In general I have to work off of their purported goals and priorities to get a feel for where the final destination of the language will be when it's more complete.
If they say they aren't going to prioritize machine semantics, C-level runtime performance, or systems-grade control over code generation then I have assume those priorities will fall wayside to the established priorities of safety and concurrency.
I'm not saying Rust will "fail" like Go seems to be doing so far, I'm just saying I don't think they're going to prioritize making Rust useful for driver development[1].
[1] Which I think is brilliant anyway. It's solving a very hard problem that needs solved.
Your hunch is correct, Rust's developers have stated that Rust isn't aiming to be a language with which to implement kernels or device drivers.[1]
It's interesting to see that the domain of "systems" programming languages appears to be splitting into "kernel-level" domains and "perfomance-critical application-level" domains. In this light, it seems more like C++ is the one caught straddling the gap. Should be interesting to watch this space for the next decade or so.
Go isn't failing. It's actually doing quite well. I disagree with the design and implementation of almost every part of the language, but credit where credit is due: Google has created a language that a lot of people like.
In general I have to work off of their purported goals and priorities to get a feel for where the final destination of the language will be when it's more complete.
If they say they aren't going to prioritize machine semantics, C-level runtime performance, or systems-grade control over code generation then I have assume those priorities will fall wayside to the established priorities of safety and concurrency.
I'm not saying Rust will "fail" like Go seems to be doing so far, I'm just saying I don't think they're going to prioritize making Rust useful for driver development[1].
[1] Which I think is brilliant anyway. It's solving a very hard problem that needs solved.