one_even_prime

Apple chips share the same physical memory between the GPU and the CPU. Still, they don't have USM/UVM (Unified Shared Memory/Unified Virtual Memory), that is, the GPU and the CPU can't access the same data concurrently and easily. Programs must map/unmap pages to control which device accesses it, and that's a very expensive operation.

Who was that guy?

More like: the Linux kernel re-implementation of Rust "print" has a bug that causes it to not adhere to Linux kernel conventions.

I'd expect that now that the bug has been reported, it'd be fixed by just hashing pointer addresses before printing them.

I also expect that "reimplementing X in a different programming language" introduces logic bugs, like the one above, and that those involved have deemed what they get out of it worth the effort of hashing these sort of bugs long term.

From the kernel pov, all of these bugs are safety issues, so the article authors are surprised the unsafe keyword is not required to introduce them, but from Rust's pov, they are just logic bugs, which safe Rust does not protect against. One of the main challenges those working on Rust in the kernel will have is figuring out how to educate other kernel developers about Rust (what it does and does not protect against, setting the right expectations, etc.). I think these articles are a great step in that direction.

Not leaving room for a language below C++ is one of C++ core values. The C++ memory model (and its execution model btw) _is_ a GPU memory model. Some of the major GPU vendors are already able to run standards conforming C++ on their GPUs (e.g. AMD via rocm-stdpar, Intel via the onedpl/algorithm header, and nvidia via their nvc++ compiler). The main reason OOTA and RFUB aren't solved problems in C++, is because the trade-offs of sburf-acyclic are at tension with C++ core values.

Given the importance of GPUs on modern computing systems and the time and effort it has taken C++ to get here, I have a hard time imagining any change to the C++ memory model that would regress this support.

Rust is different: it has a different audience and goals, and it has already painted itself into a design corner that prevents it from properly supporting even modern CPU hardware (e.g. Arm CHERI and RISC-V CHERI with 128-bit and 96-bit pointers). A memory model for Rust that is more restrictive than the C++ memory model and which prevents Rust from natively running on more modern hardware like GPUs, could be a valid point in Rust's design space, if these restrictions were to buy Rust programmers simplicity, productivity, or safety.