[wpietri]

> 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.

As an example, for fun I've been working on a mobile app using Dart and Flutter. They are clearly targeting the niche of "mobile app developers who want to be cross platform and don't really care about it being a perfect iOS experience". Which is a pretty big niche, and Google has invested a lot in the platform, so I'm enjoying it. But library support is about 10% of what I'd want, so for things where in Python I'd have a few decent packages to pick from, in Flutter I'm often deciding between an under-maintained 0.0.7 and rolling my own.

If I were doing this for real and with funding, this would at least be a risky bet. Maybe we save 20-40% on our mobile dev costs and , maybe we get screwed by Google's fickleness and have to rewrite everything. Does that offset the extra recruiting and ramp-up time costs? Are good mobile devs willing to work in a less marketable language? Will Google dessert-topping-and-floor-wax it to death in service of internal political goals? Etc, etc.

Scala's in a similar bucket for me. I tried it out and liked it well enough. It's certainly reliable; I wrote my home lighting system in it and the only failure I've had in 3+ years was when Kubernetes shat the bed. But I'm of a similar mindset to Eckel on this: when it's good it's good, but it has a lot of cliffs that I found it very easy to stumble over. [1] Add on top of the hiring problems, and I'm wondering in what niches the economic case is strong enough. Especially so if it's going to keep dropping in popularity.

[1] https://www.bruceeckel.com/2015/08/29/what-i-do/

[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).