Too little, too late. Hector mentions a Rust for Linux dev who also quit due to disagreements with the same maintainer, and that maintainer mentions
this video as a reason. I remember watching it last year when it happened and the whole thing is bananas. The entire interaction in the video is a veiled threat of purposely breaking the Rust side all the time to make it unmaintainable, and no one cares. It's beyond childish.
If you work for a smaller company, relish that you don't have to deal with this sort of thing on the regular. I find that larger companies also tend to start picking up behaviors like this as they grow, and the politics can get rather messy quickly because there's a bunch of these sorts of guys in the mix, both in management and as technical leadership (architects in my neck of the woods).
And from higher up, the way it's being handled is absurd to me. If they believe Rust is the future, and going to be a key part of the Linux kernel, it's ridiculous to keep up with the "Oh no one will force you to learn Rust. You can just keep writing C code and breaking any Rust code whenever". It's just a different programming language FFS. The stance should be "yes you WILL need to learn Rust to keep maintaining this part of the kernel". The very idea that parts of the same subsystem in a different programming language are automatically "not my problem" needs to be rooted out.
How I read the "No one will force you to learn Rust" stance was to try to win over maintainers by having the Rust 4 Linux maintainers take on the burden of the Rust bindings/etc early on. When a project is run as a series of fiefdoms, sometimes you have to start by appeasing the local feudal lords like the guy in the video.
At some point, the core maintainers
will have to take on Rust, I agree. But the thinking was to try to get Rust rolling by not trying to bootstrap a bunch of kernel maintainers on Rust before anything could be merged which would be unbearably slow and mean that they aren't learning much of anything about how to make Rust work well in the kernel while that happens.
IDK if this is a cultural thing or something. I started as an iOS app developer a few years after the Objective-C to Swift transition started. I mostly wrote Swift code, but occasionally I had to dive into the ObjC code to fix bugs or make small changes to adapt the Swift changes. The responsibilities of each developer were defined by the team/role we were in, not by the programming language the code was written in. That's just absurd. The entire migration would have been a disaster had we just refused to fix anything beyond the language we were most comfortable with.
This is generally been my experience as well. Back when I started, it was maintaining .NET 2 code, scripts, C/C++ interactions, etc. But there was an understanding that there's definitely nuances that take you time to ramp up on. Rust/Swift/Obj-C all have a bunch of things that C simply doesn't. I wouldn't expect someone coming from C to take up Rust all that quickly, because there are a lot of semantical differences, not just syntactically. And this means the knowledge you've gained on heap vs stack, data locality, etc are going to be different in subtle ways that take a bit to sink in, but are ultimately very important when writing low-level code like this. Doing that while also managing all code flowing into your component
is a burden, and I can understand a bunch of crotchety types getting upset at the idea that they won't know what's in a PR as well as they do today.
As Swift is derived in part from Obj-C, and the lessons Apple had learned in the decade or so using it on the Mac and iOS, there's much more semantic overlap. The memory management model in particular is very similar, with a few key differences that were honestly things that needed to change from Obj-C.
9to5mac.com
