[adwn]

> for everything else on userspace compiled managed languages are a much better option

That might be true if you're developing a pure application [1], but not if you're writing a library. Have fun integrating a C# library in a Java program, a Java library in a C# program, or either of those in a Python, Node, C, C++, or Rust program. There's something to be said for not requiring a runtime.

[1] Unless you care about easy parallelization with statically guaranteed thread-safety. But hey, who needs this in the age of multicore CPUs?

[pjmlp]

OS IPC exists for a reason, aren't microservices all the rage nowadays, and Plan 9 rules?

[adwn]

> OS IPC exists for a reason

Message-passing IPC is much, much slower and less efficient than shared-memory communication, and inter-process IPC (both message-passing and shared-memory) is much less convenient than intra-process multi-threading. Rust is the only mainstream language, managed or otherwise, which enables safe and efficient multi-threading.

[pjmlp]

Not at all, because as I explain on another sibiling answer, it is only safe if we cut down the use cases to a very specific one that helps to sell that narrative.

[adwn]

This one?

> Turns out threads also may share resources like out-of-process files, memory mapped regions, shared memory, databases, distributed transactions

For multi-threaded parallelization,

    - out-of-process files
    - databases
    - distributed transactions

aren't really relevant, and Rust directly helps with the other two aspects:

    - memory mapped regions
    - shared memory

In practice, your "very specific" aspect is the most important one, and the hardest to get right without Rust's Send and Sync traits and their automatic enforcement.

[pjmlp]

Who gets to say what is relevant is the architect driving the project implementation.

> aren't really relevant, and Rust directly helps with the other two aspects:

Not at all, because Rust code has nothing to say about what other processes do to those resources, the only thing you can do is wrap accesses in a unsafe code block and hope for the best, that nothing was corrupted.

[adwn]

I think you're confusing concurrency with parallelism. I've been talking about parallelization since my first comment in this thread. There's some overlap, yes, but the aspects you listed have typically very little to do with parallelization, which is why I called them "[not] really relevant". And where they do matter to multi-threading (the shared memory part), Rust does help with correctness.

[pdimitar]

Eh, modern OS-es indeed have loads of problems still, of which non-transactional access to the filesystem is in my top three, but to put those problems on Rust is a bit uncharitable. It's not Rust's fault that zero kernel devs have the courage to finally start enforcing patterns that have proven themselves useful and safe for decades, in other areas outside of IT as well (i.e. in financial accounting).

Rust plucks the fruit it can reach and it mostly stays in its lane and it's trying to expand it here and there (like Rust in Linux and embedded). I too want one ultimate language and one ultimate kernel but I don't think you and I will live to see it. Maybe our grandchildren will not as well.