2 ms·

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

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.

mikece 3y 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.
- cmrdporcupine 3y 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.
  - goku12 3y ago
    > 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?
    - cmrdporcupine 3y ago
      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.
mcronce 3y ago
This is predicted on the assumption that the only benefit of Rust over mainstream GC languages is performance, which is false.
- cmrdporcupine 3y 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 3y 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.
- jackmott42 3y 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.
  - cmrdporcupine 3y ago
    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...
  - mcronce 3y ago
    * 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.
MrBuddyCasino 3y 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 3y 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_crank 3y 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.
- cmrdporcupine 3y 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.

mikece 3y 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.

cmrdporcupine 3y 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.
- goku12 3y ago
  > 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?
  - cmrdporcupine 3y ago
    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.

mcronce 3y ago

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

cmrdporcupine 3y 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 3y 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.
jackmott42 3y 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.
- cmrdporcupine 3y ago
  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...
- mcronce 3y ago
  * 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.

MrBuddyCasino 3y 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 3y 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_crank 3y 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.
cmrdporcupine 3y 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.