Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scala 3 Migration: Report from the field

blog.pierre-ricadat.com

Post reply on HN
Print view View original

81–90 of 124 posts

Re: Scala 3 Migration: Report from the field

#81

Post by acjohnson55 »

joshlemer wrote: post #69
lmm wrote: post #55

Earlier quoted context omitted.

> I feel like the biggest misstep that the Scala ecosystem and Typesafe/Lightbend did was that they didn't invest more in Play Framework. 10 or 12 years ago, Play had a lot of energy and momentum, and it's a kind of thing that has broad enterprise/start up appeal. But focus was always more on Akka and what seemed like really niche architecture astronaut stuff like Actors and Actor System Clusters and Event Sourcing e…

I disagree, productivity and ergonomics drives plenty of popular tools - React, Laravel, Rails, React Native, etc.

Yeah, but I don't think Play (which I enjoyed) was ever going to top those, unless it had a fundamentally new idea to bring.

Re: Scala 3 Migration: Report from the field

#82

Post by dtech »

senorrib wrote: post #67
jeremyjh wrote: post #23

Earlier quoted context omitted.

It still seems bizarre to me that the Java ecosystem relies upon code-sharing through precompiled binary packages. Compared to for example Rust or Elixir where you only download source and build it locally so that everything is built with the same compiler and environment. This makes it absolutely trivial to debug your dependencies and even fork them when necessary. Most Java programmers wouldn't ever dream of doing…

That's actually a major drawback on Rust to be adopted in enterprise settings. Any GPL library statically compiled would force the entire codebase to be licensed under GPL as well.

Whether it's source or a binary doesn't matter. You aren't allowed to use a compiled GPL library in non free code. LGPL was specifically made for that case.

Re: Scala 3 Migration: Report from the field

#83

Post by threeseed »

estebank wrote: post #46
threeseed wrote: post #42

Earlier quoted context omitted.

I have been writing Scala and Rust everyday for the last few years. I actually don’t see the two overlapping all that much. Rust is a terrible backend language compared to Scala/JVM. When you are dealing with real world concurrency i.e. error/thread management Rust’s memory management model becomes unusably complex very quickly. And the entire ecosystem lacks maturity i.e. the majority of libraries I use are not at v…

> And the entire ecosystem lacks maturity i.e. the majority of libraries I use are not at version 1. I'm marginally bothered by the reluctance to bite the bullet and accept a 2.0 will happen in the future, but version numbers do not make for mature libraries. There are plenty of foundational libraries written in C keeping Linux desktops running that are permanent 0.x versions. > Whereas from Scala you can just use an…

> but version numbers do not make for mature libraries

No but they do symbolise a belief amongst the library maintainers that it isn't stable. And so I end up spending an inordinate amount of time refactoring for the latest version.

> and the same thing will happen to Rust in 10 years

From what I've seen in the last year it won't. Most of the libraries I use have stopped being maintained. The reason Java does so well here is because in enterprise space supporting something for decades is common.

Re: Scala 3 Migration: Report from the field

#84

Post by threeseed »

packetlost wrote: post #43
threeseed wrote: post #42

Earlier quoted context omitted.

I have been writing Scala and Rust everyday for the last few years. I actually don’t see the two overlapping all that much. Rust is a terrible backend language compared to Scala/JVM. When you are dealing with real world concurrency i.e. error/thread management Rust’s memory management model becomes unusably complex very quickly. And the entire ecosystem lacks maturity i.e. the majority of libraries I use are not at v…

> When you are dealing with real world concurrency i.e. error/thread management Rust’s memory management model becomes unusably complex very quickly I've seen this several times, but having built several highly concurrent applications in Rust, I just don't agree. Building a concurrent Rust application the wrong way is certainly complex, but if you know how Rust's strong opinions on how to structure an application wor…

Compare this to Scala and it just doesn't matter about right/wrong way.

It all just works without issue. Maybe you use a few more CPU cycles garbage collecting but these days it's unnoticeable.

Re: Scala 3 Migration: Report from the field

#85

Post by dingi »

jeremyjh wrote: post #23
theLiminator wrote: post #18

Back when I used to use Scala, the biggest PITA was how every minor version bump you'd run into binary version incompatibilities that you'd only run into at runtime. Has that situation changed? I've always felt that Scala the language was always pretty nice, but Scala the ecosystem/tooling was moderately painful to work with. It was getting better over time, but they lost all the momentum they had.

It still seems bizarre to me that the Java ecosystem relies upon code-sharing through precompiled binary packages. Compared to for example Rust or Elixir where you only download source and build it locally so that everything is built with the same compiler and environment. This makes it absolutely trivial to debug your dependencies and even fork them when necessary. Most Java programmers wouldn't ever dream of doing…

