blandflakes

I think they're pretty different, but there are some places where you can compare them:

1. Hiring and job market - the JVM is simply more employable

2. Ecosystem - in general you can expect the JVM to have library support for most things you're going to need.

3. Typing - if you like static types, you're probably going to miss that in Elixir/Erlang. They're working on a gradual type system for Elixir that looks quite pragmatic, so I'm excited to see how that works out.

The Elixir side of things has some real advantages, though. Runtimes like the JVM are slowly adding threading paradigms that start to look like how the beam works, if you squint enough. Naturally, Elixir already has that, and already has technologies that work very well with it. Virtual threads on the JVM are a smart effort that will take a long time to be complete and will always have to take backwards-compatibility into account, especially if you're in Java itself.

Phoenix is also IMO a best-in-class web framework. I don't think it's universally applicable, but if any JVM language had something like Phoenix I doubt I'd be considering Elixir nearly as strongly (due to my affection for types). So while the JVM ecosystem is broader, it's not uniformly stronger.

I also think that "domain" is much broader for JVM stuff. The web technologies there feel pretty baroque rather than empowering, but you can still do web on the JVM, and Kotlin or Scala in particular IMO serve better for systems where the bulk of the code is internal business logic. I think that even if I adopted Elixir entirely, I'd probably retain some "second language" for deeper systems.

I find that if most of my logic is relatively gluey, then the fields in my API boundaries are heavily optional, at which point types add a lot less than they do when most of my logic is more internal, and in cases where what I'm doing is just getting some JSON and doing something with it, I'd rather just have the dynamic shape of the JSON in a lot of cases than have to declare an entire schema/codec.

We have so much boilerplate and tooling to share request/response types between services and it's just... heavy. The same feeling arises when I'm sitting here trying to share a shape between a web app and the backend service, where FINALLY I just want the types to get out of my way instead of having to go through all this ceremony.

And my domain is relatively precise and typeable - streaming video with a deterministic set of parameters.

Generally though I'm more likely to agree with the value of types than to undersell them; I just can't find a ways to describe the above experiences such that they reflect that perspective.

I think it's not that I don't want types, it's that I want simple types that play slightly more dynamically - maps of <string, heterogeneous values>, for example, and reasonable means of interacting with them (like various "safe traversal" operators that some languages have added).

This has sort of been my issue with Elixir. I've been doing Scala for years but I think Phoenix is really the best web story at the moment for how I want to be building web apps. And while I believe that the benefits of static typing somewhat decrease in the web arena, it's still frustrating to have to manage type relationships in my head.

I'm hopeful that the incoming type system work makes me happier there, though I'd also prefer a nicer editor experience than is currently available.

I always find downvoting on stuff like this perplexing. It still isn't there. I know that a lot of Scala people are doing metals and some kind of text editor experience, but if you've used something as powerful as Intellij, the Scala 3 experience is a serious downgrade, and it still is today, even though it's better than it was a year ago.

One impressive thing for us is that the changes to macros were hardly an issue. We'd been trending off macro-heavy libraries for a while, and our Scala 3 adoption has not really been harmed by the new macro system.

The bug in TFA is hardly a reason that Scala is not a success, though.

Have you ever heard the expression "you get what you pay for?"

I think we're simply going to have to agree to disagree.

Your position presupposes quite a bit of "systems already in motion" to make the point that there isn't friction. Except... there is, and _somebody_ has to maintain your builds, and handle all those fun deprecations like when the integration test project gets removed and the syntax gets updated. These things aren't stable, untouched pieces of your services over time, and I want everybody on my team, not just some experienced Scala developer who has already performed the rituals required to understand and establish practices for sbt, to contribute.

And what about the onramp to Scala? I'm certainly not relying on a team of established practitioners to pave the way when I'm learning a new language. We're talking about a dying language, I think it's silly to dismiss this.

> But anyway you're missing my point. Developer friendly toolchains are the exception, not the norm. There's some impact on industry adoption, but not a huge one all things considered. Otherwise nobody would have touched Python before 2024.

And you continue to miss mine - incumbent languages can afford more friction than niche languages. Python or Java's ability to have mediocre dev experiences do not have much bearing on how impactful Scala's is (though frankly, Java is not really worse than Scala in my opinion, and trendwise I think we see sbt displaced by java tools or mill more than maven or gradle in the reverse, so the industry tends to agree).

Bazel being used by some companies is not vindication that sbt wasn't a significant source of friction, just another arena where sbt was considered less fit for the job (whether one could argue sbt should have been able to do the job would certainly be context-dependent).

