Hacker News new | past | comments | ask | show | jobs | submit login
Rustful – A RESTful web framework for Rust (github.com/ogeon)
140 points by aethertap on Oct 15, 2014 | hide | past | favorite | 30 comments



Wow! I did not expect this. It's fantastic to see that people are actually interested in this project, so here comes the story of Rustful:

It all began at the beginning 2014. I had a university project where I should build some kind of website with a database and I wanted to build it in Rust. The problem what that there was no good frameworks out there and those who existed did not compile, so I decided to roll my own. I would just need the basic routing and request handling, so it wasn't hard. I played with some words and came up with the name Rustful (combination of Rust and RESTful, but you did probably guess that) and hated it, but my friends told me that it was a great name and I thought that, well, it's silly enough to actually work. It grew on me over time.

Anyway, time passed and I finished my project. I thought that I could keep developing Rustful and use it for my own website and so on. I thought that I should keep it small and simple and "out of the way", because I do personally get annoyed by things that tries to control my work flow too much. There is no "The Rustful Way (tm)" to do things and it shouldn't be.

Time kept passing, as usual, and other frameworks started to pop up and gain followers and users. Some, like Iron, had a whole team behind them and it became hard to keep up and, at the same time, complete my studies. This eventually lead to me putting the project on ice during the summer.

Fast forwards to this morning. I get a mail about someone asking what the difference between Iron and Rustful is and I think "why do people still keep linking to this thing?" and then I see the torrent of stars on Github. This is when I create my HN account to write this.

Now I'm thinking: "Is it time to revive Rustful?"


"Is it time to revive Rustful?"

Make it so.


Looks to be inspired heavily by Go's net/http package and its interfaces: http://golang.org/pkg/net/http/


Nah, I never looked at it. :)


Those are fighting words ;-) Just kidding. Great minds think alike.


This is really cool -- also, I'm curious why Ogeon built this. It seems eerily similarly to what reem is trying to accomplish with IronFramework.io and what the good people at Nickel.rs are doing as well. I'd love to hear if this is trying to accomplish a fundamentally different goal or if it was more of a learning project.


Just a quick note, Rustful has been around for longer than both of those projects. Rustful just hasn't had the same amount of press that the others have had.


b0b_d0e is right. You can read the whole story in my main comment, but in short: There were no good alternatives and I needed it.


With Rust's switch to 1:1 threading (soon to be not even optional AFAIK), how will this affect the concurrency capabilities of Rust-based web servers, and servers in general?


It will have the same problems as any other webserver utilizing blocking IO.

Various people are working on async IO solutions; but it likely won't fall into the stdlib from what I can tell.

I'm currently working on a rust abstraction for epoll and kqueue to eventually be paired with a multithreaded event loop/reactor. Lots of stuff to reimplement.


Is there a github repo or similar for what you're working on?


I found this... https://github.com/carllerche/mio

No windows support yet, but planned.


AFAIK green threads were removed from the core language but are available as crate green (also known as greenlib). You can use that for building servers.

http://doc.rust-lang.org/green/


*libgreen

They're gonna get yanked out of the core distribution too and won't be integrated in the stdlib IO anymore, so it's fair to say that Rust is switching to 1:1 threading.


Any reason why? I'd love to read some discussion about it.


Since both threading models were supported and compatible throughout IO, concurrency primitives and other runtime bits, the design of both was considered to be constrained too much to get either model where it should be.

The decision was made around https://github.com/rust-lang/rfcs/pull/230 but I'm not sure whether there's any important prior discussion not linked from there, the topic has been kicked around for a bit.


We talked about it at the last work week a lot https://github.com/rust-lang/meeting-minutes/blob/master/wor...


I only play with Rust because I'm a language junky, but I don't think Rust has been built so far with the intentions of being a great language for servers. It feels like a language targeted towards system engineering, which is a bit different than network engineering (which is where I would put web servers).

That said, with a 1:1 threading model, you can still build good abstractions for asynchronous I/O onto those threads. Erlang is kind of like this in that it spawns as many threads as you have cores (unless you tell it otherwise) and uses a thread for async I/O via epoll/kqueue.


I'm curious about how these web framework crates, like this and IronFramework.io, are dealing with the imminent obsoletion of rust-http. It seems rather strange to build a completely new web framework on rust-http when it will soon be completely replaced with teepee.


There's more out there than rust-http and Teepee. For example, the Cargo registry is using Rust bindings to Civet...

(That said, yes, it would be bad to build on top of a deprecated library. This library isn't new though, it's older than the Teepee announcement.)


There's also hyper (https://github.com/hyperium/hyper), a native Rust HTTP implementation I am working on.


This is the type of thing that will make me want to try Rust. Just glancing over the code this looks fairly clean and simple, and could be a good foundation moving forward.

Nice work!


You should checkout IronFramework.io and nickel.rs. They are both a little farther along and try to do something similar to ExpressJS.


http://ironframework.io/ and http://nickel.rs/ for anyone not wanting to search and then find the links.


Which is more feature rich and/or mature? They both seem really interesting and I've been enjoying Rust a lot.


After playing with them both I'd say at this stage they are very close. I ended up going with Nickel because it felt more comfortable. Both are actively worked on, I'd suggest writing a quick prototype in both and seeing which you prefer.


I see. I'll give them both a try, Rustful looks interesting but very new and immature. I need to read through the docs for Nickel and Iron because they both look great and make some test apps. I'm coming from the Django/Flask world and I've really taken an interest in Rust.


This looks great. Now all I need is a database abstraction layer, any recommendations?


Checkout Rust Postgres: https://github.com/sfackler/rust-postgres

That's what the community is focused on.


Is Rust Postgres async?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: