I've historically been very skeptical of Rust in the web application tier, but I've been playing around with it lately. It's been nicer than I've expected.
Crates.io, our package server, uses Rust + Ember. One thing that is really interesting about Rust in this space is memory usage: last I heard, crates.io uses a flat ~30 MB of RAM, resident. I'm used to Rails where that is... very different.
On that note, I think "Rust serving JSON + Javascript for the frontend" is a really interesting stack. I've been trying to find the time (and hopefully roping another person or two in) to build a http://jsonapi.org/ library for this purpose. I have a project where I've been using it, but I went down the "why use a library, I can generate the JSON by hand" and it's.... ugly. Serde is so much nicer.
As always with a young ecosystem, we need more libraries. For everything. It's gotten a lot better, and much of the basics are there, but sometimes, you're still going to have to write things yourself, which slows things down.
mio is gaining preliminary Windows support, and once it does, hyper will roll it in, which should significantly improve performance in many web contexts, as well.
I largely come from Ruby, where Rails was such a leap forward that people learned Ruby just to use it. I expect that if you know Rust, writing application-tier Rust will be fine, but I'm not sure it will ever see the same kind of pattern.
I don't have a login on rust-lang yet, but I wanted to add this comment regarding the documentation:
The rust-doc auto generated pages are really confusing. The sidebar generally fails to show where in the hierarchy of the API docs you are (ideally it would highlight the current page you're looking at in the hierarchy and provide the full hierarchy to give you context), the breadcrumbs don't indicate that they are links, the breadcrumbs indicate the type of the entry to the left rather than the right adding semantic confusion, and long pages tend to not have a TOC meaning you have to either search in the page or know the page structure ahead of time (probably mostly an issue for new users).
I feel like those are all simple mechanical issues that could make the auto-generated rust-docs a lot more useful.
It'd also be nice to tie non-auto generated docs into a crate's documentation, but I haven't looked into how rustdoc works so I'd guess that's possible but a lot of people don't do it.
Is it possible to do https serving in any of the web frameworks? Last I checked (months ago) it did not seem possible. I guess a crypto and tls library would be essential to this. I think https is pretty important feature to have given http2 and whats coming down the pipe.
What's the deal with Serde / rustc_serialize ? I've used serde mainly because I've seen mentioned a few times and saw a thread somewhere saying it was the successor of rustc_serialize.
I have fully switched over to Rust to do my web backend's. I use Nickel.rs and it has worked great. The code is very succinct and fast. The only downside I have found to this is that there is no "Hot Reload" which I had with Flask(Python) and Play(Scala).
As the ecosystem grows I only expect it to get better.
I'm using Iron instead of Nickel. Not sure who will become more popular over time...
Because of the language (no null, bounds checking, option/result types, etc.) and borrow checker I find I rarely have to 'hot reload' or even test my code. I realize that sounds surprising. I'm not doing any HTML templating in Rust - that's better done in JavaScript on the client - so I don't have the edit/compile/test cycle for every tweak to the UI.
What was behind your decision to pick Rust? My understanding is that Rust is meant as replacement for C++ in places where C++ performance is needed (browsers, systems programming (maybe)), etc. A web server does not fall into that category, so why did you pick it?
Isn't async io pretty much mandatory to compete with the top platforms/frameworks now? I'm certain rust can compete with C++ on raw compute speed, but io is still going to bog it down. Are there any rust frameworks that are using mio yet?
> the server is currently quite slow, only handling around 6.5k req/s for the GET handler, removing the database part makes it shoot up to 70k req/s so something must be going wrong somewhere around postgres
Dynamic typed language frameworks are also around 70k requests per second[1], something must be going wrong outside postgres too.
I love this type of exploration and discovery. Sometimes it's the best way to find a diamond in the rough. Who knows? Maybe Rust is the best language for web services, it just needs a little more exploring. Any feedback in terms of RDMS that you can use today or NoSQL? How about reddis? Milliseconds and memory matter when you scale.
EDIT: Agh! Armin isn't the author of Requests. :) I'm mad at myself because I even went to the Requests home page to attempt to verify that before posting this comment, and mistook his name under "Testimonials" as an indication of authorship. :P Sorry Kenneth!
I expect that Rust will actually be really good for the sort of things that Go is currently being used for on the web – i.e. services that don't have user interfaces.
The performance is better and I reckon it's much nicer to write. Unfortunately, the ecosystem isn't there yet.
> The performance is better and I reckon it's much nicer to write. Unfortunately, the ecosystem isn't there yet.
In my preliminary tinkerings, I'm a bit faster writing Go than Rust. I'm not super comfortable with either language. Rust's compiler is a lot more picky, and there's a learning curve to understand how ownership works. Go is a comparatively simple language (which can be a positive or a negative depending on your ideals and usage cases).
I think Go will probably always be "faster" to write, but Rust will keep you from making certain mistakes that you may have sunk debugging time into later. Hard to say where the time break-even is. I am keeping a close eye on both camps so that I'm equipped to make the call as soon as some of our components at work need something faster than Python.
If the main goal is static typing, it seems like using a static compile-to-JS language may be better because you can use the whole Node ecosystem. A few choices for static typing (the first two are JS supersets, the second two are just different languages):
From my experience (used Typescript for a few projects for frontend and tried Flow but ran into bugs/missing things) both TS and Flow type system are easy to fool and in the end you are still writing javascript.
I've never heard of Elm or PureScript being used for backends, users would prefer Haskell I presume.
With elm it would require using ports for almost everything, I haven't used PureScript so I can't comment on that.
And as far as ecosystems go, I would prefer using the Python one rather than the Node one.
Out of curiosity, how is that better than using Rust? My personal intuition is that by using a compile-to-JS + Node, you lose performance (Node.js is good for I/O, but not great for anything CPU-bound), plus combining Node.js and compile-to-JS is not too easy, if the compiler is not designed specifically for it (typically if it's not CPS-based).
In addition, if you intend to use static typing on generated JS, I suspect that you are going to lose plenty of information.
Are there any good GUI tools for debugging Rust? Python + PyCharm is amazing, except now django.setup() takes so long to run in the debugger, I've switched to print statements.
I've used Eclipse with the RustDT plugin to debug a project successfully. There's probably ways to make it work in Sublime/Vim/et. al, I just haven't put in the effort to figure it all out yet.
[+] [-] steveklabnik|10 years ago|reply
One thing this blog post points out is Rust ecosystem docs. I've been trying to find a good way to evaluate this: https://users.rust-lang.org/t/lets-talk-about-ecosystem-docu...
Other thoughts:
Crates.io, our package server, uses Rust + Ember. One thing that is really interesting about Rust in this space is memory usage: last I heard, crates.io uses a flat ~30 MB of RAM, resident. I'm used to Rails where that is... very different.
On that note, I think "Rust serving JSON + Javascript for the frontend" is a really interesting stack. I've been trying to find the time (and hopefully roping another person or two in) to build a http://jsonapi.org/ library for this purpose. I have a project where I've been using it, but I went down the "why use a library, I can generate the JSON by hand" and it's.... ugly. Serde is so much nicer.
As always with a young ecosystem, we need more libraries. For everything. It's gotten a lot better, and much of the basics are there, but sometimes, you're still going to have to write things yourself, which slows things down.
mio is gaining preliminary Windows support, and once it does, hyper will roll it in, which should significantly improve performance in many web contexts, as well.
I largely come from Ruby, where Rails was such a leap forward that people learned Ruby just to use it. I expect that if you know Rust, writing application-tier Rust will be fine, but I'm not sure it will ever see the same kind of pattern.
[+] [-] DannoHung|10 years ago|reply
I don't have a login on rust-lang yet, but I wanted to add this comment regarding the documentation:
The rust-doc auto generated pages are really confusing. The sidebar generally fails to show where in the hierarchy of the API docs you are (ideally it would highlight the current page you're looking at in the hierarchy and provide the full hierarchy to give you context), the breadcrumbs don't indicate that they are links, the breadcrumbs indicate the type of the entry to the left rather than the right adding semantic confusion, and long pages tend to not have a TOC meaning you have to either search in the page or know the page structure ahead of time (probably mostly an issue for new users).
I feel like those are all simple mechanical issues that could make the auto-generated rust-docs a lot more useful.
It'd also be nice to tie non-auto generated docs into a crate's documentation, but I haven't looked into how rustdoc works so I'd guess that's possible but a lot of people don't do it.
[+] [-] deskamess|10 years ago|reply
[+] [-] Keats|10 years ago|reply
[+] [-] dkhenry|10 years ago|reply
As the ecosystem grows I only expect it to get better.
[+] [-] untothebreach|10 years ago|reply
1: https://github.com/passcod/cargo-watch
[+] [-] zatkin|10 years ago|reply
[+] [-] markus2012|10 years ago|reply
I'm using Iron instead of Nickel. Not sure who will become more popular over time...
Because of the language (no null, bounds checking, option/result types, etc.) and borrow checker I find I rarely have to 'hot reload' or even test my code. I realize that sounds surprising. I'm not doing any HTML templating in Rust - that's better done in JavaScript on the client - so I don't have the edit/compile/test cycle for every tweak to the UI.
[+] [-] Touche|10 years ago|reply
[+] [-] Keats|10 years ago|reply
[+] [-] the_mitsuhiko|10 years ago|reply
[+] [-] vkjv|10 years ago|reply
[+] [-] saosebastiao|10 years ago|reply
[+] [-] steveklabnik|10 years ago|reply
[+] [-] jamwt|10 years ago|reply
[+] [-] acconsta|10 years ago|reply
[+] [-] welder|10 years ago|reply
Dynamic typed language frameworks are also around 70k requests per second[1], something must be going wrong outside postgres too.
[1] https://www.techempower.com/benchmarks/#section=data-r10&hw=...
[+] [-] cdnsteve|10 years ago|reply
[+] [-] kibwen|10 years ago|reply
EDIT: Agh! Armin isn't the author of Requests. :) I'm mad at myself because I even went to the Requests home page to attempt to verify that before posting this comment, and mistook his name under "Testimonials" as an indication of authorship. :P Sorry Kenneth!
[+] [-] steveklabnik|10 years ago|reply
[+] [-] matthewmacleod|10 years ago|reply
The performance is better and I reckon it's much nicer to write. Unfortunately, the ecosystem isn't there yet.
[+] [-] gtaylor|10 years ago|reply
In my preliminary tinkerings, I'm a bit faster writing Go than Rust. I'm not super comfortable with either language. Rust's compiler is a lot more picky, and there's a learning curve to understand how ownership works. Go is a comparatively simple language (which can be a positive or a negative depending on your ideals and usage cases).
I think Go will probably always be "faster" to write, but Rust will keep you from making certain mistakes that you may have sunk debugging time into later. Hard to say where the time break-even is. I am keeping a close eye on both camps so that I'm equipped to make the call as soon as some of our components at work need something faster than Python.
[+] [-] dangoor|10 years ago|reply
* Flow from Facebook
* TypeScript
* Elm
* PureScript
[+] [-] Keats|10 years ago|reply
I've never heard of Elm or PureScript being used for backends, users would prefer Haskell I presume. With elm it would require using ports for almost everything, I haven't used PureScript so I can't comment on that.
And as far as ecosystems go, I would prefer using the Python one rather than the Node one.
[+] [-] Yoric|10 years ago|reply
In addition, if you intend to use static typing on generated JS, I suspect that you are going to lose plenty of information.
[+] [-] munro|10 years ago|reply
[+] [-] steveklabnik|10 years ago|reply
[+] [-] kinghajj|10 years ago|reply