linux VS nomicon

You're missing on a lot of things Rust (or any language with non-toy types) can provide. Lock ordering, better accessible complex structures, enforcement of enumerated options, rich description of APIs, and many others. Atomic values are usable transparently https://github.com/AsahiLinux/linux/blob/97c628055904a7f2ef1... and multithreaded reference counting is easily enforced https://github.com/AsahiLinux/linux/blob/bd0a1a7d465fcb60685... also issues like type confusion https://www.vicarius.io/vsociety/posts/a-type-confusion-bug-... are less likely if you can easily use tagged unions checked by the compiler.

From the gpu issue tracker[0]:

> For a bit of context -- Google Maps loads images to the GPU at.. inopportune times. While games would typically load their images during a load screen (so slow image loading just means longer loading screens), Google Maps loads when scrolling around I think (so slow image loading means the whole map stutters). I don't think there's a fundamental driver bug we can fix here, but we can make image loading a lot faster which makes the symptoms go away.

[0]: https://github.com/AsahiLinux/linux/issues/72#issuecomment-1...

> Is this mostly just a thing to get more young people interested in kernel development...allowing them to start out in less important areas and in a language they are passionate about?

Not likely. At the moment you need to do extra work to get Rust working well. It's not exactly beginner friendly and doing work in the kernel, you'll need to dig into C anyway.

> Or is this a serious proposal about the future of operating systems and other low level infrastructure code?

Serious code already exists, so... Yes?

> Do you just program everything in unsafe mode? What about runtimes?

Why would you? You need that only when interfacing with something that can't hold the Rust compiler assumptions. See for example https://github.com/AsahiLinux/linux/blob/gpu/rebase-6.4/driv...

The few places that need direct access / unsafe are almost all single-line areas with an explanation.

I think the idea with the M-series laptops in particular is that you can drive the speakers at volumes that actually damage them very quickly ( see https://github.com/AsahiLinux/linux/issues/53 ). The idea AIUI is that you can use a DSP along with a physical model of the voice coil to get better sound than you would if the speakers were volume-limited.

I am using Asahi Linux and the GPU driver works great, it even supports OpenGL 3.1 (https://asahilinux.org/2023/06/opengl-3-1-on-asahi-linux/). Definitely not alpha, I would say it's close to a "release candidate". Many bugs got resolved, nothing much left (besides newer OpenGL and Vulkan of course, but current state is very stable): https://github.com/AsahiLinux/linux/issues/72

There aren't really any non-trivial mainline modules, since the Rust support is so new. There's the non-mainline Asahi M1 GPU driver though! It will eventually be mainlined, but IIRC some more Rust support code needs to be mainlined first.

https://github.com/AsahiLinux/linux/tree/asahi/drivers/gpu/d...

You can follow the progress here: https://github.com/AsahiLinux/linux/issues/91

it’s even written by the same person that wrote the Nomicon (the guide to the dark arts of unsafe)

If you want to dive deeper you can always have other options but now there are concrete cases, if you want to do low level thing https://doc.rust-lang.org/nomicon/ while if you want multi thread/concurrency stuff https://marabos.nl/atomics/ . There are many many books so you will have to point yourself to what you want

Nonononono. SeqCst is the most error prone memory order: https://github.com/rust-lang/nomicon/issues/166

Hope this helps. For more details, see the Rustonomicon. I referenced the subtyping chapter here extensively.

Nice video! Glad I could help out. This stuff is hard, and I'm still learning a lot about it myself even years later. The Rustonomicon is a great read if you haven't already.

Have you got a moment to read through the good book , after reading through this perhaps try the Rustonomicon.

That is not what UB means. Undefined Behaviour is behaviour that the compiler is allowed to assume will never happen, and which can consequently cause miscompilations due to optimisation passes gone wrong if it does in fact occur in the source code.

It's true that Rust does not have a written specification that clearly delineates what is and isn't UB in a single place. But:

1. UB is impossible in safe code (modulo bugs in unsafe code)

2. There are resources such as the Rustinomicon (https://doc.rust-lang.org/nomicon/) that provide a detailed guide on what is and isn't allowed in unsafe code.

In practice, it's much easier to avoid UB in Rust than it is in C++.

However, this is a wide topic out of scope for a Reddit comment, so maybe just read the Rustonomicon. It explains everything about data handling in Rust.

The ownership model & borrow checker makes rust a bit of an awkward language in which to write complex data structures like trees and graphs. It can be done - since you can always use raw pointers & unsafe code when you absolutely need to to treat rust like C. But the language fights you, and the community can get a bit moralistic about this sort of thing. The rust nomicon is a fantastic resource for learning the limits of the borrow checker, and where and how to use unsafe code correctly. You will need unsafe less than you think you will, but sometimes you will have no choice.