I recommend you do not duckduckgo for that.

Oh yes he duckduckdid.

You duckduckwent.

I hope you have the time of your life in my ass.

You’re gonna need a portal gun or a time machine or some pretty unusual anatomy.

Oh yeah, rust has to win, but I think this was an empathy-free paradigm war masquerading as an innocent request for information. I think trying to bolt rust into Linux is a strategic error. It’s going to cause quite a lot of unnecessary friction and an awful lot of unnecessary technical complication and will be absolutely riddled with complexities and ways of doing things that are inherently unsafe. Instead build a posix compliant OS as rust from the bottom up and it’ll knock the spots off Linux and will be rock solid. It’ll take well over a decade but it’ll be far, far better.

TL;DR: Vast culture clash that rust guys didn’t perceive and C guys hated and false assertion that “you don’t need to learn rust” based on inexplicably naive lack of understanding that maintenance might be necessary.

If someone builds a rust api on top of your C code inside your project, you have exactly five choices: (1) preserve the assumptions the rust code is making (2) only change your code if you have a rust expert to collaborate with handy (3) edit the rust code yourself (4) break the rust assumptions leading to hard to find bugs (5) break the build. The C guys hated all five of those options, and the rust guys told them they didn’t need to worry their pretty little heads about it. ON, they weren’t as dismissive as that, but they either didn’t understand those as issues or didn’t care about them or dismissed them.

The rust guys were asking the C guys to tell them the semantics so that they could fix the type signatures for their rust functions and the C guys were reluctant to do that because they wanted to be able to change the semantics of that turned out to be useful to them. They didn’t want to commit so something that was documented in a way they weren’t familiar with because they felt that even if they wanted to, they couldn’t ensure their code was compliant with this specification going forward because they didn’t understand the rust type signature fully. (They got hung up on the self argument and launched a rant against OOP.)

The rust guys knew instinctively that the Result return type meant that the operation could fail and could tell from the two arguments to that both in what ways it could fail and every kind of answer it could produce if it succeeded, but the C guys found almost none of that obvious. This was for just one function in the rust API, but it also radically changed the way of doing it. This one rust call replaced the whole algorithms of ask, check answer, if none, check this and that, otherwise do this blah blah blah. The C guys are used to keeping everything lean and simple with a single purpose and were being asked to think of a while collection of procedural knowledge and edge cases with a handle everything monolith. But they were audibly reluctant to commit to that being all the edge cases because they don’t think of all of those tests as one thing and instinctively wouldn’t write something that checks for all of the edge cases because (a) in a lot of circumstances the code they’re writing only needs to know that there was a problem and will give up quickly and move on and (b) they want to be able to freely choose to add other edge cases in the future like they normally do without having to worry about the rust code breaking.

They weren’t complaining that they were being asked to write rust, they were complaining that they didn’t want to learn rust, and they were complaining this because they could see that to preserve all the rust API type signatures they would have to understand them, the expectations around them and memory safety principles, so that a rust programmer in the future wouldn’t have to change the rust type signature.

The rust guys would have gained a lot more traction by just asking the C guys to keep a bunch of comments up to date detailing the semantics and error checking procedures, and promising to edit their rust API if the C code changes, but I suspect they didn’t ask for that because they know that no guarantees come from a comment and they want to be sure that the rust code works across all the possible scenarios and in rust culture, that is always documented in the type system where it can be enforced.

The rust guys spoke like it was self evident that having a monolithic API with a bunch of stuff guaranteed by the rust compiler was best, but seem not to have realised that this is a massive culture clash because the C guys come from a culture of rejecting the idea of compiler guarantees anyway (because they have long had confidence in their ability to hand optimize their code to be faster than some prescriptive compiler’s output and look down on people who choose to have the guardrails up).

They felt like they were being asked to help write an interface definition in a monolithic style that they have always rejected, to achieve goals that they have long resisted, in a language that they find alien, with no guarantees for them that the rust guys were going to stick around to agree and implement the rust changes necessary if they changed the C code, and with no confidence that they understood what would count as a breaking change at the rust level.

