34 ms·

Whenever I write Rust, I have a lot of fun, but I'm still not sold on it for most web dev. The analogy that comes to mind is that Rust is a really nice sports

Whenever I write Rust, I have a lot of fun, but I'm still not sold on it for most web dev. The analogy that comes to mind is that Rust is a really nice sports car with a great engine. It handles like a dream and you can feel the powerful engine humming while driving it. With the right open road, it's a great time. You can really optimize code, make great abstractions and work with data easily. Unfortunately, web dev generally isn't a wide open road. It's a lot of little turns and alleys and special cases. Driving Rust in web dev is a lot of accelerating only to screech to a halt. I wrote a backend API for a side project in Rust. And true to what I said, Rust handled like a dream. But I didn't need the power. I spent most of my time screeching to a halt worrying about the plumbing between the various immature Rust libraries. And that's on the backend, which is way more mature compared to the frontend Rust libraries. Judging by this post, OP managed to find a great open road in web dev to use Rust. I only wish I could find one as worthwhile.

rkwz 6y ago
Love the analogy! I think there's value in mixing Rust with languages with mature libraries like JS/Python/etc to optimize performance critical code paths - basically for things we've been using C/C++ so far. There's also a lot of progress in Rust community, I believe it'll get mature libraries very soon in future.
nicolodavis 6y ago
Yep, I don't think Rust is quite there yet for web dev. I didn't use Rust for any frontend interactions. The web app is an SPA written in Svelte. I only used it for the core state update logic, which benefits from the typing and performance boost.
- hardwaregeek 6y ago
  Yep! You found a really great open road to drive Rust. I'm jealous :D. If I had an app with as interesting requirements, I'd certainly consider your approach
laurencerowe 6y ago
For backend web development I was somewhat disappointed to see that many of the new web frameworks (all async) allocate extensively on the heap (for example lots of Strings in their http request types.) I mean it works but I don't understand why I would go to the bother of thinking about lifetimes when it seems performance would be similar to Kotlin / Swift / F#.
- staticassertion 6y ago
  I often write my code to allocate at first just to get a feel for the API and business logic and then go through it later to remove them. Given that all of those frameworks are still fairly new it wouldn't shock me to hear that that's the case.
- drewm1980 6y ago
  Rust never has to run a garbage collector, because it already figured out the lifetimes of all the values in your program statically, with relatively minor help from the programmer. This may make your code faster or more likely to be correct than code written in some of those languages.
  - laurencerowe 6y ago
    That's a fair point, I should distinguish heap allocation from reference counting. It still seems somewhat tricky to replicate the well proven arena allocation approach of Apache and Nginx which avoids memory fragmentation in current stable Rust though.
    - kd5bjo 6y ago
      For general areana allocation, you can use something like the Bumpalo crate: https://docs.rs/bumpalo/3.4.0/bumpalo/ https://docs.rs/bumpalo/3.4.0/bumpalo/
  - blub 6y ago
    It didn't figure them out at all, the programmer had to figure them out the hard way and then code them in so that the compiler understands them. GC is figuring out things mostly correctly and the programmer can focus on other things, at least until they hit a performance problem :)
aphextron 6y ago
This really nails why languages like PHP and Ruby have won out over static typed, compiled ones for application level web development. The web is a massive collection of disjointed, loosely coupled APIs that all (just barely) interoperate to provide a massive array of functionality. Languages that tend to work well with it are those that are highly flexible around the corner cases of these technologies, and allow you to quickly iterate through the process of gluing them together.
- swyx 6y ago
  this was historically true, but I suspect in the age of the evergreen browser this argument has been seriously dented (but not invalidated)
