You have to continually practice fluidity and actively learn things lest you solidify and lose that skill like any other.

I’m all for keeping one’s cognitive skills. However it is a fact that this decline happens, and that there is a phase of life where one has wisdom without necessarily having the same raw intelligence they had before. The wisdom is encoded in crystallized intelligence.

By wisdom here I mean “The tendency to make decisions that turn out well”.

My father was an equipment operator well into his 70s. After he retired they kept bringing him back to train the younger guys, and to get things don’t they couldn’t get done.

That was possible because those machines don’t change too much as time marches on. Because they use a stable platform, his organization was able to do better work by relying on his deep expertise. He could train those younger guys because it was the same platform he’d always used. Same dirt, same physics, mostly the same machines, same techniques, same pitfalls, etc.

His fluid intelligence is almost zero. The man’s practically an ASIC at this point, yet he’s fascinating to talk to and competent in the world. Fluid intelligence is not the only way to get things done.

We of course play plenty of video games together to keep him sharp. We also eat mushrooms, paper when necessary, and he works out a lot. We do all we can, believe me.

PHP is still in use and Wordpress is still somehow a behemoth. But the fact is that PHP has fallen out of favor, isn't used by new projects, and there's less demand for people with that skillset

Also while I’m driving, my Uber app locks up. Siri talks to me in a halting, broken voice, and responds with “something went wrong”. Google Maps shows a brief flash of my home before flipping to my current location. Then back to home again, then back to my current location. Spotify doesn’t remember what song I was listening to. Amazon Prime Video can’t remember what episode I was last watching.

Enshittification is everywhere. Our tech is buggy as fuck and solved problems in project management and devops are recurring. It’s not just about focusing on advertisers’ needs over customers. It’s also about wanting to kick out the greybeards as part of our great cultural revolution. It’s about driving trains into tunnels without adequate ventilation because fuck the previous generation thinking they know better than me.

It is the case that new technologies are introduced all the time, but that’s not necessarily right.

This example doesn't work as well with C/++ since that's older than most people here (though the language has also gone through iterations) and likely won't be going away any time soon. But still, in most cases you probably don't want to use that language for general work.

Why not? Because you won’t be able to hire younger devs? That is a function of this culture of pushing for change in everything. Younger people don’t learn C++ because it’s a little harder to read and because culturally we don’t respect established things. I’m sure there’s a word I don’t know here, but we generally have a culture of hating the past.

The good news is though, that it's relatively easy to transfer core skills between most languages.

I agree. Design patterns, work patterns, these transcend languages. And they’re 99% of the success or failure of a project.

And yet here we are emphasizing how C++ and Rust can’t realistically coexist in a serious project, because there’s some mismatch in their capabilities. I point to the current conundrum as the counter to this idea of transferability. The devil’s in the details and if the wisdom transfers between languages so well then we don’t need new languages.

Fundamentally, the question is “What are these news things that need to be done by code, that weren’t being done by code 30 years ago, such that it necessitates new languages?”

It’s cool to be able to tell your college buddies you’re building a new programming language.

In fact, it’s great that people are making new languages as a way of keeping language design wisdom alive. It’s great that CS kids build logic circuits from scratch for the same reason.

But then again, Netflix can’t remember what episode I was watching, when I’m almost certain they had that ability a few years ago.

They are having to take on the burden of gently letting down other devs who are angry over a simple misunderstanding.

I feel like, if anyone would be happily willing to do that in their free time, they would have been a Politician or an HR and not a Developer.

I'm pretty n00b as a dev, but if I were to see someone misinterpreting my explanation, the most I would do is rephrase the same in a more understandable manner.
Definitely not going to resort to using "people management tactics", specially not in an Open Source Free Work setting, where the expectation is that the other person wants the good of the project as much as I do ^[as compared to a corporate setting, where if they are getting money to sit and do nothing, they will prefer that].

Facts are more important than feelings, specially when written text is the medium, where the reader can, at any time, go back and re-read to make sure they are at the same page, which a responsible, non-sleepy, non-drunk person would do in such a case.

