Earlier quoted context omitted.
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.
Scala 3 Migration: Report from the field
111–120 of 124 posts
Re: Scala 3 Migration: Report from the field
#112I currently work at a company who is primarily writing in Scala. I really like Scala but assume my next role won’t be in that. Are my two best options Rust and Java if I want to keep some of the typing, functional style, and pattern matching while also moving to a more popular language?
Re: Scala 3 Migration: Report from the field
#113Earlier quoted context omitted.
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
#114Earlier 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…
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.
I know that I can step into a source package with the debugger, but editing that source and rebuilding doesn’t compile the change into my build does it? The last step of debugging is fixing the code, its much more convenient to first try this in the same project where you encountered it.
Re: Scala 3 Migration: Report from the field
#115Earlier quoted context omitted.
It did, which makes it all the more frustrating that you can't adopt it separately from the syntax and tooling changes.
But the new syntax is optional, right? So you could upgrade and keep the old syntax? (I'm not a Scala dev, so this is just my impression.)
Re: Scala 3 Migration: Report from the field
#116Earlier 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…
Tapir looks nice, didn't know about. Can I ask, do you use it together with Netty? How fast is it for you? (if you happen to have benchmarked it) 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.)
But SoftwareMill has done extensive benchmarking to make sure the overhead from Tapir vs calling the http backend directly was insignifiant. I believe Netty is the recommended backend if you want direct style (i.e no effect systems) on Java 21+ virtual threads even though Oracle's Helidon Níma is supported too.
Re: Scala 3 Migration: Report from the field
#117Earlier quoted context omitted.
Hmm. Fair point for Rails and Laravel (whereas I think React had a killer app in terms of being able to make SPAs without going crazy) but those are tools that you can pick up for a one-off throwaway project - indeed I suspect most adopters didn't "move" to them so much as start doing projects in them and eventually stop doing projects in other things. Scala was never really competing in that space - I don't think an…
I mean, I don't find that working with IntelliJ makes it any "heavier" than other languages in terms of prototyping. I use PHP Storm for Laravel development and I never say to my self, "if only I wasn't using an IDE, maybe I could get this site put together faster". Quite the opposite, Intellij makes me super productive. I think all of these frameworks - Laravel, Rails, Django, Next.js, Spring - require deep familiar…
But the first time you tried out PHP, did you have to install the IDE first? Did you have to change your existing PHP tooling setup the first time you tried out Lavarel?
I would agree that IDEs are an improvement over not using them in most languages, but my feeling the "tooling curve" is much steeper for Scala than for something like PHP.
Re: Scala 3 Migration: Report from the field
#118Earlier quoted context omitted.
Tapir looks nice, didn't know about. Can I ask, do you use it together with Netty? How fast is it for you? (if you happen to have benchmarked it) 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.)
I use Tapir with http4s as the http server isn't my bottleneck anyway and I like Cats Effect and fs2. But SoftwareMill has done extensive benchmarking to make sure the overhead from Tapir vs calling the http backend directly was insignifiant. I believe Netty is the recommended backend if you want direct style (i.e no effect systems) on Java 21+ virtual threads even though Oracle's Helidon Níma is supported too.
Nice to know that there are good alternatives, if time it is some day to migrate away from Play.
Re: Scala 3 Migration: Report from the field
#119I left the Scala ecosystems (mostly) a year or 4 ago, right around the release of Scala 3. It's a shame that the compatibility and tooling situation doesn't seem to have improved much since then. The Scala devs always said they wanted to avoid a Python 2->3 situation, but it seemed like they didn't quite achieve that.
I don't know, if anything the Scala situation seems much worse than the Python situation. The language looks completely different and there is no easy migration path (not that Python had one, but at least the language was almost the same and you could with some effort write code that worked in both versions). We are in Scala 2.13 and while there are talks about migrating there is no actual plan. Looking at this blog…
Re: Scala 3 Migration: Report from the field
#120This 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…