Live data from Hacker News

Scala 3 slowed us down?

kmaliszewski9.github.io

21–30 of 195 posts

Re: Scala 3 slowed us down?

#21
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?

That's kind of what I'm asking. I did have a former co-worker write a micro service in Kotlin around 2018. He said that as nice as the language is, the ecosystem was (at the time, not sure how it is today) so utterly dominated by Android development, that he said he wouldn't recommend using it again - half the time he was calling out Java anyways.

Re: Scala 3 slowed us down?

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

Re: Scala 3 slowed us down?

#23
post #18

Earlier quoted context omitted.

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?

That's kind of what I'm asking. I did have a former co-worker write a micro service in Kotlin around 2018. He said that as nice as the language is, the ecosystem was (at the time, not sure how it is today) so utterly dominated by Android development, that he said he wouldn't recommend using it again - half the time he was calling out Java anyways.

I use kotlin and I do not feel oppressed by Android in any way. And I'd rather call Java libraries from Kotlin than Java. Many have Kotlin wrappers.

Re: Scala 3 slowed us down?

#25
post #4
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?

For production systems I use flight recordings (jfrs). To analyze I use java mission control.

For OOME problems I use a heap dump and eclipse memory analysis tool.

For microbenchmarks, I use JMH. But I tend to try and avoid doing those.

Re: Scala 3 slowed us down?

#26
post #16
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.

You could also have compared it, more attractively, to Haskell.

Except the reason behind the syntax change is the losing mindshare from Scala into Python, after its relevance in the big data wave that predated the current AI wave.

Nothing to do with Haskell, even if it is also white space significant.

Re: Scala 3 slowed us down?

#27

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 create this problem.

Re: Scala 3 slowed us down?

#28
post #18

Earlier quoted context omitted.

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?

That's kind of what I'm asking. I did have a former co-worker write a micro service in Kotlin around 2018. He said that as nice as the language is, the ecosystem was (at the time, not sure how it is today) so utterly dominated by Android development, that he said he wouldn't recommend using it again - half the time he was calling out Java anyways.

That's a weird take. Even if true, kotlin has perfect interop with calling Java libs so there's not really a downside to keep using Java libs. There's not that much demand for kotlin-specific libs outside multiplatform which includes Android.

For what it's worth, Spring has first tier Kotlin support, I haven't noticed this bias.

Re: Scala 3 slowed us down?

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

Re: Scala 3 slowed us down?

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

Sort of true, but I often hear this take from Java programmers and it feels like "Blub" [1]/Stockholm syndrome to me.

Personally, I'm extremely glad to not have had to write .toStream().map(...).collect(Collectors.list()) or whatever in years for what could be a map. Similar with async code and exception handling.

For me one of the main advantages of Kotlin is that is decreases verbosity so much that the interesting business logic is actually much easier to follow. Even if you disregard all the things it has Java doesn't the syntax is just so much better.

[1] https://paulgraham.com/avg.html

Post reply on HN