[zmmmmm]

> > But I just mean that not every language needs to aim to be a top 5 language.

> I wonder about the extent to which this is true. One of my primary considerations in picking the language for a product is economic fit. Once you get outside of the top 10 or so, I think you need an especially strong set of niche-specific positives to offset the negatives of a small community.

I think you have to take into account the ecosystem in that equation. Scala may have less than 5% programmer mindshare but it has access to the massive Java ecosystem underneath. So languages like that I think get to be viable at a significantly lower threshold than languages that require the whole ecosystem to be built from the ground up (even if that is mostly by writing wrappers that FFI to C libraries). The risk is heavily mitigated by that as well, as a retreat back to Java from Scala is far more doable than from say, Go or Rust to Java if things turn sour.

Scala is disadvantaged by the fact it philosophically departs from the Java ecosystem (in terms of FP, HOF, etc), because that pretty much ruins the interop story backwards into Java (that is, without effort, your idiomatic Scala code / library is not going to be accessible idiomatically to Java programmers). This is unlike Kotlin and Groovy both of which are built intentionally to fit smoothly into the bigger Java ecosystem (although Groovy is more so than Kotlin).

[wpietri]

Good point on the ecosystem. That definitely makes Scala more viable. I know I never would have tried it without that. Although I think that applies more to runtimes and (some) libraries than what I think the real drivers of cost are, like hiring and a community of practice (e.g., forums, mailing lists, and the likelihood of having the SO answer you need in your first few Google hits). And I think there's still a tax there; if you're doing a lot of Java interop you'll still have to know Java and the quirks of dealing with it from Scala.

Of course, there could be special-purpose stuff that's very nice not to have to rewrite. PDF generation comes to mind, as it's an enormous pain in the ass, and there are some good Java libraries for it. But it's often not much more work to encapsulate something like that as a service or a CLI tool.

Not to say people shouldn't do it, of course. But I'm not sure what Scala's niche should be as it shrinks. I originally saw it as a better Java, but I think Kotlin did a better job of is winning there. I get the impression that Clojure is doing better at "functional language on the JVM". Which is already a niche inside the FP niche. And given how much other languages have been learning from functional approaches, I don't know whether that niche is growing. I look forward to seeing if they find one.

[zmmmmm]

Yes, I agree with you, I think it's niche is probably going to shrink away from the "better java" and enterprise space but will probably hold up in the data science space as the only real counterpoint to Python for large scale distributed data processing. For people who for whatever reason want to use the JVM, or who need language performance that can't be achieved with Python, there isn't really anything else in the data science space to compete with it.

The killer problem for me is that you can't write a good library in Scala and have Java users adopt it. Because it uses its own collections etc, unless you build highly non-idiomatic Scala code, you will always end up with a huge impedence mismatch there. So while you can use libraries from java, you can't contribute to them, and your audience is always limited. Contrast with Kotlin or Groovy where you can write idiomatic Java-consumable libraries much more easily (esp. Groovy).