[zamalek]

Rust 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 :)

[procaryote]

> 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

[torginus]

Even the statement that (100% safe) Rust does not have memory bugs/mutable aliasing is not always true.

It's well known that Rust has difficulty representing graph-like memory structures, and people have taken to using arrays of `Node`-s to represent graphs, where each graph edge represents a pointer to another node.

This both efficient, and fast, but this approach sidesteps the borrow checker.

If you had a method that 2 mutable `Node` references as parameters, the borrow checker would complain if they'd point to the same struct. If you pass 2 ints, it won't.

Likewise, since liveness is tracked by user logic, you can refer to stale, deallocated `Node`-s or ones that haven't been initialized yet.

I've had people argue this is not a true memory bug, since you're not causing 'real' memory faults, but in C, `malloc` is just a function that hands you pointers into chunks of pre-allocated memory space most of the time, when it doesn't have to ask the OS for more.

I know from experience some people see this criticism as an attack on their favourite language and instantly rebuke it.

But I'd like to argue that there's something there, and it bears thinking about how 'memory allocation exisitng outside Rust' and 'memory allocating existing inside Rust' behave differently might be seen as an interesting dicothomy that needs to be resolved and that resolution might improve Rust's (or some successor language's) memory model.

[endorphine]

I guess parent argues that:

  - humans have a track-record of writing memory bugs

  - memory-safe languages prevent such by construction

Therefore, what's the justification of not using a memory-safe language (as opposed to an unsafe one)?

[IshKebab]

> Memory management bugs is just one class of bugs

It's a particularly bad one though because it always leads to UB, which means you can't say anything about what happens next.

That's why memory bug severity is often "MAY lead to RCE but who knows". At least with non-UB bugs you can reason about them.

In any case, Rust massively helps with logic bugs too. It's not just about memory safety.

[sheepscreek]

> 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.

[raincole]

> 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.

[0]: https://nvd.nist.gov/vuln/detail/cve-2018-1000657

[dminik]

It's not really that interesting. For instance, we've seemingly decided that various blue collar workers are incapable of not falling to their deaths and so have come up with OSHA and various other national equivalents. Drivers are incapable of not crashing and so we started including air bags. Woodworkers seemingly can't stop cutting their fingers off using a table saw and so we came up with SawStop.

[slekker]

Following your analogy, if there is a way for the lawyer to never lose a case due to misinterpreting the law...

[Ygg2]

Fixed since 1.22.0

You're only proving unsafe Rust is tricky. Even for experienced maintenaners.

[j-krieger]

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.

[Ygg2]

I'm pretty sure the issue isn't Rust but the fact outside Browser UI, every native UI sucks.

And the biggest culprit is Apple by far, followed by Microsoft, followed by Linux lack of consistency.

[znkr]

> 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

[ViewTrick1002]

Just compare the Buns and Deno issue trackers.

Bun is segfaults galore, I’ve stumbled upon them.

In Deno they essentially only come from integrating with C and C++ libraries.

[g947o]

Hmm... A bug report from near a decade ago, where the bug was fixed within days. Not sure what your point is. If anything, it shows how much Rust cares about memory safety, because elsewhere it wouldn't be a compiler bug in the first place.

[echelon]

> 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.

[giancarlostoro]

I've been experimenting (thanks to Claude Code because it removes the headache drastically for me of Rust nuances, I'm not a Rust expert by any means) with Qt and Rust.

I discovered cxx-qt which is maintained by some Qt maintainers, which are all employed at KDAB. I had no idea KDAB or this project existed. It's been very smooth so far.

I can honestly say the barrier to building a GUI is very low with Claude, must to the dismay of others, but it beats me building an Electron app.

https://github.com/KDAB/cxx-qt

[pjmlp]

> Who is using native UI in 2026? GTK and QT don't feel great.

Game developers, Windows applications in .NET (possibly with some C++/COM modules)

The problem with native UIs is mostly a Year of Linux Desktop problem.

[steve1977]

> Who is using native UI in 2026?

Swift. Which is similar to Rust in some ways actually.

[apatheticonion]

> you'll see that we still haven't figured out how to do Rust UIs

This is really a symptom of the horrendous desktop GUI API landscape. I'd argue that Rust is syntactically actually very well suited to writing GUI applications - and better than most given the fearless concurrency you get with it.

MacOS is committed to making sure only developers are using Mac hardware and Apple languages to write GUIs - they feel deliberately combative to the prospect of cross platform applications

Windows? How do you even make a Windows GUI these days? Win32? WinUI? Winforms? The examples on the Microsoft website don't even compile when when using the supported languages.

Linux is pretty okay, if it weren't for Linux GUI programming being a mess of DEs. GTK-rs and QT are standard - but you'll never have something that looks consistent on every environment.

The only hope is WASM, but the standards body is busy figuring out how to make web assembly replace docker containers or something. It's barely usable and I've been dying to rewrite all my web applications in Rust.

This is why Electron is everywhere, it's the best we can do without going insane.

[Moldoteck]

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

[dminik]

Yes there is. RAII is not a full replacement for GC and you will shoot yourself in the foot if you treat it as such. The design of C++ also includes many unpatchable holes in the standard library which WILL cause errors and UB.

[ben-schaaf]

> 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?

Smart pointers and containers are nowhere near memory safe, just enforcing their use gets you nowhere. `std::vector::operator[](size_t)` doesn't check bounds, `std::unique_ptr::operator*()` doesn't check null.

> Imo the strong point of rust is compile error if you try to use an obj after move (unlike c++ with undef behavior

The state of a value after being moved is defined by the move constructor. It is unspecified by the spec, but it's generally not undefined behavior.

[pjmlp]

Yes, because code review isn't common, it is at the same level as writing documentation, or unit tests in most companies.

Unless there is some DevOps freedom to at least put something like Sonar or clang tidy on the build pipeline breaking PR that don't play by the rules, and even then you cannot prevent everything via static analysis rules.

[pjmlp]

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.