33 ms·

Rust needs a web framework

252 points by dcminter 2y ago

dartos 2y ago
Isn’t there a rust rails clone? Yeah, it’s called loco https://loco.rs/ 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.
- hermanradtke 2y ago
  Rails clones in modern languages don’t get wide adoption. I wrote about why I think that is: https://hermanradtke.com/why-your-rails-like-framework-is-not-widely-used/ https://hermanradtke.com/why-your-rails-like-framework-is-no...
  - paradox460 2y ago
    For what it's worth, Phoenix is quite rails like, as is the ash framework, and both are quietly popular
  - deleted 2y ago
    [deleted]
- erlend_sh 2y ago
  This needs to be higher up. Loco seems to be exactly what OP is looking for, yet it wasn’t mentioned in the article.
  - GolDDranks 2y ago
    My first thoughts. Before writing the piece, maybe they should look into what already exists.
- dajonker 2y ago
  What makes Rails (and similar frameworks in other languages) great is the large number of companies using it in production and having many people contribute to it. It therefore is very feature complete and works for a lot of use cases and edge cases. For everything that Rails does not do out of the box, there is a great ecosystem of libraries. Rust has no such framework. There is often just one person pulling the whole project and the number of active contributors is very small. This carries some risks and might mean that you end up having to do a lot of plumbing yourself.
paulgb 2y ago
I was surprised not to see Rocket (https://rocket.rs/ 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.
- wslh 2y ago
  I 100% agree. I'm just a casual multi-language programmer these days, but I'm familiar with Rocket.
- hobofan 2y ago
  While Rocket was one of the earliest Rust frameworks that really pushed for good UX (via proc-macros), I think it has largely fallen out of favor in many parts of the community. For a very long time it required nightly Rust versions to build, which is a no-go for many people wanting to use a framework in a production setting. Also for a period of ~2 years it was stuck in a 0.5.0 release candidate limbo where the latest stable released version was significantly lagging behind the rest of Rust web frameworks (requiring nightly; no async support yet). Maybe it will be better now after the 0.5 hump, but in general the development history of Rocket is something that dissuades me from using it when compared to e.g. Axum.
  - capitainenemo 2y ago
    When I asked them about that 2 year limbo, they said the release candidate was feature complete, and simply had incomplete documentation (also some plans for a new management structure). So, it wasn't actually lagging, it had that async for quite some time... But yeah, being in a "release candidate" did scare people off.
    - appplication 2y ago
      That is a bit telling on how the maintainers view their users, i.e. unseriously.
henning 2y ago
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.
BikeShuester 2y ago
I'd rather see Crystal on Rails. Combines the elegance of Ruby with the performance of a compiled language. And of course: macro support.
- binkethy 2y ago
  Amber or Lucky, already well established...
godisdad 2y ago
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
doctorpangloss 2y ago
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.
- johnny22 2y ago
  Next.js is not nearly flexible enough. I'd never use it. It feels like rails, but somehow even more tightly coupled than that.
- googledocsftw 2y ago
  1. Lots of dead ends. Fetch cache limit for example. Cant replicate prod page caching behaviour in dev. Etc. Many issues with 100 thumbs get abandoned. 2. NodeJS. Not everyone likes it. 3. It is slow. Yes it is! Try to get good web metrics with Next I dare you! 4. Premature release of App Router. Will they do something like that again.
  - doctorpangloss 2y ago
    I appreciate that you’re getting to the crux of the matter instead of downvoting. In our experience elevating the web metrics in Next.js takes the same expertise as doing it in any other framework. Our experience with Vertx and Microsoft’s dotnet web frameworks have been good, but Next.js got us to a fast, featureful, performant website sooner and with more flexibility around requirements. I won’t pass judgement on rust frameworks I haven’t used, but it’s just to say that in an honest accounting, a naked backend framework is less than half the product when you’re talking about web applications actually worth making with original ideas. Unless you work at Google.
    - googledocsftw 2y ago
      Ok I will bite. How did you manage to get scripts to defer?
      - doctorpangloss 2y ago
devjab 2y ago
> 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?
- deleted 2y ago
  [deleted]
- wongarsu 2y ago
  This is definetly something the article should have drilled down on. Why Rust? I'm sure everyone's tired of hearing why rust is an excellent alternative to c/c++ for new projects, but as an alternative against Python it gets muddier. Rust has a clear advantage in performance and memory footprint and a much better multithreading story, but those are things that aren't high priorities for 95% of web development. That basically leaves you with Rust's type system. Rust's type system is pretty great, and if we pretend we can't hear the Haskell developers it's one of the best type systems out there. That might seem to get in the way of quick prototyping, but on the other hand it would mesh really well with a framework like Django. One of the great things of Django was that you define your data schema, and Django takes care of both the database and a passable admin area. I'm sure you could greatly expand on that principle, with data types driving a lot of behavior and conveniences that the framework just handles for you. Maybe a bit like .NET, but without the enterprisy coat of paint and without putting dependency injection everywhere.
  - creatonez 2y ago
    The answer for why folks are so inclined towards doing high-level tasks in Rust... is the type system. Its sensibilities are in a sweet spot that makes it very easy to pull off huge refactors. It was also a lot of people's first introduction to algebraic data types being used in nearly all error handling (its usage of `Result<T, E> where E implements Error` and lack of nulls or exceptions). It makes a lot of progress towards the goal of "make invalid states unrepresentable", which could be really useful for web apps.
mifydev 2y ago
There is https://shuttle.rs https://shuttle.rs. Not only a framework but a tool that can generate all the web boilerplate around it, sounds lazy enough for me!
pmccarren 2y ago
s/lazy/efficient/g :)
Barrin92 2y ago
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.
- kstrauser 2y ago
  I don’t know about that. I already knew a little Rust last month when I wanted to write a REST API server that would benefit from being deployable as a single executable. I probably spent a grand total of 2-3 hours researching which framework to use (actix-web for me), reading the code, and implementing the endpoints I needed. The end result ended up looking an awful lot like a Python Flask app. The actual code writing part of the project wasn’t any more complicated than using any other language might’ve been. Learning Rust and learning web service programming at the same time would have a steep curve. If you already know the basics of Rust and have written web services before, writing a new one in Rust needn’t be stressful.
- kelnos 2y ago
  I write my hobby projects because writing them is fun. I don't find writing Ruby, Python, Go, and a host of other so-called "more appropriate" languages fun. If someone enjoys writing Rust, it's natural that they'll reach for it when they're looking to write something for fun. If the tools/libraries in that language exist to make writing a particular type of thing more fun or easier, then more the better.
- J_Shelby_J 2y ago
  > minimal effort hobby project Sorry, just spent 6 hours figuring setting up my python environment. Ready to start my hobby project now!
- keybored 2y ago
  No the flowchart is more like this 1. Do I like the language enough to use it for fun? (no: go to (2)) 2. Am I neutral towards the language? (no: go to (3)) 3. Am I fine with other people using it for fun? (no: go to (4)) 4. Feel free to harangue people who explicitly say they are using it for fun if their reasons for using it is not a 100% utilitarian (which is very likely to be the case: refer to the for fun section)
