7 ms·

Scala is a great language, and functional programming (not pure functional) made me a much better programmer. And functional error handling is a fantastic way t

by osdev 10mo ago

Scala is a great language, and functional programming (not pure functional) made me a much better programmer. And functional error handling is a fantastic way to model success and failure, whether you’re using Either or the newer Result type. I have to both agree and disagree with some of the commenters here regarding why scala declined in usage. There are several reasons. 1. People just got fed up with the push toward pure FP and the complexity. Pure FP and category theory, and effect libraries are just not for the average audience. 2. Android support for Kotlin drastically reduced the momentum as well 3. Spark usage was pretty heavy driver for using Scala and I’m not sure about it’s used as much. 4. Scala became more and more niche as a result of item 1 above. This being said, I switched to Kotlin for all server side work. I think a language and in particular the ecosystem, needs the vision/stewardship that can offer more practicality and balance in the language design, programming style, tooling, and frameworks. Kotlin just became a simpler language with better support for all of the above. I can’t think of a better company to drive the development than Jetbrains. I don’t agree with all the choices, but Kotlin overall is a beautiful, simpler language, with all the practicality, and support needed to keep it going. However, now that Java is making strides in the language features, as compared to historical improvements at the VM level, I’m curious to see how the market share for Kotlin outside of android is going to be affected. Personally, I still prefer Kotlin for the practical FP support, Ktor as an HTTP server, and pretty good compatibility with Java. And lastly, I think there is enormous potential in multiplatform, as a strong alternative to typescript/react native for mobile. Disclosure: I am biased as I’m developing some libraries and soon to be made (more) public server framework.

hocuspocus 10mo ago
1. There was never a push. Functional ecosystems are simply the ones that survived. You can't blame communities that keep the language alive for doing what they want, and not what you want. Without Typelevel and ZIO where would be Scala 3's adoption today? 2. Android has never been even remotely relevant to the space where Scala exists. And no, this was not a missed opportunity for the language. People who think Scala had a shot are completely delusional. 3. I'm personally convinced Spark was the worst thing that happened to the ecosystem as it brought a lot of attention, and indeed, drove adoption, only to result in an incredible amount of shitty code plagued by the worst annoyances in the JVM and big data space. Spark is the biggest open source project in Scala, yet Databricks doesn't seem to give a damn about the language and couldn't even be bothered shipping a Scala 2.13 runtime for years after its release. I sincerely hope Spark moves away from the JVM entirely. Kotlin is really not any simpler especially with the constant feature creep that results in copying Scala features, only halfbaked. It's even less principled which is the biggest gripe against Scala having too many ways to do the same thing. There's nothing beautiful or practical about a language where people regularly write expression oriented code next to early returns.
- pjmlp 10mo ago
  Any language pushed by Android overload has a shot at Android. Kotlin would be irrelevant on the JVM space otherwise, only something being pushed by Jet Brains that some folks play with outside the company. There would not exist a Kotlin Foundation which is basically Jet Brains in bed with Google. I keep waiting for the announcement of Google's acquisition from Jet Brains.
  - hocuspocus 10mo ago
    Right and if you know the first thing about Scala, Kotlin, Google and JetBrains, it should be clear Scala on Android was simply never going to happen, even if Typesafe somehow managed to find extra millions in funding and could allocate dozens of people behind it.
    - pjmlp 10mo ago
      It certainly would, had Google decided that would happen, and support the ongoing existing efforts from the community. If you know anything about Google politics, you would know Kotlin only took off because of a couple of folks on the Android Tools team doing free advocacy for JetBrains. In an alternative reality, if those same persons had been Scala heads, Jetpack Compose would be a Scala DSL today.
      - hocuspocus 10mo ago
        Scala was a bad fit for the Android runtime and the SDK. On a $200 Android phone with 2015 specs the performance aspect was definitely not a trivial argument against Scala; Kotlin has perfect interop with very little overhead, no conversions between collections (often slow and immutable in Scala), a nullability story that doesn't box everything in Option, ... And most Googlers do not like clever languages with bad tooling, especially the ones working to productize languages and toolchains for Blaze and other internal tools.
        pjmlp 10mo ago