This perceived straightjacket made them particularly cross. They complained about the inability to change their C code and its semantics and the need to learn enough rust to understand quickly what not to change, but they didn’t want to not change things and would need to edit the rust API at the same time as editing the C code if they didn’t want the rust build to break, and then there would be even more downstream changes from that, so realistically they would need not only to be able to understand the rust type signatures, they would need to be able to edit both the type signatures and the functions themselves, and basically maintain all the downstream rust, and they would want to be sure they were writing efficient rust, well aware that it took them decades to get to the level of extreme efficiency they write in pure C, a much simpler language.

The rust guys said “Just tell us what your code means so we can write our type signatures”, but the C guys didn’t want to help create for themselves a prison whose walls were of a strange and intricate design they found hard to perceive, made out of materials they didn’t have experience working with. They felt like the first guys were asking them how all the doors, windows, chimneys, air vents etc of the house that they built by hand would ever be used, so they could encase it in a stainless steel shell and make it part of a giant steel city. The C guys said “but I might want to build an extension or a wider garage!” They claimed that the C guys didn’t have to learn how to weld or manufacture steel sheets, and that their house would be much safer, but for some reason this didn’t win the C guys round to the plan, and there’s a bunch of people online calling the C guys tech luddites for not liking the whole thing and saying that they were incorrect that they needed to learn rust just because the rust guys made that claim, but that claim is actually completely incorrect unless you think that it’s OK to stop the project compiling with your pull request or you think that changes to the C code should be banned wherever a rust API is built on top of it.

I saw the clip previously. The rust guys are absolutely assuming that the C guys would go for something because (a) the compiler guarantees it’s memory safe (b) the semantics would be encoded in the type system. They demonstrate this using rust terminology and algebraic data types. Algebraic data types are the bees knees, (but not with that syntax and clumsiness), and compiler guarantees are the bees knees, but that’s not how a C programmer who’s middle aged sees the world, it just isn’t. Your typical middle aged C programmer grew up telling pascal programmers that automatic array bounds checking is for wimps and real men use pointer arithmetic and their programs run five times as fast. They were always right because their programs did really run significantly faster, but now rust comes along and its fast and safe. Why wouldn’t C programmers like it? Because the speed was the excuse and the lack of guardrails was the real reason they liked C.

I said it’s a massive culture clash that the rust folks didn’t realise they were having because they just assume that “memory safe” wins people round, whereas C folks value their freedom from automatic compiler-based safety, and here you are, sounding like a rust person, saying it isn’t a culture clash at all and that the rust folks are right about memory safety and the C folks are just being irresponsible.

Expecting C programmers to like a compiler-based approach to memory safety is like expecting petrolheads to like a car purely because it’s electric. They have always viewed compiler based memory safety techniques as guard rails for novices. In their view, good bowlers don’t need guard rails at the bowling alley. It’s a massive massive clash of cultures and the rust folks come into the discussion with an assumption that C devs would leap with joy at the chance to automate memory management. Rust and C are complete opposites, but rust programmers seem to assume that just because rust is fast C programmers will love it.

I watched the video. The presenter is explaining how it’s really helpful to encode the semantics in the type system and the co presenter was talking about how algebraic data types are great for this kind of stuff. They wanted the C guys to agree a semantics for some file system api stuff, but some of the C folks were very reluctant to commit to a semantics that they weren’t convinced covered all the edge cases and that was going to be encoded using concepts they’re unfamiliar with and syntax that looks alien to them.

The whole “but look at all the guarantees this gives you, see how much effort and worry the compiler now handles for you, and how while classes of bugs simply cannot happen!” thing is stuff people have been saying to the C programming community for well over three decades. It didn’t wash with them then, why would it wash now?

Pascal advocates said “look how the compiler does array bounds checking for you, you need never segfault again” and the C programmers said “yeah, your program quits with a pretty and polite message about how it ran out of space and mine segfaults, but mine runs twice as fast as yours and your syntax is stupid, I’m sticking query my curly braces.”

