4 ms·

There are teams rewriting web apps and APIs in Rust. Maybe they're making a mistake, maybe they're doing great and are happy trading off some developer time and

by jstx1 3y ago

There are teams rewriting web apps and APIs in Rust. Maybe they're making a mistake, maybe they're doing great and are happy trading off some developer time and training overhead for what they're getting from the language - I don't know which one is more common but the trend of rewriting in Rust is definitely there and it's accelerating.

cmrdporcupine 3y ago
I'm sure they'll have some success. But if I was the engineering manager or technical lead for teams like this, I would be cautious. From a hiring/staffing point of view it is foolish and probably unnecessary; there is a large pool of talent trained in existing web framework tech, and generally most web applications do not need the latency guarantees that come with a non-GC language like Rust. If you're trying to staff and maintain a team doing this kind of thing, picking boring old TypeScript and staffing up with excellent senior engineers and just applying rigorous quality controls and engineering standards to the codebase makes more sense. It gives you better ability to bring on new staff, and to use existing frameworks. FWIW I worked in ad serving for some years (at Google and prior) and much of that work is done in C++ because of millisecond granularity P99, etc. latency concerns. Rust is a natural fit there, even though that is nominally "web serving"; but that's a different domain than serving up database-backed microservices for typical web customer workloads; that stuff is on the whole I/O blocked and not impacted by GC sweeps.
twic 3y ago
Mostly, they are making a mistake. Some people are writing APIs where they genuinely need Rust's efficiency, but not many. I don't think the language of the project team can be blamed for encouraging this, but the community has unfortunately normalised it.
- Yoric 3y ago
  Frankly, I've just moved from writing web APIs in Rust to writing web APIs in Python and I miss Rust. I didn't use the language because it was fast (that was a nice side-benefit) but because it was reliable.
bryanlarsen 3y ago
If you have a compute-intensive app that benefits from Rust, it's really convenient to be able to easily add a web interface on it, for stuff like Prometheus metrics and for easy RPC control.
mamcx 3y ago
> There are teams rewriting web apps and APIs in Rust. That is not a bad sing, in fact. That mean the app was write and now is the second(third...) time. I do this, for work. People pay me to make this stuff several times in the past. And moving langs and other major changes (like move from web to mobile). Rust make this much better than before: You get some fast, yeah, some safety, great, but much better modeling of logic and great tooling, even errors are much better here! (ie more detailed, better resolutions). --- Rewriting a system is assumed to be a terrible mistake, and that is true mostly for organizational or political reason, but is VERY profitable if done by technical reasons! To make it a failure: - You need something dysfunctional in the org/team, and stay or move anyway will lead to doom. Make the jump to Rust WILL make this more evident! - You have inexperienced people doing this. Stay or move anyway will lead to doom, but move will be faster! To make it a success: - You somehow have a decent org/team - Budget the time required to make the change, not do it with major time presures - Do some small test validations, maybe just experiment a little a few weeks/months if the app is truly big. - Make the jump and use real data ASAP The rest is obvious work...

by jstx1 3y ago

cmrdporcupine 3y ago

I'm sure they'll have some success. But if I was the engineering manager or technical lead for teams like this, I would be cautious. From a hiring/staffing point of view it is foolish and probably unnecessary; there is a large pool of talent trained in existing web framework tech, and generally most web applications do not need the latency guarantees that come with a non-GC language like Rust. If you're trying to staff and maintain a team doing this kind of thing, picking boring old TypeScript and staffing up with excellent senior engineers and just applying rigorous quality controls and engineering standards to the codebase makes more sense. It gives you better ability to bring on new staff, and to use existing frameworks. FWIW I worked in ad serving for some years (at Google and prior) and much of that work is done in C++ because of millisecond granularity P99, etc. latency concerns. Rust is a natural fit there, even though that is nominally "web serving"; but that's a different domain than serving up database-backed microservices for typical web customer workloads; that stuff is on the whole I/O blocked and not impacted by GC sweeps.

twic 3y ago

Mostly, they are making a mistake. Some people are writing APIs where they genuinely need Rust's efficiency, but not many. I don't think the language of the project team can be blamed for encouraging this, but the community has unfortunately normalised it.

Yoric 3y ago
Frankly, I've just moved from writing web APIs in Rust to writing web APIs in Python and I miss Rust. I didn't use the language because it was fast (that was a nice side-benefit) but because it was reliable.

bryanlarsen 3y ago

If you have a compute-intensive app that benefits from Rust, it's really convenient to be able to easily add a web interface on it, for stuff like Prometheus metrics and for easy RPC control.

mamcx 3y ago

> There are teams rewriting web apps and APIs in Rust. That is not a bad sing, in fact. That mean the app was write and now is the second(third...) time. I do this, for work. People pay me to make this stuff several times in the past. And moving langs and other major changes (like move from web to mobile). Rust make this much better than before: You get some fast, yeah, some safety, great, but much better modeling of logic and great tooling, even errors are much better here! (ie more detailed, better resolutions). --- Rewriting a system is assumed to be a terrible mistake, and that is true mostly for organizational or political reason, but is VERY profitable if done by technical reasons! To make it a failure: - You need something dysfunctional in the org/team, and stay or move anyway will lead to doom. Make the jump to Rust WILL make this more evident! - You have inexperienced people doing this. Stay or move anyway will lead to doom, but move will be faster! To make it a success: - You somehow have a decent org/team - Budget the time required to make the change, not do it with major time presures - Do some small test validations, maybe just experiment a little a few weeks/months if the app is truly big. - Make the jump and use real data ASAP The rest is obvious work...