Memory safety can be addressed via kernel tools or frameworks and should not be the job of a language IMHO.
Memory safety could've been addressed through kernel tools and frameworks for decades, but it hasn't. And it _should_ be part of the language, as even low level languages like C try not to clobber memory and specify undefined behaviour in cases where you may accidentally end up doing it anyway.
There are good arguments for and against other Rust features such as the way panic!() works and the strictness of the borrow checker. However, "C and tooling can do everything your fancy pants new language does" has been said for longer than I've been alive and yet every month I see CVE reports about major projects caused by bugs that would never have passed the Rust compiler.
Out of every reason I can think of, a lack of hardware support seems like the least likely reason for a hardware manufacturer not to upstream hardware support. Look at companies like Qualcom, with massive ranges of devices and working kernel drivers, hacked together because upstreaming doesn't benefit them. Look at companies like Apple, who doesn't care if their software works on Linux or not. The Linux kernel supports everything from 90s supercomputers to drones to smart toothbrushes, there's no lack of hardware support.
it’s clear from your comment you never built a device yourself running linux on an obscure SoC dealing with patches that were never accepted.
Applying patches to the Linux kernel isn't that hard? Porting abandoned code sucks, but putting in the work to finish and include the patches would just move that annoying work to the rest of the kernel instead of a few people working on weird SoCs.
> essentially you are saying rust is great because companies can hire clueless people and rust will compensate for their inability
That's not what I'm saying, at all. What I'm saying is that nobody is perfect, not even C developers. Even if the mythical perfect C developer, who writes bugless code, does all the necessary sanitization, and always applies the necessary layers of tooling even when personally inconvenient, does exist, they can make better use of their time by using a language toolset that doesn't necessitate that extra work in the first place, regardless of whether that's Rust, C++, Zig, Frama-C, Carbon or Jakt.
The "everybody who makes mistakes is clueless" crowd is exactly why C developers get such a bad rep. C compilers have a billion warnings and -Weverything -Wnoimeaneverything -Wnoeverysinglething exactly because C developers, like any other developers, need help.
And Rust does seem to be increasing the rate and level of support small outfits can offer - see Asahi Linux for an example of that.
if your usage requires that fine. don’t place your requirements on other users.
also you are basically saying adopting linux is only for big tech. i don’t think that is in the spirit of open source.
> if your usage requires that fine. don’t place your requirements on other users.
Conversely, if you don't care about code quality feel free to not use Linux or make your own in-house patches without contaminating the kernel other people are trying to use.
> also you are basically saying adopting linux is only for big tech. i don’t think that is in the spirit of open source.
If only "big tech" can write kernel code safely then so be it. Of course, I think that premise is nonsense, but I don't care about the onramp enough to compromise on security.
Have you written much C or C++? What kind of kernel tools or frameworks are you thinking of? Have you ever used Rust? Are you familiar with the different kinds of memory errors?
I really struggle to imagine how anyone who is actually familiar with all this stuff could say things like this but you aren't the first...
i don’t need or want rust.
I think most C++ people will (after using it for a while) begrudgingly admit that it is a very nice language, at least in some regards.
So do you just not mind the frustration and time wasted debugging these issues?