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

51–60 of 195 posts

Re: Scala 3 slowed us down?

#51

Post by pjmlp »

esafak wrote: post #18
hylaride wrote: post #14

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?

Because the Java Virtual Machine is designed for Java, and that is what all vendors care about.

Kotlin is Google's C#, with Android being Google's .NET, after Google being sued by coming up with Google's J++, Android Java dialect.

Since Google wasn't able to come up with a replacement themselves, Fuchsia/Dart lost the internal politics, they adopted the language of the JetBrains, thanks to internal JetBrains advocates.

Re: Scala 3 slowed us down?

#52

Post by dtech »

pjmlp wrote: post #48
dtech wrote: post #27

Earlier quoted context omitted.

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.

Kotlin existed before Java 7 and kept support JVM 1.6 for a long time (mainly because of Android)

Even then, they benchmarked it, and inlining was still faster* than invokedynamic and friends, so they aren't changing it now JVM 1.8+ is a requirement.

* at the expense of expanded bytecode size

Re: Scala 3 slowed us down?

#53

Post by alberth »

groundzeros2015 wrote: post #50

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.

To be fair, it’s misleading to group Scala (or any JVM language), with other “high-level languages.”

The JVM is extremely mature and performant, and JVM-based languages often run 5x (or more) than non-JVM high-level languages like Python or Ruby.

Re: Scala 3 slowed us down?

#54

Post by groundzeros2015 »

alberth wrote: post #53
groundzeros2015 wrote: post #50

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.

To be fair, it’s misleading to group Scala (or any JVM language), with other “high-level languages.” The JVM is extremely mature and performant, and JVM-based languages often run 5x (or more) than non-JVM high-level languages like Python or Ruby.

That doesn’t follow. Scala is a high level language and compiler above the JVM. The bug here is a high level one:

> Turns out there was indeed a subtle bug making chained evaluations inefficient in Scala 3

I’m comparing with Haskell, Scheme, or even SQl which all promise to compile efficient code from high level descriptions.

Re: Scala 3 slowed us down?

#56

Post by pjmlp »

dtech wrote: post #52
pjmlp wrote: post #48

Earlier quoted context omitted.

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.

Kotlin existed before Java 7 and kept support JVM 1.6 for a long time (mainly because of Android) Even then, they benchmarked it, and inlining was still faster* than invokedynamic and friends, so they aren't changing it now JVM 1.8+ is a requirement. * at the expense of expanded bytecode size

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 and compete on merit, instead of sniffling one to push their own horse.

Even on their Podcast they reveal complete lack of knowledge where Java stands.

Re: Scala 3 slowed us down?

#57

Post by gavinray »

pjmlp wrote: post #48
dtech wrote: post #27

Earlier quoted context omitted.

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.

There are Kotlin compiler flags to default to "indy" optimization, and which may be enabled by default for some time now?

Also not all Kotlin inlines are lambdas or even include method calls

Re: Scala 3 slowed us down?

#58

Post by sema4hacker »

game_the0ry wrote: post #5

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.

> I was refreshing one of our services. Part of this process was to migrate codebase from Scala 2.13 to Scala 3.

My first question was: why?

Re: Scala 3 slowed us down?

#59

Post by gavinray »

hylaride wrote: post #21
esafak wrote: 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.

Kotlins "ecosystem" is all of Java, and then all of Kotlin.

Put another way: Java only has access to a subset of the ecosystem

Almost all of the backend libraries I use are Java libs. Some of them have additional Kotlin extension libs that add syntax sugar for more idiomatic code.

Re: Scala 3 slowed us down?

#60

Post by xolve »

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.

Post reply on HN