mrkeen 10mo ago
> People just got fed up with the push toward pure FP and the complexity. Pure FP and category theory Amen. My eyes start to glaze over whenever I read about covariance. It's one thing if a feature works because of category theory, but if you just "feel like arrays should be covariant", and then the actual category theorists come along and can't work with its limitations, maybe give it a miss.
blandflakes 10mo ago
> However, now that Java is making strides in the language features, as compared to historical improvements at the VM level, I’m curious to see how the market share for Kotlin outside of android is going to be affected. My employer has decided to abandon Scala, and they proposed Java as the language to head toward. I don't think Java's strides are fast enough to provide modern table stakes. In 2025, the big ones to me are: 1. null handling at the cultural and language level 2. abstractions over concurrency For null handling, Java has Option, but you're just going to have to deal with the fact that basically any API or caller can give you null. This is not good enough in 2025. For concurrency, Java has an excellent java.util.concurrent package (and the JVM is very good at concurrency in general). However, I've come to believe that it's a losing proposition to expect the average programmer to use concurrency primitives correctly, even at that level of abstraction. Every Java PR I review I have to add 20-30 comments about thread interruption, memory barriers, etc. Structured Concurrency helps, but is new/in preview, and hardly helps with actually providing safer concurrency operations. I think Java is doing the right things and the glacial pace of innovation at the language level is correct for protecting their users (contrast this with Scala 3...), but on the flipside I just think that it is hard to recommend Java vs C#/Kotlin.
- pjmlp 10mo ago
  Depending on the market, C# isn't always an option. One example out of many, https://www.aicas.com https://www.aicas.com This isn't like Meadows, this is a real-time VM with AOT compilation and soft-realtime deadlines, there are others. Or stuff like https://www.azul.com/products/prime/cloud-native-compiler https://www.azul.com/products/prime/cloud-native-compiler, again there are others offering the same. Kotlin will always be a second language on the JVM, it isn't what Oracle, IBM, and others think about when designing runtime features, and eventually like all guest languages will face the problem to either exposed the platform features, or have multiple ways, with different semantics, to achive the same. Virtual threads, versus co-routines, structured concurrency, SIMD/Vector, value class/records,....
  - blandflakes 10mo ago
    It frankly doesn't matter in which markets C# isn't an option - if you're in one of those, well... then obviously don't consider C#. That doesn't somehow indict C# as a language which better makes it possible to write concurrent code. For a very large proportion of the population, you're picking a language and running some services on a cloud provider or machine you control. The problem I'm citing in Java is not the performance, it's the semantics and having to explain what an InterruptedException is to every generation of programmers, including those who came before me. If you think virtual threads somehow do anything about what's difficult about concurrency on the JVM, we're talking on different wavelengths. Structured Concurrency is the TINIEST of baby steps and doesn't really do anything to change the experience, and it's only just now in preview, in the most recent LTS JVM? Hardly a solution. It doesn't matter whether the JVM is developed with Kotlin in mind, as long as Kotlin continues to offer a better way to leverage what the JVM does have to offer. It's not some killer argument that Kotlin somehow can't be useful if the host platform isn't specifically developing their roadmap (especially because you can... just write Java, if you need it?). Scala's demise likewise has nothing to do with whether the JVM is supporting Scala, and any suggestion that Java's language features have eliminated Scala's value proposition are similarly misplaced.

by osdev 10mo ago

hocuspocus 10mo ago

1. There was never a push. Functional ecosystems are simply the ones that survived. You can't blame communities that keep the language alive for doing what they want, and not what you want. Without Typelevel and ZIO where would be Scala 3's adoption today? 2. Android has never been even remotely relevant to the space where Scala exists. And no, this was not a missed opportunity for the language. People who think Scala had a shot are completely delusional. 3. I'm personally convinced Spark was the worst thing that happened to the ecosystem as it brought a lot of attention, and indeed, drove adoption, only to result in an incredible amount of shitty code plagued by the worst annoyances in the JVM and big data space. Spark is the biggest open source project in Scala, yet Databricks doesn't seem to give a damn about the language and couldn't even be bothered shipping a Scala 2.13 runtime for years after its release. I sincerely hope Spark moves away from the JVM entirely. Kotlin is really not any simpler especially with the constant feature creep that results in copying Scala features, only halfbaked. It's even less principled which is the biggest gripe against Scala having too many ways to do the same thing. There's nothing beautiful or practical about a language where people regularly write expression oriented code next to early returns.

