However, the list of examples has... basically nothing. So it hasn't really proved that its set of features is enough to do anything with it.

The syntax is... off-putting. Regardless of how superficial it might seem, most systems programmers will want curly braces, and going against that is a really bad idea.

Extra features and extra static checking add complexity. Extra complexity in the language can make simple programs harder, and they make complex programs easier to code and maintain, like you said.

However, nobody will ever be able to make a Rust equivalent of TinyCC, the language's rules are insanely complex, especially for things like GATs and the other tricky concepts it's trying to tackle.

The Rust compiler can build a 2024 edition application which depends on a 2015 edition library, which in turn depends on a 2018 edition library.

Every crate can upgrade at their own pace, or even never at all.

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.