Live data from Hacker News

Rocket, Rust Web Framework, v0.3: Fairings, TLS, Private Cookies

rocket.rs

41–50 of 75 posts

Re: Rocket, Rust Web Framework, v0.3: Fairings, TLS, Private Cookies

#41
post #40

Earlier quoted context omitted.

arewewebyet hasn't been updated since March, and there's been some big developments since then. Those probably are the two most popular, but there's a Cambrian Explosion going on right now, with new frameworks like Susanoo and Cargonauts appearing on the regular. Heck, I even have my own little half-baked one.

This is actually driving me a bit insane trying to do anything more than the simplest Rust samples. There are... a lot of competing libraries implementing the same concepts. Input validators, crypto, tls, http (there are I believe at least 3 http/2 implementations, and hyper doesn't even support it yet) and pretty much every concept under the sun (hell, hyper has its own implementation of a url type independent from…

Yup, that's what early ecosystems are like! It'll settle down eventually.

Re: Rocket, Rust Web Framework, v0.3: Fairings, TLS, Private Cookies

#42
post #33

It's really a shame they haven't jumped on tokio yet. Then again, I tried to look at the code, and it didn't seem to be a simple dropin thing to move over to tokio.

Rocket might have an easier time doing async than, for example, Python. You get 90% of the benefit from only having the async internal - you can make all the route handlers async without needing the user to do anything else, and even if the occasional route is blocked by io you can just generate a ton of threads. It still means the "average" use case of static page returns or fast redis access will be able to handle a ton more requests.

Even going all the way, I don't see much more of an issue than just exposing a handle to routes to do async IO with if they want to and making the internal async core available to fairings and other code from main().

Internally it would probably be a big mess right now, though.

Re: Rocket, Rust Web Framework, v0.3: Fairings, TLS, Private Cookies

#43

I don't have any experience in Rust. From what I read, Rust is a low level / system programming language. Comparing to dynamic languages like Python, I understand that Rust is much faster. However, Python is fast enough for most web applications. So why should I use Rust in web development? Even if the library ecosystem were mature enough, could I expect my productivity could become nearly high as in Python?

It takes longer to get the code to compile, but once it does the integration pains and debugging needed will be significantly less. I'd absolutely argue that productivity can be higher in Rust, especially the larger the project is, or the longer you expect to support it for.

A lot of what people miss when approaching Rust is that writing libraries is really hard and time consuming, but writing applications using libraries is often as easy as Python. Libraries need to provide abstractions, and thus use really complex features like code generation macros, trait extension, generics, type conversion, and the annoying lifetimes that most people beat their heads on when first learning Rust. Rust for an application developer feels almost entirely OOP, like Java, and much nicer than C++ because simple data structures don't hit undefined behavior every other line with the other half being full of memory leaks.

Re: Rocket, Rust Web Framework, v0.3: Fairings, TLS, Private Cookies

#44

Since its async, do you have to develop in it using callbacks?

Unlike with Python and similar single-threaded languages you can actually avoid a lot of the complexity of having async everywhere by using the CpuPool reactor for Rust futures.

I imagine Rocket, when it gets its async support, will have the ability to use callbacks to create fully async routes, but the halfway compromise until then will be to have async-dispatched routes that are themselves blocking to a very large threadpool. As long as you have enough generated threads to rarely get all of them stuck in blocking IO you get all the benefits of concurrency without having to callback every IO operation in a route handler.

Re: Rocket, Rust Web Framework, v0.3: Fairings, TLS, Private Cookies

#45
post #14

I actually really love the restrictions on fairings. I'm working on a project right now that uses Node.js with Express, and there are all of these pieces of middleware that won't compose at all, and I often find myself ripping things out and putting them in new functions. By having clear delineations between fairings, request guards, and data guards, I think you can really avoid making a lot of design mistakes. I'm g…

Rust Stable is great, but not all of the macro (the Macro 2.0 stuff) support is on the stable release channel yet. There are still some things you can't do on stable (or can do, but inconveniently). (Rocket also depends on a few other nightly only features. Things will likely change in the future once the Macro stuff stabilizes though) There is also the matter of compiler plugins... which may never land in stable.

Syntax extension plugins are probably going to happen, folks are working on it.

Re: Rocket, Rust Web Framework, v0.3: Fairings, TLS, Private Cookies

#46

I don't have any experience in Rust. From what I read, Rust is a low level / system programming language. Comparing to dynamic languages like Python, I understand that Rust is much faster. However, Python is fast enough for most web applications. So why should I use Rust in web development? Even if the library ecosystem were mature enough, could I expect my productivity could become nearly high as in Python?

Rust doesn't have a stable/mature HTTP implementation/abstraction yet.

Hyper is pretty darn good and I haven't seen issues with it not being mature.

Re: Rocket, Rust Web Framework, v0.3: Fairings, TLS, Private Cookies

#47
post #38

I'm a Rocket fan and glad to see this big slate of improvements. On the other hand, I do want to register a bit of concern regarding the plan to add "first-class database support" for 0.4. I hope that doesn't result in a close coupling to any particular database, or to using a database in general.

Isn't Postgres worth coupling to? SQLite is a close favorite, for different reasons.

Re: Rocket, Rust Web Framework, v0.3: Fairings, TLS, Private Cookies

#48
post #23
post #20

Earlier quoted context omitted.

I'd say it's true that Python is fast enough for most web servers. Rather than strictly considering performance, I'd guess that people seeking to do webdev in Rust are looking to leverage Rust's static analysis to improve resilience, trading off up-front productivity for long-term maintainability (which isn't to denigrate Python, which I love, but fearless refactoring really is something that compiled langs excel at)…

We also shouldn't discount it just because Python is usually fast enough (all my personal projects are in Python). Developer time is cheaper than hardware 99% of the time. For the 1% that are running millions of requests per second through their web stacks the value proposition is pretty compelling.

> Developer time is cheaper than hardware 99% of the time.

I find the exact opposite to be true in most cases.

Re: Rocket, Rust Web Framework, v0.3: Fairings, TLS, Private Cookies

#49
post #38

I'm a Rocket fan and glad to see this big slate of improvements. On the other hand, I do want to register a bit of concern regarding the plan to add "first-class database support" for 0.4. I hope that doesn't result in a close coupling to any particular database, or to using a database in general.

Isn't Postgres worth coupling to? SQLite is a close favorite, for different reasons.

As someone who only uses Postgres and SQLite: No. It's not.

People inevitably have to deal with preexisting systems they can't modify for their needs.

Re: Rocket, Rust Web Framework, v0.3: Fairings, TLS, Private Cookies

#50
post #48
post #23

Earlier quoted context omitted.

We also shouldn't discount it just because Python is usually fast enough (all my personal projects are in Python). Developer time is cheaper than hardware 99% of the time. For the 1% that are running millions of requests per second through their web stacks the value proposition is pretty compelling.

> Developer time is cheaper than hardware 99% of the time. I find the exact opposite to be true in most cases.

In bare metal deployments or cloud? If the latter, then moving to the former seems like an obvious choice.
Post reply on HN