Live data from Hacker News

The Road to Scala 3

scala-lang.org

141–150 of 196 posts

Re: The Road to Scala 3

#141

Earlier quoted context omitted.

What about kotlin?

Yes, Kotlin seems to me like the future of Java.

I would have said that a year ago but I'm not so sure now. I actually think Kotlin is at risk of suffering the same fate as Ruby and perhaps Swift: so stereotyped into being viewed as a single domain language to the extent it gets ignored by the mainstream. To some extent Groovy suffers it as well - as soon as you say it people think either Jenkins or Gradle and recall their last nightmare debugging session trying to reason about its crazy dynamic behavior, all the while blind to the fact that it has huge general applicability to all kinds of application development. I even think this is starting to hurt Python where now everyone thinks it is for data science.

Re: The Road to Scala 3

#142
post #97

The problem of Scala is that it is outclassed by Rust and Kotlin at its two niches of, respectively, "best designed programming language" and "better Java on the JVM". Scala can't beat Rust because you can't have safe concurrency (and also single-threaded mutation control) without linear types, and you can't have linear types on the JVM; furthermore, a GC and VM-based language is inferior to a native non-GC one provi…

> you can't have linear types on the JVM

Why can't you have linear types on the JVM?

Re: The Road to Scala 3

#143

Earlier quoted context omitted.

What about kotlin?

Yes, Kotlin seems to me like the future of Java.

I'm not so sure. I don't see it being used on the server side a whole lot, it seems to be more or less synonymous with Android dev -- and Dart/Flutter is taking big chunks of that space now and growing rapidly.

Re: The Road to Scala 3

#144
post #104

To all those saying Scala is dying: Personally I am making top money on Scala gigs, and I don't see that changing anytime soon. The people I meet on these gigs share my opinion. Most people wouldn't take a Java job even if it paid more, same for Go or Node ( both of which I have used in production in the last month, and wouldn't take over Scala, with the exception of serverless) Teams in Media, Government and Finance…

>With all that said, the church of FP and the hascalator community is a problem for Scala. Overly dogmatic & academic functional programming styles don't have a place in production systems.

Isn't Scala minus the problems you mentioned just Kotlin?

Re: The Road to Scala 3

#145
post #133

Earlier quoted context omitted.

Yes, Kotlin seems to me like the future of Java.

Kotlin is not the future of anything. They got the Android boost and still, two years later, all they have to offer is a molasses-slow improvement pace and a shitty dev experience in their signature IDE (which also happens to be made by the same company). Last time I tried to create a Kotlin project in IDEA, it couldn't provide type information on hover. The Kotlin dialect of Gradle was barely supported enough to be…

[deleted]

Re: The Road to Scala 3

#146
post #97

The problem of Scala is that it is outclassed by Rust and Kotlin at its two niches of, respectively, "best designed programming language" and "better Java on the JVM". Scala can't beat Rust because you can't have safe concurrency (and also single-threaded mutation control) without linear types, and you can't have linear types on the JVM; furthermore, a GC and VM-based language is inferior to a native non-GC one provi…

> you can't have linear types on the JVM Why can't you have linear types on the JVM?

I don't get it either - its a compiler construct, not a runtime check (remember Rust's "zero overhead" motto).

Re: The Road to Scala 3

#147
post #133

Earlier quoted context omitted.

Yes, Kotlin seems to me like the future of Java.

Kotlin is not the future of anything. They got the Android boost and still, two years later, all they have to offer is a molasses-slow improvement pace and a shitty dev experience in their signature IDE (which also happens to be made by the same company). Last time I tried to create a Kotlin project in IDEA, it couldn't provide type information on hover. The Kotlin dialect of Gradle was barely supported enough to be…

We're writing new apps in Kotlin instead of Java, works fine for us. shrug Vert.x , Ktor apps, Kafka streaming apps. IDEA handles it absolutely fine these days, I suspect you last tried it sometime ago.

Can't comment on the Gradle stuff though, I vastly prefer Maven.

Re: The Road to Scala 3

#148
post #44

Earlier quoted context omitted.

That’s precisely the issue imo: it’s a language carefully designed to meet Google’s requirements. The whole “we don’t need generics” fiasco was hilarious, though.

Its actually not designed to meet Googles requirements, that just something people who don't know Go say. They have a survey they put out every year and take feedback from customers on issues that arise. They try and fix those issues with as little code as possible, because code and features have a cost.

Well, Go magically fits right between C++ and Java, which were both Google’s main backend languages AFAIK.

I wonder if generics and proper dependency management were on this survey you’re talking about...

Re: The Road to Scala 3

#149
post #3

I really love Scala, but I worry about its future given Google putting its weight behind Kotlin, and the two offering a lot of the same features and philosophy. Does anyone know if the Scala maintainers have addressed this directly?

* If you use even half of Scala's functional capabilities, Kotlin isn't really an alternative. * What Google does with Kotlin and Android is completely irrelevant to the Scala ecosystem and its users. * On the back-end side, Kotlin doesn't intersect that much with Scala. I haven't met anyone migrating from say, Play to Spring thanks to Kotlin's support. * In the big data world, if you rely heavily on Spark, Scala is…

> I haven't met anyone migrating from say, Play to Spring thanks to Kotlin's support.

Hi, now you have :) Well, Vert.x and Ktor, not so much Spring Boot.

It's mainly because effective and readable Scala requires a lot more discipline and experience than effective Kotlin for a Java developer. If we'd started solely with experienced Scala devs then I suspect we wouldn't have had an issue.

There is, also, the problem of footguns - we've inherited a large Scala codebase from a sister company, and they, unfortunately, let the devs run free. So there's large amounts of hard to debug, hard to read, Scala magic going on. Implicit classes, inherited three levels deep! Macros! Why? Because they could!

Re: The Road to Scala 3

#150
post #148

Earlier quoted context omitted.

Its actually not designed to meet Googles requirements, that just something people who don't know Go say. They have a survey they put out every year and take feedback from customers on issues that arise. They try and fix those issues with as little code as possible, because code and features have a cost.

Well, Go magically fits right between C++ and Java, which were both Google’s main backend languages AFAIK. I wonder if generics and proper dependency management were on this survey you’re talking about...

Caught me, Go was developed for Google only because it fits between C++ and Java meaning its worthless to everyone else ;)

Generics and dep management were on the top of that survey last year. They are the primary focus of the Go team right now. Russ wrote Go Modules for dep managment, the implementation specifically addresses pain points from the community. Generics are a hot topic and looks like we're close to a finalized design.

Post reply on HN