3 ms·

If you were starting a project do you think it would ever be a good idea to write parts of out in different languages? Surely if you think a language is good th

If you were starting a project do you think it would ever be a good idea to write parts of out in different languages? Surely if you think a language is good then it's good enough for most things and the advantages of having a common language (review, experience, transferring devs, cognitive overhead etc) outweigh the benefits of using the perfect language for every task (even if you could get people to agree on what each language is - it will be hard enough to get them to agree on one)

duderific 12y ago
This is entirely dependent on what type of project it is. At most companies, tastes change over time so you end up with a hybrid of application layers built on different languages and technologies. I guess in an ideal world the stack would be as non-diverse as possible, but it never seems to end up that way.
kasey_junk 12y ago
So I have several responses to that. - Lots and lots of large systems are decomposed across different languages based on the advantages they have. Some parts of the system may be extremely latency sensitive and therefore can't afford GC based languages, other parts may need to interact with existing enterprise systems and therefore are best written in Java or the .NET stack. A very common split is amongst quantitative developers who prefer languages like python vs other developers that prefer something else. So basically yes, there are times that I've worked on systems that were designed from the ground up to use different languages (or should have been). That said, of course you want to make sure you aren't adding complexity for it's own sake and a unified language is usually better. - A very common use of service architectures is not green field development. It is in migrating from legacy systems or augmenting them. Lots of large web based systems were originally written as monoliths on the LAMP stack or as Perl/CGI. As they grow it becomes obvious that scaling will require different technology choices, but it is almost always a mistake to do a full rewrite. In those cases, language agnosticism can be a real boon as you can ramp up in languages that are more popular at the time of need (or in languages that allow you to attract good developers).

duderific 12y ago

This is entirely dependent on what type of project it is. At most companies, tastes change over time so you end up with a hybrid of application layers built on different languages and technologies. I guess in an ideal world the stack would be as non-diverse as possible, but it never seems to end up that way.

kasey_junk 12y ago

So I have several responses to that. - Lots and lots of large systems are decomposed across different languages based on the advantages they have. Some parts of the system may be extremely latency sensitive and therefore can't afford GC based languages, other parts may need to interact with existing enterprise systems and therefore are best written in Java or the .NET stack. A very common split is amongst quantitative developers who prefer languages like python vs other developers that prefer something else. So basically yes, there are times that I've worked on systems that were designed from the ground up to use different languages (or should have been). That said, of course you want to make sure you aren't adding complexity for it's own sake and a unified language is usually better. - A very common use of service architectures is not green field development. It is in migrating from legacy systems or augmenting them. Lots of large web based systems were originally written as monoliths on the LAMP stack or as Perl/CGI. As they grow it becomes obvious that scaling will require different technology choices, but it is almost always a mistake to do a full rewrite. In those cases, language agnosticism can be a real boon as you can ramp up in languages that are more popular at the time of need (or in languages that allow you to attract good developers).