Rust Absolutely Positively Sucks [video]
youtube.com
youtube.com
He adds context, as a professional dev. He is entertaining, even if the original content isn't. And even if it is: the average human being today doesn't read anymore.
Switching to rust made iteration times on my OS significantly smaller, the code much easier to maintain, and the tooling almost completely standard Rust tooling instead of a jury rigged amalgamation of Unix tools etc.
To each their own.
But, all that said. Rust Good. I work in Rust. I like Rust. I just don't believe in one size fits all, and I want to see companies apply balanced processes in technology or framework adoption.
> Great, more pointless language warring.
Then:
> Switching to rust made iteration times on my OS significantly smaller, the code much easier to maintain, and the tooling almost completely standard Rust tooling instead of a jury rigged amalgamation of Unix tools etc.
That's language warring. Of all languages, Rust is the last that should complain about language warring (there's an entire "rewrite it in Rust" culture).
My own Ax. I love Rust, but wish it had used white spaces instead of curly braces.
This kind of gripe seems valid about the language. Rust is fantastic if you can be very Rusty, but it's also a language with a lot of opinions about how you ought to write code.
Being permissive on this front is a language design choice, and while it is in vogue to make your language extremely opinionated to the point where you can't write non-idiomatic code that compiles, it does limit your language's applicable scope. This is such a problem that Google is currently working on their private "Carbon" language instead of switching to Rust (outside of a few areas).
The OP isn't learning Rust the way you or I learned Rust. He is learning it in the context of someone who (1) doesn't want to, and (2) is doing it within a huge legacy codebase. That is a fundamentally different experience than someone who is excited about it and gets to start with a blank slate.
Yeah I get they’re not interested in learning Rust - but again that’s not rusts fault or a flaw, or in any way supportive of less opinionated languages. It’s a rookie mistake. When you’ve only learned one or two languages learning a new one is a chore and disheartening and it’s always someone else’s fault you feel like a loser. As you mature as an engineer first it gets easier and more rewarding to learn new ways of doing things, but you also realize that feeling of being a loser is just the brain resisting and the feeling of learning.
Sure, allowing people to do whatever they want means that code written without discipline will just be a jumbled mess, but that will be true in idiomatic code too.
Also, a mature language and the associated community has to be able to deal with non-hobbyists learning and using it.
Or that there is any language that has no warts at all, and so any problems are automatically "holding it wrong"?
1. Rust is supposed to be harder than Java, you get runtime performance for your efforts. If you don't need that performance, by all means do not use Rust!
2. Rust is not as mature of an ecosystem as Java yet, and so there are going to be pain points compared to stuff that has been around forever.
3. Rust is also new to the poster, while using a new language is fun on toy projects, having to use a new language in production is always frustrating, even when you aren't moving to one that is fundamentally harder
So, yeah I like Rust, but don't really disagree with their views here. Hopefully work is choosing to use Rust for a reason!
I have to disagree with this. It's easy to use Rust as a general purpose programming language once you are familiar with its type system. Getting there of course, is a different matter. There is a point beyond which the strict rules of the language stops feeling like a burden and starts feeling like a guide.
> So even though I like Rust, I don't really disagree with their feelings.
I can sympathize with the beginners. Navigating the Rust type system as a beginner takes a lot of patience and contemplation. Doing it under deadlines imposed by management is completely counterproductive. If I were a manager, I would either hire someone who knows it already, or invest in their training.
That said, it's a very toxic behavior to take out that frustration on a community that created and loves the language. Express the frustration and seek help? That's fine. But calling them liars and cursing their project a swift death? I don't see how that's agreeable. This really isn't about Rust - it's about not being completely inconsiderate with strangers on the internet. People need a detox from the pressures of corporate life.
2. Some people look at those rants as toxic, and I understand that, but there is also value in expressing and seeing people's true feelings. Rust does this to people! Can we fix it?
You are conflating difficulty in learning with difficulty to use. Not the same. Rust borrow checker complains for a reason. Once you understand what that reason is (i.e after learning the hard part), Rust becomes just another tool assisting you in writing memory-safe programs.
> Some people look at those rants as toxic, and I understand that, but there is also value in expressing and seeing people's true feelings.
Would it be so hard to express the problems without personally attacking everyone else out there? You can expect to be socially isolated if you do this in the real world. Despite that, people behave as if it is acceptable if it's online.
https://www.reddit.com/r/rust/comments/12b7p2p/the_rust_prog...
Stepping back from the emotional overreaction in the OP, this seems to be the relevant bit:
> Right off the bat, as a total Rust newbie, I'm hitting all kinds of rough edges in Rust. For example, I'm trying to use rusqlite. It would be natural to stash DB prepared statements in a thread local for reuse in my multi-threaded code. I can't pass the connections around, because I need them in a C call-back (too much detail here I know) so I have to be able to look them up. Alas, after banging my head against the wall for a full day, I'm just giving up on the thread-local approach, because I simply can't get it to work. Part of the problem is that I can't stash a prepared statement in the same (thread local) struct as the connection from which they are created, due to lifetime limitations. It also seems that you can't really use two thread locals (one for the connection and one for the prepared statements) either. If there's a way to do it, I can't figure it out.
What I take from this is that the library was designed to work with lifetimes a specific way, and the OP is trying to use them in a way not intended. Rust lifetimes being baked into the language means there is really no way around the design the library authors had in mind. If the library authors made bad choices, you are basically stuck.
This is the crux of the matter. A poorly designed library in Rust comes with a straightjacket that you must wear. I've had students hit this kind of things several times. This kind of experience absolutely kills the flow and sucks all the joy out of programming. Poorly-designed lifetimes are non-composable and lead programmers down completely unnecessary, totally unproductive rabbit holes.
Making memory management orthogonal APIs is the only way to make them composable.
The first will lower performance perhaps by a lot, but performance is probably why you're writing Rust in the first place. The second is a nasty hack that will require you to remember this cache exists and keep its size carefully tuned.
As all he wants to do is stash prepared statements in TLS, a pretty normal task, it seems like a valid complaint that this is so hard and rustql doesn't seem to allow it.
One aspect of Rust I wonder about it is that when reading it I see way more cloning than you'd intuitively expect. Seems like people hit the borrow checker, can't see a way out and just copy the memory to escape. Presumably that will lead to diffuse performance losses all over the app of the sort that can't easily be spotted in a profiler, sort of like pointer chasing in languages without value types.
I wonder if C++ will actually end up having an edge in performance due to this. I know there are very heavily tuned benchmarks that show Rust being the fastest but I mean for "real" code of the sort this person is needing to write (done under time pressure).
Maybe this is an inevitable dynamic between compilers, library writers, and application writers? Seems to have played out in many languages.
So you started learning rust by trying to make something multithreaded that also interops with C instead of starting with something simpler so you can learn to understand the borrow checker? That's a recipe for disaster.
>am truly convinced that all the people who claim Rust is great are either lying to themselves or others
A Rust novice telling every Rust developer in the world being wrong? There must be some irrefutable wisdom in there somewhere!
Rust is more like Go than C. Both Rust and Go can be used to write high performance services. Both Rust and Go have many modern convenience features. And both languages expect you to write code in a specific idiomatic way, wrt borrow checking and go channels respectively.
If you need shared memory and fine-grained locking for performance you're not going to have a good time. And that makes Go and Rust unsuitable for a large chunk of applications.
The idea being to provide safety-minded well crafted but performant libraries where the hard thinking about atomics & locking and unsafe-bounded memory shenanigans are confined in well-tested locales.
Also don't see why you're comparing with Go. Entirely different bowl of soup. Go is not a systems programming language.
After decades of trying to get C-style systems programming right, we're still finding unsafe memory related security issues (ignoring implicit integer casts and UB).
Thesis: Maybe c-style systems programming is bad.
Rust consumes what we learned from cyclone et al as well as leveraging llvm and while I think we had reason to be cautiously optimistic for a while there, now it honestly seems to be working. But it works because we abandoned what we thought were the bad parts of c-style systems programming.
Meanwhile, someone tries to shove c-style programming back into rust and finds it's not actually possible. Then complains. Technically, this is fine.
The part that isn't fine is to loudly proclaim that everyone who is able to learn how to use rust correctly must be lairs.
[As an aside, there's D, P, jai, rust, odin, zig, carbon, vale, swift, c++11+, and more. A good rule of thumb is that a programming language takes about a decade to really get moving. There's a reason that an absurd amount of time has been dumped into replacing c-style systems programming.]
... okay. Although, on the other hand:
| Beware of bugs in the above code; I have only proved it correct, not tried it - Knuth
Perhaps bug free code does not exist?
My point was that a lot of people have put a lot of time into not using c. Maybe they have a reason for doing this.
The reddit post is upset at having to use rust. Which is fine. It's not fine to also include a claim that everyone who uses rust lies. This is implicitly trying to keep everyone in c. Or the author trying to do the very thing that they are complaining about being done to them. Not great.
SystemJava is a very odd animal. It's a Java superset that is sort of hidden away inside the Graal project and not really advertised. SystemJava is Java for systems programming, proven out by its use to write a full JVM (with garbage collector etc, all in Java).
SystemJava is syntactically identical to Java, so all existing tools and IDEs can work with it. However the semantics are quite different:
1. It's always compiled ahead of time to a standard platform native binary (exe or lib).
2. You can do both GCd and manual memory allocation, pointer arithmetic, stack allocation, calling in and out of C without JNI and so on.
3. Some objects are "magic" and not compiled as objects at all like CWordPointer which lets you do raw ptr derefs.
Tutorial example file:
https://github.com/oracle/graal/blob/14d366284d137415f3defb2...
With this you can do things like make what appears to be a C library on the outside, but write it with Java on the inside. The parts of the runtime needed will be compiled into the binary. You can rely on the GC for anything that isn't performance sensitive, and use manual memory management for the rest. Or you can use the GraalEE version which has the G1 GC that is these days very fast and powerful, without needing much tuning.
SystemJava doesn't have anything like the Rust type system, so it won't catch data races or double frees (when working with manually managed memory). But it might have been a better tradeoff given the skills profile of this team.
I have a feeling that far too many people go do Rust while what they actually need is OCaml - it's fast, has a nice type system and you don't have to think about lifetimes.
F# or Scala seem like reasonable choices.
(but yes, it seems to be 'object' v 'functional' language war critiques again)
* Lambdas/closures: Java has had them since day one, albeit with horrible syntax. Nice syntax since Java 8, almost ten years ago (indeed predating Rust 1.0!). Some functional patterns are even easier in Java thanks to GC of captured variables.
* Lazy lists, combinator chaining: Rust has iterators (and with rayon, parallel iterators); Java has streams, parallelizable by design, since Java 8.
* Closed sum types: Rust has enums, Java 17 has sealed interfaces (semantically equivalent albeit much more verbose to define).
* Pattern matching: Rust has `match` (and `if let` et al.), Java has `switch` which although not nearly at Rust's level yet, has been gradually gaining extra matching powers (JEPs 440 and 441).
The real stumbling blocks for a Java developer are a lack of GC, the sharing XOR mutation paradigm, and lack of support for some common OOP patterns. Also a lack of reflection is a pretty big thing.
Just ... stop writing web services in it. Not writing a compiler, a browser, an operating system, a database, an interpreter, building fundamental datastructures, or a working on an embedded system etc? Go back to enjoying the conveniences of garbage collection and looser ownership models.
If you hit a wall with the GC and performance there, you can always rewrite portions native later.
OCaml, F#, or Haskell would offer many of the benefits that come with Rust's type system.
I've used OCaml professionally, and it's been a real pleasure.
Writing a low latency, high throughput ad server / RTB system from scratch? Sure, go Rust. Google uses C++ for this stuff still for a reason.
But in reality most of the services we're talking about are I/O bound low-thread-count data pipelines. And they'll be perfectly served by various managed languages.
Instead we get tokio-all-the-things...And Rust is a flavour of the month, and the JVM Isn't Cool, etc...
* Immutability by default, including a warning for unnecessary mutability
* Usable documentation even when the library author wrote none
* Extremely low-friction testing, including fuzzing
To name a few.
Racing to get an HTTP service that starts but doesn't do anything you want it to do correctly isn't really useful; in my experience, that's the only advantage e.g. Python, Go, etc really give you over Rust.
And honestly, TypeScript's union & intersection types are pretty nice and that language is nice and expressive.
Actually I actually routinely run up against expressiveness limits in Rust's enums in places where e.g. Scala would actually allow for a more static-declarative model (for better or for worse). I haven't worked in Scala in 15 years, but it was actually quite compelling.
It is such pain compared to Rust's enums. Wish there was more Rust front-end.
A technology that works equally well in all use cases is not optimized for any particular application (by definition) and thus will be outperformed by a technology that IS optimized for the target needs. While there is an argument to be made for the existence of stacks that are "good enough" for most/all problems, that shouldn't empower proponents of said stack to spit on everybody else's choices - many of which being objectively better for the task at hand.
It's in large part because the industry is top-heavy with younger people who get senior titles and decision making powers after only a handful of years of work, and they're by nature excitement and novelty seekers. I definitely went through that phase.
Do I want to work in cool tech? Yes. But there's always a trade-off.
FWIW Rust is my fulltime language. And actually I would probably use it for (some) web services, for personal things. But if I were managing and staffing a team, I would not do this simply because hiring and managing that would suck.
Could you elaborate on the disadvantages of Rust from the point of view of a manager or a project lead?
Established best practices -- this is still being sorted out in Rust in various domains.
Third party library support -- again, immature in some domains but not all.
Managing and tutoring junior devs -- a bit trickier here.
I think there is potential big win in using Rust. I want to see it propagate. I work in the language, and love it. But also a big fan of right tools in right places. For most web service ("full stack") type projects a GC managed language with a pile of existing code and a larger potential hiring pool just makes sense.