The title sounded worse than it is.
Rust in the kernel is no longer experimental
61–70 of 853 posts
Re: Rust in the kernel is no longer experimental
#62Earlier quoted context omitted.
People can learn Rust at any age. The reality is that experienced people often are more hesitant to learn new things. I can think of possible reasons: Early in life, in school and early career, much of what you work on is inevitably new to you, and also authorities (professor, boss) compel you to learn whatever they choose. You become accustomed to and skilled at adapting new things. Later, when you have power to mak…
I still think you're off the mark. Again, most existing Rust developers are not "blank slate Rust developers". That they do not rush out to rewrite all of their past projects in C++ may be more about sunk costs, and wanting to solve new problems with from-scratch development.
That's fair; my claims are kept simplistic for purposes of space and time. However, I'm talking about new projects, not rewriting legacy code.
Re: Rust in the kernel is no longer experimental
#63Oh dear can you imagine the crushing complexity of a future Rust kernel.
[deleted]
Re: Rust in the kernel is no longer experimental
#64Does the removal of “experimental” now mean that all maintainers are now obligated to not break Rust code?
Re: Rust in the kernel is no longer experimental
#65Not a system programmer -- at this point, does C hold any significant advantage over Rust? Is it inevitable that everything written in C is going to be gradually converted to safer languages?
Every system under the Sun has a C compiler. This isn't remotely true for Rust. Rust is more modern than C, but has it's own issues, among others very slow compilation times. My guess is that C will be around long after people will have moved on from Rust to another newfangled alternative.
Doesn’t rustc emit LLVM IR? Are there a lot of systems that LLVM doesn’t support?
Re: Rust in the kernel is no longer experimental
#66Earlier quoted context omitted.
C currently remains the language of system ABIs, and there remains functionality that C can express that Rust cannot (principally bitfields). Furthermore, in terms of extensions to the language to support more obtuse architecture, Rust has made a couple of decisions that make it hard for some of those architectures to be supported well. For example, Rust has decided that the array index type, the object size type, an…
That first sentence though. Bitfields and ABI alongside each other. Bitfield packing rules get pretty wild. Sure the user facing API in the language is convenient, but the ABI it produces is terrible (particularly in evolution).
I would like a revision to bitfields and structs to make them behave the way a programmer things, with the compiler free to suggest changes which optimize the layout. As well as some flag that indicates the compiler should not, it's a finalized structure.
Re: Rust in the kernel is no longer experimental
#67This title is moderately clickbait-y and comes with a subtle implication that Rust might be getting removed from the kernel. IMO it should be changed to "Rust in the kernel is no longer experimental"
I think on HN, people generally want the submission's title to match the page's title. (I do agree it's clickbait-y though)
I think on HN, people waste too much time arguing about the phrasing of the headline, whether it is clickbait, etc. and not enough discussing the actual substance of the article.
Re: Rust in the kernel is no longer experimental
#68Not a system programmer -- at this point, does C hold any significant advantage over Rust? Is it inevitable that everything written in C is going to be gradually converted to safer languages?
Rust still compiles into bigger binary sizes than C, by a small amount. Although it’s such a complex thing depending on your code that it really depends case-by-case, and you can get pretty close. On embedded systems with small amounts of ram (think on the order of 64kbytes), a few extra kb still hurts a lot.
Re: Rust in the kernel is no longer experimental
#69Oh dear can you imagine the crushing complexity of a future Rust kernel.
There’s one already — they seem to be doing decently well.
Re: Rust in the kernel is no longer experimental
#70Earlier quoted context omitted.
C currently remains the language of system ABIs, and there remains functionality that C can express that Rust cannot (principally bitfields). Furthermore, in terms of extensions to the language to support more obtuse architecture, Rust has made a couple of decisions that make it hard for some of those architectures to be supported well. For example, Rust has decided that the array index type, the object size type, an…
I'm genuinely surprised that usize pointer convertibility exists. Even Go has different types for pointer-width integers (uintptr) and sizes of things (int/uint). I can only guess that Rust's choice was seen as a harmless simplification at the time. Is it something that can be fixed with editions? My guess is no, or at least not easily.
There is a cost to having multiple language-level types that represent the exact same set of values, as C has (and is really noticeable in C++). Rust made an early, fairly explicit decision that a) usize is a distinct fundamental type from the other types, and not merely a target-specific typedef, and b) not to introduce more types for things like uindex or uaddr or uptr, which are the same as usize on nearly every platform.
Rust worded in its initial guarantee that usize was sufficient to roundtrip a pointer (making it effectively uptr), and there remains concern among several of the maintainers about breaking that guarantee, despite the fact that people on the only target that would be affected basically saying they'd rather see that guarantee broken. Sort of the more fundamental problem is that many crates are perfectly happy opting out of compiling for weirder platform--I've designed some stuff that relies on 64-bit system properties, and I'd rather like to have the ability to say "no compile for you on platform where usize-is-not-u64" and get impl From for u64 and impl From for usize. If you've got something like that, it also provides a neat way to say "I don't want to opt out of [or into] compiling for usize≠uptr" and keeping backwards compatibility.
If you want to see some long, gory debates on the topic, https://internals.rust-lang.org/t/pre-rfc-usize-is-not-size-... is a good starting point.