-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
> But later maintenance will simply drop your productivity as any refactor
Thins very off take: Refactoring is Rust is one where even VERY deep changes can be done in economical times. Try the same in python is nearly impossible.
And I mean it: I fully rewritten all my app (a fairly complex niche eCommerce platform) to async and remade all things along it.
And I have A LOT of experience building, rewriting, and porting code and Rust is the faster/more friendly to refactor both large or small.
However, I concede that get the knowledge with Rust have challenges and my first attempts at this (when doing my hobby https://tablam.org language) were miserable"le by lack of understanding, so it could be a factor.
https://actix.rs/
Look at the first example. It can be very similar.
For reference I'd say the "current async framework" is either Starlette [1] or FastAPI [2] for web stuff, and trio [3] for more stupidproof async than twisted. IMHO of course!
[1] https://www.starlette.io/
Also in Rust, you have combinations of existing and upcoming language features that make certain conceptually simple designs either outright impossible to implement, or possible to implement a subset of due to certain compiler quirks, or impossible to determine whether it is actually possible to implement them without sinking hours of time into dead-end prototyping attempts.
Like, not an "Rust doesn't do this," but "there's a 50% chance that Rust can do this, but it might turn out to be impossible after all, and absolutely no one can tell which is which, because the language is just barely not expressive enough, or the compiler doesn't analyze this particular case, and might not until both the borrow checker and the type system receive complete rewrites."
And this, in turn, kind of explains why the Rust standard library and especially the Rust compiler are swimming not just in unsafe code blocks, but code that uses features so unstable and private that you can't even enable them with flags on nightly builds.
[0] https://github.com/rust-lang/rust/pull/96709#issuecomment-11...
> Go to github and find one Rust repo which doesn't use unwrap excessively.
Consider serde-json, a widely used library to serialise and deserialise json. You asked me to find “one Rust repo”. Ok here it is - https://github.com/serde-rs/json/search?q=unwrap&type=. Of the 22 uses of unwrap, nearly all are in test code or in comments. Of the remaining 3 or 4, they seem safe to me. But maybe they’re not. Could you think of some json input that could trigger a panic from one of those unwraps?
I’ll put my money where my mouth is. I’ll donate $100 to a charity of your choice if you can find that.
> And what would the helpful error dialog even say? „A problem has occurred and the app will now shut down“? From the user’s point of view, is that really an actionable or helpful error dialog?
Yes, literally - or even continue if you are running an event-driven app where the error may have happened as part of an event handler (and thus very limited to a very specific part of the software).
To give my own experience: I develop https://ossia.io and use this catch-all method. In 7 years I've gotten numerous thanks from the users for it not crashing but being able to carry forward. Not a single time I remember this to cause some memory corruption later.
This may be the closest thing I've personally seen: https://github.com/timvisee/advent-of-code-2021