Lisp programmers said “macros? Those aren’t macros. You have no idea what power real macros have. Imagine if your code could edit itself!” and the C programmers said “that meant parens would give me RSI and my code runs five times as fast as yours.”

Pure functional programmers have been extolling the virtues of algebraic data types (and immutability by default, and automatic memory management) for decades, but the C community has never wanted to know, why would they now?

The C community heard all these ideas, and all these lovely guarantees, and has repeatedly said “See those guard rails at the bowling alley? I don’t use them. They’re for people who aren’t good at bowling. If you want a big guiding abstraction that really works in practice, here it is: everything is just a stream of bytes. Simple, effective and FAST.”

Expecting compiler guarantees and memory safety to win round a C programmer or someone that’s into dynamic types is like expecting a motorbike rider to trade their bike for a pickup truck on the grounds that it’s so roomy and robust. They’ve never wanted that. It’s a massive, massive culture clash that the rust folks don’t see at all, because they know they’re right, they’ve seen the light, they know the truth, and it’s fast and fast enough for full on systems programming so they’re in the same club as the C folks, but the C folks didn’t want to be saved from C because they never weighed the risks as high as other folks did.

It reminds me of two Republican women whose children were badly traumatised in a genuine active shooter crisis at their school, and they realised that they’d been downplaying it and that actually this was a really serious issue that needs fixing, but they were very surprised, baffled and hurt that their Republican friends, councillors and law makers didn’t realise like they did how important this stuff was and continued to downplay it as if the children’s trauma was somehow less important than their friends political beliefs.

Summary: rust folks are very late indeed to the “aren’t compiler enforced guarantees great” party, and these C folks have been turning down invitations since forever. They’re going at it with missionary zeal to the very community that ignored 100% of the previous missionaries, and are surprised that they’re getting so much push back and resistance to what they feel so inevitably has to happen in the end and so clearly the Right Thing.

C is where the people who love the speed and freedom of manual memory management hang out. Why would anyone expect a 35 minute talk to change all of that?

Personally I always think it’s weird when people expect open source authors to implement their preferences for them. Just stop acting like your priorities are inevitable. They’re not. Why should everyone else drop everything and do it your way, even if it is in your view obviously better?

It’s just that if I were the FBI, or the CIA, or a large criminal organisation, why wouldn’t I be putting a lot of money and the best people I could find on sneaking backdoors for tor into the onion somehow. What a treasure trove of the most potent information there is there! If you can crack tor, you own the keys to the underworld and enough blackmail fodder to get you almost anything you want.

Why wouldn’t tor be compromised?

Oh, I’m totally wrong and had mixed the two up, sorry.

Ah OK, yes. Then “Hey, Intel, Red Hat, Linaro, IBM and 500 other companies and a bunch of other people, You have to make this massive C project rust compliant otherwise you’re tech luddites.” It’s still entitled.

The Linux kernel folks say that the rust folks missed the deadline for major code changes and the project is currently in minor bug fix mode prior to release. They weren’t prepared to accept thousands of lines of changes at this point on the grounds that introducing new regressions without time to fix them is a real risk. So timing is claimed to be an issue.

It looks to me like there’s a bit of deadline ignoring going on, but even if it really is at heart reluctance to learn rust, aren’t a lot of linux developers volunteers? Getting cross that a bunch of volunteers don’t want to commit to permanently supporting rust (with its famously steep learning curve and famously hard to please borrow checker) seems a bit entitled to me.

“You there! Volunteers! Get on with doing exactly what I want exactly the way I want it and before you release your next version. Stop resisting the inevitable rise of your new priority: doing things our way. It’s better, so you’re wrong. Quickly now, stop resisting.”

Yeah, but you don’t have more than two options for president of the united states. You have the one supporting unions and the weird racist loony hater one. Anyone suggesting something else might happen this year is lying to you.

I suspect I’ll regret asking, but what is this?

BoTH SiDes