Scala 3 Migration: Report from the field • Hacker News Board

Re: Scala 3 Migration: Report from the field

#121

Post by flakiness » Sat, Feb 08, 2025, 7:08 PM UTC

markus_zhang wrote: post #107

flakiness wrote: post #106

Earlier quoted context omitted.

Java (+Kotlin) for Android, Python for its automation and tooling (and obviously, data.) These aren't very low-level - For Android there is always C++ if you want to go down to metal.

Ah that's interesting. And there is ofc Swift and ObjC for Apple devices. Maybe I should get into app dev. Thanks. Do you think there is a strong market of Android/iOS native app development? As a DE I don't think my previous experience worths much -- maybe a bit more when we move to Flink which uses Java, and the might would rather hire new graduates instead of me.

I don't expect native mobile dev market to grow and was wondering how other disciplines like data is doing ;-)

Re: Scala 3 Migration: Report from the field

#122

Post by hocuspocus » Sun, Feb 09, 2025, 12:13 AM UTC

joshlemer wrote: post #105

hocuspocus wrote: post #98

Earlier quoted context omitted.

Like KajMagnus mentioned: - The churn caused by breaking changes in minor versions used to be annoyingly high. - Slick looks neat at first but caused a lot of friction when used by less experienced developers. - The fact Akka is in your dependency tree encourages people to reach for it and raw actors are usually a bad choice. Akka streams work well for websockets and SSE but it's another footgun. Additionally: - It w…

> Slick Totally agreed, Slick is definitely not a good way to access the database. It massively over complicates things and was a massive oil spill that destroyed the maintainability of many codebases. But that's not really Play, specifically, just a library that lots of people used with Play. I personally was always more a fan of https://scalikejdbc.org/ , if not just plain JDBC > It was in state of semi-abandonment…

It's true some Scala features or patterns fell out of fashion but I don't recall any time where replacing compile-time logic with annotation based runtime reflection was considered a good idea. And I don't think Guice was ever the most popular JSR-330 implementation, at least not when Play started using it. Spring had been dominating the Java world for several years by then. Funnily enough in the Android world I remember Dagger being very popular exactly around that time as people figured compile-time automatic DI is a lot saner than Guice.

Of course Spring is another can of worms entirely and I find many aspects infuriating. But things like diamond dependencies are less of an issue thanks to Maven BOMs which are common in the ecosystem.

My point is that ~10 years ago people started using Spark at my company, got curious about Scala and thought Play was compelling. Nowadays Spark (in Scala) is less ubiquitous and these teams remember that so many people got burned by Play before.

Funnily enough the peak of Scala's hype which I believe plateaued between 2014 and 2019 before dropping sharply was mainly driven by:

Spark: ground breaking in many ways but has become a huge liability to the ecosystem, holding so many libraries back. Databricks is also the main financial contributor to the Scala Center (I believe) while not giving much of a damn about the community or Scala 3 altogether. Spark is a very frustrating piece of software overall and today 95% of users are in PySpark anyway, avoiding JVM dependency hell being one reason.

Play: good idea, questionable execution, poor governance, and today mostly irrelevant to the future of Scala. Props to community maintainers who managed to secure funding and brought the framework back from the dead, saving many projects from a certain death.

Akka: also ground breaking, pretty much the only game in town if you need stateful cluster sharding, deployed at scale by top-tier companies. But also overkill for most people, and on top of that the relicensing really hurt the community and broke trust.

The boons and banes of Scala.

Re: Scala 3 Migration: Report from the field

#123

Post by markus_zhang » Sun, Feb 09, 2025, 3:00 PM UTC

flakiness wrote: post #121

markus_zhang wrote: post #107

Earlier quoted context omitted.

Ah that's interesting. And there is ofc Swift and ObjC for Apple devices. Maybe I should get into app dev. Thanks. Do you think there is a strong market of Android/iOS native app development? As a DE I don't think my previous experience worths much -- maybe a bit more when we move to Flink which uses Java, and the might would rather hire new graduates instead of me.

I don't expect native mobile dev market to grow and was wondering how other disciplines like data is doing ;-)

Data is still a big thing, but nowadays vendors successfully removed most of the management because people just want to get things done, so a lot of companies are moving to Snowflake and similar places. You basically do some click ops and hopefully shit sticks on the walls.

Interesting if you just like data, but bad if you like the tech beneath. I'd recommend moving away from DWH part of data engineering if you can, and focus on OLTP, streaming which are more technical. The culture is also different.

Re: Scala 3 Migration: Report from the field

#124

Post by phendrenad2 » Thu, Feb 13, 2025, 10:42 AM UTC

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…

Give it another look, it's actually quite nice. The issue you find with it doesn't come up that often in practice. Most of the time (99.9+%) you can find the source code to a specific JAR easily. Want to fork or modify? No problem, just edit he code, compile a new JAR, drop it somewhere. Done. It's like if the intermediate code to your favorite language's JIT were shippable (I'm actually surprised more languages don't do this).