I just so don’t get the comparison of a high level language like Go to a goddamn system programming language like Rust. They are nowhere in the same league.
Rust’s solution has to account for the true variability and complexity of the underlying platform, as otherwise it would be a bad low level language, while go can/could easily hide it behind a supposedly clever abstraction.
I don't understand this weird, embarrassing subset of Rust programmers who talk as if they're working for the first time with manual memory allocation and it's a revelation that somehow sets the language apart from all others. In fact, the overlap between problem domains for Go and Rust is immense. There is no language that has done more to halt and roll back the progression of memory-unsafe C/C++ than Go, which is, in fact, a systems programming language --- a term that does not in fact mean "usable in the Linux kernel" (a definition that would also have excluded C++ at times).
They are eminently comparable languages. Go gets some stuff very right, and so does Rust.
Then you can just as well expand the definition of systems programming languages to JS, Java and Python.. sure, don’t get me wrong, there are very very few niches where a managed language can’t be applied (a whole OS can be written in GCd languages) but there is a few and in these cases Go is simply a no-go (sorry for the pun).
Java, yes: I have worked on systems, as have others on HN I'm sure, where Java is the bottom level language: there's a JVM, and below that there's hardware, and that's the whole story. JS and Python, not so much. This isn't complicated: there is a general agreement about what "systems programming" is, and the only people who make a huge deal out of the divide between managed languages and unmanaged languages are, again, this weird embarrassing (tiny!) subset of Rust people. I think the Rust core team people must wince about these arguments.
It's not as if Java and Go programmers don't understand the value of "zero-cost abstractions" (a term from the same 1990s vintage as the first version of Java) and manual memory management. I don't see a lot of serious energy being applied to getting Go running in the Linux kernel. To my eyes, the only people who really seem uncertain about Rust's value are the "those aren't systems programming languages!" people. Rust is not good because we finally have a language to do systems programming in; it's good because it's a good, interesting language on its own merits.
Just by way of example: pay attention to how Niko Matsakis answers the first question ("what is systems programming") on this panel with Bjarne and Alexandrescu and Rob Pike:
(It's hard for me to disagree with any of them, except maybe that I don't at all agree with Alexandescu's argument that systems programming is defined in part by being able to forge pointers from integers --- something, of course, that you can do in both Go and Rust [unfortunately]).
Rust’s solution has to account for the true variability and complexity of the underlying platform, as otherwise it would be a bad low level language, while go can/could easily hide it behind a supposedly clever abstraction.