Language choices
Very much a part two of ‘Mistakes I’ve made in my career (so far)’
The Question
My Experience
I am expanding on my Twitter thread.
At a previous start-up. Greenfield project. New team. We got started with building version one. We began as a free for all. The mindset was the best tool for the job. Resulting in every service being in a different language. Node, Go, Haskell, Python.
For the MVP, everything was in containers, so deploying and running the system was not that bad. Maybe a little too complex for the features we had but nothing too horrible. Engineers worked on the same service most of the time. No one was switching back and forth between services. Maintenance or anything post-demo got zero thought. We needed to ship sometime that vaguely worked.
Post MVP. Maintenance was a problem; only certain people could work on certain services. Hiring was the other major problem and ultimately forced the issue. No one knew all those languages. Even people that knew two or three of them were not at the same level in all the languages. Mentally switching between different languages is tiring.
We took the difficult decision to standardise on Go. The largest and most active service used that. Everyone on the project would work in Go at least sometimes. We still had some other languages but only for specific uses. For example, python for data science tasks, but the default was Go for everything. We took the hit of rewriting services not already in Go over time. In the end, it cost a couple of months to get back to where we were for the MVP.
I do not think anyone thought the MVP code would survive long-term. I certainly did not. We were always going to rewrite, expand the services and remove all the last-minute fixes we needed to get the project out the door. If those services had already been in Go, that would have been an incremental refactoring process. We would always build a shippable version of the project. Instead, we broke everything and could not ship anything for what seemed like aeons. in start-up time. We were lucky and only needed to demonstrate the project on one or two occasions. Each time was a painful experience until we had finished the rewrite.
Hiring was more focused. We had less of a laundry list of skills and languages—this ultimately allowed us to hire some junior engineers. You can not expect someone at the start of their career to be able to write production code in three or four languages. Maintenance was more manageable with only a single language. Everyone in engineering could help each other. The general quality of code went up.
Painful lesson learnt.
At my current place we started off standardising on Node. Not because it is my favourite language but because the centre of gravity in the project is around Node. The same with yarn.