jknoepfler 2y ago
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).
- skeptrune 2y ago
  > dreadful concurrency model (I will never voluntarily go back to async/await after working in Golang), Rust supports golang style message-passing concurrency if you want it[1]. I'd argue Rust mpsc channels are actually more powerful than Golang's and add richness to message-passing concurrency modeling. [1]: https://doc.rust-lang.org/book/ch16-02-message-passing.html https://doc.rust-lang.org/book/ch16-02-message-passing.html
  - kelnos 2y ago
    Yeah, I don't get the hate here. Rust's channels are just as powerful as Go's, and there are even implementations of them in the futures crate that implement the Future trait, so you can await on them and effectively get the same behavior as "blocking" on a channel in a goroutine, without having a bunch of blocking native threads.
  - lossolo 2y ago
    > I'd argue Rust mpsc channels are actually more powerful than Golang's Do they support Go select functionality, buffered channels etc without using 3rd party libraries?
elAhmo 2y ago
Rust is not for lazy developers and there are other languages if you want to put minimal effort in building things.
- p1necone 2y ago
  I'm a lazy developer and I love languages with an "if it compiles it works" feel. I'd much rather hack around in rust or typescript with half my brain switched off and a beer in hand and eventually get working software than hack around in javascript with half my brain switched off and a beer in hand and get more and more broken software until I eventually give up.
  - RandomThoughts3 2y ago
    Then just use Ocaml or F#. You are welcome.
    - 6gvONxR4sf7o 2y ago
      For a person just curious about all three, how do the ecosystems compare?
  - 27theo 2y ago
    TypeScript sure, but Rust? Half your brain switched off? There is a middle ground between unfettered madness and the Rust compiler's strict regime. Maybe try Elm.
    - Philpax 2y ago
      Yes, really. I've found Rust to be the easiest language to use while cognitively impaired (i.e. drunk) because the compiler can maintain all of the invariants that my conscious mind would need to manually maintain in any other* language. *: There are simpler FP languages that can offer a similar experience, but they come with their drawbacks: I don't think I'd want to set up OCaml on Windows under such a state
  - throw10920 2y ago
tightbookkeeper 2y ago
“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.
axegon_ 2y ago
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 https://crates.io/crates/poem-openapi [1] https://github.com/poem-web/poem https://github.com/poem-web/poem
- giancarlostoro 2y ago
  Not just Django, probably Rails, ASP .NET Core, and many other full-feature, batteries included web frameworks. Emphasis on framework.
the__alchemist 2y ago
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.
- satvikpendem 2y ago
  Loco.rs?
mococa 2y ago
What make rust better than any language when the bottleneck is the network or the database?
- yakshaving_jgt 2y ago
  The bottleneck is mostly developer hours.
- drpossum 2y ago
  Not every application or even web application bottlenecks at the network or database level.
  - Capricorn2481 2y ago
    Doesn't really answer the question. Most webapps are this way and people are still surprisingly unaware of this.
    - drpossum 2y ago
      It is a refutation of the premise which invalidates this particular question as it was posed.
      - slowmovintarget 2y ago
        "Not every" is not the same as "none" and the discussion is about the majority, so I think your refutation is only of the absolute case and not of the original premise. Rust would be overkill for most web applications.
        sn9 2y ago
        Performance is one thing but there's also maintenance costs and the cost of servers. Also potential for future scaling.
        drpossum 2y ago
yakshaving_jgt 2y ago
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.
perrohunter 2y ago
The http server in the std library is one of the things Go got right and improved it's adoption, rust needs something similar
aabhay 2y ago
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.
- CoconutMilk 2y ago
  Curious which YouTube video you watched that helped learn Axum.
  - aabhay 2y ago
    https://youtu.be/Wnb_n5YktO8?si=lCGrH36DvXATdyEs https://youtu.be/Wnb_n5YktO8?si=lCGrH36DvXATdyEs
- skeptrune 2y ago
  >once you understand what is going on I think this is the big issue. We as members of the Rust community should be doing more to explain all the patterns for webservers in particular. Support is there, but it's non-obvious.
rob 2y ago
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.
PedroBatista 2y ago
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.
- tcfhgj 2y ago
  It's an investment in energy efficiency
  - jillesvangurp 2y ago
    The advantages of a language like Rust where most interactions are blocked on either user input or network IO are fairly limited. Rust shines when things are CPU or memory bound primarily. Web applications are mostly IO bound. Which is why people have been getting away with fairly poorly optimized interpreted languages for decades. Even when computers were a lot slower than they are today, this worked fairly well.
    - binkethy 2y ago
      Strict typing can enforce proper composition from models to the request responses. Rust is a high AND low level lego due to type composition and ability to directly address memory with no hacky garbage collection required. Garbage collection is a bad idea when your state machine is basically a stateless request response cycle that can fit in n stack frames and has a defined lifetime ending in the response. Interpreted languages calculate runtime code paths on an ad-hoc basis and are subject to bugs that a binary executable will never encounter. One can objectively state that Interpreted languages and their virtual machines are LESS DETERMINISTIC than binary executables whose runtime code already exists at compilation time. Of course, shared libs and other things that violate the spirit of the above can wreak havoc with even binaries, however the executable is a finite artifact.
    - tcfhgj 2y ago
      Energy efficiency is improved even in this case.
    - 2y ago
tombert 2y ago
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 2y ago
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.
- htdar 2y ago
  Tauri? https://tauri.app https://tauri.app
  - djbusby 2y ago
    Its pretty awesome and almost there. Actually, I'm sure if we could find the time it would be there. (We $DAYJOB)
yarg 2y ago
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.
skeptrune 2y ago
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-frontend/src/handlers/page_handler.rs#L48 https://github.com/devflowinc/hn-search-RAG/blob/main/actix-... [2]: https://github.com/devflowinc/hn-search-RAG/blob/main/actix-frontend/src/lib.rs#L99 https://github.com/devflowinc/hn-search-RAG/blob/main/actix-... [3]: https://github.com/devflowinc/trieve/blob/main/server/src/handlers/auth_handler.rs#L114 https://github.com/devflowinc/trieve/blob/main/server/src/ha... [4]: https://github.com/devflowinc/trieve/blob/main/server/src/handlers/auth_handler.rs#L66 https://github.com/devflowinc/trieve/blob/main/server/src/ha... [5]: https://www.lpalmieri.com/posts/2020-09-27-zero-to-production-4-are-we-observable-yet/ https://www.lpalmieri.com/posts/2020-09-27-zero-to-productio... [6]: https://romankudryashov.com/blog/2021/11/monitoring-rust-web-application/ https://romankudryashov.com/blog/2021/11/monitoring-rust-web...
kuon 2y ago
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.
- satvikpendem 2y ago
  No types in Elixir, I think a better comparison is actually Gleam, it is Rust-like in type system but is built on and interoperable with Erlang/OTP.
  - neonsunset 2y ago
    Both are exceedingly slow and memory-hungry. The average user of Rust might get shocked and never touch these again. Now F# on the other hand…
    - satvikpendem 2y ago
      Yeah I mean it depends if you want the benefits of OTP or not. To be honest, while it was nice as an all in one solution 50 years ago, these days there are all sorts of solutions for deployment so I wouldn't want to choose a programming language just because of its additional features in the form of OTP, especially if it entails dynamic typing or slower speed.
