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

141–150 of 195 posts

Re: Scala 3 slowed us down?

#141

Post by kokada »

AdieuToLogic wrote: post #114
_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…

> There's an important behavioral difference between Scala 2 and 3: in 2, @inline was merely a suggestion to the compiler, whereas in 3, the compiler unconditionally applies the inline keyword. Consequently, directly replacing @inline with inline when migrating from 2 to 3 is a mistake. This reminds me of a similar lesson C/C++ compilers had to learn with the "register" keyword. Early versions treated the keyword as…

And now we have things like `__attribute__((always_inline))` for GCC where you are completely, 100% sure that you want to inline :).

Re: Scala 3 slowed us down?

#142

Post by spicybbq »

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?

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

I've written multiple production services in Kotlin Spring Boot. Now, we're building a new system and using Java 21 (25 soon).

Why? Kotlin the language is great, but there are corresponding tradeoffs in interop. Meanwhile, Java the language has improved to the point that it's good enough, and Java feels like it's headed in the right direction. In my opinion, AI models are better at Java than Kotlin. If you prefer a weaker claim, the models are trained on more Java code than Kotlin code.

Finally, from an enterprise perspective, it is a safer long-term investment for a Java shop to own an application written in Java rather than in Kotlin.

Re: Scala 3 slowed us down?

#143

Post by bhawks »

pjmlp wrote: post #132
bhawks wrote: post #99

Earlier quoted context omitted.

| Android being Google's .NET, after Google being sued by coming up with Google's J++, Android Java dialect. The Oracle v Google was specifically over copyright infringement concerning the Java APIs used in Android's original implementation (Dalvik/ART), not about creating a "J++" dialect. Android never ran a JVM on mobile because it cannot be optimized for resource constrained devices a solution like DalvikVM was ne…

Lies sold by Google. Nokia and Sony Ericsson were using J2ME perfectly fine, as did Blackberry. I should know ad ex-Nokian. Kotlin met nothing, it was pushed by Kotlin heads working on Android Studio, telling lies comparing Kotlin to Java 7, instead of Java was already offering at the time. To this day they never do Kotlin vs Java samples, where modern Java is used, rather the version that bests fits their purpose to…

J2ME was an alphabet soup of incompatible implementations stuck somewhere between Java 1.2 and 1.3. Getting code to run across device manufacturers was a huge engineering burden. In fact doing something like JetPack for that world would be technically impossible.

If Sun was offering some technically relevant foundation for the smartphone era, it would have been able to actually have some adoption. They were starting from a leading position (obviously - see blackberry or Nokia), and in the space of 3 to 4 years they completely disappeared.

Re: Scala 3 slowed us down?

#144

Post by TuxSH »

AdieuToLogic wrote: post #114
_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…

> There's an important behavioral difference between Scala 2 and 3: in 2, @inline was merely a suggestion to the compiler, whereas in 3, the compiler unconditionally applies the inline keyword. Consequently, directly replacing @inline with inline when migrating from 2 to 3 is a mistake. This reminds me of a similar lesson C/C++ compilers had to learn with the "register" keyword. Early versions treated the keyword as…

> The C++ inline keyword is treated similarly as well, with different metrics used of course.

You are thinking of C's inline/static inline.

C++'s "inline" semantics (which are implied for constexpr functions, in-class-defined methods, and static constexpr class attributes) allow for multiple "weak" copies of a function or variable to exist with external linkage. Rather than just an optimization hint it's much more of a "I don't want to put this in any specific TU" these days.

Re: Scala 3 slowed us down?

#145

Post by re-thc »

bhawks wrote: post #143
pjmlp wrote: post #132

Earlier quoted context omitted.

Lies sold by Google. Nokia and Sony Ericsson were using J2ME perfectly fine, as did Blackberry. I should know ad ex-Nokian. Kotlin met nothing, it was pushed by Kotlin heads working on Android Studio, telling lies comparing Kotlin to Java 7, instead of Java was already offering at the time. To this day they never do Kotlin vs Java samples, where modern Java is used, rather the version that bests fits their purpose to…

J2ME was an alphabet soup of incompatible implementations stuck somewhere between Java 1.2 and 1.3. Getting code to run across device manufacturers was a huge engineering burden. In fact doing something like JetPack for that world would be technically impossible. If Sun was offering some technically relevant foundation for the smartphone era, it would have been able to actually have some adoption. They were starting…

> J2ME was an alphabet soup of incompatible implementations

So Google?

(alphabet)

Re: Scala 3 slowed us down?

#146

Post by theCodeStig »

pjmlp wrote: post #81
spockz wrote: post #66

Earlier quoted context omitted.

