Scala 3 slowed us down?

I am not a scala fan and do not care for it, but I upvote for the thorough thought process, breakdown, and debugging of the problem. This is how technical blogs should be written. AI aint got shit on this.

In Scala 3, the inline keyword is part of the macro system.

When inline is used on a parameter, it instructs the compiler to inline the expression at the call site. If the expression is substantial, this creates considerable work for the JIT compiler.

Requesting inlining at the compiler level (as opposed to letting the JIT handle it) is risky unless you can guarantee that a later compiler phase will simplify the inlined code.

There's an important behavioral difference between Scala 2 and 3: in 2, @inline was merely a suggestion to the compiler, whereas in 3, the compiler unconditionally applies the inline keyword. Consequently, directly replacing @inline with inline when migrating from 2 to 3 is a mistake.

> After upgrading the library, performance and CPU characteristics on Scala 3 became indistinguishable from Scala 2.13.

We had a similar experience moving Ruby 2->3, which has a ton of performance improvements. It was in fact faster in many ways but we had issues with RAM spiking in production where it didn't in the past. It turned out simply upgrading a couple old dependencies (gems) to latest versions fixed most of the issues as people spotted similar issues as OP.

It's never good enough just to get it running with old code/dependencies, always lots of small things that can turn into bigger issues. You'll always be upgrading the system, not just the language.

The problem with Scala 3 is that nobody asked for it. The problem with Scala 2 is that the type inference part of the compiler is still broken. Nobody worked on that. Instead they changed the language in ways that don't address complaints. Completely ignore the market and deliver a product nobody wants. That's what happened here.

PS Perhaps they should make an actual unit test suite for their compiler. Instead they have a couple of dozen tests and have to guess if their compiler PR will break things.

> After upgrading the library, performance and CPU characteristics on Scala 3 became indistinguishable from Scala 2.13.

Checking the bug mentioned, it was fixed in 2022.

So, I’m wondering how one would upgrade to scala 3, while keeping old version of libraries?

Keeping updated libraries is a good practice (even mandatory if you get audits like PCI-DSS).

That part puzzled me more than the rest.

For me the main takeaway of this is that you want to have automated performance tests in place combined with insights into flamegraphs by default. And especially for these kind of major language upgrade changes.

I was involved in a Scala point version migration (2.x) migration a few years ago. I remember it being painful. Although I recall most of the pain was around having lots of dependencies and waiting for libraries to become available.

At the time Scala was on upswing because it had Spark as its killer app. It would have been a good time for the Scala maintainers to switch modes - from using Scala as a testbed for interesting programming-language theories and extensions to providing a usable platform as a general commercially usable programming language.

It missed the boat I feel. The window has passed (Spark moved to Python and Kotlin took over as the "modern" JVM language) and Scala is back to being an academic curiosity. But maybe the language curators never saw expanding mainstream usage as a goal.

The only issue I have with Scala 3 is Python envy, they should not have come up with a second syntax, and pushing it as the future.

If anything is slowly down Scala 3 is that, including the tooling ecosystem that needs to be updated to deal with it.

The bug reports linked on softwaremill and scala GitHub's are precise and surprisingly small fixes! It does show Scala's power in expressiveness.

Scala is a great language and I really prefer its typesafe and easy way to write powerful programs: https://www.lihaoyi.com/post/comlihaoyiScalaExecutablePseudo... Its a great Python replacement, especially if your project is not tied to ML libraries where Python is defacto, like JS on web.

The takeaway of upgrading your libraries when upgrading major language and framework versions applies beyond Scala. Especially when the libraries abuse magic language features (and far too many Scala libraries do) or otherwise integrate deep into the framework/language.

I know this topic has been beat to death but this is another example of why high level language with super optimizing compiler has had less industry success.

If performance is a feature it needs to be written in the code. Otherwise it implicitly regresses when you reorder a symbol and you have no recourse to fix it, other than fiddling to see if it likes another pattern.

I'm on Spark Scala 2 project and I hate it. Basically any good Scala dev would never want to work on our ETL projects, so we get second rate Python or Java devs like me who bastardize the language to get anything to work. Most of our new stuff is all pyspark, hopefully we can replace Scala asap.

https://www.experimental-history.com/p/bag-of-words-have-mer...

It's quite impressive that you can swap out major version from under running application and have just one subtle issue.

Awesome language, nice to see others using it.

I can thoroughly recommend it. Once of the best languages out there in terms of expressive power.

Thank you for sharing. Interesting insight on dep libraries.

I’m not familiar with Scala’s macro system, but it seems like a big takeaway here is: Be careful with code that invokes the compiler (JIT) at runtime. That seems like it’s asking for trouble.

Controversial opinion: Scala should have gone into maintenance mode a decade ago. They got the language right at the beginning, and a decade of tinkering has just fatigued everyone and destroyed any momentum the language once had.