7 ms·

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'

by zamalek 8mo ago

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

echelon 8mo ago
> 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 8mo ago
  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 https://github.com/KDAB/cxx-qt
- steve1977 8mo ago
  > Who is using native UI in 2026? Swift. Which is similar to Rust in some ways actually.
- pjmlp 8mo ago
  > 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.
  - g947o 8mo ago
    Let's set gaming development aside for a moment. I believe when people talk about Rust UI, most people assume it's cross-platform. Developing an app just focused on Mac or Windows is a completely different problem. In fact, one could easily argue that you should never use Rust for those single platform apps.
procaryote 8mo ago
> 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
- IshKebab 8mo ago
  > 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.
  - zozbot234 8mo ago
    > It's a particularly bad one though because it always leads to UB, which means you can't say anything about what happens next. This is also why memory safety is table-stakes when it comes to formal verification of the underlying program logic. You can't solve logic bugs (even where that's known to be feasible, such as for tightly self-contained, library-like features) without solving memory safety first.
  - nananana9 8mo ago
    > it always leads to UB, which means you can't say anything about what happens next. If you read a language standard and try very hard to forget that the actual computer exists, sure. If you remember computers are real, you can pretty easily tell what will happen when you write to address 0x00000000 on a CPU with virtual memory.
    - FartyMcFarter 8mo ago
      Not all memory bugs result in writing to a null pointer. For example, you can do a double free, or write to a pointer that was freed.
raincole 8mo ago
> 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 https://nvd.nist.gov/vuln/detail/cve-2018-1000657
- slekker 8mo ago
  Following your analogy, if there is a way for the lawyer to never lose a case due to misinterpreting the law...
- dminik 8mo ago
  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.
- Ygg2 8mo ago
  Fixed since 1.22.0 You're only proving unsafe Rust is tricky. Even for experienced maintenaners.
  - deleted 8mo ago
    [deleted]
Moldoteck 8mo ago
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
- pjmlp 8mo ago
  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.
  - Moldoteck 8mo ago
    I think it's (mostly) sufficient to have a regex on git change-set for "new" "malloc" "calloc" keywords to cut most of such stuff if you have such a policy. Documentation / UT are harder to define (what is good documentation, is UT covering everything?), but usage of manual memory handling can be spotted relatively easy automatically. There can be some exceptions for 3rd party libs interaction if it's absolutely necessary but detecting such occurrences and keeping track of them is relatively easy.
    - pjmlp 8mo ago
      See, already there you missed all the C language constructs that C++ is copy-paste compatible with, and should only be used inside unsafe code blocks. Which in C++ good practices means type safe abstractions not exposing any kind of C style strings, arrays, casts, pointer arithmetic,.... Unfortunely still relatively rare, some of us when we were the C++ Striking Force in the 1990's Usenet flamewars already advocated for such practices, most of them already possible with C++ARM, no need for modern, post-modern, rococo, baroque or whatever C++ style is going on with C++26 now.
pjmlp 8mo ago
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.
selfmodruntime 8mo ago
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 8mo ago
  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.
  - speed_spread 8mo ago
    We had Delphi and VB thirty years ago and the native UIs were pretty good. The web brought a massive regression in UI programming, functionality and usability that we generally haven't recovered from yet. Not every app can be a web site.
    - Ygg2 8mo ago
      Sure. It was a simpler time. Web didn't make massive regression in UI, it made minimum feature set huge.
      - pjmlp 8mo ago
        So simple that layout managers were already a thing, even if Electron kiddies have no idea about them in native UIs. By the 2000's doing pixel perfect native UI was a sign of being lazy to learn UI best practices.
        Ygg2 8mo ago
        Say what you want but for modern UI localization and accessibility are part of minimum feature set. Those two massively increase complexity (UTF8, IME, Braile, Text to speech, etc.) The big issue I'm talking about is cross OS UI Toolkit. Great your UI supports IME on Windows and Mac. Now do that for Linux, BSD, etc.
znkr 8mo ago
> 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 https://github.com/rust-lang/rust/issues/44800
- g947o 8mo ago
  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.
  - jmull 8mo ago
    > Not sure what your point is I’m not the previous poster but it seems pretty clear the point is to show how silly that absolutist pronouncement is.
    - MindSpunk 8mo ago
      Being so absolutist is silly but their counter argument is very weak. Can I invalidate any memory safe language by dredging up old bug reports? Java had a bug once I guess it's over, everyone back to C. The argument is so thin it's hard to tell what they're trying to say. It's just as reductive as the person they're replying to.
      - jmull 8mo ago
        > Being so absolutist is silly but their counter argument is very weak. The entire point is that being so absolutist is silly. The comment reflects the previous poster's logic back at them so they (or others) can hopefully see how little sense it makes. You seem to be trying to see some additional argument about rust being bad/invalid, but there isn't one... The reason that argument is, indeed, "very weak" and "so thin", as you say, is that it isn't even there at all.
