Live data from Hacker News

Scala 3 slowed us down?

kmaliszewski9.github.io

121–130 of 195 posts

Re: Scala 3 slowed us down?

#121

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?

Why not though the upgrade process from 2.13 to 3 is pretty smooth. And you get all the new language features. I can think of a few that I actually like. I’ll just mention enums because it’s a good example.

Re: Scala 3 slowed us down?

#122
post #119

The problem with Scala 3 is that nobody asked for it. The problem with Scala 2 is that the type inference part of the compiler is still broken. Nobody worked on that. Instead they changed the language in ways that don't address complaints. Completely ignore the market and deliver a product nobody wants. That's what happened here. PS Perhaps they should make an actual unit test suite for their compiler. Instead they h…

It was absolutely amazing how stubborn and ridiculous the whole bracket-less syntax change was handled. It was basically a dictatorial decision that they pretended to be a community decision. It was just pushed and tons of people voiced their disapproval. In the end it was "so bad so sad you can always reenable brackets". They did it to try to appeal to Pythonists.. turns out that wasn't why Pythonists didn't use sca…

I think it’s nice to be able to use it. But like pretty much everything in scala, it’s a huge smorgasbord of things from which you can choose. I personally don’t use that syntax, but it’s cool that I can and sometimes I do just for fun.

Re: Scala 3 slowed us down?

#123

The problem with Scala 3 is that nobody asked for it. The problem with Scala 2 is that the type inference part of the compiler is still broken. Nobody worked on that. Instead they changed the language in ways that don't address complaints. Completely ignore the market and deliver a product nobody wants. That's what happened here. PS Perhaps they should make an actual unit test suite for their compiler. Instead they h…

I tried getting into Scala several times and kept going back to Clojure. Unless you are into type system minigames Clojure has many of the things Scala advertises but without the dumptruck of Scala overhead and complexity. Another commenter briefly touched on this but it's a language made by academics for academics to play with language design. It was a little weird it blew up in industry for a while.

The simplicity of closure is certainly a main part of its appeal. I’ve never done OOP in it, but I don’t think I want to. I have a lot of respect for it though.

Re: Scala 3 slowed us down?

#124

Earlier quoted context omitted.

> Type systems were pretty uncool before Scala I’m not up on programming language engineering as much as I should be at 37, could you elaborate a bit here? (To my untrained ear, it sounds like you’re saying Scala was one of the first languages that helped types break through? And I’m thinking that means, like, have int x = 42; or Foo y = new Foo()”

Not types, type-safety. Things like covariant and contravariant type declarations, implicit types (variables looked up by type instead of by label), and other things that you need to make a type safe system/service/application. The problem is that that feature of a language is massively oversold. Its nice but to pretend it prevents bugs or is even a great design goal is questionable and not backed up by research (as…

But it’s still a way more powerful and expressive type system than Java. So using it in a JVM ecosystem is a perfect fit.

Re: Scala 3 slowed us down?

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

[deleted]

Re: Scala 3 slowed us down?

#126

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?

If you're going to "refresh" a codebase you probably want it to be on the current version of things. Old dependencies rot, like it or not. I don't think there's any timeframe for Scala 2 EOL yet, but new development is happening in 3.

Re: Scala 3 slowed us down?

#127

Earlier quoted context omitted.

Maybe the JVM team should listen to the market then and disable the jigsaw encapsulation that keeps devs on 1.8. Forcing a questionable security framework on everyone is why 1.8 is still used. Again, this is a problem because the PMs (and some devs) refuse to listen to what the market wants. So they are stuck keeping a 20 year old version of the code working. Serves them right to have to do this. It is their penance…

I'm pretty sure that the majority of shops that aren't worrying about Android have moved on from Java 8. The JVM team only keep Java 8 working for customers paying them lots of money for extended support contracts. And that's only because they have this long-term extended support system for all LTS JVM releases (they are also still supporting 11 in a similar manner). On the other hand, Android doesn't even support Ja…

Didn't Google win the lawsuit with Oracle?

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.

Ex: I just took a look at a dependency I'm using

https://github.com/locationtech/spatial4j

Can it be used on Android..? I have no idea

From what I understand it's a weird stack now where nobody is actually writing Java for Android.

I'm still waiting for the day I can write a Clojure app for my phone..

(and not a Dart chat app.. but something actually performant that uses the hardware to the full extent)

Re: Scala 3 slowed us down?

#128
post #30

Earlier quoted context omitted.

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…

Java 16+ stream.map(...).toList() https://bugs.openjdk.org/browse/JDK-8180352

So only 2 bullshit boilerplate calls instead of 3? I guess that's progress.

Re: Scala 3 slowed us down?

#129
post #127

Earlier quoted context omitted.

I'm pretty sure that the majority of shops that aren't worrying about Android have moved on from Java 8. The JVM team only keep Java 8 working for customers paying them lots of money for extended support contracts. And that's only because they have this long-term extended support system for all LTS JVM releases (they are also still supporting 11 in a similar manner). On the other hand, Android doesn't even support Ja…

Didn't Google win the lawsuit with Oracle? 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. Ex: I just took a look at a dependency I'm using https://github.com/locationtech/spatial4j Can it be used on Android..? I have no idea From what I understand…

> 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 a breath of fresh air. It does use the hardware to the full extent, imo it's significantly more performant: it does an end-around all the ossified Android nonsense.

Re: Scala 3 slowed us down?

#130

Earlier quoted context omitted.

What you're asking for is essentially commercial support from Oracle.

Nope, what I am asking for is disabling an on by default feature that maybe 1% of the market wants and/or needs and creates significant pain for the other 99%. By the time strong encapsulation meets an attacker, the battle is already lost most of the time.

It's not just for security, it's also for maintainability. Frankly being able to reflect across package boundaries has always seemed like a misfeature for maintainability to me. The code you have that is broken by Java 9 was already badly behaved, the JVM was just lenient about it.
Post reply on HN