3 ms·

There's something to this. Rust was built to do low-level programming well, and as a result it's quite hard. It's fundamentally more work to do things than in a

by twic 5y ago

There's something to this. Rust was built to do low-level programming well, and as a result it's quite hard. It's fundamentally more work to do things than in a GC'd language of similar modernity. That's a perfectly reasonable tradeoff. But somehow, Rust got cool, and now a large fraction of its community wants to use it to write web services. So there's a lot of gravity dragging the ecosystem, and even the standard library and the language, in that direction. Even though it is a poor choice for almost all web services. One day, the shine will wear off, and it will be easy to see that it's a poor choice for almost all web services, and we will feel some regret over the amount of time and energy that went into building in that direction.

the__alchemist 5y ago
Agreed - I built a rust frontend framework, and tried to use it on the backend for a while. Ended up switching back to Python and Javascript for web - I use rust for embedded mostly now.
hu3 5y ago
Like Uber, some do manage to avoid the pitfall of trying to shoehorn hard languages everywhere. I recently learned their microservice fleet is almost entirely in Go [1]. Could also have been C#, Java, Python or Node but the point is it is not Rust or C++. Probably for the reasons you stated. [1] https://news.ycombinator.com/item?id=27120689 https://news.ycombinator.com/item?id=27120689
- littlestymaar 5y ago
  For companies like Uber, Rust would probably be a good fit if they started today: at this scale you spend more time optimizing some otherwise simple logic in order to scale up without wasting too much resources. Go has a decent optimization story, thanks to the escape analysis diagnostic which makes it quite straightforward to avoid many allocations (much more easily than in C# for instance, even if it's also doable in C# indeed), but Rust takes it step farther, and you'll have better performance to begin with, which will drastically reduce your scaling effort. For instance, look at what Cloudflare ended up doing to get Go working as they wanted: https://blog.cloudflare.com/go-dont-collect-my-garbage/ https://blog.cloudflare.com/go-dont-collect-my-garbage/ Rust will never be a competitor to Python or PHP (but it can enhance them, because making a native extension in Rust in way easier than in C, especially for people with a web back-end background and little C experience), but Go is losing a lot of appeal now that Rust is here ready for prime time.
  - johnnycerberus 5y ago
    You have some unsubstantiated claims. Firstly, Go focuses on infrastructure, it is actually the bootloader of cloud-native wave. Rust is great but still, it can be replaced by C, C++ or Zig when it becomes stable. It doesn't have its own ecosystem nor there's any ROI coming out from there to say that it will replace Go tomorrow. On the other hand, when it comes to modern DevOps, Go became as irreplaceable as Python and Bash. Using Rust won't translate into better performance without effort. Because of its focus on soundness, I would say that you need to put in even more effort.
    - littlestymaar 5y ago
      > On the other hand, when it comes to modern DevOps, Go became as irreplaceable as Python and Bash Most devops don't use Go and I argue that for the ones who do, Rust is a big improvement. Sure Go is being used to make Docker and k8s, but with this reasoning Haskell is also irreplaceable since Pandoc is made with it… Ironically enough, the mere existence of docker negates the main asset of Go in a devops context: statically linked binaries. Without containers, it's a huge selling point, but as soon as you use docker it brings nothing to the table anymore. > Using Rust won't translate into better performance without effort. Because of its focus on soundness, I would say that you need to put in even more effort. Saying so reveals that you've probably never tried it. The biggest performance issues I've been facing where memory allocations. With Go, things are “magically” allocated or not depending on the compiler's mood of the day (or the compiler version in practice) and you need to diagnoses these by looking through the escape analysis log, see when the compiler cannot elide the allocation and refactor until it works. With Rust, you just don't allocate memory unless you're using a `Box` or heap-allocated collection (a Vec or a HashMap for instance). In both case you can have an implementation with a good performance, but with Go you need tedious tuning, while Rust gives you an explicit control of the allocations. That's an enormous productivity difference.
steveklabnik 5y ago
> it will be easy to see that it's a poor choice for almost all web services Time will tell. I used to think this way, but don't anymore. That doesn't mean it's right for the majority of them, but I think it's workable for a very surprising number of them.
- twic 5y ago
  "workable for a very surprising number of them" seems substantially the same as "a poor choice for almost all" to me!
  - steveklabnik 5y ago
    Time will tell :)

