The RustCrypto organization has a bunch of crates for common crypto schemes. From when I looked into some of it, it looked pretty solid. It seems well maintained compared to other options, although most crates still have not reached version 1.0 and might be relatively new in the grand scheme of things, which is something to consider when security is critical.

Cryptography is considered to be one of the best application of rust.

Cryptography itself requires using assembly to avoid timing attacks. Using Rust on top of that is indeed a good match, and a widely used one (e.g. aws-lc-rs)

blessed.rs is my usual place to get started with these sorts of questions, and they have a section on cryptography crates.

I have been thinking of semver incorrectly, you're right: https://doc.rust-lang.org/cargo/reference/semver.html#enum-variant-new

The language wouldn't have lost much without tuples actually. But they do at least have direct pattern destructuring utility. Anonymous enums don't.

They also don't pose potential future awkwardness if/when variant types become a thing.

While I agree with you that anonymous sum types are useful, the language designers tend to avoid anything that might include a hidden cost (in this case either the size of the enum or cost of boxing). Something along those lines might end up in the language eventually, though.

Macros are often not very ergonomical to use compared to language features.

Also, why anonymous product types but not anonymous sum types? It seems kind of weird to me. Anonymous sum types can be just as useful as anonymous product types, as the blog post illustrates quite well I think.

A language feature is not needed because macros exist.

I would even argue that perhaps the most important role macros play is blocking adding endless language features 😉

Had to just think about why #[non_exhaustive] exists, so perhaps this helps you as well:

Imagine you're developing a really important core library, something like TCP. And then other libraries depend on your library.
Now, if you change your implementation, you may need to introduce a new error case, even though the rest of the API still works the same.

You have two choices to deal with that:

• Release version 2.0, because that's a breaking change. Each library that depends on you needs to manually upgrade to version 2.0. Some never will, because they're unmaintained. Any application that ships your library as a transitive dependency will need to ship both, version 1.0 and version 2.0, for the next few years until the last of their direct dependencies has upgraded to 2.0 or been removed.
• Or: You've declared that error enum #[non_exhaustive] before going 1.0 and therefore forced all depending libraries to implement a default match case. You can sneak in the new error case in version 1.1 without all those depending libraries needing to manually upgrade. The ecosystem does not split in half between 1.0 vs. 2.0.

Obviously, if it's a really egregious new error case that needs specific handling, then you might still want to release version 2.0, but by adding the #[non_exhaustive], you can decide later on and if you are such a central library, there's definitely going to be situations where you want to make use of it.

I've never thought about what swapping out allocators would do in an async environment like that. Very readable and interesting!

Maybe a default branch in the handler could do, though

This is exactly what it's for. #[non_exhaustive] forces you to add a default branch when matching on the error. It's already used a lot, so without a way to do that, it becomes less useful in library code.

I'm not sure non-exhsustive makes sense — you want the caller to handle everything you may return to them, and the new errors won't be handled. Maybe a default branch in the handler could do, though

I like the general idea (not a fan of the syntax but whatever). The one thing I'm not seeing is non-exhaustive error types. For example, in a library, you likely want to say "these errors are known to be possible, and some errors may be added in the future". Without non-exhaustive error types, this would mostly be useful exclusively in applications, not libraries. Of course, syntax-wise, you can just do (E1, E2, ...) or something to mark it non-exhaustive (if you were to add this to the language directly).

Either way, I agree that defining errors is needlessly extraordinarily verbose. I'm tempted to make a simple one-line macro to union a bunch of error types into an enum. (or use this library since I misread this as a language proposal lol) This, of course, falls apart when a function might use the same error type for multiple errors, or if it uses custom errors with no inner errors, but those cases are what thiserror is for.

Damn, this looks like it might solve my pain points with error handling. Will have to see, if it replaces them with new pain points, since error handling is fundamentally hard, but at least, it isn't starting completely from scratch...

Interesting. I'm surprised that it's possible to use tuples like that. Might try this.

So basically their argument is that the missing piece is anonymous sum types. I tend to agree! It would be amazing to have that as a language feature, i.e. Result<(), FooError | BarError>. Unfortunately that is unlikely to arrive to the language for a loooong time... But I think I will definitely try out this library in the meantime.

MPRIS is the spec that Linux desktops use to make players transfer metadata about the thing they are playing and its state.

For example: title, artists, cover art, position, playing/paused, etc...

It doesn't specify where the metadata should come from, for example the xesam:asText can be populated with lyrics from the metadata embedded in the song file itself, a companion .lrc file or even fetched from lrclib by the player, as long as the player is the one doing the IO and populating it.

The benchmarks mentioned seem to be a little misleading. The wild author has investigated these benchmarks in a blog post which has also been featured in the next to last This Week In Rust issue.

Is it too much effort to write wtf the package is?

mold: A Modern Linker

mold is a high-performance drop-in replacement for existing Unix linkers, designed to speed up builds. In our August 2026 benchmarks, it links 4.9x faster than LLVM lld and 1.9x faster than wild at the median; see Benchmark for the full results.

Yep, looks like it's AI assisted:

https://github.com/rui314/mold/discussions/1643

But I really like Mold, and if he thinks it's the right move, who am I to argue? I'm also a former C++ developer who writes only in Rust nowadays.

There is probably a funny hidden circle here. As wild was initially looking at and utilizing mold (well, mostly their test suite). And now mold (via Claude) would have inevitably relied on wild code.

Perhaps it would have been better to keep mold in maintenance mode while pointing people to wild, not necessarily as an immediate migration target, but as the long term option.

But who am I to argue with a project with such a prestigious sponsor list!

The Media Player Remote Interfacing Specification (MPRIS) is a standard D-Bus interface which aims to provide a common programmatic API for controlling media players.

This metadata is only for media streams, not something that would be embedded as metadata in a file?

Alec Benjamin mentioned!

Neat project.

wdym?

I specifically don't use AI for questions, just read the docs.

There's another notch where you only ask questions and do the writing alone