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.
Hey there. Thanks! Rustdoc can _certainly_ use way more improvements. Many of the things you've expressed are here: https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Ais... I would love to re-write all of Rustdoc, frankly, but haven't been able to. Even just re-doing the HTML/CS/JS would be pretty great, I think. There are never enough hours in the day.
I'm not overly familiar with Rustdoc's internals, but I would imagine that traversing type information will become much more straightforward when HIR/MIR become a reality. Is that accurate? If so, maybe that's a something for which it's worth delaying a structural overhaul.
I have no idea how rustdoc works, frankly. Parsers are one of those things that I am irrationally scared to hack on. At some point, I'll get fed up and overcome that, but it hasn't quite gotten there yet...
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.
And if you want to patch other frameworks or build your own: I have personally used Hyper (http-crate) with the OpenSSL crate to do Https before and I found it very easy.
Can you point me to an example? I tried looking at the cargo github repo and searched for tls but had no luck. Also searched for 443 and found it in source.rs but it was in a url canonicalization function when calling github.
I am looking for example code where I can pass in the server certificate prior to listening. Something similar in functionality to Go's http.ListenAndServeTLS(":443", "cert.pem", "key.pem", nil)
Cargo is a client, not a server, so that's probably where your problem finding things lies. I don't have an example handy, to be honest. Historically speaking, when deploying Rails, I would always use Nginx in front of my application server to terminate SSL anyway...
Also, the Iron docs that another commenter pointed you at looks vaguely like that call. I'm not familiar with Go's API.
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.
rustc_serialize was built for the compiler itself, and not really well-designed to be an external library. But it was Good Enough for a long time. Serde is the next-gen, built from the ground up to be awesome thing.
Well, it depends. Serde is still in active development, not at 1.0 yet. I don't think it's totally clear that at _this moment_, it's always better. It will be in the future, I'm just not sure that future is today.
Plus, there are other serialization libraries as well, and having the official Rust docs play favorites in the ecosystem is something we try to avoid.
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.