> The truth of the matter, though, is that the Rust community seems to want to take a different approach to concurrent data access.

Not knowing anything about development of the kernel, does this kind of thing create a two tier Linux development experience?

▲

zaphar 13 hours ago | parent [-]

Not sure if it introduces a tiered experience or not. But reading the article it appears that the Rust devs advocated for an api that is clearer in it's semantics with the tradeoff that now understanding how it interacts with C code requires understanding two APIs. How this shakes out in practice remains to be seen.

▲

thenewwazoo 10 hours ago | parent [-]

Advocating for an API with clearer semantics has, afaict, been most of the actual work of integrating Rust into the kernel.

▲

zaphar 10 hours ago | parent [-]

That is my understanding from the outside as well. The core question here should, I think, be whether the adoption and spread of clearer semantics via Rust is worth the potential for confusion and misunderstandings at the boundaries between C and Rust. From the article it appears that this specific instance actually resulted in identifying issues in the usage of the C api's here that are geting scrutiny and fixes as a result. That would indicate the introduction of Rust is causing the trend line to go in the correct direction in at least this instance.

	▲	thenewwazoo 10 hours ago \| parent [-]
		That's been largely my experience of RIIR over years of work in numerous contexts: attempting to encode invariants in the type system results in identifying semantic issues. over and over. edit to add: and I'm not talking about compilation failures so much as design problems. when the meaning of a value is overloaded, or when there's a "you must do Y after X and never before" and then you can't write equivalent code in all cases, and so on. "but what does this mean?" becomes the question to answer.