Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scala 3 slowed us down?

kmaliszewski9.github.io

Post reply on HN
Print view View original

71–80 of 195 posts

Re: Scala 3 slowed us down?

#71

Post by tasuki »

jiehong wrote: post #31

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

> Keeping updated libraries is a good practice

First, the "good practice" argument is just an attempt to shut down the discussion. God wanted it so.

Second, I rather keep my dependencies outdated. New features, new bugs. Why update, unless there's a specific reason to do so? By upgrading, you're opening yourself up to:

- Accidental new bugs that didn't have the time to be spotted yet.

- Subtly different runtime characteristics (see the original post).

- Maintainer going rogue or the dependency getting hijacked and introducing security issues, unless you audit the full code whenever upgrading (which you don't).

Re: Scala 3 slowed us down?

#72

Post by hunterpayne »

munchler wrote: post #35
dtech wrote: post #34

Earlier quoted context omitted.

Macro's are compile time, there is no runtime codegen. The problem was overly-frequent inlining generating enormous expressions, causing a lot JIT phase and slow execution.

Thank you for the clarification. If I understand correctly, these large expressions are created at compile-time, but the impact isn't felt until JIT occurs in the runtime environment. In that scenario, shouldn't the JIT just run once at startup, though? I'm still not quite understanding how JIT can take so much time in a production environment.

Because the jit will let the unoptimized code run a few (hundred) times to take measurements to know what needs to be optimized and how it needs to be optimized. This is a good solution and makes hotspot very effective. The problem is that it happens randomly a few minutes/seconds into the operation of the service. So you randomly have a big pause with the performance hit everytime you run the service. The upside is that this only happens once. But you have to plan for a big performance hit to requests which are unlucky enough to be called at the wrong time.

Re: Scala 3 slowed us down?

#73

Post by thefaux »

hunterpayne wrote: post #64

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 h…

It's sad but I generally agree. Scala was in my view pretty well positioned for an up and coming language ~2010-15. Not only did the scala 3 rewrite fail to address many of the most common pain points -- compile times and tooling immediately come to mind -- the rewrite took many years and completely stalled the momentum of the project. I have to wonder at this point who is actually starting a new project in scala in 2025.

It's really a shame because in many ways I do think it is a better language than anything else that is widely used in industry but it seems the world has moved on.

Re: Scala 3 slowed us down?

#74

Post by oelang »

hunterpayne wrote: post #64

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 h…

And I wish you read the article, you're comments are completely off topic.

Re: Scala 3 slowed us down?

#75

Post by voidfunc »

hunterpayne wrote: post #64

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 h…

Scala has deep roots in the Ivory Towers of Academia, its not shocking they think they know better than their users what the problems with the language are and didn't do any kind of real product management to figure out the actual problems before embarking on a rebuild.

Re: Scala 3 slowed us down?

#76

Post by hunterpayne »

instig007 wrote: post #33
phendrenad2 wrote: post #29

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.

> and a decade of tinkering has just fatigued everyone and destroyed any momentum the language once had. it's hard to buy it, considering that many of those "fatigued" moved on Kotlin, led by their managers' bs talking points.

Many of the Scala projects got people fired. Something the Scala devs largely ignore. Plus Scala support is truly awful even by the low standards of an OpenSource project. Then there is the fact that the Scala specific libraries are largely dead.

Scala had/has a lot of promise. But how the language is marketed/managed/maintained really let a lot of people down and caused a lot of saltiness about it. And that is before we talk about the church of type-safety.

Scala is a more powerful language than Kotlin. But which do you want? A language with decent support that all your devs can use, or a language with more power but terrible support and only your very best devs can really take advantage of. And I say this as someone writing a compiler in Scala right now. Scala has its uses. But trying to get physicists used to Python to use it isn't one of them. Although that probably says more about the data science folks than Scala.

PS The GP is right, they should have focused on support and fixing the problems with the Scala compiler instead of changing the language. The original language spec is the best thing the Scala devs ever made.

Re: Scala 3 slowed us down?

#77

Post by izacus »

wrathofmonads wrote: post #67
derriz wrote: post #9

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 inter…

Kotlin hasn’t made much of an impact in server-side development on the JVM. I’m not sure where this perception comes from, but in my experience, it’s virtually nonexistent in the local job market.

Why is your personal experience relevant to the wider market? How many companies and locations did you survey for that?

Re: Scala 3 slowed us down?

#78

Post by imtringued »

hunterpayne wrote: post #68
pjmlp wrote: post #56

Earlier quoted context omitted.

Java 7 to Java 25 is a world apart, and then on which JVM? Naturally it is a requirement, JetBrains and Google only care about the JVM as means to launch their Kotlin platform, pity that they aren't into making a KVM to show Kotlin greatness. If it feels salty, I would have appreciated if Android team was honest about Java vs Kotlin, but they weren't and still aren't. If they were, both languages would be supported a…

Maybe the JVM team should listen to the market then and disable the jigsaw encapsulation that keeps devs on 1.8. Forcing a questionable security framework on everyone is why 1.8 is still used. Again, this is a problem because the PMs (and some devs) refuse to listen to what the market wants. So they are stuck keeping a 20 year old version of the code working. Serves them right to have to do this. It is their penance…

What you're asking for is essentially commercial support from Oracle.

Re: Scala 3 slowed us down?

#79

Post by lispisok »

hunterpayne wrote: post #64

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 h…

I tried getting into Scala several times and kept going back to Clojure. Unless you are into type system minigames Clojure has many of the things Scala advertises but without the dumptruck of Scala overhead and complexity. Another commenter briefly touched on this but it's a language made by academics for academics to play with language design. It was a little weird it blew up in industry for a while.

Re: Scala 3 slowed us down?

#80

Post by pjmlp »

hunterpayne wrote: post #68
pjmlp wrote: post #56

Earlier quoted context omitted.

Java 7 to Java 25 is a world apart, and then on which JVM? Naturally it is a requirement, JetBrains and Google only care about the JVM as means to launch their Kotlin platform, pity that they aren't into making a KVM to show Kotlin greatness. If it feels salty, I would have appreciated if Android team was honest about Java vs Kotlin, but they weren't and still aren't. If they were, both languages would be supported a…

Maybe the JVM team should listen to the market then and disable the jigsaw encapsulation that keeps devs on 1.8. Forcing a questionable security framework on everyone is why 1.8 is still used. Again, this is a problem because the PMs (and some devs) refuse to listen to what the market wants. So they are stuck keeping a 20 year old version of the code working. Serves them right to have to do this. It is their penance…

I have not done a Java 8 project in years, other than Android because the reasons we all know.

Maybe Google could finally support latest Java versions on Android, instead of begrudgingly update when Kotlin lags behind Maven Central most used versions.

Which by the way is a Java 17 subset, not Java 8, when supporting Android versions below Android 12 isn't required.

Post reply on HN