Is Rust Ready for the Web Yet? (2020)

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.

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.

I am a longtime django user my self(since v0.95) and rocket comes pretty close to it.

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.

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.

Wow, that looks really extensive. Great work!

missing the most important part. the underbrush.

This is not backend related though, WASM is just a binary that can be executed by the browser.

Runs well in a browser, with ergonomic integration with HTML, CSS, and other browser APIs?

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".

How does rust run on the front-end? Or is this the compile to wasm thing?

Java?

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.

Rust syntax is fine. Actix with its pervasive use of macros, ain't.

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?

Rust is verbose, but here you don't need to build response, just return string and Actix will handle that.

Is there a meta website for all the "are we X yet" about rust?

Why wouldn't it be ready with Actix?

Am I missing something or is the Slavo “book” two pages and ends in plaintext “hello world” being sent to the client with no demonstration of routing, middleware, static assets, database, or templates?

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.

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

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.

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".

Non paywalled version here

https://scribe.rip/is-rust-ready-for-the-web-yet-9ec38c01dca...

If you mean old style html templates, it's been ready for many years. If you mean React style ssr, it's new but at least some frameworks have it too.