alt Hacker NewsRust happens to be an extremely good tool. There are definitely situations where it absolutely sucks. e.g. Zed is a heroic effort, but look at the code and you'll see that we still haven't figured out how to do Rust UIs.
We may disagree on the premise that humans are generally incapable of correct and safe manual memory management, but that's a degree of distrust I hold for myself. You may have never written a memory bug in your life, but I have, and that renders me completely incompetent.
If a project in an unsafe language has ever had a memory bug (I'm looking at you, Bun), the maintainers objectively have a track record of not being capable of manual memory management. You wouldn't put a person who has a track record of crashing busses at the wheel of a school bus.
And Rust isn't the only memory-safe language. You can turn to Java, Go, C#, Type/JavaScript, and whole bunch of others. Rust just so happens to have ocaml tendencies and other things that make it a joy to read and write, so that's definitely preference on my part. One of these days I'll learn ocaml and possibly drop Rust :)
Replies
> You may have never written a memory bug in your life, but I have, and that renders me completely incompetent.
This feels overly binary. Memory management bugs is just one class of bugs, and there have been many other bugs leading to security issues or defects.
If you apply the standard "has ever written a bug" → "completely incompetent" you will have to stop using software, and if you think about it most other technology too
Memory safety is a very useful trait for a language though, and as you say provided by a whole bunch of different languages nowadays
I‘ve been writing Rust for half a decade now and I‘m firmly believing that it‘s just not good for UI. Global state and a model that lends itself to inheritance just doesn‘t fit in the language.
> If a project in an unsafe language has ever had a memory bug (I'm looking at you, Bun), the maintainers objectively have a track record of not being capable of manual memory management
That's an interesting way to navigate the world. Do you hold this attitude towards other professionals? For example, if a lawyer ever lost a case by misinterpreting a law, they have a track record of not being capable to practice laws and should be disbarred?
There were (and most likely, still are) even memory bugs in Rust standard library[0]. By your logic the standard library maintainers objectively can't handle unsafe blocks.
> If a project in an unsafe language has ever had a memory bug (I'm looking at you, Bun), the maintainers objectively have a track record of not being capable of manual memory management. You wouldn't put a person who has a track record of crashing busses at the wheel of a school bus.
If you’re serious, you should stop using Rust (which happens to contain an unsafe language): https://github.com/rust-lang/rust/issues/44800
> Zed is a heroic effort, but look at the code and you'll see that we still haven't figured out how to do Rust UIs.
Only a handful of apps and frameworks have figured this out. Most of the world moved onto HTML+Javascript plus Electron. Or mobile UI.
Who is using native UI in 2026? GTK and QT don't feel great.
I'm glad Zed is trying. We need more efforts.
Is there a difference between c++ and java/go/etc if you enforce at code review for C++ to use only auto memory management like smart ptrs, containers, etc? I guess the only difference would be c++ can have diamond problem that's solved in a specific way, but that's relatively easy to spot with compilers, but otherwise...
Imo the strong point of rust is compile error if you try to use an obj after move (unlike c++ with undef behavior and I guess it should be the same for java/c#), or that you can't modify a container if you hold a ref/pointer to some of it's elements/range which may cause invalidation in C++ case due to realloc
Zig would be an interesting contender back in the 1990's between Object Pascal and Modula-2, nowadays we know better.
For me while Go is definitly better than Oberon(-2), and Oberon-07, some of its design decisions are kind of meh, still I will advocate for it in certain contexts, see TinyGo and TamaGo efforts.
As old ML fanboy, you can find such tendencies on plenty of languages not only OCaml. :)
I see Rust as a great way to have made affine types more mainstream, however I rather see the mix of automatic resource management + strong type systmems as a better way forward.
Which is even being acknowledged by Rust's steering group, see Roadmap 2026 proposals.
> Rust happens to be an extremely good tool. There
Sir (or ma’am), you stole literally the line I came to write in the comments!
To anyone new picking up Rust, beware of shortcuts (unwrap() and expect() when used unwisely). They are fine for prototyping but will leave your app brittle, as it will panic whenever things do not go the expected way. So learn early on to handle all pathways in a way that works well for your users.
Also, if you’re looking for a simpler experience (like Rust but less verbose), Swift is phenomenal. It does not have a GC, uses ARC automatically. I spent months building a layer on top of Rust that removed ownership and borrow considerations, only to realize Swift does it already and really well! Swift also has a stable ABI making it great for writing apps with compiled dynamic components such as plugins and extensions. It’s cross platform story is much better today and you can expect similar performance on all OS.
For me personally, this relegates rust for me to single threaded tasks - as I would happily take the 20% performance hit with Swift for the flexibility I get when multithreading. My threads can share mutable references, without fighting with the borrow checker - because it’s just a bad use case for Rust (one it was not designed for). A part of my work is performance critical to that often becomes a bottleneck for me. But shouldn’t be a problem for anyone else using RwLock<Arc<…>>. Anyway - they’re both great languages and for a cli tool or utility, you can’t go wrong with either.