Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
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.
-
-
-
-
zig
General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
-
-
rust-orphan-rules
An unofficial, experimental place for documenting and gathering feedback on the design problems around Rust's orphan rules
-
-
azure-sdk-for-net
This repository is for active development of the Azure SDK for .NET. For consumers of the SDK we recommend visiting our public developer docs at https://learn.microsoft.com/dotnet/azure/ or our versioned developer docs at https://azure.github.io/azure-sdk-for-net.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
If you're willing to use nightly, you should be able to use the "type alias impl trait" (TAIT) feature (https://github.com/rust-lang/rust/issues/63063) to obtain a name for the anonymous types/closures. I've defintely done it in non const/static contexts, and it looks to me like it should be possible to do it in const/static contexts too.
There's currently an RFC under consideration for that.
The discoverability problem could be solved in other ways, like at least a community recommended libraries list, though curating it is difficult. Maybe something like most directly depended-upon crates is a good start, since transitive dependencies are by definition ones you didn't need to learn to use directly, but direct dependencies are ones that reflect how many people need to know a library exists. Someone did this analysis years ago, I guess it should be automated and made into a dynamic page. crates.io tracks the metadata for dependencies already, so that seems like a natural place for it.
I'm so glad you asked: https://github.com/Lucretiel/dislike-in-rust
Even extremely foundational crates like hyper and rustls have yet to make their 1.0 promise. Hyper is very close, in the -rc stages, but as of today it's not settled yet. Rustls is very important, something almost any production service will need, but still up in the air on compatibility. If you have multiple dependencies that aren't on the same page about something like hyper or rustls, you're either holding versions back or cramming multiple dependency graphs into one build. Cargo makes that easy when it's possible, but it's not always possible let alone practical, like when we had Tokio 0.2.x and 0.3.x at the same time.
This is certainly one that's bugged me too. There's the delegate crate which helps, but is still a decent amount of boilerplate due to macro limitations
Binaries file-sizes in debug are just insanely big, a Hello World will be around ~4MB, an empty Bevy project will be around ~600MB.
Do you already use nextest or something else? That really leans into test parallelism and sounds like a perfect fit for how you structure the tests.
I would wait for the getrandom crate to reach 1.0, which will answer many of the questions around what an API like this can look like, and then maybe the standard library discussion will be on firmer footing because at least we'll know what API we want to immortalize. Rushing that now just to save people importing a small crate does not seem to be the way to go.
There's already an accepted but not yet implemented proposal for supporting sandboxed build-time execution.
As for what you're asking for specifically, keep an eye on zig cc and the Rust wrapper, cargo-zigbuild. (Behind the scenes, it's essentially an effort to complete LLVM's compiler_rt enough that you can use it instead of the platform C runtimes that are such a pain to cross-compile for.)
And yet I think there are people enjoying async model for embedded systems. The embassy framework/executor is on my list of things I want to try out in Rust. Async/await isn't useful only for scaling with the amount of threads available, that's not even the main benefit of using of the model. I think async Rust is something novel that hits a middle ground between high and low levels of abstractions, making it mainly high-level for those who need to use it as such (most of the time).
Well, unless someone comes up with better, compatible rules, the orpan rules are gonna stick around.
You will get used to it when you write more Rust code. Read the book, implement some exercises and watch some tutorial YT videos, everything will make sense eventually.
Firstly, I recommend you read the book. It explains pretty much everything you are confused about.
Check out https://github.com/zesterer/pollster. This can be the solution to the async problem you described
I believe SSO could be solved, in part, with the Storage proposal I made a while ago, which Christopher Duram refined in his storages-api repository.
So how do you download part of a blob from Azure? Well, in https://github.com/Azure/azure-sdk-for-net/releases/tag/Azure.Storage.Blobs_12.12.0 there's a function that looks like this: