4 ms·
Another thing is that back in 2004, a larger % of code was hand written. So, choosing a new language didn’t come with as high a switching cost outside of learni
by awb 4y ago
Another thing is that back in 2004, a larger % of code was hand written. So, choosing a new language didn’t come with as high a switching cost outside of learning a new syntax.
Now, if you deviate from PHP, Python, Node, Rails, etc., to one of the new “esoteric” languages, you have to learn a new language, plus reinvent the wheel in a lot of areas that you’d otherwise be getting for free.
So you have brilliant developers working in esoteric languages trying to complete 25-50% more code.
Even if you can swim upstream fast enough to compete with highly competent devs working in a more popular language, then you get into hiring / onboarding challenges, documenting and debugging custom features (features that would otherwise be a “solved problem” in other languages), acquisition due diligence, etc., that persistently weighs against you.
- solatic 4y ago> Now, if you deviate... to one of the new “esoteric” languages, you have to... reinvent the wheel in a lot of areas that you’d otherwise be getting for free. I think this is the key concern. The #1 priority is how quickly Engineering can respond to business demands. Maybe the #1 priority instead ought to be culture, and that can be a great approach for Mittelstand-style/small-forever/bootstrapped businesses. But for venture-backed growth-at-all-costs businesses? Porting functionality to an esoteric language does not drive business value. Complain that you have difficulty hiring because you can't find engineers who know the esoteric language, and you're likely to get pressure from your investors to make boring technology choices instead.