you may want to have a look at Rocket https://rocket.rs/, you won't be disappointed
Rocket's biggest feature is their flashy website, in my opinion. Their website is really nice looking and the self-assured marketing is convincing to readers.
Actix-Web seems like a more mature framework (I don't expect my application to randomly break), it's asynchronous (so it's really fast) and it works on stable Rust. Warp and Tower Web look like promising async frameworks, but they're not very mature yet. Rouille is a pretty stable option for a simple, synchronous web framework.
For what it's worth, at least some of the largest rust adopters just pin to a nightly version, and don't have a ton of issues upgrading.
I work for one such prominent early adopter of Rust, and we were very happy to move to stable sometime back. Stable versions are widely used, so issues are much more likely to be noticed, and fixes are backported to the current stable release.
If you pick a random nightly version, you have much less support to begin with simply because fewer people use it, and you're on nightly because you're dependent on features that haven't been as thoroughly tested as those features that exist on stable, and which could disappear entirely in the next nightly. Each time you upgrade to a different nightly increases the risk of introducing some hard-to-find bug into production.
Some companies do use nightly Rust in production. You're completely correct. It's just not something that I would personally be willing to do unless I had absolutely no reasonable alternative.
Regardless, Rust is stabilizing procedural macros which just leaves the never type as the last stabilization required for Rocket to be able to run on stable Rust. Additionally, I believe their next release is targeting the rewrite to async. A lot of it has to do with Rust firming up its own story around async.
Two sides of the same coin. I clearly disagree about the amount of ergonomics that would have to be "sacrificed" in order to make the library usable in a production environment (on stable). So, it's simply an unwillingness to bring the library to stable, from my point of view.
Take Tower Web for example: https://medium.com/@carllerche/tower-web-0-3-async-await-and...
This has very similar ergonomics to Rocket in that it allows decorating handlers with their route, but it runs on Stable Rust. If you want to use `async fn`, that requires nightly for now since that's literally the nightly syntax for an async function, but the route decorators work on stable. As I previously mentioned, Tower Web is not mature, so I would not recommend it at this stage, but it shows what is possible.
I don't personally think that decorating handlers with routes is significantly more ergonomic than defining a table of contents somewhere else, like Actix does it. Defining routes is usually a very small part of your code that you do once and move on. Beyond that, what ergonomics are we talking about?
Actix can easily and automatically deserialize JSON into structs, for example: https://actix.rs/docs/extractors/#json
https://news.ycombinator.com/item?id=16543914
Anecdotally, I've been hearing claims that Rocket will run on stable "real soon now" for quite a while now. It just doesn't look like it's going to happen.
Never type can use a crate. The hygiene and error APIs aren’t going to be stable soon.
In theory it looks like rocket could use that package and accept worse error messages and build on stable. Sergio would have to weigh in on that, though, I could be wrong.
> it's asynchronous (so it's really fast)
Whether something is 'synchronous' or 'asynchronous' has absolutely no bearing on performance.
Suppose you have a synchronous web server with 4 threads, synchronous naturally means that each thread can only handle one request at a time. Each request can take dozens or hundreds of milliseconds to complete, just by being bottlenecked on latency. If it takes 100ms to complete each request, that server can only handle 40 requests per second.
If that server were asynchronous, each thread could handle thousands of simultaneous connections, making the performance literally thousands of times better at a minimum.
If you suggest spinning up an unlimited number of OS threads, that's quickly going to run into problems because most OSes can only handle a couple of thousand threads before you start running into OS limits that you have to adjust, knobs for which aren't always easy to find, and even then, each thread takes a significant amount of time to start and stop, as well as much larger amounts of RAM.
An alternative solution is green threading, which Go calls Goroutines, for example. In such a system, the asynchronous operations are handled by the underlying runtime and your code can treat them as synchronous and just spawn new "threads".
If you disagree, I would love to hear a more detailed response, because I can't see how your claim could be true.
Using async I/O or a userland abstraction like green threads necessarily means you're moving the I/O scheduling work into userland. Sometimes this might be the right call, but it's effectively a bet that your userland scheduler can do a better job than the kernel's own scheduler.
This bet might pay off in highly specialised cases where your userland scheduler is well tuned to your workload, but the majority of userland schedulers (to name a few examples: the Go runtime, node.js's libuv) are also aimed at general purpose workloads and in many cases are far less mature than the kernel's scheduler.
There's been a massive amount of engineering work that's gone into the Linux kernel's various scheduling algorithms over the years. Pathological edge cases resulting in starvation or other performance issues have largely been identified and worked out. The various schedulers are also highly tuneable to the specifics of your workload if you need to do that.
These days OS threads are a totally viable option for building highly concurrent network services on Linux. Spawning hundreds of thousands of threads works fine and is fast enough for most applications. While threads will have 8MB of virtual address space reserved for their stack by default, this is just 'on paper' memory use - no pages are actually allocated until you use them.
I don't agree. If you're at the point where you need to handle such large numbers of concurrent threads, my own experience and online benchmarks clearly show it is not fast enough. Why are none of the top performers on the TechEmpower benchmark using a thread per connection? The simplest answer is that that can't or they would, since it would be a waste of time to reimplement so much in userland.
More anecdotally, I have been unable to get my Fedora laptop to spawn more than a few tens of thousands of threads before the kernel tells everyone that "resource is temporarily unavailable" to any process that attempts to spawn a new thread or process until the offending process is stopped. I've googled the issue extensively, tweaked countless knobs, and come up empty handed. I'm certain the Linux kernel can spawn more threads than that, but my point still stands that it is nontrivial.
In theory, that's a great perspective you presented. However, the async interfaces into the kernel exist for very real reasons.
I would also challenge you (if you're bored) to write a C, C++, or Rust program that spawns 1 or 2 million threads that do nothing but sleep for a very long time, and write a similar program in Go. See how the two compare in how long it takes to launch all of the tasks, and see how much memory they use. Ideally, you would also use, say, Rust futures + tokio and spawn a million sleeping futures to compare there too, but futures and tokio aren't the most intuitive or well documented things yet, in my opinion.
I've done similar tests in the past, and OS threads are not a lightweight resource.