Lots of major companies like Microsoft and IBM also contribute to Linux, it doesn't make them saints nor even necessarily compare to what they get for using the volunteer dev work inside Linux.
Most of those companies actually contribute to the kernel or to foundational software used on servers, but few contribute to the userspace for desktop consumers on the level that Valve does.
Zig is "c", but modern and safe.
Zig is safer than C, but not on a level that is comparable to Rust, so it lacks its biggest selling point. Unfortunately just being a more modern language is not enough to sell it.
So imagine if trying to fit in a C-like cousin failed
C++ was not added to Linux because Linus Torvalds thought it was an horrible language, not because it was not possible to integrate in the kernel.
No, macros can see only the tokens you give them. They have no notion of the fact that crate::functions is a module, that PluginFunction is a trait and that functions_map is a variable. Not even the compiler may know those informations when the macro is expanded.
If you really really want to do this, you can use something like inventory. Note that inventory uses a special linker section to do this, which some consider a hack. This is also not supported on WASM if you want to target it.
CEO bonuses should be awarded 10 years after their mandate
Would it makes sense to provide a "share nothing" runtime implementation that can be injected at startup?
Isn't this tokio::task::spawn_local?
It also seems to require a GC though...
newxml is GC only, for simplicity sake.
Pointers are not guaranteed to be safe
So I guess they are forbidden in @safe mode?
but it's being replaced by something else instead
Do you know what is the replacement? I tried looking up DIP1000 but it only says "superceded" without mentioning by what.
This makes me wonder how ready D is for someone that wants to extensively use @safe though.
For local variables, one should use pointers, otherwise
refdoes references that are guaranteed to be valid to their lifetime, and thus have said limitations.
Should I take this to mean that pointers instead are not guaranteed to be valid, and thus are not memory safe?
Note that Rust does not "solve" memory management for you, it just checks whether yours is memory safe. Initially you might rely on the borrow checker for those checks, but as you become more and more used to Rust you'll start to anticipate it and write code that already safisfies it. So ultimately you'll still learn how to safely deal with memory management, just in a different way.
Rust for Linux used to be developed in parallel to the mainline Linux before Linus Torvalds merged support in the main tree.
"safe by default" can be done by starting your files with
@safe:
Last time I heard about that it was much more limited than Rust, for example it even disallowed taking references to local variables. Has something changed since then?
If you think this is normal then imagine what other people think of the linux community though!
But here's the issue: the parent comment didn't even provide reasons why they think Windows sucks or examples/episodes where this was a problem for them. It adds nothing to the discussion, just free hate.