dzbarsky

This was nowhere near the top submission. But even if a solo engineer could get a top kernel, you don't think that having thousands of engineers, infinite tokens, and stronger models than are available to the public would give the labs a significant edge?

See my comment above - the common language rulesets work in similar ways as Buck(2), AIUI. (Except bazel has features to consume external dependencies without vendoring, as opposed to Reindeer approach for example). Another difference is that since Bazel has much more adoption across the OSS world, there are more viable choices in language implementation rulesets, as opposed to Buck's prelude.

This comment gives off the impression the bazel just wraps cargo/pip/npm invocations, which is incorrect.

First of all, bazel does not handle any of these languages/ecosystems itself. Such logic is delegated to language-specific rulesets, of which there are multiple implementations with different tradeoffs.

For python - https://github.com/aspect-build/rules_py parses a UV lockfile and does not use either UV or pip at build time.

For rust - https://github.com/hermeticbuild/rules_rs parses the cargo lockfiles but does not invoke cargo itself.

For js, https://github.com/aspect-build/rules_js parses the pnpm lockfile but does not invoke pm at build time in the commonly used configurations.

While it's true that bazel allows to patch all dependencies on the fly, in my experience many Bazel users do try to contribute back, because managing stacks of hundreds of patches across all your dependencies isn't particularly fun.

Care to elaborate how OpenAI is failing in your opinion?

Check out https://github.com/cerisier/glibc-stubs-generator

None? All of these things were in flight for a while and given Zigs anti-AI stance i think they wrote off Bun ever since the acquisition

Look into Bazel, a very standard build system used at many large tech companies. It splits fetches from build/test actions and allows blocking network for build/test actions with a single CLI flag. No hassle at all.

The fact that you haven't come across this kind of setup suggests that your hundreds of CI systems are not representative of the industry as a whole.

https://github.com/dzbarsky/static-clang should let you build it in a reproducible way with a single command.

Even if you ignore all the other benefits of type annotations, merely being explicit about the types of parameters your function accepts helps people reading your code.

If you're going to make the argument that you can just add comments with the types - well then that's exactly what mypy is doing, but if you do it in the mypy format you get static analysis of your types for free.

Static typing and unit testing aren't mutually exclusive.

> What does mypy do if you make a call from code with type annotations into code without? Or vice-versa?

It's not able to analyze across such boundaries, but as you expand the set of typed code you get better and better coverage.

> Has anyone ever gotten paid to add annotations to code that works?

At Dropbox, we're starting to add type annotations to code. We're confident it will catch many bugs at lint time. Source: I work at Dropbox.

> Personally, I view type systems as like a safety line when doing work on a roof, and optional typing as having a line that might or might not be tied off.

At least it has the possibility of being tied off and catching you. Better than definitely not having a line.

This is why you should use containers for running binaries on user-supplied data.