by twic 5y ago

the__alchemist 5y ago

Agreed - I built a rust frontend framework, and tried to use it on the backend for a while. Ended up switching back to Python and Javascript for web - I use rust for embedded mostly now.

hu3 5y ago

Like Uber, some do manage to avoid the pitfall of trying to shoehorn hard languages everywhere. I recently learned their microservice fleet is almost entirely in Go [1]. Could also have been C#, Java, Python or Node but the point is it is not Rust or C++. Probably for the reasons you stated. [1] https://news.ycombinator.com/item?id=27120689 https://news.ycombinator.com/item?id=27120689

littlestymaar 5y ago
For companies like Uber, Rust would probably be a good fit if they started today: at this scale you spend more time optimizing some otherwise simple logic in order to scale up without wasting too much resources. Go has a decent optimization story, thanks to the escape analysis diagnostic which makes it quite straightforward to avoid many allocations (much more easily than in C# for instance, even if it's also doable in C# indeed), but Rust takes it step farther, and you'll have better performance to begin with, which will drastically reduce your scaling effort. For instance, look at what Cloudflare ended up doing to get Go working as they wanted: https://blog.cloudflare.com/go-dont-collect-my-garbage/ https://blog.cloudflare.com/go-dont-collect-my-garbage/ Rust will never be a competitor to Python or PHP (but it can enhance them, because making a native extension in Rust in way easier than in C, especially for people with a web back-end background and little C experience), but Go is losing a lot of appeal now that Rust is here ready for prime time.
- johnnycerberus 5y ago
  You have some unsubstantiated claims. Firstly, Go focuses on infrastructure, it is actually the bootloader of cloud-native wave. Rust is great but still, it can be replaced by C, C++ or Zig when it becomes stable. It doesn't have its own ecosystem nor there's any ROI coming out from there to say that it will replace Go tomorrow. On the other hand, when it comes to modern DevOps, Go became as irreplaceable as Python and Bash. Using Rust won't translate into better performance without effort. Because of its focus on soundness, I would say that you need to put in even more effort.
  - littlestymaar 5y ago
    > On the other hand, when it comes to modern DevOps, Go became as irreplaceable as Python and Bash Most devops don't use Go and I argue that for the ones who do, Rust is a big improvement. Sure Go is being used to make Docker and k8s, but with this reasoning Haskell is also irreplaceable since Pandoc is made with it… Ironically enough, the mere existence of docker negates the main asset of Go in a devops context: statically linked binaries. Without containers, it's a huge selling point, but as soon as you use docker it brings nothing to the table anymore. > Using Rust won't translate into better performance without effort. Because of its focus on soundness, I would say that you need to put in even more effort. Saying so reveals that you've probably never tried it. The biggest performance issues I've been facing where memory allocations. With Go, things are “magically” allocated or not depending on the compiler's mood of the day (or the compiler version in practice) and you need to diagnoses these by looking through the escape analysis log, see when the compiler cannot elide the allocation and refactor until it works. With Rust, you just don't allocate memory unless you're using a `Box` or heap-allocated collection (a Vec or a HashMap for instance). In both case you can have an implementation with a good performance, but with Go you need tedious tuning, while Rust gives you an explicit control of the allocations. That's an enormous productivity difference.

steveklabnik 5y ago

> it will be easy to see that it's a poor choice for almost all web services Time will tell. I used to think this way, but don't anymore. That doesn't mean it's right for the majority of them, but I think it's workable for a very surprising number of them.

twic 5y ago
"workable for a very surprising number of them" seems substantially the same as "a poor choice for almost all" to me!
- steveklabnik 5y ago
  Time will tell :)