Rust Absolutely Positively Sucks [video](youtube.com)
youtube.com
Rust Absolutely Positively Sucks [video]
https://www.youtube.com/watch?v=BB-H5ivmdwQ
81 comments
Picking Rust up for work, I feel like I had the opposite experience due to how much the difficulty curve had been hyped by some members of the community. The compiler basically tells you what to do, if you don't understand the message, you google a little or find the relevant part of the Rust book online. I'll admit, I started a lot smaller than the author of that post.
This is a 20 minute video about someone reading out a reddit thread whilst streaming? Why?
Content for the content gods.
Because it has 150,000 views. Why does content exist? Because people watch it.
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.
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.
I had to turn it off just based on how badly the person was stumbling in reading the damn thing.
What's wrong with commentary?
Because I can listen to that in the background while doing other things.
Great, more pointless language warring.
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.
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.
Language warring isn't really pointless, because generating hype and buzz is what drives BIG-BUSINESS-CORPS into adopting new languages for their flavor of the decade.
Having been directly involved in language support discussions at one of the very largest BIG-BUSINESS-CORPS, I am pretty confident that "hype and buzz" is not the key contributor to decision making.
Yes, not sure what commenter is pointing at. It's not the large corps that drive this kind of froth, it's smaller shops or startups with smaller teams where decisions get more easily dominated by individuals with opinions.
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.
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.
While Java is the 'safe' pick now, remember that it was once a language being fad pushed by Sun and Smalltalk fans.
"I Was There, Gandalf, 3000 Years Ago"
You write:
> 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).
> 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).
You missed the point of my comment, then.
Apropos of nothing, it's "jerry rigged". Jury-rigged is a corruption which is why it doesn't make sense. The phrase originates in World War 1 when jerry was slang for a German (and might itself have been a corruption of the word German).
Thanks, I actually always thought it was Jerry, but I see jury way more often and just had it in my head that I must have been wrong. :D The internet giveth and taketh.
Competition is good, right? Debating the merits of each.
My own Ax. I love Rust, but wish it had used white spaces instead of curly braces.
My own Ax. I love Rust, but wish it had used white spaces instead of curly braces.
shrimp_emoji(1)
The situation described in the video can and probably does happen to C++ codebases as well, if not even more than Rust. It's easier to be good at Rust than it is to be at C++, even if C++ seems easier at first.
From the video it sounds like the largest problem is that the company/manager prescribed Rust as the solution to a problem where Rust might not have been the best fit. The dude wrote a Java version on his own time and despite being on a Java team at that job management insisted it be done in Rust. There might be issues with Rust and the scenario in question but it sounds like conditions at that work place are a bigger problem than the choice of a language.
The specific situation the poster is in is very Rusty. If you are used to doing things a certain way that the borrow checker doesn't like (no, that doesn't automatically mean that what you want to do is unsafe or incorrect) then you will have big problems writing Rust. In this case, Rust was forced on the original author by management and there was a pre-existing codebase that did things in a very non-Rusty way. On top of that, it appears to be a performance-sensitive application with the need for async. That's just a recipe for a uniquely Rusty form of pain.
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.
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.
Writing language code idiomatically is a bit of the deal with any language. Trying to break a languages fu to be more like a language you’re more familiar with is common when learning a new language, but blaming the language is a rookie mistake.
What kind of mistake is thinking all legitimate tasks are equally doable in all legitimate languages?
Or that there is any language that has no warts at all, and so any problems are automatically "holding it wrong"?
Or that there is any language that has no warts at all, and so any problems are automatically "holding it wrong"?
I think people say this about languages that are very opinionated (like Rust and Go) not realizing that many other languages are a lot more forgiving of a non-idiomatic style. There are lots of good reasons to use a non-idiomatic style, one of which is mentioned here: there is an existing codebase that doesn't fit the language's idioms. Compared to Rust, C++ and Java will let you compile and run code in a lot of different styles, and it will work (albeit without the guardrails).
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.
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.
Most languages have an idiomatic way of writing them, Java certainly does, Python, ruby, etc. C++ doesn’t simply because it’s a giant mess of hodge podge. Simply being able to compile something doesn’t mean you’re using the language idiomatically, and when you innovate your style off the idiomatic path sooner or later you’ll end up in a world of hurt with everyone you turn to for help telling you you did it wrong. You’ll have trouble finding collaborators, retaining talent, etc. Eventually you’ll rewrite as an idiomatic version. The fact languages have gotten tighter over time with their idiomatic style being verified up front is, IMO, a feature not a flaw. over the 40 or so years I’ve been programming I’ve come to appreciate more and more being able to learn the idiomatic way toll free when learning the language. I think rusts limitations are more to do with immaturity than opinionation - for instance lack of async closures, async traits, compile time reflection, generators, etc, are all point in time flaws that with time will make the language much easier to make expressive and flexible implantations.
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.
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.
Often in a professional context, a non-idiomatic layer written with a lot of discipline is an effective shim between nice clean code and something "dirty." Precluding people from writing that shim just makes things harder.
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.
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.
[deleted]
At the end of their reddit post they say "Rust feels like a MAJOR step back from Java." which I think sums up the issue:
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!
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!
> 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!
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.
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.
1. "easy to use once you figure out this hard thing" is another way of saying hard.
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?
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?
> "easy to use once you figure out this hard thing" is another way of saying hard.
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.
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.
I didn't see the OP personally attack "everyone else out there"
Here's the post that the video is about
https://www.reddit.com/r/rust/comments/12b7p2p/the_rust_prog...
https://www.reddit.com/r/rust/comments/12b7p2p/the_rust_prog...
Thanks for posting the link. The video is useless, it's just rage-baiting.
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.
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.
It seems almost worse - the author of rusqlite replies and says, essentially, that you just cannot do what he wants to do at all, and the "fix" is to either constantly re-prepare statements, or rely on some sort of library built-in cache!
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).
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).
Yeah, it seems like suffering little tiny copies all over the place is regressing back to the thinly-spread performance sludge that Rust's ownership is designed to police and therefore eliminate. If it becomes too widespread a problem, then compilers will be tempted to start intrinsifying and then eliminating copies in order to make them fast and go away, which unfortunately will always come with cliffs where the compiler misses an opportunity. So the game theory of that in the end is that programmers do less and less and compilers do more and more.
Maybe this is an inevitable dynamic between compilers, library writers, and application writers? Seems to have played out in many languages.
Maybe this is an inevitable dynamic between compilers, library writers, and application writers? Seems to have played out in many languages.
I actually ran into these precise problems with rusqlite and found them equally frustrating, and ended up ripping that code out in the end. The lifetimes model in that library are, IMHO, "wrong".
I dont know rust but the following comment from the reddit thread resonates with me:
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.
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.
The choice of language was forced on the dev. He did a Java version of the app -- ON HIS OWN TIME -- and management nixed it.
That doesn't excuse his choice of words.
>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!
>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!
Yeah - there's a huge psychological difference between adopting a language out of your own free will and it being forced upon you. I suspect that's where a lot of the current hyperbole about Rust comes from...
The issue here is that Rust presents itself as a systems language, i.e. a language where the programmer has control over how the system's resources get used. However, Rust has safety mechanisms that will stop you from doing what you want, even when what you want to do is safe and sensible. There is a contradiction here that Rust enthusiasts endlessly make excuses for.
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.
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.
There is unsafe{} if you want to do something not normally allowed. But, well, it's unsafe. I was surprised to learn of a memory management vulnerability in a Rust serialization library the other day (for capn'proto). It was using unsafe. You'd think that serialization is the sort of library where Rust's guarantees are most valuable.
This is simply false. Having written code like what you're talking about... There is always an escape-hatch. Rust just wants to make sure you really know what you're doing before letting you go there.
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.
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.
Rust is used for writing entire OS (e.g Redox) or parts of the OS that needs precise management of resources (e.g Linux kernel, Windows). It is used to write parts of web browsers (servo and quantum parts of firefox), game engines and in embedded systems. It's used everywhere that traditionally used C, C++ or Ada. There really isn't a justification to dismiss Rust as a systems programming language. The limitations that you claim are not there. The reasons are there in the other reply to you.
Thanks for the link. I saw the youtube video advertised to me by the algorithm, but wasn't about to waste my time watching it.
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.]
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.]
Bug free code only exists when it can be formally verified.
| Bug free code only exists when it can be formally verified.
... 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?
... 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?
The replacement languages for C in systems programming aren't memory safe. They can cause segfaults. They have additional tools and syntax rules to make it less likely, but they can and will have memory bugs.
A language that segfaults may still be memory-safe, if that's how it behaves every time the code is about to do something illegal with memory. You can still build a robust system on top of that, because you know for certain that you'll never read or write out of bounds.
Okay, great.
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.
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.
Hypothesis: maybe this guy would have been better off learning SystemJava instead of Rust? Given that he already knows Java.
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.
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 can't even find a single page describing System Java on https://graalvm.org, so they'd probably have even more difficulty with that than Rust.
There was a nice comment Prime made that it's not only about the ownership model, many people come to Rust for it's type system.
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.
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.
I agree, and OCaml (and the less popular but delightful StandardML) are lovely. But the problem there is the ecosystem just isn't there.
F# or Scala seem like reasonable choices.
F# or Scala seem like reasonable choices.
Ownership is part of the type system.
Anecdotally, if you are coming from Java, then changing your brain to think like Rust (functional) is a paradigm shift. (in true sense of word paradigm, a shift in perspective). Until the grok happens, yeah, it probably seems stupid and pointless.
(but yes, it seems to be 'object' v 'functional' language war critiques again)
(but yes, it seems to be 'object' v 'functional' language war critiques again)
Java is, in fact, roughly as functional as Rust is!
* 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.
* 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.
Rust is more imperative with a functional nature, and has no meaningful runtime reflection and fairly weak object nature making it a real shift for Java developers, but a more natural shift for C developers who are familiar with basic functional programming.
Honestly, half of this is just ... use Rust for what it's for: systems programming. Where the handcuffs and compromises it puts on you make sense.
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.
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.
This is predicted on the assumption that the only benefit of Rust over mainstream GC languages is performance, which is false.
There are plenty of advantages, which is why I work in Rust (but for systems dev); but for projects like that they are all outweighed by the much larger ecosystem of talent and tools and the ease of development that goes with other options.
GP didn't say to go for mainstream GC languages, though.
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.
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.
There isn't much else. Depending on the mainstream language in question you may have a little bit stricter typing, and while you get Data Race protection that is motivated by wanting to get performance from multi-threading with less risk.
Yep, and I would freely admit that if you really do have a heavily concurrent workload and you're going to be doing a lot of multithreading on high core count machines ... you could/should in fact reach for Rust.
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...
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...
* Sum types, and with them, exhaustive match checks
* 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.
* 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.
As others have pointed out, you can get these in F# or OCaml, or Scala as well. Or at least variants of them. And for F# and Scala you will have the advantage of an ecosystem of integrated libraries for .NET and the JVM respectively as well.
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.
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.
> And honestly, TypeScript's union & intersection types are pretty nice and that language is nice and expressive.
It is such pain compared to Rust's enums. Wish there was more Rust front-end.
It is such pain compared to Rust's enums. Wish there was more Rust front-end.
I've noticed a growing trend of "one solution fits all" in Software Engineering, where people exhibit near-religious attachment to a language, technology, architectural pattern (hello microservices!) or framework and believe that it solves every problem. This is the opposite of what Software Engineering should be about. An experienced engineer will pick the best approach for the particular use case.
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.
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 could be that. Or it could just be the noxious tribal-flavour-of-the-month thing that has been there ever since I got into this industry in the late 90s. I've seen several waves of it, and had plenty of people roll their eyes about suggested technology choices in ways that basically came down to but that isn't cool.
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.
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.
This attitude smells like unconscious job security to me. A world where everyone believes they should rewrite it in Rust is a world where Rust developers are in demand. A world where everyone has seen the light and accepted Haskell as their lord and savior is a world where Haskell devs can get paid to write all the CRUD apps of the world. And so on.
Pretty much this. I like C aesthetically, but once you had to debug memory corruption on an embedded MCU, writing Rust is a productivity upgrade. It certainly is a downgrade from Java or Golang, but thats because you're in the wrong domain - use the right tool for the right job.
The choice of language was forced on the dev. He did a Java version of the app -- ON HIS OWN TIME -- and management nixed it.
Yep, sounds like bad engineering management. My comment wasn't aimed at him but people like whoever his team lead is.
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.
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.
> 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?
Could you elaborate on the disadvantages of Rust from the point of view of a manager or a project lead?
Potential for staffing -- finding talent, and competent talent.
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.
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.