- pjmlp 6y ago
  Having ridden the 90's .com startup wave with an in-house application server written in a mix of Apache plugins and Tcl, I learned the hard way to never again rely on anything that doesn't bring a JIT or AOT compiler to the party.
  - quickthrower2 6y ago
    What's the hard lesson? Performance? You have more power these days. The bottleneck won't be the interpreter.
    - pjmlp 6y ago
      Performance yes, there is always more power as long as the bank account is full, and even then it isn't enough when working at scale. The amount of histories of porting code prove otherwise. Note I am not pushing away dynamic languages, only those that don't have a JIT/AOT as part of their canonical implementation. Common Lisp, Julia, JavaScript, PHP (7 and later) are all invited to the party. Meanwhile maybe JRuby or PyPy will eventually get more community love, instead of being the black swans.
      - 6y ago
EugeneOZ 6y ago
I use Rust for web not for performance, but for strict typing + smart compiler, safe refactoring, errors handling and many other language features - Rust is an amazing language even when you don't need performance.
deleted 6y ago
[deleted]
csomar 6y ago
It's still a significant upgrade over JavaScript. I'm developing a web app with the Backend in Rust and Front-end in Vuejs/JavaScript. Sure Rust was slower to develop, but it doesn't throw errors like 'val in undefined' and then I have to go debugging where I check for the value of val. You do that beforehand on Rust and that avoid a whole class of problems. JavaScript is cheaper to get started but becomes way more expensive to maintain. My Rust code on the other hand: Once it works it keeps working. If it compile it probably won't bug down the road. I'd switch to Rust / WebAssembly once the libraries are mature/stable/documented enough. The overhead cost is worth it in the long run.
- MaxBarraclough 6y ago
  You're referring to Rust's static type system. What do you make of TypeScript?
  - csomar 6y ago
    I've tried TypeScript and I didn't really like it. Plus you can ignore the strict type if you'd like to which is a slippery-slope if you are in a hurry to get something to market.
- qq717719152 6y ago
  test
- dgb23 6y ago
  > JavaScript is cheaper to get started but becomes way more expensive to maintain. I think this is assumption is a bit too broad. There is another side of this: In JS you write less code than in Rust and there is less explicit coupling in a dynamic codebase. So changes tend to be smaller and faster as well. For example if you pass a top-level data-structure X through A, B... and C but only C cares about some part Z. Then you change how Z is produced in A and consumed in C. If you are dynamic you just do exactly that, which is actually just fine. In a static language you have to change all the B's. Or you take the time and write a sensible abstraction over Z or X so in the future you don't have to change the B's anymore, which is better, but ultimately less readable and more complex. Stuff that is well understood and specified in advance suits a language like Rust better. You get all these runtime guarantees and performance. You get all this expressive (but explicit!) power to fine-tune abstractions and performance. It's great. But the closer you get to a UI (especially GUI) and non-technical, direct(!) users, the more dynamic you want to be. Because in this context you are more of a human to computer translator: requirements get discovered via iterations, interactions need to be tested and evolve etc.
Dowwie 6y ago
The first exposure is the hardest part. It's not the kind of language that one can just pick up and use effectively without first understanding the fundamentals, especially if using an async runtime. The investment is worthwhile, though.
lewisjoe 6y ago
Nice analogy. Here's somethine new. Rust is not just a sports car, but an eco-friendly electric one at that. One topic OP hasn't touched upon is the disadvantage of "pushing client side to the server". JS is terrible at handling concurrent processes. The browsers have been able to make do because they typically care about just one user. In the server though, it's terribly important to handle thousands of users concurrently. JS engines suck at it. To put it in plain words, if you are into SPAs and want server side rendering, among all the other issues the one sure wall you'd be hitting is scaling issues. JS will never be able to construct and send HTML over as efficiently as Rust could. This is going to be the reason why Rust(or a similar tech) will eventually win the web.
- josephg 6y ago
  I wish speed mattered more, but JavaScript on Nodejs is performant enough for 95% of websites out there. Most websites are in the long tail, and never need to handle more than about 10 requests per second. For most websites, team velocity matters more than the AWS bill. A clean static rendering system with caching, built on top of react / svelte / whatever performs well enough for almost everyone. And every year cpu costs drop, V8 gets faster and JS libraries get a little bit more mature. I love rust, but I don’t see it displacing nodejs any time soon. Maybe when websites can be 100% wasm and the rust web framework ecosystem matures some more. Fingers crossed, but I’m not holding my breath.
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
yachtman 6y ago
You might enjoy this blog post I wrote: http://kyleprifogle.com/churn-based-programming/ http://kyleprifogle.com/churn-based-programming/
- mkesper 6y ago
  It would be even more enjoyable if the text was black, had to use reader mode.
  - yachtman 6y ago
    Disadvantage of retina screens, I didn't even realize. Thanks for pointing out, i'll fix.
