This sounds fun until your entire stack is on Perl in 2023 (which, is fine-ish when your CTO was the perl project lead). But then you have a bajillion dependencies that aren't really updated anymore, you end up owning most of the Mail::Toolkit libraries, etc. and nobody really knows perl that well. I mean, a lot of us can jimmy around in Perl, but of the real Perl Gurus in the world, you will end up hiring 50% just to keep your company going
>> I hire based on ability/intelligence, not knowledge.
Well, yeah that's really your only choice if the experience you need is not easily available.
Don't tell me, you are the guy who puts in the not mainstream technology and needs to defend that with justifications such as "when we use (non mainstream technology X) we get super motivated job applicants because anyone with an interest in non mainstream technologies is inherently passionate and interested".
And you are the guy who left Visual Basic, COBOL, Perl, and FORTRAN off their "obviously safe choices for hiring in the future" list, despite them all having once been perceived as such.
These inconvenient counterexamples blow up the entire thesis. In practice, the "safe choice" for longevity is only evident in hindsight.
If anyone is hiring for TypeScript in 2050 I'll eat my hat
I'm in sympathy with your main argument, but given that people still, in 2023, hire for COBOL, a language made in 1959, makes me think you'll be eating your hat.
Notwithstanding that I'm effectively forecasting the decline & fall of TypeScript as javascript-flavour-of-the-month, note that I shrewdly also granted myself the better part of three decades to launch an edible headwear startup
Most of the perceived value that Typescript brings will probably fade once js gets type annotations [1], though Typescript will always have more advanced syntax and capabilities.
There are interesting discussions about Typescript becoming more of a run-time type checker, which would be opt-in and have significant performance penalties, but would give more guarantees of type safety.
"Ability" by itself is a bit vague here, but I will say that having a proven trackrecord in their ability to learn is something I specifically look for in a candidate. Not only learning new tech, but also learning from mistakes and experiences over time.
However, I don't think raw "intelligence" is the right metric for hiring. Unless you specifically mean emotional intelligence, which can curtainly contribute to improving communication skills on the team.
I've also found that when hiring someone with mostly expertise outside your current stack it's critical to provide good feedback loops and mentoring early on so they can "get up to speed" and contributing valuable, idiomatic code as fast as possible without feeling as though your entire onboarding experience is trial by fire. This mentoring takes up extra resources and is a net drain on your team in the short term, but pays off in the long term.
Just curious, what are some of those footguns your team is encountering? Only thing that comes to mind is the somewhat tedious error handling imposed by the language. Which language would you say had _less_ footguns than go? Or was this sarcasm and it went straight over my head?
