I don’t want to be mean, but this is quite a lot of misinformation. For the benefit of other readers: this post makes a large number of specific claims very confidently, and almost all of them are wrong.

It takes time to make sense of this subject and it’s normal to get things wrong while learning. I just don’t want other people to go away thinking that closures have something to do with memory safety, etc.

deleted by creator

I greatly fear refactoring in Rust. Making a single conceptual change can require a huge number of code changes in practice, especially if it’s a change to ownership.

Refactoring in languages like Java and C# is effortless in comparison, and not error prone at all in a modern codebase.

You can use RC and clone everywhere, but now your code is unreadable, slow, and might even have memory leaks.

You can use slotmaps everywhere, but now you’re embedding a different memory model with verbose syntax that doesn’t even have first-class references.

I don’t even dislike Rust; I recently chose it for another project. I just think it has clear weaknesses and this is one of them.

What a whirlwind!

Also, Rust is perhaps, the shittiest, slowest compiled language out there. Even TCC has a leg up on it.

TCC is written exclusively to compile quickly, not to do any real optimisation. There is no conceivable situation in which TCC output will outperform equivalent Rust code.

If you really like how Rust handles its syntax, use a real functional language like OCaml

Rust takes inspiration from OCaml in almost every area except syntax. Close to zero syntax similarly.

In fact, SML compilers like MLton are sometimes faster than Rust.

Lmao, this is a classic line from ~2009 message boards, but with “C++” swapped out for Rust.

Almost every single thing you said is wrong, but in a way too precise to be attributed to random noise. Like scoring zero in a multiple choice exam. I don’t know if you are some kind of performance art troll, but please continue. I’m an instant fan of your work.

Is it really fair to say retain doesn’t compose as well just because it requires reference-based update instead of move-based? I also think using move semantics for in-place updates makes it harder to optimise things like a single field being updated on a large struct.

It also seems harsh to say iterators aren’t a zero-cost abstraction if they miss an optimisation that falls outside what the API promises. It’s natural to expect collect to allocate, no?

But I’m only writing this because I wonder if I haven’t understood your point fully.

(Side note: I think you could implement the API you want on top of retain_mut by using std::mem::replace with a default value, but you’d be hoping that the compiler optimises away all the replace calls when it inlines and sees the code can’t panic. Idk if that would actually work.)

A bit tangential, but if the US government really commits to pushing big tech firms to migrate to memory safe languages, where would that leave Zig?

It seems completely implausible to rewrite all the deployed C and C++ in the world any time soon. Even so, the uncertainty created by a top-down push might be enough to stall adoption of an unsafe language.

I just wondered if anyone knows whether that story has affected the plans of the Zig maintainers at all. Or whether there has been any spike in Rust job postings?

Haskell has very famously not solved this problem. As in, pretty much every academic paper published on the subject in the past 15 years includes a brief paragraph explaining why Haskell’s effect monads are terrible.

Also, it would be surprising for Rust’s developers to be scared of monads when Rust already has monads as a core language feature, with special syntax support and everything.

I wonder what the planned scope is. C++ is such a fundamentally uncooperative language.

I appreciate your perspective, thanks for taking the time to share it!

I also agree with most of your points in favour of Rust. It is clearly the biggest programming language design breakthrough in decades.

I know Rust has these features, but they are intended to be features of last resort and it shows. It’s not a criticism; Rust pushes people relentlessly towards safety and performance, and is extremely successful at that.

I am imagining a language more like Pony, but with less of a focus on the actor model. I could use a language like that to write a high performance game engine with no GC pausing issues, and then write very high level gameplay scripts on top of it in the same language.

You could do that in Rust, but the Rust game engine space has already made it clear that most people feel the need for a scripting language.

I believe you, but for it to be a fair comparison you’d need to compare to an alternative rewrite, not to the original software.

Rust has plenty of merits. It has a very readable functional style, single aliasing to reduce complexity, powerful libraries for stuff like generating serialisation code, and cargo is incredible.

However, expressing any complex graph structure in Rust is just painful, and so is refactoring code. Small changes in intent require complex reworking of data structures, because Rust forces you to be extremely specific about data layouts at all times. These issues crop up constantly in any complex project, and they really slow things down.

Although Rust is a nice language, you can now write functional code with immutable data structures in pretty much any modern, statically-typed language. C#, Kotlin, Scala, Swift, etc. It will be concise, quick to write, easy to modify and pretty fast at runtime.

Perhaps I’m mistaken in some way, but this has been my honest experience after many years using Rust.

Rust is a groundbreaking language, but it’s not without tradeoffs. There are loads of things it makes extremely difficult compared to slightly higher level languages.

I used it happily for years, but I wouldn’t recommend it for any project that didn’t explicitly need the low-level performance optimisation.

There is a huge and valuable possibility space between python and Rust. We know this because it is already occupied by many extremely successful languages (Java, C#, Swift, etc).

The value of a language that sits between C# and Rust also seems pretty obvious at this point; a language that gives you Rust’s memory management tools for optimisation, but doesn’t force you to use them for all of your code.

The biggest difference I see is allowing multiple mutable borrows, which would make a lot of things easier, but aside from that it sounds like it would have most of the same usability problems as Rust.

I’m also a bit put off when I see LLVM advertised as the primary compiler back-end these days. Pretty much guarantees slow builds.