Rust Absolutely Positively Sucks [video]

https://www.youtube.com/watch?v=BB-H5ivmdwQ

by mikece • 3 years ago

30 77 3 years ago

youtube.com

bena• 3 years ago

Here's the post that the video is about

https://www.reddit.com/r/rust/comments/12b7p2p/the_rust_prog...

msh• 3 years ago

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.

mikece4• 3 years ago

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.

gizmo• 3 years ago

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.

titzer2• 3 years ago

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.

cmrdporcupine12• 3 years ago

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".

mike_hearn3• 3 years ago

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).

Verdex3• 3 years ago

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.]

c_crank5• 3 years ago

Bug free code only exists when it can be formally verified.

linusg789• 3 years ago

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.

mikece4• 3 years ago

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.

pclmulqdq3• 3 years ago

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.

fnordpiglet3• 3 years ago

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.

junon3• 3 years ago

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.

c_crank5• 3 years ago

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.

UncleMeat2• 3 years ago

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.

FrustratedMonky2• 3 years ago

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.

bachmeier• 3 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).

junon3• 3 years ago

You missed the point of my comment, then.

nvm0n1• 3 years ago

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).

junon3• 3 years ago

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.

jackmott424• 3 years ago

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!

goku124• 3 years ago

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.

jackmott424• 3 years ago

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?

cmrdporcupine12• 3 years ago

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.

mikece4• 3 years ago

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.

cmrdporcupine12• 3 years ago

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.

mcronce2• 3 years ago

This is predicted on the assumption that the only benefit of Rust over mainstream GC languages is performance, which is false.

cmrdporcupine12• 3 years ago

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.

yberreby• 3 years ago

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.

jackmott424• 3 years ago

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.

MrBuddyCasino• 3 years ago

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.

glimshe• 3 years ago

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.

c_crank5• 3 years ago

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.

cmrdporcupine12• 3 years ago

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.

FrustratedMonky2• 3 years ago

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)

fnordpiglet3• 3 years ago

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.

Sharlin• 3 years ago

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.

raspyberr• 3 years ago

This is a 20 minute video about someone reading out a reddit thread whilst streaming? Why?

UncleMeat2• 3 years ago

Content for the content gods.

coding123• 3 years ago

Some people feel like they are more important than others, so they make a video of their reactions to reddit since it is indeed more authentic than everyone else. /S

afiori• 3 years ago

Actual truth is that reaction content is incredibly cheap to make.

mikece4• 3 years ago

Because I can listen to that in the background while doing other things.

horsawlarway• 3 years ago

I had to turn it off just based on how badly the person was stumbling in reading the damn thing.

015a• 3 years ago

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.

delaaxe• 3 years ago

What's wrong with commentary?

jamil7• 3 years ago

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.

nymalt• 3 years ago

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.

cmrdporcupine12• 3 years ago

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.

duped• 3 years ago

Ownership is part of the type system.

mike_hearn3• 3 years ago

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.

telotortium• 3 years ago

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.

Rust Absolutely Positively Sucks [video]

Related Stories