This problem is solvable by basic market dynamics. When everyone knows that a JavaScript "Dev" can make $80k and a cobol one can make $190k, people with learn cobol. It isn't hard. If you can grasp one imperative language, you can grasp any of them.
True, but if the Cobol market is for 10k developers worldwide, not many people will venture there, even for higher pay. Cause if you get fired from your Cobol job and there’s no openings for Cobol devs, your market value just plummeted to $40k as a Junior Javascript dev ;)
And despite what we may think, except for the big tech companies, everyone else doesn’t really hire generalists. You could have 20 years experience as a programmer in 10 different languages, HR still wants a Java programmer with 5 years of Java experience.
There's no churn, it's great. And there's plenty to learn once you get in, depending on where you go. COBOL requires knowing a good bit about the business itself, so it's hard to get bored with it. At least, I haven't yet and I've been at it for a whopping 2 years.
You could also become an embedded dev. Write software for cars or planes, or train, or nuclear power plants. If you want you can work on the same piece of software using the same tooling for your whole career.
I was in ECE in college (graduated in 2017) but do full stack software engineering for a bank now. AFAIK it's still C, but I wouldn't be surprised if Rust picked up due to the emphasis on memory safety- dynamic memory allocation and recursion are usually avoided in embedded.
Some of the lessons I got from embedded have carried over to my place of work- I found a repo that used floating point for money and immediately knew why that was a bad idea, because my embedded systems professor had spent an almost an entire lesson explaining why you don't use floating point for money or time.
It isn't about the language but about the physics process you are controlling. To write software to fly a plane you need to understand how the plane works, same for power plants, saw mills, assembly lines, refineries, pipelines, etc.
Choose the process you want to control and then go work at a place that has that process or a consultant that supplies equipment or services to the owner/operator of the plant. Then you will learn how the process operates and how the software controlling it works, and how it could be improved.
* persuaded to come: tough sell for Cobol
* 99% internally trained cause the pool of Cobol devs is probably similar to that of Elm devs :)