Axum 0.8
tokio.rs
tokio.rs
https://github.com/tokio-rs/axum?tab=readme-ov-file#getting-...
https://github.com/tokio-rs/axum/blob/main/ECOSYSTEM.md#tuto...
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.
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".
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.
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.
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.
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.
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 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.)
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.
I always thought WASM would be difficult to use. With Leptos, it’s easier than JavaScript.
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've seen more than one Java program that will compile, but will throw a NullPointerError that gets unhandled.
Though it is interesting that a lot of the frustration I had with C++ in my younger years were crashes for unknown reasons.
You still have to deal with errors in logic, but it's quite nice to not have to deal with all the other headaches.
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.
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.
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.
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.
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 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.
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.
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/
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 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.
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.
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?
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/
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.
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.