I think why really need a way to transfer ownership of crate names if the original owner is completely unresponsive. The Python ecosystem has a process for this.

Apart from the aesthetic and its strength, a major advantage of gyroid that I experienced is that it reduces jerk which leads to less vibrations and noise.

This lightning infill looks like the exact opposite in that regard.

I like isolang for handling ISO-639 language codes.

(Disclaimer: I contributed to it)

In the async world, I love the smol stack where each functionality is split into an independent subcrate.

In fact, I would hypothesize that, from an ecosystem adoption POV, tokio’s only killer feature is hyper’s dependence on it.

AFAICT, the current hyper v1 release candidate only depends on tokio for tokio::sync::{mpsc, oneshot} (and sync is the only enabled feature).

It’s intended to be runtime-agnostic. See also https://docs.rs/hyper/1.0.0-rc.4/hyper/rt/trait.Executor.html . I agree that its ecosystem is still very tokio-centric.

I think the best part about smol is its composability.

Unlike tokio which consists of one large integrated library, smol provides many smaller, mostly runtime-agnostic crates e. g. blocking to run blocking I/O on a thread pool or async-lock for async lock primitives.

“PLA Filament” isn’t pure PLA, it can contain lots of additives that aren’t food safe.

Imagine being stuck in VR Vim.

Wow, that is incredibly detailed!

The owner of exa hasn’t been active for close to 2 years and the project isn’t very actively maintained. eza is a community maintained fork. Context: https://github.com/ogham/exa/issues/1139#issuecomment-1656702098

From eza’s readme:

eza features not in exa (non-exhaustive):

• Fixes “The Grid Bug” introduced in exa 2021.
• Hyperlink support.
• Selinux context output.
• Git repo status output.
• Human readable relative dates.
• Several security fixes (see dependabot)
• Many smaller bug fixes/changes!

I was under the impression the binary was compiled on the user’s machine

That’s how procedural macros used to and were intended to work.

The precompiled implementation is the only supported way to use the macros that are published in serde_derive. If there is implementation work needed in some build tools to accommodate it, someone should feel free to do that work

~ dtolnay (source)

That sounds like he doesn’t like to (re-)introduce any other options.