pjmlp 10mo ago
Any language pushed by Android overload has a shot at Android. Kotlin would be irrelevant on the JVM space otherwise, only something being pushed by Jet Brains that some folks play with outside the company. There would not exist a Kotlin Foundation which is basically Jet Brains in bed with Google. I keep waiting for the announcement of Google's acquisition from Jet Brains.
- hocuspocus 10mo ago
  Right and if you know the first thing about Scala, Kotlin, Google and JetBrains, it should be clear Scala on Android was simply never going to happen, even if Typesafe somehow managed to find extra millions in funding and could allocate dozens of people behind it.
  - pjmlp 10mo ago
    It certainly would, had Google decided that would happen, and support the ongoing existing efforts from the community. If you know anything about Google politics, you would know Kotlin only took off because of a couple of folks on the Android Tools team doing free advocacy for JetBrains. In an alternative reality, if those same persons had been Scala heads, Jetpack Compose would be a Scala DSL today.
    - hocuspocus 10mo ago
      Scala was a bad fit for the Android runtime and the SDK. On a $200 Android phone with 2015 specs the performance aspect was definitely not a trivial argument against Scala; Kotlin has perfect interop with very little overhead, no conversions between collections (often slow and immutable in Scala), a nullability story that doesn't box everything in Option, ... And most Googlers do not like clever languages with bad tooling, especially the ones working to productize languages and toolchains for Blaze and other internal tools.
      - pjmlp 10mo ago

mrkeen 10mo ago

> People just got fed up with the push toward pure FP and the complexity. Pure FP and category theory Amen. My eyes start to glaze over whenever I read about covariance. It's one thing if a feature works because of category theory, but if you just "feel like arrays should be covariant", and then the actual category theorists come along and can't work with its limitations, maybe give it a miss.

blandflakes 10mo ago

> However, now that Java is making strides in the language features, as compared to historical improvements at the VM level, I’m curious to see how the market share for Kotlin outside of android is going to be affected. My employer has decided to abandon Scala, and they proposed Java as the language to head toward. I don't think Java's strides are fast enough to provide modern table stakes. In 2025, the big ones to me are: 1. null handling at the cultural and language level 2. abstractions over concurrency For null handling, Java has Option, but you're just going to have to deal with the fact that basically any API or caller can give you null. This is not good enough in 2025. For concurrency, Java has an excellent java.util.concurrent package (and the JVM is very good at concurrency in general). However, I've come to believe that it's a losing proposition to expect the average programmer to use concurrency primitives correctly, even at that level of abstraction. Every Java PR I review I have to add 20-30 comments about thread interruption, memory barriers, etc. Structured Concurrency helps, but is new/in preview, and hardly helps with actually providing safer concurrency operations. I think Java is doing the right things and the glacial pace of innovation at the language level is correct for protecting their users (contrast this with Scala 3...), but on the flipside I just think that it is hard to recommend Java vs C#/Kotlin.

pjmlp 10mo ago
Depending on the market, C# isn't always an option. One example out of many, https://www.aicas.com https://www.aicas.com This isn't like Meadows, this is a real-time VM with AOT compilation and soft-realtime deadlines, there are others. Or stuff like https://www.azul.com/products/prime/cloud-native-compiler https://www.azul.com/products/prime/cloud-native-compiler, again there are others offering the same. Kotlin will always be a second language on the JVM, it isn't what Oracle, IBM, and others think about when designing runtime features, and eventually like all guest languages will face the problem to either exposed the platform features, or have multiple ways, with different semantics, to achive the same. Virtual threads, versus co-routines, structured concurrency, SIMD/Vector, value class/records,....
- blandflakes 10mo ago
  It frankly doesn't matter in which markets C# isn't an option - if you're in one of those, well... then obviously don't consider C#. That doesn't somehow indict C# as a language which better makes it possible to write concurrent code. For a very large proportion of the population, you're picking a language and running some services on a cloud provider or machine you control. The problem I'm citing in Java is not the performance, it's the semantics and having to explain what an InterruptedException is to every generation of programmers, including those who came before me. If you think virtual threads somehow do anything about what's difficult about concurrency on the JVM, we're talking on different wavelengths. Structured Concurrency is the TINIEST of baby steps and doesn't really do anything to change the experience, and it's only just now in preview, in the most recent LTS JVM? Hardly a solution. It doesn't matter whether the JVM is developed with Kotlin in mind, as long as Kotlin continues to offer a better way to leverage what the JVM does have to offer. It's not some killer argument that Kotlin somehow can't be useful if the host platform isn't specifically developing their roadmap (especially because you can... just write Java, if you need it?). Scala's demise likewise has nothing to do with whether the JVM is supporting Scala, and any suggestion that Java's language features have eliminated Scala's value proposition are similarly misplaced.