Go is an incremental improvement over C#?? I think you’re going to find quite a bit of controversy with that take.
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.
I'm not arguing that Go wasn't well-made. But "having good tooling early on" isn't a new paradigm. Neither is message-based concurrency.
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.
I was familiar with Ada, but I wasn't aware that it had an ownership system like Rust that could guarantee memory safety. So I looked it up, and the first result was a paper called "Safe Dynamic Memory Management in Ada and SPARK" [1]. Here's a quote (emphasis mine):
> In this work, we propose a restricted form of pointers for Ada that is safe
enough to be included in the SPARK subset. As our main contribution, we
show how to adapt the ideas underlying the safe pointers from permission-based
languages like Rust or ParaSail, to safely restrict the use of pointers in
more traditional imperative languages like Ada. In section 2, we provide rationale
for the rules that we propose to include in the next version of Ada, which takes
into account specifics of Ada such as by-copy/by-reference parameter passing
and exception handling. In section 3, we outline how these rules make it possible
to formally verify SPARK programs using such pointers. Finally, we present
related work and conclude.
> Section 2: A Proposal for Ownership Types in Ada
If Ada and SPARK are now taking inspiration from Rust with regard to safe memory management, I think that's enough to demonstrate that Rust's ownership system is substantially novel, relative to Ada and SPARK.
> I was familiar with Ada, but I wasn't aware that it had an ownership system like Rust that could guarantee memory safety.
The point for bringing up Ada was more that a non-academic "memory-safe" language without GC existed for decades (predating Linux). Old school Ada doesn't use the ownership system, and true doesn't give all the compile-time safety guarantees of Rust but it does give some (and rust in practice cant't either, run the output of grep unsafe | wc on the linux/rust source tree), it also provides some affordances lacking in safe rust. Memory-safety is not some binary or univariate concept that you seem somewhat close to implying.
You could have written Linux in Ada from day one and been "safer" than C (imagine that universe).
> I think that's enough to demonstrate that Rust's ownership system is substantially novel
Well, where did anyone say it wasn't, but it certainly wasn't novel in pushing safety as a first class concept for a low level systems language. The fact that it is as (deservedly) successful as it is must be due to other factors.
I'm not saying Ada did it first as some kind of gotcha, but Ada did it first and it does not rule the world.
Also, interesting comments from the creator of Rust.
I'll reiterate, I'm very pro-Rust. I'm just old and look at the current governance and state of corporate involvement and it gives me flashbacks to commercial Unix in the late 80s/early 90s. IIn any case, I think fetishizing the borrow checker or a specific PL feature as having much to with its success (or failure) is sort of irrelevant.
> Ada did it first and it does not rule the world.
Well I mean, Ada didn't do "it" first—"it" being whatever Rust did that led to it making such a big splash. If Ada had done that first, it would have made the kind of splash that Rust has. Rust isn't the first systems language to ever consider being safer than C, but it is the first one to have such a large impact, and I think that's a product, primarily, of its technical decisions.
> I think fetishizing the borrow checker or a specific PL feature as having much to with its success (or failure) is sort of irrelevant.
I think that's an odd stance. Why would the technical specs of a language be irrelevant to its success? I think that's probably the most relevant factor, besides an institutional backer. C# was pushed hard by Microsoft and Go got a lot of support from Google. Rust wasn't part of an major tech player's pre-existing ecosystem, though, so it had to succeed on technical merit alone. None of its ideas are really that new except the borrow checker, and most of the time, when I've seen an institution talk about adopting Rust, there's been a lot of focus on the safety afforded by the borrow checker. I don't think that can be a coincidence.
That's not "fetishization." When a programming language with one new idea and little institutional backing gains traction in the mainstream, it's probably because that new idea in particular has a lot of merit.
It did the safety thing first, or at least much earlier.
> Rust wasn't part of an major tech player's pre-existing ecosystem,
Completely overlooking Mozilla’s backing early on is too extreme. Mozilla pumped a ton of money that got Rust off the ground. And of course even now the Rust Foundation isn’t poor or something.
Despite Google employing the Go people, not really part of their “ecosystem” for years either. They really hedged on that one. Go popularity mostly grew outside of Google for years
But yes both projects have/had plenty of money. This isn’t Nim or Lua or something.
> when I've seen an institution talk about adopting Rust, there's been a lot of focus on the safety afforded by the borrow checker.
So why did they just start caring about safety this recently?
> it's probably because that new idea in particular has a lot of merit.
The point is “safety” for a low level system language wasn’t a new idea at all, it was just that the world outside did not value/demand it.
> That's not "fetishization."
The fetishization I am referring to is focusing on the memory safety so far above the type system, tooling, open community building, and even the syntax. Conversely Rust can’t manage to have an ABI past extern “C”.
Never said technical specs are irrelevant, that’s a straw man.
And finally, again this all to say, I think its memory safety story is not what is going to determine its fate and destiny in the next decade. It needs to evolve, this is more about governance than about a particular feature.
That rust in Linux depends on unstable isn’t end of the world, it’s not something to be proud of either.
I think it’s naive to think things like Carbon don’t have some competitive effects either.
To touch back on “it's still a relatively young language.” Java, C#, Swift and Go were all well established in their niches younger than Rust. But, it really doesn’t matter one whit if Rust is 5 or 35. I’m more interested in the present trajectory and where and why Rust struggles or has struggled to make inroads, not everything is fair to chalk up to just age IMHO.
I agree that Go is not an improvement over C#. In my experience the language ergonomics of C# are better than Go. I've done both in industry and am much more productive with C#. It is too bad that C# and .NET are often perceived as bad because of Microsoft & Windows. .NET core has a lot of really things going on.
Not that Go is a bad language. It has its place. I recommend it for embedded systems and as an option for systems programming.
Yeah I should clarify that Go considers itself to be an incremental improvement on the Java/C# paradigm. You could certainly argue that it oversimplifies things.
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.