On this note, I went and re-read the above comment and I realise, the "But that’s the thing where you are wrong." sentence is kinda useless. If the previous commenter were to have read the rest, they would realise that's where they were wrong. Mental note to not use useless stuff like this as the first sentence in a reply, because I probably have the habit

Yes, I know I joined both circumstances, this comment thread and the condition of the Rust Linux dev. It seemed relevant to me.

Lots of good insight there. While I disagree with much of it, I get it.

I’m all for keeping one’s cognitive skills. However it is a fact that this decline happens, and that there is a phase of life where one has wisdom without necessarily having the same raw intelligence they had before. The wisdom is encoded in crystallized intelligence.

Yeah, realizing you have that wisdom is eye opening and it's actually pretty powerful. I can hunt down bugs by smell now with surprising accuracy. But I'm not convinced it's mutually exclusive to fluidity. I guess I'm just hoping my brain doesn't petrify and am battling against it.

That was possible because those machines don’t change too much as time marches on. Because they use a stable platform, his organization was able to do better work by relying on his deep expertise. He could train those younger guys because it was the same platform he’d always used. Same dirt, same physics, mostly the same machines, same techniques, same pitfalls, etc.

It's a poor analogy for software though. Software is an ongoing conversation. Not a device you build and forget about. User demands change, hardware changes, bugs are found, and performance is improved.

I'm honestly curious what the oldest line of code in the Linux kernel is now. I would be pretty shocked to see that anything survived 30 years. And I don't think that's because of enshittification.

This example doesn’t work as well with C/++ since that’s older than most people here (though the language has also gone through iterations) and likely won’t be going away any time soon. But still, in most cases you probably don’t want to use that language for general work.

Why not? Because you won’t be able to hire younger devs? That is a function of this culture of pushing for change in everything.

No, because C/++ isn't the right tool for every job. If I want to write up something quick and dirty to download a sequence of files, I'm not going to write that in C. It's worth learning other things.

I have to admit though that the conservative approach is more suited to things like a kernel, aerospace applications, or other things with lives riding on it. But also software that doesn't change becomes useless and irrelevant very quickly. For instance, running Windows XP is a bad call in just about any case.

But again I'm also not trying to say all software should be trend following. Just that devs should embrace learning and experiencing new things.

How to Win Friends and Influence People by Dale Carnegie should be required reading for everyone. It's full of things that are so obvious in hindsight but go against our natural instincts so we blunder through attempts to persuade not realizing that we might be increasing resistance rather than decreasing it.

Like the whole, "you might be right but you're still an asshole" thing. Being correct just isn't enough. In some cases you get crucified and then after some time has passed, the point you were trying to convince others of becomes the popular accepted fact. And they might even still hate you after coming around on the point you were trying to make.

That book won't turn you into a persuasive guru, but it will help avoid many of the pitfalls that make debates turn ugly or individuals stubborn.

Or, on the flip side, you can use the inverse of the lessons to become a more effective troll and learn how to act like you're arguing one thing while really trying to rile people up or convince them of the opposite. I say this not so much to suggest it but because knowing about this can make you less susceptible to it (and it's already a part of the Russian troll farm MO).

I guess the question is, what happens to the kernel when all the people who learned on C are gone? The majority of even the brightest new devs aren't going to cut their teeth on C, and will feel the same resistance to learning a new language when they think that there are diminishing returns to be had compared to what's new and modern and, most importantly, familiar.

I honestly get the hostility, the fast pace of technology has left a lot of older devs being seen as undesirable because the don't know the new stuff, even if their fundamental understanding of low level languages could be a huge asset. Their knowledge of C is vast and valuable, and they're working on a project that thrives because of it. To have new people come to the project and say "Yeah, we could do this without having to worry about all that stuff" feels like throwing away a lot of the skill they've built. I'm not sure what the solution is, I really don't think there are enough new C developers in the world to keep the project going strong into the future though. Maybe a fork is just the way to go; time will tell which is more sustainable.