cs702 6y ago
> The analogy that comes to mind is that Rust is a really nice sports car with a great engine. It handles like a dream and you can feel the powerful engine humming while driving it. With the right open road, it's a great time. You can really optimize code, make great abstractions and work with data easily. I prefer a different analogy: Rust is high-end automated industrial equipment for machining high-precision metal parts that will fit perfectly with each other and which you can use to build anything you want, with high confidence that it will work and last a long time. But if you're under pressure to build lots of small, partially documented, constantly changing parts every day, you might be better off using more flexible equipment and materials (balsa wood, bailing wire, masking tape, etc.) to get the job done, even if the result will be messier and more prone to breaking.
- otoburb 6y ago
  >>But if you're under pressure to build lots of small, partially documented, constantly changing parts every day, you might be better off using more flexible equipment and materials (balsa wood, bailing wire, masking tape, etc.) to get the job done, even if the result will be messier and more prone to breaking. Python & Deno/Node fit the bill for the latter category. Would you consider Julia in the former or latter category for ML use-cases?
  - cs702 6y ago
    For ML/scientific computing, it can fulfill both roles, I'd say. Julia looks about as flexible and easy to use as Python, R, and matlab for experimenting and iterating quickly with throwaway code, and superior to those languages in every other important dimension except one: it lacks Python's gigantic ecosystem.
    - ChrisRackauckas 6y ago
      Julia has a much larger ecosystem in terms of things like numerical linear algebra, scientific computing, and differentiable programming. How do you use block banded Jacobians inside of ODE solvers? Python's ML ecosystems just barely got non-stiff methods, so advanced accelerations are fairly far away, whereas these are things that have worked with Julia's ML solvers for a long time now.

rkwz 6y ago

Love the analogy! I think there's value in mixing Rust with languages with mature libraries like JS/Python/etc to optimize performance critical code paths - basically for things we've been using C/C++ so far. There's also a lot of progress in Rust community, I believe it'll get mature libraries very soon in future.

nicolodavis 6y ago

Yep, I don't think Rust is quite there yet for web dev. I didn't use Rust for any frontend interactions. The web app is an SPA written in Svelte. I only used it for the core state update logic, which benefits from the typing and performance boost.

hardwaregeek 6y ago
Yep! You found a really great open road to drive Rust. I'm jealous :D. If I had an app with as interesting requirements, I'd certainly consider your approach

laurencerowe 6y ago

For backend web development I was somewhat disappointed to see that many of the new web frameworks (all async) allocate extensively on the heap (for example lots of Strings in their http request types.) I mean it works but I don't understand why I would go to the bother of thinking about lifetimes when it seems performance would be similar to Kotlin / Swift / F#.

staticassertion 6y ago
I often write my code to allocate at first just to get a feel for the API and business logic and then go through it later to remove them. Given that all of those frameworks are still fairly new it wouldn't shock me to hear that that's the case.
drewm1980 6y ago
Rust never has to run a garbage collector, because it already figured out the lifetimes of all the values in your program statically, with relatively minor help from the programmer. This may make your code faster or more likely to be correct than code written in some of those languages.
- laurencerowe 6y ago
  That's a fair point, I should distinguish heap allocation from reference counting. It still seems somewhat tricky to replicate the well proven arena allocation approach of Apache and Nginx which avoids memory fragmentation in current stable Rust though.
  - kd5bjo 6y ago
    For general areana allocation, you can use something like the Bumpalo crate: https://docs.rs/bumpalo/3.4.0/bumpalo/ https://docs.rs/bumpalo/3.4.0/bumpalo/