sheepscreek 8mo ago
> 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.
apatheticonion 8mo ago
> 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.

by zamalek 8mo ago

echelon 8mo ago

> 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 8mo ago
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 https://github.com/KDAB/cxx-qt
steve1977 8mo ago
> Who is using native UI in 2026? Swift. Which is similar to Rust in some ways actually.
pjmlp 8mo ago
> 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.
- g947o 8mo ago
  Let's set gaming development aside for a moment. I believe when people talk about Rust UI, most people assume it's cross-platform. Developing an app just focused on Mac or Windows is a completely different problem. In fact, one could easily argue that you should never use Rust for those single platform apps.

procaryote 8mo ago

> 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

IshKebab 8mo ago
> 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.
- zozbot234 8mo ago
  > It's a particularly bad one though because it always leads to UB, which means you can't say anything about what happens next. This is also why memory safety is table-stakes when it comes to formal verification of the underlying program logic. You can't solve logic bugs (even where that's known to be feasible, such as for tightly self-contained, library-like features) without solving memory safety first.
- nananana9 8mo ago
  > it always leads to UB, which means you can't say anything about what happens next. If you read a language standard and try very hard to forget that the actual computer exists, sure. If you remember computers are real, you can pretty easily tell what will happen when you write to address 0x00000000 on a CPU with virtual memory.
  - FartyMcFarter 8mo ago
    Not all memory bugs result in writing to a null pointer. For example, you can do a double free, or write to a pointer that was freed.

raincole 8mo ago

> 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 https://nvd.nist.gov/vuln/detail/cve-2018-1000657

slekker 8mo ago
Following your analogy, if there is a way for the lawyer to never lose a case due to misinterpreting the law...
dminik 8mo ago
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.
Ygg2 8mo ago
Fixed since 1.22.0 You're only proving unsafe Rust is tricky. Even for experienced maintenaners.
- deleted 8mo ago
  [deleted]

Moldoteck 8mo ago

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

pjmlp 8mo ago
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.
- Moldoteck 8mo ago
  I think it's (mostly) sufficient to have a regex on git change-set for "new" "malloc" "calloc" keywords to cut most of such stuff if you have such a policy. Documentation / UT are harder to define (what is good documentation, is UT covering everything?), but usage of manual memory handling can be spotted relatively easy automatically. There can be some exceptions for 3rd party libs interaction if it's absolutely necessary but detecting such occurrences and keeping track of them is relatively easy.
  - pjmlp 8mo ago
    See, already there you missed all the C language constructs that C++ is copy-paste compatible with, and should only be used inside unsafe code blocks. Which in C++ good practices means type safe abstractions not exposing any kind of C style strings, arrays, casts, pointer arithmetic,.... Unfortunely still relatively rare, some of us when we were the C++ Striking Force in the 1990's Usenet flamewars already advocated for such practices, most of them already possible with C++ARM, no need for modern, post-modern, rococo, baroque or whatever C++ style is going on with C++26 now.

pjmlp 8mo ago

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.

selfmodruntime 8mo ago

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 8mo ago
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.
- speed_spread 8mo ago
  We had Delphi and VB thirty years ago and the native UIs were pretty good. The web brought a massive regression in UI programming, functionality and usability that we generally haven't recovered from yet. Not every app can be a web site.
  - Ygg2 8mo ago
    Sure. It was a simpler time. Web didn't make massive regression in UI, it made minimum feature set huge.
    - pjmlp 8mo ago
      So simple that layout managers were already a thing, even if Electron kiddies have no idea about them in native UIs. By the 2000's doing pixel perfect native UI was a sign of being lazy to learn UI best practices.
      - Ygg2 8mo ago
        Say what you want but for modern UI localization and accessibility are part of minimum feature set. Those two massively increase complexity (UTF8, IME, Braile, Text to speech, etc.) The big issue I'm talking about is cross OS UI Toolkit. Great your UI supports IME on Windows and Mac. Now do that for Linux, BSD, etc.

znkr 8mo ago

> 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 https://github.com/rust-lang/rust/issues/44800

g947o 8mo ago
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.
- jmull 8mo ago
  > Not sure what your point is I’m not the previous poster but it seems pretty clear the point is to show how silly that absolutist pronouncement is.
  - MindSpunk 8mo ago
    Being so absolutist is silly but their counter argument is very weak. Can I invalidate any memory safe language by dredging up old bug reports? Java had a bug once I guess it's over, everyone back to C. The argument is so thin it's hard to tell what they're trying to say. It's just as reductive as the person they're replying to.
    - jmull 8mo ago
      > Being so absolutist is silly but their counter argument is very weak. The entire point is that being so absolutist is silly. The comment reflects the previous poster's logic back at them so they (or others) can hopefully see how little sense it makes. You seem to be trying to see some additional argument about rust being bad/invalid, but there isn't one... The reason that argument is, indeed, "very weak" and "so thin", as you say, is that it isn't even there at all.

sheepscreek 8mo ago

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

apatheticonion 8mo ago

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