stonethrowaway 2y ago
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.
dougthesnails 2y ago
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.
- angra_mainyu 2y ago
  I've been on the fence w.r.t giving it a try. How does it compare to Ocaml and haskell?
  - consteval 2y ago
    From a web point of view, you get full access to .NET, all the associated packages, and all the tooling. You start with a huge head start as opposed to Ocaml and haskell for that usecase.
  - dougthesnails 2y ago
    It is Ocaml in all the ways that matter, but with .NET's async story/runtime/memory management, and tooling.
- EasyMark 2y ago
  Doesn’t f# require the .net virtual machine though? Most people I know picking rust like the fact that it’s compile to native code “always” and predictability and lack of random time of recovery from garbage collection
  - neonsunset 2y ago
    What does a VM mean to you? Because LLVM as a target is a VM of sorts too, and so is the memory model assumed by C.
bsnnkv 2y ago
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.
- chowells 2y ago
  Some people are comfortable offloading mental effort to a compiler. Others suffer from anxiety at the suggestion.
  - bsnnkv 2y ago
    I'm the other way around I guess - a lot of anxiety when I'm forced to touch fragile bits written in Ruby, Python and JS at work. Part of it might be the terrible tooling story in each of those language ecosystems as well. Last week I deployed a Ruby change where a missed comma between two strings in an array did not get picked up by any of the automated tooling or by 3 other team members who code reviewed my change, and ended up cutting 50+ sev2s at 10pm. AWS folks can probably guess which internal tool I had to touch that requires Ruby. (I was on call, fun times)
    - x3n0ph3n3 2y ago
      > 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. > anxiety when I'm forced to touch fragile bits written in Ruby Wild, because the first sentiment is exactly how I feel about Ruby.
giancarlostoro 2y ago
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.
sublinear 2y ago
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.
- akaike 2y ago
  Least error-prone and JavaScript in one sentence, I’m not sure about that, to be honest. JavaScript alone without any types in a big project is a shot in the foot, let alone the quirks JavaScript has. Apps crash when a thrown error is unhandled, etc. I would say JavaScript is easy, but it’s definitely not the type for a least error-prone app.
  - wiseowise 2y ago
    Slap TypeScript on it.
- bigiain 2y ago
  I think there's a scale/complexity thing to be considered. If your web app is simple, then frameworks and "safe" languages are unnecessary. At some stage though, that flips around. There's no way I'd choose to write, say, gmail or Trello in "plain javascript". The learning curve of a suitable framework for projects like that are well worth the eventual productivity, and the number of feet to shoot in your project will way exceed the number of feet added by the framework, and hopefully the framework will prevent way more foot shooting opportunities than it adds.
sodapopcan 2y ago
"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.
- bigiain 2y ago
  But surely "making silly things" in Rust counts as learning Rust? I remember writing a 2.5D "Doom style" renderer thing that let you move around in a bunch of rooms/corridors in real time in MacPerl/Quickdraw back in the Mac OS9 and Perl4 days. Probably taught me more about Perl than I'd learn in several years doing it for a job.
  - sodapopcan 2y ago
    For sure, but the article is from the perspective of knowing Rust and wanting to work around, well, Rust. I'm saying if that's what you want, use a language suited for that. Variety is a good thing.
- wiseowise 2y ago
  > Learn multiple languages Not everyone wants to be jack of all trades - master of none or have time, energy or capacity to waste their life in hamster wheel of constant relearning of the same thing. > is why the least interesting--and straight-up pretty terrible albeit very capable--languages are dominating our field. If they’re dominating our field they can’t be terrible by definition.
LAC-Tech 2y ago
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.
joshdavham 2y ago
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.
- pdpi 2y ago
  It all makes sense if you consider laziness here to mean the same as in Larry Wall's three great virtues of a programmer.
- deleted 2y ago
  [deleted]
Uptrenda 2y ago
[flagged]
- sedatk 2y ago
  I wrote my first web app in Pascal as a CGI because that was what I knew. That app turned out to become the most popular Turkish social platform for the following 25 years. I coded that app in 3 hours. It was very crude as you can imagine. But, it did its job. If I had to start with a “better” platform that I didn’t know, I could have spent days or weeks to learn and may not have released anything in the end because I got bored. Don’t discount a language for a certain type of application because you think it’d be harder to work with than something else. Familiarity goes a long way.
wokwokwok 2y ago
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 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 https://news.ycombinator.com/item?id=32288291 [2] - "A Rails like framework for Clojure." https://news.ycombinator.com/item?id=822210 https://news.ycombinator.com/item?id=822210 [3] - "Luminus – A Clojure Web Framework" https://news.ycombinator.com/item?id=22852375 https://news.ycombinator.com/item?id=22852375
- pantulis 2y ago
  > 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 idea of creating a "one man framework" like Rails in a systems programming language like Rust is a very tricky one. I don't think you can mimic the best productivity features of Rails without metaprogramming. Yes, you can do something like it, but the abstractions would leak all over the place making it uncomfortable for a Rust developer and not good enough for a Rails developer.
pjmlp 2y ago
Languages with automatic resource management are much better option for distributed computing scenarios that one with strong focus on affine types.
tonyhart7 2y ago
in case someone really need it like in the article https://github.com/spring-rs/spring-rs https://github.com/spring-rs/spring-rs
jiggawatts 2y ago
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.
myst 2y ago
> Rust needs a web framework for lazy developers Write one?
- Philpax 2y ago
  You'll never believe what the end of the post says.
  - myst 2y ago
    I can guess it without reading the post now. Thanks!
pkstn 2y ago
https://deno.com/ https://deno.com/
csomar 2y ago
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.
fbn79 2y ago
It is always a good idea to write a library, not so for frameworks https://www.brandons.me/blog/libraries-not-frameworks https://www.brandons.me/blog/libraries-not-frameworks
ramon156 2y ago
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.
monlockandkey 2y ago
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.
- neonsunset 2y ago
  Go is stuck in the eighties and replies like this are a good demonstration why it's very difficult to engage in intelligent discussion with many from Go communities. As someone who mainly specializes in .NET, I have had incomparably better time participating in Java and C++ ones because people there are usually able to acknowledge pros and cons of various platforms, how they evolved and where are their strengths and weaknesses. The average level of understanding and ability to consider what is the dev flow and how the language of choice impacts it in Go ones seems to be just so much worse it's not even funny. That is to say, goroutines are discount futures/tasks which force you into synchronizing the "yielding of result" manually either via a channel or a waitgroup and a collection, or similar. Not to mention they are also much more expensive than .NET Tasks. I have not measured the cost of Java's new green threads yet but assume they are going to be in the same ballpark of memory cost as Goroutines, but with drastically better steady state performance provided by OpenJDK HotSpot when it comes to regular application code. And lastly - Go requires you writing heaps of boilerplate for simplest things, Go channels come with a lot of footguns and gotchas you have to learn, standard library has weird omissions, type system is static but weak and as the demands put onto Go continue to become more complex, as more and more developers are forced into it, the language becomes the kind of unreadable soup you accuse other languages of. Just look at range over funcs and iterators discussions recently. It's ugly and token-heavy. And you will see a lot of code like this if you browse random libraries on Github - it's unnecessarily bulky, in a way that is excusable for true system programming languages but not in Go which has even higher level of abstraction runtime than .NET.
palmfacehn 2y ago
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.
- masklinn 2y ago
  It’s really not clear what you mean by “basic servlet API”, because the main rust web frameworks are pretty much just routing by default, with (largely opt-in) parsing and serialisation support. It “hasn’t been clear what the templating looks” like because there isn’t any just as AFAIK servlets provide no templating.
