RIP Scala, I will miss you! You showed me the joy of pattern matching, functional OO, currying, how to use `map` `flatMap` `fold`, etc. All things with continued influence! <3
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 etc, rather than getting the basics to be super ergonomic or productive.
If they had keep just making Play Framework better and better and focusing on the practical problems that every web service faces, they could be in a similar great position as Laravel is in today or any of the many Rails/Laravel consultancies.
I'd say the opposite. They pushed Play a lot. But it was never a killer app, and it never even really leveraged the strengths of Scala.
People and especially companies don't switch languages for "super ergonomic and productive". They switch because they want to do something they can't do in their current language. I'm not a fan of Akka or Actors, but it made for some incredible demos that you really couldn't do in anything else except Erlang.
And then it just…stopped. Not sure what happened there honestly.
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 version 1.
Whereas from Scala you can just use any Java library e.g. Vertx, Spring almost all of which have commercial, enterprise support and continue to be proven time and time again. It almost always just works.
Rust’s strength is in desktop apps e.g. Tauri and low-level programming.
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 work, it's downright pleasant.
Except async. Rust's async story still sucks and should be avoided as much as possible.
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 any Java library e.g. Vertx, Spring almost all of which have commercial, enterprise support and continue to be proven time and time again.
I find that "wide and storied library ecosystem" can be a double edged sword: an old library can either be battle-tested, or just old (with cruft or poor design or implementation) and you can't always tell which it is ahead of time. This is true for libraries in any language, and the same thing will happen to Rust in 10 years.
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.
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 similar reasons, now I just remembered, and prefers Rust over it... I love what they are doing with their Golem Cloud.
Scala has unfortunately fizzled out, I would say mainly because of incompetent leadership (or more precisely academia-driven) but also because the alternatives got much better since it got introduced (Java mainly). Which is a shame as it is a great language that offers elegance and great power.
Moreover, they didn't need to do it. What makes it similar to the Python 2 -> 3 situation is the lack of urgency to migrate, because nobody suffers for not migrating. That's a good thing.
We are in Scala 2.13 and while there are talks about migrating there is no actual plan. Looking at this blog post the situation seems to be more dire than I initially expected. I think we will only end up migrating when the situation becomes unsustainable (libraries stop supporting Scala 2).
Related to Python 2->3, I don't see how Scala 2->3 compares, there are clear migration guides + tools to help re-writing to switch between the new/old syntax, I have done many migrations and I have used these tools since the time when Scala 3 was launched (I admit that I reverted a migration at that time).
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.
https://docs.scala-lang.org/overviews/core/binary-compatibil...
For Scala 3, the minor version is the second number in a version, e.g., 2 in v3.2.1. The third number is the patch version. The major version is always 3.
Scala 3 guarantees both backward and forward compatibility across patch releases within a single minor release (enforcing forward binary compatibility is helpful to maintain source compatibility). In particular, this applies within an entire Long-Term-Support (LTS) series such as Scala 3.3.x.
Scala 3 also guarantees backward compatibility across minor releases in the entire 3.x series, but not forward compatibility. This means that libraries compiled with any Scala 3.x version can be used in projects compiled with any Scala 3.y version with y >= x.
In addition, Scala 3.x provides backward binary compatibility with respect to Scala 2.13.y. Libraries compiled with Scala 2.13.y can be used in projects using Scala 3.x. This policy does not apply to experimental Scala 2 features, which notably includes macros.
And given how fragile/unreproducible it is you almost never want to modify lines in a dependency. In python I'd make a wrapper or monkey patch it instead of modifying the dependency(Or if you need to actually for the library and add it to the dependenies). Unless it was blocking a one of task that I needed done right away.
First brute force it, observe but don't panic, until you don't get any further.
Then start over and do it properly.
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.
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".
I've used Scala my entire career at multiple companies, and Typelevel has been the default at all of them. I'm not even entirely sure where Scala ends and Cats begins, so it's hard to identify what's "fancy", let alone justify it. I do like IO, and monad transformers. I think neither of those are native. Flat code tends to be maintainable.
From my perspective, fully baked frameworks and ORMs are what's "fancy" (a readability nightmare). I don't know if it's a cultural thing, but Scala codebases that go hard on FP tend not to introduce these, which I appreciate. Pick your poison I guess.
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 execute this either using normal or virtual threads i.e. fibers without locks so it’s extremely fast.
But the incredible part is that it does all of this whilst seamlessly handling every type of error. Which if you’ve ever written complex concurrent code is extremely hard to get right.
Regarding no sbt, I would highly recommend to have a look at the mill build tool https://mill-build.org. I personally find it very pleasant to use as a replacement for sbt, mostly because of the following points:
- it uses regular Scala code to define a build
- it isn't DSL-heavy like sbt, which means it's A) easy to debug by simple searching, and B) anyone unfamiliar can get a vague idea of what's going on at a first glance
- it is designed around a generic task graph and isn't centered around the JVM world (disclaimer: I'm helping with development, and recently first-class support for Python and JavaScript projects was added)
I really like the simplicity of the com-lihaoyi ecosystem but I also enjoy cats/fs2 and friends on occasion.
Rust also checks your feature boxes, but staying in the JVM-verse is almost certainly the safer bet unless you end up really needing fast native binaries that aren't a chore to code.
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 organisation.
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 (previously Lightbend, previously TypeSafe) is the maintainer of Scala 2, and derives part of its revenue from Scala 2 support contracts so there's even less incentive to migrate when there's no EOL date as Python 2 (eventually) had.
The bigger issue comes from Databricks being the biggest Scala Center sponsor while holding the entire ecosystem back, for instance with their managed Spark runtime still on 2.12.
It was released May 2021.
It is a big change though.
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 information in the type is convenient. It seems like the same religion of untyped vs typed.
What is left as reasons to choose for scala or Kotlin?
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.
But 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:)
Our company is still on 2.13 and probably will be for a long time. The reality is that we need rock-solid library support across all transitive dependencies, and mature battle-tested tooling.
I like that the Scala language continues to improve, but its appeal in real-world enterprise applications took a hammering due to the backwards-incompatible changes in Scala 3, shaky tooling and ecosystem issues.
Also the elephant in the room - the Scala Center and toxicity within the Scala community.
The Scala Center Executive Director is a political sciences graduate with no commercial Scala experience, who gave this expletive-laden sexualised rant at a Scala conference:
https://x.com/jdegoes/status/1633888998434193411?s=46&t=V_LF...
When this ugly performance was called out by a member of the Scala ecosystem, it was the guy that called it out that got brigaded and cancelled, while the executive director Darja Jovanovic was defended by the community, and remains in place.
And then there's Scala Center Community Representative Zainab Ali, who led an orchestrated witch hunt against a contributor to the Scala ecosystem. She ended up in the UK High Court for her role in this, and admitted fault (defamation) and settled.
https://pretty.direct/statement
Like the executive director, the community rep remains in place at Scala Center:
"whoever it is I challenge that person to grow some fucking male anatomy and come and speak to me ... you little female anatomy plural you are just fucked up"
Fairly shocking language but also pretty devoid of context although I come to suspect it has to do with people talking behind her back regarding the second part.
The second case appears to be a fellow who was publicly libeled professionally ruined and then sued the shit out of the offender. According to him this was solely because he had dumped community rep. In the settlement they admitted that they had circulated the letter claiming he was a serial sexual harasser based on no evidence but unverified claims. Settled for a rather paltry sum of £5000.
So community rep and contributor split for whatever reasons and then she shit talks him spreading possibly true likely untrue claims that he's a particular type of jerk which she likely can't back up with anything like evidence other than her own now terminated relationship.
If they didn't fire her they probably believe that she was in the right but settled.
No part of this probably belonged as part of professional life and should have stayed between them. I don't believe enough evidence exists for people who don't know either party to declare anyone a villain and if I had any professional involvement with either I would simply pretend none of that existed and move on.
If I was merely using the code I would definitely ignore it.
Same with Rust, Go, and any other language.
