5 ms·

Is it just me, or is using Rust for web apps kinda odd?

excepttheweasel 11y ago
The main downside to using Rust for web apps - at least in my opinion: is having to learn and use a type system which includes affine types: lifetimes, borrowing etc. But if you've already put in the effort to get to grips with this part of the language, that's not as big a drawback. Then you get all the other positives of the language, like its strong type system, fast speed, sensible package manager, lack of GC pauses etc.
- pcwalton 11y ago
  I'm in full agreement with this. The learning curve (and the compilation speed I guess--but that's improving quickly) is the main drawback to writing Web apps in Rust. If you've already learned it, though, then it's basically just down to the typical static vs. dynamic typing tradeoff, with Rust just being like any other statically typed language.
  - EugeneOZ 11y ago
    Rust's errors handling and memory safety are important differences too.
- losvedir 11y ago
  > Then you get all the other positives of the language, like [...] lack of GC pauses etc. One thing I've been curious about: is it the case that there are no pauses, or that you know when they happen? I know one of the concerns with GC is it can just kind of happen whenever and pause whatever else you've got going on. It also has to do extra work to track down what sort of memory is reachable or not. Now is rust's RAII-style approach actually faster or do you just have more control over it? It doesn't have to trace reachable memory from the roots like a GC, but it still does have to do some work, right?
  - dimfeld 11y ago
    It's both faster and you have more control over it; the two are linked in this case. This system lets the compiler do the hard work to figure out when it's ok to deallocate some piece of memory, unlike a GC, which figures it out at runtime. One you've determined that some memory can be deallocated, the actual process is very quick, usually just updating a list of free blocks in the memory allocator and maybe some statistics. Rust does also support reference counting when you want it, which can bring its own set of performance issues in certain circumstances. Think more about general slowness due to constantly incrementing and decrementing references in an atomic fashion when you pass RC-ed data between functions, rather than the pauses seen with garbage collection. But how bad that is depends greatly on how and where you're using reference counted variables, and the addition of the lifetime/borrow system makes it easier to avoid some of the more egregious cases here. Additionally, some people are doing work on GCs that work with Rust. The two links below have some good descriptions of the progress and challenges related to that. http://blog.pnkfx.org/blog/2015/10/27/gc-and-rust-part-0-how-does-gc-work/ http://blog.pnkfx.org/blog/2015/10/27/gc-and-rust-part-0-how... http://manishearth.github.io/blog/2015/09/01/designing-a-gc-in-rust/ http://manishearth.github.io/blog/2015/09/01/designing-a-gc-...
mrcwinn 11y ago
It wouldn't be my first choice (or second, or third), but I would say that Rust could be well-suited for APIs. So, if your web app is a single page app that is simply communicating with an API, it starts to make a little more sense, if your primary motivation is doing something "new" or challenging for the sake of it. That being said, I don't think that should be anybody's primary motivation for a production application. :)
- dikaiosune 11y ago
  I didn't get the impression from the article that they just wanted to do something new, they wanted a language/compiler that provided a lot of guarantees before they ever started debugging. That seems like a perfectly reasonable motivation for using a new technology in production.
