I think Go focusing on certain aspects of tooling and deployment early on might be considered improvements on C#/.NET (some, not all). There are aspects of the Golang standard library that are better designed for purpose than C#/.NET (Again even this has to be nuanced because quite a few 3rd party libraries in .NET were basically “standard”). .NET was hobbled by being effectively Windows only, not because of C#.
> Part of what I mean by "making a big impact" is affecting how we think about programs, which Rust has done and Go has not.
A hallmark of Go is the deprioritization of expressiveness compared to its contemporaries, and I argue this does just as much to affect how one thinks about programs.
A further hallmark of golang is CSP, which of course was nearly a 50 year old concept but not something mainstream at the time (which describes just about everything is Rust but perhaps for a number <50). And IMHO, Rust did not get this one right, async is ugly.
I can’t read your mind and this is too vague. It’s a matter of perspective but I’m not sure what the big new paradigm in Rust you are referring to. Rust doesn’t really break new ground either, which is partly why it isn’t less obscure, widely used languages are almost never the debut of new features, they have been cooking in research and more obscure PLs for years and years. It is at the end of the day still an imperative/mutable language. It just uses a hell of a lot more PL features than Go.
If we’re talking about the borrow checker, which was plan B (plan A was GC), I challenge the idea that it affects how we think about programs. The concept of ownership, lifetimes, aliasing and move semantics were already thought about heavily in C++ prior to Rust (many things codified in the 2011 standard). You still have to think about these things, it’s just that C++ lacks the ability to enforce it. And of course Rust lifted most of the design from Cyclone. There are few large scale Rust projects that can avoid RC either (or some other dynamic lifetime or surrogate reference copium).
You also haven’t mentioned Swift which in many ways is more clever than Rust. Its adoption is more hobbled by the circumstances surrounding its specific corporate driven ecosystem. Maybe that will change.
The new paradigm Rust introduced was compiler-enforced memory and concurrency safety in a non-GC language. I'm not saying nobody had thought about these things before, but as you said, C++ can't enforce any of it. Rust can.
When Python hit the market, it was competing with C++ for web dev, and the difference there is massive, because Python is dramatically simpler and more expressive. Java was fast, cross-platform and GC'd, and that also makes a massive difference as compared to C++. When you compare Rust with C++, Rust entirely eliminates dangerous categories of errors without the cost of a GC, and that's a big deal too.
Conversely, if you want to discuss Go vs C#, you can have a long talk about expressiveness and simplicity and it'll ultimately be mostly subjective unless you have a specific use case in mind. I like Go because it's less invested in object orientation than C# is, but Go isn't doing something transformatively new. It's just kinda nicer in some ways.
If Rust didn't guarantee memory safety, it would never have gotten into the Linux kernel. It'd fall into the same category as Go, Swift, D, Clojure, Nim, Zig, and every other programming language with good ideas but no killer value proposition. If Go didn't have Google's backing, it would never have seen mass adoption, because language choice is conservative. Picking something new is risky, and unless it has a big benefit or a big backer, people are going to avoid it where possible.
The design and mechanics of goroutines are pretty unique to Go among its commonly used contemporaries.
> The new paradigm Rust introduced was compiler-enforced memory and concurrency safety in a non-GC language.
Ada and SPARK? Clearly Rust has become more “mainstream” and popular that’s not the argument (though both have had significant niche commercial success, they’re not obscure), just that the narrative comes across a bit reductionist.
Not that Go is a bad language. It has its place. I recommend it for embedded systems and as an option for systems programming.
