That seems like a non sequiteur. Did you watch the video? Did you hear what the presenter was asking for? Technical feedback on the API semantics they were describing. A heads-up if breaking changes to those APIs were about to land, so they can update bindings. They were bending over backwards to be accommodating. None of this is the entitled behaviour you describe.
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?
That seems like a non sequiteur. Did you watch the video? Did you hear what the presenter was asking for? Technical feedback on the API semantics they were describing. A heads-up if breaking changes to those APIs were about to land, so they can update bindings. They were bending over backwards to be accommodating. None of this is the entitled behaviour you describe.
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?