bpicolo 11y ago
It's not just you, it is kind of odd. It is -doable-, but outside of having some really specific requirements wouldn't be my go to. The overhead for web stuff in other languages is just so much lower.
DasIch 11y ago
At the moment it is because the ecosystem isn't quite there, yet. Fundamentally though there are quite a few advantages when it comes to performance and safety.
pjmlp 11y ago
Why should it be odd? It should be perfectly natural to use compiled languages to serve web requests. Rust is a very expressive language, and with its focus on safety a very good candidate for distributed systems. I for one, given my experience using Tcl for an application server, find odd to use scripting languages for web.
- skewart 11y ago
  I don't think there's anything inherently wrong with Rust the language in this context, but an API server doesn't really let Rust play to its relative strengths. Response times are more likely to be DB or I/O bound than anything else, so you'reprobably not improving response time much compared to Ruby or Python (of course, that's not always true though). Also, the ecosystem seems immature enough still that you'd inevitably have to reinvent at least a few wheels. That said, I think it's great to do things like this. Someone has to pave the way. And, if a good API/web ecosystem builds up in Rust there's no reason _not_ to use it. At the moment though, I think a more _natural_ fit for Rust would be for something a little lower level than an API server.
  - 6d65 11y ago
    Static linking i.e. having one single binary to drop onto a server, and most likely lower memory consumption(more concurrent users served by a single box). These two could probably be added to a list of reasons.
    - bschwindHN 11y ago
      That is a huge reason I'm interested in Rust for backend web programming. I love the ease of use NPM provides when it comes to installing dependencies. Installing libraries is definitely a pain point in something like a C++ project. Cargo is like NPM but the end result is a native executable. And if you have a lot of users, Rust can help lower your monthly bill by requiring fewer resources. The safer memory guarantees from the compiler is a great bonus on top of all that.
EugeneOZ 11y ago
Using Go for web servers is Ok (ask Google), Rust is in (almost) same field (just much better), so there are not so many differences.
grayrest 11y ago
No more odd than using Java. There's the huge difference in libraries and tooling but I don't think any inherent feature of Rust makes it less suitable for web backends than Java. I wouldn't pitch this project at work today but somebody has to go first. Rust makes the most sense to me in a GraphQL/Falcor type backend. The lower number of endpoints combined with Rust's perf and focus on correctness seem like a better fit than templating out web pages.
lambda 11y ago
I don't really see why it would be odd, other than the ecosystem not having quite caught up yet with some other languages. It's an expressive, high level language, which makes being explicit about error handling very easy, the type system makes it a lot easier to guarantee at compile time that a number of errors possible in dynamic languages will never happen, and it's quite efficient. The efficiency and explicit memory ownership in Rust makes it a lot easier to avoid some of the scalability problems you run into in dynamic languages. The amount of material you can find online on people discussing hunting down memory leaks in Rails, or discussing how they just scale up by throwing gobs of RAM and extra servers at the problem or restarting their app every day or two, is all stuff that is much easier to avoid in a language like Rust. It is possible to leak memory in Rust, but due to how explicit you are about how memory is owned, it's less likely and more likely to be easier to track down if you do. It is a bit more conceptual overhead to learn Rust than many dynamic languages, but I think that overhead is well spent as it can pay off in performance, stability, and maintainability later on.
- nickjj 11y ago
  It's unfortunate that the ecosystem is such a strong point for so many people. Sure I might need 250mb of RAM for a Rails app but there's 10+ years of real life thought and care put into the framework and about the same in external gems/blog posts/etc.. I'm ok with spending $5/month on an instance to serve a Rails app for 95% of use cases and I'm a load balancer away from multiplying my throughput if I need to scale out. If I could snap my fingers and have the same ecosystem in Rust I would switch instantly but it's not the world we live in. I'm not sure if even 5 years will be enough because Go 1.0 has been out almost 4 years and it's still not even in the same galaxy as Rails in terms of ecosystem.
  - lambda 11y ago
    Of course, now that increasingly more work is being done on the client side, or by communicating with microservices, Rust makes more sense for a pure API backend. There's a lot less ecosystem needed there; mostly just bindings to whatever database you need to talk to, possibly some other stuff. So if you're just going to be exposing a RESTful API backend for a JavaScript based frontend, or even for a Rails app frontend to talk to, Rust makes a lot more sense. Also, the only way an ecosystem gets bootstrapped up is by people scratching their own itches. By starting to write web services in Rust now, and implementing those things that aren't yet implemented, you can help to bootstrap it up. Of course, that only works if you have the extra time to spare to do so, but for those things that only need one or two extra things that don't yet exist, it may pay off due to the lower chances of having to debug runtime errors, less time and complexity spent trying to make it scale out, etc.
yawaramin 11y ago
This is for the backend, not the frontend, so it's perfectly fine.
eva1984 11y ago
My feeling too. Don't know how safety claim of Rust ensures on server side, here seems more on the application layer. However, if just writing some apis, then any language will do, I don't see Rust is particular odd in that sense, if you are willing to forget about ecosystem, while at the same time I don't believe it has a edge over other language.
bsaul 11y ago
The more i code over the full stack, the more i realize many technics on the backend are similar to the ones you find on Single Page Application or native apps. The flow is this : an event comes in, you need to answer to it very quickly by doing synchronous tasks, and sometimes you also need to trigger asynchronous tasks in parallel, wait for their result, and assemble it before sending the result ( / upadte the gui). Basically, synchronous algorithls are solved by any language. The core issue that remains both on the client and the server is handling shared state and parallelism.
jeffdavis 11y ago
You never know when something is going to really click. One thing that's really cool about rust is that it can choose a conversion function based on the type of thing you are assigning to. In other words, in "let x = foo()", foo() can do a different thing depending on the type of x. I found that out working on a simple rust program interacting with postgresql. Not saying that one feature makes all the difference, but you find nice advantages like that all around. Taken together, they might lead you to a more creative overall solution, and it might be a game changer.
nvarsj 11y ago
Adding the cognitive overhead of memory management for a web app is rarely going to be worth it. Unfortunately there are there a certain class of devs who are always going to chase the latest shiny thing (and they are predominately web developers, for some reason).

The main downside to using Rust for web apps - at least in my opinion: is having to learn and use a type system which includes affine types: lifetimes, borrowing etc. But if you've already put in the effort to get to grips with this part of the language, that's not as big a drawback. Then you get all the other positives of the language, like its strong type system, fast speed, sensible package manager, lack of GC pauses etc.

pcwalton 11y ago
I'm in full agreement with this. The learning curve (and the compilation speed I guess--but that's improving quickly) is the main drawback to writing Web apps in Rust. If you've already learned it, though, then it's basically just down to the typical static vs. dynamic typing tradeoff, with Rust just being like any other statically typed language.
- EugeneOZ 11y ago
  Rust's errors handling and memory safety are important differences too.
