4 ms·

I actually think Scala is in the best position it's ever been. There is a commitment to making the language simpler, easier and cleaner. On the backend, ZIO (

I actually think Scala is in the best position it's ever been. There is a commitment to making the language simpler, easier and cleaner. On the backend, ZIO (https://zio.dev https://zio.dev) is the best concurrency library on any platform. On the frontend you have really interesting Scala.js projects like Laminar (https://laminar.dev https://laminar.dev). The biggest issue really is the tooling. SBT is simply awful.

brightball 4y ago
On any platform?
- threeseed 4y ago
  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.
  - bdangubic 4y ago
    This is exactly the kind of problem that 0.000324% of us are having while being productive in Java/Rust/Go/C++ ... ;)
    - geodel 4y ago
      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.
    - misja111 4y ago
      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.
    - valenterry 4y ago
      It definitely is. You can even see it by looking at how the languages market themselves, claiming to make concurrency easy etc.
  - Joeri 4y ago
    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/race https://www.learnrxjs.io/learn-rxjs/operators/combination/ra...
    - vyshane 4y ago
      No backpressure in RxJS.
  - cube2222 4y ago
    This is actually trivial in Go as well, with a context (cancellation) and a WaitGroup or channel (waiting for the first one to finish).
    - valenterry 4y ago
      Go fails at the error-handling and resource-safety part. The compiler does not cover you properly.
      - cube2222 4y ago
        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.
        valenterry 4y ago
        > 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!
        cube2222 4y ago
        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
        valenterry 4y ago
        Fair enough, that sentence is a bit over the top. I personally agree, but it is subjective and sounds like a fact.
  - theCodeStig 4y ago
    Cats effect can do the same
  - brightball 4y ago
    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.
    - valenterry 4y ago
      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!
      - Taikonerd 4y ago
        A statically-typed language running on BEAM? Sounds like Gleam: https://gleam.run/ https://gleam.run/ (Disclaimer: I haven't used Gleam, I just know it exists.)
        valenterry 4y ago
        I think as a Scala developer, my expectations/demands can't be matched by Gleam unfortunately. But if it could, then yes!
  - jodersky 4y ago
    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).
    - pshirshov 4y ago
      > 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.
  - marcosdumay 4y ago
    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.
    - seer-zig 4y ago
      This will make it trivial in Java: https://openjdk.org/jeps/428 https://openjdk.org/jeps/428
sixminuteabs 4y ago
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.
- AaronM 4y ago
  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.
  - esarbe 4y ago
    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/ 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.
JackFr 4y ago
> 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."
- the_af 4y ago
  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).
  - therealdrag0 4y ago
    What kills me is IJ underlines all my sbt files in red.
    - the_af 4y ago
      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.
- jodersky 4y ago
  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.
esarbe 4y ago
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.
weego 4y ago
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.
- wbillingsley 4y ago
  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.
- kaba0 4y ago
  > 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.
- dropofwill 4y ago
  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.
thefaux 4y ago
> 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=HHwWgsCjjYDbmZ8fAAAA 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.

brightball 4y ago

On any platform?

threeseed 4y ago
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.
- bdangubic 4y ago
  This is exactly the kind of problem that 0.000324% of us are having while being productive in Java/Rust/Go/C++ ... ;)
  - geodel 4y ago
    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.
  - misja111 4y ago
    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.
  - valenterry 4y ago
    It definitely is. You can even see it by looking at how the languages market themselves, claiming to make concurrency easy etc.
- Joeri 4y ago
  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/race https://www.learnrxjs.io/learn-rxjs/operators/combination/ra...
  - vyshane 4y ago
    No backpressure in RxJS.
- cube2222 4y ago
  This is actually trivial in Go as well, with a context (cancellation) and a WaitGroup or channel (waiting for the first one to finish).
  - valenterry 4y ago
    Go fails at the error-handling and resource-safety part. The compiler does not cover you properly.
    - cube2222 4y ago
      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.
      - valenterry 4y ago
        > 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!
        cube2222 4y ago
        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
        valenterry 4y ago
        Fair enough, that sentence is a bit over the top. I personally agree, but it is subjective and sounds like a fact.
- theCodeStig 4y ago
  Cats effect can do the same
- brightball 4y ago
  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.
  - valenterry 4y ago
    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!
    - Taikonerd 4y ago
      A statically-typed language running on BEAM? Sounds like Gleam: https://gleam.run/ https://gleam.run/ (Disclaimer: I haven't used Gleam, I just know it exists.)
      - valenterry 4y ago
        I think as a Scala developer, my expectations/demands can't be matched by Gleam unfortunately. But if it could, then yes!
- jodersky 4y ago
  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).
  - pshirshov 4y ago
    > 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.
- marcosdumay 4y ago
  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.
  - seer-zig 4y ago
    This will make it trivial in Java: https://openjdk.org/jeps/428 https://openjdk.org/jeps/428

sixminuteabs 4y ago

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.

AaronM 4y ago
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.
- esarbe 4y ago
  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/ 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.

JackFr 4y ago

> 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."

the_af 4y ago
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).
- therealdrag0 4y ago
  What kills me is IJ underlines all my sbt files in red.
  - the_af 4y ago
    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.
jodersky 4y ago
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.

esarbe 4y ago

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.

weego 4y ago

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.

wbillingsley 4y ago
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.
kaba0 4y ago
> 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.
dropofwill 4y ago
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.

thefaux 4y ago

> 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=HHwWgsCjjYDbmZ8fAAAA 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.