No mention of CSP makes me think the author is still writing Go programs in a non-concurrent, imperative style. Used in this fashion you only get limited gains from Go's simple syntax and nice tooling. But writing using CSP patterns gets you a different experience and feel and is where Go really shines.
Go's concurrency story isn't great compared to other languages tbh. Combining channels, wait groups and mutexes (because sometimes you do need to use all three or mix/match) leads to confusion on when exactly to use what, when.
Yes. And if the metric is "confusion when to use what" then Rust (and especially async Rust) might fare even worse: Now there's multiple types of Mutexes, Semaphores, Channels: Awaitable ones and not awaitable ones. And one needs to understand how they fit into programs, and interact with all the other stuff. Most people which just pick an async Rust runtime because they read it's a great thing are having a rather hard time with this.
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]).
I always find myself reaching for the same constructs in other languages. In Rust I go with crossbeam channels and use mutexes or RwLocks when I don't need the channel synchronization overhead.
Ada had only CSP at the start of eighties and then gained mutexes to allow for more expressive and efficient patterns.
It is very puzzling for me why Go went with CSP and added a lot of language support for it like the select operator. А data type like a priority queue to post messages to a thread would serve similar purposes as CSP while allowing for more patterns and simpler reasoning.
CSP is a low level concurrency primitive that lets you implement most other systems in it if you want. Implementing a priority queue w/ message passing would be simple.
