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 :)
> 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
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.
The difference is the checking, and actual enforcement of it.
Go and use get_unchecked if you want to and get C like behavior. But the safety note tells you the potential issues:
Safety
Calling this method with an out-of-bounds index is undefined behavior even if the resulting reference is not used.
You can think of this like .get(index).unwrap_unchecked(). It’s UB to call .get_unchecked(len), even if you immediately convert to a pointer. And it’s UB to call .get_unchecked(..len + 1), .get_unchecked(..=len), or similar.
> 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.
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.
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.
> 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.
Rusts memory safety constructs do also impose a (much smaller) runtime performance penalty. Every Arc / Rc is a memory safe abstraction with runtime cost since rust has no way to prove cyclic reference graphs are safe at compile time.
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.
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.
> 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.
> 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.
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.
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.
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.
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.
I'm talking about accessibility and localization as part of a GUI toolkit.
Take localization. Any doofus with CSV and regex can localize a binary. How do you localize dynamic things like "Hi (Sir) PJMLP, you have (0 unread messages)"?[1]
In JS I can always Intl.PluralRules. Where are my Plural rules in say C#'s Avalonia (or whatever GUI is hot in C# these days, I can't keep track)?
The issue isn't a checklist; it's a quality of availability [2]. The complexity there is essential, because languages are complex beasts, and mitigations for disability are getting better and hence more complex[2].
[1] Why is localizing this a problem? Some languages are language neutral, some have honorific speech, which changes other words, and some have different ways of counting (Hello Welsh. Nice that you have ordinals for zero, one, two, few, many, and more), some have genders, some don't, some have but don't use it in some cases, ad infinitum.
[2] There is a huge Mariana Trench in the quality of accessibility for software that offers a magnifying glass and software that offers text-to-speech.
Sure. Show me how Windows 3.* supported Unicode, i18n (internationalisation), l10n (localisation), a11y (accessibility), with special focus on CLDR plural rules.
Which will be interesting since Unicode 1.0 came around 1991. And CLDR in 2003. And Windows 3.x came in 1990.
I'm not saying it is impossible, just highly unlikely MSFT implemented those as early in 3.x. They could have taken part in those early efforts.
If you are so keen in Windows 3.x, remember before standards each OS did its own thing, and I can gladly show you the proprietary APIs used by Windows 3.x.
For someone using a GUI toolkit, there is a massive difference between "invent and integrate your own" and "it comes pre-installed".
I'm saying the reason modern cross platform GUIs are hard is that the developer and user preferences have changed. Developers want GUIs that come with many bells and whistles.
This raises the bar for minimal implementation from - "it will take one guy two weeks to implement" to "it will take a huge group decades of effort to implement."
And that's JUST the implementation. At any point, you also face an adoption cliff. Sure, your super layout engine (SLE) might automatically layout stuff, but Josh here doesn't know SLE, he knows CSS.
Yeah but whatever the browser provides, the OS can also provide. You don't have to reinvent a browser when you code outside of it. Anyway, this conversation had slipped out of the window. Web app UI programming tools still suck compared to what we had 25 years ago and say what you will, there's NO good reason for that.
Which OS? This is talk about cross-platform GUI toolkit.
My point was, "Why X language sucks at cross-platform GUI" is because X isn't JavaScript or TypeScript, and it's not backed by the huge corpo that is Google.
> Web app UI programming tools still suck compared to what we had 25 years ago
Funny. I can think of few examples, namely Flash, Dreamweaver, and Delphi, but that's more rose-tinted glasses than any objective metric. They all did a few things better than the modern web but failed in so many other ways.
> 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.
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.
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.
> 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.
It seems odd to me to put this much effort into misunderstanding what people are saying. You just end up talking past everyone, essentially talking to no one about nothing.
If it wasn't obvious from my ramble, Rust concerns are pragmatic, not absolutist. The only absolutism is that for memory safety to be truly upheld, you can't half-ass it (Zig) or ignore it (C).
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
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.
You take a reference to a vector element, which you later accidentally invalidate by pushing to the same vector.
You move out of a unique_ptr, but then you accidentally use it again.
You create a cycle with shared_ptr causing a memory leak.
If you std::sort a list of floats with NaNs (among other things) you can stomp over memory. The sort function requires some very specific ordering otherwise you get UB.
> 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.
The hardened runtime improves things, but it's still a far cry from memory safety. For example `std::vector::erase` has no hardened precondition. And of course the rest of the language around the stdlib is still entirely unsafe, not just the C parts.
In theory, that will be taken care of with contracts and further revisions.
In practice, it depends on how the contracts drama folds out.
However I do agree it is still not quite there.
Still, C++ isn't going anywhere anytime soon, so any improvement is welcomed, even rustc has to gain from it.
I don't expect any RIR for GCC and LLVM happening any time soon, not only due to existing code, also due to all universities, and companies that contribute to upstream and aren't racing to adopt Rust.
As I said, unique_ptr (or any of the others), do not check for null. So you can do this, and it will cause a segfault:
std::unique_ptr<int> a;
printf("%d\n", *a);
Similarly unique_ptr::operator[] doesn't (and can't) do bounds checking, for example:
std::unique_ptr<int[]> a = std::make_unique<int[]>(2);
printf("%d\n", a[2]);
There's also no attempt to limit the construction of invalid smart pointers, for example:
int num;
std::unique_ptr<int> a(&num);
Smart pointers simplify memory management, and they're slightly harder to misuse than regular pointers, but they simply make no attempt at providing memory safety.
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.
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.
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.
> 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.
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 is just a tool. A decent tool that I think can be made better (by removing stuff and stop adding more stuff to the surface syntax). So I am down to criticize Rust.
However, I also don't understand how people don't see the usefulness of what Rust put to the mainstream: algebraic data types, sum types, traits, etc.
I also get super annoyed when people think Rust is only chosen for "safety". Says frustrating things like "so I can just use unsafe", because no you don't and if you do I would reject your changes immediately.
Honestly, in general, I am just annoyed when people don't use the right tool for the right job. And attempts to fix the tool with more bespoke stuff on top it.
Yes. To me personally, Rust and both its restrictions and features (ie no OOP and prevalence of sum types and hence other goodies) makes approaching the implementation of big problems differently; eventually the experience with Rust also changes (to some extent) the way you write and structure the code in other languages. One might argue that Rust is not unique here and this would also apply to languages like ocaml etc - sure, perhaps; but I can't write in any of those languages at work on daily basis since they don't fit performance-wise or for many other reasons.
> Says frustrating things like "so I can just use unsafe", because no you don't and if you do I would reject your changes immediately.
This is the kind of hostility (which is frankly toxic) that’s become associated with parts of the Rust community, and has fairly or not, driven away many talented people over time.
Overly enthusiastic Rust evangelists can be annoying, but nowhere as much as C++ or C advocates defensively claiming memory safety isn't a big deal, and they are going to have it in the next version of the language anyway.
I find my experience with Erlang has helped with the (considerable) learning curve for Rust, but I still prefer Go for most use-cases.
1000x yes. Rust is not a One True Language, there exists no One True Language. Rust made some improvements over previous languages (many of which were ported over from previous languages that demonstrated the value but weren't break out successes) and serendipitously those improvements added up to something that was really significant and unlocked interesting and useful capabilities. I'm never going back to how my workflows were before I learned Rust (though I still write in other languages everyday).
But there will be other languages in the future that will continue to deliver small improvements until one day they result in another phase change. The honeymoon with Rust will be over and it will start feeling more antiquated.
C, Python, Java, are just a couple random languages that were/are similarly influential. (C is of course orders of magnitude more influential, the only language more influential is probably COBOL?)
The weird thing about this is many core Rust people agree that Rust is not the best language that could possibly ever be, even evaluated by the core principles of Rust (that is: no UB, no mutable aliasing, no memory bugs).
And if we move outside of Rust's memory model, some people have raised issues with the inconsistent syntax, and the module-based compilation model which makes compilers inherently slow, as you have to parse the whole module every time.
So there's room for improvement, and people are already working on putting ideas into practice, and some of these people who came from the Rust ecosystem itself.
And if you happen to disagree with Rust's core goals (or just place less emphasis on them), then it's obviously not the perfect language.
> But there will be other languages in the future that will continue to deliver small improvements until one day they result in another phase change. The honeymoon with Rust will be over and it will start feeling more antiquated.
That language may well be Rust itself, especially if they manage to figure out the "how to deprecate standard library features across language editions and allow reuse of their idiomatic syntax?" problem.
Totally true. Similarly I think a C revival is more likely than people might think because of Fil-C, improvements to the language standard, and maybe hardware improvements like CHERI. Eg, maybe there will be a new generation of Fil-C like compilers, maybe C will get a lot easier, and maybe that will cause C to displace Python as the preffered pedagogical "first language" (which would really be reprising it's role). Not because it's easier than Python but because it's easy enough and we start emphasizing low-level optimization more because AI is eating all of our compute. Stranger things have happened.
I can see some interest in Fil-C, but some will still be against it due to the overhead it imposes (1.5x-4x worse performance, less deterministic since there's a GC), as well as the program will simply crash on arbitrary memory reinterpretation, use-after-free, and reading uninitialized memory. This is certainly better than it continuing, but certainly not as good as it could be.
CHERI has different characteristics in that it will crash for buffer overflows, but crashing on use-after-free is opt-in, it can only detect double-frees sometimes, it does nothing about uninitialized memory access, etc. It also requires adopting new hardware, which may be a hard sell.
In all I've mentioned above, I haven't even touched thread safety or integer safety which these do nothing about.
So with that being said, do as you please, but understand that simply adopting these is a different level of safety (program will not be exploitable but will crash) compared to something like Rust (program is not exploitable and will not crash because these issues are mostly* compile-time errors).
* "Mostly" since I mentioned integer safety which will be a runtime crash like the C safeguards, you can use unsafe, etc.
> I can see some interest in Fil-C, but some will still be against it due to the overhead it imposes (1.5x-4x worse performance, less deterministic since there's a GC)
Yeah this is where I stand with it. Fil-C seems to be the worst of all worlds. It combines the performance of an immature GC language, with the primitive syntax and ecosystem of C. (Eg nullability, void*, no generics, no collection types, a bad standard library, header files, no good build system, bad cross-OS portability, BYO strings, etc).
I don't choose C for its wonderful syntax. I choose it because its small, light and performant. If I was happy to use a garbage collector, I'd much prefer to go all the way and grab Typescript, C# or Go.
The only use case I can see for Fil-C is running legacy code that you can't be bothered porting to a better language.
Don't forget the compatibility issues: Fil-C isn't really usable if you mix C with other languages in the process.
It's especially problematic to have multiple different garbage collectors; so given the desire to reuse libraries across language boundaries, there's still a strong demand for Yolo-C, C++ or Rust.
Really what I'm getting at is that people are not done innovating on C ergonomics and safety and that there is potential there. Not that there is a new shivel-ready paradigm shift that has arrived to C. I'm only saying that that may happen and that it is more likely than most people credit.
Fil-C is actually not very low-level efficient, Golang probably has better efficiency (being built from the ground up for lightweight concurrent GC) and a hypothetical support within Rust for "pluggable" GC heaps might be even more clearly preferable.
If your LLM can output 10-100x the LOC output, and it's equally good at all languages, and you're not bound to an existing language choice or ecosystem, why not choose Rust?
Rust code will be faster, safer, and easier to ameliorate bugs in.
Rust seems like the best language to serialize business logic to now that LLMs are so good at it.
If the LLM makes a mistake in Javascript or Python, you literally won't know until runtime. With Rust, you'll know immediately and have really good compiler recommendations for fixes.
I think Rust is the best LLM language. I am somewhat biased: I've written Rust code for ten years, and I'm having a blast with Claude Code writing it for me instead now. But I've also used so many other tools and languages - enough to say that Rust has some unique advantages here. And also that Claude does a fantastic job emitting Rust.
LLMs emitting Python feels like building with clay. LLMs emitting Rust feels like building well-engineered steel skyscrapers.
I'm also having a really good time having LLMs write code in Rust. In Typescript they tend to abuse `any` or just cast stuff around, bypassing the type system at every corner. In Rust they seem to take compiler errors to heart and things tend to work well.
You might also have success asking your agent to run `eslint` at the end of every subtask and instruct it to always address lint errors, even if they are preexisting. I agree with your diagnosis; there's "implicit prompting" in Rust being more strongly typed and the agent "knowing" that going in but we can compensate with explicit prompting. (You do also have to tell it to actually fix the lints, I find, or it will conclude they aren't relevant.)
> But there will be other languages in the future that will continue to deliver small improvements until one day they result in another phase change
I agree, and I'm interested to see what it is in the age of LLMs or similar future tools. I suspect a future phase change might be towards disregarding how easy it is for humans to work with the code and instead focus on provability, testing, perhaps combined with token efficiency.
Maybe Lean combined with Rust shrunk down to something that is very compiler friendly. Imagine if you could specify what you need in high level language and instead of getting back "vibe code", you get back proven correct code, because that's the only kind of code that will successfully compile.
Rust is an amazing tool that sadly has the most toxic self-righteous community in PL. Like doxxing that kid for daring to post he refactored his pet project from Rust to Go.
Every community has these assholes. In my experience, the Rust user base is nothing but polite, understanding and pragmatic. There's no smugness, explicit or implied. The Rust lore is just a joke that's getting less funny every day someone takes it seriously.
Technically, I prefer Rust but I understand people who find Go better suited for their work. For example, devops is mostly Go nowadays and that makes more sense than Rust (or Python).
But I've never, ever seen toxic behavior from the Go community. For Rust, it's the norm, sadly.
Frankly, I see _a lot_ more uninformed attacks on Rust than actual Rust evangelism / snobbery. And most of these anti-Rust comments reek of personal insecurities and low-effort trolling. Like saying that Java is slow. It's getting old real quick.
I agree with this (short and sweet) piece. I'm Rust user but the crab-hype turned me off for the long time.
Personally I'd prefer writing Haskell but there are sharp edges I can't overlook (like constantly breaking LSP of 11/10 difficulty on producing distributable binaries).
I cringe every time I spit out 50 lines of boilerplate just to get C done Rust, but it's best tool I found that's good enough in many scopes.
I don't think Rust/PHP are all that much more safe than Zig/C++.
80% of memory safety bugs in C++ are just basically "array out of bounds", for which you don't need a memory checker at all just array bounds checks which LLVM has enabled by default for Rust but you can also use it for C++.
70% of vulns in C++ are memory related but only ~10% of those would be caught by borrow checking. Most are already caught by forcing object initialisation and array bounds checking. Only use-after-free is caught by either borrow checking OR OTHER TOOLS like ARM has 4 bits in addresses that can encode if the memory location has not been pulled from under you.
So aaaaall this trouble if the borrow checker to have in some cases max 10% fewer vulnos.
I'm not going to switch to Rust/PHP just for that little memory safety bonus.
I've has more core dumps/seg faults than any other language I've ever used.
Skill issue? Yes, 100℅, it's definitely due to my lack of skill in the language
The only time I've ever made a rust program seg fault is when using nightly macros/"features" and being on stable, leading to rustc crashing with a nice error and then I change to nightly
and that was caught at compile time...
Skill is a huge factor in safety
"70% of vulns are..."
Yes, production code written at huge companies by experts... If experts are making those mistakes, that says a lot about it IMO
That being said, I'm not a "one language for all", they have their place, embedded rust is hilarious as it's essentially a requirement to have unsafe blocks in your initialisation
I'm curious about the exact exchange that prompted the author to say this.
> refuse to admit there are alternatives to RAII
I'm even more curious about this. Can the author or anybody else explain what this means specifically? Can anybody list those alternatives other than GC and RC?
PS: Computer Science isn't exactly my primary professional competence.
Batching/arenas can get you very far. If you adopt the zig/c object model as “things that have data” most destructors become useless. Resource management also can be accomplished at the batch level (eg you can free a bunch of fd’s all at once with a management layer rather than having each File object implicitly manage its own fd). For memory management, i believe proper use of arenas and batching tends to be faster than each object managing its own memory but idrk tbh. What the author is saying is that you dont have to have raii, you can use approaches like the one i described and they can still be pretty safe if you know what youre doing, but rust’s model basically prevents this if youre using rust idiomatically
Yeah if your program has a natural notion of a "frame" (eg most video games), you can do memory management by simply incrementing an integer (bump allocation). At the end of your frame, you reset the integer to zero. You can't really get any faster than that.
An additional benefit of this style of allocation over malloc/free is that you can get a lot of the same type of objects contiguous in memory so that iteration over them is a lot faster because there are fewer cache misses.
I forgot about the arena approach. So, which language is the best to try it out? How does Zig look? I have been putting off my attempts to learn it, due to the fact that it's not stable yet. Perhaps it's time to give it another go?
Rust is boaring! I ll never use Rust for something I build for fun.
It will be a shame if new programmers will stay away from C because of all the scaremongering regarding the consequences of not freeing some memory (in some toy, pet project) in their own computers.
Yes, Rust does not guarantee that it'll prevent memory leaks. But the design of the language does make it harder for you (and your collaborators/dependencies) to accidentally leak memory compared to, say, C++.
Sherlock Holmes liked to say "When you have eliminated the impossible whatever remains, however improbable, must be the truth".
The same is true for programming languages. When you have eliminated all the others for their fatal flaws, only Rust remains, so it's not "just a tool", it's the best tool (or less worse, depending on how you like the syntax).
All technology is just a tool, unfortunately it turns into religion like behaviours, because it defines with whom we work, what projects we can work on, what CVs get through HR and which ones don't,....
That phrasing makes me imagine a cultural anthropologist studying the behavior of programmers in the wild, their tool use, rituals, magical worldviews like object-orientation. There's that classic paper about how a language is a "tool for thinking", that it both expands and limits how and what a person can think. It makes sense that it shares characteristics with religion, a conceptual system of interfacing with the world.
The horror of picking tech working in it 10 or 15 years and then it suddenly becoming obsolete or irrelevant. Is something a lot of people can relate to.
We're a new industry. So long as we keep iterating on our tools, this will continue to happen. Obsolescence is - in this case - an indicator of progress.
I don’t subscribe to the notion that we are „new industry”.
It already is well past 80 years and we can easily add computation jobs and record keeping that were there before those were digitalized.
„Centuries” of experience in other fields for me feels like it is exactly the case of that guy who has 20 years of experience in his CV in software development but can’t write fizz buzz if you ask for it.
There is so much knowledge lost and new guys don’t study centuries of history to build a house or become a sales person. You might study battles from century ago but they are mostly irrelevant.
It’s useful to align groups on underlying philosophies about problem solving and what tooling we will use.
The alternative is way slower and less effective. “Just use whatever language and frameworks you want and solve the problem in a vacuum” would be a nightmare for any team trying to ship.
> Programming Rust does not mean I have to: buy into their marketing hype
> give the same smug lectures about "safety"
I'm often confused reading articles like this, which take for granted the existence of some "rust evangelism strike force" which goes after people on the internet for not liking rust enough.
The way people talk, it sounds like there's some insanely effective marketing campaign going on to promote rust everywhere. But I haven't seen it. Certainly not any more than any other technology people get excited about for awhile, like Go. Or docker when that launched.
Where are these comments? Can anyone give some actual links to these sort of comments people say online, which don't get immediately downvoted? The way people talk, these comments must be made in such large volumes that it seems very odd I don't notice them?
It's way rarer on Hacker News than people alleging an omnipresent Rust Evangelism Task Force is constantly imposing itself on people. I have seen "overly enthusiastic" comments about Rust, but I can count them on one hand. I'm not going to link them because I don't want to dogpile ob people. Note that I read many/most of the Rust threads that make it to the front page.
But I have seen thousands of comments complaining about these supposed evangelists (no exaggeration). Less often and less reliably in the past few years, the meme is petering out. But there's absolutely no comparison of the relative frequency. People complain bitterly about Rust on this forum consistently, actual Rust zealots appear very rarely.
It is simultaneously true that Rust is "just a tool" and that this is a significant fact, and that the people complaining about Rust are the bigger problem in the day to day discourse in Rust related threads on this platform and in the present day.
Sure; there's one or two unbalanced, positive comments about rust in this thread. Does that seem out of balance to you, out of 113 comments?
If there was a post about Go, Kotlin or C#, I bet there'd be a few glowing positive comments about the languages. I'd be surprised if there weren't.
Is that a problem? I don't want to move the goal posts, but this really doesn't seem like the problem its made out to be. I count far more comments complaining about rust evangelists than I see actual rust evangelism. Even in a thread about rust being a good tool.
I think it's that the few enthusiastic fans make such hyperbolic statements, they create drama and stand out among the majority of reasonable users of the language. They attract attention of the people who are curious about the language, and give the impression that the community is hyping it up too much.
The other day I saw a developer who works on the Rust language saying, please tone it down because it's making us look like fanatics. It's healthy to acknowledge that the language is not perfect, it has room to improve, even some fundamental flaws. Oh, I recognize your user name, recently read a great article you wrote - here it is. This was really informative and interesting.
That's a nice way to handwave drive-by unproductive "rust btw" commnents.
Sure there's comments on all spectrums. But rust commenters are on an extreme end of it when it comes to making sure the world knows how other languages are inferior and often their users too.
Thanks for yet another example if toxic behaviour by that community. So now arguing is also "parroting".
If you were discussing in good faith, instead of belitling arguments as "parroting" you'd use something like algolia to find the answer for yourself. And you could have an easy start by finding comments from the links on this post alone. Let alone 10 in the entire HN in the last month. But that is of little interest I see.
Funnily I already see some on the first page, incredible:
You see what you want to see and I refuse to be dragged into a mud-slinging contest. Please reconsider your tone for the future. Start off better and we can chat.
I think it's just what happens when something genuinely great comes along. Some people try it and enthuse about it. Sometimes other people who haven't tried it assume that it's just like all the other average things and therefore the only explanation is irrational fanboyism.
We saw the same thing with the iPhone. It was a step change from previous phones. Loads of people were like "it's just Apple fanbois, I'll stick to my N95" without even trying it.
Post anything negative about rust, or anything about a severe bug in some non-rust code, for examples of your own
I have nothing against rust, although the learning curve is too steep and development in rust is too slow to be a practical general purpose language for a regular company.
The culture around dependencies also means you pay for your memory safety by increased supply chain risk.
Golang or Java gets you memory safety, faster compilation, easy hiring and have better standard libraries
I think it's an old stereotype. When Rust started gaining popularity, I did see comments like that. Even felt compelled to post them sometimes. But now that we have real production Rust experience, we're a bit more nuanced in our views.
I started periodically asking the same question and I get 20-25 upvotes and then eat 15 downvotes some hours later. One recent example (if ~75 days is recent: https://news.ycombinator.com/item?id=46291249).
It is a very weird case of aggressors pretending to be victims.
Did I see zealous Rust comments? Sure! 4-5 on HN in the last 5 years maximum. On Reddit it could be 10-15 for the same period but the discourse there is not very civil or informative anyway so I started ignoring them and not thinking them representative.
On HN I see regular Rust hate while claiming that zealots are everywhere... and like you, I just can't see it.
It's just a tool. But to some people, Rust is more like a religion than a tool and they let it define them to the point even the language maintainers disavow them.
At any point, if you provide any conterpoints or fair criticism towards the language objectively, just expect lots of fans to remind you that it is the best programming language ever created and yours is "unsafe" by default.
> At any point, if you provide any conterpoints or fair criticism towards the language objectively, just expect lots of fans to remind you that it is the best programming language ever created and yours is "unsafe" by default.
This is mostly just a disagreement about what the word "unsafe" means in this context?
"safe" and "unsafe" in the sense Rust uses them aren't a moral judgment about a language, it's a specific (and limited in scope) feature of the language, where memory safety is enforced by the compiler.
Sometimes when you have a really good tool, you want to share it.
This was the case with Linux for many people over many years.
FWIW I agree that the community has some frustrating elements, and that its a lot of dogma in comments, though I actually think that’s a fringe element.
Not even C/C++, only if vim and emacs are the only experience one has ever had.
See Visual C++ (with hot code reloading, incremental linking, AI integration, on the fly analysis), QtCreator, Clion (comparable with VS in many options), C++ Builder (with its RAD capabilities),....
Cargo is great as long as it is only Rust code and there is little need to interop with platform SDKs, then it is build.rs fun.
Java has over 3 decades of history, during which many IDEs were developed just for Java, and the ecosystem evolved over that long period. Rust is still way too young.
It doesn't have the same kind of high quality tooling, period. People on the internet are not going around saying "look at Rust, such a young language but already has such awesome tooling like cargo, can't wait to see what we are going to have in few years from now". They just simply claim that Rust tooling is superior to anything else.
Because only thing they know are CLI-based workflows for cavemen.
While these are all reasonable points, there is a distinction between criticising people for using ${lang} (bad) and criticising the language (neutral).
Some people get their egoes attached to their choices (for or against Rust).
Also there's a time and a place for all criticism. If the conversation is not fundamentally about language choice then it's very irritating to have it brought up.
Rust is a very very ugly language, this is made worse when it is shamelessly promoted by bunch of persistent people with bad tastes.
Also trying to fight runtime behavior with compile time constraints cannot be a universal treatment. Trying to enforce OOP is one of such examples, and it already failed .
A programming language is a medium to communicate programs to something that can execute them. That isn't exactly the same thing as a tool. A tool in my book is a metaphor for a program that helps achieve some well-defined task. Even if we ignore this difference, we would still want to talk about tool safety.
In my experience there is a C++ mob that hates Rust. These are the people who declare statement of facts as ideology. No good faith dialogue is possible.
There are also competent C++ programmers who misunderstand or don't know how static checking works.
I also witness normal people who are completely surprised by a statement like "C++ is all unsafe" and find that too strong. Using the word "safe" with a technical meaning throws normal people off because, sadly, not everyone who writes code is an academic PL researcher.
"Safe", in Rust and much PL research, means "statically checked by the compiler to be free of UB". If you are pedantic, you need to add "... under the assumption that the programmer checked all conditions for the code that is marked `unsafe`" for Rust. That is all there is to it. Scientific definition.
C++ in its current form is full of gross design mistakes, many of which could be corrected at the price of breaking backwards compatibility. Mistakes happen, aldo to world leading PL researcher (the ML language and polymorphic references) which is why the field embraced mechanically checked proofs. The difference is the willingness to address mistakes.
Academics use "safe" in exactly the meaning the Rust community uses. If you don't understand this, go and educate yourself.
Academics need to communicate effectively which leads to technical meanings for everyday words or made up words and jargon.
Maybe a statically checked safe low-level language is marketing genius. It is also a technical breakthrough building on decades of academic research, and took a lot of effort.
Bjarne and friends chose a different direction. Safety was not a design goal originally but doubling down on this direction means that C++ is not going to improve. These are all facts.
Backwards compatibility is a constraint. Constraints don't give anyone license to stop people who don't have those constraints.
We don't have to feel any moral obligation to use statically checked languages for programs. But claiming that static checking does not make a difference is ignorant, and attaching value to one's ignorance certainly seems like an indicator for ideology and delusion.
"$LANG is just a tool" has never been right. The Sapir–Whorf hypothesis (or the blub lang analogy - and not the smug part - for programmers) is still true to this day.
tl;dr: Just a tool, but "we shape our tools and then our tools shape us".
Rust has nothing new (even the lifetime stuff is copied) really. It just marketed itself really well. It got a huge number of migrants from JS/TS ecosystem, and python, and some from the C(+*) ecosystems.
Its a good language dont get me wrong, but also a huge pita to work with.
> Rust has nothing new (even the lifetime stuff is copied) really.
Rust has nothing new by academic standards, and this is an explicit goal of the project. (And that's why it has yet to support e.g. Haskell-like higher-kinded types; or dependent types for compile-time programming: the interaction with its low-level featureset is very much an open question.) It's incredibly novel as a production language, of course.
It has nothing new but they did a good job at cherry picking what what nice in other languages.
Which makes it an interesting language to learn actually. I even feel like Rust can even be a superb first language to learn for a new programmer : that’s a journey for sure but it would expose you to most of the modern programming concepts.
Saying it has nothing new seems like an uncharitable take. Yes, it has influences (that rust docs dedicate a page to [0]), but PL theory has such a rich body of literature that you can make a similar claim about virtually any language. It's the whole package that matters, and I don't think there's anything "rust but earlier" to point to there. Certainly isn't Ada.
Rust is cool but there is way too much dogma around its memory safety and static typing in general being a panacea. Most errors are not type errors. Two days after Cloudfare's little Rust hiccup that took the internet down for a day I saw people posting about Rust "if it compiles it runs".
I actually don't think this is true. I do think that most programming errors are type errors, in the broader sense of one part of a system making one set of assumptions about the properties of some data, that aren't shared by another part of the system; and that would've been caught automatically by sufficiently sophisticated static correctness checking. I do not think that Rust has a maximally sophisticated type system (nor is it trying to), and while this is reasonable for Rust as a project to decide, I do expect that there will be languages in the future that do more complex things with type systems that might supplant Rust in some domains.
The Cloudflare incident was caused by a confluence of factors, of which code written in Rust was only one. I actually think that Rust code worked reasonably well given the other parts of the system that failed - a developer used unwrap() to immediately crash instead of handling an error condition they thought would never happen; when that error condition did happen the Rust program crashed immediately exactly as expected; and if Cloudflare decided that they wanted to ban not handling an error like this in their codebase, it's a pretty easy thing to lint for with automatic tooling.
If it helps finally acknowledging basic stuff like bounds checking matters, great, this from a guy that rather use system languages with automatic resource management.
"A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
-- C.A.R Hoare's "The 1980 ACM Turing Award Lecture"
From 1980!
C++26 will finally have hardening on the standard library, something that I could already enjoy in 1990's with Turbo Vision, OWL, MFC, VCL, but was too much to ask for on the standard library apparently, even if compilers kept having each own their approach.
It took governments and companies to start mapping CVEs to money spent fixing them, to finally acknowledge something had to change.
Meanwhile on C land, business as usual regarding Hoare's quote.
It's interesting how it's Obviously Impossible to write OSes in garbage-collected languages, and this is proven by the fact successful OSes were written in garbage-collected languages back in the Stone Age, or 1980s, whichever. My current laptop has enough RAM to swallow the entire state of a Symbolics workstation (RAM and disk) without noticing, but it's obviously too wimpy to run an OS written in anything other than C.
(Nitpickers' Corner: "Successful" and "the most commercially successful" are, in fact, two different words. Gots all them different letters an' everything. Therefore, Genera not being as profitable as such Sophisticated Top-Of-The-Line Pieces of Professional-Grade Enterprise-Ready software as MS-DOS doesn't mean Genera wasn't successful.)
Yeah its funny what we can get away with using different design tradeoffs on modern computers.
I've been reading through the SeL4 source code lately. SeL4 isn't a multithreaded kernel. It supports SMP - so, it can use all the cores on your computer. But the kernel itself uses a big mutex. Complex syscalls can't run concurrently.
And you know what? I think its fine. A tiny microkernel like SeL4 offloads almost everything to separate processes anyway. The only things in the core kernel are the bootloader, scheduler and thread cap tables. Device drivers are multithreaded because they all run in separate processes.
Having the kernel itself effectively single threaded reduces a whole class of bugs and complexity, at a (hopefully) negligible performance cost. Its smart.
This industry pretends to be driven by technical considerations, yet, with some exceptions, is mostly driven by fads, folk knowledge and aesthetic choices.
Folk knowledge may, and often is, grounded in reality and real experience, but let us not forget that most heated debates in programming of today are rooted mostly in tribal logic and fad chasing.
Static vs dynamic typing is a chief example. Empirical evidence that static typing makes some real difference in terms of bugs or safety is inconclusive at best. Yet it doesn't prevent some people from literally shaming those that prefer dynamic languages. Same with OOP - for years it was everywhere, now you may have an impression that it is a sin to ever use it. But now, as much as back then, there is no evidence to support claim that using or not using OOP is "one true way".
Now, memory safety is a real concern, and we can confidently say that we have found ways (exemplified in Rust) to prevent whole class of issues, but suddenly we are in the situation that every single bit of code out there is supposed to put memory safety as a chief concern, no matter if we are talking about some high perf web server, missile control logic, simple script solving Lotka-Volterra equations or simple calculator app.
If you follow good strong typing principles, you can ensure that most errors are type errors. Yaron Minsky’s phrase, “Make illegal states unrepresentable”, captures this. But it doesn’t happen by accident just because you’re using a strongly typed language.
Also, if Cloudflare had run the standard Clippy linter on their Rust code, and taken the results seriously, it would have prevented the issue you referenced. Static checks don’t help if you ignore them.
Rust doesn't eliminate all bugs. But anecdotally, by the time the type checker and borrow checker have humbled me, my programs really do often work the first time I run them. Its quite remarkable.
This isn't a special thing about rust. All languages are on a spectrum of "detect all bugs statically" to "detect all bugs dynamically". Rust programs run correctly "first time" more than javascript, more than typescript. But still less than haskell.
You can still write bugs in rust, obviously. I've written plenty. As you say, so has cloudflare. But strong typing does find a lot of bugs in practice.
With a sufficiently strong type system all errors are type errors! Rust doesn't have that of course, but it does have quite a strong type system so this is a very bold assertion with no evidence.
Rust does have an "if it compiles it works" feel. Nobody means that literally (this should be really obvious). They just mean that once you get it to compile the chance that it works first time is quite high (like 20% maybe?) compared to most other languages where it's more like 1%.
I don't think your comment deserves the downvotes (upvoted to compensate) but I do think that it's questionable if "Most errors are not type errors" is true.
Rust's culture of pushing things into type checking does eliminate a huge swathe of bugs and I wouldn't be surprised if it was the majority.
The hurdle of negotiating translation between filesystem strings and unicode strings strikes me as a good example of a place where most languages don't protect you from bugs and a strongly typed one does. The downside, of course, is that you have to handle these cases (even if it's to explicitly say "I don't care").
I still create dumbass bugs in Rust, but they are usually simple logical errors that are pretty obvious when debugging.
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 :)
> 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
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.
The difference is the checking, and actual enforcement of it.
Go and use get_unchecked if you want to and get C like behavior. But the safety note tells you the potential issues:
Safety
Calling this method with an out-of-bounds index is undefined behavior even if the resulting reference is not used.
You can think of this like .get(index).unwrap_unchecked(). It’s UB to call .get_unchecked(len), even if you immediately convert to a pointer. And it’s UB to call .get_unchecked(..len + 1), .get_unchecked(..=len), or similar.
https://doc.rust-lang.org/std/vec/struct.Vec.html
> 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.
> 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.
> 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.
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.
Are there any languages other than C and C++ that have this “nasal demons” interpretation of undefined behavior?
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.
Are you asking if there are programming languages in which how undefined behaviour behaves is strictly defined?
I’m talking about the “non-local” flavor of undefined behavior. For example, I’d expect the following code:
to always print 0, but it can it fact do anything at all.I think so, at least when it comes to assuming that multi-threading data races don't happen.
Rust and Zig do, and I think also Go.
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.
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-...
I guess parent argues that:
Therefore, what's the justification of not using a memory-safe language (as opposed to an unsafe one)?> 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.
> because lots of seemingly valid programs won't pass the borrow checker
Some straight-up valid programs as well
Rusts memory safety constructs do also impose a (much smaller) runtime performance penalty. Every Arc / Rc is a memory safe abstraction with runtime cost since rust has no way to prove cyclic reference graphs are safe at compile time.
Interop.
> 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.
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
> 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.
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.
> Who is using native UI in 2026?
Swift. Which is similar to Rust in some ways actually.
> 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.
> 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
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.
Following your analogy, if there is a way for the lawyer to never lose a case due to misinterpreting the law...
Fixed since 1.22.0
You're only proving unsafe Rust is tricky. Even for experienced maintenaners.
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.
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.
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.
Sure. It was a simpler time.
Web didn't make massive regression in UI, it made minimum feature set huge.
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.
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.
First they have to decide what distribution actually matters for the desktop, out of hundreds that get forked for frivolous reasons.
And yes accessibility and localisation were already a thing in Windows 3.x, classical Mac OS, OS/2,...
I'm talking about accessibility and localization as part of a GUI toolkit.
Take localization. Any doofus with CSV and regex can localize a binary. How do you localize dynamic things like "Hi (Sir) PJMLP, you have (0 unread messages)"?[1]
In JS I can always Intl.PluralRules. Where are my Plural rules in say C#'s Avalonia (or whatever GUI is hot in C# these days, I can't keep track)?
The issue isn't a checklist; it's a quality of availability [2]. The complexity there is essential, because languages are complex beasts, and mitigations for disability are getting better and hence more complex[2].
[1] Why is localizing this a problem? Some languages are language neutral, some have honorific speech, which changes other words, and some have different ways of counting (Hello Welsh. Nice that you have ordinals for zero, one, two, few, many, and more), some have genders, some don't, some have but don't use it in some cases, ad infinitum.
[2] There is a huge Mariana Trench in the quality of accessibility for software that offers a magnifying glass and software that offers text-to-speech.
And I am talking that was already available in 2000's.
Do I have to link to digital copies of documentation to make my point?
Sure. Show me how Windows 3.* supported Unicode, i18n (internationalisation), l10n (localisation), a11y (accessibility), with special focus on CLDR plural rules.
Which will be interesting since Unicode 1.0 came around 1991. And CLDR in 2003. And Windows 3.x came in 1990.
I'm not saying it is impossible, just highly unlikely MSFT implemented those as early in 3.x. They could have taken part in those early efforts.
If you are so keen in Windows 3.x, remember before standards each OS did its own thing, and I can gladly show you the proprietary APIs used by Windows 3.x.
I imagine you never coded for it.
I'm keen on you explaining this part:
(emphasis mine)Because it's the one I used of the things listed, and from my memories, its accessibility was extremely lackluster.
I don't care about API as much as you explaining what its a10n features were.
None of the things you mention would have been impossible to integrate in native GUI. They're platform features.
For someone using a GUI toolkit, there is a massive difference between "invent and integrate your own" and "it comes pre-installed".
I'm saying the reason modern cross platform GUIs are hard is that the developer and user preferences have changed. Developers want GUIs that come with many bells and whistles.
This raises the bar for minimal implementation from - "it will take one guy two weeks to implement" to "it will take a huge group decades of effort to implement."
And that's JUST the implementation. At any point, you also face an adoption cliff. Sure, your super layout engine (SLE) might automatically layout stuff, but Josh here doesn't know SLE, he knows CSS.
Yeah but whatever the browser provides, the OS can also provide. You don't have to reinvent a browser when you code outside of it. Anyway, this conversation had slipped out of the window. Web app UI programming tools still suck compared to what we had 25 years ago and say what you will, there's NO good reason for that.
Which OS? This is talk about cross-platform GUI toolkit.
My point was, "Why X language sucks at cross-platform GUI" is because X isn't JavaScript or TypeScript, and it's not backed by the huge corpo that is Google.
> Web app UI programming tools still suck compared to what we had 25 years ago
Funny. I can think of few examples, namely Flash, Dreamweaver, and Delphi, but that's more rose-tinted glasses than any objective metric. They all did a few things better than the modern web but failed in so many other ways.
> 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
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.
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.
> 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.
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.
> 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.
> The entire point is that being so absolutist is silly.
You're misinterpreting what Rust people are telling you.
- Rust is safe lang
- Nah, C is safe if you're good
- Rust evangelical gestures towards billions or CVEs brought on by overly-sure C programmers
- Yeah, well, a version of Rust was unsafe for few months ten years ago. Besides Zig prevents more bugs than C and is the successor
- Rust person points to Bun's abysmal record
- Stop being absolutist.
The issue is that in C or Zig few people can write mostly UB free code. In Rust anyone can write UB free code as long as they don't reach for unsafe.
It seems odd to me to put this much effort into misunderstanding what people are saying. You just end up talking past everyone, essentially talking to no one about nothing.
If it wasn't obvious from my ramble, Rust concerns are pragmatic, not absolutist. The only absolutism is that for memory safety to be truly upheld, you can't half-ass it (Zig) or ignore it (C).
Some properties are like that.
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
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.
So how exactly would this shooting in the foot look like compared to say java
Too many to list, but for some examples:
You take a reference to a vector element, which you later accidentally invalidate by pushing to the same vector.
You move out of a unique_ptr, but then you accidentally use it again.
You create a cycle with shared_ptr causing a memory leak.
If you std::sort a list of floats with NaNs (among other things) you can stomp over memory. The sort function requires some very specific ordering otherwise you get UB.
thx! For some reason I thought Java too has invalidation problem
[dead]
> 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.
They do when using hardned runtimes configuration, which was compiler specific, and starting with C++26 is officially part of the standard.
It naturally doesn't cover C style programming in C++.
The hardened runtime improves things, but it's still a far cry from memory safety. For example `std::vector::erase` has no hardened precondition. And of course the rest of the language around the stdlib is still entirely unsafe, not just the C parts.
In theory, that will be taken care of with contracts and further revisions.
In practice, it depends on how the contracts drama folds out.
However I do agree it is still not quite there.
Still, C++ isn't going anywhere anytime soon, so any improvement is welcomed, even rustc has to gain from it.
I don't expect any RIR for GCC and LLVM happening any time soon, not only due to existing code, also due to all universities, and companies that contribute to upstream and aren't racing to adopt Rust.
What you mean by smart ptrs not being memory safe? Vector access can be done with at method
As I said, unique_ptr (or any of the others), do not check for null. So you can do this, and it will cause a segfault:
Similarly unique_ptr::operator[] doesn't (and can't) do bounds checking, for example: There's also no attempt to limit the construction of invalid smart pointers, for example: Smart pointers simplify memory management, and they're slightly harder to misuse than regular pointers, but they simply make no attempt at providing memory safety.Which unfortunately most people avoid using, and until C++26 there is no at() for span.
The best is really to enable compiler specific hardening.
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.
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.
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.
> 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.
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 is just a tool. A decent tool that I think can be made better (by removing stuff and stop adding more stuff to the surface syntax). So I am down to criticize Rust.
However, I also don't understand how people don't see the usefulness of what Rust put to the mainstream: algebraic data types, sum types, traits, etc.
I also get super annoyed when people think Rust is only chosen for "safety". Says frustrating things like "so I can just use unsafe", because no you don't and if you do I would reject your changes immediately.
Honestly, in general, I am just annoyed when people don't use the right tool for the right job. And attempts to fix the tool with more bespoke stuff on top it.
Yes. To me personally, Rust and both its restrictions and features (ie no OOP and prevalence of sum types and hence other goodies) makes approaching the implementation of big problems differently; eventually the experience with Rust also changes (to some extent) the way you write and structure the code in other languages. One might argue that Rust is not unique here and this would also apply to languages like ocaml etc - sure, perhaps; but I can't write in any of those languages at work on daily basis since they don't fit performance-wise or for many other reasons.
> Says frustrating things like "so I can just use unsafe", because no you don't and if you do I would reject your changes immediately.
This is the kind of hostility (which is frankly toxic) that’s become associated with parts of the Rust community, and has fairly or not, driven away many talented people over time.
Overly enthusiastic Rust evangelists can be annoying, but nowhere as much as C++ or C advocates defensively claiming memory safety isn't a big deal, and they are going to have it in the next version of the language anyway.
I find my experience with Erlang has helped with the (considerable) learning curve for Rust, but I still prefer Go for most use-cases.
> claiming memory safety isn't a big deal
There are contexts where it is, there are contexts where it is not.
But suddenly everyone out there is dealing only with those context where it is.
1000x yes. Rust is not a One True Language, there exists no One True Language. Rust made some improvements over previous languages (many of which were ported over from previous languages that demonstrated the value but weren't break out successes) and serendipitously those improvements added up to something that was really significant and unlocked interesting and useful capabilities. I'm never going back to how my workflows were before I learned Rust (though I still write in other languages everyday).
But there will be other languages in the future that will continue to deliver small improvements until one day they result in another phase change. The honeymoon with Rust will be over and it will start feeling more antiquated.
C, Python, Java, are just a couple random languages that were/are similarly influential. (C is of course orders of magnitude more influential, the only language more influential is probably COBOL?)
The weird thing about this is many core Rust people agree that Rust is not the best language that could possibly ever be, even evaluated by the core principles of Rust (that is: no UB, no mutable aliasing, no memory bugs).
And if we move outside of Rust's memory model, some people have raised issues with the inconsistent syntax, and the module-based compilation model which makes compilers inherently slow, as you have to parse the whole module every time.
So there's room for improvement, and people are already working on putting ideas into practice, and some of these people who came from the Rust ecosystem itself.
And if you happen to disagree with Rust's core goals (or just place less emphasis on them), then it's obviously not the perfect language.
> But there will be other languages in the future that will continue to deliver small improvements until one day they result in another phase change. The honeymoon with Rust will be over and it will start feeling more antiquated.
That language may well be Rust itself, especially if they manage to figure out the "how to deprecate standard library features across language editions and allow reuse of their idiomatic syntax?" problem.
I think Rust has a big flaw to overcome in the age of LLMs: slow compilation.
If they can't fix this, a language with similar guarantees, even syntax, but fast compilation is bound to succeed in niches where Rust is desireable.
Iteration speed is a big bottleneck in agentic workflows. Well, any workflow.
Totally true. Similarly I think a C revival is more likely than people might think because of Fil-C, improvements to the language standard, and maybe hardware improvements like CHERI. Eg, maybe there will be a new generation of Fil-C like compilers, maybe C will get a lot easier, and maybe that will cause C to displace Python as the preffered pedagogical "first language" (which would really be reprising it's role). Not because it's easier than Python but because it's easy enough and we start emphasizing low-level optimization more because AI is eating all of our compute. Stranger things have happened.
I can see some interest in Fil-C, but some will still be against it due to the overhead it imposes (1.5x-4x worse performance, less deterministic since there's a GC), as well as the program will simply crash on arbitrary memory reinterpretation, use-after-free, and reading uninitialized memory. This is certainly better than it continuing, but certainly not as good as it could be.
CHERI has different characteristics in that it will crash for buffer overflows, but crashing on use-after-free is opt-in, it can only detect double-frees sometimes, it does nothing about uninitialized memory access, etc. It also requires adopting new hardware, which may be a hard sell.
In all I've mentioned above, I haven't even touched thread safety or integer safety which these do nothing about.
So with that being said, do as you please, but understand that simply adopting these is a different level of safety (program will not be exploitable but will crash) compared to something like Rust (program is not exploitable and will not crash because these issues are mostly* compile-time errors).
* "Mostly" since I mentioned integer safety which will be a runtime crash like the C safeguards, you can use unsafe, etc.
> I can see some interest in Fil-C, but some will still be against it due to the overhead it imposes (1.5x-4x worse performance, less deterministic since there's a GC)
Yeah this is where I stand with it. Fil-C seems to be the worst of all worlds. It combines the performance of an immature GC language, with the primitive syntax and ecosystem of C. (Eg nullability, void*, no generics, no collection types, a bad standard library, header files, no good build system, bad cross-OS portability, BYO strings, etc).
I don't choose C for its wonderful syntax. I choose it because its small, light and performant. If I was happy to use a garbage collector, I'd much prefer to go all the way and grab Typescript, C# or Go.
The only use case I can see for Fil-C is running legacy code that you can't be bothered porting to a better language.
Don't forget the compatibility issues: Fil-C isn't really usable if you mix C with other languages in the process.
It's especially problematic to have multiple different garbage collectors; so given the desire to reuse libraries across language boundaries, there's still a strong demand for Yolo-C, C++ or Rust.
Really what I'm getting at is that people are not done innovating on C ergonomics and safety and that there is potential there. Not that there is a new shivel-ready paradigm shift that has arrived to C. I'm only saying that that may happen and that it is more likely than most people credit.
Fil-C is actually not very low-level efficient, Golang probably has better efficiency (being built from the ground up for lightweight concurrent GC) and a hypothetical support within Rust for "pluggable" GC heaps might be even more clearly preferable.
If your LLM can output 10-100x the LOC output, and it's equally good at all languages, and you're not bound to an existing language choice or ecosystem, why not choose Rust?
Rust code will be faster, safer, and easier to ameliorate bugs in.
Rust seems like the best language to serialize business logic to now that LLMs are so good at it.
If the LLM makes a mistake in Javascript or Python, you literally won't know until runtime. With Rust, you'll know immediately and have really good compiler recommendations for fixes.
I think Rust is the best LLM language. I am somewhat biased: I've written Rust code for ten years, and I'm having a blast with Claude Code writing it for me instead now. But I've also used so many other tools and languages - enough to say that Rust has some unique advantages here. And also that Claude does a fantastic job emitting Rust.
LLMs emitting Python feels like building with clay. LLMs emitting Rust feels like building well-engineered steel skyscrapers.
I'm also having a really good time having LLMs write code in Rust. In Typescript they tend to abuse `any` or just cast stuff around, bypassing the type system at every corner. In Rust they seem to take compiler errors to heart and things tend to work well.
You might also have success asking your agent to run `eslint` at the end of every subtask and instruct it to always address lint errors, even if they are preexisting. I agree with your diagnosis; there's "implicit prompting" in Rust being more strongly typed and the agent "knowing" that going in but we can compensate with explicit prompting. (You do also have to tell it to actually fix the lints, I find, or it will conclude they aren't relevant.)
I do choose Rust. For now. I write Rust everyday. I'm generating Rust at this moment.
But when I learn a better language I will adopt it.
> LLMs emitting Rust feels like building well-engineered steel skyscrapers
Oh the irony.
Good thing that real engineers cannot build their skyscrapes with LLMs.
> But there will be other languages in the future that will continue to deliver small improvements until one day they result in another phase change
I agree, and I'm interested to see what it is in the age of LLMs or similar future tools. I suspect a future phase change might be towards disregarding how easy it is for humans to work with the code and instead focus on provability, testing, perhaps combined with token efficiency.
Maybe Lean combined with Rust shrunk down to something that is very compiler friendly. Imagine if you could specify what you need in high level language and instead of getting back "vibe code", you get back proven correct code, because that's the only kind of code that will successfully compile.
Sir/Madam/Sovereign... did you hear about Prolog? ;)
This isn't the first time someone has said that to me, so I really ought to make time to learn it.
> (C is of course orders of magnitude more influential, the only language more influential is probably COBOL?)
Lisp. Which coincidentally solved memory management over a decade before C was created.
I also think ALGOL was more influential than COBOL, but measuring influence can be tricky.
Rust is an amazing tool that sadly has the most toxic self-righteous community in PL. Like doxxing that kid for daring to post he refactored his pet project from Rust to Go.
Every community has these assholes. In my experience, the Rust user base is nothing but polite, understanding and pragmatic. There's no smugness, explicit or implied. The Rust lore is just a joke that's getting less funny every day someone takes it seriously.
I feel like it's far easier to find more zealously anti-Rust people than zealously pro-Rust people - hating Rust has almost turned into a meme.
They are people of very similar mentality, with opposing sensibilities.
The rest navigate quietly, bobbing in the rippling wakes of their passionate fighting.
Technically, I prefer Rust but I understand people who find Go better suited for their work. For example, devops is mostly Go nowadays and that makes more sense than Rust (or Python).
But I've never, ever seen toxic behavior from the Go community. For Rust, it's the norm, sadly.
Yet, almost every Rust thread here serves as a evidence that your experience doesn't reflect reality.
Frankly, I see _a lot_ more uninformed attacks on Rust than actual Rust evangelism / snobbery. And most of these anti-Rust comments reek of personal insecurities and low-effort trolling. Like saying that Java is slow. It's getting old real quick.
> Rust (...) has the most toxic self-righteous community in PL.
You never dealt with C programmers, did you?
I agree with this (short and sweet) piece. I'm Rust user but the crab-hype turned me off for the long time.
Personally I'd prefer writing Haskell but there are sharp edges I can't overlook (like constantly breaking LSP of 11/10 difficulty on producing distributable binaries).
I cringe every time I spit out 50 lines of boilerplate just to get C done Rust, but it's best tool I found that's good enough in many scopes.
I don't think Rust/PHP are all that much more safe than Zig/C++.
80% of memory safety bugs in C++ are just basically "array out of bounds", for which you don't need a memory checker at all just array bounds checks which LLVM has enabled by default for Rust but you can also use it for C++.
70% of vulns in C++ are memory related but only ~10% of those would be caught by borrow checking. Most are already caught by forcing object initialisation and array bounds checking. Only use-after-free is caught by either borrow checking OR OTHER TOOLS like ARM has 4 bits in addresses that can encode if the memory location has not been pulled from under you.
So aaaaall this trouble if the borrow checker to have in some cases max 10% fewer vulnos.
I'm not going to switch to Rust/PHP just for that little memory safety bonus.
As someone who has only used zig a little
I've has more core dumps/seg faults than any other language I've ever used.
Skill issue? Yes, 100℅, it's definitely due to my lack of skill in the language
The only time I've ever made a rust program seg fault is when using nightly macros/"features" and being on stable, leading to rustc crashing with a nice error and then I change to nightly
and that was caught at compile time...
Skill is a huge factor in safety
"70% of vulns are..." Yes, production code written at huge companies by experts... If experts are making those mistakes, that says a lot about it IMO
That being said, I'm not a "one language for all", they have their place, embedded rust is hilarious as it's essentially a requirement to have unsafe blocks in your initialisation
Anyway rant over
I'm curious about the exact exchange that prompted the author to say this.
> refuse to admit there are alternatives to RAII
I'm even more curious about this. Can the author or anybody else explain what this means specifically? Can anybody list those alternatives other than GC and RC?
PS: Computer Science isn't exactly my primary professional competence.
Batching/arenas can get you very far. If you adopt the zig/c object model as “things that have data” most destructors become useless. Resource management also can be accomplished at the batch level (eg you can free a bunch of fd’s all at once with a management layer rather than having each File object implicitly manage its own fd). For memory management, i believe proper use of arenas and batching tends to be faster than each object managing its own memory but idrk tbh. What the author is saying is that you dont have to have raii, you can use approaches like the one i described and they can still be pretty safe if you know what youre doing, but rust’s model basically prevents this if youre using rust idiomatically
Yeah if your program has a natural notion of a "frame" (eg most video games), you can do memory management by simply incrementing an integer (bump allocation). At the end of your frame, you reset the integer to zero. You can't really get any faster than that.
An additional benefit of this style of allocation over malloc/free is that you can get a lot of the same type of objects contiguous in memory so that iteration over them is a lot faster because there are fewer cache misses.
What is a 'frame'? Are you referring to the stack frame?
I forgot about the arena approach. So, which language is the best to try it out? How does Zig look? I have been putting off my attempts to learn it, due to the fact that it's not stable yet. Perhaps it's time to give it another go?
Rust is boaring! I ll never use Rust for something I build for fun.
It will be a shame if new programmers will stay away from C because of all the scaremongering regarding the consequences of not freeing some memory (in some toy, pet project) in their own computers.
You seem to believe that Rust prevents memory leaks. It does not, and that's not what "memory safety" means.
Yes, Rust does not guarantee that it'll prevent memory leaks. But the design of the language does make it harder for you (and your collaborators/dependencies) to accidentally leak memory compared to, say, C++.
Sherlock Holmes liked to say "When you have eliminated the impossible whatever remains, however improbable, must be the truth".
The same is true for programming languages. When you have eliminated all the others for their fatal flaws, only Rust remains, so it's not "just a tool", it's the best tool (or less worse, depending on how you like the syntax).
You can read more about the technical reasons here: https://kerkour.com/rust-software-engineering-reliability
This is why I get turned off hearing about Rust (and I use it from time to time). You can say Rust is good without saying other languages are bad.
Luckily software development is not a static crime to be solved.
It's an evergreen field to be researched forever. With languages coming and going. ;)
hah hah hah!
All technology is just a tool, unfortunately it turns into religion like behaviours, because it defines with whom we work, what projects we can work on, what CVs get through HR and which ones don't,....
> religion like behaviours
That phrasing makes me imagine a cultural anthropologist studying the behavior of programmers in the wild, their tool use, rituals, magical worldviews like object-orientation. There's that classic paper about how a language is a "tool for thinking", that it both expands and limits how and what a person can think. It makes sense that it shares characteristics with religion, a conceptual system of interfacing with the world.
Well, since you asked for it, :)
https://youtu.be/ocwnns57cYQ?si=GLb9kNEcAQkaM0up
Literally laughed out loud at the very first sentence spoken with that voice. Haha.
>That phrasing makes me imagine a cultural anthropologist studying the behavior of programmers in the wild
Google scholar is your friend here
The horror of picking tech working in it 10 or 15 years and then it suddenly becoming obsolete or irrelevant. Is something a lot of people can relate to.
We're a new industry. So long as we keep iterating on our tools, this will continue to happen. Obsolescence is - in this case - an indicator of progress.
I don’t subscribe to the notion that we are „new industry”.
It already is well past 80 years and we can easily add computation jobs and record keeping that were there before those were digitalized.
„Centuries” of experience in other fields for me feels like it is exactly the case of that guy who has 20 years of experience in his CV in software development but can’t write fizz buzz if you ask for it.
There is so much knowledge lost and new guys don’t study centuries of history to build a house or become a sales person. You might study battles from century ago but they are mostly irrelevant.
It’s useful to align groups on underlying philosophies about problem solving and what tooling we will use.
The alternative is way slower and less effective. “Just use whatever language and frameworks you want and solve the problem in a vacuum” would be a nightmare for any team trying to ship.
> Programming Rust does not mean I have to: buy into their marketing hype
> give the same smug lectures about "safety"
I'm often confused reading articles like this, which take for granted the existence of some "rust evangelism strike force" which goes after people on the internet for not liking rust enough.
The way people talk, it sounds like there's some insanely effective marketing campaign going on to promote rust everywhere. But I haven't seen it. Certainly not any more than any other technology people get excited about for awhile, like Go. Or docker when that launched.
Where are these comments? Can anyone give some actual links to these sort of comments people say online, which don't get immediately downvoted? The way people talk, these comments must be made in such large volumes that it seems very odd I don't notice them?
It's way rarer on Hacker News than people alleging an omnipresent Rust Evangelism Task Force is constantly imposing itself on people. I have seen "overly enthusiastic" comments about Rust, but I can count them on one hand. I'm not going to link them because I don't want to dogpile ob people. Note that I read many/most of the Rust threads that make it to the front page.
But I have seen thousands of comments complaining about these supposed evangelists (no exaggeration). Less often and less reliably in the past few years, the meme is petering out. But there's absolutely no comparison of the relative frequency. People complain bitterly about Rust on this forum consistently, actual Rust zealots appear very rarely.
It is simultaneously true that Rust is "just a tool" and that this is a significant fact, and that the people complaining about Rust are the bigger problem in the day to day discourse in Rust related threads on this platform and in the present day.
Yeah, I keep hearing about this toxic community from people who won't blink twice to use decade-out-of-date critiques of Java :)
In this very comments section: https://news.ycombinator.com/item?id=47193361
"all others languages are flawed, Rust is the only that stands the scrutiny" sounds pretty evangelist to me.
Sure; there's one or two unbalanced, positive comments about rust in this thread. Does that seem out of balance to you, out of 113 comments?
If there was a post about Go, Kotlin or C#, I bet there'd be a few glowing positive comments about the languages. I'd be surprised if there weren't.
Is that a problem? I don't want to move the goal posts, but this really doesn't seem like the problem its made out to be. I count far more comments complaining about rust evangelists than I see actual rust evangelism. Even in a thread about rust being a good tool.
What gives?
I think it's that the few enthusiastic fans make such hyperbolic statements, they create drama and stand out among the majority of reasonable users of the language. They attract attention of the people who are curious about the language, and give the impression that the community is hyping it up too much.
The other day I saw a developer who works on the Rust language saying, please tone it down because it's making us look like fanatics. It's healthy to acknowledge that the language is not perfect, it has room to improve, even some fundamental flaws. Oh, I recognize your user name, recently read a great article you wrote - here it is. This was really informative and interesting.
Rewriting Rust - https://josephg.com/blog/rewriting-rust/
It's not marketing. It's just unproductive and incessant.
For example in this PHP post 3 days ago, ofc someone commented about how they ditched PHP and Go for Rust.
https://news.ycombinator.com/item?id=47149752
This is a technical forum. People often flex on what they find better / faster / more productive.
I've seen plenty of comments of people giving up on Rust and going for Go or Typescript for their internal company's tooling needs as well. ¯\_(ツ)_/¯
That's a nice way to handwave drive-by unproductive "rust btw" commnents.
Sure there's comments on all spectrums. But rust commenters are on an extreme end of it when it comes to making sure the world knows how other languages are inferior and often their users too.
If you show me 10 in the last month then we can talk on a more objective ground.
As it is, you're parroting something that multiple people in this thread said they're not seeing.
"Drive-by" comments exist in every thread, too.
Thanks for yet another example if toxic behaviour by that community. So now arguing is also "parroting".
If you were discussing in good faith, instead of belitling arguments as "parroting" you'd use something like algolia to find the answer for yourself. And you could have an easy start by finding comments from the links on this post alone. Let alone 10 in the entire HN in the last month. But that is of little interest I see.
Funnily I already see some on the first page, incredible:
https://hn.algolia.com/?dateRange=pastMonth&page=0&prefix=tr...
You see what you want to see and I refuse to be dragged into a mud-slinging contest. Please reconsider your tone for the future. Start off better and we can chat.
As I predicted, we'll have to agree to disagree.
But not all is lost, the search link is there for those who want to educate themselves.
And you "parroting" comment is exibit A of described toxic behaviour.
I think it's just what happens when something genuinely great comes along. Some people try it and enthuse about it. Sometimes other people who haven't tried it assume that it's just like all the other average things and therefore the only explanation is irrational fanboyism.
We saw the same thing with the iPhone. It was a step change from previous phones. Loads of people were like "it's just Apple fanbois, I'll stick to my N95" without even trying it.
check further down this discussion for immediately downvoted comments
https://news.ycombinator.com/item?id=47191837 https://news.ycombinator.com/item?id=47191619
Post anything negative about rust, or anything about a severe bug in some non-rust code, for examples of your own
I have nothing against rust, although the learning curve is too steep and development in rust is too slow to be a practical general purpose language for a regular company.
The culture around dependencies also means you pay for your memory safety by increased supply chain risk.
Golang or Java gets you memory safety, faster compilation, easy hiring and have better standard libraries
I completely agree with your criticisms. I've been saying many of the same things about rust for years on HN. But I'm rarely downvoted for saying so.
FWIW, I also really like rust. I personally much prefer it over Go and Java. But those are still very legitimate criticisms.
I think it's an old stereotype. When Rust started gaining popularity, I did see comments like that. Even felt compelled to post them sometimes. But now that we have real production Rust experience, we're a bit more nuanced in our views.
Remember Axum or the reflection drama?
You're probably thinking of Actix and the unsafe/TechEmpower thing? I've never seen Axum involved in any notable drama.
Yeah that one.
Yeah; but that was 6 years ago - from way back in 2020. Was it really that traumatic for people?
That was part of Rust Evangelism Striking Force meme genesis.
And then we have the whole reflection drama with the author going back contributing to C and C++ ISO work.
I started periodically asking the same question and I get 20-25 upvotes and then eat 15 downvotes some hours later. One recent example (if ~75 days is recent: https://news.ycombinator.com/item?id=46291249).
It is a very weird case of aggressors pretending to be victims.
Did I see zealous Rust comments? Sure! 4-5 on HN in the last 5 years maximum. On Reddit it could be 10-15 for the same period but the discourse there is not very civil or informative anyway so I started ignoring them and not thinking them representative.
On HN I see regular Rust hate while claiming that zealots are everywhere... and like you, I just can't see it.
IMO it's mostly people who, after being told that only bad programmers need memory management, don't immediately kiss the feet of the speaker.
It's just a tool. But to some people, Rust is more like a religion than a tool and they let it define them to the point even the language maintainers disavow them.
At any point, if you provide any conterpoints or fair criticism towards the language objectively, just expect lots of fans to remind you that it is the best programming language ever created and yours is "unsafe" by default.
> At any point, if you provide any conterpoints or fair criticism towards the language objectively, just expect lots of fans to remind you that it is the best programming language ever created and yours is "unsafe" by default.
This is mostly just a disagreement about what the word "unsafe" means in this context?
"safe" and "unsafe" in the sense Rust uses them aren't a moral judgment about a language, it's a specific (and limited in scope) feature of the language, where memory safety is enforced by the compiler.
I like Rust, though I’m not zealous about it.
Sometimes when you have a really good tool, you want to share it.
This was the case with Linux for many people over many years.
FWIW I agree that the community has some frustrating elements, and that its a lot of dogma in comments, though I actually think that’s a fringe element.
Sounds like the point of the article is that you can just use the language and keep counterpoints to yourself.
Rust does not have the best tooling by far imo.
The IDE capabilities are not nearly as advanced as they are for Java for example.
Compared to C/C++ or dynamically typed languages, sure.
I love that cargo unifies the ecosystem, no quabble over one shitty build tool over another.
I feel like the IDE story still has a long way to go.
Not even C/C++, only if vim and emacs are the only experience one has ever had.
See Visual C++ (with hot code reloading, incremental linking, AI integration, on the fly analysis), QtCreator, Clion (comparable with VS in many options), C++ Builder (with its RAD capabilities),....
Cargo is great as long as it is only Rust code and there is little need to interop with platform SDKs, then it is build.rs fun.
Java has over 3 decades of history, during which many IDEs were developed just for Java, and the ecosystem evolved over that long period. Rust is still way too young.
It doesn't have the same kind of high quality tooling, period. People on the internet are not going around saying "look at Rust, such a young language but already has such awesome tooling like cargo, can't wait to see what we are going to have in few years from now". They just simply claim that Rust tooling is superior to anything else.
Because only thing they know are CLI-based workflows for cavemen.
See the hype about TUIs as if Turbo Vision, Clipper and ncurses never happened.
Once upon a time that was all many of us could reach for.
> and they may prefer different tools to us. > We would do well to accept this.
Why is it better to accept harm from bad tools, especially since we are the ones harmed by those preferences?
> like every popular crate buy into their marketing hype > follow community "best practices"
Yea, I get smug judgement from Rust zealots for not picking the in vogue crates.
I get a lot of help too though.
People are passionate about it. That has good and bad outcomes.
I’m glad that Rust users are willing to accept that other approaches to safety like Ada are also interesting or effective.
In the past I had the impression that some thought that Rust was the first programming language to ever have the concept.
Now we just need the Zig ones acknowledging Object Pascal, Modula-2, Ada,.... as well :)
While these are all reasonable points, there is a distinction between criticising people for using ${lang} (bad) and criticising the language (neutral).
Some people get their egoes attached to their choices (for or against Rust).
Also there's a time and a place for all criticism. If the conversation is not fundamentally about language choice then it's very irritating to have it brought up.
My only gripe with Rust is Rust-Analyzer taking up so much of my system's resources. And I know it is not really fixable which is a bummer.
Rust is a very very ugly language, this is made worse when it is shamelessly promoted by bunch of persistent people with bad tastes.
Also trying to fight runtime behavior with compile time constraints cannot be a universal treatment. Trying to enforce OOP is one of such examples, and it already failed .
Good for systems programming? Perhaps. But to install all the dependencies you need so many crates you literally can install another operating system.
A programming language is a medium to communicate programs to something that can execute them. That isn't exactly the same thing as a tool. A tool in my book is a metaphor for a program that helps achieve some well-defined task. Even if we ignore this difference, we would still want to talk about tool safety.
In my experience there is a C++ mob that hates Rust. These are the people who declare statement of facts as ideology. No good faith dialogue is possible.
There are also competent C++ programmers who misunderstand or don't know how static checking works.
I also witness normal people who are completely surprised by a statement like "C++ is all unsafe" and find that too strong. Using the word "safe" with a technical meaning throws normal people off because, sadly, not everyone who writes code is an academic PL researcher.
"Safe", in Rust and much PL research, means "statically checked by the compiler to be free of UB". If you are pedantic, you need to add "... under the assumption that the programmer checked all conditions for the code that is marked `unsafe`" for Rust. That is all there is to it. Scientific definition.
C++ in its current form is full of gross design mistakes, many of which could be corrected at the price of breaking backwards compatibility. Mistakes happen, aldo to world leading PL researcher (the ML language and polymorphic references) which is why the field embraced mechanically checked proofs. The difference is the willingness to address mistakes.
Academics use "safe" in exactly the meaning the Rust community uses. If you don't understand this, go and educate yourself. Academics need to communicate effectively which leads to technical meanings for everyday words or made up words and jargon.
Maybe a statically checked safe low-level language is marketing genius. It is also a technical breakthrough building on decades of academic research, and took a lot of effort.
Bjarne and friends chose a different direction. Safety was not a design goal originally but doubling down on this direction means that C++ is not going to improve. These are all facts.
Backwards compatibility is a constraint. Constraints don't give anyone license to stop people who don't have those constraints.
We don't have to feel any moral obligation to use statically checked languages for programs. But claiming that static checking does not make a difference is ignorant, and attaching value to one's ignorance certainly seems like an indicator for ideology and delusion.
Everyone's getting the wrong metaphor. Languages are raw material, not tools.
Any recommandation for a quality non-toy rust codebase to study?
Two arbitrary picks:
https://crates.io/crates/serde
https://crates.io/crates/regex
Anything covered by Gjengset's "decrusted" series: https://youtube.com/playlist?list=PLqbS7AVVErFirH9armw8yXlE6...
Sort of on the border between toy and not-toy; Gjengset implements a concurrent hash map: https://youtube.com/playlist?list=PLqbS7AVVErFj824-6QgnK_Za1... [17hr recorded over 3 streams]
The rust standard library is excellent. Start more or less anywhere, and click "view source". Or open up the source code files on github.
There's often a lot more comments than code, which is kind of annoying. But it really is the best way to learn how a lot of good rust is written.
Vec is a good read: https://doc.rust-lang.org/src/alloc/vec/mod.rs.html
Here's the lovely slice::binary_search_by: https://doc.rust-lang.org/src/core/slice/mod.rs.html#2967-29...
[dead]
"$LANG is just a tool" has never been right. The Sapir–Whorf hypothesis (or the blub lang analogy - and not the smug part - for programmers) is still true to this day.
tl;dr: Just a tool, but "we shape our tools and then our tools shape us".
We need more courageous people like him.
Next you're going to say the choice of vim or emacs is just about editing text.
BURN THE HERETIC!
[dead]
[flagged]
We've had memory-safe languages for 50 years, don't act like Rust is the first one.
Rust has nothing new (even the lifetime stuff is copied) really. It just marketed itself really well. It got a huge number of migrants from JS/TS ecosystem, and python, and some from the C(+*) ecosystems.
Its a good language dont get me wrong, but also a huge pita to work with.
> Rust has nothing new (even the lifetime stuff is copied) really.
Rust has nothing new by academic standards, and this is an explicit goal of the project. (And that's why it has yet to support e.g. Haskell-like higher-kinded types; or dependent types for compile-time programming: the interaction with its low-level featureset is very much an open question.) It's incredibly novel as a production language, of course.
It has nothing new but they did a good job at cherry picking what what nice in other languages.
Which makes it an interesting language to learn actually. I even feel like Rust can even be a superb first language to learn for a new programmer : that’s a journey for sure but it would expose you to most of the modern programming concepts.
> [Rust is] a good language [...] but also a huge pita to work with
This is practically the elevator pitch of the language :) and I speak as one who likes it a lot!
Saying it has nothing new seems like an uncharitable take. Yes, it has influences (that rust docs dedicate a page to [0]), but PL theory has such a rich body of literature that you can make a similar claim about virtually any language. It's the whole package that matters, and I don't think there's anything "rust but earlier" to point to there. Certainly isn't Ada.
[0] https://doc.rust-lang.org/reference/influences.html
Rust is cool but there is way too much dogma around its memory safety and static typing in general being a panacea. Most errors are not type errors. Two days after Cloudfare's little Rust hiccup that took the internet down for a day I saw people posting about Rust "if it compiles it runs".
I actually don't think this is true. I do think that most programming errors are type errors, in the broader sense of one part of a system making one set of assumptions about the properties of some data, that aren't shared by another part of the system; and that would've been caught automatically by sufficiently sophisticated static correctness checking. I do not think that Rust has a maximally sophisticated type system (nor is it trying to), and while this is reasonable for Rust as a project to decide, I do expect that there will be languages in the future that do more complex things with type systems that might supplant Rust in some domains.
The Cloudflare incident was caused by a confluence of factors, of which code written in Rust was only one. I actually think that Rust code worked reasonably well given the other parts of the system that failed - a developer used unwrap() to immediately crash instead of handling an error condition they thought would never happen; when that error condition did happen the Rust program crashed immediately exactly as expected; and if Cloudflare decided that they wanted to ban not handling an error like this in their codebase, it's a pretty easy thing to lint for with automatic tooling.
If it helps finally acknowledging basic stuff like bounds checking matters, great, this from a guy that rather use system languages with automatic resource management.
"A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
-- C.A.R Hoare's "The 1980 ACM Turing Award Lecture"
From 1980!
C++26 will finally have hardening on the standard library, something that I could already enjoy in 1990's with Turbo Vision, OWL, MFC, VCL, but was too much to ask for on the standard library apparently, even if compilers kept having each own their approach.
It took governments and companies to start mapping CVEs to money spent fixing them, to finally acknowledge something had to change.
Meanwhile on C land, business as usual regarding Hoare's quote.
It's interesting how it's Obviously Impossible to write OSes in garbage-collected languages, and this is proven by the fact successful OSes were written in garbage-collected languages back in the Stone Age, or 1980s, whichever. My current laptop has enough RAM to swallow the entire state of a Symbolics workstation (RAM and disk) without noticing, but it's obviously too wimpy to run an OS written in anything other than C.
(Nitpickers' Corner: "Successful" and "the most commercially successful" are, in fact, two different words. Gots all them different letters an' everything. Therefore, Genera not being as profitable as such Sophisticated Top-Of-The-Line Pieces of Professional-Grade Enterprise-Ready software as MS-DOS doesn't mean Genera wasn't successful.)
Yeah its funny what we can get away with using different design tradeoffs on modern computers.
I've been reading through the SeL4 source code lately. SeL4 isn't a multithreaded kernel. It supports SMP - so, it can use all the cores on your computer. But the kernel itself uses a big mutex. Complex syscalls can't run concurrently.
And you know what? I think its fine. A tiny microkernel like SeL4 offloads almost everything to separate processes anyway. The only things in the core kernel are the bootloader, scheduler and thread cap tables. Device drivers are multithreaded because they all run in separate processes.
Having the kernel itself effectively single threaded reduces a whole class of bugs and complexity, at a (hopefully) negligible performance cost. Its smart.
I noticed now that I didn't fully got your point, I do agree and the point with Android userspace also stands.
Better half victory than trying to change the whole world in one day.
My android with garbage collected userspace challenging Termux folks, works just fine....
This industry pretends to be driven by technical considerations, yet, with some exceptions, is mostly driven by fads, folk knowledge and aesthetic choices.
Folk knowledge may, and often is, grounded in reality and real experience, but let us not forget that most heated debates in programming of today are rooted mostly in tribal logic and fad chasing.
Static vs dynamic typing is a chief example. Empirical evidence that static typing makes some real difference in terms of bugs or safety is inconclusive at best. Yet it doesn't prevent some people from literally shaming those that prefer dynamic languages. Same with OOP - for years it was everywhere, now you may have an impression that it is a sin to ever use it. But now, as much as back then, there is no evidence to support claim that using or not using OOP is "one true way".
Now, memory safety is a real concern, and we can confidently say that we have found ways (exemplified in Rust) to prevent whole class of issues, but suddenly we are in the situation that every single bit of code out there is supposed to put memory safety as a chief concern, no matter if we are talking about some high perf web server, missile control logic, simple script solving Lotka-Volterra equations or simple calculator app.
> Most errors are not type errors.
If you follow good strong typing principles, you can ensure that most errors are type errors. Yaron Minsky’s phrase, “Make illegal states unrepresentable”, captures this. But it doesn’t happen by accident just because you’re using a strongly typed language.
Also, if Cloudflare had run the standard Clippy linter on their Rust code, and taken the results seriously, it would have prevented the issue you referenced. Static checks don’t help if you ignore them.
Rust doesn't eliminate all bugs. But anecdotally, by the time the type checker and borrow checker have humbled me, my programs really do often work the first time I run them. Its quite remarkable.
This isn't a special thing about rust. All languages are on a spectrum of "detect all bugs statically" to "detect all bugs dynamically". Rust programs run correctly "first time" more than javascript, more than typescript. But still less than haskell.
You can still write bugs in rust, obviously. I've written plenty. As you say, so has cloudflare. But strong typing does find a lot of bugs in practice.
> Most errors are not type errors.
With a sufficiently strong type system all errors are type errors! Rust doesn't have that of course, but it does have quite a strong type system so this is a very bold assertion with no evidence.
Rust does have an "if it compiles it works" feel. Nobody means that literally (this should be really obvious). They just mean that once you get it to compile the chance that it works first time is quite high (like 20% maybe?) compared to most other languages where it's more like 1%.
I don't think your comment deserves the downvotes (upvoted to compensate) but I do think that it's questionable if "Most errors are not type errors" is true.
Rust's culture of pushing things into type checking does eliminate a huge swathe of bugs and I wouldn't be surprised if it was the majority.
The hurdle of negotiating translation between filesystem strings and unicode strings strikes me as a good example of a place where most languages don't protect you from bugs and a strongly typed one does. The downside, of course, is that you have to handle these cases (even if it's to explicitly say "I don't care").
I still create dumbass bugs in Rust, but they are usually simple logical errors that are pretty obvious when debugging.