[0] https://pkg.go.dev/testing/synctest

This usually doesn't work, and in the end all they can do is complain about behaviours that their license choice explicitly allowed.

[0] https://en.wikipedia.org/wiki/AMD_10h

That's funny, for me that's exactly the best GUI out of the box. I actually did some tinkering to reduce the GUI parts even more, and added more keyboard shortcuts.

The structure, probably. In gendered languages objects have a grammatical gender, and "structure" is feminine in at least French, Italian, and Spanish (they all derived from Latin "structura", which is feminine). Non-native English speakers will sometime carry over a noun's gender when writing in English.

No. If a module's go.mod files declares go1.21, the compiler will use go1.21 semantics when building it, even if 1.22 has already been published and the module is being used from a 1.22-enabled program. This is explicitly mentioned in the blog post.

I've been a contributor since the Go compiler was a tree-based C program and I've never heard anyone say that. What they said (and it's in the Go FAQ page) is: "At the beginning of the project we considered using LLVM for gc but decided it was too large and slow to meet our performance goals." [1]

If you're building a language with the explicit goal to make it compile fast, it's objectively true that starting out with LLVM is not the best approach. You'll get incredible runtime performance of the generated code since the early days, but NOT fast compilation. The Go makers choose a different tradeoff.

> and they end up building their own SSA IR

They switched to a SSA IR because it was a good idea to begin with, after an initial phase with the tree-base prototype. I've also never heard anyone argue that "SSA is bad", despite what you claim. The first compiler was tree-based because they reused a simple tree-based C compiler from plan9.

> building their own SSA IR and spending a bunch of time trying to bring compilation time closer to what it was before as it made everything much slower

The new compiler was ported to Go (machine-rewritten from C) and that's the main reason it was ~2x slower than the old compiler. It's not due to the switch to a SSA-IR.

[1] https://go.dev/doc/faq#Implementation

That's kinda my point? free is there and does something, but also silently does nothing if you violate a fairly subtle invariant. Kinda the definition of "error-prone", and the whole blog post seems to prove it, as the leak was essentially caused by the author not realizing that free was silently doing nothing. I understand why bump-allocators exist, I'm just saying this particular one's API has quite the footgun.

So no, that's not the actual size of "the Go runtime" for any meaningful definition of "the Go runtime".