- stefs 2y ago
  just out of curiosity: why commons db connection pooling instead of hikari? i've only ever used the latter.
  - palmfacehn 2y ago
    I've been using version two for a long time now. It just works. I hadn't heard of Hikari until now.
datadeft 2y ago
Please no. Frameworks are the breeding ground of accidental complexity. Rust already has excellent libraries that are easy to use in many different stacks.
skor 2y ago
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.
snappr021 2y ago
Something like https://sinatrarb.com/ https://sinatrarb.com/ for rust would be cool.
- javierhonduco 2y ago
  Axum + minijinja is quite close to this I would say. Been using it for a little while and I am very happy so far.
  - aquariusDue 2y ago
    Seconding the recommendation, it's really great when paired with HTMX on the frontend too.
nfrankel 2y ago
Basically, the author wants Spring Boot for Rust
- creshal 2y ago
  Spring Boot, Django, Rails, Laravel, ASP, ... it's not unreasonable to expect Rust to have an equivalent to something that most popular languages have.
isosphere 2y ago
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.
- chrismorgan 2y ago
  > 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. Great UX, you say? Great UX!? Flutter’s unashamed pure-canvas approach makes it fundamentally and unfixably awful. Links don’t work because they’re fake (and it’s impossible to fake them), scrolling is atrocious for a significant fraction of users, text handling is obnoxious and wrong… seriously, speaking as a user, I’ve come across things made with Flutter three times in the last four years (plus looking at their demos), and Flutter makes for literally the worst user experience that I have come across in that time. Now Flutter does actually have a DOM renderer, but it never seems to be used. I’m not entirely sure why. Actually, scratch that, I just went to find a link, and found https://docs.flutter.dev/platform-integration/web/renderers https://docs.flutter.dev/platform-integration/web/renderers only talking about canvaskit and skwasm, no mention of the html renderer any more… it seems like they deprecated it earlier this year <https://github.com/flutter/flutter/issues/145954 https://github.com/flutter/flutter/issues/145954>, and will presumably remove it some time soon, doubling down on pure-canvas. Well, at least that lets me more unconditionally condemn Flutter for the web. Text is bad, especially if you use emoji. Links are bad because they’re fake. Scrolling is bad for a decent fraction of users. And none of these three are fixable if you insist on pure-canvas. (Links you could kinda make work tolerably if you were willing to compromise a little, but the other two just can’t be done.) If you want more substance to my complaints about the pure-canvas approach, search HN comments for “chrismorgan canvas” or similar. I still haven’t finished reducing it to an article on my website. If you intend to target the web and care about the web at all, please don’t use Flutter.
meindnoch 2y ago
Yet another one?
jmartin2683 2y ago
Rust and ‘minimal effort’ have to business being in the same room.
- Hackbraten 2y ago
  panic: something something upper or lower boundary of that "'minimal" lifetime you tried to use ^^^^^^^^^^ expected lifetime<Ref<Rc<Arc<&mut str>>>>, found Ref<Cell<&mut<lifetime<mut str>>>>
