4 ms·

> they force alignment on one language or at least runtime How is this possibly a down-side from an org perspective? You don't want to fracture knowledge and

> they force alignment on one language or at least runtime How is this possibly a down-side from an org perspective? You don't want to fracture knowledge and make hiring/training more difficult even if there are some technical optimizations possible otherwise.

nlnn 4y ago
The capabilites of the language and the libraries available for it can sometimes be a good reason for dealing with multiple languages. E.g. if you end up having a requirement to add some machine learning to your application, you might be better off using Tensorflow/PyTorch via Python than trying to deal with it in whatever language the core of the app is written in.
- JAlexoid 4y ago
  Different domains will have different requirements. Doing a monolith, doesn't preclude you from building domain specific services external to the monolith (Model serving service for example). Take an RDBMS as an example, that is a service external to the monolith often written in a very different language to the monolith.
hinkley 4y ago
In an organization that will be bankrupt in three years it doesn’t matter. But if you can pour that much energy into a doomed project you’re a steely eyed missile man. Or dumb as a post. Or maybe both at once. This is the Pendulum Swing all over again. If one language and runtime is limiting, forty is not liberating. If forty languages are anarchy, switching to one is not the answer. This is in my opinion a Rule of Three scenario. At any moment there should be one language or framework that is encouraged for all new work. Existing systems should be migrating onto it. And because someone will always drag their feet, and you can’t limit progress to the slowest team, there is also a point in the migration where one or two teams are experimenting with ideas for the next migration. But once that starts to crystallize any teams that are still legacy are in mortal danger of losing their mandate to another team.
philippejara 4y ago
>You don't want to fracture knowledge and make hiring/training more difficult these are not maxims of development, there can be reasons that make these consequences worth it. Furthermore you can still use just a single language with microservices*, nothing is stopping you from doing that if those consequences are far too steep to risk. *:you can also use several languages with modules by using FFI and ABIs, probably.

nlnn 4y ago

The capabilites of the language and the libraries available for it can sometimes be a good reason for dealing with multiple languages. E.g. if you end up having a requirement to add some machine learning to your application, you might be better off using Tensorflow/PyTorch via Python than trying to deal with it in whatever language the core of the app is written in.

JAlexoid 4y ago
Different domains will have different requirements. Doing a monolith, doesn't preclude you from building domain specific services external to the monolith (Model serving service for example). Take an RDBMS as an example, that is a service external to the monolith often written in a very different language to the monolith.

hinkley 4y ago

In an organization that will be bankrupt in three years it doesn’t matter. But if you can pour that much energy into a doomed project you’re a steely eyed missile man. Or dumb as a post. Or maybe both at once. This is the Pendulum Swing all over again. If one language and runtime is limiting, forty is not liberating. If forty languages are anarchy, switching to one is not the answer. This is in my opinion a Rule of Three scenario. At any moment there should be one language or framework that is encouraged for all new work. Existing systems should be migrating onto it. And because someone will always drag their feet, and you can’t limit progress to the slowest team, there is also a point in the migration where one or two teams are experimenting with ideas for the next migration. But once that starts to crystallize any teams that are still legacy are in mortal danger of losing their mandate to another team.

philippejara 4y ago

>You don't want to fracture knowledge and make hiring/training more difficult these are not maxims of development, there can be reasons that make these consequences worth it. Furthermore you can still use just a single language with microservices*, nothing is stopping you from doing that if those consequences are far too steep to risk. *:you can also use several languages with modules by using FFI and ABIs, probably.