losvedir 11y ago
> Then you get all the other positives of the language, like [...] lack of GC pauses etc. One thing I've been curious about: is it the case that there are no pauses, or that you know when they happen? I know one of the concerns with GC is it can just kind of happen whenever and pause whatever else you've got going on. It also has to do extra work to track down what sort of memory is reachable or not. Now is rust's RAII-style approach actually faster or do you just have more control over it? It doesn't have to trace reachable memory from the roots like a GC, but it still does have to do some work, right?
- dimfeld 11y ago
  It's both faster and you have more control over it; the two are linked in this case. This system lets the compiler do the hard work to figure out when it's ok to deallocate some piece of memory, unlike a GC, which figures it out at runtime. One you've determined that some memory can be deallocated, the actual process is very quick, usually just updating a list of free blocks in the memory allocator and maybe some statistics. Rust does also support reference counting when you want it, which can bring its own set of performance issues in certain circumstances. Think more about general slowness due to constantly incrementing and decrementing references in an atomic fashion when you pass RC-ed data between functions, rather than the pauses seen with garbage collection. But how bad that is depends greatly on how and where you're using reference counted variables, and the addition of the lifetime/borrow system makes it easier to avoid some of the more egregious cases here. Additionally, some people are doing work on GCs that work with Rust. The two links below have some good descriptions of the progress and challenges related to that. http://blog.pnkfx.org/blog/2015/10/27/gc-and-rust-part-0-how-does-gc-work/ http://blog.pnkfx.org/blog/2015/10/27/gc-and-rust-part-0-how... http://manishearth.github.io/blog/2015/09/01/designing-a-gc-in-rust/ http://manishearth.github.io/blog/2015/09/01/designing-a-gc-...

mrcwinn 11y ago

It wouldn't be my first choice (or second, or third), but I would say that Rust could be well-suited for APIs. So, if your web app is a single page app that is simply communicating with an API, it starts to make a little more sense, if your primary motivation is doing something "new" or challenging for the sake of it. That being said, I don't think that should be anybody's primary motivation for a production application. :)

dikaiosune 11y ago
I didn't get the impression from the article that they just wanted to do something new, they wanted a language/compiler that provided a lot of guarantees before they ever started debugging. That seems like a perfectly reasonable motivation for using a new technology in production.

bpicolo 11y ago

It's not just you, it is kind of odd. It is -doable-, but outside of having some really specific requirements wouldn't be my go to. The overhead for web stuff in other languages is just so much lower.

DasIch 11y ago

At the moment it is because the ecosystem isn't quite there, yet. Fundamentally though there are quite a few advantages when it comes to performance and safety.

pjmlp 11y ago

Why should it be odd? It should be perfectly natural to use compiled languages to serve web requests. Rust is a very expressive language, and with its focus on safety a very good candidate for distributed systems. I for one, given my experience using Tcl for an application server, find odd to use scripting languages for web.

