Pretty much that. Safety gimmick aside, Rust is (mostly) what C++ would have been if designed with modern knowledge of programming languages theory and compiler practice in mind. It’s not like Rust brings that much novel things to the table, it is has its roots in ML and friends that have been around for decades. It’s just that we didn’t know how to make ML-type languages fast in the 80-ties. So C++ designers did the best they could given the time period and the circumstances.

Safety is what brings me to the table. I'm not a genius, I'm not a 10^Nx coder. I'm a guy who wants to make neat things. I've been doing this programming thing for a while and have had my forays into C and C++. I've spend a lot of time in python and go too. The thing I like about rust is that it gives me the level of control C and C++ do without all the mental overhead of remembering "is this for reading, writing, both? none of the above?" for each and every pointer and variable. It's written down in the type signature and then the compiler verifies that for me.

That saves me time and energy - time because I don't have to wait for my misunderstanding to manifest weeks or months later at runtime (in a worst case) and energy because my editor will fill show me signature information inline - I can just glance up a few lines if I need to remind myself of what the constraints of a variable are.

I know for a fact that I don't strictly need this - I am capable of writing C that preserves those contracts, at least for smallish projects. It just takes much more time and effort. And in big projects even the "gods" have trouble with getting it right every time.

In fact, I've been willing to tackle much more difficult problems professionally that I would have shied away from (outside a research setting anyway) without the guarantees rust tooling provides.

The whole "safety is a gimmick" angle always brings to mind a bunch of 9-fingered carpenters sitting around trying to convince their boss not to buy saw-stop because you just gotta be careful using the tablesaw.

If you're capable of writing C that gets things right, even if in just smallish projects, chances are good you could crank out bullet-proof C++98.

So ignoring the main point of Rust, it's (mostly) what C++ would have been...

You could do this with basically any language advancement. Ignoring classes, C++ was (mostly) what C... Ignoring GC, Java was (mostly) what C++...

Also, a language is more than the sum of its parts. If it weren't, kitchen sink languages would be the best ones out there, because they have the most parts.

> So ignoring the main point of Rust, it's (mostly) what C++ would have been...

"And the sanitation"

"Oh, yeah, the sanitation, Reg. Remember what the city used to be like?"

Yeah. All right. I’ll grant you the aqueduct and the sanitation are two things that the Romans have done.

I am so glad someone got where I was going with that!

I think Go has done a lot in the last 10 years to facilitate a mindset shift in our industry to "less is more". For a long time, Go was (and probably still is) ridiculed for eschewing many of the features that programming language practitioners have dreamt up over the last several decades, but as more people have tried the language in earnest they have to grapple with the fact that there are some advantages to not having to grok an enormous feature matrix even if they disagree with Go's specific feature set. The conversation has advanced beyond the "if you don't like a feature just don't use it" justification for kitchen sink languages.

Is go really used a lot?

I know some larger corporations use it but I don't hear much about it otherwise. The most obvious plus side I hear about is the small memory footprint and fast boot time which makes it good for functions-as-a-service.

It is also getting generics know which makes it sound like the simplicity was a lie or will be a lie.

Except the critiques for not including generics were valid and the designers finally had to admit they should be in the language. "Less is more" really just meant "omit anything newer than we are used to."

You're implying a contradiction (and a weirdly adversarial one) where none exist. "Less is more" never implied "we will never change anything" or "we got it exactly right with v1". Yes, Go launched without generics so the developers could figure out whether they were really necessary and how best to add them.

I'm sure many will say "well I could have told them they were necessary from the start", but the overwhelming majority of these people are just lucky--they picked a conclusion that happened to pan out. And we know this with certainty because most of these people make arguments for generics where they are neither necessary nor useful--they're merely familiar with languages with generics and they reach for them on first sight of a problem. These people also can't articulate the advantages of not having generics--namely the unreasonable productivity that accompanies everyone writing the same code absent personal flourishes. The very fact that these people consider it a no-brainer that generics were the way to go from the start betrays their error--generics are only just worth their costs, and the emphatically pro-generics camp can only rarely articulate those costs due to their inexperience with other kinds of programming.

