[tracker1]

More often than not, preference should be given to the language most of the team know the best. The only exception is when everyone on the team feels a different language is a better fit for the need or there are underlying reasons for a language shift.

Personally, my bias is towards the languages I'm most comfortable with. I recognize this and will make other suggestions and if I'm not responsible for the code, I'm more than flexible.

All the fad chasing and top down declarations that we're all going to use Cucumber, GraphQL, Microservices or anything else is often a bad move.

First learn the problem you are trying to solve and empathize on behalf of the user... Then empathize on behalf of support... on behalf of the maintenance developers... on behalf of yourself in a decade. Is there a boxed solution? Buy it.. Is something custom really needed, what can you outsource as part of it? integrate it. Do the simplest, easiest thing you can to get the job done.

[thomasmg]

> the language most of the team know the best

I fully agree. The challenge is, some will want to use the latest languages and technologies because they want to learn it (personal development, meaning: the next job). Sometimes the "new thing" can be limited to (non-critical) testing and utilities. But having many languages and technologies just increases the friction, complicates things, and prevents refactoring. Even mixing just scripts with regular languages is a problem; calling one language from another is similar. The same with unnecessary remote APIs. Less technologies is often better, even if the technologies are not the best (eg. using PostgreSQL for features like fulltext search, event processing, etc.)

This is a bit related to external dependencies vs build yourself (AKA reinvent the wheel). Quite often the external library, long term, causes more issues than building it yourself (assuming you _can_ build a competent implementation).

[balder1991]

> This is a bit related to external dependencies vs build yourself (AKA reinvent the wheel). Quite often the external library, long term, causes more issues than building it yourself (assuming you _can_ build a competent implementation).

I feel like this happens mostly because simpler is better, and most of these dependencies don’t follow a good “UNIX” philosophy of modularity, being generic etc. something that you’d notice the standard libraries try to achieve.

Most of these third party dependencies are just a very specific feature that starts to add more use cases until it becomes bloated to support multiple users with slightly different needs.

[pdimitar]

Yep, true in my experience as well. And in the age of LLMs it is not so difficult to ask it to extract just this or that piece of functionality into another package but with a different API. So these days it's even easier to roll your own stuff. It's not such a huge time sink as it sometimes was before.

[hunterpayne]

> More often than not, preference should be given to the language most of the team know the best.

I'm sorry but I disagree. Languages are tools, pick the best tool for the job. The idea that languages are all good at everything is not true. And when I see takes like this, I tend to think that that person just doesn't understand how to assess a language's strengths and weaknesses.

Want to write ML, probably best to use a language with functions as first class types (ie a FP language). You might say, most people doing ML use Python. This came to be because the language was picked based upon what people knew. But the big companies doing ML (successfully) don't use Python anymore and haven't for over a decade. ML researchers kept FP alive for several decades when nobody else cared because FP is the best tool for ML (or for writing a compiler). Where the FP folks get into trouble is trying to push FP where it doesn't make sense. I see this pattern repeating over and over again. Languages are pitched as silver bullets when they are just screwdrivers and hammers.

Right tool for the job, ignoring this leads to "religious wars" because that's how we describe disputes which are matters of taste.

Also, you are massively overvaluing expertise in a given language. A more talented engineer who doesn't know your favorite language after a couple of months will be better than you in your favorite language too despite your greater experience with that language.

[dwohnitmok]

> Want to write ML, probably best to use a language with functions as first class types (ie a FP language). You might say, most people doing ML use Python. This came to be because the language was picked based upon what people knew. But the big companies doing ML (successfully) don't use Python anymore and haven't for over a decade. ML researchers kept FP alive for several decades when nobody else cared because FP is the best tool for ML (or for writing a compiler).

I strongly disagree. The top AI companies are using a lot of Python (although sure they also use other languages too, but they're definitely using Python!). Even if by ML you mean old-school ML techniques, a ton of big companies also use Python for this (some might use MATLAB or R).

On the other hand I don't know of a single large company using an FP language for ML, unless you count something like Spark (which I would push back on: the Scala API of Spark is not really FP and almost all users of Spark that I know of program mainly in the more OO part of Scala rather than its FP part).

Even die-hard FP companies such as Jane Street use Python for their ML (see e.g. https://www.janestreet.com/join-jane-street/position/4276720... which notably mentions Python and does not mention OCaml).

Do you know of any company with a team of over 50 ML researchers (either old-school ML or modern AI) using an FP language as their primary workhorse for that team? Because I can't think of a single one.

More to the point, do you know of any ML researcher (and who is acknowledged as primarily an ML researcher by other ML researchers) who primarily programs in an FP language?

Even in the golden era of symbolic AI from the 70s and 80s they still weren't using FP languages (they basically didn't exist yet). The closest you could say is that they were using Lisps, but Lisps aren't FP languages by default. Some are (e.g. Clojure), but many aren't or at least aren't any more FP than any other multiparadigmatic language (e.g. Common Lisp). And again I don't know of any significant ML work being done in Lisps at this point (there's some scattered small teams and individuals doing work there, but nothing that I think could rise to the level of "big ML company").

[fabian2k]

I think for many cases it is fair to make the assumption that you're staying roughly within the same kind of application. So if your team previously did web applications you won't suddenly do embedded stuff or high-frequency trading. And within such an area, there aren't enough differences between languages to overcome the drawback of learning a new one.

[pdimitar]

There is plenty of difference in Web backends. F.ex. Elixir, Golang, Rust make parallelism much easier and they scale better on a single host (which is what at least 95% of all startups ever will need).

[tracker1]

I think you missed something...

> ... or there are underlying reasons for a language shift.

As to "best language" that is just as dogmatic as anything else... just look at the C/C++ vs. Rust divide in the Linux community.

I think you are overestimating the value of a best fit language for any given task, especially those where there are a half dozen popular languages that more people know well that can do the job good enough. Don't build for a sky scraper when all you need is a birdhouse.

Also, MOST engineers aren't particularly talented. If you're fortunate enough to be working for an organization where everyone is a rockstar, that's great... for those doing bog standard CRUD apps for business, you don't get rockstar money, and you aren't finding rockstar talent. You get what you get and make the pest of it.

In nearly three decades, I've once, only once worked a project where I didn't have to explain a relatively simple concept to someone, where everyone on the project delivers their pieces in time and all were talented. It was wonderful. Then new management gets stacked on top, all the job roles are reclassified to mid level developers and everyone rolls out of that group.

A lot of the actual experience is literally explaining public/private key usage to other developers who manage to (re)use the same keys from dev to all the production deployments. Or a pissing match with the "security expert" who doesn't understand that your app's use case is different than the in the box security script that is failing, because your /login route is a different app from / and the bogus query params don't matter.