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

41–50 of 195 posts

Re: Scala 3 slowed us down?

#41

Post by weego »

jfim wrote: post #20
gedy wrote: post #11

Earlier quoted context omitted.

As a former Scala fan, wow you aren't kidding, wth val month = i match case 1 => "January" case 2 => "February" // more months here ... case 11 => "November" case 12 => "December" case _ => "Invalid month" // the default, catch-all // used for a side effect: i match case 1 | 3 | 5 | 7 | 9 => println("odd") case 2 | 4 | 6 | 8 | 10 => println("even") // a function written with 'match': def isTrueInPerl(a: Matchable): B…

It's been a while since I touched Scala but wasn't that a thing in previous versions, minus the braces not being present?

Yes, that's all just as it was, and in places braces were not required / interchangeable so this is more of an optional compiler choice than a real change

Re: Scala 3 slowed us down?

#42

Post by gavinray »

mystifyingpoi wrote: post #39
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.

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.

It would have been a transitive dependency based on the comments about the library being "transparent" and the author unaware it was even used.

Pinning specific versions of transitive deps is fairly common in large JVM projects due to either security reasons or ABI compatibility or bugs

Re: Scala 3 slowed us down?

#43

Post by gavinray »

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.

If your Maven/Gradle/SBT build specifies a version constraint for a third party lib, updating your Scala or Kotlin version doesn't affect this

(For scala-specific libs, there is a bit more nuance, because lib versions contain scala version + lib version, e.g. foolib:2.12_1.0.2 where 2.12 = scala version)

Re: Scala 3 slowed us down?

#44

Post by gavinray »

dtech wrote: post #27
_old_dude_ wrote: post #10

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

Kotlin heavily uses the inline keyword basically everywhere, to get rid of lamdba overhead for functions like map. Basically every stdlib and 3rd part library function that takes a lamdba is inlined. In general it's a performance benefit and I never heard of performance problems like this. I wonder if combined with Scala's infamous macro system and libraries like quicklens it can generate huge expressions which creat…

The killer is specifically the inlining of macros -- which Kotlin lacks.

And not all macros, but just the ones which expand to massive expressions

Think template expressions in C++ or proc macros in Rust

Re: Scala 3 slowed us down?

#45

Post by gavinray »

esafak wrote: post #4
spockz wrote: post #2

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.

What are folks using for perf testing on JVM these days?

async-profiler

Re: Scala 3 slowed us down?

#46

Post by gavinray »

hylaride wrote: post #14
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…

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 org had to write a pivotal backend service on the JVM, due to JDBC having the largest number of data source adapters.

The choice was Kotlin. Scala is too "powerful" and can be written in a style that is difficult for others, and Java too verbose.

Kotlin is instantly familiar to modern TypeScript/Swift/Rust etc devs.

The only negative in my mind has been IntelliJ being the only decent IDE, but even this has changed recently with Jetbrains releasing `kotlin-lsp` for VS Code

https://github.com/Kotlin/kotlin-lsp

Re: Scala 3 slowed us down?

#47

Post by pjmlp »

noelwelsh wrote: post #37
pjmlp wrote: 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.

When I checked a year ago, the IDE tooling still wasn't quite there.

Re: Scala 3 slowed us down?

#48

Post by pjmlp »

dtech wrote: post #27
_old_dude_ wrote: post #10

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

Kotlin heavily uses the inline keyword basically everywhere, to get rid of lamdba overhead for functions like map. Basically every stdlib and 3rd part library function that takes a lamdba is inlined. In general it's a performance benefit and I never heard of performance problems like this. I wonder if combined with Scala's infamous macro system and libraries like quicklens it can generate huge expressions which creat…

This is one example why being a guest language isn't optimal.

They should have made use of JVM bytecodes that allow to optimize lambdas away and make JIT aware of them, via invokedynamic and MethodHandle optimizations.

Naturally they cannot rely on them being there, because Kotlin also needs to target ART, JS runtimes, WebAssembly and its own native version.

Re: Scala 3 slowed us down?

#49

Post by pjmlp »

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 is an Android language, because Google says so, and they stiffle Java support on purpose (Java 17 LTS subset currently).

Outside Android, I don't even care it exists.

If I remember correctly, latest InfoQ survey had it about 10% market share of JVM projects.

Re: Scala 3 slowed us down?

#50

Post by groundzeros2015 »

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.

Post reply on HN