Live data from Hacker News

Scala 3 slowed us down?

kmaliszewski9.github.io

31–40 of 195 posts

Re: Scala 3 slowed us down?

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

Re: Scala 3 slowed us down?

#32
post #18

Earlier quoted context omitted.

Outside of Android work, has Kotlin really taken over? My understanding is that Java added a lot of functional programming and that took a lot of wind out of Scala's sails (though Scala's poor tooling certainly never helped anything).

Java's new features are always going to be on paper. The ecosystem, with all its legacy code, is always going to be a decade behind. And if you are starting a new project, why would you pick Java over Kotlin?

It’s a lot cheaper to hire for Java than for „modern“ languages.

Re: Scala 3 slowed us down?

#33

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.

Re: Scala 3 slowed us down?

#34

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.

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.

Re: Scala 3 slowed us down?

#35
post #34

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.

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.

Re: Scala 3 slowed us down?

#36
post #18

Earlier quoted context omitted.

Outside of Android work, has Kotlin really taken over? My understanding is that Java added a lot of functional programming and that took a lot of wind out of Scala's sails (though Scala's poor tooling certainly never helped anything).

Java's new features are always going to be on paper. The ecosystem, with all its legacy code, is always going to be a decade behind. And if you are starting a new project, why would you pick Java over Kotlin?

> And if you are starting a new project, why would you pick Java over Kotlin?

Because in 5-10 years you'll have a Java project that people can still maintain as if it's any other Java project. If you pick Kotlin, that might at that point no longer be a popular language in whatever niche you are in. What used to be the cool Kotlin project is now seen as a burden. See: Groovy, Clojure, Scala. Of course, I recognize that not all projects work on these kinds of timelines, but many do, including most things that I work on.

Re: Scala 3 slowed us down?

#37
post #6

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.

Everything is up to date with the new syntax as far as I'm aware. Also, the compiler and scalafmt can rewrite one to the other. A project can pick whatever style it wants and have CI reformat code to that style.

Re: Scala 3 slowed us down?

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

> Checking the bug mentioned, it was fixed in 2022.

I was considerably less impressed by the reporting when I finally found out the culprit.

Sure it was “Scala 3” … but not really.

It was an interaction of factors and I don’t think it would take away from the story to acknowledge that up front.

Re: Scala 3 slowed us down?

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

I'm confused as well, because he wrote

> I did it as usual - updating dependencies

but later

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

So... he didn't upgrade everything at first? Which IMO makes sense, generally you'd want to upgrade as little as possible with small steps. He just got unlucky.

Re: Scala 3 slowed us down?

#40
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…

Outside of Android work, has Kotlin really taken over? My understanding is that Java added a lot of functional programming and that took a lot of wind out of Scala's sails (though Scala's poor tooling certainly never helped anything).

> My understanding is that Java added a lot of functional programming

This is true, but needs more context. Java 8 added Stream API, which (at this time) was a fantastic breath of fresh air. However, the whole thing felt overengineered at many points, aka - it made complex things possible (collector chaining is admittedly cool, parallel streams are useful for quick-and-dirty data processing), but simple everyday things cumbersome. I cannot emphasize how tiring it was to have to write this useless bolierplate

  customers.stream().map(c -> c.getName()).collect(Collectors.joining(", "))
for 1000th time, knowing that

  customers.map(c -> c.getName()).join(", ")
is what users need 99.99999% of the time.
Post reply on HN