101–110 of 124 posts
Earlier quoted context omitted.
But did it provide a gain in power and soundness? There issues with the 2.x system.
It did, which makes it all the more frustrating that you can't adopt it separately from the syntax and tooling changes.
Scala 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…
Earlier quoted context omitted.
> 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.
I've mostly come to the conclusion that a mediocre engineer can write performant enough Java/Scala/Clojure/Kotlin/etc. Usually even more performant than what an inexperienced/mediocre C/C++/Rust engineer could write and have an easier time doing it. However trying to ilk out the last bit of performance in a JVM language can be very challenging.
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…
Yes totally lovely :- ) And the best std lib? (On shared 1st place I'd guess, Rust looks nice too)
I just miss better debugging of async code, so I could see the execution context in other threads earlier in the "async call stack".
Earlier 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…
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 for several years
Yes, this is my main complaint. I remember on the front page for like 5 years after TypeSafe Activator had been totally removed from the internet, the Play website was still showing Activator commands. To this day, the Play site still hasn't removed their line about how they support CoffeeScript and Less.
> Guice (in 2.4 afaik) was a terrible mistake, completely unnecessary and at odds with the Scala philosophy > Play-JSON depends on Jackson > Standard library Futures are not so nice
Well, it turned out that the Scala Philosophy wasn't the be-all and end-all anyways, and was always changing (at some point DSL's were in, then they were out. The way people encode TypeClasses changed over the years, selectDynamic/applyDynamic were in and then they were out, symbols were everywhere and then deprecated, implicit conversions were in and then "best practice" switched to Converters) and there was always at least 2 camps who had very different philosophies. Guice is probably the most popular DI tool in the JVM world so seems to make sense to use it.
The Jackson dependency and Scala Future's shortcomings might be annoying to many, but I don't think they really hindered adoption. Even in your case, what happened? At your company they're ripping out Play and replacing it with Spring, which uses DI very similar to Guice, probably depending on Jackson, and using java Futures (if they're doing async at all).
Earlier quoted context omitted.
Ok so boring things won. (Well I'm writing Java and Python every day outside Data context this is not dissing.)
Just curious what do you do? I'm thinking about moving away from data, maybe into something that is a little bit lower-level.
Earlier quoted context omitted.
Just curious what do you do? I'm thinking about moving away from data, maybe into something that is a little bit lower-level.
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.
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.
Earlier quoted context omitted.
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…
I would argue that John left due to political reasons mostly, and honestly, for good.
Earlier quoted context omitted.
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…
Jon DeGoes still works on the ZIO ecosystem along with his Rust projects.
Earlier quoted context omitted.
I disagree, productivity and ergonomics drives plenty of popular tools - React, Laravel, Rails, React Native, etc.
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 think all of these frameworks - Laravel, Rails, Django, Next.js, Spring - require deep familiarity to get the best out of them.
> Honestly I struggle to see how they could've done it without making the compiler and build tool much faster
Well, Lightbend literally was the owner of Play, SBT, and Scalac. They were in a perfect position to make the build tool and compiler much faster. Or even if SBT can't be made much faster, ditch it and make integration with gradle and/or maven really great.