No, it doesn't matter. You are advocating for the special case, not the average case, and it has no bearing on C#'s _general_ aptness that it can't be deployed somewhere. The same is true of Java! This is nitpicking with no justification.

> Any guest language on the JVM will trip on the InterruptedException just as well, it is called leaky abstractions for a reason.

They can (and do) reduce how often and where you have to interact with it. I at this point am not sure whether you are intentionally arguing from a position of ignorance or whether this is actual bad faith. Are you suggesting that abstraction is not useful or impossible? Yes _obviously_ InterruptedException is still on the classpath and in implementation code; that doesn't mean we should throw in the towel and interact with APIs that constantly throw it.

> Improvements on the platfrom language eventually always drive the guest languages away, because all guest languages either lose their value proposition, or use the platform to bootstrap their own ecosystem.

You have done nothing to address the issue that Java adopts new features extremely conservatively and slowly. I already used the perfect example that you gave of Structured Concurrency, which is not only not enough, but not even available, and ten years late. It is simply false that Java has done anything significant to compete with its guest languages. Javascript, yes! C#... debatable, but certainly better at it than Java.

> Turns out when they take second option, they open the door to having libraries that only work in one platform, and the usual #ifdef like complexity.

This is why I'm skeptical of multiplatform approaches such as Kotlin's, but that my suggestion that Kotlin is useful is not based on any degree of multiplatform support. Even at the end of the day if I thought Kotlin didn't have a future, my point is that that is table stakes level of abstraction in 2025 and Java ain't it.

> Kotlin multiplatform being adopted by Google for huge projects like Google workspace makes it sound like it may actually be a winning proposition, if you ask me. Kotlin is replacing the more-than-a-decade old, battle tested, Java-to-ObjC translation at Google. I find that very impressive.

When it comes to Google, I'll believe it when I see it. How's Fucshia?

> For sharing code between e.g. Android and iOS, Kotlin multiplatform seems to become the better solution. If you use Rust, you still have to call it from Swift and you just introduced a 3rd language.

I'm not positing Rust for this or any multiplatform thing, I was suggesting that Scala Native is eclipsed by Rust in its relatively narrow niche (and actually in addition to Rust, graal native-image).

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.

I also work at a company that used to do a lot in Scala, and have seen the decline firsthand. Who's anecdata is better?

I think a lot of posters make the mistake of saying "$otherLanguage has it worse." That's irrelevant! If otherLanguage is an incumbent, they can afford to have it worse. I don't think it's debatable that sbt harmed adoption in the first place and continued to represent a barrier to Scala's adoption for years, and it doesn't matter how good maven is or isn't.

The degree to which is certainly always going to be up for debate; as mentioned before, there are many factors, but sbt was not a nonfactor.

I'm not advocating for Gradle either, but you already pointed out why the build tool being bad is relevant for Scala and not for Kotlin - Android developers have enough other reasons that they're going to use Kotlin, even though Gradle sucks. Scala developers... don't, and so just another straw stacked on a camel's back, so to speak.

Kotlin is pretty nice. I think the build tool in Scala being so esoteric didn't help with adoption; I remember avoiding Scala for a few years because dealing with sbt left a horrible taste in my mouth.

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

It competes in some ways and not in others. It does a pretty good job of providing similar benefits as many Scala ecosystems, but providing approachability over purity.

Kotlin becoming The Official Android Language helps it quite a bit, though the future gets interesting if Google successfully abandons the JVM entirely to rid themselves of Oracle. I'm skeptical that Kotlin targeting multiple runtimes is a winning proposition, but it certainly seems to be doing a better job than Scala Native (also Rust is probably the better choice than Scala Native for that kind of code anyway).

I think realistically we're looking at a lot of causes (which is not surprising; it's rarely a singular thing). Scala 3's momentum may have already been negative but how Scala 3 landed represented a nail in the coffin for a lot of individuals, teams, and organizations.

> IDE support for Scala 3 was really rough when it first released. We checked in on it with every IntelliJ release for roughly 3 years before we decided it was far enough along. Prior to that it was rough enough that we froze migration efforts in order to keep the tooling usable enough for engineers to be productive.

Same story for us - about 3 years before Intellij was usable, even then not up to what it had been on Scala 2. We still only have 2 Scala 3 repos, out of about 30, for my team, and we're actually MORE adventurous than most other teams at the company!

As other posters mentioned, a lot of it is about lacking critical mass in the first place. Making such a dramatic change is a high-risk thing, and Scala didn't have enough of a lead at all to justify it.

> The only bad thing was that it took quite long for Scala3 to become available leading to a lot of stagnation.

