This is just incorrect. Unless you think you know some older technology completely, there's always plenty of room to grow and learn on any tech stack. Some of t

This is just incorrect. Unless you think you know some older technology completely, there's always plenty of room to grow and learn on any tech stack. Some of the technologies I use daily, such as vim and bash, have been around for decades, yet I still learn things about them on a regular basis. In fact, one thing I've learned from working on bleeding-edge tech stacks is that communities around bleeding-edge tech stacks can often be narrow-minded in a way that hinders learning. Many (but not all) members Go community, for example, seem intent on not learning anything from other languages: if you point out that coroutines predate Go by decades and there's a lot to learn about their use from other languages, or that Go actually has a fairly weak type system, you'll get a lot of defensive pushback from Go fanboys who know literally nothing about other languages that contain coroutines, and don't understand that there's a difference between static types and strong types. There are good programmers in bad ecosystems--the folks who are bringing in generics might yet make Go a decent language--but remember that there was immense infighting to get there: I've been keeping track of Go long enough to remember all the people ranting that Go didn't need generics because it had `go generate`--a glorified C macro system (since they couldn't be arsed to learn from the mistakes of even one of the most adjacent languages) that breaks the entire point of not including generics in the first place (to keep the compiler single-pass). If this is the sort of "growing and learning" you're talking about, I generally tend to avoid working with people who "grow and learn" in this way.