Windows 11 Insider Preview Build 25905 brings a bit of Rust in the kernel
blogs.windows.com
blogs.windows.com
"In celebration of Marvel Studio’s Guardians of the Galaxy Volume 3, we temporarily re-launched Zune.net last month. We also took the opportunity to fix an issue that was causing some challenges in getting the original Zune drivers to install in Windows 11 with this build in the Canary Channel. So now it should be easier to use your (totally unsupported and still discontinued) Zune on Windows 11."
It was a joke, like saying, "You're finally with the times. Drop your tape deck, here's a Zune!" It wouldn't have landed the same way with an iPod.
Not everything is a "product placement".
In this case it was a nostalgic, offbeat item, to funnily convey those things about the character that would use one, like the Walkman and music choice was in the first movie.
Just hard to tell what's sarcasm on the internet now.
So much for the "iPod killer". And then for the Windows Phone "iPhone killer" that replaced it. The tech press is so predictably wrong, with BS clickbait headlines.
There is even a template library for it, Windows Implementation Libray, WIL.
C++ has been usable in the Windows kernel for a long time but you need to make sure that code ends up in the correct PE segment types for pageable and non pageable code and that there are no hidden gotchas for features like exception unwinding and that new can use paged or non paged pool appropriately. Same for Rust: getting to a nostd etc that is compatible with kernel use.
I think there’s a strong case that many drivers could be written with either a user mode driver framework or a small VM. Most of the hardware devices I’ve worked with we just need fast transfers of data to user mode buffers so our application can handle it, and the code is mostly boilerplate framework code plus setting up device registers to set up DMA transfers. I don’t see why that couldn’t be handled with say an EBPF or WASM equivalent byte code.
https://community.osr.com/discussion/291326/the-new-wil-libr...
> wil was primarily developed by the Windows shell team for writing usermode code, but the NDIS and Bluetooth teams have contributed some small kernel-specific features. Here's a few examples of how you can use wil in your kernel driver:
A more serious counter argument is that Mozilla did exactly this with Rust in Firefox - and it seems to be a success, there's still lots of Rust in the browser and it seemingly is working.
Point being, using Rust for all of the things will probably be painfully cumbersome today, but writing up a complicated enough component with a well defined boundary with the rest of the kernel will probably prove immensely useful and won't be painfully cumbersome.
In this case it's helpful. I've wanted to do similar in the past but been hesitant as was under the impression it breaks HN rules or etiquette.
Key bit: "unless it is misleading or linkbait"
Editing or even completely rewriting the title seems to be okay as long as it's accurate and not inciteful or opinionated. I've done it when there was no title or the title didn't say anything meaningful with no complaints.
If I remember correctly, there is a safe dialect of Ada but it was difficult to setup on Linux. Is that still the case ?
[0] https://www.reddit.com/r/ada/comments/mme3jk/is_ada_memory_s...
Shouldn’t readability/ understandability be a critical requirement for kernel code?
Kernel code should be easily readable and understandable, shouldn’t it?
If Rust is complex and hard to understand won’t that lead to the kernel source code becoming a giant kablooie of complexity?
Surely the relatively simple nature of C is what makes it suitable for large scale kernel development.
Maybe the answer for more secure kernel code is C with better security analysis tools?
Rust is hard/simple. The rules aren't complex. The constructs aren't complex. But it's hard to write because the rules are very restrictive.
Rust is also much easier to read than write (for a reader who understands the rules).
It's optimising for exactly the things you want in systems programming:
Easier to read than the write. Simple rules that are easy to understand but hard to follow, and that produce simple programs.
Compare that to C which is easy/complex. It's much easier to write than to read. It's easy to learn and write but produces code that's very complex. The rules are all by convention instead of part of the type system.
So you’re saying it’s not a problem to understand if you understand it.
Its pretty easy to learn the rules. Once you've done that you can watch a game and know roughly what is happening. But its still a hard game to master.
> The rules aren't complex. The constructs aren't complex.
So yes, once you understand it, you understand it, but they also specifically said it's not hard to get to the point of understanding it. If we're going to assume that any out-of-context quote is equivalent to the entirety of the content, I'll just cite you on this one:
> it’s not a problem
And the number of bugs per line of code is constant, so you will have more bugs in C code than in Rust code simply because you'll have more code.
the relatively simple nature of any language would make it suitable for ANY large scale development
I dont know why you attribute this to kernel development specifically. When you think about kernel development, the uniqe requirement is never "being simple". I would think it has something to do with being closer to bare metal and can do low level instructions performantly.
> Maybe the answer for more secure kernel code is C with better security analysis tools?
Perhaps like a way of expressing the constraints of a program and automatically checking if portions of a program satisfy those constraints. Aka a type checker.
>C is not simple. It is small.
C is complex because of undefined/unspecified/implementation defined behaviour. Any language which is used on as wide of a range of platforms will have those issues.
That is why in the Windows kernel, according to https://en.wikipedia.org/w/index.php?title=Windows_NT&oldid=..., C++ is rather avoided, and C is preferred for kernel code (for user-mode code, the priorities are reversed):
"Windows NT is written in C and C++, with a very small amount written in assembly language. C is mostly used for the kernel code while C++ is mostly used for user-mode code. Assembly language is avoided where possible because it would impede portability."
C++ supported in the kernel since Vista,
https://learn.microsoft.com/en-us/cpp/build/reference/kernel...
"The new wil library for C++ code in drivers"
https://community.osr.com/discussion/291326/the-new-wil-libr...
> wil was primarily developed by the Windows shell team for writing usermode code, but the NDIS and Bluetooth teams have contributed some small kernel-specific features. Here's a few examples of how you can use wil in your kernel driver:
>C++ supported in the kernel since Vista
Both of those things code be true.
I would argue rust is hard to learn, and not hard to read or understand once you know it. In my opinion, for example:
Hard to learn, easy to read: Rust Easy to learn, hard to read: Perl Hard to learn, hard to read: C++ Easy to learn, easy to read: Python
Even if you don't agree exactly with my opinions, you could maybe see the distinction between (easy/hard to learn) and (easy/hard to read, once you learned it).
I also think that 99% of the difficulty in learning rust is learning how to get to a compiled state. Once the binary is built, you can make a lot more assumptions about it than other binaries (for example, locations of crashes, overflows, ownership, memory freeing can all be detexted). Compare that to c or c++ where getting to a compiled state is way easier, but the resulting binary segfaults or other issues.
Hard to learn, easy to read: Rust
Easy to learn, hard to read: Perl
Hard to learn, hard to read: C++
Easy to learn, easy to read: Python
The problem with this assertion is that it says a lot of different things, some of which I'd believe to be true, and some of which I do not.
> Shouldn’t readability/ understandability be a critical requirement for kernel code?
I don't think anyone is going to say "readability is not important," but the problem is that there's a looming question of "for whom"?
This is basically part of the issue here. You are making an incredibly broad generalization about a fairly complicated topic, one of which we don't even have a lot of evidence about, but many opinions.
https://opensource.googleblog.com/2023/06/rust-fact-vs-ficti...