Is Rust Ready for the Web Yet? (2020)(blog.devgenius.io)
blog.devgenius.io
Is Rust Ready for the Web Yet? (2020)
https://blog.devgenius.io/is-rust-ready-for-the-web-yet-9ec38c01dcaf
68 comments
I am a longtime django user my self(since v0.95) and rocket comes pretty close to it.
In terms of database and framework design there are several Rust libraries that come close. Diesel for database and migrations and something like Rocket for the backend itself should be enough for a quick JSON API or Thymeleaf based page renderer.
Auto generated admin stuff is pretty rare in anything outside Django I think, though I don't see why one couldn't make those for Rust. I suppose most devs would probably want their CRUD APIs to function on their own and use those for management if performance is critical enough that you'd prefer Rust over something like dotnet or Java.
Auto generated admin stuff is pretty rare in anything outside Django I think, though I don't see why one couldn't make those for Rust. I suppose most devs would probably want their CRUD APIs to function on their own and use those for management if performance is critical enough that you'd prefer Rust over something like dotnet or Java.
> Auto generated admin stuff is pretty rare in anything outside Django I think
Just wanted to say that anywhere from Ruby on Rails, to Laravel, to Yii, to... Pretty much every major web framework in the most common language used for web dev (php, python, ruby) has a builtin admin (among tons of other stuff).
Edit:
> Diesel
Diesel doesn't come close to where the ORMs of Django or RoR stand. Not by chance. Having to write by hand SQL (according to Diesel's docs) is something that modern web frameworks solved years ago. And I'm not even talking about automatic mapping of models to tables, automatic migrations, etc... Diesel is simply not anywhere near what a web dev would expect. Not saying that Diesel is bad, just that it's not in the same category where current ORMs stand.
Just wanted to say that anywhere from Ruby on Rails, to Laravel, to Yii, to... Pretty much every major web framework in the most common language used for web dev (php, python, ruby) has a builtin admin (among tons of other stuff).
Edit:
> Diesel
Diesel doesn't come close to where the ORMs of Django or RoR stand. Not by chance. Having to write by hand SQL (according to Diesel's docs) is something that modern web frameworks solved years ago. And I'm not even talking about automatic mapping of models to tables, automatic migrations, etc... Diesel is simply not anywhere near what a web dev would expect. Not saying that Diesel is bad, just that it's not in the same category where current ORMs stand.
It’s really not that close IMO. Diesel is more analogous to SQLAlchemy. It doesn’t have the nice distinguishing features of the Django ORM like model-based schema generation and auto-generated migrations; it’s on you to ensure your struct lines up with the DB table, and you have to write the SQL for up/down migrations by hand.
The API layer options I have seen are more like Flask rather than generating full APIs from the model schema.
I’d love for this to be the case but Rust is not close to having a Django yet. Part of the problem is that structs are very inflexible; there is no equivalent of the metaclass manipulation that Django does.
You could perhaps build something equivalent with macros? But there is lots of syntactic sugar in Python like descriptors that let you generate really clean class-level APIs.
The API layer options I have seen are more like Flask rather than generating full APIs from the model schema.
I’d love for this to be the case but Rust is not close to having a Django yet. Part of the problem is that structs are very inflexible; there is no equivalent of the metaclass manipulation that Django does.
You could perhaps build something equivalent with macros? But there is lots of syntactic sugar in Python like descriptors that let you generate really clean class-level APIs.
Rust database and migration story is really not that nice yet. SQLx is nice for pure SQL but doesn't have a good query builder story yet. Diesel is very clunky in comparison to Django ORM as soon as you get to anything beyond basic. Migrations are even less polished.
And in my experience going from Django to anything in Rust will be at least 10 times the boilerplate and some things will be very very annoying to handle, especially things like sharing parts of model, automating things like creation / update metadata for all models, and even sharing authentication mechanism for most routes can be annoying depending on the way you have to do authentication (in my case Firebase auth so authenticating sometimes does require making async calls... And that's a trouble).
And in my experience going from Django to anything in Rust will be at least 10 times the boilerplate and some things will be very very annoying to handle, especially things like sharing parts of model, automating things like creation / update metadata for all models, and even sharing authentication mechanism for most routes can be annoying depending on the way you have to do authentication (in my case Firebase auth so authenticating sometimes does require making async calls... And that's a trouble).
We run https://FakeYou.com on Rust/Actix/sqlx, and I'm not missing the "batteries included" anymore. The type safety alone makes Python and Ruby a thing of the past for us. The tests being easy to refactor is really nice too.
Both sqlx and diesel have DB migrations. We use them. Sqlx is actually type checked too, which is awesome.
There are plenty of 3rd party auth and email packages (though we didn't use any, so I can't attest to them). It was quick enough to grow our own internal stuff, which we now reuse internally.
Rust is fantastic for working with audio or video on the server. We're starting work on rendering 3D workloads headlessly.
Another thing Rust can do that Python can't dream of - our servers have easy to manage background threads! We can launch async processes or have long-running background processes (infinite loops with periodic sleeps) that update singletons (Arc<Lock<T>>) of important caches, which is way faster and more durable than Redis in certain cases. Actix makes these a breeze to work with.
Both sqlx and diesel have DB migrations. We use them. Sqlx is actually type checked too, which is awesome.
There are plenty of 3rd party auth and email packages (though we didn't use any, so I can't attest to them). It was quick enough to grow our own internal stuff, which we now reuse internally.
Rust is fantastic for working with audio or video on the server. We're starting work on rendering 3D workloads headlessly.
Another thing Rust can do that Python can't dream of - our servers have easy to manage background threads! We can launch async processes or have long-running background processes (infinite loops with periodic sleeps) that update singletons (Arc<Lock<T>>) of important caches, which is way faster and more durable than Redis in certain cases. Actix makes these a breeze to work with.
Not to take anything from Rust, but there are decent web frameworks that are fully type safe (modern ASP.NET is my favorite, although it's not the only one), with a fully-fledged ORM (build up some experience with LINQ and you'll be missing it on every other platform), background worker threads, etc. So there is middle ground for those unwilling to try Rust yet.
Eh, HTTP with Rust is as fun as HTTP with C++. In both cases, there's people that swear they're very productive with it.
I'm building an app powered by Rust, and I love it, but I'd rather use Elixir for the Web facing part.
Perhaps when the whole async thing is more ergonomic I'll reconsider, but there is no chance any Rust framework can be as nice as any language running on the BEAM (or PHP, or Python, or Ruby, or Go, or Lisp), especially not as nice as Elixir can be as a website backend.
Use the right tool for the job.
I'm building an app powered by Rust, and I love it, but I'd rather use Elixir for the Web facing part.
Perhaps when the whole async thing is more ergonomic I'll reconsider, but there is no chance any Rust framework can be as nice as any language running on the BEAM (or PHP, or Python, or Ruby, or Go, or Lisp), especially not as nice as Elixir can be as a website backend.
Use the right tool for the job.
Lunatic runtime for Rust to avoid the async parts might become quite nice in the future: https://github.com/lunatic-solutions/submillisecond
Not sure what it might take for someone to write database connectors for it but it does look promising.
Not sure what it might take for someone to write database connectors for it but it does look promising.
Looks nice. But I'm not sure why the router needs to be a macro.
What's wrong with
What's wrong with
router.get("/foo", |req, res| -> Response {
...
});Sorry, a better link would have been https://lunatic.solutions/blog/rust-without-the-async-hard-p...
Just wanted to comment on the async part that interesting solutions are being developed.
I'm curious, are there any specific parts of the stack that make backend dev harder for you? My experience with async Rust on the backend is that it doesn't really slow me down too much, cause most of the problems are not really relevant there. Functions handling requests are usually of a form: get request data, fetch sth from the database, return a response. In this context you don't really need to care too much about async, lifetimes, ownership etc.
Yes, it's ready. Read Zero To Production In Rust by Luca Palmieri for best practices: https://www.zero2prod.com/
[deleted]
Are there really that many use cases in web development where you absolutely can not live with just using a language with automatic garbage collection?
I can see maybe using Rust for some performance critical parts but for the daily CRUD or API? I don't get how you could justify using it. (In a professional context that is, if it's just for fun, go ahead, of course.)
There are so many amazing backend-languages with huge ecosystems be it Elixir, PHP, Golang, Node or whatever you favorite poison may be. You would miss out on so much productivity.
Rust is amazing but it solves a very specific problem while most of the software world is better off using garbage collected languages.
I can see maybe using Rust for some performance critical parts but for the daily CRUD or API? I don't get how you could justify using it. (In a professional context that is, if it's just for fun, go ahead, of course.)
There are so many amazing backend-languages with huge ecosystems be it Elixir, PHP, Golang, Node or whatever you favorite poison may be. You would miss out on so much productivity.
Rust is amazing but it solves a very specific problem while most of the software world is better off using garbage collected languages.
I've built 2 production sites so far in rust and documented it here https://rust-on-nails.com/
Wow, that looks really extensive. Great work!
Yes Rust is ready for the web. Here's a brief intro about how to use Rust for the web with Axum, Tower, Hyper, Tokio, and Serde.
https://github.com/joelparkerhenderson/demo-rust-axum
https://github.com/joelparkerhenderson/demo-rust-axum
Recently I wrote a simple forest fire simulation to test out using egui in WASM. I was impressed by how simple it was to get up and running.
https://maxbondabe.github.io/forest-fire
https://maxbondabe.github.io/forest-fire
This is not backend related though, WASM is just a binary that can be executed by the browser.
missing the most important part. the underbrush.
Yeah for sure, the goal was to learn egui and validate it's portability. The logic is largely lifted from the NetLogo model library (https://ccl.northwestern.edu/netlogo/models/Fire) and represents only the relationship with density and how far a fire is able to spread. I added a couple variations for fun (like using Perlin noise).
My larger concern is whether it is time efficient. Rust seems quite low level.
It's no coincidence that web is full of bloated frameworks - because the emphasis is on cranking out yet another generic page not optimising things to within an inch of its life.
It's no coincidence that web is full of bloated frameworks - because the emphasis is on cranking out yet another generic page not optimising things to within an inch of its life.
Rust is pretty much the only language that runs well on all of front-end, back-end, iOS, Android, Windows & MacOS, with decent UI bindings.
Javascript is the only real competition, but the needed shims are lossy at times.
C++ is the closest, but Dioxus and Cacao are nicer than anything in the C++ ecosystem AFAICT.
It's perhaps not the ideal language for any of those, but there's substantial benefit to having your whole team in the same ecosystem.
Javascript is the only real competition, but the needed shims are lossy at times.
C++ is the closest, but Dioxus and Cacao are nicer than anything in the C++ ecosystem AFAICT.
It's perhaps not the ideal language for any of those, but there's substantial benefit to having your whole team in the same ecosystem.
How does rust run on the front-end? Or is this the compile to wasm thing?
Java?
Do Java applets even work on the modern web?
I don't think so, but there're solutions for Java to JS transpiling.
Runs well in a browser, with ergonomic integration with HTML, CSS, and other browser APIs?
Yes. It's new enough that you will find a bug or two, but it's about as closely integrated as Javascript.
Yes, check out Dioxus, which is essentially React for Rust, and is faster than react at many tasks.
QT is still far ahead.
This isn't a dig on Rust, but wherever Rust runs, so does C++. There are a lot of dimensions where Rust is better, but definitely not "runs everywhere" and "ecosystem".
This isn't a dig on Rust, but wherever Rust runs, so does C++. There are a lot of dimensions where Rust is better, but definitely not "runs everywhere" and "ecosystem".
Compare this demo: https://www.qt.io/web-assembly-example-pizza-shop?hsCtaTrack...
with this demo: https://github.com/DioxusLabs/example-projects/tree/master/e...
QT is unusably slow. Dioxus is indistinguishable from a Javascript app.
with this demo: https://github.com/DioxusLabs/example-projects/tree/master/e...
QT is unusably slow. Dioxus is indistinguishable from a Javascript app.
My main gripe with QT is that apps created with it are, as a rule, ugly and non-native feeling.
My suspicion is that this is because QT widgets sort of look like native widgets but aren’t quite there, causing it to fall into some kind of “uncanny valley” analogue.
My suspicion is that this is because QT widgets sort of look like native widgets but aren’t quite there, causing it to fall into some kind of “uncanny valley” analogue.
From my experience, the same is true for most Rust frameworks. In fact, I don't think there's a single stable Rust GUI library that tries to accommodate system controls.
You can use the win32 API on Windows and Gtk on GNOME, but for KDE and all else you'll need to use some kind of Qt wrapper that has the problems you encounter.
You can use the win32 API on Windows and Gtk on GNOME, but for KDE and all else you'll need to use some kind of Qt wrapper that has the problems you encounter.
IME your rust apps should use native frameworks. Cacao for iOS, Dioxus for web, etc.
C++ does not run as well on the browser.
Yes, QT on the desktop is very good. There are bindings for Rust too, as there are for most languages, but the most integrated one is C++. (I'd say the close integration is just not worth it.)
Anyway, I don't know why people want so badly a single language to run on every context. They are forfeiting a lot of value for that.
Yes, QT on the desktop is very good. There are bindings for Rust too, as there are for most languages, but the most integrated one is C++. (I'd say the close integration is just not worth it.)
Anyway, I don't know why people want so badly a single language to run on every context. They are forfeiting a lot of value for that.
With all due respect does anyone else find Rust's syntax just horrible?
#[get("/")]
#[actix_web::main]
std::io::Result<()>
HttpResponse::Ok().body("Hello world!")
Rust's syntax took me a long time to get used to, and was sort of dazzling and difficult to read at first. Lifetimes and generics were especially difficult, it just looked like a jumbled mess to me.
There's (at least) three things going on in the snippet you posted. One is that actix, like most (all?) Rust frameworks, is macro based; that code would look pretty similar if it were written in Flask, but with different syntax.
Another is that the strict type system can lead to some heavy verbosity, eg having to populate the generic in `std::io::Result<()>` with unit (`()`) just to say you're not returning anything.
Regarding `HttpResponse::Ok().body("Hello world!")`, the builder pattern is also pretty verbose and some people don't like it, but it's friendly to the type system and you can use it to provide really cool guarantees (like not being able to call `build()` until you've fully populated the builder).
Generally I'm of the mind that computers should conform to the needs of people and not the other way around, but programming language are a place where I'm willing to make many concessions, since as a rule humans are smarter than compilers.
There's (at least) three things going on in the snippet you posted. One is that actix, like most (all?) Rust frameworks, is macro based; that code would look pretty similar if it were written in Flask, but with different syntax.
Another is that the strict type system can lead to some heavy verbosity, eg having to populate the generic in `std::io::Result<()>` with unit (`()`) just to say you're not returning anything.
Regarding `HttpResponse::Ok().body("Hello world!")`, the builder pattern is also pretty verbose and some people don't like it, but it's friendly to the type system and you can use it to provide really cool guarantees (like not being able to call `build()` until you've fully populated the builder).
Generally I'm of the mind that computers should conform to the needs of people and not the other way around, but programming language are a place where I'm willing to make many concessions, since as a rule humans are smarter than compilers.
As a sidenote to your sidenote: I've noticed that the term "syntax" seems to have two different meanings nowadays. There's the technical meaning, namely "the rules that govern how characters are parsed into abstract syntax tree nodes", which in your example, would cover whether Rust shoud use `.` or `::` as a namespace separator, whether to use `[]` or `<>` for generics, that sort of thing. (Both of which have trade-offs in constraining how other parts of the language can be designed.)
But I think sometimes, people use "syntax" in a blanket "how the language looks" way — that is, whether it's symbol-heavy, whether it's word-based, whether it's information-light or information-dense, and so on. This makes it more a function of which features of expressivity the language chooses to expose, than the individual syntactic choices that determine which characters we use and for what. Again in Rust's case, it has attributes, it has namespace separators, it has the zero-tuple, it has generics, and it has lifetimes, all of which need some way to be expressed.
Don't get me wrong, you're allowed to not use a language if you don't like the way it looks visually. Or maybe it makes good use of a certain character that's hard to type on your particular keyboard layout. That's fine. I also can't decree that either of these uses of the term "syntax" are wrong. But when we're talking about language syntax, it's important to remember when you're talking about syntax, and when you're instead talking about language features. If you don't like the way lifetimes look, that's one thing; if you don't like the way lifetimes make you change the way you write code, that's another.
So I have to ask: of those four code snippets, how would you prefer to write them? What would you change? And can you get away with making those changes without breaking anything else?
But I think sometimes, people use "syntax" in a blanket "how the language looks" way — that is, whether it's symbol-heavy, whether it's word-based, whether it's information-light or information-dense, and so on. This makes it more a function of which features of expressivity the language chooses to expose, than the individual syntactic choices that determine which characters we use and for what. Again in Rust's case, it has attributes, it has namespace separators, it has the zero-tuple, it has generics, and it has lifetimes, all of which need some way to be expressed.
Don't get me wrong, you're allowed to not use a language if you don't like the way it looks visually. Or maybe it makes good use of a certain character that's hard to type on your particular keyboard layout. That's fine. I also can't decree that either of these uses of the term "syntax" are wrong. But when we're talking about language syntax, it's important to remember when you're talking about syntax, and when you're instead talking about language features. If you don't like the way lifetimes look, that's one thing; if you don't like the way lifetimes make you change the way you write code, that's another.
So I have to ask: of those four code snippets, how would you prefer to write them? What would you change? And can you get away with making those changes without breaking anything else?
I have no idea how/why Rust works/looks the way it does. Never used it beyond a hello world. I just know it's syntax looks horrible to me. I can already imagine my pinky going sore typing all those characters.
Rust syntax is fine. Actix with its pervasive use of macros, ain't.
Rust is verbose, but here you don't need to build response, just return string and Actix will handle that.
[deleted]
Also see: https://www.arewewebyet.org/
Is there a meta website for all the "are we X yet" about rust?
On Mozilla's wiki: https://wiki.mozilla.org/Areweyet
There's a http://arewemetayet.com
I believe you mean, "Are we meta website yet?"
It sounds like you've found your weekend project ;)
Maybe not with Actix, but certainly with axum: https://github.com/tokio-rs/axum
Salvo is also great: https://salvo.rs
Salvo is also great: https://salvo.rs
This is just a bad article. Yes it is ready and it's been for at least 2 years, we are building Caido (https://caido.io) entirely on rust from our proxy to the cloud backend and it is great. We use actix-web, diesel(proxy) / sea-orm(cloud), async-graphql. I don't want to go back to dynamically typed languages and no it's not like C++. It's a "Flask" level if you want a comparison but I absolutely hate Django (all frameworks really) so it is fine by me.
I've built all my web backends in either Flask or Django - what are the selling points/advantages of using Rust vs. Python in this context? Certainly not arguing against it but am very curious and unfamiliar with Rust. If anyone has moved from Python to Rust for this kind of work, can you speak on your experiences with doing so?
I have a very limited experience with Python (3 months of production experience), but vast Ruby experience and I think a lot of the things apply to both. For me these are reasons why I would choose Rust over Python or Ruby in most cases:
* it's relatively easy to write code that will pretty much never crash. yes, Rust will not prevent all of the bugs, but it will prevent almost all of the things that end up as a runtime exception in dynamic languages. So ou will not end up with an error tracker full of errors
* refactoring is so much easier in Rust - I can enter a new project, change a bunch of stuff and after I fix compile errors and tests my confidence that I didn't break anything is like 10 times higher than in Ruby or Python
* while most of the time speed is not a major concern for backend development, it sometimes is a huge bonus. There were cases in the past when I had to spend a lot of time to optimise Ruby code, because it was just too slow (imagine rendering a lot of HTML, doing computation that is hard to do on the DB side etc)
* handling JSON with serde is just on another level
* Rust is very versatile. When a company starts using a language, they will naturally try to fit as much stuff into the language as possible, after all if you have mostly Python devs, you will prefer Python. A lot of people say "just use the right tool for the job", but even if there was something like "the right tool for the job", in practice it's more like: if the downsides of using our primary tech are huge, let's consider introducing a new language, otherwise let's stick with what we have. I've seen it numerous times in the past. I feel like with Rust the downsides of using it for most of the stuff are much smaller than for example for most of the other languages
* it's relatively easy to write code that will pretty much never crash. yes, Rust will not prevent all of the bugs, but it will prevent almost all of the things that end up as a runtime exception in dynamic languages. So ou will not end up with an error tracker full of errors
* refactoring is so much easier in Rust - I can enter a new project, change a bunch of stuff and after I fix compile errors and tests my confidence that I didn't break anything is like 10 times higher than in Ruby or Python
* while most of the time speed is not a major concern for backend development, it sometimes is a huge bonus. There were cases in the past when I had to spend a lot of time to optimise Ruby code, because it was just too slow (imagine rendering a lot of HTML, doing computation that is hard to do on the DB side etc)
* handling JSON with serde is just on another level
* Rust is very versatile. When a company starts using a language, they will naturally try to fit as much stuff into the language as possible, after all if you have mostly Python devs, you will prefer Python. A lot of people say "just use the right tool for the job", but even if there was something like "the right tool for the job", in practice it's more like: if the downsides of using our primary tech are huge, let's consider introducing a new language, otherwise let's stick with what we have. I've seen it numerous times in the past. I feel like with Rust the downsides of using it for most of the stuff are much smaller than for example for most of the other languages
Modern web will be Python + Django/Flask + Js/Typescript (and maybe Swift or Java for mobile apps). You can replace almost all of that with Rust, so you'll get one language to rule them all, but focusing on Python part only:
obviously performance, sane tooling and dependency management, statically typed language results in less runtime errors. Overall Python gets you a lot faster from 0 to "it works on my laptop", Rust gets you faster to 'it's good enough to put it in production".
If you really need speed (high RPS) then Python is going to tap out at some point. Normally for line-of-business apps and most startups, developer productivity trumps raw perf IMO (obviously depends on the domain though).
There is some argument that you (or at least some developers) can be more productive with a strongly-typed ORM, but I think FastAPI / Django-ninja capture most of these benefits in the Python ecosystem so it’s not a big win in this dimension IMO.
But in summary it’s a perf vs productivity trade-off.
There is some argument that you (or at least some developers) can be more productive with a strongly-typed ORM, but I think FastAPI / Django-ninja capture most of these benefits in the Python ecosystem so it’s not a big win in this dimension IMO.
But in summary it’s a perf vs productivity trade-off.
It's written in Rust. Rust is at the state of its life where people will try to do anything and everything with it because they can. Some will stick, while some is just silly.
If I interviewed somewhere that used Rust for web apis, I'd be very hesitant because this isn't really what Rust is good at (yet?), and someone chose it because they wanted to try it more than use the right tool for the job.
If I interviewed somewhere that used Rust for web apis, I'd be very hesitant because this isn't really what Rust is good at (yet?), and someone chose it because they wanted to try it more than use the right tool for the job.
Yes!
Backend: https://rocket.rs/
Frontend: https://github.com/yewstack/yew
I personally use lit on the frontend to talk to rocket backend.
Yes!
I was delighted just a few weeks ago to go from nothing to a rest server, redis connection, database connection and templating out dynamic html with rust after a few hours of tinkering.
I was delighted just a few weeks ago to go from nothing to a rest server, redis connection, database connection and templating out dynamic html with rust after a few hours of tinkering.
It looks like this article requires sign up to read.
Non paywalled version here
https://scribe.rip/is-rust-ready-for-the-web-yet-9ec38c01dca...
https://scribe.rip/is-rust-ready-for-the-web-yet-9ec38c01dca...
Having fun porting my Typescript/NodeJS/ReactJS stack into Rust and Yew. Same productivity, more safety.
How much faster is this stack than the equivalent node/express setup?
I will continue using Rust for embedded, 3D graphics, and desktop PC programs, but won't touch it for websites until this is solved.