skewart 11y ago
I don't think there's anything inherently wrong with Rust the language in this context, but an API server doesn't really let Rust play to its relative strengths. Response times are more likely to be DB or I/O bound than anything else, so you'reprobably not improving response time much compared to Ruby or Python (of course, that's not always true though). Also, the ecosystem seems immature enough still that you'd inevitably have to reinvent at least a few wheels. That said, I think it's great to do things like this. Someone has to pave the way. And, if a good API/web ecosystem builds up in Rust there's no reason _not_ to use it. At the moment though, I think a more _natural_ fit for Rust would be for something a little lower level than an API server.
- 6d65 11y ago
  Static linking i.e. having one single binary to drop onto a server, and most likely lower memory consumption(more concurrent users served by a single box). These two could probably be added to a list of reasons.
  - bschwindHN 11y ago
    That is a huge reason I'm interested in Rust for backend web programming. I love the ease of use NPM provides when it comes to installing dependencies. Installing libraries is definitely a pain point in something like a C++ project. Cargo is like NPM but the end result is a native executable. And if you have a lot of users, Rust can help lower your monthly bill by requiring fewer resources. The safer memory guarantees from the compiler is a great bonus on top of all that.

EugeneOZ 11y ago

Using Go for web servers is Ok (ask Google), Rust is in (almost) same field (just much better), so there are not so many differences.

grayrest 11y ago

No more odd than using Java. There's the huge difference in libraries and tooling but I don't think any inherent feature of Rust makes it less suitable for web backends than Java. I wouldn't pitch this project at work today but somebody has to go first. Rust makes the most sense to me in a GraphQL/Falcor type backend. The lower number of endpoints combined with Rust's perf and focus on correctness seem like a better fit than templating out web pages.

lambda 11y ago

I don't really see why it would be odd, other than the ecosystem not having quite caught up yet with some other languages. It's an expressive, high level language, which makes being explicit about error handling very easy, the type system makes it a lot easier to guarantee at compile time that a number of errors possible in dynamic languages will never happen, and it's quite efficient. The efficiency and explicit memory ownership in Rust makes it a lot easier to avoid some of the scalability problems you run into in dynamic languages. The amount of material you can find online on people discussing hunting down memory leaks in Rails, or discussing how they just scale up by throwing gobs of RAM and extra servers at the problem or restarting their app every day or two, is all stuff that is much easier to avoid in a language like Rust. It is possible to leak memory in Rust, but due to how explicit you are about how memory is owned, it's less likely and more likely to be easier to track down if you do. It is a bit more conceptual overhead to learn Rust than many dynamic languages, but I think that overhead is well spent as it can pay off in performance, stability, and maintainability later on.

nickjj 11y ago
It's unfortunate that the ecosystem is such a strong point for so many people. Sure I might need 250mb of RAM for a Rails app but there's 10+ years of real life thought and care put into the framework and about the same in external gems/blog posts/etc.. I'm ok with spending $5/month on an instance to serve a Rails app for 95% of use cases and I'm a load balancer away from multiplying my throughput if I need to scale out. If I could snap my fingers and have the same ecosystem in Rust I would switch instantly but it's not the world we live in. I'm not sure if even 5 years will be enough because Go 1.0 has been out almost 4 years and it's still not even in the same galaxy as Rails in terms of ecosystem.
- lambda 11y ago
  Of course, now that increasingly more work is being done on the client side, or by communicating with microservices, Rust makes more sense for a pure API backend. There's a lot less ecosystem needed there; mostly just bindings to whatever database you need to talk to, possibly some other stuff. So if you're just going to be exposing a RESTful API backend for a JavaScript based frontend, or even for a Rails app frontend to talk to, Rust makes a lot more sense. Also, the only way an ecosystem gets bootstrapped up is by people scratching their own itches. By starting to write web services in Rust now, and implementing those things that aren't yet implemented, you can help to bootstrap it up. Of course, that only works if you have the extra time to spare to do so, but for those things that only need one or two extra things that don't yet exist, it may pay off due to the lower chances of having to debug runtime errors, less time and complexity spent trying to make it scale out, etc.

yawaramin 11y ago

This is for the backend, not the frontend, so it's perfectly fine.

eva1984 11y ago

My feeling too. Don't know how safety claim of Rust ensures on server side, here seems more on the application layer. However, if just writing some apis, then any language will do, I don't see Rust is particular odd in that sense, if you are willing to forget about ecosystem, while at the same time I don't believe it has a edge over other language.

bsaul 11y ago

The more i code over the full stack, the more i realize many technics on the backend are similar to the ones you find on Single Page Application or native apps. The flow is this : an event comes in, you need to answer to it very quickly by doing synchronous tasks, and sometimes you also need to trigger asynchronous tasks in parallel, wait for their result, and assemble it before sending the result ( / upadte the gui). Basically, synchronous algorithls are solved by any language. The core issue that remains both on the client and the server is handling shared state and parallelism.

jeffdavis 11y ago

You never know when something is going to really click. One thing that's really cool about rust is that it can choose a conversion function based on the type of thing you are assigning to. In other words, in "let x = foo()", foo() can do a different thing depending on the type of x. I found that out working on a simple rust program interacting with postgresql. Not saying that one feature makes all the difference, but you find nice advantages like that all around. Taken together, they might lead you to a more creative overall solution, and it might be a game changer.

nvarsj 11y ago

Adding the cognitive overhead of memory management for a web app is rarely going to be worth it. Unfortunately there are there a certain class of devs who are always going to chase the latest shiny thing (and they are predominately web developers, for some reason).