I don't disagree, but Java keeps adding features that make it closer to Scala, and Kotlin is well-supported and has cleaner syntax, so you have better choices than C++. The space between C and C++ is too fragmented, and too many of the languages are niche.

Yes, I haven't been in the Java world for almost 10 years now, so I can't comment too much on that, but it seems like Java improvements & Kotlin have vacuumed up the reasoning for using something like Scala. When I used it 12 years ago, the core Java language itself was terribly anemic.

Java stagnated for a long time at 7. Java 8 really started the change and it has been moving forward at a good pace since then.

I'm going to say maybe too fast. Not that the changes aren't good (they are good) but rather that the pace of features from 8 to 11 and then 11 to 17 has been fast and trying to get old toolchains updated to 8 (yes, it pains me) - much less use the features that are present in 11.

While in the organization that I work in there was some "ok, we've got old things on the computers, update to the latest Java now?" was postponed until September so that we can say "Java 17 is the standard" and have that be our long term platform for awhile.

But there are a lot of people who are still writing code that would compile in 7.

Looking at the version history, 12 years ago would have been Java 6... there were a lot of good changes with collections in Java 7. https://www.oracle.com/java/technologies/javase/jdk7-relnote...

The try with resources and catches were the two big things that made 7 much better than 6 for me. And with 8 - https://www.oracle.com/java/technologies/javase/8-whats-new.... - while:

* Classes in the new java.util.stream package provide a Stream API to support functional-style operations on streams of elements.

is only a single bullet point, that's a big thing.

That's how it is successful. HN said my post was too long, but here's my rebuttal to the op and it pretty much goes along with what you said: https://gist.github.com/jackcviers/a7e74a3ad0a57f6ab97afd25c...

If you are in the databricks Spark ecosystem -- stick to using the Databricks style and Spark libraries. Don't bring in anything that isn't in that ecosystem, because it runs way behind standard scala -- it's on a 6 year old version at this point.

If you don't want java to eat the features you use, use either the typelevel ecosystem or the ZIO scala ecosystem of libraries, use their respective preferred built-in DI methods (tagless final and ZIO environments, respectively).

If you don't mind eventually having java eat your features, go ahead and use the Lightbend ecosystem and buy the support license. If you don't want to buy support, the twitter/finagle ecosystem is basically the same without a support possibility. But within those there's definitely room for creative license.

All in all, the functional and typelevel subset works best as it's a tiny footprint of features and libraries, it doesn't leave any gray area for personal expression, and treats the language as its own language rather than clone - you - a - c++ - java - javascript - ruby.

Would I rather everything move to Mill? Yes. Is that ever going to happen, nope.

Some of the twitter ecosystem works fines with typelevel style. Finch, in particular, comes to mind

An evergreen conversation:

"I love C++." —Alice

"Oh? Which C++?" —Bob

Every successful C++ team defines its own C++ subset.

This is why I can't figure out how for the life of me to learn C++ effectively for professional use.

In reality it's not really like that. Yes different shops are going to be using different C++ features in different ways but they usually share some common "core" of the language.

One approach is to get a sample of code from the domain you want to inhabit, preferably including some from the very people you want to work with, and learn the subset of the language they use.

Also Stroustrup thinks that is the way to use cpp, his talks are all about 'do not use all of cpp, pick your features'. Makes senses in a way but it does lead to various notion of what cpp is.

That is exactly it. A company wide style and coding guide is a must with scala

A company wide style doesn't quite get it done. Is your style not to allow high kinded FP coding? (because it is too hard to understand). If so does that mean you don't allow libraries written in that style, like SLICK?

We had PHDs and very senior engineers, and they thought debugging common libraries like slick would take them weeks of work and they opted for avoiding that entire type of scala. But that is hard to do, because its a lot more than a coding style.

I do not think you do much high kinded Fp coding in slick other than "lifting" values from scala code to sql, though I havent worked with slick for in a while. I am not sure why they exposed internal types as we didnt really have any control over them

Perfectly said(!).