Rust For The Linux Kernel Sent Out For Review A Fourth Time

[dragonn]

How "successful" a language is can be difficult to define.....but popularity and widespread adoption (especially by big companies) can be one indication of "success" right?

It can be if you are talking about languages with comparable adoption time on the market.
At the current moment it is like saying when the first smartphone come out that the regular old phones are more "successful" because the are more popular and widespread.
Or when MP3 players come out saying that cd players are more "successful" because the are more popular and widespread. Or pick any example you like.
They is no value in comparing a 40 years language to a 10 years old (and to be fair, the stable version is only 8 years old..., is they are any language with comparable lifetime and wider adoption? I can not think about any) one in terms of popularity and widespread

[akira128]

It can be if you are talking about languages with comparable adoption time on the market.
At the current moment it is like saying when the first smartphone come out that the regular old phones are more "successful" because the are more popular and widespread.
Or when MP3 players come out saying that cd players are more "successful" because the are more popular and widespread. Or pick any example you like.
They is no value in comparing a 40 years language to a 10 years old (and to be fair, the stable version is only 8 years old..., is they are any language with comparable lifetime and wider adoption? I can not think about any) one in terms of popularity and widespread

I was simply pointing out that the steady rise in popularity and increased adoption of Rust is an indication of its "success" as a language.
The time frame is irrelevant (albeit that helps on the "maturity" scale), it's the rate of adoption that really matters.

[dragonn]

I was simply pointing out that the steady rise in popularity and increased adoption of Rust is an indication of its "success" as a language.

Yes, that for sure. Didn't understand you point in this way, was to much focused on other people arguments here about raw comparing C and Rust popularity and adoption without getting the time context in mind

[mmstick]

https://kerkour.com/rust-in-production-2021/

Weird quote pick for System76. We've made better pitches for Rust in the past, and that was just a description of a small project.

This would be more appropriate: https://www.rust-lang.org/production/users (138 companies listed)

But it's only a small fraction of companies using Rust, because your company has to willingly and voluntarily request to be added to the Rust website. Apple, Google, Microsoft, IBM, and virtually all the fortune 500 won't bother.

[qm3ster]

But Rust doesn't use "garbage collection", it uses "unicorn farts that nobody can quite describe"

> "values are dropped at the end of the block they were declared in" is magical and incomprehensible
> it's very immoral when a library type can suggest a cleanup/reclamation strategy for itself
> now stop bothering me with this malarkey, I have more important things to attend to, like remembering to call MY_C_LIBRARY_STRUCT_FREE_METHOD(pointer_to_my_c_li brary_struct) before the last copy of the pointer goes out of scope, but only exactly once. (I also not only know exactly what the dynamically linked MY_C_LIBRARY_STRUCT_FREE_METHOD does, I control it, thank you for asking)

Jokes aside, thank you for inspiring the following:
Rust is excellent for an OS kernel because memory management is 100% up to the developer. You decide your own allocation strategy, you decide when and how to initialize memory, your own reuse strategy, and you decide when to free memory. There is no "unsafe" portion of the language that one must rely exclusively on in low-level scenarios. No "garbage collection", which is a "for dummies" feature. Rust is a win, and nothing else.
Gonna go copypasta it somewhere.

[binarybanana]

I like Rust a lot, it's a great language. I have even written a semi-popular project in it. The compile time safetey is great and makes writing insanely daring zero copy multithreadedcode almost a no-brainer.
But I wonder how much of that will hold for low level kernel code. At that level you don't only have to worry about memory safetey, but also about hardware state. I'm sure there are ways to encode some things in the type system, for example, to prevent enabling interrups while holding some kind of lock in a piece of code that initializes some hardware or whatever in a short loop that polls for readiness. But it will not help you to set the right magic registers to the correct value at whatever memory address the device is placed. So you can still easily trigger nasty bugs and "undefined behavior" if you get that wrong and the NIC or whatever goes apeshit and starts writing random crap into all memory it has access to through DMA or benaves strangeley in other ways the code doesn't expect or foresees to check for.
Luckily things like that can be mitigated with an IOMMU and testing drivers in a VM, which should (mostly) protect the host system in any case, so it's not that bad.I'll certainly enjoy hacking on Rust drivers much more than what we have now in any case.

[mmstick]

If you have any doubt about Rust being useful at the level of a kernel, spend some time reading the source code for the Redox kernel. You can also check out the embedded hardware projects that people are using Rust for. The code that interacts directly with hardware may be unsafe, but you can create safe abstractions from that. You can absolutely create newtypes and state machines to logically represent hardware states and prevent misuse of hardware APIs in a similar fashion that the Rust standard library provides safe abstractions for interacting with OS APIs.

https://gitlab.redox-os.org/redox-os/redox

https://github.com/stm32-rs/stm32-rs

[Vistaus]

Both are an attempt to make programming "easier" for people that cannot handle true low level programming.

If that attracts more developers and it's still as safe (which it is, because it's Rust), then that's a win in my book.

[Vistaus]

C is very mature but definitely not successful, at least not in terms of the quality of the software it has produced. It has been successful in terms of adoption because as you rightly say, for decades there was basically nothing else, so it was used by default.

Exactly! Hell, if we only kept using the adopted stuff rather than the good stuff, we'd have no over-the-counter drugs to cure headaches as drilling a hole into people's skull to alleviate headaches was very successful in terms of adoption wordwide. Just to name an example.
Or in software land: we'd all be using Windows rather than Linux. (talking about desktops, not servers where Linux is king)

[CommunityMember]

The most advanced and successful operating system kernels are written in C.

Actually, the most successful OSs (and their predecessors) were written in System 360/370/ESA/Z assembly language and (in some cases) PL/X. z/OS, z/VM, z/TPF, z/VSE are the current variants. While you may never have heard of those OS's, they do run a significant part of the underlying infrastructure and would be considered advanced and successful.