I think the answer to this is roughly ... the content of an applied statistics degree, or a research methodology practicum. There are so, so many ways that quantitative measurement of human phenomena can mislead, from measurement error to conflation between trends/sample sizes/effect sizes, to p-hacking, to good old bias (in interpretation or in deciding what tools to use to smooth or normalize data), and thousands more.

Pedantically, colored functions in Go might be ones that produce their output on a channel rather than returning a value. Then, you need select/for-range/<- to get their result, similar to “await”.

Practically, the runtime’s ability to suspend and move goroutines around means that the impact of that (niche/rarely appropriate as a default approach) kind of coloring is much less in Go than in other languages.

That has no propagation up the stack at all. Whether a child function does or does not use channels has no effect on the parent.

Case law citation needed.

You don’t have to have all of that material published and polished before you turn your website live. It literally is stuff that belongs on your marketing Wordpress static site or whatever.

If the founder had done a big b2b ad blitz without that stuff, sure, some griping might be warranted. But this isn’t that: some fledgling product website went viral-ish in HN and you’re complaining about the digital equivalent of the paint not being dry.

It’s rife with “and that’s the important thing. $thing”-type constructions. Human writing uses those much more sparingly and doesn’t separate them into two sentences as often. It has a lot of “subject change: teaser” constructions, too. And overuse of bold and restatement.

Could it be human? Sure. But it doesn’t seem likely to me.

“It’s worth being honest about…” yeah, no.

...crash?

Seriously: crash if your dependencies aren't available. There are better ways to do optional dependencies. ImportError ain't it.

What is the right way to handle an optional dependency?

I don't understand, sorry. How does declaring an optional dependency in a toml file solve the problem of accessing the symbol in your code?

Also, you need something that works for simple one-file scripts, not just a whole package or project.

Declare the optional dependency and then import it unconditionally if the optional is installed. You can conditionally import a file you control based on asking whether an optional specifier was installed, either by probing the filesystem, a CLI argument, an environment variable, or whatever folks come up with for https://github.com/pypa/packaging-problems/issues/215. The "if: ... import" laziness-defeating clause only applies to your stub module, and the imports in that module are unconditional and thus will work with analyzers/laziness/etc.

If you need something for one-off scripts, use https://docs.astral.sh/uv/guides/scripts/.

I think this import flow tends to be the canonical one.

I might recommend doing something like importing from something like `numpy.version` (or some other "random" very small utils package) so that the work done on file load is still fairly small.

Common? Yes. Canonical/ideal? No. Optional dependency specifiers in your package metadata is a much better way to go. You can use those even if you don't publish your package as an artifact; `pip install -e .[optional-thing]` should work, or can be made to, easily.

That's only part of the puzzle. Your program needs to branch on whether the dependency is installed or not!

"Oh you don't have optional dependency? Then do X" needs to happen at runtime right?

I explained further here: https://news.ycombinator.com/item?id=49604462

In my preference order: an explicit CLI option/envvar which requires the optional dep, a flag file on the filesystem, or an ImportError attempt if you absolutely must. Use a stub/trampoline file in the conditionals so that static analyzers and laziness analysis on that file itself still work.

It's not clear such a thing even exists in general though. It's certainly not guaranteed by packages.

What would that be for numba?

Yep it's not clear, and a bit of a case-by-case thing. Fortunately most codebases only need to do this in a handful of spots so you can really "just" look at a package and find a file that probably is safe.

For example, numba._version only imports standard library stuff so is probably good enough here[0]

It would be nice to have general querying capabilities here, of course. I just think that in practice there's at least a halfway-decent workaround in almost any real situation

[0] https://github.com/numba/numba/blob/main/numba/_version.py

I’m not sure either is “how names are established”.

This is a pretty mushy area, philosophically. Is a name what you think something is called (I think our planet is called “Bloop”, but nobody cares) what a lot of people think something is called (“Indian” in reference to indigenous Americans is a famous example of that going poorly, as are many racist epithets), or what an official body says it should be called (“Palestine”, “New Zealand”, and “Taiwan” have entered the chat)?

I don’t think popular usage is any more “truly authoritative” for a name than other sources.

I interpreted GP as referring to the higher quantity of questionable software in the Play Store, not custom .apk installation.

It always could.

not sure it always could. we had to continue using conda for binary packages like cudann, or anything where a wheel wasn't available (nvidia now has Jax-compatible wheels for cuda packages, but it didn't before)

You're asking for something different here. What conda does is package all binary dependencies (e.g., libpq, cuda) that normally should be dynamically linked and provided by your OS.

The pip ecosystem (including uv) doesn't encourage this. Although you could and many have, the build tools don't support it as first class.

For why? Ask what happens if you want an updated version or specific version of CUDA? The library author must add support for runtime linking or users would have rebuild the entire conda package.