Netflix is using FreeBSD for servers. You can't blame everything they do wrong as being a problem with the new hires. They are using an OS older than Linux that changes more slowly than Linux, simply because it performs the best for their specific application. Rate of change isn't the issue here.

In fact that's 90% of what this comment is. Blaming new people and new techniques for problems when you aren't a part of that organisation and don't actually know what's happening.

Working with computers is not the same as working with construction equipment. Some degree of fluid intelligence is needed in this field, no matter how experienced you might be, just like how a surgeon needs steady hands. The people you call greybeards aren't nearly as old as your father is. We are talking about people who are in their 50s and 40s. They don't have that level of cognitive decline yet. Likewise some things like ext4 aren't likely going to be ported to Rust now or even ever. They can keep maintaining them as they are now for the foreseeable future. Plus I don't want people to have to keep working into their 70s and 80s. At some point it becomes elder abuse. Let people retire man.

C has existed for a long time now. We've been trying to replace it for ages, for most of it's lifespan even. C++ actually was one of the new options at one point. I get it seemed immovable only a decade ago, and I think that has lulled people into a false sense of security. In truth it was inevitable it would have to be replaced one day. It's already well outlived the life expectancy of a programming language. Just think about Ruby: created long after C yet has already become mostly irrelevant. You talk about the maximum rate of tool change, but C is one of the oldest tools we have, keeping it around would be almost 0 rate of tool change over decades. If you can't see that C is very slowly dying then you haven't seen the writing on the wall for the past several years. It's on you at that point.

We should look back with pride at everything that has been accomplished with C, and just how long it's been relevant. We can do this while still acknowledging it needs to be phased out gradually.

No one is asking for change that rapid either. Linux started adopting Rust four years ago now. It's probably still going to have C code inside it for at least a decade from now. This isn't some quick change, it's a gradual process. People have plenty of time to adapt, and those who are too old to do so will be around retirement agent if not already dead by the time C is fully phased out.

We of course play plenty of video games together to keep him sharp. We also eat mushrooms, paper when necessary, and he works out a lot. We do all we can, believe me.

Honestly you take more care of yourself and your father than I do. I am only in my 20s and suck at video games. If I took mushies or LSD I would probably lose my mind, assuming it's all still there in the first place. I suspect there is a good reason why people like me only have a life expectancy of 58 or so.

That is honestly a decent analogy. So, on what rides is it ok if something goes wrong and a young family member is killed? Rust says, it is never ok so we won’t let you do it.

To use your analogy though, the issue is the driver feeling quite confident in their skills and rating the risk as low. Then a tire blows on a corner. Or somebody else runs a red light. Or, there is just that one day when an otherwise good driver makes a mistake. History tells us, the risk is higher than the overconfident “good” drivers think it is.

In particular, history shows that 70% of the real world injuries and fatalities come from passengers without seat belts. So, instead of each driver deciding if it is safe, we as a society decide that seat belt use is mandatory because it will prevent those 70% of injuries and fatalities ( without worrying about which individual drivers are responsible )

Rust is the seat belt law that demonstrably saves lives regardless of how safe each individual driver thinks they are. It is a hard transition with many critics but the generation that grows up with seat belts will never go back. Eventually, we will all realize just how crazy it was that they were not always used.

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.

They aren't asking C devs to write Rust code, which is what the guy being a heckler was claiming. Why don't they want to right Rust? For exactly the reasons you describe. The thing is though that's not currently being asked of them, all they actually want is the documentation to create that code themselves.

You really don't have to explain any of the culture clash to me lol. I've written both C/C++ and Rust. My C and C++ coding skills are demonstrably better (or at least used to be, it's been a while) than my Rust skills. Why? Because of how complex those guardrails are. The difference is I have the self awareness to know that my lack of Rust skills doesn't mean that the language is bad, or that C is a safe language to use. Rust tutorials could be improved. Perhaps an easier to use language like Zig might be more useful for some people. I feel like it's a good compromise between safety and ease of use. Rust though is still incredibly progressive for the industry, and will improve systems security, maintainability and reliability going forward if only people would stop getting in the way.