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…
Scala 3 Migration: Report from the field
91–100 of 124 posts
Re: Scala 3 Migration: Report from the field
#92Scala used to be my hobby / enthusiast language. Introduced to it through a college course, and used a bit through school. Later, I would use it for Advent of Code, tinkered with a Scala Play webapp, and dream about using it professionally. Rust has almost completely filled that void now. Rust is native, I'm not waiting on the 1.0 release of `scala-native` anymore. The community around Rust seems to be enthusiastic a…
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…
So my rule of thumb is: Large enterprise monolithic projects - Scala. Microservises, serverless functions, systems where resources have hard constraints, cli apps - Rust.
Both are great languages.
Re: Scala 3 Migration: Report from the field
#93Scala used to be my hobby / enthusiast language. Introduced to it through a college course, and used a bit through school. Later, I would use it for Advent of Code, tinkered with a Scala Play webapp, and dream about using it professionally. Rust has almost completely filled that void now. Rust is native, I'm not waiting on the 1.0 release of `scala-native` anymore. The community around Rust seems to be enthusiastic a…
I thought I was reading my own story! same here... 10 years of Scala 2.xx till it was Scala 3 that caused my withdrawal, and that infinite waiting for scala-native... killed my interest. Now, and for the foreseeable future, it is Rust. I had a look at Mojo, love it, but I am no longer interested in OO (used OO for 20+ years and I figured I am no more interested). EDIT: even John DeGoes (the ZIO guy) left Scala for si…
Re: Scala 3 Migration: Report from the field
#94Earlier 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.
Could they have made Play an alternative to Rails for one-off throwaway websites? Maybe, but the thing that would have needed to be different wouldn't be pushing Play itself, but rather lighter tooling and making it easier to get from zero to pages being served. Honestly I struggle to see how they could've done it without making the compiler and build tool much faster, and either making the IDEs much more efficient (difficult) or making the language easier without an IDE (difficult, and would risk splitting efforts). And even then, you wouldn't really show the compelling advantage of Scala, which is fearless refactoring in large codebases. I don't know that it could ever have been better than Rails at what Rails does, and also we already have Rails. Whereas even if it eventually "dies", Scala has already pushed Java and Kotlin to be much better than they were.
Re: Scala 3 Migration: Report from the field
#95That's how I learned to do migrations/major refactoring from my mentors back in the days. First brute force it, observe but don't panic, until you don't get any further. Then start over and do it properly.
Re: Scala 3 Migration: Report from the field
#96Earlier quoted context omitted.
That is correct. Play's hype did more harm than good. I work at a company that has many legacy projects in Scala because we were/are heavily invested in Spark, and Play is a disaster overall.
What is so bad specifically about play?
In the past, however, upgrading to new versions, was annoying, because of pretty big changes in the API. (Don't know if this is what GP had in mind though.)
And even worse (I suppose) for people who were using the different ORMs which have come and gone, instead of plain SQL.
Akka has been annoying too: Adding WebSocket to my project, using Akka, was extremely much more complicated than doing the same in Nodejs (at least looking at the Nodejs docs I've seen).
Today, to me, Play is feature complete and all I want is maintenance updates (and performance optimizations but not so important). And yes, that's how things look right now: Some bigger companies pay an open-source maintainer, so Play gets regular maintenance updates, but not any annoying major API changes (or so I hope), nice.
Play has become boring in a good way? :- ) (Thinking about some "Use boring tech" HN posts.)
Re: Scala 3 Migration: Report from the field
#97I only allow myself to use Scala these days if follow some rules: no sbt (just Maven) and no Scala libraries (just Java ones). I never used fancy stuff like Cats anyways. Curious to hear who actually does, and for what.
I use ZIO ( https://zio.dev ) and nothing really like it exists on any platform. You can wrap any computation in a single ZIO object e.g. normal, callback, future, promise etc. Which you can then chain together in different ways e.g. run them in parallel, sequentially, race them against each other and kill the loser, schedule in elaborate ways, run with a timeout and then run another if it’s exceeded etc. And it will…
Re: Scala 3 Migration: Report from the field
#98Earlier quoted context omitted.
That is correct. Play's hype did more harm than good. I work at a company that has many legacy projects in Scala because we were/are heavily invested in Spark, and Play is a disaster overall.
What is so bad specifically about play?
- 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 was in state of semi-abandonment for several years before Lightbend gave the project to the community. Even though there are/were big companies deploying Play apps at scale, for instance Apple.
- The introduction of Guice (in 2.4 afaik) was a terrible mistake, completely unnecessary and at odds with the Scala philosophy. Sure you can not use it, or use something else (like macwire) but defaults matter.
- Play-JSON depends on Jackson which is annoying in the JVM world, causing binary compatibility issues when you have diamond dependencies.
- Standard library Futures are not so nice when you've experienced anything else (Scalaz Task, Cats IO, ZIO, even Twitter Future...)
- Code generation from routes files is an odd choice when Scala has always been expressive and DSL friendly.
- Swagger/OpenAPI integration is brittle.
I've personally used Tapir since 2019 and couldn't be happier. All Play apps still running at my company are being abandoned or replaced by Spring/Java projects.
Re: Scala 3 Migration: Report from the field
#99Earlier quoted context omitted.
What is so bad specifically about play?
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…
Have you tried Vertx with Scala? (Or Spring + Scala, or sth else?)
> The introduction of Guice
Personally I've wired everything statically at compile time, zero dependency injections. (Felt as if what I did went a tiny bit against the framework, but works fine.)
Re: Scala 3 Migration: Report from the field
#100But that is where good parts end.
From the POV of real world boots-on-theground software challenges and developers it is a poorly designed, overengineered and overrated piece of complexity.
Complexity disconnected from reality of software engineering as a tool to serve business needs.
I can explain why this happens but I don’t want to get downvotes. People hate hearing bitter truth:)