5 ms·

you may want to have a look at Rocket https://rocket.rs/ https://rocket.rs/, you won't be disappointed

coder543 8y ago
Rocket requires the nightly Rust compiler, which isn't something I find acceptable for production applications, and it's synchronous, so it's really slow. I have been rather disappointed by what I perceive as the author's unwillingness to work towards stable Rust. They have a GitHub issue where they track all of their dependencies on nightly, and kind of just say they aren't going to do anything about it -- it's up to the Rust core team to just make all the things stable that Rocket is using, or else it will stay on nightly forever. 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.
- staticassertion 8y ago
  > which isn't something I find acceptable for production applications 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.
  - coder543 8y ago
    That was definitely true before Rust 1.15, but it becomes even less beneficial with each new stable release. 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.
- Spartan-S63 8y ago
  It's not that he's unwilling to make it run on stable, it's that he has to sacrifice ergonomics to make it run on stable. Despite it not being async, yet, Rocket is my go-to because it has the best ergonomics. Something like actix-web may be more performant, but it's ergonomics are poor in comparison. 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.
  - coder543 8y ago
    > It's not that he's unwilling to make it run on stable, it's that he has to sacrifice ergonomics to make it run on stable. 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-template-support-e0bb8ed47941 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://actix.rs/docs/extractors/#json
  - foldr 8y ago
    Is Rocket still on track to run on stable by the end of 2018, as per your comment here? https://news.ycombinator.com/item?id=16543914 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.
- charliesome 8y ago
  > and it's synchronous, so it's really slow. > it's asynchronous (so it's really fast) Whether something is 'synchronous' or 'asynchronous' has absolutely no bearing on performance.
  - coder543 8y ago
    I don't understand the point you're trying to make. In networked stuff, the (a)synchronicity absolutely does make something fast or slow. 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.
    - charliesome 8y ago
      All network I/O is inherently asynchronous of course, so the sync vs async debate is more about whether to use the blocking abstraction the kernel provides versus bringing your own or writing async code directly. 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.

Rocket requires the nightly Rust compiler, which isn't something I find acceptable for production applications, and it's synchronous, so it's really slow. I have been rather disappointed by what I perceive as the author's unwillingness to work towards stable Rust. They have a GitHub issue where they track all of their dependencies on nightly, and kind of just say they aren't going to do anything about it -- it's up to the Rust core team to just make all the things stable that Rocket is using, or else it will stay on nightly forever. 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.

staticassertion 8y ago
> which isn't something I find acceptable for production applications 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.
- coder543 8y ago
  That was definitely true before Rust 1.15, but it becomes even less beneficial with each new stable release. 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.
Spartan-S63 8y ago
It's not that he's unwilling to make it run on stable, it's that he has to sacrifice ergonomics to make it run on stable. Despite it not being async, yet, Rocket is my go-to because it has the best ergonomics. Something like actix-web may be more performant, but it's ergonomics are poor in comparison. 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.
- coder543 8y ago
  > It's not that he's unwilling to make it run on stable, it's that he has to sacrifice ergonomics to make it run on stable. 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-template-support-e0bb8ed47941 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://actix.rs/docs/extractors/#json
- foldr 8y ago
  Is Rocket still on track to run on stable by the end of 2018, as per your comment here? https://news.ycombinator.com/item?id=16543914 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.
charliesome 8y ago
> and it's synchronous, so it's really slow. > it's asynchronous (so it's really fast) Whether something is 'synchronous' or 'asynchronous' has absolutely no bearing on performance.
- coder543 8y ago
  I don't understand the point you're trying to make. In networked stuff, the (a)synchronicity absolutely does make something fast or slow. 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.
  - charliesome 8y ago
    All network I/O is inherently asynchronous of course, so the sync vs async debate is more about whether to use the blocking abstraction the kernel provides versus bringing your own or writing async code directly. 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.