Hacker News Reader

Comment by mangeletti | Hacker News Reader

I've been excited to try Rust for some time now, but I've been holding off, only because I'm primarily developing web applications and I've heard from a few people that Rust is better suited for other tasks (based on the built-ins, packages, etc.?), despite there being at least a few frameworks out there.

What are your thoughts on this? Have things changed? Is the assumption just dead wrong, and Rust is in fact tremendous for web application development?

View on HN

I've been toying with a web app[1][2] using hyper[3] as for http connections and ws[4] for web socket connections. This was my first project using anything lower level than Javascript. I had a fairly good experience, my problems stemmed more from not knowing the least bit about memory management rather than lack of libraries. In fact the libraries that are already there tend to be very well documented, with lots of examples and explanations.

1: http://theremins.club

2: https://github.com/runarberg/theremins

3: https://crates.io/crates/hyper

4: https://crates.io/crates/ws

For production ready, out of the gate, little config, extensive ecosystem, Rust isn't quite there. It will take much more to get many of the things that other languages/frameworks/libraries already provide that are well tested and stable. But the community is progressing surprisingly fast, so I don't think it'll be long before enough of the helper libraries are well tested and stable that building a web server wouldn't be much more difficult than other options. For just a web server, depending on what you're doing, the benefits of using Rust compared to say Node or Go are still, IMO, not a big list YET. One big thing for me is the Rust types system.

I'm working on a new project now where my web server will be Node, however much of my api and micro services/jobs will be in Rust. I expect it to go well, we'll see.

I have historically been skeptical of Rust as an application-tier language, but my experiments with it as of late have made me reconsider a bit. The largest weakness, imho, is the lack of libraries for various standards and formats: do you really want to implement OAuth yourself? (EDIT: Apparently we do have OAuth now. ha!) The maturity of the Rails ecosystem has spoiled me.

Here's a random fact that I've always found interesting: https://crates.io/ uses Rust on the server. It links to libgit, it does a lot of stuff. It uses about 30 megs of memory, resident, at all times. Coming from Rails, that's... shocking.

I have witnessed someone implementing OAuth2 themselves: https://crates.io/crates/inth-oauth2 I hope they solved the problem permanently, since this is the third crate attempting OAuth2 and the first two are abandoned/incomplete.

I don't even know what a "complete" OAuth2 library would be. One that not only deals with the quirks of existing services that use OAuth2, but anticipates all future ones?

You can certainly try it out for web applications. It has shortcomings, but I assume that by "try Rust" you don't mean "immediately develop something for production"? :)

I have a deamon running that does a specific reverse proxy thing. I wrote it in Rust, and that has been a very pleasant experience. For example, the excellent support for serialization and deserialization makes working with JSON a breeze :)

Rust is immature in general. It will probably make a perfectly good language for web, comparable to e.g. OCaml, though the manual memory management is always going to add a little bit of overhead. IMO the web is a lot like anything else, and the best web languages are just the best general-purpose programming languages.

I haven't written a lot of Rust, but what manual memory management are you referring to? As far as I can tell, the whole point of the language is that you don't have to worry about that if you listen to the compiler.

You have to think about it. You don't have to worry about it.

This sounds like Rust propaganda! It's too slick...

it sounds slick, but for the first few hours you'll think that hell is a nicer place than here because the borrow checker won't be there. it takes a while for it to become slick again and only then you really start to appreciate the language. theory vs practive and all that.

It's sort of the opposite, it's that the compiler won't permit you to neglect any aspect of memory management until it deems your work passable. You think about memory management even more than you would in most languages. The result is you get some guarantees about correctness.

You may have to think about it, but you certainly aren't doing the work of e.g. writing malloc and free statements.

It'll get there simply because the language is doing pretty well and lots of people write web servers but it's not there yet. Once someone figures out "the way" to do an internet-facing async http/http2/websocket server I think we'll see a lot more motion in the Rust web dev space.

There is this reference site [1], though I have no personal experience so I am not sure if it is up-to-date.

[1] http://arewewebyet.com/

Edit: According to Steve Klabnik in his comment below, it is not up-to-date.

If not for Rust, would you write your app in C++ or Python/Ruby/JS?

Python (currently using), or Go.

Add JS to that list as well, because I've done a little bit of work in Node, but that was before Coroutines (back in the days of yore when "callback hell" was a thing), so I wasn't nearly as excited at the time as I probably would be now.

So no, Rust is not a good option :)

Try Elixir (https://elixir-lang.org). Phoenix framework is awesome and working with it is a pleasure.

Thanks. Elixir looks interesting. I'm apprehensive about the "runs on Erlang" part though (wary of compiles-to or runs-on languages, unless the "to" or "on" is C).

Actually Elixir and Erlang are totally interoperable with zero overhead. They both compile to BEAM virtual machine code. That "runs on Erlang" part is a selling point IMO.

You should become skeptical of languages that compile to C. I can't get into the details because I don't know them very well, but take a look a pcwalton's comment history for a fairly technical discussion of why it makes a poor compilation target.

Reply on news.ycombinator.com