| ▲ | zamalek 5 hours 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 :) |
|
| ▲ | procaryote 5 hours ago | parent | next [-] |
| > 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 |
| |
| ▲ | endorphine 3 hours ago | parent | next [-] | | 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)? | | |
| ▲ | josephg an hour ago | parent | next [-] | | > what's the justification of not using a memory-safe language Use Go, Java or Fil-C, and memory safety is achieved at the expense of runtime performance. Tracing garbage collectors make your programs run slower and use more RAM. With Rust you pay with complexity. Rust has new, weird syntax (lifetimes, HRTB, etc) and invisible borrow checker state that you've gotta understand and keep track of while programming. Rust is a painful language to learn, because lots of seemingly valid programs won't pass the borrow checker. And it takes awhile to internalise those rules. I personally think the headache of rust is worth it. But I can totally understand why people come to the opposite conclusion. | |
| ▲ | jmull an hour ago | parent | prev [-] | | Interop. |
| |
| ▲ | IshKebab 5 hours ago | parent | prev [-] | | > 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 5 hours ago | parent | next [-] | | > 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 4 hours ago | parent | prev [-] | | > 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. | | |
| ▲ | Tuna-Fish 3 hours ago | parent | next [-] | | Do note that with modern compilers it's surprisingly hard to accidentally do something that is always guaranteed to write to 0. Because it is UB, and an optimizing compiler is allowed assume that it doesn't happen. This can lead to seemingly crazy things like a variable that is set to zero, and when you deref through it it gives you something completely different instead. Because if a variable is first set to zero in all code paths, and then complex logic usually sets it to something else, after which it is dereferenced, the compiler is allowed to notice that the path where it is accessed without being first set to something else never happens, and then it is allowed to notice that the first write to the variable is dead because it's never read before being set to something else, and thus can be eliminated. | | |
| ▲ | xigoi 2 hours ago | parent [-] | | Are there any languages other than C and C++ that have this “nasal demons” interpretation of undefined behavior? | | |
| ▲ | josephg an hour ago | parent | next [-] | | I assume this is a product of sufficiently advanced compilers. Other LLVM languages almost certainly suffer from this too, including Zig, Swift and unsafe rust. | |
| ▲ | FartyMcFarter 2 hours ago | parent | prev [-] | | I think so, at least when it comes to assuming that multi-threading data races don't happen. |
|
| |
| ▲ | FartyMcFarter 4 hours ago | parent | prev | next [-] | | 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. | |
| ▲ | IshKebab 3 hours ago | parent | prev [-] | | Ah you're in the "but it doesn't really mean anything can happen" denial stage. Welcome to acceptance: https://mohitmv.github.io/blog/Shocking-Undefined-Behaviour-... |
|
|
|
|
| ▲ | znkr 2 hours ago | parent | prev | next [-] |
| > 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 |
| |
| ▲ | g947o 2 hours ago | parent [-] | | 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. |
|
|
| ▲ | Moldoteck 4 hours ago | parent | prev | next [-] |
| 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 3 hours ago | parent | next [-] | | 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. | | |
| ▲ | Moldoteck an hour ago | parent [-] | | So how exactly would this shooting in the foot look like compared to say java |
| |
| ▲ | ben-schaaf 3 hours ago | parent | prev | next [-] | | > 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. | | |
| ▲ | Moldoteck an hour ago | parent [-] | | What you mean by smart ptrs not being memory safe?
Vector access can be done with at method |
| |
| ▲ | pjmlp 4 hours ago | parent | prev [-] | | 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 3 hours ago | parent [-] | | 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 3 hours ago | parent [-] | | 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. |
|
|
|
|
| ▲ | echelon 5 hours ago | parent | prev | next [-] |
| > 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 5 hours ago | parent | next [-] | | 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 3 hours ago | parent | prev | next [-] | | > 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 2 hours ago | parent [-] | | 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. |
| |
| ▲ | steve1977 4 hours ago | parent | prev [-] | | > Who is using native UI in 2026? Swift. Which is similar to Rust in some ways actually. |
|
|
| ▲ | j-krieger 3 hours ago | parent | prev | next [-] |
| 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 3 hours ago | parent [-] | | 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 41 minutes ago | parent [-] | | 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. |
|
|
|
| ▲ | raincole 5 hours ago | parent | prev | next [-] |
| > 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 2 hours ago | parent | next [-] | | 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 2 hours ago | parent | prev | next [-] | | Fixed since 1.22.0 You're only proving unsafe Rust is tricky. Even for experienced maintenaners. | | | |
| ▲ | slekker 4 hours ago | parent | prev [-] | | Following your analogy, if there is a way for the lawyer to never lose a case due to misinterpreting the law... |
|
|
| ▲ | pjmlp 4 hours ago | parent | prev [-] |
| 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. |
