[Zagitta]

"Programming in Rust is like being in an emotionally abusive relationship. Rust screams at you all day, every day, often about things that you would have considered perfectly normal in another life. Eventually, you get used to the tantrums. They become routine. You learn to walk the tightrope to avoid triggering the compiler’s temper. And just like in real life, those behavior changes stick with you forever."

This is a pretty negative and unfortunate take on rust that I cannot recognize after having spent the past 2 years professionally writing backend rust. I did write c++ before that so it's likely that it takes some experience with the pain of an unhelpful (and in some cases downright hostile) to fully understand and appreciate the so called "yelling" rust does.

From my perspective every lifetime complaint the compiler has is a deeply appreciated hint that not only saves you countless hours of debugging down the line but also makes me feel confident/safe in the code which you never could achieve in a c++ codebase without making defensive copies everywhere.

Being able to lend/borrow data without fear truely is rust's greatest strength and something people coming from GC languages have a hard time appreciating.

[Analemma_]

It's a bit of an oversimplification, but a little quip I've used when talking about developing in Rust vs. other languages is, it's a question of where/when do you want the pain. In Rust, it's at development time (and hiring and ramp-up time); in C++ it's at runtime; and with GC languages it's at billing time when you have to pay for that extra compute and RAM. There's no way to get rid of the pain entirely.

[willsmith72]

if it were that simple, I'd take the "billing time" payment every time. Engineers' time is the greatest cost for just about any tech business

[scrollaway]

Sometimes billing time is your customer's patience, their phone battery, or other things like that which make your product worse and give your competitors an edge.

[fbdab103]

>...which make your product worse and give your competitors an edge

I would find that argument passable if some of the biggest products from the largest companies functioned better. Performant software seems like a distant memory.

[_aavaa_]

And yet the big tech companies are perpetually re-writing their whole stack, or going out of their way to create new compilers for their language in order to lower their billing time.

[maxbond]

Salaries are dominant in early stage startups, and infrastructure costs becomes dominant as you scale (also probably a SaaS-centric oversimplification). You can get into trouble in the middle, where you have enough scale to be paying jaw dropping cloud bills, but you don't have the staff to move to a cheaper architecture and you may still need to focus on getting new features out to drive growth (or to attract investment).

In startups that chasm is generally filled with VC money paid to cloud vendors, but if you're bootstrapping or not looking to be a unicorn, you probably will want to drive down infrastructure costs much earlier.

[_aavaa_]

I tend to agree with you, but your aside about it being Saas-centric is really important.

One need only open Microsoft Teams to see the “billing time” costs. If the billing time cost is not paid by the developers or their company, then it stop being a cost to them and it becomes an unpriced externality. Who cares, who even knows, that this app we’re writing runs slowly on regular people’s old hardware.

[erik_seaberg]

Rewrites in big tech are a symptom of too many people each trying to demonstrate impact that checks the boxes of an elaborate promotion process.

[riku_iki]

its depends on your app, if you run infra on 100k servers then win can be much larger than cost of engineer.

Or if you write mobile app and became slow and laggy, then you lose users.

[ModernMech]

Yes but there’s a difference in who feels the pain. Compile time pain is felt by devs, who have the constitution and ability to fix such issues. Runtime pain is felt by users and can result in data loss and security issues in the wild, and is harder to debug.

One kind of pain has a bigger blast radius than the other. I prefer compile time pain to runtime pain.

[Xeamek]

>From my perspective every lifetime complaint the compiler has is a deeply appreciated hint that not only saves you countless hours of debugging down the line but also makes me feel confident/safe in the code

Meh, the fact that Rust's compiler is overly strict is just a truth (All compiling programs are valid, but not all valid programs are compiling), and I find it lowkey annoying that every time someone has a problem with it, rustceans jump to the defense to the point of almost denying the OPs experience. I mean on a case by case basis it might simply be a difference of experiences and both are valid, but on a larger scale it does look like a bit of a pattern, at least to me.

Ofcourse, there restrictions aren't just a whim of a Rust core team (usually ;p ), and do come from practical limitations but regardless, it's fair to be frustrated at them.

[ModernMech]

Indeed, I’ve been writing rust professionally since 2015 (yes before 1.0) and I would consider the first encounter with the compiler as maybe it yelling at me, because I was used to C++. But it actually taught me a lot about why the code I was writing may have seemed okay at first glance, but actually introduced a tricky corner case bug that I hadn’t considered. The borrow checker got it tho, and I had to rearchitect my code to avoid that edge case. Now the code is better, free of that bug, and I won’t make that mistake in the future.

Was that the result of a process in which the compiler “abused” me? I don’t think so.

[juliangmp]

Its wild how different the perspective is depending on your background

The author also wrote >[Rust's] dev tooling leaves much to be desired

I can't even begin to comprehend such a statement. Rust's tooling ecosystem is the number one reason why I want to convince my colleagues to give it a shot. Its literal heaven coming from C++ with cmake...

[hun3]

Yeah, blaiming the compiler for pointing out potential runtime bugs is just shooting the messenger.

[jamincan]

In general, the error messages are also nice and offer suggestions on how to fix the problem. Far from being yelled at, it's more akin to pair programming. "Try doing this..." "Did you mean to do this?"

[oivey]

Did you mean non-GC languages? GC languages by default have at least memory safety because the GC frees for you when an object is detected to no longer be accessible.