- blub 6y ago
  It didn't figure them out at all, the programmer had to figure them out the hard way and then code them in so that the compiler understands them. GC is figuring out things mostly correctly and the programmer can focus on other things, at least until they hit a performance problem :)

aphextron 6y ago

This really nails why languages like PHP and Ruby have won out over static typed, compiled ones for application level web development. The web is a massive collection of disjointed, loosely coupled APIs that all (just barely) interoperate to provide a massive array of functionality. Languages that tend to work well with it are those that are highly flexible around the corner cases of these technologies, and allow you to quickly iterate through the process of gluing them together.

swyx 6y ago
this was historically true, but I suspect in the age of the evergreen browser this argument has been seriously dented (but not invalidated)
pjmlp 6y ago
Having ridden the 90's .com startup wave with an in-house application server written in a mix of Apache plugins and Tcl, I learned the hard way to never again rely on anything that doesn't bring a JIT or AOT compiler to the party.
- quickthrower2 6y ago
  What's the hard lesson? Performance? You have more power these days. The bottleneck won't be the interpreter.
  - pjmlp 6y ago
    Performance yes, there is always more power as long as the bank account is full, and even then it isn't enough when working at scale. The amount of histories of porting code prove otherwise. Note I am not pushing away dynamic languages, only those that don't have a JIT/AOT as part of their canonical implementation. Common Lisp, Julia, JavaScript, PHP (7 and later) are all invited to the party. Meanwhile maybe JRuby or PyPy will eventually get more community love, instead of being the black swans.
    - 6y ago

EugeneOZ 6y ago

I use Rust for web not for performance, but for strict typing + smart compiler, safe refactoring, errors handling and many other language features - Rust is an amazing language even when you don't need performance.

deleted 6y ago

[deleted]

csomar 6y ago

It's still a significant upgrade over JavaScript. I'm developing a web app with the Backend in Rust and Front-end in Vuejs/JavaScript. Sure Rust was slower to develop, but it doesn't throw errors like 'val in undefined' and then I have to go debugging where I check for the value of val. You do that beforehand on Rust and that avoid a whole class of problems. JavaScript is cheaper to get started but becomes way more expensive to maintain. My Rust code on the other hand: Once it works it keeps working. If it compile it probably won't bug down the road. I'd switch to Rust / WebAssembly once the libraries are mature/stable/documented enough. The overhead cost is worth it in the long run.

MaxBarraclough 6y ago
You're referring to Rust's static type system. What do you make of TypeScript?
- csomar 6y ago
  I've tried TypeScript and I didn't really like it. Plus you can ignore the strict type if you'd like to which is a slippery-slope if you are in a hurry to get something to market.
qq717719152 6y ago
test
dgb23 6y ago
> JavaScript is cheaper to get started but becomes way more expensive to maintain. I think this is assumption is a bit too broad. There is another side of this: In JS you write less code than in Rust and there is less explicit coupling in a dynamic codebase. So changes tend to be smaller and faster as well. For example if you pass a top-level data-structure X through A, B... and C but only C cares about some part Z. Then you change how Z is produced in A and consumed in C. If you are dynamic you just do exactly that, which is actually just fine. In a static language you have to change all the B's. Or you take the time and write a sensible abstraction over Z or X so in the future you don't have to change the B's anymore, which is better, but ultimately less readable and more complex. Stuff that is well understood and specified in advance suits a language like Rust better. You get all these runtime guarantees and performance. You get all this expressive (but explicit!) power to fine-tune abstractions and performance. It's great. But the closer you get to a UI (especially GUI) and non-technical, direct(!) users, the more dynamic you want to be. Because in this context you are more of a human to computer translator: requirements get discovered via iterations, interactions need to be tested and evolve etc.