My stance is adversarial because Go has wasted an enormous amount of people's time. Not having generics was pitched as a feature, and they spent a lot of effort bragging about how fast compiles were without mentioning that this was because their optimizer was pitiful rather than some great property of the language design. They ignored just about every major development in programming language research in decades and rereleased something they'd already built before, just laundered under Google brand this time to ensure popularity.

The value of generics is obvious if you ever write your own container. Go had pre-Java-1.4 level type safety for any container not specially blessed by the creators. Prior art on how to do them without significant compile time cost was already established by Java, not even some obscure academic language. Go was dumb from the start.

> Go was dumb from the start.

You betrayed your own credibility. As previously mentioned, those who can't articulate the tradeoffs associated with the generics question lack qualifications--they are amateurs, and their opinions aren't interesting to professionals. Consequently, for lack of interest, I'll leave you to your opinions.

I don’t know if it’s Go that’s been that influence more or if it’s the generally increasing profile of functional programming languages (especially JavaScript!) which have always taken a more minimal approach to features.

> Also, a language is more than the sum of its parts. If it weren't, kitchen sink languages would be the best ones out there, because they have the most parts.

I've been hugely interested in this recently, at least part of what you are describing is programming language affordances.

To be fair C++ is backwards compatible with C. That meant there was a large amount of design space they couldn't explore. Rust not going there gave them the ability to do better.

That intent to be "backwards compatible with C" doesn't stretch so far as to say, provide any way to spell valid symbols from C.

Imagine you have some C that has (for whatever reason) named two important functions "class" and "fn" which are completely reasonable C symbol names. In C++ that word "class" is reserved, so you can't name symbols class, but, that is what the C symbol's name is so too bad? However in Rust, even though fn is a reserved word there's no problem referring to that symbol, you just have to spell it r#fn meaning "the symbol named fn" as distinct from the keyword fn.

C++ is no longer backwards compatible with modern C.

C++ compatibility has improved. E.g. I've noticed that C++20 has designated initializers for struct members, which were introduced in C99. So now if you're writing C that has to compile as C++, you can use C99 designated initializers, if you're OK with requiring C++20.

Like Ada in 1983, or Modula-3 in 1990's, but I digress.

Are there other languages with compile time GC prior to Rust? I thought that was a pretty novel feature. I recall an ML variant with region inference, but that was just an optimization I believe for it's runtime GC.

Edit: MLKit was the ML dialect I was thinking of - looked it up

Nothing that has hit the mainstream like Rust. To my knowledge, Rust's lifetimes take influence from a language called Cyclone.

Cyclone I believe (has been a while) used region based inference like MLKit I mentioned. I'm not sure off hand if Cyclone was influenced by MLKit or the other way around. Cool tech, but Rust took it to the next level by making it pure compile time.

Pony has some references how they came to it before Rust. Easily doable with escape analysis. Just that pony added a proper GC protocol for it's threaded actors and proper concurrency safety by avoiding blocking IO.

More important is tracking the owner, which perl6 used.

Interesting, thx for the response. Pony is on my list of languages to do a deeper dive on at some point in the future. It has some interesting ideas I thought when I last glanced at it.

Could you elaborate on what Perl6 does? I thought it was just regular old GC.

What exactly do you mean by compile time GC? Various techniques like compiler-optimized GC have been around for a while. If you are looking for mainstream stuff, Apple’s automatic reference counting for Objective C comes to mind (has been shipping since around 2009)

I mean that Rust knows exactly when something will be deallocated at compile time due to its lifetime system (for things that are single ownership, Rc/Arc excluded). In contrast, ARC does compiler assisted increments/decrements if I recall, but still uses runtime ref count to know if something needs deallocation.

Ah, I see. True, Rust has a more restricted model that allows it to track lifetimes more precisely. As far as I know, Clang will omit reference counting if it can be statically determined but of course it has fewer optimization opportunities here. In the end, the two approaches are not entirely dissimilar: ARC uses static analysis to detect dependencies and will fallback to dynamic RC n complex scenarios; while Rust enforces certain rules that only allow most basic dependencies and requires the user to mark these by using dedicated tools.

