This sounds interesting. Could you go into a bit more detail?

I have 3 branches off of a single commit, update that commit, and all branches automatically rebase? Or?

But if you somehow do manage that, then you'll soon have hundreds of outdated vendored dependencies, full of unpatched security issues.

I tried Discord, and this one seems to download some updates on first run, but the version sticks to the one from the system (0.0.127, latest is 0.0.129). So I assume it just doesn't update, or it tries to and fails.

I think 29MB is still huge for a terminal text editor, but nevertheless not "hundreds".

    i32 -> u32 -> u64
    i32 -> i64 -> u64

* data races in a multi-threaded program

* type-casting to the wrong type (e.g. via unions) with compiler optimizations that rely on proper types

* assuming values are absolutely never aliased (shared xor mutable) when there's actually a way to create aliased values (e.g. unsafe {} and raw pointers)

* creating objects out of a sequence of bytes that is not valid for their type

...and likely many others I can't remember.

> Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize.

I think K8s couples two concepts: the declarative-style cluster management, and infrastructure + container orchestration. Keep CRDs, remove everything else, and implement the business-specific stuff on top of the CRD-only layer.

This would give something like DBus, except cluster-wide, with declarative features. Then, container orchestration would be an application you install on top of that.

Edit: I see a sibling mentioned KCP. I’ve never heard of it before, but I think that’s probably exactly what I’d like.

I have seen &pin being proposed recently [1], first time I'm seeing the others.

[1] https://blog.rust-lang.org/2025/11/19/project-goals-update-o...

Or rather, it gives abstractions so that higher-level types in stdlib and other libraries can prevent such access. The low-level implementation of the Mutex/etc types themselves do the same thing C and C++ do, via unsafe blocks, atomic primitives, fences, etc.

I think Rust's concurrency safety (e.g. async on a single thread) is mostly granted by the Pin trait [1], and the async code-gen making sure lifetimes make sense over .await points (which requires things to be either pinned across those points, or to not care about their location in memory potentially moving).

Thread safety is instead given by a couple of auto-derived marker traits, called Send and Sync [2], that denote which kinds of data can be sent or shared between threads safely.

This is coupled with types like Arc, Mutex, etc that can wrap data that isn't safe to share, so that the wrapped data as a whole is safe to share. It is also coupled with functions (like std::thread::spawn [3] and MPSC's send()) that have a requirement for the data to either be Sync/Send, or to take full ownership of it (which ensures there are no other active references to it).

[1] https://doc.rust-lang.org/std/pin/struct.Pin.html

[2] https://doc.rust-lang.org/std/marker/trait.Sync.html

[3] https://doc.rust-lang.org/std/thread/fn.spawn.html

Which part here is misinformation? Do you know something we, or the author, does not? I'm quite curious what that might be.

As another comment said, global state is allowed. It just has to be proven thread-safe via Rust's Send and Sync traits, and 'static lifetime. I've used things like LazyLock and ArcSwap to achieve this in the past.

[0] https://docs.rs/log/latest/log/fn.set_logger.html

The sad exception is obviously that Rust's std collections are not built on top of it, and neither is almost anything else.

But nevertheless, I think this means it's not a Zig vs Rust thing, it's a Zig stdlib vs Rust stdlib thing, and Rust's stdlib can be replaced via #[no_std]. In the far future, it's likely someone will make a Zig-like stdlib for Rust too, with a &dyn Allocator inside collections.

But they use I/O inside, and we arrive at this issue:

I'm writing async, and I need to call std::fs::read. I can't, because it blocks the thread; I could use spawn_blocking but that defeats the purpose of async. So instead I have to go look for a similar function but of the other color, probably from tokio.

In Zig, if you're writing sync, you call the standard library function for reading files. If you're writing async, you call the same library function for reading files. Then, the creator of the `io` object decides whether the whole thing will be sync or async.

You might be different, and you might start doing that in your code, but almost none of either std or 3rd party libraries will cooperate with you.

The difference with Zig is not in its capabilities, but rather in how the ecosystem around its stdlib is built.

The equivalent in Rust would be if almost all I/O functions in std would be async; granted that would be far too expensive and disruptive given how async works.

    Cannot start a runtime from within a runtime. This happens because a function (like `block_on`) attempted to block the current thread while the thread is being used to drive asynchronous tasks.