What I don’t get because there is LSP and BSP support. What else is needed to get support for scala 3 from an IDE? Obviously, Kotlin coming from Jetbrains will make it receive a lot more love and first class support.

Parity with Scala 2 development experience, which was lacking a year ago.

With Metals the Scala 3 development experience is better; plus one is no-longer tied to one specific IDE.

Re: Scala 3 slowed us down?

#147

Post by refulgentis »

geokon wrote: post #133
refulgentis wrote: post #129

Earlier quoted context omitted.

> I never understood why they do not track the OpenJDK versions. I don't work on Android apps.. but it seems mildly insane to basically have a weird almost-Java where you aren't even sure if you can use a given Java lib. NIH syndrome > (and not a Dart chat app.. but something actually performant that uses the hardware to the full extent) I used to work on Android, quit two years ago and have used Flutter since, it's…

Hmm, so if you wanted to make an AR app, or some audio processing app, would you do that in Flutter? All the projects I have in mind involve using the camera/microphone/gps etc. Looking at Dart sample projects it just seemed to be quite different from what they're aiming at

My caffeinated instinct is to say basically "yes I'd do anything in Flutter", I honestly would rather stop coding than go back to anything I've done before (ObjC/Swift/Java/Kotlin with side journeys in C++). It boggles my mind how much of a different job dev is with true hot reload.

More carefully, and dealing with what you're indicating more directly:

There's stuff that we just need every millisecond of performance from.

Generally, Dart's great, I don't notice any difference between iOS / Android standard UI platforms.

But...for example, Flutter's image decoding is actually using "native" code behind the scenes, i.e. calling into C or OS-level APIs or browser APIs as needed on each platform. And there's a Flutter package called "image" that's Dart-native but I abhor because I know it's going to be higher latency than going thru lower-level code. (now I'm wondering how Java does this...I wonder if its JNI...)

Let's do a scenario: I've been contracted to build a bus route app for the local gov't. They want an AR feature. What happens if I choose to build on Flutter, build out the basic features, then get to the AR, and I'm getting 5 fps?"

Solution to that is "plugins" - https://docs.flutter.dev/packages-and-plugins/developing-pac... - the intro to the doc is way out of date, like years. TL;DR is you can drop in C / Swift / Java / whatever easily as needed.

You can get a sense of what that looks like from my package for doing ML inference here: https://github.com/Telosnex/fonnx, specifically https://github.com/Telosnex/fonnx/tree/main/lib/models/minis...: X_native.dart shows us calling into shared C code on every non-mobile platform. On mobile, I have to take a dep on specific packaged & code signed libraries provided by Microsoft for ONNX. Then, I (AI, at this point) writes Swift and Kotlin to call into that library. (Swift: https://github.com/Telosnex/fonnx/blob/main/ios/Classes/OrtM..., Kotlin: https://github.com/Telosnex/fonnx/blob/main/android/src/main...)

This might feel convoluted at first, it did to me, but really, all that's going on is: when things are slow, we write a Dart interface, then for each platform where we want to use native code, provide impls of that interface in native.

Re: Scala 3 slowed us down?

#148

Post by still_grokking »

zahlman wrote: post #90
thefaux wrote: post #73

Earlier quoted context omitted.

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…

>It's sad but I generally agree. Scala was in my view pretty well positioned for an up and coming language ~2010-15 I used Scala for a bit around that period. My main recollection of it is getting Java compiler errors because Scala constructs were being implemented with deeply nested inner classes and the generated symbol names were too long.

> My main recollection of it is getting Java compiler errors because Scala constructs were being implemented with deeply nested inner classes and the generated symbol names were too long.

Sounds like you've used some beta version over 15 years ago.

Nothing like described happens in current Scala and it's like that as long as I can think back. Never even heard of such bugs like stated.

Coming up with such possibly made up stuff over 15 years later sounds like typical FUD, to be honest.

Re: Scala 3 slowed us down?

#149

Post by esafak »

frje1400 wrote: post #36
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?

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

Kotlin has already been around for ~10 years and it's in the TIOBE top 20. https://www.tiobe.com/tiobe-index/kotlin/

Re: Scala 3 slowed us down?

#150

Post by esafak »

malkia wrote: post #62
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.

Benchmarking requires a bit of different setup than the rest of the testing, especially if you want down to the ms timings. We have continous benchmarking of one of our tools, it's written in C++, and to get "same" results everytime we launch it on the same machine. This is far from ideal, but otherwise there be either noisy neighbours, pesky host (if it's vm), etc. etc. One idea that we thought was what if we can ru…

https://en.wikipedia.org/wiki/Hardware_performance_counter can help with noisy neighbors. I am still getting into this.
Post reply on HN