C++ programmers where selectively implementing borrow checkers at runtime decades ago (see library omnetpp as an example). Moving those borrow checkers to compile time with templating is possible (but people did not do it because the borrow checking could be disabled after testing and no overhead would be paid neither at runtime nor compile time). That Rust implements borrow checking as pillar of the language I think it is great.

> Safety gimmick aside

Safety is a gimmick?

The initial C++ designers produced a language which was still very understandable, and in which you could easily write bullet-proof programs.

In C++98 (the first ISO standard version of C++) you can fairly easily organize a program such that any low-level activities are confined to classes that are almost impervious to misuse by the rest of the application, so there will be no memory misuse or leaks, or out of bounds arithmetic.

If Rust takes off, there will be widespread use of its unsafe parts by programmers who are under pressure to deliver something and take the obvious route of telling the machine where to put what bits, exactly like what C++ programmers have been doing.

But tools like cargo geiger will tell you exactly where the unsafe parts are so you can progressively remove them. Also safety is usually terser in Rust, so programmer laziness usually leads to safe code.

For me Rust and C++ have similar complexity in terms of learning curve and the main difference is where you spend your time. Rust programs have a tendency to work on the first or second try provided you can get them to compile. In C++ it’s easier to rig something up that technically meets the portion of the language spec that the compiler enforces, but who knows if it actually does what you expect and the debug cycle is much longer. Debugging is generally more frustrating and time consuming than simply conceptually massaging your implementation strategy until it fits Rust’s model, at least for me.

Also Rust is pretty mainstream at this point.

It's already happened:

* Discord replaced Go with Rust[0]

* Microsoft's VS Code uses ripgrep for searching through code which is coded in Rust.

* npm is using Rust

* Cloudflare (I believe for their serverless platform)

* Figma (unsure how)

* And I'm sure countless more, hell one of my former employers is using it for mission critical work in place of C++

As you can see Rust is used by some pretty massive services, even if you don't use them, millions of people do. In fact VS Code is the most surprising to me I had no idea it was using it all along. I also believe Atom was looking into using Rust to improve performance for Atom but I'm not sure if it was just native code in place of JS / HTML.

I would argue Rust has entered the mainstream, it will be slow to be far more common, but it is getting there. I will not be surprised if we see it all snowball once there is a full feature web framework like Django or Rails but for Rust with all the batteries included. Go took a little while before it became as big as it did, and some would naively argue Go isn't mainstream, while they deploy code using docker to their kubernetes cluster (for those who missed it both of those tools are coded in Go) or what have you.

[0]: https://discord.com/blog/why-discord-is-switching-from-go-to...

I work at a 100% Rust shop, so I’m well aware that it’s being used for real stuff. I agree with you, but it still has a long way to go before it’s as mainstream as C++ and has a similarly mature ecosystem.

I’m impressed with the adoption of both Rust and Go. Seven years ago I wouldn’t have been surprised if Rust had just become a language for PL enthusiasts and Mozillians, and that Go had just become a language for worse-is-better enthusiasts and Googlers. :)

Add:

* A build system

* A package manager with powerful features

* A toolchain manager for getting different version of compiler etc

* Code generation in the language

* Build scripts in the language

* A test framework

And when I write "a test framework" or "a package manager", it's not just that it has one, but that it has one.

On the mainstream question, since I told friends and colleagues I'm learning Rust, I get a lot of statements like "I think I should learn that too, it looks like its going to take off". That is a strong signal that it has already taken off. Like once regular investors have heard of some stock (or bitcoin).

I have many colleagues who have foresworn C++ but are liking Rust (myself included).

Rust already is mainstream. It's being adopted at a very impressive rate and is running in production in innumerable places, serving billions of users.

I think you make that point better than the author.

The author talks about drills and holes, but to me, the conversation is more analogous to cordless drills versus regular electric drills - they both can do the same thing, but have different characteristics about the process of drilling the holes.