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.
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?
Correct, those institutions should not exist
“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.