Axum 0.8(tokio.rs)
tokio.rs
Axum 0.8
https://tokio.rs/blog/2025-01-01-announcing-axum-0-8-0
72 comments
The API docs[1] often have a decent amount of guide level information on items within the library, but are perhaps lacking in the "use this crate for ..." type space. What specifically do you think is missing?
[1]: https://docs.rs/axum/latest/axum/
[1]: https://docs.rs/axum/latest/axum/
I've been dabbling with axum as of late and I agree the docs are relatively good.
I think 2 things that are missing.
- What you mention, "use this for that" sorts of guides. The ecosystem is pretty good, but when you pull down axum you aren't getting something like Java's Spring framework. Instead, you are getting something more like Javascript's expressjs. That makes it a bit tricky to go through and track down which tower plugins you should be using.
- "How to structure your app" sorts of guides. Axum doesn't really force any sort of layout of design, which is good, but it's also not great in that it leaves that actual design up to the beginners imagination. Something like "Here's an example of a todo app with multiple users" would do wonders in showing a recommended layout. Covering how you should do DI, input validation, error handling, session management, module layout, testing. All that sort of stuff would be really useful to have/see.
I think 2 things that are missing.
- What you mention, "use this for that" sorts of guides. The ecosystem is pretty good, but when you pull down axum you aren't getting something like Java's Spring framework. Instead, you are getting something more like Javascript's expressjs. That makes it a bit tricky to go through and track down which tower plugins you should be using.
- "How to structure your app" sorts of guides. Axum doesn't really force any sort of layout of design, which is good, but it's also not great in that it leaves that actual design up to the beginners imagination. Something like "Here's an example of a todo app with multiple users" would do wonders in showing a recommended layout. Covering how you should do DI, input validation, error handling, session management, module layout, testing. All that sort of stuff would be really useful to have/see.
They actually have quite a few examples in the axum repo and linked from their docs. Something a bit more use-friendly and approachable like Bevy's website would be beneficial, though.
There are examples, but they are fairly focused and not really full applications.
For example, you can find an example of error handling and an example of login flow. You won't see an example of the two put together.
Also importantly, the examples for simplicity are likely to lump everything into `main.rs`. A great way to show off specifically how to do something. Not a great way to show off "apps should look like this".
For example, you can find an example of error handling and an example of login flow. You won't see an example of the two put together.
Also importantly, the examples for simplicity are likely to lump everything into `main.rs`. A great way to show off specifically how to do something. Not a great way to show off "apps should look like this".
Thanks for the answer :)
Thanks for the answer :)
Thanks for the answer :)
I think this is all a bit like "here are the tools, this is a circle, now draw the rest of the owl".
Don't get me wrong, the docs are great. What I meant by that is that all the individual parts are well explained, but a framework is all about how you compose its parts — and that is described best by walking people through the thought-process of why to combine certain elements in a certain way and what behaviour you achieve by that as a result. Because in the end it is about the result.
A stellar example of this is Miguel Grinbergs Flask Mega-Tutorial: https://blog.miguelgrinberg.com/post/the-flask-mega-tutorial...
This bridges the gap between a good reference and a complex example project.
Don't get me wrong, the docs are great. What I meant by that is that all the individual parts are well explained, but a framework is all about how you compose its parts — and that is described best by walking people through the thought-process of why to combine certain elements in a certain way and what behaviour you achieve by that as a result. Because in the end it is about the result.
A stellar example of this is Miguel Grinbergs Flask Mega-Tutorial: https://blog.miguelgrinberg.com/post/the-flask-mega-tutorial...
This bridges the gap between a good reference and a complex example project.
Thanks for the answer :)
I usually ask gpt4o as my ref doc.
I've enjoyed what I've done with Axum thus far. I ultimately opted to use Leptos on top of it, so I don't really use it directly at this point. But it's neat.
For a long time, I used PHP and JS/TS for web projects. Now I'm using Rust with Axum/Tokio/Tower/Hyper (web server), Leptos (SSR using "Islands" flag, which also allows WASM generation for front end; JSX-like syntax), and Diesel (ORM and query builder that expects you define your schema using raw SQL). (I also leapt from DB2, MySQL and MariaDB to PostgreSQL)
It's heaven.
For a long time, I used PHP and JS/TS for web projects. Now I'm using Rust with Axum/Tokio/Tower/Hyper (web server), Leptos (SSR using "Islands" flag, which also allows WASM generation for front end; JSX-like syntax), and Diesel (ORM and query builder that expects you define your schema using raw SQL). (I also leapt from DB2, MySQL and MariaDB to PostgreSQL)
It's heaven.
It's great, isn't it? I'm doing the same for my apps, with Rust as the backend with Axum and Diesel, except I'm using Flutter for the frontend and also flutter_rust_bridge for some Rust crates I want to use directly inside the Flutter frontend.
I'm using Flutter as I'm making mobile apps primarily and I think it will take Rust based solutions a long time to get to feature and component parity with Flutter, it is simply a huge task to create a UI framework and component library from scratch, only a company like Google or Apple seem to be able to do so.
I'm using Flutter as I'm making mobile apps primarily and I think it will take Rust based solutions a long time to get to feature and component parity with Flutter, it is simply a huge task to create a UI framework and component library from scratch, only a company like Google or Apple seem to be able to do so.
> It's heaven.
Your welcome.
PHP and JS/TS are SWE ghettos. The improvements that TypeScript React, Laravel or Drizzle (smart SQL builder for TS) give are great but none can fix the underlying problems that a really shitty programming language results in.
I used to really love Ruby. But I now believe there's even better that's also totally free.
Rust is really nice!
Kotlin, OCaml and Haskell also have some amazing "doing it right" cultures, that leverage "stronger typing" techniques.
Your welcome.
PHP and JS/TS are SWE ghettos. The improvements that TypeScript React, Laravel or Drizzle (smart SQL builder for TS) give are great but none can fix the underlying problems that a really shitty programming language results in.
I used to really love Ruby. But I now believe there's even better that's also totally free.
Rust is really nice!
Kotlin, OCaml and Haskell also have some amazing "doing it right" cultures, that leverage "stronger typing" techniques.
I’ve always loved Haskell as well, although the most I did with it was writing a small language interpreter for a CS class.
It’s amazing how much better major languages could be. They’re slowly getting better - I started out using PHP 5 at work, and the improvements since then (eg PHP 8.4) are HUGE. I’ve used modern C++ extensively as well.
I love Rust more than either.
If you like Ruby, Loco RS is really neat as a(n immature) Ruby on Rails replacement.
It’s amazing how much better major languages could be. They’re slowly getting better - I started out using PHP 5 at work, and the improvements since then (eg PHP 8.4) are HUGE. I’ve used modern C++ extensively as well.
I love Rust more than either.
If you like Ruby, Loco RS is really neat as a(n immature) Ruby on Rails replacement.
While the improvements can be huge, they can never truly fix a language imho. There's too much code depending on it, and there's the stdlib that contains a lot of the "worst practices".
It's easy to love Rust (OCaml, Kotlin, ...) more.
> If you like Ruby
Nah, only for very small throwaway script. And even for them I prefer Kotlin nowadays (stronger typing, better IDE integration, etc.)
It's easy to love Rust (OCaml, Kotlin, ...) more.
> If you like Ruby
Nah, only for very small throwaway script. And even for them I prefer Kotlin nowadays (stronger typing, better IDE integration, etc.)
Absolutely a game changer. I'm using the same stack (minus Diesel) and I love that if it compiles it almost always works. Not so with JS/TS.
With server functions (and of course client/server in the same codebase/language) I also finally get why anyone would be attracted to running JS/TS on the server side.
With server functions (and of course client/server in the same codebase/language) I also finally get why anyone would be attracted to running JS/TS on the server side.
The only hitch was figuring out how to get server side includes not to break the WASM compilation (the solution was adding #[cfg] and #[cfg_attr] guards around the diesel use and derive rules). Other than that, it just worked - it’s so damn easy!
I always thought WASM would be difficult to use. With Leptos, it’s easier than JavaScript.
I always thought WASM would be difficult to use. With Leptos, it’s easier than JavaScript.
> I love that if it compiles it almost always works
I'm going to dig in a bit here: What do you mean specifcally by this? It is quite the claim! I suspect it has to do with meaning there is a low likelyhood of crashing, e.g. no type errors at runtime. My skepticism is that that general statement implies more than this.
I'm going to dig in a bit here: What do you mean specifcally by this? It is quite the claim! I suspect it has to do with meaning there is a low likelyhood of crashing, e.g. no type errors at runtime. My skepticism is that that general statement implies more than this.
Is it because the types and memory issues have been sorted out during the compile phase meaning code will "run" without crashing? That doesn't mean the code will work (infinite loops, etc), but it will run, right?
I've seen more than one Java program that will compile, but will throw a NullPointerError that gets unhandled.
I've seen more than one Java program that will compile, but will throw a NullPointerError that gets unhandled.
Yes. Quite often you spend hours working on something and when you run it the first time it just works. This is one of the major reasons people fall in love with Rust. There are just very ugly surprises or runtime issues. If it compiles it runs.
Compilation != Correct unless you're Ada spark with probably correct software.
Though it is interesting that a lot of the frustration I had with C++ in my younger years were crashes for unknown reasons.
Though it is interesting that a lot of the frustration I had with C++ in my younger years were crashes for unknown reasons.
Certain classes of errors will not appear during runtime if a rust program compiles. This is not the same as saying the program will run correctly. Can you see why?
Of course you’re technically right (you can absolutely write buggy code with Rust) but what others are saying (and what I have also anecdotally observed) is that Rust seems to have a much higher probability of new code just working (bug free) once you’ve cleared the compile step. The only language I’ve used that worked like that was ocaml and maybe Haskell (though I only dabbled in that).
It was quite obvious I was speaking anecdotally.
Say you are sending the data from the back-end to the front-end and you have a time field. With Rust, you are almost 100% certain that you are serializing/deserializing the same type. So if your code compiles, it'll probably work. With JavaScript, there is a good chance that the date String gets misinterpreted somehow and your application misbehaves.
The other advantage: with JavaScript/TypeScript, I find myself frequently getting the output and testing my functions in JavaScript to make sure stuff works. I don't do that when doing Rust -> Rust. If it's a DateTime chrono, the behaviour will be the same.
Also TypeScript is more like type documentation that strong typing enforcement. So it does help but only a little.
The other advantage: with JavaScript/TypeScript, I find myself frequently getting the output and testing my functions in JavaScript to make sure stuff works. I don't do that when doing Rust -> Rust. If it's a DateTime chrono, the behaviour will be the same.
Also TypeScript is more like type documentation that strong typing enforcement. So it does help but only a little.
There's a type safety mantra that goes "make illegal states unrepresentable" (which came from Yaron Minsky at Jane Street, I believe.) In other words, if you try to represent an illegal program state, the type checker should flag it.
If you design a program's types with this in mind - which requires a fairly powerful type system to do well - that goes a long way to achieving the other commenter's claim.
Related to this is the idea of "static debugging". Following the above approach, the type checker will alert you to many semantic bugs while you're writing the program, without needing to actually run it.
Working through this process tends to help you discover bugs that the type checker alone can't detect. The type system and checker helps you reason about the program's behavior.
The end result of this is that it does indeed tend to seem that "if it compiles, it almost always works."
That's not to say you never experience dynamic logic errors, and it can depend on the kind of program you're writing.
Another way to think about it is that good type systems are the ultimate "shift left" in the software development cycle. They allow you to detect problems about as early as you possibly can. Leveraging that can make a big difference to the SDLC.
If you design a program's types with this in mind - which requires a fairly powerful type system to do well - that goes a long way to achieving the other commenter's claim.
Related to this is the idea of "static debugging". Following the above approach, the type checker will alert you to many semantic bugs while you're writing the program, without needing to actually run it.
Working through this process tends to help you discover bugs that the type checker alone can't detect. The type system and checker helps you reason about the program's behavior.
The end result of this is that it does indeed tend to seem that "if it compiles, it almost always works."
That's not to say you never experience dynamic logic errors, and it can depend on the kind of program you're writing.
Another way to think about it is that good type systems are the ultimate "shift left" in the software development cycle. They allow you to detect problems about as early as you possibly can. Leveraging that can make a big difference to the SDLC.
In axiomatic safe Rust -- Rust code that doesn't deal with raw pointers -- you won't run into issues like null reference issues unexpectedly because code that can fail will return a type encapsulating the result (ie: Result or Option) that has to have the failure case either explicitly handled, or explicitly discarded with an ".unwrap()"/".expect()" call.
You still have to deal with errors in logic, but it's quite nice to not have to deal with all the other headaches.
You still have to deal with errors in logic, but it's quite nice to not have to deal with all the other headaches.
Concur. I bring this up because logic errors are the big one (anecdotally), and statements like "If it compiles it's correct" confuse people who haven't used rust, and give them the impression that people saying it are dishonest or exaggerate.
Rust doesn't completely prevent logic errors like it does memory issues, but in practice I find they're much more rare. Rust's type system is very expressive and allows you to check many of your application invariants at compile time (see "Parse, don't validate": https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...). In particular, I'd call out Rust's enums/discriminated unions as being probably the most impactful feature that's missing from many other programming languages.
From a more theoretical perspective, Rust's type system, ownership model, and borrow checker are general-purpose tools you can use to express compile-time-checked application invariants. The language and standard library use them to implement provably safe memory management, but you can also use them to prevent invalid states in your own applications or libraries. My understanding of the history of Rust's development is that the strong type system/ownership/lifetimes came first as a way of preventing logic bugs in complex concurrent applications, and only later the designers realized that system was powerful enough for full memory safety without garbage collection.
When I work with other programming languages, the experience of writing several hundred lines of code, compiling, and have them all work perfectly the first time is rare enough to be a surprise. When I write Rust, it's the norm.
I agree that "if it compiles it's correct" is a sloppy and possibly disingenuous statement. The compiler guarantees that your program is free from memory management errors and type errors; and it gives you the tools to turn most logic errors into type errors; but it does not guarantee absolute freedom from logic errors.
From a more theoretical perspective, Rust's type system, ownership model, and borrow checker are general-purpose tools you can use to express compile-time-checked application invariants. The language and standard library use them to implement provably safe memory management, but you can also use them to prevent invalid states in your own applications or libraries. My understanding of the history of Rust's development is that the strong type system/ownership/lifetimes came first as a way of preventing logic bugs in complex concurrent applications, and only later the designers realized that system was powerful enough for full memory safety without garbage collection.
When I work with other programming languages, the experience of writing several hundred lines of code, compiling, and have them all work perfectly the first time is rare enough to be a surprise. When I write Rust, it's the norm.
I agree that "if it compiles it's correct" is a sloppy and possibly disingenuous statement. The compiler guarantees that your program is free from memory management errors and type errors; and it gives you the tools to turn most logic errors into type errors; but it does not guarantee absolute freedom from logic errors.
How are you liking Leptos? I've been on the fence of trying Leptos vs Dioxus for a new project. They both seem great, but when I look for things like "charts" or "plots" or other components I don't see much support. Even though I am not a fan of TS I'm not sure if I really want to make those components myself.
I liked the Leptos JSX syntax and I feel like Dioxus is addressing a different problem. Dioxus specifically markets itself as a tool for universal app development. I looked at it, Perseus, Askama + JS, etc, but ultimately thought Leptos seemed like the best to dive in with.
For charts and plots -- I was thinking about the same thing today, actually! I've usually done those manually with SVG and JS. I was wanting a framework, and spent 30 minutes or so today looking at tools to use R diagrams on the web [0]. Also thought a little bit about making my own library. There are existing libraries like Plotters that should plug and play with Leptos just fine [1], but I haven't tried any yet.
[0]: https://m-clark.github.io/webR/visualization.html
[1]: https://docs.rs/plotters/latest/plotters/
For charts and plots -- I was thinking about the same thing today, actually! I've usually done those manually with SVG and JS. I was wanting a framework, and spent 30 minutes or so today looking at tools to use R diagrams on the web [0]. Also thought a little bit about making my own library. There are existing libraries like Plotters that should plug and play with Leptos just fine [1], but I haven't tried any yet.
[0]: https://m-clark.github.io/webR/visualization.html
[1]: https://docs.rs/plotters/latest/plotters/
Thanks for chiming in.
If there was a way to embed R plots without a lot of pain or CPU cycles server-side that would be fabulous. I would love to see an example of that. Plotters is pretty decent, I've used and abused it in a few projects over the years. But if I wanted something dynamic, I'm not sure how well that might go.
It does look like SVG and JS would be the way to go. Maybe there's a nice trick there, not sure.
If there was a way to embed R plots without a lot of pain or CPU cycles server-side that would be fabulous. I would love to see an example of that. Plotters is pretty decent, I've used and abused it in a few projects over the years. But if I wanted something dynamic, I'm not sure how well that might go.
It does look like SVG and JS would be the way to go. Maybe there's a nice trick there, not sure.
I just saw this on r/rust today, a library called plotlars got a release (not to be confused with plotters).
https://www.reddit.com/r/rust/s/QG21lu2Oy4
https://www.reddit.com/r/rust/s/QG21lu2Oy4
Looks pretty nice. The default style has some perks over plotters. Not throwing shade, it just looks nice. Thank you for sharing.
I almost gave up on Leptos, because I was trying to use it with Actix, which it supports less-well than it does Axum (and I’m too stubborn for my own good and wouldn’t switch).
I came back to it recently after the Leptos 0.7 release, though, and it’s MUCH smoother.
Still early days for a framework like this, but I think it’s got a lot of magic.
I came back to it recently after the Leptos 0.7 release, though, and it’s MUCH smoother.
Still early days for a framework like this, but I think it’s got a lot of magic.
So what's your iteration time like? I've always gotten about 2 seconds between making a change and testing it out with other web servers - curious as to how long it takes with Rust.
On my laptop (2017 macbook air with an i3 and 8GB ram), about 45 seconds. On my desktop (Ryzen 5600G, 32GB ram), 2-15. I haven't tried any techniques to reduce the compilation time yet.
Can you talk about about performance implications of using WASM?
1. The browser needs to load the whole app before anything else could be done resulting in a slow first load.
2. WASM -> DOM manipulation is slow.
1. The browser needs to load the whole app before anything else could be done resulting in a slow first load.
2. WASM -> DOM manipulation is slow.
1: Actually, that's not true! I use Leptos in their "islands" mode for server side rendering. The entire page is sent as an HTML response, and there is little/no "hydration". The WASM file ONLY includes interactive "islands" that are explicitly marked with the #[island] attribute [0]. In other words, the server binary is handling most of the rendering, similar to if I used a templating tool like Askama or Tera.
2: Leptos is generally slower than vanilla JS, I believe for that reason, but comparable to major JS frameworks [1, 2].
[0]: https://book.leptos.dev/islands.html
[1]: https://krausest.github.io/js-framework-benchmark/current.ht...
[2]: https://leptos.dev/
2: Leptos is generally slower than vanilla JS, I believe for that reason, but comparable to major JS frameworks [1, 2].
[0]: https://book.leptos.dev/islands.html
[1]: https://krausest.github.io/js-framework-benchmark/current.ht...
[2]: https://leptos.dev/
What about event listeners that are supposed to listen to elements inside the islands? Like clicks, key ups, etc. Who handles that?
Related:
Getting Started with Axum – Rust's Most Popular Web Framework - https://news.ycombinator.com/item?id=38545341 - Dec 2023 (25 comments)
Axum 0.7.0 - https://news.ycombinator.com/item?id=38432225 - Nov 2023 (1 comment)
Migrating from Warp to Axum - https://news.ycombinator.com/item?id=33718765 - Nov 2022 (75 comments)
Show HN: Axum web framework for Rust – a demo tutorial - https://news.ycombinator.com/item?id=30615288 - March 2022 (1 comment)
Getting Started with Axum – Rust's Most Popular Web Framework - https://news.ycombinator.com/item?id=38545341 - Dec 2023 (25 comments)
Axum 0.7.0 - https://news.ycombinator.com/item?id=38432225 - Nov 2023 (1 comment)
Migrating from Warp to Axum - https://news.ycombinator.com/item?id=33718765 - Nov 2022 (75 comments)
Show HN: Axum web framework for Rust – a demo tutorial - https://news.ycombinator.com/item?id=30615288 - March 2022 (1 comment)
I tried Axum recently and had a fairly bad experience. Incomprehensible trait errors, generics all over the place, and mind-numbing async glue code. Salvo wound up being way more straightforward for my (admittedly simple) use case.
I haven't written a Rust web server since before async/await, back in the Actix days. Axum is definitely an improvement on that. But I think the async ecosystem still has a long way to go.
I haven't written a Rust web server since before async/await, back in the Actix days. Axum is definitely an improvement on that. But I think the async ecosystem still has a long way to go.
The key for trait errors is https://docs.rs/axum-macros/latest/axum_macros/attr.debug_ha... -- it's made solving my problems much easier.
Consider Rouille - it's a very minimal web server in Rust. It does not have the ergonomics problems Axum does, which you describe.
I really like Axum. Like... a lot.
However, it feels petty weird sometimes as the extractor thing results in somewhat unusual-looking function signatures. Not a real problem and something I'm sure I would appreciate more if I understood exactly how it worked...
But it makes for really ergonomic definitions of route handlers. Even if it presently feels a little bit like weird or gross dependency injection.
However, it feels petty weird sometimes as the extractor thing results in somewhat unusual-looking function signatures. Not a real problem and something I'm sure I would appreciate more if I understood exactly how it worked...
But it makes for really ergonomic definitions of route handlers. Even if it presently feels a little bit like weird or gross dependency injection.
I'd recommend giving https://www.youtube.com/watch?v=Wnb_n5YktO8 a watch if you want to learn how it all works. Although, after watching it I'm pretty convinced Axum is actually an alien technology designed by minds greater than our own...
> https://www.youtube.com/watch?v=Wnb_n5YktO8
Two hour video which is basically a raw dump of a past live stream... Is there any condensed version with the relevant information, or even better, a text article version?
Two hour video which is basically a raw dump of a past live stream... Is there any condensed version with the relevant information, or even better, a text article version?
I had the same thought about both axum and diesel
Explained it perfectly. Thank you!
[deleted]
I wish they extracted the magic functions into a separate library. There is no reason for dependency injection to be tied to HTTP servers.
Isn’t that the point of Axum? It’s the convenience of route management (and more) built on top of an underlying HTTP server, in this case Hyper.
I really like Axum but have two issues with it 1) no well-integrated OpenAPI generation and 2) confusing error messages when you make an error in the request handler signature. The second problem Iblwsrned today might be solved with the #[debug_handler] macro but I know of no solution to the former.
I have slowly been getting into Rust for some personal projects. Already ported one of my Clojure applications to Rust and really enjoy the the tooling (and resource efficiency!) compared to Clojure.
Would like to try Axum, but couldn't find reliable code generation tools. Has the tooling improved on that front? I would love to hear if anyone has tried the rust-axum[1] OpenAPI generator and whether it generates decent Axum-based code.
OpenAPI isn't a hard requirement. I'm open to using Protobuf or Smithy as an IDL if the Rust ecosystem offers better server code generation with them.
[1] https://openapi-generator.tech/docs/generators/rust-axum/
Would like to try Axum, but couldn't find reliable code generation tools. Has the tooling improved on that front? I would love to hear if anyone has tried the rust-axum[1] OpenAPI generator and whether it generates decent Axum-based code.
OpenAPI isn't a hard requirement. I'm open to using Protobuf or Smithy as an IDL if the Rust ecosystem offers better server code generation with them.
[1] https://openapi-generator.tech/docs/generators/rust-axum/
Smithy can likely do all you need: https://github.com/smithy-lang/smithy-rs
Since it is used on production in AWS, some versions are lagging behind, however. Server generator is based on hyper/tower and works with axum too.
Since it is used on production in AWS, some versions are lagging behind, however. Server generator is based on hyper/tower and works with axum too.
I've used Axum for almost a year now, last project I built is a mix of APIs and SSR with HTMX + Askama. It's been great so far.
Hypermedia was scary at first because I was used to Next.js and React, breaking down everything into single and reusable components and their logic living inside of it. Now I'm doing pretty much all of it with minimal JS and the help of XPath.
I've been playing with this stack for months and I am now digging it - Plus, can't beat the beauty of the single binary that comes out of it! I run that with systemd and it's been flawless so far.
Hypermedia was scary at first because I was used to Next.js and React, breaking down everything into single and reusable components and their logic living inside of it. Now I'm doing pretty much all of it with minimal JS and the help of XPath.
I've been playing with this stack for months and I am now digging it - Plus, can't beat the beauty of the single binary that comes out of it! I run that with systemd and it's been flawless so far.
I want to try this sometime. I’m in the process of learning rust by creating something using rocket.rs. Apparently this is out of style and more people use Axum now. But I’m going to keep going with rocket.
I think Axum has been pretty great... like a high perforance version of Oak/Koa/Hono in the JS/TS space. Mostly used it for straight web services so far.
I await the day we'll get full-featured (Django-like; not flask-like), and non-Async web server in rust.
I think loco.rs, which actually builds on axum is the closest thing right now.
Last time I toyed around with it though, I found it to be pretty verbose, particularly because it uses SeaORM
We were already there in Rust infancy. Nobody enjoyed the baggage that came with userspace threads.
Curious, why the non-async requirement?
The most popular rust web frameworks are Async, and I don't enjoy Async code. (Nothing original here; standard coloring/ergonomics concerns)
If you're waiting for non-async, it'll probably never happen. The best that might happen is with the keyword generics proposal that will remove any differences ergonomically between sync and async code.
DidYaWipe(2)
https://github.com/tokio-rs/axum?tab=readme-ov-file#getting-...
https://github.com/tokio-rs/axum/blob/main/ECOSYSTEM.md#tuto...