Isn't this due to inherent limitations of native binaries? Java has very few native dependencies, so its trivial to do binary dependencies. Besides, most packages in maven central have their sources in there as well. You can easily download the source package and let the debugger use that.

Re: Scala 3 Migration: Report from the field

#86

Post by dtech »

spockz wrote: post #78

As I mentioned deeper in the thread, https://news.ycombinator.com/item?id=42969519 , Java seems to have caught up with Kotlin and Scala language wise. (With Scala3 having the most extensive type system.) The ecosystem also seems to have petered out. Akka, spark, and flink used to be reasons to do scala. But they have decent java interfaces now. I’ve had too much struggles convincing colleagues that actually more info…

I think you're over-selling the parity.

Value based classes aren't definable by your own code yet. Records are severely underbaked, unless I missed it there isn't even a copy method yet, and those are essential for working with immutable data.

Then there's still a lot of features that Java is sorely lacking like extension methods, named parameters and delegation, even though they have proven themselves in multiple other programming languages by now.

Re: Scala 3 Migration: Report from the field

#87

Post by imtringued »

jeremyjh wrote: post #73
senorrib wrote: post #67

Earlier quoted context omitted.

That's actually a major drawback on Rust to be adopted in enterprise settings. Any GPL library statically compiled would force the entire codebase to be licensed under GPL as well.

GPL can contaminate you when shared as a dynamic library under certain circumstances. But that doesn't matter, since there are few mainstream libraries in these communities licensed as GPL. Nearly all of it is MIT or Apache.

There is no such thing as contamination.

GPL code doesn't change the license of your code. It only prevents you from using GPL code from your code.

Re: Scala 3 Migration: Report from the field

#88

Post by imtringued »

spockz wrote: post #76
lyall wrote: post #71

Earlier quoted context omitted.

Kotlin is gaining steam in the Java world. We're moving to make it our default server-side language at my company instead of Java. Given its great Java interop, you can basically think of it as a modern, more functional Java that doesn't have multiple decades of baggage associated with it. I highly recommend considering it in any place you'd consider Java.

Now that Java has caught up a lot with records, value classes, project loom (virtual/green threads), pattern matching. What is left? Scala has the better type system with union types and effects (a more generic way of having “throws”.) Kotlin has a nicer way of dealing with optional values with the ? operator. What’s left is the syntax. Or am I missing something? These alone do not seem to justify moving an organisat…

Java still sucks.

Where are Java properties, so people can stop writing the silly getter setter nonsense?

Where are default parameters and named parameter calls?

Where is the null friendly field access operator ?. ?

Where is the convenient list and hashmap literal syntax?

Why is the stream API so verbose? Why not offer a third generation collections API?

Where are the sane ORMs?

Now here is some JVM hate:

How do I make sure that my application starts up quickly and isn't slow the first time you're accessing a web page after a restart?

How do I make sure that I don't need a 2GB RAM server for a simple web app? Cloud providers are stingy with RAM, so this adds up, even though RAM costs are an insignificant part of overall server costs.

How do I write a CLI app with the JVM? You don't.

So yeah, Java is in this uncanny valley where it is either obsoleted language wise by JVM languages from 2009 and runtime obsoleted by languages like Rust, where you trade off a bit of convenience, which Java by the way does not have either, for a bit of performance.

Re: Scala 3 Migration: Report from the field

#89

Post by rat87 »

virtualwhys wrote: post #29

Migrated a Scala 2.8(!) era codebase to Scala 3. As OP explains, macros and abstract type projections tend to be the biggest pain points in complex applications; otherwise, with Scala Rewrite tool it's pretty straightforward. I think it's more inertia than anything else that more Scala 2 companies don't migrate. Unpopular opinion, but setting a Scala 2 sunset time would spur companies into action :) As it stands Akka…

As someone who has done a couple of python 2 to python 3 migrations I'm still surprised that there isn't someone big selling support/security patches for python2. There must be a lot of giant corporate python2 code bases that were a lot harder to port and where it was much less acceptable to find random 2to3 bug I'm production then the QA and build system codebases I ported

Re: Scala 3 Migration: Report from the field

#90

Post by danielciocirlan »

This is a good report.

Scala 3 is really what Scala was supposed to be. The language is just about perfect, and the most important and popular libraries and tools (Cats/Cats Effect, ZIO, Play Framework, Akka/Apache Pekko) are all supporting the new version for years already.

It's really a shame that IDE support has yet to catch up and the dev experience is frustrating at times, but I'm using Scala 3 for everything I can.

Post reply on HN