[solicode]

I often see comparisons to Go, Kotlin, Rust, etc, and I agree that it's unlikely for Scala to have a second renaissance and have an steep upward trajectory like those languages, but is that really a death of a language? I'm actually fine with Scala narrowing its scope and focus at being really good at just a couple of things. Such as embracing its FP-side more so than its OO-side. Not to say there is no value in its OO-side (I still see some value there mostly pertaining to modules). But I just mean that not every language needs to aim to be a top 5 language. FP and advanced type systems still seems to alienate a significant percentage of programmers for various reasons. That's fine. It's not like that sentiment is going to change overnight.

Scala missed its opportunity with Android. I think you just have to concede that to Kotlin at this point and just focus on moving in a direction that is not occupied. Which is why I mention FP with a strong focus on types. There's not much competition there besides Haskell. And since Haskell for the JVM will likely never be a thing (a few have tried, but none have gained traction), Scala is still there. And with the direction Scala 3 is going and all the improvements it brings, it's actually looking quite positive. At least in my eyes.

And besides, I don't think Scala has to be a "worse Haskell" in everything that it does. I think ZIO is a good example of a great Scala library that actually resulted in something really special by embracing what Scala can do: https://zio.dev

[osdev]

I agree with almost everything you're saying. I'll just add that while Scala missed it's opportunity with Android, the big problem has always been a borderline dogmatic approach to pure FP by the community at the cost of simplicity. Scala libraries are generally complex and difficult to use (sometimes even for Scala engineers with several years experience).

Also, core FP principles are not that hard (immutability, expressions, HOF, functional error handling, pattern matching), but when you go full / pure FP, that is a steep cliff and an end goal in itself that has serious time /monetary/ complexity costs. The real goals should always be a healthy balance of reasonably fast business functionality delivery and a good code base.

[solicode]

There is that, yeah. There was a lot of translating things from Haskell to Scala 1:1, and that didn't always work out so well. Well, actually it does mostly work on a technical level, but with heavy costs when it comes to ergonomics. The implicit imports and poor type inference was enough to cause frustration within our team.

That's why I specifically mentioned ZIO. Things improved greatly after migrating to it. It feels like it plays to Scala's strength. It infers well and we don't have a single implicit import to make it work. Well, with the 1 exception of the optional Duration syntax so that we can write "5 seconds" instead of "Duration(5, TimeUnit.SECONDS)".

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

[melling]

What is the story with Scala on Android? Years ago I thought it was a matter of using too much memory. There’s not much talk about it but it does seem to be possible:

https://scala-android.org/

Will Scala 3 help?

[oxnrtr]

As the person who was involved in Scala on Android (and particular in creating the website), I'll chime in with this:

What sunk Scala on Android was largely the completely lack of interest from the core team.

Everything that Scala on Android achieved was pretty much _despite_ the actions of Scala's upper echelon.

- It's hard to get a good message out, when core members spread FUD by bringing up problems that were solved year ago (like the big std lib issue).

- The core team's perception of Scala was always inward – new platforms existed such that Scala developers could run their code in more places, not because it could attract new developers from these existing ecosystems to Scala.

(Scala.js partially overcame this by herculean efforts of individual members of the Scala.js community that got the word out to the JavaScript world about Scala.js.)

- Core Scala pulled the plug from Android support in the backend. So Scala on Android was pretty much left to die on an outdated Scala version.

- Something like TASTY (an interchange format that can be recompiled on the fly to target new backends), which could have dealt with the problem above – was promised for years, but still hasn't shipped.

- The core team was against even acknowledging the existence of Scala on Android on the website – good luck in convincing that Scala on Android works, if the official website/documentation doesn't mention it with a single word.

- Core Scala treated the main contributor with so much public disrespect, that I'm still surprised he didn't outright quit back then. It takes balls to publicly blame the main contributor of Scala-on-Android for not working on the project full-time, but also conveniently managing not to tell him this crucial "requirement" for half a decade. And with "full-time" I mean "unpaid full-time".

It's a sad story, because Scala-on-Android shipped with some amazing features like hot-code-replacement years before Google managed to ship it. The typed resources stuff was also pretty impressive.

[oxnrtr]

So, no, Scala 3 won't help. Most people who cared left years ago.

[solicode]

I don't know the whole story. Perhaps somebody who knows can chime in. But my impression is that Android being stuck basically on pre-Java 8 at the time while Scala relying heavily on Java 8 features was one complication. Scala generating a bunch of class files for lambdas and so on with no SAM types + invokedynamic to reduce all that plus strange DEX limitations might have caused issues. Plus memory limitations like you said.

I'm not sure there are any real blockers for Scala on Android anymore. I imagine it's mostly a resource problem now. With Kotlin's momentum in that space though, I'm not sure too many people are calling for it anymore. Who knows though, maybe after Scala 3 is finally out the door priorities could shift.

[sideeffffect]

> not sure there are any real blockers for Scala on Android anymore. I imagine it's mostly a resource problem now

not really, it's still the problem Android being Java < 8, and Scala on Java 8 features.

https://github.com/scala-android/sbt-android/issues/334#issu...

[rst]

From a few years ago, with Scala 2, but the fundamentals may not have changed much.

Scala had, and has, a large bespoke standard library, which is big enough that if you tried to ship it with even a trivial app, it exceeded limits not just on memory, but on numbers of classes, methods, and so forth. (And even if those limits have been raised on newer phones, older ones are still a nontrivial market segment.)

So the way people got around that was by using "tree shakers", which would grovel through the app and its libraries, and chuck out portions of the library which weren't actually used. This works, but significantly complicates the development toolchain.

Between that and the official support for Kotlin as the "better Java" dialect of choice, you have to really like Scala to make it worth the effort...

[whateveracct]

> And since Haskell for the JVM will likely never be a thing (a few have tried, but none have gained traction)

It's more than social reasons. The JVM has technical limitations that ruin idiomatic Haskell. Lack of a mechanism for efficiently and modularly compiling general tail-call elimination.

For instance, if you traverse too long of a list, you'll blow your stack. You can try it and fail yourself with Eta.

FP in Scala has the same issues, but they have some extra utilities to work around it, but it's something you gotta be aware of.

[monksy]

One of the biggest complaints that I've had about Scala is it's community. They've made huge strides to make political statements and gatekeep who contributes. (The core team makes it worse for John De Goes (He's the guy that was either the creator or a big contributer with scalaz and zio) at every turn and it's really annoying)

[kev009]

F#?

[solicode]

F# is quite nice. I used it a long time ago for a couple of libraries when I was working in a team that mostly used C#. Fable looks really cool too.

I remember getting the feeling that C# is holding it back though. F# can't have any feature that it wants because interop in both directions seems to be a priority. If I recall correctly, that's what is holding back higher-kinded types in F#.

That, and the last time I tried F# on .NET Core things were still very rough. This was when .NET Core was still fairly new though. It might be fine now.

[sideeffffect]

> C# is holding it back though

not as much C# the language, as CLR, the runtime. Because of reified generics, which is the way things are done in the .NET world, and which the runtime needs to support, it would also require explicit support in the runtime for Higher-kinded types or Type classes. And that won't happen without C# having these features (and having them first).

F# is really really great, but it is like an unwanted child of Microsoft :(

https://github.com/fsharp/fslang-suggestions/issues/175