toolchains_llvm

In my previous position, we accomplished this using a "dev docker" (which I covered generally in a previous post: https://blog.fahhem.com/2023/12/dev-onboarding-then-now/) that's based around a specific version of Ubuntu (20.04) so the glibc is tied to that. In another project, I used a hermetic C++ toolchain (you can use gcc with https://github.com/f0rmiga/gcc-toolchain/ or clang/llvm with https://github.com/bazel-contrib/toolchains_llvm) that pulled in its own (locked) version of glibc and lld, etc.

The biggest feature I want out of Starlark the language (not Bazel the build system) is to allow optional type annotations. They don’t have to do anything, they don’t have to specified, it just needs to be syntactically valid to put type annotations somewhere. If there were syntax for type annotations that tools like Bazel ignored, it would be possible for some enterprising soul who’s forced to use Bazel at work to throw up an initial prototype of a type checker and a language server for Starlark in Bazel. The language is not that complicated that a type checker couldn’t be written by a hobbiest. My biggest frustration when using Bazel is not even Bazel—it’s the fact that when I’m looking at code like this[1], everything comes from a single, unannotated `rctx` variable that has no type annotation. So when I’m trying to read the code, it’s