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

131–140 of 195 posts

Re: Scala 3 slowed us down?

#131

Post by fulafel »

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…

I don't think Clojure belongs there. It was never as big as Kotlin, but it's got great community, longevity and takes backwards compatibility very seriously, and 10 year old Clojure projects seem to be aging at least as well as 10 year old Java projects.

Re: Scala 3 slowed us down?

#132

Post by pjmlp »

bhawks wrote: post #99
pjmlp wrote: post #51

Earlier quoted context omitted.

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 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 sell why Kotlin.

Fragmentation, what a joke, the fragmentation got so bad in Android, that JetPack libraries, previously Android X, exist to work around the fragmentation and lack of OEM updates.

Gosling said it better, regarding Google's "good" intentions

https://www.youtube.com/watch?v=ZYw3X4RZv6Y&feature=youtu.be...

Re: Scala 3 slowed us down?

#133

Post by geokon »

refulgentis wrote: post #129
geokon wrote: post #127

Earlier quoted context omitted.

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…

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

Re: Scala 3 slowed us down?

#134

Post by theLiminator »

thefaux wrote: post #73
hunterpayne wrote: post #64

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'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 really a shame because in many ways I do think it is a better language than anything else that is widely used in industry but it seems the world has moved on.

I'm really hoping that https://flix.dev/ will learn from the mistakes of Scala. I t looks like a pretty nice spiritual successor to Scala.

Re: Scala 3 slowed us down?

#135

Post by vletal »

hunterpayne wrote: post #64

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 was so stoked, when it was released. Loved the approach they take. So, I can say, there was at least one person who asked for it.

With the hindsight, it is not a great mainstream language and the new opinionated language is too hard for junior Joe developers.

Anyway, you clearly have not read the article, as it is about bug in a transitive dependency, not an actual Scala 3 issue.

p.s.: Scala compiler is one of the most aggressively tested pieces of software in the JVM ecosystem.

Re: Scala 3 slowed us down?

#136

Post by bvrmn »

mystifyingpoi wrote: post #40
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).

> My understanding is that Java added a lot of functional programming This is true, but needs more context. Java 8 added Stream API, which (at this time) was a fantastic breath of fresh air. However, the whole thing felt overengineered at many points, aka - it made complex things possible (collector chaining is admittedly cool, parallel streams are useful for quick-and-dirty data processing), but simple everyday thin…

It bothers me that majority of languages ignores a nice python approach. `', '.join(any_str_iterable)`. Instead of supporting join for myriads of containers there is a single str method.

Re: Scala 3 slowed us down?

#137

Post by aquariusDue »

refulgentis wrote: post #129
geokon wrote: post #127

Earlier quoted context omitted.

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…

RE: Flutter

Yeah, I'm currently developing a Flutter app and also using flutter_rust_bridge to separate the business logic and I can hardly believe how enjoyable it is.

Other than the initial project setup which is a me and Nix flakes problem it all comes together pretty smoothly.

Re: Scala 3 slowed us down?

#138

Post by js8 »

voidfunc wrote: post #75
hunterpayne wrote: post #64

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…

Scala has deep roots in the Ivory Towers of Academia, its not shocking they think they know better than their users what the problems with the language are and didn't do any kind of real product management to figure out the actual problems before embarking on a rebuild.

It wouldn't be a problem, but the issue is a one of expectations.

Was Scala supposed to be a research language (focus on novel features) or an industrial language (focus on stability and maintainability)? I think Oderski wanted the first but many people wished for the second.

Re: Scala 3 slowed us down?

#139

Post by jll29 »

dionian wrote: post #122
monksy wrote: post #119

Earlier quoted context omitted.

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.

A language should not be complicated. (Wish Odersky, capable as he is, kept working on his much-verlooked TurboModula).

Simple:

- Scheme

- C

- Pascal

- Go

- Lua

Complicated

- PL/1

- C++ 2024

- Scala 3

Still borderline or beyond?

- Rust

- Java (>850 pp. lang. specification...)

Re: Scala 3 slowed us down?

#140

Post by pron »

hunterpayne wrote: post #68
pjmlp wrote: 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…

First, the number of projects still on 8 is low, and almost all of them are legacy projects with little to no evolution.

Second, modules' encapsulation is not what caused the migration difficulties from 8 to 9+, evidenced by the fact that it wasn't even turned on until JDK 16: https://openjdk.org/jeps/396. From JDK 9 through 15, all access remained the same as it was in 8. The reason a lot of stuff broke was the JDK 9 was the largest release ever, and it began changing internals after some years of stagnation. Many JDK 8 libraries had used those internals and had become dependent on them not changing - though there was no promise of backward compatibility - because there was no encapsulation.

Finally, the market clearly wants things like projects Loom and Panama and Valhalla, things that wouldn't have been possible without encapsulation (at least not without breaking programs that depend on internals over and over). It's like people complaining about the noise and dust that installing cable ducts causes and say, "nobody asked for this, we just asked for fast internet!"

Post reply on HN