11–17 of 17 posts
Earlier quoted context omitted.
It has the tooling story figured out, but its type system leaves a lot to be desired
A lot? I mean, it's not rust but it's not that bad.
Rust in a web dev shop would be a huge premature optimzation smell for me. Most public web apps are expected to be up pretty much all of the time, which today, means cloud hosting and horizontally scalable architecture. In such a setup, I don't see how squeezing every last drop of performance is worth it. When I can just change a number and get more instances, choosing the language with higher cognitive load is going…
I've written websites with Rust simply because it's a sane modern language with few "gotchas" and a type system and borrowing system that allows you to eliminate huge classes of bugs (not just memory errors!)
That said I think the Rust web ecosystem is not super mature (especially client side) and most web frameworks use `async` which is one of the sketchiest parts of Rust IMO. So I don't think it would be entirely unreasonable to use something else. Especially Typescript, for the SSR/isomorphic apps.
Rust in a web dev shop would be a huge premature optimzation smell for me. Most public web apps are expected to be up pretty much all of the time, which today, means cloud hosting and horizontally scalable architecture. In such a setup, I don't see how squeezing every last drop of performance is worth it. When I can just change a number and get more instances, choosing the language with higher cognitive load is going…
Performance isn't Rust's only feature. I would say it isn't even its most important one. I've written websites with Rust simply because it's a sane modern language with few "gotchas" and a type system and borrowing system that allows you to eliminate huge classes of bugs (not just memory errors!) That said I think the Rust web ecosystem is not super mature (especially client side) and most web frameworks use `async`…
Rust in a web dev shop would be a huge premature optimzation smell for me. Most public web apps are expected to be up pretty much all of the time, which today, means cloud hosting and horizontally scalable architecture. In such a setup, I don't see how squeezing every last drop of performance is worth it. When I can just change a number and get more instances, choosing the language with higher cognitive load is going…
Performance isn't Rust's only feature. I would say it isn't even its most important one. I've written websites with Rust simply because it's a sane modern language with few "gotchas" and a type system and borrowing system that allows you to eliminate huge classes of bugs (not just memory errors!) That said I think the Rust web ecosystem is not super mature (especially client side) and most web frameworks use `async`…
I guess what's implicit in my attitude is that I think Rust introduces cognitive load that other (especially garbage-collected) languages do. There has to be enough of a win gotten to offset that. I used performance as the most likely reason I could think of.
Earlier quoted context omitted.
Performance isn't Rust's only feature. I would say it isn't even its most important one. I've written websites with Rust simply because it's a sane modern language with few "gotchas" and a type system and borrowing system that allows you to eliminate huge classes of bugs (not just memory errors!) That said I think the Rust web ecosystem is not super mature (especially client side) and most web frameworks use `async`…
How does this compare to let's say Java, which has both type-safety and a mature web ecosystem?
It does have a very mature server side web ecosystem so it's a perfectly reasonable option. I've written Java web servers before and it was fine.
I wouldn't use it for client side though (a la GWT). Debugging nightmare.