Doing my web stuff in Rust was fine but concurrency was a pain. A crate that abstracts web workers with transferrable types would help. After that you have to pick a component library of which there are few, and all are experimental. Making pretty, performant things is hard. Switching compontent libraries isn't easy. The backend stuff is a breeze, I think Rust is doing fine there.
I'm switching to Flutter for my UX needs. There's flutter-rust-bridge that binds Rust code concurrently without any headaches in the client, and I can deploy to the web, android, Linux, etc. with ease. Looks p. good out of the box. Got GRPC working quickly, am happy.
Using Rust in the client is nice because I have a single workspace that contains all of my business logic. Backend changes will cause errors in the client code if changes are necessary. The codebase is easy to refactor and trust. Dart ain't half bad.
I stayed away from Flutter at first because it doesn't respect the DOM etc but at this point I'm willing to sell my soul to the devil for how easy it is to make a great UX that deploys anywhere.
I don't love relying on something Google made, though. Feels a little like building a foundation on sand.
devjab
> I like to make silly things, and I also like to put in minimal effort for those silly things. I also like to make things in Rust…
I think this part is perhaps the silliest part of a very silly article. If you really like to put in a minimal effort then why on earth would you use Rust? If you want efficiency, memory management and a compiled modern language just use Go. Then you won’t even need anything but the standard library for what you want to do. Or… use Django as you suggest?
Yes, yes we use Rust in production because we thought it would be easier (well safer) to teach to interpreted language OOP developers than c/c++ but why on earth would you ever use it for the web unless you are a member of the cult?
show comments
bsnnkv
So strange reading all the comments here saying that Rust is not a language for "lazy developers".
I'm an incredibly lazy developer and Rust only makes me lazier. I can pretty much turn off the part of my brain that deals with "programming language" stuff and put all that energy towards the part of my brain that deals with "building stuff" whenever I write code in Rust, because I have a high level of confidence that the language itself isn't trying to make me shoot myself in the foot at every turn.
Rust is the only language where I can open something like Notepad without an LSP or highlighting, write code for an hour without testing or compiling, and then run clippy a few times to see and make the suggested fixes. It doesn't get any lazier than that.
On the web framework topic: Rocket is the greatest "lazy developer" web framework I've ever used.
show comments
paulgb
I was surprised not to see Rocket (https://rocket.rs/) mentioned among the frameworks the author listed; I haven’t used it myself because I _like_ the more unopinionated axum/actix-web, but as I understand it its goals are much more in the vein of what the author wants in a batteries-included framework and it’s been around for a while now.
show comments
axegon_
There is one: Poem[1]
The author mentions flask but looking at the "What we need section", I don't think flask covers those. I hate Djago with a passion but if those are the requirements, I think Django is the one that closely resembles what the author is describing. So Poem is not a good candidate either in that regard. Poem is all in all, something that closely resembles FastAPI, which is actually a complement. I've tried half a dozen rust web frameworks and they all come with a ton of boilerplate fiddling with the initial setup. Which is a problem if you want to get things done fast. In that regard, poem nails it. Yes, actix has a considerably better performance but unless you are aiming for sub-30 millisecond responses, then actix is not what you should be looking at to begin with. Also if you crave a Pydantic, there is a crate that sort of does that for you: https://crates.io/crates/poem-openapi
A lot of commenters are really getting hung up on the author's use of 'lazy'.
When she says lazy, she just means that she'd like a web framework that takes care of the most common and obvious schleps that are needed to create a web framework, like routing and so on. Once you get those schleps out of the way, there's still tons of work that needs to be done. Nothing lazy about that.
show comments
palmfacehn
I wouldn't mind a Rust based web framework that provides the same features as the base Servlet API. Everything else should be an optional library. When I look into it the rabbit hole goes too deep. It hasn't been immediately clear what the templating looks like. Usually they start talking about some "Reactive" framework, features I don't want and I lose interest. Afterwards, I realize that I'm already satisfied with my current web stack.
Jetty, HAProxy, JSTL, commons db connection pooling and Postgres.
show comments
dougthesnails
Take F# for a spin. It offers nearly all of the type system tomfoolery one craves and all the tooling and nice-to-haves one wants. The big drag is that the async story and memory management aren't as big as a time vampire as Rust, so you do run the risk of actually solving business needs. I am sure some part of dealing with Microsoft can fill that void, though.
show comments
ramon156
No mention of loco-rs? poem? rocket? There's already a lot of projects that aim for a batteries-included experience.
What sets these projects apart from frameworks like leptos is that there's a CLI guiding you. That's what I love about Symfony, and what I consider the 'lazy' part.
giancarlostoro
Python has Django, C# has ASP .NET Core, Ruby has Rails, and so on... If you want to really make Rust take off with web development, build up a full-feature solution.
Rocket is maybe the closest? But it's not as batteries included as any of the frameworks I've mentioned.
Please no. Frameworks are the breeding ground of accidental complexity.
Rust already has excellent libraries that are easy to use in many different stacks.
PedroBatista
Possible unpopular opinion: Rust is a systems language, doing "web work" in Rust is a waste of effort as there are much better languages and ecosystems for that.
show comments
mifydev
There is https://shuttle.rs. Not only a framework but a tool that can generate all the web boilerplate around it, sounds lazy enough for me!
godisdad
If the post were C++ focused instead of Rust would it make the same, more or less sense?
A systems language with a high cognitive barrier to entry, compile times and less than a decade of wide adoption can’t reasonably be expected to compete with something like Rails in terms of approachability
csomar
I am wondering why there is resistance to adopt GraphQL and a React-like front-end. Essentially, you no longer have routing/templating/web-server/etc... and you get lots of things handled for you (like authorization). You pretty much remove the web framework concept and just work directly on your application functionalities. With stitching, you have a gateway that add up various graphql gateways. So you could mix and match rust with other microservices or whatever.
I don't see myself doing it any other way these days.
skor
for those folks suggesting php/laravel, give cakephp a try. I've used both extensively: years and large, complex projects. Cake is just much faster to work in. In the initial phase and the long run.
What make rust better than any language when the bottleneck is the network or the database?
show comments
aabhay
Rust has some great and useful web frameworks that are a joy to use, once you understand what is going on. For example, in Axum, they use traits cleverly to allow you to use dependency injection the same way that fastapi uses it. But at least when I started using it, that wasn’t an insight made bluntly clear with tutorials as good as tiangolo’s. Instead, I had to piece it together via examples in the axum repo as well as from watching a youtube video.
Don’t fear, Rust can be as simple and clever as any other language. And the Rust core OSS developer community has spent at least the last ten minor versions improving dev ex considerably.
FWIW I prefer the pile of libraries. Big frameworks are good for scrappy startups trying to push their product out asap, but in most of situations, I’d like a lower abstraction system to build on.
show comments
sublinear
I guess I'm just "weird" for thinking the laziest and least error prone way to write a web app is in plain javascript?
Any framework is too much extra work to learn and going to eventually get you shot in the foot.
show comments
yarg
I consider myself a lazy developer: I like to write code that minimises the amount of code I'll need to write to incorporate new features in the future.
Laziness isn't necessarily a bad thing, depending on how it's implemented.
kuon
Just use Phoenix and live view.
Prototype is easy and fast. Scales well to very large user base on a single node. Interactive client side without even writing JS.
I love rust, I really do, I use it for all kind of things. But for web app, the Erlang architecture is so well designed and mature you cannot compete.
Also we use rust and zig from Erlang with native modules for video processing and AI, the elixir/Erlang "skin" gives you immense flexibility and productivity with almost no performance hit.
show comments
pjmlp
Languages with automatic resource management are much better option for distributed computing scenarios that one with strong focus on affine types.
perrohunter
The http server in the std library is one of the things Go got right and improved it's adoption, rust needs something similar
BikeShuester
I'd rather see Crystal on Rails. Combines the elegance of Ruby with the performance of a compiled language. And of course: macro support.
sodapopcan
"Right tool for the right job," no?
Learn multiple languages.
The whole "I want to do everything in the language I already know" is why the least interesting--and straight-up pretty terrible albeit very capable--languages are dominating our field.
show comments
the__alchemist
100%! I love Rust, but I will still use Python for backends because of Django. Rocket, Actix, Axum etc are more like Flask, but without Flask's integrations for the services. I don't understand why there are so many competing microframeworks; one of them should have IMO pivoted to a Django-like a while ago.
Rust is not for lazy developers and there are other languages if you want to put minimal effort in building things.
show comments
tombert
I am so glad I moved away from the web. I remember spending lots of time playing with different frameworks for Node.js and Java and PHP and Python, all with different tradeoffs, and all of them suck the fun out of programming out of me.
Yeah yeah I know <whatever> Framework is great and good for stability or something, but using a framework makes something that I enjoy (programming) feel more like filing out my taxes, just so I can end up with a mediocre CRUD application that more or less works for the project I am working on.
I have removed myself to from the web and programming almost instantly became more fun for me again.
djbusby
Servo is in Rust.
I want to make an app in Rust that hosts Servo in it with my business logic in maybe SciterJS - like electron but hopefully lighter?
Something, just a business software guy who wants something with more control than an webapp and not so heavy like electron.
show comments
rob
PHP's Laravel can do everything in that list. I'd just stick with that and focus on whatever you're trying to do, especially as a lazy developer.
monlockandkey
No harm if all these requirements are met by some framework to cater to the Rust community.
In my opinion you should for 99% of cases use Golang for your web backend. Any other languages there are tradeoffs you are making.
Go:
- very easy to learn and grok Go code
- static typing
- fast compilation
- single binary (easier deployment)
- strong standard library
- large library ecosystem
- go routines for concurrency
- highly performant
Maybe Java,Kotlin and C# but they are still an order of magnitude more complex and resource heavy than Go.
henning
Whatever you do, don't make this an RFC in a Rust repo/something up for debate and discussion. 500+ messages and literally years later, no one will agree on a single thing. Just make the thing you want and if people don't like it, they can stick with Actix.
myst
> Rust needs a web framework for lazy developers
Write one?
show comments
jiggawatts
He’s looking for the Rust equivalent of ASP.NET Core and there’s nothing wrong with that.
Sure, some people like choices and tinkering, but in many settings it’s much more productive to have the choices curated for you.
“But what if you want a different X instead? It might be Y% better!” is the typical comment, which ignores that the integration itself provides enormous value. Discrete libraries may be best of breed individually, but may be a heap of garbage if they don’t fit together smoothly.
I love programming in ASP.NET 8 specifically because I never have to think about whether a templating system will play nice with authentication, injection, routing, or anything else.
stonethrowaway
The author is I think conflating laziness for joy. We don’t care to be lazy because that won’t do it. But we do want to have a language that we like to use. To look at, to play with, to understand and to rally behind.
There is no one web framework that will satisfy all criteria and all layers of what a web framework needs. Every so often we have to migrate as technology catches up and changes the ecosystem, like wasm did with Blazor.
I’d rather have a language that programming is a joy in. The laziness is a nice side benefit. I can adapt such a language to changing landscape any day. I know Ruby is such a language, and hence Rails adopts it’s joyful mentality. But is Rust a joy to program for? That I can’t say for sure.
skeptrune
It really doesn't, actix is already there. Recently built my startup code over the past couple years with Actix and it had literally everything we needed easily. We just need more documentation and reference code bases demonstrating how to do these things. Rust devs tend to be fairly advanced and seemingly don't write enough docs or shares.
>Routing/handlers
Actix has it.
>Templates
Minijinja or liquid-rust[1]
>Static file serving
actix-files[2]
>Logins
Actix with oidccore is fantastic and easy[3]
>Permissions
Actix FromRequest is literally perfect. We have perm levels (admin, owner) and per-route perms for more fine-grained control.[4]
> Database interface
Diesel with diesel_async for connection pooling has been flawless at scale.
> Admin tooling
We didn't do this, but it would be simple with a bin/load-data.rs file that runs via a docker start command or tmuxp pane.
> Hot reloading
Cargo watch is getting deprecated, but was great. Bacon and and Watchexec are fully qualified successors. CSS watch systems work with the templates already same way as they do for SPAs.
> Background tasks
Make a bin/worker.ts file which defines a single binary and then use redis or another queing sytem to communicate between the worker and core server. We loaded all of HN (40M docs) into a search index with this approach and it was easy.
> Monitoring/observability
There's a decent story here with structured logging. Zero to production in Rust has a good chapter on it (2020) [5]. Lots of progress has been made since and exposing prom metrics endpoint is straightforward [6]. Sentry support is also decent and they sponsor actix.
> Caching
Imo, the story with Redis + actix is fine. We do this with our auth middleware to reduce latency on that operation since it happens with every route and I think it's smooth with FromRequest.
> Emails and other notifications
What's wrong with SMTP? Plus, Keycloak will handle your password reset infra out of the box. SDKs here could be better, but the APIs are fine and not too bad to do with Reqwest yourself.
> Deployment tooling + CSS/JS bundling
Imo, both of these things are the same as with other languages. Rust could use more documentation, but I don't think there's anything making it particularly hard to use.
I wish the author success in their endeavor, but Rust is pretty far down the stack of languages I'd use to deliver a webserver.
I look at Rust for serving web-traffic and I see: dreadful concurrency model (I will never voluntarily go back to async/await after working in Golang), weak client library stories (if I'm writing a service layer for a db, etc.), high barrier to entry, thin overlap with the core Rust value proposition (correctness around memory access, performance).
That's not even addressing the "what happens when my entry-level dev has to write something that interops with a web framework written in Rust." My heart can't take those code reviews, I might as well just write that shit myself without a framework for all the pain that's going to cause.
Note: I don't write a ton of Rust, for reasons that are maybe kind of obvious. I reach for it whenever C seems correct, which is rare but not never (for me).
show comments
Barrin92
If you want to make a silly, minimal effort hobby project simply don't use Rust. I'm gonna be honest I don't understand this entire genre of using extremely complex, highly optimized systems languages for tools that don't need them. Your flow chart should basically go like this:
"Do I need zero cost abstractions because I'm writing a computationally expensive very serious project?" If the answer is no use a garbage collected, runtime managed language.
show comments
LAC-Tech
I'm struggling to see a usecase for rust. If I want to do something as high level as a web app, GC is fine. If I want to do something at the systems level, Zig is much more at home there.
And development in rust is glacial. It's no one language featurep (not complaining about the borrow checker in particular), but the accumulative overhead of all of them acting in weird ways.
I will say the tooling is absolutely amazing, it's nice to span "app level" and "systems level" concerns in a single language. But it is a lot of language.
pmccarren
s/lazy/efficient/g :)
yakshaving_jgt
Yesod has most of the things on this wishlist (though it's Haskell, not Rust), and Yesod is generally awesome. I've been working with it for the past several years, and I look forward to the next several years with it.
tightbookkeeper
“Slow” scripting languages worked in the 90s for the web and they work even better for now, plus you have more to choose from. The key is to shell out to other tools for heavy lifting, like a database. Multi process architectures are where Linux really shines.
Rust can fit in that picture, but it doesn’t need to be routing http.
wokwokwok
I'm not going to lie, my first response was:
Wait, what, you think we need another web framework?
.....buuuut, if you spend more than 5 second actually reading the article...
> This doesn't exist right now, and I'm not sure if anyone else is working on it. All paths seem to lead me toward "whoops I guess I'm building a web framework." I hope someone else builds one, too, so we can have multiple options.
...
> My toolkit is called nicole's web toolkit, or newt. It's available in a public repository, but it's really not usable (the latest changes aren't even pushed yet). It's not even usable for me yet—this isn't a launch post, more shipping my design doc
Is where you can find the code, for what they're trying to make, to fill this gap.
Sure. Not a web framework. An all in one opinionated good out of the box defaults like rails.
Yes, there's no django/rails for rust.
Or go. Or clojure.
In fact, a lot of people have tried to make all-in-one frameworks, but usually the way the wind blows is that doing something specific is easy, but doing something flexible and generic is hard, a lot of work, and unless you're being paid to do it, it's a loveless job that eventually you get sick of and abandon.
I feel like if you're really going to go and write a rails clone, you need to spend a little bit of time digging into some of the other failed attempts and reasons they failed (eg. 1, 2, 3) first.
The landscape is littered with aborted rails clones.
It's perhaps... fun, but ultimately futile and naive, to think you can be 'the one that makes it' when so many others have failed, if you don't take the time to understand why so very very veryVERY many attempts to do this in many languages has failed.
(NB. Not to pick on clojure; I could have picked a bunch of go examples instead, but I guess the clojure failures have been particularly visible to me since I use clojure, and it's a place where, like rust, currently there are a lot of 'bits and pieces you can assemble yourself' and it feels like, surely just slapping them all together in one package can't be that hard...)
Doing my web stuff in Rust was fine but concurrency was a pain. A crate that abstracts web workers with transferrable types would help. After that you have to pick a component library of which there are few, and all are experimental. Making pretty, performant things is hard. Switching compontent libraries isn't easy. The backend stuff is a breeze, I think Rust is doing fine there.
I'm switching to Flutter for my UX needs. There's flutter-rust-bridge that binds Rust code concurrently without any headaches in the client, and I can deploy to the web, android, Linux, etc. with ease. Looks p. good out of the box. Got GRPC working quickly, am happy.
Using Rust in the client is nice because I have a single workspace that contains all of my business logic. Backend changes will cause errors in the client code if changes are necessary. The codebase is easy to refactor and trust. Dart ain't half bad.
I stayed away from Flutter at first because it doesn't respect the DOM etc but at this point I'm willing to sell my soul to the devil for how easy it is to make a great UX that deploys anywhere.
I don't love relying on something Google made, though. Feels a little like building a foundation on sand.
> I like to make silly things, and I also like to put in minimal effort for those silly things. I also like to make things in Rust…
I think this part is perhaps the silliest part of a very silly article. If you really like to put in a minimal effort then why on earth would you use Rust? If you want efficiency, memory management and a compiled modern language just use Go. Then you won’t even need anything but the standard library for what you want to do. Or… use Django as you suggest?
Yes, yes we use Rust in production because we thought it would be easier (well safer) to teach to interpreted language OOP developers than c/c++ but why on earth would you ever use it for the web unless you are a member of the cult?
So strange reading all the comments here saying that Rust is not a language for "lazy developers".
I'm an incredibly lazy developer and Rust only makes me lazier. I can pretty much turn off the part of my brain that deals with "programming language" stuff and put all that energy towards the part of my brain that deals with "building stuff" whenever I write code in Rust, because I have a high level of confidence that the language itself isn't trying to make me shoot myself in the foot at every turn.
Rust is the only language where I can open something like Notepad without an LSP or highlighting, write code for an hour without testing or compiling, and then run clippy a few times to see and make the suggested fixes. It doesn't get any lazier than that.
On the web framework topic: Rocket is the greatest "lazy developer" web framework I've ever used.
I was surprised not to see Rocket (https://rocket.rs/) mentioned among the frameworks the author listed; I haven’t used it myself because I _like_ the more unopinionated axum/actix-web, but as I understand it its goals are much more in the vein of what the author wants in a batteries-included framework and it’s been around for a while now.
There is one: Poem[1]
The author mentions flask but looking at the "What we need section", I don't think flask covers those. I hate Djago with a passion but if those are the requirements, I think Django is the one that closely resembles what the author is describing. So Poem is not a good candidate either in that regard. Poem is all in all, something that closely resembles FastAPI, which is actually a complement. I've tried half a dozen rust web frameworks and they all come with a ton of boilerplate fiddling with the initial setup. Which is a problem if you want to get things done fast. In that regard, poem nails it. Yes, actix has a considerably better performance but unless you are aiming for sub-30 millisecond responses, then actix is not what you should be looking at to begin with. Also if you crave a Pydantic, there is a crate that sort of does that for you: https://crates.io/crates/poem-openapi
[1] https://github.com/poem-web/poem
Basically, the author wants Spring Boot for Rust
A lot of commenters are really getting hung up on the author's use of 'lazy'.
When she says lazy, she just means that she'd like a web framework that takes care of the most common and obvious schleps that are needed to create a web framework, like routing and so on. Once you get those schleps out of the way, there's still tons of work that needs to be done. Nothing lazy about that.
I wouldn't mind a Rust based web framework that provides the same features as the base Servlet API. Everything else should be an optional library. When I look into it the rabbit hole goes too deep. It hasn't been immediately clear what the templating looks like. Usually they start talking about some "Reactive" framework, features I don't want and I lose interest. Afterwards, I realize that I'm already satisfied with my current web stack.
Jetty, HAProxy, JSTL, commons db connection pooling and Postgres.
Take F# for a spin. It offers nearly all of the type system tomfoolery one craves and all the tooling and nice-to-haves one wants. The big drag is that the async story and memory management aren't as big as a time vampire as Rust, so you do run the risk of actually solving business needs. I am sure some part of dealing with Microsoft can fill that void, though.
No mention of loco-rs? poem? rocket? There's already a lot of projects that aim for a batteries-included experience.
What sets these projects apart from frameworks like leptos is that there's a CLI guiding you. That's what I love about Symfony, and what I consider the 'lazy' part.
Python has Django, C# has ASP .NET Core, Ruby has Rails, and so on... If you want to really make Rust take off with web development, build up a full-feature solution.
Rocket is maybe the closest? But it's not as batteries included as any of the frameworks I've mentioned.
Something like https://sinatrarb.com/ for rust would be cool.
Please no. Frameworks are the breeding ground of accidental complexity.
Rust already has excellent libraries that are easy to use in many different stacks.
Possible unpopular opinion: Rust is a systems language, doing "web work" in Rust is a waste of effort as there are much better languages and ecosystems for that.
There is https://shuttle.rs. Not only a framework but a tool that can generate all the web boilerplate around it, sounds lazy enough for me!
If the post were C++ focused instead of Rust would it make the same, more or less sense?
A systems language with a high cognitive barrier to entry, compile times and less than a decade of wide adoption can’t reasonably be expected to compete with something like Rails in terms of approachability
I am wondering why there is resistance to adopt GraphQL and a React-like front-end. Essentially, you no longer have routing/templating/web-server/etc... and you get lots of things handled for you (like authorization). You pretty much remove the web framework concept and just work directly on your application functionalities. With stitching, you have a gateway that add up various graphql gateways. So you could mix and match rust with other microservices or whatever.
I don't see myself doing it any other way these days.
for those folks suggesting php/laravel, give cakephp a try. I've used both extensively: years and large, complex projects. Cake is just much faster to work in. In the initial phase and the long run.
It is always a good idea to write a library, not so for frameworks https://www.brandons.me/blog/libraries-not-frameworks
What make rust better than any language when the bottleneck is the network or the database?
Rust has some great and useful web frameworks that are a joy to use, once you understand what is going on. For example, in Axum, they use traits cleverly to allow you to use dependency injection the same way that fastapi uses it. But at least when I started using it, that wasn’t an insight made bluntly clear with tutorials as good as tiangolo’s. Instead, I had to piece it together via examples in the axum repo as well as from watching a youtube video.
Don’t fear, Rust can be as simple and clever as any other language. And the Rust core OSS developer community has spent at least the last ten minor versions improving dev ex considerably.
https://deno.com/
Isn’t there a rust rails clone?
Yeah, it’s called loco https://loco.rs/
FWIW I prefer the pile of libraries. Big frameworks are good for scrappy startups trying to push their product out asap, but in most of situations, I’d like a lower abstraction system to build on.
I guess I'm just "weird" for thinking the laziest and least error prone way to write a web app is in plain javascript?
Any framework is too much extra work to learn and going to eventually get you shot in the foot.
I consider myself a lazy developer: I like to write code that minimises the amount of code I'll need to write to incorporate new features in the future.
Laziness isn't necessarily a bad thing, depending on how it's implemented.
Just use Phoenix and live view.
Prototype is easy and fast. Scales well to very large user base on a single node. Interactive client side without even writing JS.
I love rust, I really do, I use it for all kind of things. But for web app, the Erlang architecture is so well designed and mature you cannot compete.
Also we use rust and zig from Erlang with native modules for video processing and AI, the elixir/Erlang "skin" gives you immense flexibility and productivity with almost no performance hit.
Languages with automatic resource management are much better option for distributed computing scenarios that one with strong focus on affine types.
The http server in the std library is one of the things Go got right and improved it's adoption, rust needs something similar
I'd rather see Crystal on Rails. Combines the elegance of Ruby with the performance of a compiled language. And of course: macro support.
"Right tool for the right job," no?
Learn multiple languages.
The whole "I want to do everything in the language I already know" is why the least interesting--and straight-up pretty terrible albeit very capable--languages are dominating our field.
100%! I love Rust, but I will still use Python for backends because of Django. Rocket, Actix, Axum etc are more like Flask, but without Flask's integrations for the services. I don't understand why there are so many competing microframeworks; one of them should have IMO pivoted to a Django-like a while ago.
in case someone really need it like in the article https://github.com/spring-rs/spring-rs
Rust is not for lazy developers and there are other languages if you want to put minimal effort in building things.
I am so glad I moved away from the web. I remember spending lots of time playing with different frameworks for Node.js and Java and PHP and Python, all with different tradeoffs, and all of them suck the fun out of programming out of me.
Yeah yeah I know <whatever> Framework is great and good for stability or something, but using a framework makes something that I enjoy (programming) feel more like filing out my taxes, just so I can end up with a mediocre CRUD application that more or less works for the project I am working on.
I have removed myself to from the web and programming almost instantly became more fun for me again.
Servo is in Rust.
I want to make an app in Rust that hosts Servo in it with my business logic in maybe SciterJS - like electron but hopefully lighter?
Something, just a business software guy who wants something with more control than an webapp and not so heavy like electron.
PHP's Laravel can do everything in that list. I'd just stick with that and focus on whatever you're trying to do, especially as a lazy developer.
No harm if all these requirements are met by some framework to cater to the Rust community.
In my opinion you should for 99% of cases use Golang for your web backend. Any other languages there are tradeoffs you are making.
Go:
- very easy to learn and grok Go code
- static typing
- fast compilation
- single binary (easier deployment)
- strong standard library
- large library ecosystem
- go routines for concurrency
- highly performant
Maybe Java,Kotlin and C# but they are still an order of magnitude more complex and resource heavy than Go.
Whatever you do, don't make this an RFC in a Rust repo/something up for debate and discussion. 500+ messages and literally years later, no one will agree on a single thing. Just make the thing you want and if people don't like it, they can stick with Actix.
> Rust needs a web framework for lazy developers
Write one?
He’s looking for the Rust equivalent of ASP.NET Core and there’s nothing wrong with that.
Sure, some people like choices and tinkering, but in many settings it’s much more productive to have the choices curated for you.
“But what if you want a different X instead? It might be Y% better!” is the typical comment, which ignores that the integration itself provides enormous value. Discrete libraries may be best of breed individually, but may be a heap of garbage if they don’t fit together smoothly.
I love programming in ASP.NET 8 specifically because I never have to think about whether a templating system will play nice with authentication, injection, routing, or anything else.
The author is I think conflating laziness for joy. We don’t care to be lazy because that won’t do it. But we do want to have a language that we like to use. To look at, to play with, to understand and to rally behind.
There is no one web framework that will satisfy all criteria and all layers of what a web framework needs. Every so often we have to migrate as technology catches up and changes the ecosystem, like wasm did with Blazor.
I’d rather have a language that programming is a joy in. The laziness is a nice side benefit. I can adapt such a language to changing landscape any day. I know Ruby is such a language, and hence Rails adopts it’s joyful mentality. But is Rust a joy to program for? That I can’t say for sure.
It really doesn't, actix is already there. Recently built my startup code over the past couple years with Actix and it had literally everything we needed easily. We just need more documentation and reference code bases demonstrating how to do these things. Rust devs tend to be fairly advanced and seemingly don't write enough docs or shares.
>Routing/handlers
Actix has it.
>Templates
Minijinja or liquid-rust[1]
>Static file serving
actix-files[2]
>Logins
Actix with oidccore is fantastic and easy[3]
>Permissions
Actix FromRequest is literally perfect. We have perm levels (admin, owner) and per-route perms for more fine-grained control.[4]
> Database interface
Diesel with diesel_async for connection pooling has been flawless at scale.
> Admin tooling
We didn't do this, but it would be simple with a bin/load-data.rs file that runs via a docker start command or tmuxp pane.
> Hot reloading
Cargo watch is getting deprecated, but was great. Bacon and and Watchexec are fully qualified successors. CSS watch systems work with the templates already same way as they do for SPAs.
> Background tasks
Make a bin/worker.ts file which defines a single binary and then use redis or another queing sytem to communicate between the worker and core server. We loaded all of HN (40M docs) into a search index with this approach and it was easy.
> Monitoring/observability
There's a decent story here with structured logging. Zero to production in Rust has a good chapter on it (2020) [5]. Lots of progress has been made since and exposing prom metrics endpoint is straightforward [6]. Sentry support is also decent and they sponsor actix.
> Caching
Imo, the story with Redis + actix is fine. We do this with our auth middleware to reduce latency on that operation since it happens with every route and I think it's smooth with FromRequest.
> Emails and other notifications
What's wrong with SMTP? Plus, Keycloak will handle your password reset infra out of the box. SDKs here could be better, but the APIs are fine and not too bad to do with Reqwest yourself.
> Deployment tooling + CSS/JS bundling
Imo, both of these things are the same as with other languages. Rust could use more documentation, but I don't think there's anything making it particularly hard to use.
[1]: https://github.com/devflowinc/hn-search-RAG/blob/main/actix-...
[2]: https://github.com/devflowinc/hn-search-RAG/blob/main/actix-...
[3]: https://github.com/devflowinc/trieve/blob/main/server/src/ha...
[4]: https://github.com/devflowinc/trieve/blob/main/server/src/ha...
[5]: https://www.lpalmieri.com/posts/2020-09-27-zero-to-productio...
[6]: https://romankudryashov.com/blog/2021/11/monitoring-rust-web...
I wish the author success in their endeavor, but Rust is pretty far down the stack of languages I'd use to deliver a webserver.
I look at Rust for serving web-traffic and I see: dreadful concurrency model (I will never voluntarily go back to async/await after working in Golang), weak client library stories (if I'm writing a service layer for a db, etc.), high barrier to entry, thin overlap with the core Rust value proposition (correctness around memory access, performance).
That's not even addressing the "what happens when my entry-level dev has to write something that interops with a web framework written in Rust." My heart can't take those code reviews, I might as well just write that shit myself without a framework for all the pain that's going to cause.
Note: I don't write a ton of Rust, for reasons that are maybe kind of obvious. I reach for it whenever C seems correct, which is rare but not never (for me).
If you want to make a silly, minimal effort hobby project simply don't use Rust. I'm gonna be honest I don't understand this entire genre of using extremely complex, highly optimized systems languages for tools that don't need them. Your flow chart should basically go like this:
"Do I need zero cost abstractions because I'm writing a computationally expensive very serious project?" If the answer is no use a garbage collected, runtime managed language.
I'm struggling to see a usecase for rust. If I want to do something as high level as a web app, GC is fine. If I want to do something at the systems level, Zig is much more at home there.
And development in rust is glacial. It's no one language featurep (not complaining about the borrow checker in particular), but the accumulative overhead of all of them acting in weird ways.
I will say the tooling is absolutely amazing, it's nice to span "app level" and "systems level" concerns in a single language. But it is a lot of language.
s/lazy/efficient/g :)
Yesod has most of the things on this wishlist (though it's Haskell, not Rust), and Yesod is generally awesome. I've been working with it for the past several years, and I look forward to the next several years with it.
“Slow” scripting languages worked in the 90s for the web and they work even better for now, plus you have more to choose from. The key is to shell out to other tools for heavy lifting, like a database. Multi process architectures are where Linux really shines.
Rust can fit in that picture, but it doesn’t need to be routing http.
I'm not going to lie, my first response was:
Wait, what, you think we need another web framework?
.....buuuut, if you spend more than 5 second actually reading the article...
> This doesn't exist right now, and I'm not sure if anyone else is working on it. All paths seem to lead me toward "whoops I guess I'm building a web framework." I hope someone else builds one, too, so we can have multiple options.
...
> My toolkit is called nicole's web toolkit, or newt. It's available in a public repository, but it's really not usable (the latest changes aren't even pushed yet). It's not even usable for me yet—this isn't a launch post, more shipping my design doc
ie. -> https://git.sr.ht/~ntietz/newt/tree
Is where you can find the code, for what they're trying to make, to fill this gap.
Sure. Not a web framework. An all in one opinionated good out of the box defaults like rails.
Yes, there's no django/rails for rust.
Or go. Or clojure.
In fact, a lot of people have tried to make all-in-one frameworks, but usually the way the wind blows is that doing something specific is easy, but doing something flexible and generic is hard, a lot of work, and unless you're being paid to do it, it's a loveless job that eventually you get sick of and abandon.
I feel like if you're really going to go and write a rails clone, you need to spend a little bit of time digging into some of the other failed attempts and reasons they failed (eg. 1, 2, 3) first.
The landscape is littered with aborted rails clones.
It's perhaps... fun, but ultimately futile and naive, to think you can be 'the one that makes it' when so many others have failed, if you don't take the time to understand why so very very very VERY many attempts to do this in many languages has failed.
(NB. Not to pick on clojure; I could have picked a bunch of go examples instead, but I guess the clojure failures have been particularly visible to me since I use clojure, and it's a place where, like rust, currently there are a lot of 'bits and pieces you can assemble yourself' and it feels like, surely just slapping them all together in one package can't be that hard...)
[1] - "Clojure needs a Rails" https://news.ycombinator.com/item?id=32288291 [2] - "A Rails like framework for Clojure." https://news.ycombinator.com/item?id=822210 [3] - "Luminus – A Clojure Web Framework" https://news.ycombinator.com/item?id=22852375
For new web applications, why recommend alternatives to Next.js?
How do you convince someone to use an alternative? The knowledge needed to understand why will help you get close enough in Next.js anyway.