@beandev statt Rocket kann ich Axum sehr empfehlen.
Das ist dann direkt wieder ein neues Framework, wo du dich ja gerade in Rocket einarbeitest. Und dazu noch mit async (angenommen du nutzt Rocker 0.4.x), was noch Mal eine eigene Schublade ist.
Generell ist Axum aber extrem flexibel und größtenteils keine Macros, also deutlich weniger "Magic".
Habe beide frameworks benutzt und bin von Rocker weg, weil die Entwicklung sehr eingeschlafen ist (und mein async/await zu der Zeit).
@beandev that is less for the manual call, and rather to have the value initialized as soon as possible.
Otherwise it would be initialized on first access, and not be your real startup time anymore.
You could for example delay that as well and call force() once the web server is ready, to provide the readiness uptime, without all the extra time spent on loading configs, connecting to the DB, initializing the web framework, ...
@beandev if you're willing to use nightly rust, you could already do that:
@beandev this crate is scheduled for being merged into the stdlib (for a long time already... Wonder when it actually happens).
So in the future you probably can solve it with the stdlib only.
@beandev You just need to know the right crates 😉
@musicmatze exactly, has to be in the same job.
You can use caches of course, but the overhead of saving and extracting the cache is not really worth it splitting up the two steps.
Especially as they kinda depend on each other.
@musicmatze haha, if you need that destination, it's probably best to run check, then clippy. Because clippy can run instantly on the artifacts of check and you don't have to compile twice that way.
Yes I know, it doesn't really "compile", but yeah.. that output from check 😅
@musicmatze my setup is: cargo-clippy and cargo-deny run in parallel.
Clippy actually runs check as well, so no need to have to different CI steps.
And cargo-deny is cargo-audit with many extra goodies to check dependencies and their licenses. That runs as a separate job, so it can just run in parallel. If one of the two fails, the other is automatically cancelled (in GH actions).
All sorts of Rusty Wasm-y goodness at tomorrow's RustAU Virtual meetup, streamed live this time tomorrow!
@kdwarn Just so you know, cargo itself has an aliasing features.
For example, I have an `alias c="cargo", and then in my `.cargo/config.toml` things like
t = ["test", "--all-features"]
u = ["update"]
That allow me to call it like `c t` or `c u`. Some common aliases like `c b` are already there by default too.
@janriemer yeah they are similar to yew, being a Framework, but pull it all together so you can directly build for web, desktop, mobile and even terminal UI.
Still has a long way to go I guess, but maybe in 1-2 years it might be a nice package if you want to go all Rust for your project (or just have it as a way to build a UI for your Rust project).
It's impressive how quick Tauri made it to 1.0, I hope many projects try it as an alternative to electron.
@janriemer looking forward to dioxus too which builds on top of tauri, but tries to deliver the whole "everything in Rust" package
tech, rust, html
@houkimenator don't know about html_parser, but kuchiki and scraper just use html5ever under the hood and combine it with css selectors. That's, at least the last time I used these crates 🤔
@janriemer @juliobiason Tracing is pretty cool. It directly gives you support for spans, which is pretty important for async code.
With normal logs you get messages of multiple events at the same time as they often happen in parallel. So you can plug tracing into several tools like "Jaeger" to have a nice UI to analyze events.
From the API side it looks very similar to log. I especially like, that you get key values for your log calls.
So it's basically the log crate + more 😅
The `anyhow` and `thiserror` crates are currently the go-to crates for error handling. Anyhow is mostly for applications and thiserror is mostly for libraries. They both contain great docs and show what they do and how to be used.
@musicmatze that author even has its own book about Rust... Not much expectations of that book to be honest.
I don't want to talk too bad about somebody I don't know... But can't just wave through content that I don't agree with either.
It's just not on par with the quality of other rust resources and very "wishy-washy".
@musicmatze Not just that one post, but I'm in general not a big fan of the kerkour posts. Most of them are either not very accurate, or stop way too early, leaving out tons of important information.
Seems to be quite popular and often shared on lobste.rs and Reddit, but don't really understand why.
🦀 Rust, 🐹 Go and 🍵 Kotlin enthusiast
This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!