I agree with a lot of the criticism in the article, but also agree with this idea that Scala is in the best position it has ever been. Core Scala is migrating to Scala3 (will take a few years) and the scala team had the courage to take on the rough edges. The Typelevel community (FP side) has a whole ecosystem which is maturing into something really nice. Akka pulled the ripcord on licensing so everyone knows where they stand.

Across the board the language and environment is stabilizing. Most of the (correct) criticisms expressed in this article are either 1. An expression that dependency management remains really hard as dependencies and ecosystems grow 2. An artifact of the fact that early scala projects relied heavily on borrowing from java to bootstrap and it caused a snarl of dependencies. On the latter, I see a decline in snarl overtime.

It is fair to say that Rust and Go have a really awesome toolchain experience and are setting the standard (though I wonder if the problems of being "old" and having boatloads of libraries haven't yet set in). SBT nominally has a similar experience but it's definitely slower and somehow less intuitive. Hoping to see more work in this area and I think Mill + SBT "competing" + BSP and bloop opening the door for more innovation will allow for quick progress.

For me the big win with Go, is its so easy to get from new project -> first working test.

I think there installation of the required tooling is very easy and just works, unlike other languages where you can spend a lot of time just getting all of that initial stuff setup. Also upgrading the tool chain is very easy as well.

That's funny, because this is what I really like about Scala; how quick and easy it is to get a project started.

> sbt new scala/scala3.g8

will just create an empty project. If you don't even want to bother with a project, use use scala-cli or ammonite (http://ammonite.io/) to just start banging out code.

Even the upgrading of a project from Scala2 to Scala3 is a breeze, thanks to very good backwards compatibility of new library releases.

> The biggest issue really is the tooling. SBT is simply awful.

It's like they sat down and said "Maven has a bunch of problems. Let's fix none of them and introduce a few new ones."

Agreed. Maybe the situation has changed now, but it also didn't help that sbt's DSL is so inconsistent.

Back 2 years ago, when I still used Scala, sbt had two ways to write build files, the "old" and "new" ways, both non-trivial except for the simplest cases, and when you were troubleshooting/debugging problems with your build, all the answers you found googling were for the other style (facepalm).

What kills me is IJ underlines all my sbt files in red.

Ouch.

I remember back when Scala was still on version 1, the official/recommended IDE was Scala IDE, based on Eclipse. Eclipse was already a mess at that time, and people were abandoning it in droves even for Java work, but (bizarrely) Scala IDE was endorsed by Odersky.

Get this: refactoring -- critical for a language like Scala -- was totally broken on Scala IDE. Completely, unusably broken. Like, you changed the name of a function and the IDE inserted nonsensical garbage that didn't compile or even follow syntax rules everywhere. This situation went for long enough that most sane people migrated to IntelliJ. This was back then, no idea what the situation is now or whether Scala IDE still exists.

Sometimes when creating software that solves a hard problem, the author is so thrilled by all the little conceptual breakthroughs they experience along the way that they think the users of their software will enjoy it just as much as they did, so they write the software in such a way that the users have to make all the same conceptual breakthroughs in order to use it. SBT feels like that's what happened to it. It's completely inappropriate for a build tool. 99% of the people using a build tool shouldn't have to appreciate how hard it is to write a build tool.

I recommend to have a look at Mill. It's versatile, built on simple foundations, and implements many concepts from general-purpose build tools such as Bazel (but of course it was designed for Scala). It's easy to call it from various scripts too, and doesn't require you to design your project around your build tool.

At work we've used mill to first replace sbt and then also gradle in another project, and haven't looked back. It worked out-of-the-box for our JVM projects, and we trivially wrote custom "rules" for integrating cmake-based C++ projects into the build.

granted ZIO is excellent.

Scala.js is a dead end that almost no one should be investing in. Who can honestly say that the best possible dev path for them (product/business) is to need Scala devs to do their JS frontend? Even just the economics of the pay-gap in those two skillsets is untenable. We've been through this before any number of times in JAVA, give up it's an awful choice no one will thank you for.

I'm also frustrated by how we seem to have managed to not only recreate the Spring problem with FP libraries (communities online will tell people to first go with their personal FP lib of choice as a "must have" for starting a project) but make it worse by also having competing 'factions' who argue about which one is better.

We're apparently aiming to recreate all the same mistakes JAVA started making which was the launchpad for Scala and other JVM language variants in the first place.

I sincerely hope Scala.js isn't "dead". Though I know use by academics isn't the use case you imagined, Scala.js has very much been the right choice for me publishing interactive Open Educational Resources that can include all sorts of little simulations, models, and programmable games. It's not the sort of thing I'd have time to do in any other language, but via Scala.js (and a front end framework I wrote) I can put together something that (though it's scrappy because I rarely get time to add the polish) works well enough very fast.

Disclaimer I'm already a big fan of Scala, but I agree that the tooling around scala.js is lacking and the std lib is a rather large blob to ship around, especially when compared to alternative functional languages like ocaml.

However, I've been using the above mentioned laminar for my personal frontend project needs and it really is a unique approach to the 'reactive' frontend with no vdom actually using reactive streams to track what needs to be updated. The dsl is easy to read and write and i can actually read the underlying code. For me it's scaled well too large datasets generating svgs. I think it's worth the scala.js barrier to entry.

> Who can honestly say that the best possible dev path for them (product/business) is to need Scala devs to do their JS frontend?

The ability to give a developer a feature and have them use the same language, domain model, error handling logic, business logic, serialisation codecs, tooling etc to implement it end-to-end is compelling to me.

And the number of developers who are seriously good at full-stack is far smaller than Scala ones.

> We've been through this before any number of times in JAVA, give up it's an awful choice no one will thank you for.

Is it? Google uses it quite extensively, though they mostly have their shared business code in the form of a java library that is compiled to each target platform.

Big agreement here.

Scala2 was a wonderful language, Scala 3 even more so; lots of corner cases have been removed and I even start to like the significant-whitespace-style.

ZIO and Typesafe (although I agree with the article; I could do with less drama) are simply amazing ecosystems. Libraries like Tapir and Quill seek their equal in other languages.

And even though sbt could be better it has been vastly improved in the last few years.

> The biggest issue really is the tooling. SBT is simply awful.

This is backwards. The problem is that scala is simply awful. SBT just reflects the problems with scala. First and foremost, the authors of the scala language are either incapable of writing a decent build tool or they think that SBT is good enough. They have proven over many years that they do not prioritize the experience of developers actually writing code. Slow compile times are a much bigger drain on productivity than the superficial syntactical improvements that were made for scala 3.

The specific problems with sbt, needless complexity, inscrutable dsls, bloated code paths leading to slow start up times: these are all endemic to scala itself. The standard library is so badly organized that it takes 100s of milliseconds to load a simple hello world application: https://twitter.com/li_haoyi/status/1125674970829320193?cxt=.... Mill may be better than sbt in some ways, it's definitely worse in others but at the end of the day, if you are using either, you are stuck with scala and scala is very, very unlikely to ever get significantly better than it is today.

On any platform?

It has the ability to make real-world concurrency scenarios trivial e.g.

* 3 fibers - each fetches from remote storage, local storage and in-memory cache.

* Race them, kill the two slowest and give me the result.

* Free the resources safely including if any of the connections fails for an unforeseen reason.

That's a few lines in ZIO. Pain to get working properly in Java, Rust, Go, C++ at least.

It may be the best on any platform outside of the BEAM, but there are a lot of correlating factors needed to create the ideal concurrency platform that you simply can't do without building them from the ground up.

It's why almost anything outside the BEAM can't make that claim.

True, BEAM is a platform on its own. Scala can use Akka which is also awesome, but doesn't have all the nice things builtin like BEAM.

I guess a merge of Scala as the language (because honestly, Erlang & co suck) and BEAM as the platform would be awesome!

A statically-typed language running on BEAM? Sounds like Gleam: https://gleam.run/

(Disclaimer: I haven't used Gleam, I just know it exists.)

I think as a Scala developer, my expectations/demands can't be matched by Gleam unfortunately. But if it could, then yes!

This is actually trivial in Go as well, with a context (cancellation) and a WaitGroup or channel (waiting for the first one to finish).

Go fails at the error-handling and resource-safety part. The compiler does not cover you properly.

The fact that the compiler doesn't cover that automatically doesn't mean Go fails at it, as it has very good primitives for handling them.

Error handling and deferring for resource closure work just fine.

Sure you could say "but the compiler doesn't guarantee it". But that's not much of a point if it's not a real problem in practice.

> The fact that the compiler doesn't cover that automatically doesn't mean Go fails at it

But that's exactly what OP was talking about. Maybe for you that doesn't mean Go fails here, but for (us) Scala developers it definitely feel like Go fails us. We want a language that fails at compiletime in as many cases as possible.

> But that's not much of a point if it's not a real problem in practice.

Maybe not for you. For me it is!

I agree it's fine to have different taste, as I mentioned in another reply to you.

But it's the difference between whether this statement is objective, or subjective.

> is the best concurrency library on any platform

Fair enough, that sentence is a bit over the top. I personally agree, but it is subjective and sounds like a fact.

Not a real problem in practice is just another way of saying rare. But given enough scale and enough time, rare things do happen, and they cost inordinately more programmer effort to chase down. I actually don’t mind if the compiler lets me ship very dumb bugs: those will be auto-rolled back out of production in seconds. It’s the subtle stuff that kills me.

Error handling and Go doesn’t mix well.

That's a matter of opinion. Many, me included, very much like the current, very explicit, approach.

I understand why people who like monadic constructs don't like it though.

Not quite: https://www.uber.com/blog/data-race-patterns-in-go/

I don’t know — I don’t claim that algebraic datatypes are the only proper way to handle errors, I’m okay with exceptions as well (even checked ones). But what go has is only very slightly better than C’s attempt, so I’m not sure it is that subjective.

I think the presence of multiple return values and the ability to easily use complex types for errors make a huge difference (adding wrapping messages, context, etc.).

I agree algebraic data types could improve this. I don't think monadic result types or exceptions would be an improvement.

I think maybe you've misread the intent.

I do not want to wait for the three fibers to finish. I want the whole process to stop the minute any of them have returned i.e. get me my data as quick as possible no matter its source.

I haven't.

You wait for the first result using i.e. a shared result channel, then you cancel the context.

It's still error prone in golang. Java's structured concurrency approach is much better.

This is exactly the kind of problem that 0.000324% of us are having while being productive in Java/Rust/Go/C++ ... ;)

Thats the thing with Scala, they are solving important problems. It is not spending time on useless problem like performant build system. I mean code is gonna compile eventually, if not today maybe tomorrow. But complex problem like described above will not be solved unless someone make a decent framework for it.

In the last 10 years every team/company I have been working in had to deal with at least one of these problems. Good for you if you only ever have to work with single threaded applications, but for most of us the reality of modern software development is different.

It definitely is. You can even see it by looking at how the languages market themselves, claiming to make concurrency easy etc.

I find that one of the best things about using a managed runtime such as the JVM is the ability to get stack traces when things go wrong. When debugging, it is a considerable time saver to be able to determine the causality chain that lead to a specific failure.

Unfortunately, all libraries that abstract concurrency on an application-level break the ability to get meaningful stack traces. At least all the ones I know of, including ZIO, Akka, Monix, plain Futures, etc. I know that there is tooling to counteract that (such as the abstractions used in distributed tracing), but that's again on the language level.

In my experience, for all but the most advanced applications, the debuggability advantages of using linear code outweigh the performance advantages gained by abstracting over execution contexts. Thus, I would posit that concurrency is best dealt with on the platform, not the language level, especially when starting a project.

Of course there are some situations where a library can make some concurrency task appear trivial, but as long as there is no good tooling, the time saved using beautiful abstractions tends to be paid back 5-fold when those abstraction break (which they often do as an application grows).

> Unfortunately, all libraries that abstract concurrency on an application-level break the ability to get meaningful stack traces.

This is completely false. Years ago we (7mind) added async stack traces to ZIO. Now both Cats and ZIO support them.

That sounds like RxJS race(), and given that it's JS there's often no cleanup needed (and if there is RxJS has easy ways of doing that as well).

https://www.learnrxjs.io/learn-rxjs/operators/combination/ra...

No backpressure in RxJS.

It's trivial in Haskell, a bit hard in Rust, really hard in Java, and trivial to get a non-working implementation and declare it flawless on C++. I never tried it in Go.

This will make it trivial in Java: https://openjdk.org/jeps/428

Cats effect can do the same