Rustful – A RESTful web framework for Rust
github.com
github.com
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?"
Make it so.
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.
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.
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.
No windows support yet, but planned.
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.
(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.)
Nice work!
That's what the community is focused on.