I 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.
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, just because you can pick it from the shelf and employ as-is. This blog was generated with Zola, written in Rust — I did not have to write a single line of Rust code to use it. And the Rust is a good fit for Zola SSG because of its non-interactive nature with one-way flow of immutable data. Just, please, don’t run around screaming “we should all switch our development to Rust because it’s the best programming language”.”
Is this what makes someone a Rust hater?
Lol. Its not facts. Its a description of frustrating things you've experienced working with rust, dressed up as "deep truths about the language". You don't speak for the rust community. This article would be much more interesting if you just talked about your own experience without pretending your issues are universal.
Re: compilation time, in the 2024 state of rust survey 25% of rust developers said slow builds was a big problem. And thats a lot of people! But 19% of people said its not a problem at all for them. Its certainly not "everyone".
https://blog.rust-lang.org/2025/02/13/2024-State-Of-Rust-Sur...
I suspect if you keep using rust, the things that annoy you about the language will change a lot over time. Some things will stop bothering you, and some things will start bothering you a lot more! (Like IMO Rc/Box/etc isn't a big deal. Once you learn to structure your code in a rusty way, you almost never need that stuff.)
I really like rust now. But I found learning rust to be incredibly painful. I get why you're struggling with it. But please don't confuse your struggle for universal truths about rust. You're only one person.
I disagree. There's a long road till that inflection point for me.
We need more of the security. We probably don't need the Rust though.
Uhm, I would have picked Rust just for shipping fast, iterating fast, better performance and compatibility. The security is a bonus that comes along for the ride. You probably haven't had the displeasure to work with C++ in combination with ROS. That experience really soured me on C++.
There was that article from the android team about how rust improved their development workflow[1]. Is that what you're talking about? Was that article emotionally upsetting? Do you wish it wasn't written? What in particular is upsetting? Do you want people to stop writing technical articles to protect your feelings?
Tl;DR Rust doesn't support any form of cyclic datastructure without indirection or unsafe. The indirection tooling is weak, and most real examples simply switch to unsafe rust. Unsafe rust is completely fine if you know what you are doing with memory, and is ok to use in these situations.
There are a few other gotchas that we just need to be clear about, some of these gotchas are limiting for developing higher level software and some are not e.g. String handling. If you are comfortable with unsafe, the rust toolchain is vastly superior to C/C++ development making it as close to an ideal replacement as we are likely to get.
In my opinion, unsafe rust code is worse to use than C because rust is missing the arrow operator. And rust still requires strict aliasing to be followed even in unsafe code. This makes complex unsafe code very hard to implement correctly. Like, it’s easy for something to look right and work correctly but for MIR to still find subtle issues.
Eventually I rewrote my btree on top of Vecs. My node & leaf pointers are now array indices. The result? There is no longer any unsafe code. The code has become significantly simpler and it now runs ~10% faster than it did before, which is shocking to me. I guess bounds checks are cheaper than memory fragmentation on modern computers.
I have so many thoughts having done that. First, I think this is actually the right way to write rust. Yes, manually keeping track of which array slots are in use is inconvenient. But unsafe & pointers are also quite inconvenient in rust. Programming like this makes use after free bugs possible to write. But it’s still memory safe by rust’s definition. It’s impossible to get arbitrary heap corruption because there are no raw pointers. And the indexes are bounds checked.
I also don’t think the resulting code is any worse than the equivalent C++. Everyone talks about memory safety but IMO rust’s best features are enums, traits, cargo, match expressions and so on. Even when you do a run around the borrow checker, it’s these features which make me keep coming back to rust.
I agree better guidance would be nice, but so many words have been spilled on rust already. Would you find content talking about subtle stuff like this? Sometimes the only way to learn is by trying stuff out.
Optimizations are very complex and potentially fragile in Rust, LLVM has to sort through tons of generated IR, so it might be just that native Rust structures are optimized better for compilation. Particulary, Rust is able to optimize out some bound checks.
Do note that binary trees are mostly an obsolete legacy today — they are way too cache-unfriendly. I mean you could have written similar code in C++ using std::vector or std::dequeue and get the bounds checking too.
>Everyone talks about memory safety but IMO rust’s best features are enums, traits, cargo, match expressions and so on
C++20 with concepts mostly reproduce the traits. C++17 with std::variants emulate enum/tagged union. Match is unmatched by C++, that's true.
Cargo is good for as long as there are few packages in there. Large projects already suffer from five versions of serde in one build and dependencies on FFI-connected libs that cargo itself cannot build. I mean look at the NPM nightmare — and they've mostly dodged FFI-s.
BTree is not Binary Tree. It's B-Tree and is cache-friendly
> C++20 with concepts mostly reproduce the traits.
C++20 concepts are not the same as traits. Concepts are structural and awkward to use compared to Traits which are nominal. There are other important differences, too.
As a sibling comment said, its a b-tree not a binary tree. B-trees are - as far as I know - the fastest data structure on modern computers for the class of problems they solve.
And yes, I think if I ever go back to C/C++ I'll try this approach out. It might also work great in GC languages like JS/TS/C#/Go because there's fewer pointers to keep track of.
> Cargo is good for as long as there are few packages in there. Large projects already suffer from five versions of serde in one build and dependencies on FFI-connected libs that cargo itself cannot build. I mean look at the NPM nightmare — and they've mostly dodged FFI-s.
I haven't run into the "five versions of serde" problem, but I can easily imagine it. I've lived NPM nightmares more times than I can count. But I'd still prefer that to all the problems you get from CMake, autotools and Makefiles. At this rate we're going to get self driving cars before we have a single sane build system for C.
This is simply not true, it's an ongoing thorn of mine that the Rust community seems to decide that anything which cannot be programmed in rust is obsolete legacy. This is a silly stance which is harming adoption.
I for one have coded dozens or even hundreds of tree structures. My most recent tree was a hierarchical context management system for an LLM agent!
Nobody is arguing that you can't program a binary tree or b-tree in rust.
I think its true that binary trees almost always perform worse than b-trees in programming in general. But that isn't a comment about rust. Its a comment about modern CPU memory & cache behavior.
It doesn’t optimise out the bounds checks. I checked the assembly.
Bounds checks in rust always look so ugly if you look at the assembly output because there’s all this panic string building and whatnot. But in practice, I think it’s just that modern CPUs have excellent branch prediction. A branch that follows the same path 100% of the time is cheap. Especially when it has UNLIKELY() annotation hints in the code. This is the case for bounds checks. They just don’t really show up in benchmarks as much you’d think.
Somehow there are always fresh people who think someone cares or that somehow those are important discussions.
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?
What's the git product that only carries the name?
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.