jokethrowaway 2y ago
That's interesting! I absolutely don't feel the need for a massive framework. I think a good part of the devs community has been burned by some framework at some point and doesn't feel the need for web frameworks, hence why nobody bothered to make Rails for rust. In a professional setting, all the services I interact with, have been implemented on top of express (node.js) or fast-api (python). I know people working in ecommerce who rely heavily on django or woocommerce, but rust usage among them is pretty low. Rust is also one language where there are very little junior people, so you'll see wire-it-yourself library more than frameworks. Eg. sqlx is imho the best compromise in the ORM vs query builder vs plain sql debate: you get typechecked plain sql. I think axum is very well architected and type checked routes offer a great DX (except for the tower::Service compatibility - sure, it's nice to have compatibility but the resulting code is quite clunky), and I'd rather have smaller components I understand over a huge black box.
dakom 2y ago
This article makes several different points that would ideally each be tackled on their own. You don't need a router when you have pattern matching (just split the url and match on static and dynamic vars however you need) Auth is typically DIY in any language, or SaaS like Firebase/Auth0. It's not a language or framework problem, necessarily CSS/JS tooling makes no sense for many frontend Rust frameworks like Dominator, which is in Rust (not JS) and has its own approach to styling that works for it (e.g. attaching styles to signals, so they change on the fly) I get what the author is saying - in fact I've been around the block a couple times solving all the different points in the article and it is painful. For example, see https://github.com/dakom/dominator-workers-fluent-auth https://github.com/dakom/dominator-workers-fluent-auth which does a lot of the stuff here on the Cloudflare workers framework (also adds another wishlist item - localization with Fluent) A "batteries included" full framework that does _everything_ is nice to have, but many real-world projects will want to replace those opinionated decisions and go the DIY route anyway. Rust is more than mature enough, even on the frontend web, to tackle all of that - if you know where to look (wasm-bindgen, etc.)
- Daishiman 2y ago
  > You don't need a router when you have pattern matching (just split the url and match on static and dynamic vars however you need) Web frameworks allow for much more: URL redirections, specific management of append-slash and case-sensitive URLs, complex regex matching, etc. > Auth is typically DIY in any language, or SaaS like Firebase/Auth0. It's not a language or framework problem, necessarily False. Django, Laravel, Rails and batteries-included languages have really good auth management. I personally consider it a gigantic mistake in 90% of orgs to outsource auth to external parties. The ability for experienced web devs to just hit the ground running and have 10 basic CRUDs running in a single day because they don't have to deal with this needless complexity is simply amazing for small businesses.
  - dakom 2y ago
    > URL redirection Erm, just return a new url after the match? Get fancy with state machine like enums? Rust has everything you need here, not getting why you think this requires a framework. > Specific management of [...] again, match for that, map your url parts, whatever - it doesn't need a 10,000 pound gorilla when it can be done in a line or two of code > complex regex matching erm, regex crate? > Django, Laravel, Rails Yup, those are valid choices. I said it's not a framework problem necessarily. Not a one size fits all sorta problem. Wordpress is also a fine choice if your business is knocking out new sites for a new client every month. But, if you're building a single product over the course of a year or two, it's not the end of the world to spend a couple weeks rolling your own auth and hook it up to transactional emails and everything else. It's just one small problem to deal with, not major in the grand scheme of things. YMMV
dajonker 2y ago
I think dhh said, great frameworks/libraries are extracted, not created from scratch. That would mean, someone building a (successful, money making) web application in Rust and building their own framework as they go, open sources that framework and then continues using it for their production applications. I have not seen such a success story for any Rust web framework yet. Although I would love to see one (or more!)
- oaiey 2y ago
  IMHO, there are three scenarios: - Regular Web / Services: IMHO, Go, Java, .NET are better candidates there - IoT devices with Web or API interfaces: Rust is good there. Access to I/O resources etc. - Extreme high-performance services: Something like a DNS-over-HTTP or wall street data brokers. But for that you need a VERY solid server (but most likely not a framwework). The regular web case will not produce a framework (out of commercial success), it is much easier to opt for a traditional languages/frameworks and hire inexpensive developers for that. The extreme high-performance services will not produce the framework you want and the likelihood is very small because the number of companies doing that is very low. Leaves the IoT space, which, IMHO, has the best chances BUT will not be the one optimized for your big server machine scenario.
josefrichter 2y ago
I think I've seen this exact discussion in Clojure community.
deleted 2y ago
[deleted]
binkethy 2y ago
What about loco.rs?

252 points by dcminter 2y ago

Isn’t there a rust rails clone? Yeah, it’s called loco https://loco.rs/ 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.

hermanradtke 2y ago
Rails clones in modern languages don’t get wide adoption. I wrote about why I think that is: https://hermanradtke.com/why-your-rails-like-framework-is-not-widely-used/ https://hermanradtke.com/why-your-rails-like-framework-is-no...
- paradox460 2y ago
  For what it's worth, Phoenix is quite rails like, as is the ash framework, and both are quietly popular
- deleted 2y ago
  [deleted]
erlend_sh 2y ago
This needs to be higher up. Loco seems to be exactly what OP is looking for, yet it wasn’t mentioned in the article.
- GolDDranks 2y ago
  My first thoughts. Before writing the piece, maybe they should look into what already exists.
dajonker 2y ago
What makes Rails (and similar frameworks in other languages) great is the large number of companies using it in production and having many people contribute to it. It therefore is very feature complete and works for a lot of use cases and edge cases. For everything that Rails does not do out of the box, there is a great ecosystem of libraries. Rust has no such framework. There is often just one person pulling the whole project and the number of active contributors is very small. This carries some risks and might mean that you end up having to do a lot of plumbing yourself.

paulgb 2y ago

I was surprised not to see Rocket (https://rocket.rs/ 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.

wslh 2y ago
I 100% agree. I'm just a casual multi-language programmer these days, but I'm familiar with Rocket.
hobofan 2y ago
While Rocket was one of the earliest Rust frameworks that really pushed for good UX (via proc-macros), I think it has largely fallen out of favor in many parts of the community. For a very long time it required nightly Rust versions to build, which is a no-go for many people wanting to use a framework in a production setting. Also for a period of ~2 years it was stuck in a 0.5.0 release candidate limbo where the latest stable released version was significantly lagging behind the rest of Rust web frameworks (requiring nightly; no async support yet). Maybe it will be better now after the 0.5 hump, but in general the development history of Rocket is something that dissuades me from using it when compared to e.g. Axum.
- capitainenemo 2y ago
  When I asked them about that 2 year limbo, they said the release candidate was feature complete, and simply had incomplete documentation (also some plans for a new management structure). So, it wasn't actually lagging, it had that async for quite some time... But yeah, being in a "release candidate" did scare people off.
  - appplication 2y ago
    That is a bit telling on how the maintainers view their users, i.e. unseriously.

henning 2y ago

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.

BikeShuester 2y ago

I'd rather see Crystal on Rails. Combines the elegance of Ruby with the performance of a compiled language. And of course: macro support.

binkethy 2y ago
Amber or Lucky, already well established...

godisdad 2y ago

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

doctorpangloss 2y ago

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.

johnny22 2y ago
Next.js is not nearly flexible enough. I'd never use it. It feels like rails, but somehow even more tightly coupled than that.
googledocsftw 2y ago
1. Lots of dead ends. Fetch cache limit for example. Cant replicate prod page caching behaviour in dev. Etc. Many issues with 100 thumbs get abandoned. 2. NodeJS. Not everyone likes it. 3. It is slow. Yes it is! Try to get good web metrics with Next I dare you! 4. Premature release of App Router. Will they do something like that again.
- doctorpangloss 2y ago
  I appreciate that you’re getting to the crux of the matter instead of downvoting. In our experience elevating the web metrics in Next.js takes the same expertise as doing it in any other framework. Our experience with Vertx and Microsoft’s dotnet web frameworks have been good, but Next.js got us to a fast, featureful, performant website sooner and with more flexibility around requirements. I won’t pass judgement on rust frameworks I haven’t used, but it’s just to say that in an honest accounting, a naked backend framework is less than half the product when you’re talking about web applications actually worth making with original ideas. Unless you work at Google.
  - googledocsftw 2y ago
    Ok I will bite. How did you manage to get scripts to defer?
    - doctorpangloss 2y ago

devjab 2y ago

> 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?

deleted 2y ago
[deleted]
wongarsu 2y ago
This is definetly something the article should have drilled down on. Why Rust? I'm sure everyone's tired of hearing why rust is an excellent alternative to c/c++ for new projects, but as an alternative against Python it gets muddier. Rust has a clear advantage in performance and memory footprint and a much better multithreading story, but those are things that aren't high priorities for 95% of web development. That basically leaves you with Rust's type system. Rust's type system is pretty great, and if we pretend we can't hear the Haskell developers it's one of the best type systems out there. That might seem to get in the way of quick prototyping, but on the other hand it would mesh really well with a framework like Django. One of the great things of Django was that you define your data schema, and Django takes care of both the database and a passable admin area. I'm sure you could greatly expand on that principle, with data types driving a lot of behavior and conveniences that the framework just handles for you. Maybe a bit like .NET, but without the enterprisy coat of paint and without putting dependency injection everywhere.
- creatonez 2y ago
  The answer for why folks are so inclined towards doing high-level tasks in Rust... is the type system. Its sensibilities are in a sweet spot that makes it very easy to pull off huge refactors. It was also a lot of people's first introduction to algebraic data types being used in nearly all error handling (its usage of `Result<T, E> where E implements Error` and lack of nulls or exceptions). It makes a lot of progress towards the goal of "make invalid states unrepresentable", which could be really useful for web apps.

mifydev 2y ago

There is https://shuttle.rs https://shuttle.rs. Not only a framework but a tool that can generate all the web boilerplate around it, sounds lazy enough for me!

pmccarren 2y ago

s/lazy/efficient/g :)

Barrin92 2y ago

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.

kstrauser 2y ago
I don’t know about that. I already knew a little Rust last month when I wanted to write a REST API server that would benefit from being deployable as a single executable. I probably spent a grand total of 2-3 hours researching which framework to use (actix-web for me), reading the code, and implementing the endpoints I needed. The end result ended up looking an awful lot like a Python Flask app. The actual code writing part of the project wasn’t any more complicated than using any other language might’ve been. Learning Rust and learning web service programming at the same time would have a steep curve. If you already know the basics of Rust and have written web services before, writing a new one in Rust needn’t be stressful.
kelnos 2y ago
I write my hobby projects because writing them is fun. I don't find writing Ruby, Python, Go, and a host of other so-called "more appropriate" languages fun. If someone enjoys writing Rust, it's natural that they'll reach for it when they're looking to write something for fun. If the tools/libraries in that language exist to make writing a particular type of thing more fun or easier, then more the better.
J_Shelby_J 2y ago
> minimal effort hobby project Sorry, just spent 6 hours figuring setting up my python environment. Ready to start my hobby project now!
keybored 2y ago
No the flowchart is more like this 1. Do I like the language enough to use it for fun? (no: go to (2)) 2. Am I neutral towards the language? (no: go to (3)) 3. Am I fine with other people using it for fun? (no: go to (4)) 4. Feel free to harangue people who explicitly say they are using it for fun if their reasons for using it is not a 100% utilitarian (which is very likely to be the case: refer to the for fun section)

jknoepfler 2y ago

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

skeptrune 2y ago
> dreadful concurrency model (I will never voluntarily go back to async/await after working in Golang), Rust supports golang style message-passing concurrency if you want it[1]. I'd argue Rust mpsc channels are actually more powerful than Golang's and add richness to message-passing concurrency modeling. [1]: https://doc.rust-lang.org/book/ch16-02-message-passing.html https://doc.rust-lang.org/book/ch16-02-message-passing.html
- kelnos 2y ago
  Yeah, I don't get the hate here. Rust's channels are just as powerful as Go's, and there are even implementations of them in the futures crate that implement the Future trait, so you can await on them and effectively get the same behavior as "blocking" on a channel in a goroutine, without having a bunch of blocking native threads.
- lossolo 2y ago
  > I'd argue Rust mpsc channels are actually more powerful than Golang's Do they support Go select functionality, buffered channels etc without using 3rd party libraries?

elAhmo 2y ago

Rust is not for lazy developers and there are other languages if you want to put minimal effort in building things.

p1necone 2y ago
I'm a lazy developer and I love languages with an "if it compiles it works" feel. I'd much rather hack around in rust or typescript with half my brain switched off and a beer in hand and eventually get working software than hack around in javascript with half my brain switched off and a beer in hand and get more and more broken software until I eventually give up.
- RandomThoughts3 2y ago
  Then just use Ocaml or F#. You are welcome.
  - 6gvONxR4sf7o 2y ago
    For a person just curious about all three, how do the ecosystems compare?
- 27theo 2y ago
  TypeScript sure, but Rust? Half your brain switched off? There is a middle ground between unfettered madness and the Rust compiler's strict regime. Maybe try Elm.
  - Philpax 2y ago
    Yes, really. I've found Rust to be the easiest language to use while cognitively impaired (i.e. drunk) because the compiler can maintain all of the invariants that my conscious mind would need to manually maintain in any other* language. *: There are simpler FP languages that can offer a similar experience, but they come with their drawbacks: I don't think I'd want to set up OCaml on Windows under such a state
- throw10920 2y ago

tightbookkeeper 2y ago

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

axegon_ 2y ago

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 https://crates.io/crates/poem-openapi [1] https://github.com/poem-web/poem https://github.com/poem-web/poem

giancarlostoro 2y ago
Not just Django, probably Rails, ASP .NET Core, and many other full-feature, batteries included web frameworks. Emphasis on framework.

the__alchemist 2y ago

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.

satvikpendem 2y ago
Loco.rs?

mococa 2y ago

What make rust better than any language when the bottleneck is the network or the database?

yakshaving_jgt 2y ago
The bottleneck is mostly developer hours.
drpossum 2y ago
Not every application or even web application bottlenecks at the network or database level.
- Capricorn2481 2y ago
  Doesn't really answer the question. Most webapps are this way and people are still surprisingly unaware of this.
  - drpossum 2y ago
    It is a refutation of the premise which invalidates this particular question as it was posed.
    - slowmovintarget 2y ago
      "Not every" is not the same as "none" and the discussion is about the majority, so I think your refutation is only of the absolute case and not of the original premise. Rust would be overkill for most web applications.
      - sn9 2y ago
        Performance is one thing but there's also maintenance costs and the cost of servers. Also potential for future scaling.
      - drpossum 2y ago

yakshaving_jgt 2y ago

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.

perrohunter 2y ago

The http server in the std library is one of the things Go got right and improved it's adoption, rust needs something similar

aabhay 2y ago

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.

CoconutMilk 2y ago
Curious which YouTube video you watched that helped learn Axum.
- aabhay 2y ago
  https://youtu.be/Wnb_n5YktO8?si=lCGrH36DvXATdyEs https://youtu.be/Wnb_n5YktO8?si=lCGrH36DvXATdyEs
skeptrune 2y ago
>once you understand what is going on I think this is the big issue. We as members of the Rust community should be doing more to explain all the patterns for webservers in particular. Support is there, but it's non-obvious.

rob 2y ago

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.

PedroBatista 2y ago

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.

tcfhgj 2y ago
It's an investment in energy efficiency
- jillesvangurp 2y ago
  The advantages of a language like Rust where most interactions are blocked on either user input or network IO are fairly limited. Rust shines when things are CPU or memory bound primarily. Web applications are mostly IO bound. Which is why people have been getting away with fairly poorly optimized interpreted languages for decades. Even when computers were a lot slower than they are today, this worked fairly well.
  - binkethy 2y ago
    Strict typing can enforce proper composition from models to the request responses. Rust is a high AND low level lego due to type composition and ability to directly address memory with no hacky garbage collection required. Garbage collection is a bad idea when your state machine is basically a stateless request response cycle that can fit in n stack frames and has a defined lifetime ending in the response. Interpreted languages calculate runtime code paths on an ad-hoc basis and are subject to bugs that a binary executable will never encounter. One can objectively state that Interpreted languages and their virtual machines are LESS DETERMINISTIC than binary executables whose runtime code already exists at compilation time. Of course, shared libs and other things that violate the spirit of the above can wreak havoc with even binaries, however the executable is a finite artifact.
  - tcfhgj 2y ago
    Energy efficiency is improved even in this case.
  - 2y ago

tombert 2y ago

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 2y ago

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.

htdar 2y ago
Tauri? https://tauri.app https://tauri.app
- djbusby 2y ago
  Its pretty awesome and almost there. Actually, I'm sure if we could find the time it would be there. (We $DAYJOB)

yarg 2y ago

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.

skeptrune 2y ago

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-frontend/src/handlers/page_handler.rs#L48 https://github.com/devflowinc/hn-search-RAG/blob/main/actix-... [2]: https://github.com/devflowinc/hn-search-RAG/blob/main/actix-frontend/src/lib.rs#L99 https://github.com/devflowinc/hn-search-RAG/blob/main/actix-... [3]: https://github.com/devflowinc/trieve/blob/main/server/src/handlers/auth_handler.rs#L114 https://github.com/devflowinc/trieve/blob/main/server/src/ha... [4]: https://github.com/devflowinc/trieve/blob/main/server/src/handlers/auth_handler.rs#L66 https://github.com/devflowinc/trieve/blob/main/server/src/ha... [5]: https://www.lpalmieri.com/posts/2020-09-27-zero-to-production-4-are-we-observable-yet/ https://www.lpalmieri.com/posts/2020-09-27-zero-to-productio... [6]: https://romankudryashov.com/blog/2021/11/monitoring-rust-web-application/ https://romankudryashov.com/blog/2021/11/monitoring-rust-web...

kuon 2y ago

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.

satvikpendem 2y ago
No types in Elixir, I think a better comparison is actually Gleam, it is Rust-like in type system but is built on and interoperable with Erlang/OTP.
- neonsunset 2y ago
  Both are exceedingly slow and memory-hungry. The average user of Rust might get shocked and never touch these again. Now F# on the other hand…
  - satvikpendem 2y ago
    Yeah I mean it depends if you want the benefits of OTP or not. To be honest, while it was nice as an all in one solution 50 years ago, these days there are all sorts of solutions for deployment so I wouldn't want to choose a programming language just because of its additional features in the form of OTP, especially if it entails dynamic typing or slower speed.

stonethrowaway 2y ago

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.

dougthesnails 2y ago

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.

angra_mainyu 2y ago
I've been on the fence w.r.t giving it a try. How does it compare to Ocaml and haskell?
- consteval 2y ago
  From a web point of view, you get full access to .NET, all the associated packages, and all the tooling. You start with a huge head start as opposed to Ocaml and haskell for that usecase.
- dougthesnails 2y ago
  It is Ocaml in all the ways that matter, but with .NET's async story/runtime/memory management, and tooling.
EasyMark 2y ago
Doesn’t f# require the .net virtual machine though? Most people I know picking rust like the fact that it’s compile to native code “always” and predictability and lack of random time of recovery from garbage collection
- neonsunset 2y ago
  What does a VM mean to you? Because LLVM as a target is a VM of sorts too, and so is the memory model assumed by C.

bsnnkv 2y ago

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.

chowells 2y ago
Some people are comfortable offloading mental effort to a compiler. Others suffer from anxiety at the suggestion.
- bsnnkv 2y ago
  I'm the other way around I guess - a lot of anxiety when I'm forced to touch fragile bits written in Ruby, Python and JS at work. Part of it might be the terrible tooling story in each of those language ecosystems as well. Last week I deployed a Ruby change where a missed comma between two strings in an array did not get picked up by any of the automated tooling or by 3 other team members who code reviewed my change, and ended up cutting 50+ sev2s at 10pm. AWS folks can probably guess which internal tool I had to touch that requires Ruby. (I was on call, fun times)
  - x3n0ph3n3 2y ago
    > 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. > anxiety when I'm forced to touch fragile bits written in Ruby Wild, because the first sentiment is exactly how I feel about Ruby.

giancarlostoro 2y ago

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.

sublinear 2y ago

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.

akaike 2y ago
Least error-prone and JavaScript in one sentence, I’m not sure about that, to be honest. JavaScript alone without any types in a big project is a shot in the foot, let alone the quirks JavaScript has. Apps crash when a thrown error is unhandled, etc. I would say JavaScript is easy, but it’s definitely not the type for a least error-prone app.
- wiseowise 2y ago
  Slap TypeScript on it.
bigiain 2y ago
I think there's a scale/complexity thing to be considered. If your web app is simple, then frameworks and "safe" languages are unnecessary. At some stage though, that flips around. There's no way I'd choose to write, say, gmail or Trello in "plain javascript". The learning curve of a suitable framework for projects like that are well worth the eventual productivity, and the number of feet to shoot in your project will way exceed the number of feet added by the framework, and hopefully the framework will prevent way more foot shooting opportunities than it adds.

sodapopcan 2y ago

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

bigiain 2y ago
But surely "making silly things" in Rust counts as learning Rust? I remember writing a 2.5D "Doom style" renderer thing that let you move around in a bunch of rooms/corridors in real time in MacPerl/Quickdraw back in the Mac OS9 and Perl4 days. Probably taught me more about Perl than I'd learn in several years doing it for a job.
- sodapopcan 2y ago
  For sure, but the article is from the perspective of knowing Rust and wanting to work around, well, Rust. I'm saying if that's what you want, use a language suited for that. Variety is a good thing.
wiseowise 2y ago
> Learn multiple languages Not everyone wants to be jack of all trades - master of none or have time, energy or capacity to waste their life in hamster wheel of constant relearning of the same thing. > is why the least interesting--and straight-up pretty terrible albeit very capable--languages are dominating our field. If they’re dominating our field they can’t be terrible by definition.

LAC-Tech 2y ago

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.

joshdavham 2y ago

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.

pdpi 2y ago
It all makes sense if you consider laziness here to mean the same as in Larry Wall's three great virtues of a programmer.
deleted 2y ago
[deleted]

Uptrenda 2y ago

[flagged]

sedatk 2y ago
I wrote my first web app in Pascal as a CGI because that was what I knew. That app turned out to become the most popular Turkish social platform for the following 25 years. I coded that app in 3 hours. It was very crude as you can imagine. But, it did its job. If I had to start with a “better” platform that I didn’t know, I could have spent days or weeks to learn and may not have released anything in the end because I got bored. Don’t discount a language for a certain type of application because you think it’d be harder to work with than something else. Familiarity goes a long way.

wokwokwok 2y ago

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 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 https://news.ycombinator.com/item?id=32288291 [2] - "A Rails like framework for Clojure." https://news.ycombinator.com/item?id=822210 https://news.ycombinator.com/item?id=822210 [3] - "Luminus – A Clojure Web Framework" https://news.ycombinator.com/item?id=22852375 https://news.ycombinator.com/item?id=22852375

pantulis 2y ago
> 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 idea of creating a "one man framework" like Rails in a systems programming language like Rust is a very tricky one. I don't think you can mimic the best productivity features of Rails without metaprogramming. Yes, you can do something like it, but the abstractions would leak all over the place making it uncomfortable for a Rust developer and not good enough for a Rails developer.

pjmlp 2y ago

Languages with automatic resource management are much better option for distributed computing scenarios that one with strong focus on affine types.

tonyhart7 2y ago

in case someone really need it like in the article https://github.com/spring-rs/spring-rs https://github.com/spring-rs/spring-rs

jiggawatts 2y ago

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.

myst 2y ago

> Rust needs a web framework for lazy developers Write one?

Philpax 2y ago
You'll never believe what the end of the post says.
- myst 2y ago
  I can guess it without reading the post now. Thanks!

pkstn 2y ago

https://deno.com/ https://deno.com/

csomar 2y ago

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.

fbn79 2y ago

It is always a good idea to write a library, not so for frameworks https://www.brandons.me/blog/libraries-not-frameworks https://www.brandons.me/blog/libraries-not-frameworks

ramon156 2y ago

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.

monlockandkey 2y ago

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.

neonsunset 2y ago
Go is stuck in the eighties and replies like this are a good demonstration why it's very difficult to engage in intelligent discussion with many from Go communities. As someone who mainly specializes in .NET, I have had incomparably better time participating in Java and C++ ones because people there are usually able to acknowledge pros and cons of various platforms, how they evolved and where are their strengths and weaknesses. The average level of understanding and ability to consider what is the dev flow and how the language of choice impacts it in Go ones seems to be just so much worse it's not even funny. That is to say, goroutines are discount futures/tasks which force you into synchronizing the "yielding of result" manually either via a channel or a waitgroup and a collection, or similar. Not to mention they are also much more expensive than .NET Tasks. I have not measured the cost of Java's new green threads yet but assume they are going to be in the same ballpark of memory cost as Goroutines, but with drastically better steady state performance provided by OpenJDK HotSpot when it comes to regular application code. And lastly - Go requires you writing heaps of boilerplate for simplest things, Go channels come with a lot of footguns and gotchas you have to learn, standard library has weird omissions, type system is static but weak and as the demands put onto Go continue to become more complex, as more and more developers are forced into it, the language becomes the kind of unreadable soup you accuse other languages of. Just look at range over funcs and iterators discussions recently. It's ugly and token-heavy. And you will see a lot of code like this if you browse random libraries on Github - it's unnecessarily bulky, in a way that is excusable for true system programming languages but not in Go which has even higher level of abstraction runtime than .NET.

palmfacehn 2y ago

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.

masklinn 2y ago
It’s really not clear what you mean by “basic servlet API”, because the main rust web frameworks are pretty much just routing by default, with (largely opt-in) parsing and serialisation support. It “hasn’t been clear what the templating looks” like because there isn’t any just as AFAIK servlets provide no templating.
stefs 2y ago
just out of curiosity: why commons db connection pooling instead of hikari? i've only ever used the latter.
- palmfacehn 2y ago
  I've been using version two for a long time now. It just works. I hadn't heard of Hikari until now.

datadeft 2y ago

Please no. Frameworks are the breeding ground of accidental complexity. Rust already has excellent libraries that are easy to use in many different stacks.

skor 2y ago

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.

snappr021 2y ago

Something like https://sinatrarb.com/ https://sinatrarb.com/ for rust would be cool.

javierhonduco 2y ago
Axum + minijinja is quite close to this I would say. Been using it for a little while and I am very happy so far.
- aquariusDue 2y ago
  Seconding the recommendation, it's really great when paired with HTMX on the frontend too.

nfrankel 2y ago

Basically, the author wants Spring Boot for Rust

creshal 2y ago
Spring Boot, Django, Rails, Laravel, ASP, ... it's not unreasonable to expect Rust to have an equivalent to something that most popular languages have.

isosphere 2y ago

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.

chrismorgan 2y ago
> 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. Great UX, you say? Great UX!? Flutter’s unashamed pure-canvas approach makes it fundamentally and unfixably awful. Links don’t work because they’re fake (and it’s impossible to fake them), scrolling is atrocious for a significant fraction of users, text handling is obnoxious and wrong… seriously, speaking as a user, I’ve come across things made with Flutter three times in the last four years (plus looking at their demos), and Flutter makes for literally the worst user experience that I have come across in that time. Now Flutter does actually have a DOM renderer, but it never seems to be used. I’m not entirely sure why. Actually, scratch that, I just went to find a link, and found https://docs.flutter.dev/platform-integration/web/renderers https://docs.flutter.dev/platform-integration/web/renderers only talking about canvaskit and skwasm, no mention of the html renderer any more… it seems like they deprecated it earlier this year <https://github.com/flutter/flutter/issues/145954 https://github.com/flutter/flutter/issues/145954>, and will presumably remove it some time soon, doubling down on pure-canvas. Well, at least that lets me more unconditionally condemn Flutter for the web. Text is bad, especially if you use emoji. Links are bad because they’re fake. Scrolling is bad for a decent fraction of users. And none of these three are fixable if you insist on pure-canvas. (Links you could kinda make work tolerably if you were willing to compromise a little, but the other two just can’t be done.) If you want more substance to my complaints about the pure-canvas approach, search HN comments for “chrismorgan canvas” or similar. I still haven’t finished reducing it to an article on my website. If you intend to target the web and care about the web at all, please don’t use Flutter.

meindnoch 2y ago

Yet another one?

jmartin2683 2y ago

Rust and ‘minimal effort’ have to business being in the same room.

Hackbraten 2y ago
panic: something something upper or lower boundary of that "'minimal" lifetime you tried to use ^^^^^^^^^^ expected lifetime<Ref<Rc<Arc<&mut str>>>>, found Ref<Cell<&mut<lifetime<mut str>>>>

jokethrowaway 2y ago

That's interesting! I absolutely don't feel the need for a massive framework. I think a good part of the devs community has been burned by some framework at some point and doesn't feel the need for web frameworks, hence why nobody bothered to make Rails for rust. In a professional setting, all the services I interact with, have been implemented on top of express (node.js) or fast-api (python). I know people working in ecommerce who rely heavily on django or woocommerce, but rust usage among them is pretty low. Rust is also one language where there are very little junior people, so you'll see wire-it-yourself library more than frameworks. Eg. sqlx is imho the best compromise in the ORM vs query builder vs plain sql debate: you get typechecked plain sql. I think axum is very well architected and type checked routes offer a great DX (except for the tower::Service compatibility - sure, it's nice to have compatibility but the resulting code is quite clunky), and I'd rather have smaller components I understand over a huge black box.

dakom 2y ago

This article makes several different points that would ideally each be tackled on their own. You don't need a router when you have pattern matching (just split the url and match on static and dynamic vars however you need) Auth is typically DIY in any language, or SaaS like Firebase/Auth0. It's not a language or framework problem, necessarily CSS/JS tooling makes no sense for many frontend Rust frameworks like Dominator, which is in Rust (not JS) and has its own approach to styling that works for it (e.g. attaching styles to signals, so they change on the fly) I get what the author is saying - in fact I've been around the block a couple times solving all the different points in the article and it is painful. For example, see https://github.com/dakom/dominator-workers-fluent-auth https://github.com/dakom/dominator-workers-fluent-auth which does a lot of the stuff here on the Cloudflare workers framework (also adds another wishlist item - localization with Fluent) A "batteries included" full framework that does _everything_ is nice to have, but many real-world projects will want to replace those opinionated decisions and go the DIY route anyway. Rust is more than mature enough, even on the frontend web, to tackle all of that - if you know where to look (wasm-bindgen, etc.)

Daishiman 2y ago
> You don't need a router when you have pattern matching (just split the url and match on static and dynamic vars however you need) Web frameworks allow for much more: URL redirections, specific management of append-slash and case-sensitive URLs, complex regex matching, etc. > Auth is typically DIY in any language, or SaaS like Firebase/Auth0. It's not a language or framework problem, necessarily False. Django, Laravel, Rails and batteries-included languages have really good auth management. I personally consider it a gigantic mistake in 90% of orgs to outsource auth to external parties. The ability for experienced web devs to just hit the ground running and have 10 basic CRUDs running in a single day because they don't have to deal with this needless complexity is simply amazing for small businesses.
- dakom 2y ago
  > URL redirection Erm, just return a new url after the match? Get fancy with state machine like enums? Rust has everything you need here, not getting why you think this requires a framework. > Specific management of [...] again, match for that, map your url parts, whatever - it doesn't need a 10,000 pound gorilla when it can be done in a line or two of code > complex regex matching erm, regex crate? > Django, Laravel, Rails Yup, those are valid choices. I said it's not a framework problem necessarily. Not a one size fits all sorta problem. Wordpress is also a fine choice if your business is knocking out new sites for a new client every month. But, if you're building a single product over the course of a year or two, it's not the end of the world to spend a couple weeks rolling your own auth and hook it up to transactional emails and everything else. It's just one small problem to deal with, not major in the grand scheme of things. YMMV

dajonker 2y ago

I think dhh said, great frameworks/libraries are extracted, not created from scratch. That would mean, someone building a (successful, money making) web application in Rust and building their own framework as they go, open sources that framework and then continues using it for their production applications. I have not seen such a success story for any Rust web framework yet. Although I would love to see one (or more!)

oaiey 2y ago
IMHO, there are three scenarios: - Regular Web / Services: IMHO, Go, Java, .NET are better candidates there - IoT devices with Web or API interfaces: Rust is good there. Access to I/O resources etc. - Extreme high-performance services: Something like a DNS-over-HTTP or wall street data brokers. But for that you need a VERY solid server (but most likely not a framwework). The regular web case will not produce a framework (out of commercial success), it is much easier to opt for a traditional languages/frameworks and hire inexpensive developers for that. The extreme high-performance services will not produce the framework you want and the likelihood is very small because the number of companies doing that is very low. Leaves the IoT space, which, IMHO, has the best chances BUT will not be the one optimized for your big server machine scenario.

josefrichter 2y ago

I think I've seen this exact discussion in Clojure community.

deleted 2y ago

[deleted]

binkethy 2y ago

What about loco.rs?