Our great sponsors
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
prql
PRQL is a modern language for transforming data — a simple, powerful, pipelined SQL replacement
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
> Yes! And it's freaking fast!
Going by these benchmarks (click around to find your own use case) Rust is definitely fast, but not (much) faster than many other languages, including Javascript. https://www.techempower.com/benchmarks/#section=data-r20&hw=...
When it comes to JSON serializers, there is a Java framework that is faster than Rust, which is interesting to say the least. When you start comparing actual fully-features frameworks, many Rust libraries even lose their advantage!
There are definite benefits to Rust web frameworks (despite the minimal speed diff, Rocket or similar can have less than half the RAM requirements that other languages run into!) but just because Rust compiles to machine code doesn't mean it'll revolutionize your web application.
> These provide everything you’d expect from a web framework, from routing and middleware, to templating, and JSON/form handling.
One problem I've run into is that I wanted to give Rust a try for a basic CRUD application but the features just weren't built in or available in packages. Some frameworks were missing CSRF, others were missing multipart/form uploads, and so on. Online discussions often end up concluding that "it's easy to write the middleware yourself, see this hacky POC", but this type of code is easy to mess up and easy to break with API upgrades.
Tide and Warp seem to have matured quite well, so I guess I'll have to give them a go at some point, but I'm a little sceptical. The status of this issue (https://github.com/http-rs/tide/issues/852) is a little disheartening...
> Yes! And it's freaking fast!
Going by these benchmarks (click around to find your own use case) Rust is definitely fast, but not (much) faster than many other languages, including Javascript. https://www.techempower.com/benchmarks/#section=data-r20&hw=...
When it comes to JSON serializers, there is a Java framework that is faster than Rust, which is interesting to say the least. When you start comparing actual fully-features frameworks, many Rust libraries even lose their advantage!
There are definite benefits to Rust web frameworks (despite the minimal speed diff, Rocket or similar can have less than half the RAM requirements that other languages run into!) but just because Rust compiles to machine code doesn't mean it'll revolutionize your web application.
> These provide everything you’d expect from a web framework, from routing and middleware, to templating, and JSON/form handling.
One problem I've run into is that I wanted to give Rust a try for a basic CRUD application but the features just weren't built in or available in packages. Some frameworks were missing CSRF, others were missing multipart/form uploads, and so on. Online discussions often end up concluding that "it's easy to write the middleware yourself, see this hacky POC", but this type of code is easy to mess up and easy to break with API upgrades.
Tide and Warp seem to have matured quite well, so I guess I'll have to give them a go at some point, but I'm a little sceptical. The status of this issue (https://github.com/http-rs/tide/issues/852) is a little disheartening...
This content, while still accurate, is missing out a few credible newer options.
In particular I want to shout out for Axum (https://github.com/tokio-rs/axum), from the folks who brought us Tokio. I've been building with it for the past few weeks and have never regretted it.
Here's an example of how useful webassembly can be: we're at the (fairly early) stages of developing PRQL [1]. Because it's in rust, with WASM we could put a live compiler on a webpage [2], and recompile the PRQL into SQL on every keystroke.
There's no server process — it's all built in GitHub Actions, hosted in GitHub pages, and runs in the browser. The whole WASM code is 164 lines (o/w half are comments).
[1]: https://github.com/prql/prql
Axum is an excellent web framework. I've used Actix, Rocket, Warp, Tide too. If you want a quick Axum demo, I wrote a free 50-page ebook tutorial here: https://github.com/joelparkerhenderson/demo-rust-axum
They still don't work if you use wasm-bindgen: https://github.com/rustwasm/wasm-bindgen/issues/2389
It's very hard to work without wasm-bindgen, since you have to wrap browser API manually otherwise.
That's great for you and your team, but looking at https://github.com/grapl-security/grapl it seems like your needs are pretty different from most web developers.
You may want to check out Crystal https://crystal-lang.org/ -- you will get all of the positives you describe, while avoiding perhaps 3 out of 4 of your listed negatives. (I think your "ease of iteration" point will still probably win for PHP vs any compiled language.)
Also, I'm very curious: how does the KLOC count compare for the PHP and Rust versions?
Mypy together with this plug-in gives you typing for django. https://github.com/TypedDjango/django-stubs
No, what I mean is https://github.com/rust-lang/rust-wiki-backup/blob/master/Si... and that's just pointers, you have #[] #![] and then three ways to invoke a macro !() !{} ![] and of course a lot more.
Maybe all this is necessary for a system level programming language, fine, but don't tell me this is easy to read.