My negative views on Rust (2023)

And most of C++’s language complexity doesn’t come from “large scale industry deployment”, it comes from implementing a feature in a half-assed way, then updating it, but then the old feature needs to be kept around so all the libraries need to deal with two ways of doing things. Then something new and better comes along, and it needs to deal with three ways of doing things.

Meanwhile, developers get frustrated with how difficult the abstractions are to use, and end up carving out their own codebase-specific coding standards.

On Rust’s side, there’s 10x the emphasis on making things easy to use, so developers converge to consensus on pretty much the same modern style.

Just look at project management. Before I even write a project, with C++ I’m hit with choosing between a barrage of build systems and package managers, none of them particularly good. Will I use cmake and Conan? Then I’m stuck writing several lines of boilerplate before I even get started in a weird non-imperative language.

In Rust, I type cargo init and I’m ready to go.

C++ has basically completely fallen down when it comes to language design, and from what I’ve seen, is simultaneously in denial that things are so horrible for its end users (Bjarne Stroustrup iirc putting out an essay where he claimed “C++ is fine for any project I’m concerned about”) and suddenly trying to rush to (badly) copy features from Rust, and only recently coming to the realization that it really needs to abandon some of its fundamental precepts to stop self-sabotaging by carrying around massive amounts of baggage that nobody should be using anymore.

Meanwhile even the White House and other government agencies are saying “please use anything but C or C++”. Because ultimately, no one writes anything close to modern C++, and even modern C++’s memory safety guarantees are painfully minimal in exchange for massive amounts of code complexity (you still have to track every pointer lifetime yourself, and every safety abstraction is opt-in, so you still have to have the expertise to not cut yourself, and every codebase is unique and different in its conventions, which precludes running any kind of static analysis that could rival Rust without significant time investment).

It’s just..really bad. The only way Rust will get there is if it falls prey to the same feature hoarding as C++

But Rust already has a deprecation-and-removal process for features, as well as an edition system to provide backwards compatibility for old code, and standardized tooling for linting that’s 10x better at telling you how to refactor than anything I’ve seen with C++.

And god help you if you have an error in your code, because the C++ compiler will probably dump you out with a dozen irrelevant errors of dense template code you need to skip over, while with Rust you’ll make a mistake with lifetimes that will generate a text visualization of what you did wrong with the compiler pointing to what you need to change. Plus the Rust program will probably just run the first or second try, whereas the C++ program will segfault for the next ten minutes or so, because all the strictness in Rust means the complexity is more meaningful and less performative.

Look at what people are learning in schools today and I bet they’re still starting with new and delete or even malloc and free rather than things like std::make_unique and std::span.

The whole C++ ecosystem is basically predicated on nearly everyone having incomplete knowledge and doing something different and having to support or account for infinite combinations of features, whereas Rust has a higher barrier to entry but you can presume that pretty much everybody is using an idiomatic set of constructs for a given edition.

Anyway, sorry for beating that over your head. I started with C++ around the time of Visual C++ 6, and to me it’s absolutely shameful at how bad the language has gotten. Whole ecosystems (C#, Java) and subsequent ecosystems (Go, Rust) have arisen in response to how bad people have it programming in C++, and despite two decades of people running away from C++ to create their own general-purpose programming language, so many proponents of the language seem to still be in denial. They’ve simply shifted the goalposts from C++ being the general-purpose programming language to it being a “systems” language to rationalize why the vast majority of developers don’t use it anymore because it refused to evolve.

I see people these days comparing it to COBOL, that is, it’s not that anyone wants to use it for the merits of its language design, it simply has incumbency status that means it will be around for a long time.

The thing about Rust abstractions is that they’re a lot more useful and forgiving than C++.

Eg: In Rust, I cannot accidentally use an option incorrectly and have the program compile. When it fails to compile, there’s a good chance the compiler will suggest how I could do what I wanted to do.

In C++, if I dereference an optional without checking it, I’ve triggered “undefined behavior”. The program will probably just segfault, but it could also return a bogus object of uninitialized memory, but technically it could overwrite my boot sector or call a SWAT team to raid my house, and still be in compliance with the C++ spec.

Thus when considering code written in Rust, I mostly need to just consider the happy path. With C++ I need to pedantically check that they used the constructs correctly, and consider many more runtime paths due to how lax the language is.

If I see someone dereference an optional without an if-guard, I now need to backtrack through the logic of that entire function to make sure the program doesn’t crash. If I see someone use a destructured value from an Option in Rust, I can rest easy that unless they used unwrap() somewhere, the compiler has done that for me.

This scales well for larger abstractions, because if I’m not actively digging into some code I can treat it more as a black box where it interacts with the code I am working with, than as a box of firecrackers that might explode if I do something unexpected with it.

If I use a header file, as any pre-C++-20 library will (have the major compilers implemented modules yet?), I am SOL. I am specifying a text-import of that library’s code into my code. You’d need an “extern C++11”.

As for comparing them at 10 years old, apparent language size might be similar, but in terms of program complexity C++ would be DOA.

You’re telling me it takes an equal amount of time to learn these languages, but with Rust I can write code that works on the first try, while with C++ I have to account for data races and memory mistakes at every level of my program? Why do I, a 90s programmer dealing with OSes without process separation and soon the dotcom boom, want to touch that with a 10-foot pole?

Java and C# would not exist. There’d be far too little value proposition with an alternative to C++’s memory-unsafety to justify the development of a whole new language.

You’d probably see the equivalent of Python and JavaScript (probably named RustScript following the logic of the time). There’d probably be a Go equivalent developed, ie “language that compiles fast and runs almost as fast as Rust that stresses language simplicity”. Language expressiveness and simplicity are at odds with each other and there are uses of both.

To be fair, Rust was developed with the last 30 years of programming in mind. But the thing is, memory safety kept on being a central issue of the languages that followed.

The next big design issue will probably have more to do with people trying to use LLMs as a first-class programming language. Eg something that’s easy for LLMs to write and humans to read.

Or something to do with heterogenous computing resources all sharing the same “program”. However here Rust seems already positioned to do well with its compile-time tracking of asynchronous resource dependencies between threads of computation, and procedural macros that can invoke an external compiler.

So I’m not sure that conventional language design is going to change the path it’s been on for the last 30 years until the human side of that interface starts to significantly change.

Most of the language design considerations we’re discussing boil down to “make things manageable to humans with limited memory”. If cybernetic augmentation or bioengineering sharply expands those limits, I suppose it could change the direction. Otherwise it feels like things are going to naturally cluster around “complex correct thing” and “simple iterable thing” because those are the two strategies humans can use to deal with complexity beyond the scope they can keep in their head at once.