Hacker News Reader

Comment by cmrdporcupine | Hacker News Reader

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.

View on HN

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.

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

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

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.

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.

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.

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.

> 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?

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.

Reply on news.ycombinator.com