That is a cop out. You always need to train your people. I've been doing C++ for 20 years, and consider myself somewhat and expert, but if I join your team I will still need to learn a lot of things that are just how your team does it. If I also need to learn Erlang/java/go/ (pick any language I haven't used much) that only adds a short time.

Even as complex as C++ is, I can train a great programmer C++ a lot faster than I can train a future great junior C++ programmer to be a great programmer. Yes you will encounter the rough edges of whatever language often in the first 5 years, but a great programmer will be great in any language quickly. You need one expert in the language on the team for the weird complex stuff, but most code isn't that complex.

I mean… sort of. It’d be like trying to write an ML stack in lisp circa 2023. Sure, you can find devs willing to learn it, but it’ll be at least two orders or magnitude easier to find python devs.

I love lisp, but the thought of being forced to use it exclusively for ML makes me uneasy. And I’ve tried building lisp ML stacks. :)

I’d probably use Hy and JAX, :)

Should be beautiful.

Beautiful perhaps, but not productive for ML engineers who are joining the team and familiar with the standard stack.

Sure, they can be retrained, but I feel that there’s a real cost to this, and it’s too tempting to handwave it away as “they should just learn.”

C++ was all the rage in late 90s / early 00s.

Java was all the rage then. C with classes was dominate (not to be confused with C++), but java was the rage. Just like today Rust is all the rage, but it isn't as popular as C++ in the real world.

I remember that. What puzzled me that it was the time when software written in Java ran up to 100 time slower than native processes. Now it is not nearly as bad.

I had very interesting reaction from CTO of one Telecom when I showed them a prototype running on PC handling the same amount of transactions without breaking sweat as their Java backend equivalent that ran on beefy HP servers.

Java is a language designed so that IBM can shovel interchangeable programmers into a furnace and produce something functional.

Once you start with that goal, all the compromises and quirks make more sense.

See, it's funny because as a consumer of software, I've overall been pretty pleased with solutions that come out of that process (think Jenkins, Artifactory, Elastic, Bazel).

So it does seem capable of leading to reasonable results on the eventual timescale, despite various inconveniences and tradeoffs along the way. Of course, lots of terrible software has certainly been written in Java too, so it's not fair to compare Java's cream of the crop with some random PyPI package and draw conclusions.

I think Java got a lot better when it stopped trying to bring along a OS GUI toolkit.

Hence the vastly different experience between Java-exposed-as-app and Java-exposed-as-webapp.

Do you mean big red and not big blue with that statement?

Also, this reads as unnecessary snide. Having a language that makes it easy to onboard new people is a major strength. A lot of Golangs success is attributed to that strength of the language.

IMHO, modern IBM (inasmuch as it exists) is the textbook target for Java, from a professional services standpoint.

And it's snide and isn't.

There's a lot to be said of being able to shovel programmers into a furnace and produce something functional. Decreasing risk to timeline and of failure makes large project PMs very happy. And generally makes stakeholders happy, because things don't outright fail as often.

> Do you mean big red and not big blue with that statement?

I assume you're referring to Oracle here, but Oracle didn't invent Java either. Java came out of Sun Microsystems, whose color scheme seems to shift between blue and purple, so "big violet?" Just doesn't have the same ring to it.

Java is also a language with extensive library support, and some of the most sophisticated tooling and virtual machines with state virtual machine and garbage collection implementations of any language. The most recent versions of the language are much more programmer friendly than previous versions, greatly cutting the expressibility gap with other languages.

Just stay away from Spring, and you can have a nice development experience.

The topic here isn't modern Java, it is last 90s early 2000s java. Spring was either not invented yet, but the thought process behind it was already in place, or the new hotness everyone needed to know.

Sun was the one creating and designing Java....

Pretty sure Sun wasn't working for IBM when they designed Java, were they?

Now, but IBM went all in on it which was an important boost.

Microsoft was big into C++ then.

C++ was terrible at cross-plaform (incompatible support for language futures across compiler), which was a deal breaker for many orgs.