23 ms·
Several core problems with Rust
- EnPissant 11mo ago[flagged]
- paulddraper 11mo agoWhy do you think that?
- deadbabe 11mo agolists, em dashes, headings and typical length of LLM response.
- tptacek 11mo agoYou think an AI wrote "So, is the Rust bad or good? It’s neither. It’s a mediocre programming language with thousands of man-month put into its development — this fact alone makes Rust a viable tool"? No it didn't.
- EnPissant 11mo agoI 100% think LLMs were involved in its production, just not written wholesale.
- byko3y 11mo agoIt's 200% LLM used in production — like 10 hours of dialogs right before writing the article. I had much more hours of coversations with Rust fanboys and it was mostly a waste of time, they just would not try to negotiate on Rust's weak points. I would definitely not be able to write the article with only human support — it's really sad to conclude that LLM-s are much better assistants because they are neutral and objective.
- EnPissant 11mo agoWere any parts copy pasted from LLM output (and possible changed after)?
- byko3y 11mo agoWhy would I do this and why do you think I did? Or do you feel like my english is so bad I'm probably writing ransom note out of pieces of LLM output? I can ensure you I'm good enough at typing and talking in english to not require copy-pasting. Do you have any quotes from the article that you feel like were copy-pasted from LLM?
- byko3y 11mo agoYeah, the article was written in Markdown, LLM-s employ markdown formatting too. It's not a typical length of LLM response — it's approx 1.5-2.0 times longer than a typical long LLM response. Not easily noticable to a human being though, indeed.
- kstrauser 11mo agoI disagreed with your article, but this critique of it is just goofy. I also write in Markdown, use lists where appropriate, and — gasp! — write em dashes where appropriate.
- sundarurfriend 11mo agosoon we ll hafta rite lyk dis and maybe தேவையே இல்லாம include other languages in the text, just so people won't automatically say it's AI written.
- byko3y 11mo agoBecause it follows same structure as the one used by LLM-s. At least there is a reason to think so — before you've tried to actually read the article and realize LLM-s just don't write text like this... yet. Of course, this structure is also the one used by scientific articles, which I read a lot too, so I'm really inclined to follow this style. "Has the form of scientific article but statements are not precise = AI slop" — that's the implication. Funny fact: one of the reasons Qwen suggested my article is LLM-generated is because it considered link as impossible. I was so gaslit I opened the article and clicked the link. And it worked. Mic drop.
- EnPissant 11mo agoThe ragebait part is because it feels more provocative than sincere. Some examples from the introduction: > Its compilation is slow. I mean SLOW. Slower than C++. I know over years Rust became several times faster, but objectively we need it to be two orders of magnitude faster, not just two times. I've done significant C++ and Rust and Rust compiles WAY faster than C++ for day-to-day incremental compilation. C++ suffers from the header inclusion problem and modules may as well not exist because you can't practically use them. > Arc<Mutex<Box<T>>> This is intentionally over complicated, there is no reason for the Box to be there. > You cannot get 99.999% reliability with Rust — it crashes all the time. What does this even mean?
- paulddraper 11mo agoI don’t disagree with the rage bait assessment.
- byko3y 11mo ago>I've done significant C++ and Rust and Rust compiles WAY faster than C++ for day-to-day incremental compilation. C++ suffers from the header inclusion problem and modules may as well not exist because you can't practically use them. It really depends on what you are compiling. I did lots of C/C++ that compiled 50k lines of code in 10 seconds FROM SCRATCH — I doubt you can do it in Rust. To be fair, headers in that project were somewhat optimized for compilation speed (not "hardcore", but "somewhat"). People forgot how fast C/C++ compilation can be without 10 Boost includes in each module. >This is intentionally over complicated, there is no reason for the Box to be there. Arc<RwLock<Option<T>>> — sounds good now? Don't get me wrong — C++ can be just as horrible, but Rust made it a rule, you can only write your program like this. >What does this even mean? I've already answered above, but I can repeat: there are runtime models that allow crash and recover, there are models that crash and limp. In Rust there is only one model of crash: you just crash.
- aw1621107 11mo ago> I doubt you can do it in Rust. You absolutely can. You'll need to pay attention to how things are structured and not all codebases will be equally amenable to such techniques, but those are shared characteristics with C++. As you said, "It really depends on what you are compiling." > In Rust there is only one model of crash: you just crash. Hardly. Why else would catch_unwind exist?
- tptacek 11mo agoThis reads nothing at all like AI text. It's full of grammatical errors and clipped sentences. It's written in the style of a message board post.
- yoyohello13 11mo agoI think we’ve officially reached the inflection point where the Rust haters have become more annoying than the Rust evangelists. Maybe in a couple years we will finally be able to stop writing blog post about it.
- edoceo 11mo agoNot to worry, another tech thing will be along shortly to fill the hype/hate cycle with its own drivel.
- ozim 11mo agoUnfortunately there are topics that should stop long ago but people still rave about those: ORMs, OOP, Git, JavaScript bloat, Linux vs Windows. Somehow there are always fresh people who think someone cares or that somehow those are important discussions.
- byko3y 11mo ago>ORMs, OOP, Git, JavaScript bloat, Linux vs Windows ORM and OOP whine is niche, agreed. Linux vs Windows is irrelevant because windows runs linux nowadays — I don't think I've read a single article about it. Git? Okay, mostly circumvented by solutions that don't carry any implementation from the original Git, but have "git" in the product name. Javascript bloat? I'm pretty sure that's still a hot topic. I don't remember it being solved, do you? Like if I open website and it greets me with a window suggesting to apply cookie policies for 300 (three hundred) trackers on the website — isn't it worth talking about?
- ongy 11mo agook, I'll bite. What's the git product that only carries the name?
- Klonoar 11mo agoZig currently sits in the hype cycle like Rust/Ruby/Lisp/etc once did here. Eventually something will come along and Zig will be in the hate cycle. In reality none of these things need the religious wars that seem to go back and forth. It's just an incredibly unfortunate and annoying aspect of how programmer-centric communities tend to go.
- nobodyandproud 11mo agoSo, Ada?
- IshKebab 11mo agoTotally wrong. > Its compilation is slow. I mean SLOW. Slower than C++. No way. Maybe Rust 1.0, but it's steadily improved and it's definitely faster than C++ now. > It’s complex. Just as complex as C++. True, but the problem with C++'s complexity is that you have to memorise all of it or you'll accidentally invoke UB. It's so complex that is basically impossible. Rust is complex but most of the time the compiler will tell you if you got it wrong. There are exceptions of course (lots of async footguns) but it's still night and day. > Memory safety is not that sacred. In fact, for many applications malfunctioning is better than crashing Not sure I really need to counter this... > When handling lots of mutable shared state (GUI, DB, stateful services, OS/hardware), the performance of native Rust memory model is subpar, and non-native unsafes just leave you with slow compilation, high complexity, and no memory safety in the end — which makes Rust practically meaningless for heavy mutable state jobs. Not totally clear what he's getting at here. Maybe the ergonomics of GUI style programming which are still being figured out? Hardly a deal breaker though is it? There are plenty of C/C++ GUI libraries with terrible ergonomics and the only one that is actually great (Qt) had to use a custom language extension for decades to achieve that. > So, is the Rust bad or good? It’s neither. It’s a mediocre programming language with thousands of man-month put into its development I would love to hear what he thinks a good programming language is, because I can easily pick more holes in any other language than he has. This anti-Rust zealotry is super tedious.
- singularity2001 11mo ago> I would love to hear what he thinks a good programming language is not OP, but outside of extreme performance critical software I MUCH prefer Swift, C# or python.
- Animats 11mo ago> "there is just no perfect correctness possible in the Turing machine model" Grrr. Clueless people keep saying that. People have been verifying programs for over forty years now. Formal correctness in terms of not violating assertions is possible for most useful programs. As someone pointed out about the Microsoft Static Driver Verifier, if you're program is anywhere near undecidability, it has no business being in the kernel. This not a legit criticism.
- PaulHoule 11mo agoTheorem prover ideas have an impact on Java, Rust and a lot of languages —- it really would be great to see something that accomplishes even more…. Would be nice if you could have a program that lives side by side with a correctness proof.
- PaulDavisThe1st 11mo ago> if you're program is anywhere near undecidability, it has no business being in the kernel. who the hell cares just about "the kernel" (whatever kernel that is) ? I write native desktop applications and they are completely unverifiable.
- baby 11mo agoI mean there's nothing better than Rust, just talk about what in Rust is annoying instead of saying that
- scuff3d 11mo agoUnless I need close to 100% memory safety with no compromise in performance I'd rather write Zig, Odin or Go. Zig and Odin are much more enjoyable to write and provide enough safety for a lot of applications, and Go gets you 90% of the performance of Rust without the complexity.
- snvzz 11mo ago>Unless I need close to 100% memory safety If you need that, you go Ada. Rust is practically the same as Zig, when compared to Ada.
- scuff3d 11mo agoI swear there are people who take a massive amount of pride in using languages or technology that are obscure. That thing use to be Rust, but now that it's become fairly mainstream they have to find something new to move to. I wonder how long it will be before we start seeing "Ada is the new Rust" YouTube videos.
- gr4vityWall 11mo agoThe author would probably find joy in using Zig. Personally my biggest complain from Rust is that I wish it was more readable. I've seen function signatures that seemed straight out of C++.
- nicce 11mo ago> Personally my biggest complain from Rust is that I wish it was more readable. I've seen function signatures that seemed straight out of C++. There is always a trade-off. You really cannot provide enough information for the compiler without the current signatures. There is a certain point where you cannot compress the information without losing some features.
- cogman10 11mo agoIt's always an option to create type aliases, but there's a bit of "robbing Peter to pay Paul" happening when you do that. You make the signature shorter but also take away the ability for the programmer to quickly understand what code is doing.
- gr4vityWall 11mo agoI fully believe you, I don't know what the solution would be either.
- Havoc 11mo agoI was waiting for the part where author advocates for what they like but no it’s just a rant
- PaulHoule 11mo agoSpending out something better isn’t easy. As an applications developer I want to ask “Why don’t you just use Java/C#?” and I’d go so far to say that the software reuse revolution behind Java was not OO or it’s particular approach to OO but rather the garbage collector. That is, building applications out of premade parts is a struggle in C or C++ or rust because memory management is part of the API. C devs would be very concerned about having control of memory allocation and would like to have the choice of reusing a buffer from the application in the library or have the library allocate into an arena managed by the application, etc. It’s complicated enough that libraries can’t reasonably support every scenario application developers would like and ultimately tough because to free something the application has to know if the library is done with it or the library has to know if the application is done with it…. However, the garbage collector knows!. In the end there are a lot of libraries you can’t really write for C or if you can write them you have to write them assuming the application allocates or a certain way or you lose the benefit of being in control of allocation that C allegedly gives you. On the flip side I think C is too high level in some cases, for instance you come to think the gymnastics involved in written embedded C or device drivers are normal but there are quite a few things that are a little bit cleaner in assembly language and I write things for AVR-8 that are rather small but it drives me nuts that C is moving the stack pointer around and following calling conventions that are not at all necessary for these particular programs. I had friends who worked in the IBM Mainframe world where it is still common for applications to have bits written in assembly because of efficiency or to get finer control than you can get with COBOL. Part of the COBOL puzzle is that you have to be a Macro Assembler programmer to work on that stuff and you can’t just port it to GNU COBOL on Linux without also porting the assembly! We’re still living in a multi-architecture world so the interesting idea of trying to make it easier to write assembly (imagine a super macro assembler with an integrated theorem prover) is a non-starter. Let x86 founder for a decade and if RISC-V makes no progress that picture could be different in a few years.
- commandersaki 11mo agoI can accept compilation being slow, slower than C++, but do large projects require >32GB memory, for example the case of LLVM, Chromium, or Envoy? Had to buy a new laptop because of this.
- deleted 11mo ago[deleted]
- cetra3 11mo ago> Node.js and Go are considered practically safe language Node JS has had vulnerabilities in the past: https://www.cvedetails.com/cve/CVE-2021-22940/ https://www.cvedetails.com/cve/CVE-2021-22940/ Go is also not Memory safe: https://www.ralfj.de/blog/2025/07/24/memory-safety.html https://www.ralfj.de/blog/2025/07/24/memory-safety.html
- tptacek 11mo agoNode.js and Go are both memory safe, as are Python, Ruby, and Java. "Memory safe" is a term of art referring to susceptibility to memory corruption vulnerabilities in code written by an ordinary practitioner of the language. Almost invariably, attempts to show languages like Go and Python as memory-unsafe involve a programmer deliberately working to defeat the language. But you can do that in any language, including Rust. There are essentially just two mainstream memory-unsafe languages: C and C++.
- GaggiX 11mo agoIt's easy to cause memory corruption with Go while building a concurrent system, you don't need to learn anything about "defeating the language".
- tptacek 11mo ago"Memory corruption vulnerabilities" != "concurrency bugs" or even data corruption. The last thread I was in about this, someone pointed to Go segfaults and said "see! memory corruption!" (obviously: no). An easy response to claims like this: there's a huge tower of software written Go at this point, including the entire K8s ecosystem. Show me the memory corruption exploits.
- benjiro 11mo agoThe amount of Rust code using unsafe is a major issues for a language build around safety. And yes, the same argument can also be made about Go having a unsafe keyword. The fact that there exist crates to detected the usage of unsafe in dependencies, shows that its a rather liberal used keyword. Geiger comes to mind. Unsafe in a language like Go is very rare, mostly because people do not program at such low system level to get the max performance out of it. Rust code with unsafe: 1.7M Go code with unsafe: 400k and for comparison, Go has about 2.3x the amount of repo's. So Rust has about a 10x more usage of the unsafe keyword.
- valcron1000 11mo ago> Memory safety is not that sacred. In fact, for many applications malfunctioning is better than crashing Yeah, just another data leak, no biggie.
- dlivingston 11mo agoWhat's a bit of arbitrary code execution between friends?
- deleted 11mo ago[deleted]
- themgt 11mo agoYou cannot go along like “I’m writing a cold path high-level code, I don’t need performance, I don’t need to go deeper into lifetime handling, I just want to write a high level logic”. You will be forced into the low level nuances every time you write a single line of Rust. There is no garbage collector for Rust and will never be — you will have to semi-manually pack all your data into a tree of ownership. You have to be fluent in ownership, borrowing, traits to write just a few lines of code. It's still quite rough around the edges, but Crystal is a fun choice for this type of thing. If you want a readable high level language and sane package manager that compiles to reasonably performant machine code, it's worth a look.
- claudiug 11mo agothe issues with Crystal, nim, zig, is that they have zero changes to be bigger.
- preommr 11mo agocrtystal and nim, probably not. Zig... is surprisngly used a lot given how rough the state of the language is. It makes me think that if it ever reaches v1.0, it has a very good chance of being at least a "Kotlin", probably a "elixir"/"haskell", and a decent enough shot of "typescript".
- JackStarborn 11mo agoI'm trying to understand this. The languages mentioned will never grow because others didn't give them a chance, so you won't give them a chance either. Sir, I think I've diagnosed an infinite loop here. I recently started learning Nim. I'm only at the beginning of my journey, and there are things I don't like, but overall, Nim is a very nice language :-) A significant portion of the mistakes one can make in C/C++ can be avoided by writing idiomatic Nim, which is most case is super easy to do :-) EDIT: you=>one :-)
- bccdee 11mo ago> telling a victim “but the memory was not corrupted in the crash” is a weak consolation. We actually had a recent Cloudflare outage caused by a crash on unwrap() function. It’s probably the strongest point of my whining: Rust is memory safe and unreliable. The price of memory safety was reliability This is incorrect in a way that honestly feels insulting. It's not the language's fault that you called the `crash()` function—every language has a way to terminate execution, and for good reason. Crashing isn't even necessarily incorrect behaviour; that's how you pass the error up to the infrastructure layer for handling. The problem here existed at a system design level, not a language level. For the author to paraphrase this (bad) critique like this: > You cannot get 99.999% reliability with Rust — it crashes all the time. is outright dishonest and insulting to me as a reader.
- xwolfi 11mo agoWhy did they name the crash() function "unwrap()" ? Feels weird to me ...
- aw1621107 11mo ago> Why did they name the crash() function "unwrap()" ? Because unwrap() is not guaranteed to cause a crash? panic!() is there if you actually want to guarantee a panic.
- Mauneam 11mo agoFirst, he didn't call the "crash()" function, he called the "unwrap()" function. The fact that they decided to call the crash function "unwrap()" is not the OP's fault, it's the language authors' fault. Second, you totally missed the OP's point about reliability. If one has to choose between UB and an immediate halt, those are pretty sucky options. And the OP is 100% right about Rust crashing all the time. Nothing insulting about that, just a fact.
- rddbs 11mo agoYou get to choose between UB, a crash, or handling the error — same as most other languages. It’s not a reliability issue of the language if as an author of software you choose to crash in your failure handling cases. Claiming otherwise is either disingenuous or a failure to understand what actually happened.
- deleted 11mo ago[deleted]
- cratermoon 11mo ago"they only corrupt user data and act sporadically" The author dismisses these defects, but try telling a financial institution that it's "only" corrupt user data when the books don't balance. Explain to an aerospace company that acting sporadically is just fine.
- cwillu 11mo agoThat was quite literally the author's point.
- diego_moita 11mo agoI was a Rust programmer, for 3 years. Did web backend, kernel programming, network security... Then I discovered that C++ has a very cool feature that Rust doesn't have: jobs. Now, I no longer search for Rust positions.
- vacuity 11mo agoThanks for the laugh!
- cogman10 11mo agoMutable shared state is a feature, not a bug. It's true that it's easier to write correct async code using immutable shared data or unshared data. However, it's very hard if not impossible to do fast and low memory concurrent algorithms without mutable shared state.
- loeg 11mo agoIdk, it's a general rule of thumb that the more mutable shared state an algorithm has, the worse it scales. So if you're trying to scale something to be concurrent, mutable shared state is an antipattern.
- cogman10 11mo agoIt's lock contention that slows things down more than anything. But it's really an 'it depends' situation. The fastest algorithms will smartly divide up the shared data being operated on in a way that avoids contention. For example, if working on a matrix, then dividing that matrix into tiles that are concurrently processed.
- loeg 11mo ago> It's lock contention that slows things down more than anything. It's all flavors of the same thing. Lock contention is slow because sharing mutable state between cores is slow. It's all ~MOESI. > The fastest algorithms will smartly divide up the shared data being operated on in a way that avoids contention. For example, if working on a matrix, then dividing that matrix into tiles that are concurrently processed. Yes. Aka shared nothing, or read-only shared state.
- PaulDavisThe1st 11mo agoas noted someone else, it is lock contention that doesn't scale, not mutable shared state. lock-free data structures, patterns like RCU ... in many cases these will scale entirely appropriately to the case at hand. A lot of situations that require high-scale mutable shared state have an inherent asymmetry to the data usage (e.g. one consumer, many writers; many consumers; one writer) that nearly always allow a better pattern than "wrap it in a mutex".
- fn-mote 11mo agoThe author says "Rust crashes all of the time" and then goes on to invoke the Cloudflare unwrap() as an example of that. Uhhhh... but that was clearly a programmer error, right? Ignoring the possibility of a Result being Err instead of Ok is not something the language is supposed to protect you against.
- loeg 11mo agoYes, but in C++ we would simply not have asserted the result has_value instead of has_error and instead returned some implicit memory corruption. Or, I think that is the author's argument. (I don't subscribe to that point of view.)
- saghm 11mo agoYeah, I don't really get that argument if that's what the author is trying to claim. If there's a language where a programmer mistake can't have bad consequences, C++ isn't it, so either it would need to be combined with an argument that C++ programmers are just better (which seems like a bold claim that would require evidence, on top of not really being about the language anymore), or it isn't really a point against Rust.
- byko3y 11mo agoThere are programming languages/models/runtimes that crash and recover, there are models that gracefully degrade. Rust cannot recover. Neither can C++ in many cases e.g. when you have an exception in a destructor then it's a guaranteed `std::terminate`. Do note that C did not have such a flaw built into language — C++ authors invented it and Rust inherited this flaw (the authors simply did not feel like it's a flaw). I mean specially designed embedded C code can survive total RAM erasure and still perform some meaningful work (with CPU registers and ROM intact). Or compare it to BEAM that can have processes crash all day long and still continue to work. "Memory safety at all cost" is not a practical requirement — it's theological.
- EnPissant 11mo agoNothing forces you to panic in Rust any more than anything forces you to call abort() in C. let a = b.unwrap(); is conceptually no different to: if (b == NULL) { abort(); } a = *b; don't write either if you don't want to halt.
- henning 11mo ago> T, T&, T*, std::optional, std::unique_ptr to describe similar things, each broken in its own way How is `T` broken? How are the other things broken? No matter what language you use, most of the code running between what you wrote and the hardware will be written in C. Your choice for the 1% on top is not very consequential. There is still a huge attack surface area no matter what.
- antonvs 11mo ago> No matter what language you use, most of the code running between what you wrote and the hardware will be written in C. The goal of changing that is a big part of why there’s so much discussion about Rust. > Your choice for the 1% on top is not very consequential. There is still a huge attack surface area no matter what. For an internet-exposed service, the 1% that implements that service is important. Most of the rest of that attack surface is only accessible if an attacker gets past that first layer.
- siliconsorcerer 11mo agoUse D.
- JackStarborn 11mo agoHasn't D collapsed in on itself? D had two or maybe even 3 std libraries. I believe third was just a rewrite of second library. There was two std libraries due to fact language can use GC or don't, so that resulted in problem similar to "what color is your function?". What good is a language whose standard library is in disarray/abandonware?
- alde 11mo agoThe blogs about page is fun: > People create lies to gain power and money. Which is kinda what I was supposed to do, but for random reasons I went rogue and chose sanity instead. > I am anti-bullshit. These "contrarian for the sake of being contrarian" vibes naturally flow into this Rust post. Rust has a ton of faults, but this is was a very shallow critique.
- lordnacho 11mo agoI tend to disagree. - Compile speed. Why do people care so much? Use debug for correctness and iterating your code. You're hardly going to change much between runs, and you'll get an incremental compile. Let rust-analyzer tell you if there are errors before you even try compiling. Let your CI do release optimization in its own time, who cares if CI is slow? - The cloudflare bug was not caused by rust. Every language needs some way to say "hey this thing is invalid", and that's what happened when the list of AI tools got too long (or whatever their business issue was). Making the app panic was a design choice, not a language choice. Every language has a way to not handle errors. - Things having unsafe {...} does not make them unreliable. On the contrary, if you run into a memory issue in a rust program, you know where to look for it. The problem in c++ was that the whole program was unsafe, and you then had no way to narrow it down. Memory safety errors are like type errors: a large class of errors that are worth checking for. If you're writing good c++, you have a linter that checks similar things anyway, and if you're disciplined, you've also upgraded warnings to errors. FWIW, I do think the marketing over-emphasizes memory management, because there are a lot of these hard learned lessons that are default in rust but optional in c++. - Mutable shared state: make bad designs hard to write. Mutable shared state is another one of these eternal bug sources. Use channels and pass messages. Honestly, it reads like a lot of critiques of Rust: people haven't spent enough time with it, and are not over the learning curve yet. Of course everything is cumbersome before you're used to it.
- josephg 11mo ago> The cloudflare bug was not caused by rust Yeah. Rust’s Option::None as like null in C++. Unwrapping an option is like checking if something is null and crashing. This "crash from an unwrap" is just a null pointer exception / segfault in any other language. The same bug would be trivial to write in any other language, and with more or less the exact same result. Its just - weirdly news because it was rust code. What? > Honestly, it reads like a lot of critiques of Rust: people haven't spent enough time with it, and are not over the learning curve yet. Exactly. I’ve spent years with rust and my complaints are very different. Well, I still wish it compiled faster but all the other stuff is noobie problems. As someone with more experience, my frustration points are things like how async blocks do compiler magic you can’t write yourself. I hate unnameable types. I think Pin is confusing and weird. And the syntax for interacting with raw pointers is unnecessarily inconvenient and ugly. Yes, rust makes programs with a lot of shared mutable state awkward to write. So don’t program like that. In general, if you write code in language X as if it were a bad version of language Y, you're going to have a bad time. The right question here is if the "rust way" of thinking about your code results in a beautiful program. You can't answer that if you go in with too many preconceptions of how programs should be designed.
- landr0id 11mo agoRust has its issues and there are plenty of things to not like about Rust, but this article is giving me the impression that this person has not written much Rust. Unfortunately, many such cases with Rust criticism. > Memory safety is not that sacred. In fact, for many applications malfunctioning is better than crashing — particulary in the embedded world where Rust wants to be present. You cannot get 99.999% reliability with Rust — it crashes all the time. Yeah until that memory safety issue causes memory corruption in a completely different area of code and suddenly you're wasting time debugging difficult-to-diagnose crashes once they do start to surface. > We actually had a recent Cloudflare outage caused by a crash on unwrap() function: https://blog.cloudflare.com/18-november-2025-outage/ https://blog.cloudflare.com/18-november-2025-outage/ There were multiple failures before that `unwrap()` and the argument can easily be made that this is no different than an unchecked exception or a release assertion. > Sync/Send, Mutex and reference counting (Arc)? Unfortuantely, those lock or simply mess with CPU caches badly, so they are inefficient for multithreaded communication, at least an intensive one. They are safe, but inefficient. Which kinda destroys the first uncompromising thing in Rust — performance. Doing this the "correct" way in other languages has similar impact? So I'm not sure why Rust forcing you to do the correct thing which causes perf issues is uniquely a Rust issue. Doing this the "just get it done" way in other languages will likely come back to bite you eventually even if it does unblock you temporarily. There are plenty of times I did a `static mut` global in Rust just to get some shit done and oops, accidentally hit some UB as the project grew.
- byko3y 11mo ago>Yeah until that memory safety issue causes memory corruption in a completely different area of code and suddenly you're wasting time debugging difficult-to-diagnose crashes once they do start to surface. Some very solid argument here. However, as already implied in my article, you can get most of the guarantees without losing your sanity. Memory-safety-related problems are important, but they are not the sole source of bugs in applications — as developers of Zed found out. >Doing this the "correct" way in other languages has similar impact? So I'm not sure why Rust forcing you to do the correct thing which causes perf issues is uniquely a Rust issue. Doing this the "just get it done" way in other languages will likely come back to bite you eventually even if it does unblock you temporarily. It might be counterintuitive, but garbage collectors in multithreaded code can be very efficient. I mean you just spawn lots of objects with random references in between and then eventually GC untangles the mess — it's zero overhead until the GC cycle. Escape analysis and semantic-reach containers can reduce GC work a lot (so you don't have the classical JVM GC problems). More specialized things like RCU and general quescence-state reclamation can be totally pause-less.
- dannersy 11mo agoThis is either performance art or rage bait. The opinions here are so wild. There are so many claims here that are wrong and just strange, it is hard to know where to start.
- vacuity 11mo agoSeeing this comment from Kent Overstreet was hysterical: https://news.ycombinator.com/item?id=46029555 https://news.ycombinator.com/item?id=46029555. He's not even criticizing Rust, nor is he the author, but still... But yes, this sure is a nice and sane thread.
- hypeatei 11mo ago> We actually had a recent Cloudflare outage caused by a crash on unwrap() function Oh boy, this is going to be the new thing for Rust haters isn't it? Yes, unwrapping an `Err` value causes a panic and that isn't surprising. Cloudflare had specific limits to prevent unbounded memory consumption, then a bad query returned a much larger dataset than expected which couldn't be allocated. There are two conclusions: 1) If Cloudflare hadn't decided on a proper failure mode for this (i.e. a hardcoded fallback config), the end result would've been the same: a bunch of 500s, and 2) most programs wouldn't have behaved much differently in the case of a failed allocation.
- byko3y 11mo ago>There are two conclusions: 1) If Cloudflare hadn't decided on a proper failure mode for this (i.e. a hardcoded fallback config), the end result would've been the same: a bunch of 500s, and 2) most programs wouldn't have behaved much differently in the case of a failed allocation. So why do they need Rust then? What advantages does it provide? That was the main point of the article — we all wanted a better language, but got another crappy one instead.
- aw1621107 11mo ago> So why do they need Rust then? What advantages does it provide? That Rust didn't prevent one error in one specific instance does not mean that Rust didn't prevent any errors across any instances. Nor does it mean that Cloudflare didn't benefit from Rust in some way(s) elsewhere. For example, from one of Cloudflare's previous blogposts [0] (emphasis added): > Oxy gives us a powerful combination of performance, safety, and flexibility. Built in Rust, it eliminates entire classes of bugs that plagued our Nginx/LuaJIT-based FL1, like memory safety issues and data races, while delivering C-level performance. [0]: https://blog.cloudflare.com/20-percent-internet-upgrade/ https://blog.cloudflare.com/20-percent-internet-upgrade/
- seabrookmx 11mo agoTo prevent all the other potential memory safety bugs that didn't crash prior to this one?
- jhhh 11mo agoYou really have to compare articles like this, which are just a bunch of hand waving around the author's biases, against articles with more concrete statements like the Android team finding a 1000x reduction in memory vulnerabilities compared to C/C++. Thanks for your opinion but I'm going to weigh the people who actually use the language more than you.
- hu3 11mo agoHard disagree. For my reality of developing for smaller projects than Android, I will absolutely weight Android team's opinion less than the opinion of smaller projects. Trying to mimic FAANG engineering practices is a fools endeavour that ranges between naiveness at best and CV padding at worst.
- indemnity 11mo agoThe objective data they provided is opinion now?
- koverstreet 11mo agoFAANG engineeers can't code for shit, but the one thing they did get right was when they jumped on the Rust bandwagon
- TinkersW 11mo agoThe android team wasn't comparing like to like, though people seem to gotten the impression they were.
- aw1621107 11mo ago> Unfortunately, it’s impossible to make Rust compile fast. The problem is inherent to all similar generics-heavy languages, like Haskell. I don't think this is correct, strictly speaking. Furthermore, I think this conflates two common causes of slow generic compilation: - Type-checking them can take a lot of time - Generics may be implemented in a way that generates a lot of code Neither of those are required for generics-heavy languages (e.g., OCaml is generally considered to compile fast despite having a "complex" type system), and the presence of one doesn't necessarily require the other - a hypothetical "simple" generics system with heavy use of monomorphization can end up taking a long time to compile, and a "complex" generics system that erases types may take a while to type-check but could compile fast after that. > Put a non-optional borrow-checker on top of it From my understanding the borrow checker usually takes up a small fraction of the time needed to compile. There are cases where that's not true, but I think people tend to overestimate its impact on compile times. > There are ways to implement unsafe programs that still don’t execute remote code or leak secret — they only corrupt user data and act sporadically. Reliably implementing unsafe programs that don't have RCEs or leak secrets but still corrupt data and "act sporadically" seems like a very peculiar combination of requirements to me, if it's even possible. "Act sporadically" is also quite nebulous, and depending on the precise issue may in fact be an RCE or secret leak in hiding - after all, it's not that uncommon for exploits to start their life as someone noticing a crash. > It’s probably the strongest point of my whining: Rust is memory safe and unreliable. The price of memory safety was reliability in addition to the developer’s sanity I think that is actually one of the weakest points. I didn't see any support for a claim that memory safety necessarily requires trading off reliability, let alone that that is what Rust does. > Step into the shared mutable state — and there a memory corruption is not an exception, it’s a rule. You have to handle the corruptions, you cannot simply crash. What definition of "memory corruption" is being used here? I didn't think that's the kind of thing that you usually "handle"... > Which kinda destroys the first uncompromising thing in Rust — performance. I feel this misunderstands Rust's priorities. (Safe) Rust prioritizes safety over performance, and that has been a well-known tradeoff for basically its entire lifetime. If you want performance at the expense of safety, that is what `unsafe` is for. > So, to reiterate, the second you step into the shared mutable state you lose every single advantage of Rust. Which is kinda rational considering that the main concept of Rust was to never employ a shared mutable state. This misses another useful bit of Rust, which is the ability to contain unsafety to clearly-delimited sections of your codebase. There's more I could say, but life calls...
- koakuma-chan 11mo ago> You have to be fluent in ownership, borrowing, traits to write just a few lines of code. > Rust sacrificed sanity and practicality for memory safety skill issue
- teleforce 11mo ago>Its compilation is slow. I mean SLOW. D language smiling in the corner [1]. "D supports Ownership and Borrowing, just like Rust. DMD, D's reference compiler, can compile itself in less than 5 seconds, thanks to a fast frontend and fast backend. D is easy to metaprogram through traits and templates. You can make your own JIT in D with dynamicCompile." [2] [1] Kevin James meme creator tries to guess why the photo went so viral: https://www.yahoo.com/lifestyle/kevin-james-became-internets-king-003000488.html https://www.yahoo.com/lifestyle/kevin-james-became-internets... [2] Ask HN: Why do you use Rust, when D is available? https://news.ycombinator.com/item?id=23494490 https://news.ycombinator.com/item?id=23494490
- byko3y 11mo ago>"D supports Ownership and Borrowing, just like Rust. DMD, D's reference compiler, can compile itself in less than 5 seconds, thanks to a fast frontend and fast backend. D is easy to metaprogram through traits and templates. You can make your own JIT in D with dynamicCompile." Indeed, there are languages that have generics, compile blazingly fast, and still have good runtime performance. Go lang is another good example, although not perfect too. If only Rust designers did a single thing to make it compile fast instead of "eventually".
- vacuity 11mo ago"Generics" is not why Rust compiles slowly. Rust had certain design decisions and implementation details that impact compile times significantly. Do not misrepresent them and pretend that the Rust developers are incompetent or malicious. By doing so, you invite discourse as ideological and uncritical as that of Rust fanatics, however many or few there are.
- byko3y 11mo ago>Do not misrepresent them and pretend that the Rust developers are incompetent or malicious. I'm sorry, but I sensirely think the Rust designer did a sloppy work by reimplementing C++ flaws with a new syntax. The history repeats itself, the same pathological mechanism once driving C++ development now drived Rust — I mean large enterprise wanting to change everything without changing nothing, the new tool that would feel like the old tool. They did not really invent some new model, look at std::shared_ptr, std::mutex, move semantic — it was already in C++ before the prototype of Rust. The "share immutables, lock mutables" model was a holy grail of C++ concurrency caused by the way STL worked — and STL is not nearly the only container library in C++. Okay, what's your take on why exactly Rust compiles slowly?
- saghm 11mo ago> It’s complex. Just as complex as C++. But C++ had legacy and Rust had not. The complexity of forcing your way through the jungle of Arc<Mutex<Box<T>>> on every single step directly impacts the quality of the logic being implemented i.e. you can’t see the forest for the trees. Once again, C++ has the same problem, so what’s the point of the language switch in the end? Without trying to evaluate a claim about which is more "complex", since that's somewhat subjective (even if I do have some feelings on the matter), I can pretty definitively state that the vast majority of the concurrent code I've written in Rust has not used Arc<Mutex<T>> at every single step (and I don't think I've _ever_ used `Arc<Mutex<Box<T>>`, which would be like having `std::shared_ptr<std::mutex<std::unique_ptr<T>>>` in C++). It's totally valid to argue that the learning curve for Rust is sharp, but I don't think they've made a great case for it here generally rather than just for their specific experience. This even further implied by the idea of a "language switch"; I've been programming Rust for a decade, and I only learned C++ after learning Rust, so from my perspective, I'd have to "switch" to C++ from Rust, and it seems similarly pointless to do so. (I understand my experience is probably atypical, but that's kind of my point; everyone's perspective is different, and I don't think that making an argument based almost entirely out of subjective personal experience speaks very well to a "core problem" in a language unless you can speak to why that's representative of the general experience most people have, and I don't think they've done that here at all).
- deleted 11mo ago[deleted]
- delifue 11mo agoThe biggest value of Rust is to avoid heisenbug https://en.wikipedia.org/wiki/Heisenbug https://en.wikipedia.org/wiki/Heisenbug Memory safety and thread safety are causes of heisenbugs. However there are other causes. Rust don't catch all heisenbug. But not being perfect doesn't mean it's useless (perfect solution fallacy). The article has some valid points but is full of ragebait exaggeration.
- fhap 11mo ago> The article has some valid points but is full of ragebait exaggeration. Given that Rust doesn’t always have critiques that are backed with evidence, this wasn’t bad. People can use C now that LLMs make it easier, so Rust is no longer needed in many ways.
- merb 11mo agoYou are joking, right? Writing c with llm‘s… what can go wrong?!
- ameixaseca 11mo ago> Given that Rust doesn’t always have critiques that are backed with evidence, this wasn’t bad. What evidence?
- leoh 11mo ago>Its compilation is slow. I mean SLOW. Slower than C++. I know over years Rust became several times faster, but objectively we need it to be two orders of magnitude faster, not just two times. Refactor your build. >It’s complex. Just as complex as C++. But C++ had legacy and Rust had not. The complexity of forcing your way through the jungle of Arc<Mutex<Box<T>>> on every single step directly impacts the quality of the logic being implemented i.e. you can’t see the forest for the trees. Once again, C++ has the same problem, so what’s the point of the language switch in the end? If you can come up with something better, write a macro for it. >Memory safety is not that sacred. In fact, for many applications malfunctioning is better than crashing — particulary in the embedded world where Rust wants to be present. You cannot get 99.999% reliability with Rust — it crashes all the time. Learn the language a bit better, use code coverage tools, and write better tests. >When handling lots of mutable shared state (GUI, DB, stateful services, OS/hardware), the performance of native Rust memory model is subpar, and non-native unsafes just leave you with slow compilation, high complexity, and no memory safety in the end — which makes Rust practically meaningless for heavy mutable state jobs. True for C++, too, if you don't implement things properly.
- vacuity 11mo ago> Refactor your build. People do this, and at best it works for some people. This kind of messaging towards people who bring up a valid criticism of Rust does not help.
- leoh 11mo agoAlthough naively factored builds can be slow on rust, I firmly believe that most folks complaining about this problem have not taken the time to learn how to do this and their builds could be perhaps 10x faster. Bringing this up an important counter-point that all too frequently is ignored or met with hostility, as this replier has done.
- vacuity 11mo agoI do not understand how you justify your claims. Should I link any number of instances where Rust team members admit to compile times being a major issue, one which prompts significant effort to improve? Perhaps you are right about 10x speedups, but then that clearly isn't enough, reading the room. I also do not understand how you see hostility in my comment. For one thing, I did not downvote you. Rather, your original comment is dismissive, even if the article it replies to is dubious. For another, it would also be trivial to see that I am both highly supportive and informed about Rust. Your comments simply do not help, certainly not with the common perception of Rust fans as zealots.
- leoh 11mo agoAm I understanding that bykozy is claiming that "Rust is memory safe and unreliable" because Cloudflare crashed due to an unhandled exception??
- Jweb_Guru 11mo agoThis is the quality of discourse I expect at this point from anti-Rust folks, yes.
- rayiner 11mo ago> It’s probably the strongest point of my whining: Rust is memory safe and unreliable. The price of memory safety was reliability in addition to the developer’s sanity — that’s why I’m telling the language designers went overboard. This complaint is nonsensical. If your Rust program panics, it’s because things are fucked up and it’s not possible to safely continue. The alternative is to continue unsafely, which will fuck things up even more. The Linux kernel does the same thing. If it encounters an error, it panics.
- anon-3988 11mo ago> Arc<Mutex<Box<T>>> is complex This is not the language problem, but its simply the nature of the problem no? It is like saying, full adders are complex, can't we design something simpler? No, full adders are the way they are because addition in binary is complicated. What you are saying is that this problem is not your kind of problem, which is fine. Not everyone needs to face the complexity of optimizing full adders. And so we created abstractions. The question is, how good is that abstraction? C++ is like using FP math to do binary addition.
- boroboro4 11mo agoProbably if you use a lot of Arc<Mutex<Box<T>>> languages with proper runtime (like Go or Java) are gonna be more performant, in the end they are built with those abstractions in mind. So the question isn’t only how much the nature of the problem it is, but also how common the problem is, and is rust a correct way to solve this problem.
- marisen 11mo agoIf you use a lot of Arc<Mutex<Box<T>>> you you probably just learn to use Rust properly and just use Arc<Mutex<T>> instead because it pretty much never makes sense to have a Box inside an Arc... I say that as someone that thinks Rust's learning curve is the main reason it rarely makes economic sense to use it.
- tyleo 11mo agoI'm annoyed that this submission's title was changed. This was first submitted with the original title, "Rust is a disappointment," and got flagged. It looks like it's been unflagged and the title has been changed. A quick search of HN shows a bunch of articles, "X is a disappointment," which aren't flagged. Do folks have such thin skin about this topic that expressing disappointment deserves flags?
- ModernMech 11mo agoRegarding slow compilation... On the one hand, I don't regard it as a real "problem" because as the post says, it's by design and the design is that you pay the compilation cost but in return you get something valuable from it: fast safe code. So you pay a fixed cost to compile during development and it's your users and future you who get the benefit of future performance and stability. This is why Rust users are usually okay with it, because the more you use Rust, the less you pay for the compile times. On the other hand, I'm sitting here now 20 minutes into building a random Rust project I found (I believe it's AI vibecoded so I won't link it). It's only 3000 lines of Rust code... I honestly cannot fathom why it's taking so long, because I have a codebase of 100kloc Rust with more dependencies and lots of macros, and that takes only about 2 minutes to compile from scratch. But apparently, some people/machines can write Rust so bad that 3000 lines takes 20+ minutes, and that's just not good at all for Rust. So whereas the slow compilation times are by design, I think perhaps if my daily experience were 3kloc taking 20 minutes to compile, I wouldn't ever use Rust. So I'm wondering if that's how some people's experience with it goes, leading to the disparity of opinions. I kind of want to figure out why this particular project is taking so long to avoid whatever trap the AI coded itself into (aside: this is another problem with AI that I hadn't thought about yet... a human programmer would have noticed the rapidly ballooning compile times and corrected for them before they got absurd; whereas the AI writes it all at once and doesn't factor how the code impacts compile times. So it maybe be technically correct, but also pathological).
- TinkersW 11mo agoMy understanding is Rust compiles each crate in the same way C++ compiles each .cpp file, so if you stick everything in a single crate you get horrible compile times. This does seem like a poor design decision by Rust to me, forcing people to break things into arbitrary crates just to get reasonable compile times. It also seems like a disaster for incremental compilation.
- aw1621107 11mo ago> This does seem like a poor design decision by Rust to me, forcing people to break things into arbitrary crates just to get reasonable compile times. Not necessarily, since codegen units can introduce intra-crate parallelism during compilation. But in any case, as with basically everything there are tradeoffs involved in choosing compilation unit size. Making your compilation unit crate-sized also means that you have some more flexibility in your code organization (e.g., stuff can mutually depend on each other, which is itself potentially useful and/or harmful) and you don't run into other potential issues like the orphan rule. There are also potential impacts on optimization, though LTO muddy the picture. Codegen units are just the cherry on top. There's almost certainly other things I'm forgetting and/or not knowledgeable about as well.
- subspacer 11mo agoover the past decade i've spent alot of time compiling rust code for arm6 / arm7 cpu's, which is a fancy way of saying that in my free time i have spent alot of time running `cargo build` on a variety of raspberry pi's. doing that first when setting up an rpi is a good way to not only grab a bunch of useful programs like exa and bat, but it also functions as a nice benchmarking and stress test tool. i can check my heatsinks and fans, and grab a smoke and a coffee, while cargo compiles an app that concatenates a file with syntax rendering
- bigstrat2003 11mo ago> Its compilation is slow. I mean SLOW. Slower than C++. I know over years Rust became several times faster, but objectively we need it to be two orders of magnitude faster, not just two times. This is not objective. You're entitled to your opinion, but I at least am fine with compile times the way they are. For it to be objective, it would have to be something that is true independent of your or my opinion, but ultimately this is a subjective matter. > Memory safety is not that sacred. In fact, for many applications malfunctioning is better than crashing — particulary in the embedded world where Rust wants to be present. You cannot get 99.999% reliability with Rust — it crashes all the time. This is a completely baseless assertion; Rust does not "crash all the time". If a programmer chooses to crash rather than keep going when the program is in an unforseen state, that is his choice, not something the language requires. Presumably that programmer feels that crashing is beneficial (because it helps to make bugs obvious sooner), but you aren't required to do the same.
- weedhopper 11mo agoI don’t think i’ll ever understand the compile time argument https://xkcd.com/303/ https://xkcd.com/303/ One thing that this blog doesn’t address though, is the cult-like following of Rust. It’s like the “AI” of oss — a main selling point by itself despite not being a feature. Seemingly, there is an assumption that software written in Rust is inherently better than any other, or that if something is written in Rust, it cannot have any errors. Sure, new software should be written in it instead of C. But why fix programs that are already memory safe?
- whytevuhuni 11mo ago> Seemingly, there is an assumption that software written in Rust is inherently better Yes. Both Rust and its standard library have features that make programs be less likely to have problems. > than any other No. It's just better than the languages that are very popular right now. > or that if something is written in Rust, it cannot have any errors. No. How people keep jumping from "better" to "absolutely 100% infallible" is beyond me. Nobody is claiming this. > But why fix programs that are already memory safe? Because: 1. Programs that are already memory safe still need to be improved, and those improvements are really dangerous in a dangerous language 2. Things like https://news.ycombinator.com/item?id=46013579 https://news.ycombinator.com/item?id=46013579
- csomar 11mo agoI am biased, so keep that in mind. > Its compilation is slow. I agree on this. But you can get better hardware, split a large code base into several crates, optimize for fast compilation when developing. On the other hand, I feel the guarantees of Rust compilation are discounted. If your code is more correct before deployment, wouldn't that save you debugging time later? My biggest issue is with macros. I like them (and LLMs are good at writing macros) but they make both compilation and LSP ridiculously slow. > It’s complex. No, it is not. There is a learning curve. But after a while, you just alias your "Arc<Mutex<Box<T>>>" and name it something you understand (mypipedtype) and then just fly over the abstractions. There is sunk time to build/architecture your complex type but I see that as investment that can save you time later. > In fact, for many applications malfunctioning is better than crashing What does malfunctioning mean? Leaking your secrets? Compromising your system? Corrupting your data/state? I'd take crashing any time of the day. > When handling lots of mutable shared state (GUI, DB, stateful services, OS/hardware) This is a problem until the whole stack becomes Rust. If you are using lots of extern/FFIs in your code, I really sympathize with your position and you are kind of in a worst of both worlds situation.
- anarki8 11mo ago> We actually had a recent Cloudflare outage caused by a crash on unwrap() function > Memory safety is not that sacred. In fact, for many applications malfunctioning is better than crashing — particulary in the embedded world where Rust wants to be present. You cannot get 99.999% reliability with Rust — it crashes all the time. Would you prefer silent UB/memory corruption in Cloudflare case? I don't think most developers would agree with this.
- deng 11mo ago> In fact, for many applications malfunctioning is better than crashing — particulary in the embedded world where Rust wants to be present. Not a fact. Particularly in the embedded world, crashing is preferable to malfunctioning, as many embedded devices control things that might hurt people, directly or indirectly. > If a pacemaker stops — telling a victim “but the memory was not corrupted in the crash” is a weak consolation. If a pacemaker suddenly starts firing at 200Hz, telling a victim "but at least it didn't crash" is a weak consolation. A stopping pacemaker is almost always preferable to a malfunctioning one, as most people with pacemakers still have sufficient natural rhythm to survive this for long enough to get help. > We actually had a recent Cloudflare outage caused by a crash on unwrap() function Please read the whole article. If the unwrap hadn't caused an exit, the process would've run out of memory, leading to a much less deterministic behavior which is much harder to diagnose and fix. I always prefer an early exit with a clear error instead of getting killed by the OOM reaper.
- jmaker 11mo agoYeah, the blog post is a very confused write-up. I saw lots of similar posts on LinkedIn recently, with quite a lot of likes and echo chamber comments. It’s just hilarious how a narrative emerges that reinforces biases due to ignorance. There must be a name for that sort of fallacy. I love to write in Rust precisely because I can express failures more explicitly, it’s the transparency that wins here. I’d frame the issue Cloudflare had rather in the PR review and QA corner, maybe as some AI complacency. But it’s not a problem with Rust.
- dev_l1x_be 11mo agoI love the ub Go forces you to have explicit error handling ones the most.
- ameixaseca 11mo ago> There must be a name for that sort of fallacy. Motivated reasoning
- tialaramex 11mo agoAlso stopping is a state which definitely might happen anyway and must be planned for. The pacemaker's wires can be dislodged or damaged, power sources fail, these things will stop the pacemaker regardless of how much you love the "just keep going" approach to software engineering. Which means medics have already thought about what they're going to do when this happens to a patient, and "The software failed" just goes on the same list as "10 year battery only last 8 years" in terms of undesirable but hardly impossible scenarios which constitute a medical emergency.
- devnull3 11mo agoThere is a fundamental trade off between (1) Memory Safety (2) Zero cost abstraction/Performance (3) Ease of use Rust attempts to solve this trifecta and that is where the complexity arises. If the problem at hand does not need async, then Rust has done commendable progress in dealing with the above trade-offs. Async is in Rust can be hard because the problem it is trying to solve is hard. All the above may be fine but when it comes to choosing the language in practice we need to think of trade-offs and guarantees that are suitable for problem at hand. There is a reason why C++ reigns supreme in HFT and Gaming as memory safety is not super critical. Disclaimer: I like Rust.
- anarki8 11mo ago> Its compilation is slow. I mean SLOW. Slower than C++. I know over years Rust became several times faster, but objectively we need it to be two orders of magnitude faster, not just two times. I am more concerned about correctness and "zero-cost abstraction" of the end result, if sacrificing few seconds of compilation time is necessary for that - fine by me. > It’s complex. Just as complex as C++. But C++ had legacy and Rust had not. The complexity of forcing your way through the jungle of Arc<Mutex<Box<T>>> on every single step directly impacts the quality of the logic being implemented i.e. you can’t see the forest for the trees. Once again, C++ has the same problem, so what’s the point of the language switch in the end? So, you seem to prefer data races and dangling pointers, or? Have you tried "actors-like" channels+rayon approach if you hate mutex so much? > Memory safety is not that sacred. In fact, for many applications malfunctioning is better than crashing — particulary in the embedded world where Rust wants to be present. You cannot get 99.999% reliability with Rust — it crashes all the time. You again prefer UB and/or corrupted state (and call that "reliability") over required explicit checks of Result via matching. This is definition of bad code to me. > When handling lots of mutable shared state (GUI, DB, stateful services, OS/hardware), the performance of native Rust memory model is subpar Few boundary checks sometimes add negligible overhead, but again you need those in any language to enforce correctness, Rust just adds those automatically.
- jimjag 11mo agoI think people are missing the main point. The real issue with Rust is that it is a designed language which is really tuned and optimized for a specific use case. And for that specific usage, it is really, really good. But even so, it requires a lot more up-front work, due to the limitations and restrictions it imposes. But it is NOT a good general purpose language. And, maybe to be putting words into the author's mouth, that is their main beef. That every seems to be pushing "Rust All Things" even when it makes no sense, and even if there are much better alternatives available. So for such comments as "so what about compile time", the issue is that for some, compile time _is a concern_. If it isn't for you, great. But you just can't discount what are valid concerns for others. People seem to forget that languages are _tools_, and as such, have different sweet-spot use-cases.
- marshallr 11mo ago> Rust is memory safe and unreliable. The price of memory safety was reliability Uptime isn't reliability; it's producing predictable behavior. Allowing indeterminate ("malfunctioning") behavior is the opposite of reliability.
- Voultapher 11mo agoWhat a waste of time article. There is plenty of debunking of the points already so I won't repeat them. Yes C++ has many many issues, and yet most of the biggest most complex software systems in existence are written in it. I don't see the browsers, OSs, DAWs, AAA games etc. being implemented in Go. Rust is a real improvement for these areas, with a proven track record of making software more reliable and maintainable. If the author intended to say "Rust is not the best programming language for every problem" they should have said that but it would have been worth an article as much as "Screwdrivers are not the best hammers".
- wseqyrku 11mo agoThe post describes very clearly why you should choose Go if this is where you're at.
- deleted 11mo ago[deleted]