Developers who are not willing to learn something new and not adapt are the worst.
And this is why COBOL developers are desperately needed these days: because too many people think that āoldā was the same thing as āneeds a replacementā.
The situation of COBOL has nothing to do with Rust in Linux. C is not replaced by Rust, first. Secondly, there are legitimate reasons why Rust was introduced, as a secondary language. You are conflicting two different cases that are two different problems. Itās not replacing a language.
āLearning something newā does not mean the thing you are learning is new. It just means itās new to you. One of the best things you can do for yourself as a dev is to learn to be fluid and be able to adapt to new languages, protocols, and technologies.
Why? I mean, I, personally, try to be as polyglot as possible, but not everyone working on the Linux kernel is even interested in doing anything thatās not C kernel code, nor is it their profession.
Learning is key in this field. Being able to learn new things allows you to move from one thing to the next as needed. You also learn a lot from experiencing different things. Other ways of doing things, other points of view, other concepts that you may have not been exposed to before.
It also expands your employment potential and general usefulness. Knowing only one thing will severely limit your abilities.
It also expands your employment potential and general usefulness.
I have already mentioned that programming is not everyoneās profession. Not everyone chooses what they do in their unpaid free time primarily based on whether it makes them a more useful person. I think the very phrase āmy usefulnessā is dangerous.
I never said anything about someoneās usefulness as a person. Their usefulness as a software developer was the topic at hand. Maybe itās not your profession but a hobby but the point stands.
I think the very phrase āmy usefulnessā is dangerous. Are we only worth something as drones?
And yet itās drones that do one thing and only one thing their entire lives, never learn and grow.
Maybe itās not your profession but a hobby but the point stands.
To be honest, Iāve hardly ever asked myself how I could best please a potential employer with any of my hobbies. But I recognise that youāre probably taking a different approach.
employment potential and learning are generally problems if you are young. if you are old, the time investment to learn a new language is generally not self beneficial as your time of employability starts to dwindle.
Linux ultimately will have to run into the situation of if the people want the newer language to become the mainstream, they need to be more proactive at the development of the kernel itself instead of relying on yhe older generation, who does ot the way they only know how, as relearning and rewriting everything ultimately to them, a waste of time at their point in life.
think like proton was for gaming. you dont(and will not) convince all devs to make linux compatible games using a vulkan branch. the solution in that front was to create a translation layer to offload most of that work off because its nonsensical to expect every dev to learn vulkan. this would be applied moreso to the linux kernel, so the only realistic option (imo) is that the ones who are working in rust need to make the rust based kernel and hope that it takes off in a few years to actually gain traction.
employment potential and learning are generally problems if you are young. if you are old, the time investment to learn a new language is generally not self beneficial as your time of employability starts to dwindle.
Middle age software engineer here. Very disagree. Hoping to code until arthritis gets me. My point wasnāt only for employment (more of a perk), but primarily self-improvement and improvement on your craft. The day I can no longer do that, that may be the end for me.
That said, I donāt know what Linux community should do about Rust adoption. I just wanted to point out that I think itās very important for all devs to be able to embrace learning new things and expand and refine their skillset.
One problem is (even Linus acknowledged it in some interview, sorry I have no source) that in future C might no longer be the popular language to learn. I mean learning basics is one thing, but getting good at C and writing in the Kernel, while trying to dodge memory issues is a huge task to ask.
Lot of people learn Rust instead for systems programming today. Meaning in future it might be very useful to get new people into Kernel programming. And as said before, those who are not interested into Rust are perfectly fine using C. The Kernel is huge! Even new code in C is allowed, so this is not something that is going away. Remember, its an addition to the base, not replacement.
So basically youāre saying one of the best things you can do for yourself as a dev is be young.
Itās a well-documented fact that as people get older their fluid intelligence declines.
If you predicate your tech culture on requiring high fluid intelligence, you (a) make less readable code since the people writing it have more working memory and can hold more lines in their mind at a time and (b) break long-term institutional memory resulting in the reoccurrence of solved problems.
At the level of organizational architecture, a culture of emphasizing fluid intelligence as the strategy for attacking problems and adaptation causes serious losses of efficiency, and hence fluidity at a higher scale.
Ensuring compatibility with greybeardsā brains is key to long term success, and that means respecting an upper boundary on the rate of tools change.
Itās a well-documented fact that as people get older their fluid intelligence declines.
Iām quickly approaching grey beard status. I recognize that Iām nowhere near as fluid as I was 20 years ago but I make an effort. You have to continually practice fluidity and actively learn things lest you solidify and lose that skill like any other. Itās important to stay fluid because things change and change faster than we all expect.
At the level of organizational architecture, a culture of emphasizing fluid intelligence as the strategy for attacking problems and adaptation causes serious losses of efficiency, and hence fluidity at a higher scale.
Ensuring compatibility with greybeardsā brains is key to long term success, and that means respecting an upper boundary on the rate of tools change.
Thereās some truth to that. 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. So as a dev, itās important to recognize that tools come and go and be flexible.
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. So youāll probably have to pick up other things for your toolchain (and higher level) work which of course has changed a lot.
The good news is though, that itās relatively easy to transfer core skills between most languages. Especially the ones with C-like syntax, which is most languages.
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.
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.
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.
C has been around for a very long time. I donāt think wanting to replace a 1970s language, that was old when current gray beards were young is a bad thing. People have had more than enough time, and still have a good decade or two to make their careers writing and maintaining C code. Sometimes things have to change, old people be damned. Itās diatribes like this that remind me the human race advances one body at a time as those holding us back die out.
Edit: also we arenāt talking about people in their 70s and 80s here. Most of these āgreybeardsā are in their 40s and 50s at most. Linux itself is from the 1990s and is therefore more modern than C.
And this is why COBOL developers are desperately needed these days: because too many people think that āoldā was the same thing as āneeds a replacementā.
The situation of COBOL has nothing to do with Rust in Linux. C is not replaced by Rust, first. Secondly, there are legitimate reasons why Rust was introduced, as a secondary language. You are conflicting two different cases that are two different problems. Itās not replacing a language.
Third, we do not need COBOL. All those systems that are still running on COBOL are businesses that shouldnāt exists in the first place anymore.
Like banks and insurance companies?
deleted by creator
So you advocate for the abolition of money also?
Exactly.
āLearning something newā does not mean the thing you are learning is new. It just means itās new to you. One of the best things you can do for yourself as a dev is to learn to be fluid and be able to adapt to new languages, protocols, and technologies.
Why? I mean, I, personally, try to be as polyglot as possible, but not everyone working on the Linux kernel is even interested in doing anything thatās not C kernel code, nor is it their profession.
Learning is key in this field. Being able to learn new things allows you to move from one thing to the next as needed. You also learn a lot from experiencing different things. Other ways of doing things, other points of view, other concepts that you may have not been exposed to before.
It also expands your employment potential and general usefulness. Knowing only one thing will severely limit your abilities.
I have already mentioned that programming is not everyoneās profession. Not everyone chooses what they do in their unpaid free time primarily based on whether it makes them a more useful person. I think the very phrase āmy usefulnessā is dangerous.
Are we only worth something as drones?
I never said anything about someoneās usefulness as a person. Their usefulness as a software developer was the topic at hand. Maybe itās not your profession but a hobby but the point stands.
And yet itās drones that do one thing and only one thing their entire lives, never learn and grow.
To be honest, Iāve hardly ever asked myself how I could best please a potential employer with any of my hobbies. But I recognise that youāre probably taking a different approach.
employment potential and learning are generally problems if you are young. if you are old, the time investment to learn a new language is generally not self beneficial as your time of employability starts to dwindle.
Linux ultimately will have to run into the situation of if the people want the newer language to become the mainstream, they need to be more proactive at the development of the kernel itself instead of relying on yhe older generation, who does ot the way they only know how, as relearning and rewriting everything ultimately to them, a waste of time at their point in life.
think like proton was for gaming. you dont(and will not) convince all devs to make linux compatible games using a vulkan branch. the solution in that front was to create a translation layer to offload most of that work off because its nonsensical to expect every dev to learn vulkan. this would be applied moreso to the linux kernel, so the only realistic option (imo) is that the ones who are working in rust need to make the rust based kernel and hope that it takes off in a few years to actually gain traction.
Middle age software engineer here. Very disagree. Hoping to code until arthritis gets me. My point wasnāt only for employment (more of a perk), but primarily self-improvement and improvement on your craft. The day I can no longer do that, that may be the end for me.
That said, I donāt know what Linux community should do about Rust adoption. I just wanted to point out that I think itās very important for all devs to be able to embrace learning new things and expand and refine their skillset.
One problem is (even Linus acknowledged it in some interview, sorry I have no source) that in future C might no longer be the popular language to learn. I mean learning basics is one thing, but getting good at C and writing in the Kernel, while trying to dodge memory issues is a huge task to ask.
Lot of people learn Rust instead for systems programming today. Meaning in future it might be very useful to get new people into Kernel programming. And as said before, those who are not interested into Rust are perfectly fine using C. The Kernel is huge! Even new code in C is allowed, so this is not something that is going away. Remember, its an addition to the base, not replacement.
So basically youāre saying one of the best things you can do for yourself as a dev is be young.
Itās a well-documented fact that as people get older their fluid intelligence declines.
If you predicate your tech culture on requiring high fluid intelligence, you (a) make less readable code since the people writing it have more working memory and can hold more lines in their mind at a time and (b) break long-term institutional memory resulting in the reoccurrence of solved problems.
At the level of organizational architecture, a culture of emphasizing fluid intelligence as the strategy for attacking problems and adaptation causes serious losses of efficiency, and hence fluidity at a higher scale.
Ensuring compatibility with greybeardsā brains is key to long term success, and that means respecting an upper boundary on the rate of tools change.
Iām quickly approaching grey beard status. I recognize that Iām nowhere near as fluid as I was 20 years ago but I make an effort. You have to continually practice fluidity and actively learn things lest you solidify and lose that skill like any other. Itās important to stay fluid because things change and change faster than we all expect.
Thereās some truth to that. 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. So as a dev, itās important to recognize that tools come and go and be flexible.
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. So youāll probably have to pick up other things for your toolchain (and higher level) work which of course has changed a lot.
The good news is though, that itās relatively easy to transfer core skills between most languages. Especially the ones with C-like syntax, which is most languages.
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.
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.
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.
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.
Lots of good insight there. While I disagree with much of it, I get it.
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.
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.
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.
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.
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.
C has been around for a very long time. I donāt think wanting to replace a 1970s language, that was old when current gray beards were young is a bad thing. People have had more than enough time, and still have a good decade or two to make their careers writing and maintaining C code. Sometimes things have to change, old people be damned. Itās diatribes like this that remind me the human race advances one body at a time as those holding us back die out.
Edit: also we arenāt talking about people in their 70s and 80s here. Most of these āgreybeardsā are in their 40s and 50s at most. Linux itself is from the 1990s and is therefore more modern than C.