Dowwie 6y ago

The first exposure is the hardest part. It's not the kind of language that one can just pick up and use effectively without first understanding the fundamentals, especially if using an async runtime. The investment is worthwhile, though.

lewisjoe 6y ago

Nice analogy. Here's somethine new. Rust is not just a sports car, but an eco-friendly electric one at that. One topic OP hasn't touched upon is the disadvantage of "pushing client side to the server". JS is terrible at handling concurrent processes. The browsers have been able to make do because they typically care about just one user. In the server though, it's terribly important to handle thousands of users concurrently. JS engines suck at it. To put it in plain words, if you are into SPAs and want server side rendering, among all the other issues the one sure wall you'd be hitting is scaling issues. JS will never be able to construct and send HTML over as efficiently as Rust could. This is going to be the reason why Rust(or a similar tech) will eventually win the web.

josephg 6y ago
I wish speed mattered more, but JavaScript on Nodejs is performant enough for 95% of websites out there. Most websites are in the long tail, and never need to handle more than about 10 requests per second. For most websites, team velocity matters more than the AWS bill. A clean static rendering system with caching, built on top of react / svelte / whatever performs well enough for almost everyone. And every year cpu costs drop, V8 gets faster and JS libraries get a little bit more mature. I love rust, but I don’t see it displacing nodejs any time soon. Maybe when websites can be 100% wasm and the rust web framework ecosystem matures some more. Fingers crossed, but I’m not holding my breath.

deleted 6y ago

[deleted]

deleted 6y ago

[deleted]

yachtman 6y ago

You might enjoy this blog post I wrote: http://kyleprifogle.com/churn-based-programming/ http://kyleprifogle.com/churn-based-programming/

mkesper 6y ago
It would be even more enjoyable if the text was black, had to use reader mode.
- yachtman 6y ago
  Disadvantage of retina screens, I didn't even realize. Thanks for pointing out, i'll fix.

cs702 6y ago

> The analogy that comes to mind is that Rust is a really nice sports car with a great engine. It handles like a dream and you can feel the powerful engine humming while driving it. With the right open road, it's a great time. You can really optimize code, make great abstractions and work with data easily. I prefer a different analogy: Rust is high-end automated industrial equipment for machining high-precision metal parts that will fit perfectly with each other and which you can use to build anything you want, with high confidence that it will work and last a long time. But if you're under pressure to build lots of small, partially documented, constantly changing parts every day, you might be better off using more flexible equipment and materials (balsa wood, bailing wire, masking tape, etc.) to get the job done, even if the result will be messier and more prone to breaking.

otoburb 6y ago
>>But if you're under pressure to build lots of small, partially documented, constantly changing parts every day, you might be better off using more flexible equipment and materials (balsa wood, bailing wire, masking tape, etc.) to get the job done, even if the result will be messier and more prone to breaking. Python & Deno/Node fit the bill for the latter category. Would you consider Julia in the former or latter category for ML use-cases?
- cs702 6y ago
  For ML/scientific computing, it can fulfill both roles, I'd say. Julia looks about as flexible and easy to use as Python, R, and matlab for experimenting and iterating quickly with throwaway code, and superior to those languages in every other important dimension except one: it lacks Python's gigantic ecosystem.
  - ChrisRackauckas 6y ago
    Julia has a much larger ecosystem in terms of things like numerical linear algebra, scientific computing, and differentiable programming. How do you use block banded Jacobians inside of ODE solvers? Python's ML ecosystems just barely got non-stiff methods, so advanced accelerations are fairly far away, whereas these are things that have worked with Julia's ML solvers for a long time now.