Unfortunately this isn't the only bad thing. The language overall is definitely a nicer language (though I complain about the whitespace change elsewhere). The tooling was broken for years, which actually stalled our team's migration. How could I advocate for moving to Scala 3, just to send everybody's editors and IDEs back to the stone age?

I'm not arguing that they built bad technology, I'm arguing that they ignored the reality: the value prop of moving to Scala 3 vs... moving to something else, at that point, isn't that compelling.

The language is actually really nice. The "we won't ship dotty as the next version of Scala, just kidding, here it is", the breakage of editors and IDEs that lasted for years, etc (aka, the WAY they did it) make migrating a poor value prop. If I have to suffer worse tools and pay the tax of fixing them/updating them, then for each system when I think it's time to migrate to Scala 3 I might think it's time to migrate off Scala entirely.

It's possible that nothing could have reversed their existing trend, but I think it's fair to say that smaller communities (as another poster mentioned) can't afford this level of friction. Have we not seen Perl->Raku? Python2-3?

Additionally, while almost all of Scala 3 is an improvement over 2, whitespace significance seems like an awful hill to die on. Most people who value that sort of syntax in domains where Scala has made any inroads are already on Python, and we're going to alienate many existing developers in the (vain) hope of increasing marketability?

Yeah, I think with a community as small as Scala's, you can't really afford:

a. fragmentation of the ecosystem b. repeated shuttering/abandonment of some of the most popular options (Lift, Play, Akka) c. splitting the language in two

The perception within and without my own employer (which heavily invests in Scala) swapped from "acceptable" to "this ecosystem is a dead-end and we need to get out" with the launch of Scala 3. It's possible they would have reached the same conclusion, but I don't think breaking every industry engineer's development tools for years is a good strategy.

They really obliterated their momentum with how they went about Scala 3, unfortunately.

I have a similar experience, though it's not necessarily related to shortcomings in the STM implementation (which I always felt was quite competent in the space). To expand, I think a few things are true:

1. I've come to feel that actually managing concurrency is a "below the fold" competency for most engineers. I'm not saying it should be, and people need to understand what a data race is. 2. As you pointed out, most state in services that I work on is not in need of coordinated updates, so atoms are where you want to be, or single-writer queues. 100% agreed 3. Structured concurrency approaches, fibers, and other abstracted runtimes seem to be the best way to get concurrent and parallel work, given points 1 and 2 about how coordinated state really isn't that common for most work on my team

A lot of times when we're updating state we're more having to think about it in the database, employing either a last-write-wins strategy or when coordination is in need, some form of pessimistic or optimistic locking.

I also feel like this is good advice when making a language shift, or any _other_ shift, even a stylistic one.

A lot of my coworkers get in this situation where, when a change in direction is made, they feel like we have to stuff the roadmap with work to rewrite everything. That work is... 0 value, in most cases, unless the decision we have made is intended to directly solve an issue in the existing code.

Many times I find that if you just do new work in the new thing, you'll "naturally" prioritize rewriting at the right rate. When we do it that way, we end up replacing, rather than rewriting, those legacy systems, which avoids the pitfall of trying to reproduce prior behavior, down to the bugs it may have had.

Joy is probably an improvement on slog, but one person's joy is another's hell. I've inherited a lot of joyful projects that were an awful fit for continued maintenance because joyful meant using new, unproven, and unstable technologies.

Return false! They aren't equal. But of course we're comparing a reference to a primitive, so we either lift the primitive to a reference, or lower the reference... so here we are.

This really becomes tedious when you're working with Java's primary means of codesharing/abstraction, inheritance. You can't subtract an IOException from an interface, and you can't introduce one if you're extending an interface. So you're forced to handle an exception that you frequently can't recover from and that paradoxically you probably don't expect to ever be thrown, for a majority of methods.

No disagreement on my part. I largely hope not to be in a world where I'm choosing between C or Go, though!

My job has been making a tactical retreat from Scala, and it's really fascinating to look to alternatives like F# and see that they're even less "successful", from an adoption point of view. I'm surprised at how little success even marginally higher-level languages than C# or Java are having.

As you say though, really we've seen a shift in a direction I didn't expect as much, more toward languages that aren't bringing a virtual machine. Even the dialog at work talks about elastic computing where the JVM is less of a dominant player than something that uses fewer resources and starts fast.

Go has really become the poster child for a lot of this momentum in my circles... intentionally not an elaborate language, good ecosystem, good runtime characteristics. I personally don't really want to be moving to Go, but the gulf between status quo and "moves the needle" languages has grown, not shrunk, these last few years, it feels.