In my opinion, this is less of a problem for a programmer than for a product-company.
Depending on the size of the change, a reasonably competent programmer can pick up enough of a new programming language or framework in something between a weekend and a month of playing around with it.
However, if a company has invested years of work into a product, they can't simply switch the programming language or framework. Worst case is that they have to rewrite everything.
I'm in a position where pretty much exactly 5 years ago, at the company I worked at we evaluated which web-framework and programming language we should switch to and rewrite the product in (that was previously written in Perl).
We decided to go with Java, as it seemed a safe bet. That was before Sun was bought and, while Java wasn't an innovation leader, the language was being properly maintained. E.g. Lambdas didn't seem to far away, there was talk about replacing get/set methods with properties etc. Then Oracle came along and drove the whole process straight off a cliff. Meanwhile, even Objective C has both properties and blocks!
We chose the Seam Framework: Open Source, innovative, trying to get their stuff into the standards. The last part actually worked somewhat, however stateful web framework have proven to be a looser: Especially in enterprise, back in 08/09 browser performance was terrible and you'd try to do as much as possible on the server. Today, it's the other way around.
Plus, the stateful Seam Framework works really bad in the cloud. Each server needs memory to store session state. Want to load balance requests between servers? Want to be able to kill a server? Synchronize the state between servers and loose as much performance as you gain by adding a new server. Plus, you'll always have to buy beefy instances to have enough memory at hand. 5 years ago, cloud was much more about IaaS than PaaS and during the hype anything was ready-for-cloud and every solution had lots of initial quirks.
We tried to make a couple of safer bets 5 years ago. We lost. As a programmer, I easily moved on to greener pastures. But migrating that product off to something like Angular in the frontend or to a stateless architecture in the backend? Even if the new technology doubles the development speed, halfs the maintenance effort and hosting costs, it'll take a massive investment... by the time it pays off, half of the technology is probably hopelessly outdated again.
Depending on the size of the change, a reasonably competent programmer can pick up enough of a new programming language or framework in something between a weekend and a month of playing around with it.
However, if a company has invested years of work into a product, they can't simply switch the programming language or framework. Worst case is that they have to rewrite everything.
I'm in a position where pretty much exactly 5 years ago, at the company I worked at we evaluated which web-framework and programming language we should switch to and rewrite the product in (that was previously written in Perl).
We decided to go with Java, as it seemed a safe bet. That was before Sun was bought and, while Java wasn't an innovation leader, the language was being properly maintained. E.g. Lambdas didn't seem to far away, there was talk about replacing get/set methods with properties etc. Then Oracle came along and drove the whole process straight off a cliff. Meanwhile, even Objective C has both properties and blocks!
We chose the Seam Framework: Open Source, innovative, trying to get their stuff into the standards. The last part actually worked somewhat, however stateful web framework have proven to be a looser: Especially in enterprise, back in 08/09 browser performance was terrible and you'd try to do as much as possible on the server. Today, it's the other way around.
Plus, the stateful Seam Framework works really bad in the cloud. Each server needs memory to store session state. Want to load balance requests between servers? Want to be able to kill a server? Synchronize the state between servers and loose as much performance as you gain by adding a new server. Plus, you'll always have to buy beefy instances to have enough memory at hand. 5 years ago, cloud was much more about IaaS than PaaS and during the hype anything was ready-for-cloud and every solution had lots of initial quirks.
We tried to make a couple of safer bets 5 years ago. We lost. As a programmer, I easily moved on to greener pastures. But migrating that product off to something like Angular in the frontend or to a stateless architecture in the backend? Even if the new technology doubles the development speed, halfs the maintenance effort and hosting costs, it'll take a massive investment... by the time it pays off, half of the technology is probably hopelessly outdated again.