For me, a language or tech stack is not more than a tool box to achieve a higher goal, namely solving specific problems. While I do enjoy building software, "writing code" or mastering a particular tech stack is only one component of several things that make software engineering enjoyable.
One of these other things is understanding the kind of problem I want to solve and its environment, by collaborating with stakeholders and domain experts. As soon as I understand their expectations, I decide on the tech stack.
That being said, if I want to make an estimation which tech stacks are likely to be relevant in the long run, I would start with understanding which business requirements will be relevant. Based on that (and maybe more), I can assess which stacks could be a promising fit.
And if I'm wrong, don't neglect the experience I make mastering or learning a tech steck.
One of these other things is understanding the kind of problem I want to solve and its environment, by collaborating with stakeholders and domain experts. As soon as I understand their expectations, I decide on the tech stack.
That being said, if I want to make an estimation which tech stacks are likely to be relevant in the long run, I would start with understanding which business requirements will be relevant. Based on that (and maybe more), I can assess which stacks could be a promising fit.
And if I'm wrong, don't neglect the experience I make mastering or learning a tech steck.