5 ms·
Using a new language for a new project is a risk. Risks need to be weighed, and new languages rarely offer such a huge benefit that it's worth taking that risk
by lifefeed 4y ago
Using a new language for a new project is a risk. Risks need to be weighed, and new languages rarely offer such a huge benefit that it's worth taking that risk over others. [0]
Also, it takes years to get fluent in a language.
I know every programmer likes to believe they can learn a language in a week or so, but that's really just the syntax and semantics. Becoming fluent means inhaling best practices and reading through years of PIPs and forum posts and pull requests, and watching other people struggle to solve weird problems and seeing how small choices in development impact future maintenance. Turning all of that into "unconscious competence" takes time, and it's obvious when people haven't put in that time.
Basically, I've spent a lot of time debugging Perl/Python/Go code written by people who only knew the bare syntax, and were obviously C/C++/Java programmers, and it was not a happy time.
[0] - Two exceptions I've seen were switching from PHP to Ruby on Rails back in 2005, and switching from Perl to Java for its typing and IDE support.
- dhagz 4y agoNot only that, but the chances of having more than one developer at a company who already know $LANGUAGE_NOT_USED_AT_COMPANY is slim. There's maybe like two or three other people at my company who know Rust, and none of them are on my team or even close to my team in the org chart. So me proposing we write a new service in $LANGUAGE is basically me saying, "If I ever leave, you will have to literally move heaven and earth to maintain this thing. Or worse, you'll have to build institutional knowledge of $LANGUAGE as an insurance policy against me leaving."