Live data from Hacker News

Scala 3 slowed us down?

kmaliszewski9.github.io

91–100 of 195 posts

Re: Scala 3 slowed us down?

#91

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.

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

Yep. They have always been pretty honest about this.

I think that it blew up in industry because it really was ahead of its time. Type systems were pretty uncool before Scala. It proved that you could get OO and FP in a single type system.

Actually, a big part of reason for doing Scala 3 was rebasing the language on a more rigorous basis for unifying OO and FP. They felt that for all their other big ideas, it was time to rethink the fundamentals.

Re: Scala 3 slowed us down?

#92
post #32
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?

It’s a lot cheaper to hire for Java than for „modern“ languages.

Have you ever heard the expression "you get what you pay for?"

Re: Scala 3 slowed us down?

#93
post #53

Earlier quoted context omitted.

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.

The bug in TFA is hardly a reason that Scala is not a success, though.

Re: Scala 3 slowed us down?

#94

Earlier quoted context omitted.

Many of the Scala projects got people fired. Something the Scala devs largely ignore. Plus Scala support is truly awful even by the low standards of an OpenSource project. Then there is the fact that the Scala specific libraries are largely dead. Scala had/has a lot of promise. But how the language is marketed/managed/maintained really let a lot of people down and caused a lot of saltiness about it. And that is befor…

Kotlin has become a pretty big and complex language on its own so I'm not sure this is a good counterexample. The fundamental issue is that fixing Scala 2 warts warranted an entirely new compiler, TASTy, revamped macros... There was no way around most of the migration pains that we've witnessed. And at least the standard library got frozen for 6+ years. However I agree that the syntax is a textbook case of trying to…

One impressive thing for us is that the changes to macros were hardly an issue. We'd been trending off macro-heavy libraries for a while, and our Scala 3 adoption has not really been harmed by the new macro system.

Re: Scala 3 slowed us down?

#95
post #56

Earlier quoted context omitted.

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

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 Java 8. It supports the long-dead Java 7 plus a subset of Java 8 features. Android essentially froze their core application runtime in amber over ten years ago and have just been adding layer upon layer of compiler-level sugar ever since. The effect is an increasing loss of the benefit of being on the Java platform, in terms of code sharing.

Re: Scala 3 slowed us down?

#96

Earlier quoted context omitted.

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.

> 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. Yep. They have always been pretty honest about this. I think that it blew up in industry because it really was ahead of its time. Type systems were pretty uncool before Scala. It proved that you could get OO and FP in a single type system. Actually, a big part of reason for doing S…

> 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()”

Re: Scala 3 slowed us down?

#97

Earlier quoted context omitted.

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.

The bug in TFA is hardly a reason that Scala is not a success, though.

I didn’t say that. I’m highlighting a specific challenge of getting predictable performance over the lifetime of code.

Lower-level languages don’t have this same problem to the same extent. They have other problems Scala doesn’t have.

Re: Scala 3 slowed us down?

#98
post #65

Earlier quoted context omitted.

Sorry, I'm coming from C++-ish background - can anyone explain what's going on :)

Scala 2's syntax is mostly Java/C-style with a few peculiarities. Scala 3's optionally allows indentation based, brace-less syntax. Much closer to the ML family or Python, depending on how you look at it. It does indeed look better, but brings its share of issues.[1] Worse, a lot of people in the community, whether they like it or not, think this was an unnecessary distraction on top of the challenges for the entire…

My personal take is this would be like JavaScript adopting an optional Coffeescript[1] syntax. It's so different that it seems odd to make it an option vs a new language, etc.

[1] https://coffeescript.org/#introduction

Re: Scala 3 slowed us down?

#99
post #51
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?

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

| 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 necessary. If you want to level critiques about creating fragmented dialects of Java I would recommend starting with J2ME. The only nice thing I can say about J2ME is at least it died.

The Android ecosystem was far too mature for Fuchsia/Dart to be successful without a very compelling interop story that was never produced.

As a technology Kotlin met Android's platform and community needs. Advocacy and politicking played a minimal, if any, role.

Re: Scala 3 slowed us down?

#100
post #30

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

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
Post reply on HN