[vojant]

That really depends on the startup, and sometimes starting with micro-services helps with hiring - In our case thanks to starting with micro-services we hired developers knowing different programming languages and they can work together on the project by exposing end-points/consumers. Of course I wouldn't recommend doing that for everyone but in our use-case we had to start with distributed system anyway due to quite complicated domain.

[bpicolo]

Even with microservices, I wouldn't recommend changing languages between the bunch without a very good reason. You -will- build up infrastructure and packages that are language and stack specific: monitoring, logging, helpers, etc. that take a lot of time to reinvent.

If you're switching languages/stacks just for funsies, you're going to make services more difficult to maintain over time (and just generally slow down development)

As far as languages go, pick one. When you hit a problem that absolutely cannot be reasonably solved under the specifications you care about, consider a different one for that service. Apart from that, there's little value, and lots of overhead, in moving. Getting to write that one Haskell microservice is sure a romantic idea, until that employee leaves and nobody knows Haskell anymore, and suddenly the service is dysfunctional because dependencies have changed. (For non-mission-critical funsies, sure, use whatever, though non-mission-critical apps tend to have a knack for becoming very important for workflows, hah)

[vojant]

That's a good comment and of course there is a list of approved stacks (not random list of languages) and we try to think about future. Hiring people wasn't our only reason and we had technical reasons to go with micro-services and multiple languages, but it was nice perk.