Scala 3.0.0-M1 (opens in new tab)

Scala is weird. Sometimes it feels fluid and effortless but sometimes it simply cannot do things you would expect it to. For example, chaining custom methods. Why is it possible to do "arr.map(_.nonEmpty).filter(a => a % 2)" but not possible "arr.map(_.nonEmpty).myCustomFilter(_)"? In D thanks to UFCS and Properties you can chain all kinds of std and custom stuff together which looks more "efforless" and FP in my eyes.

Syntax aside I find Scala code hard to read due to how much implicitness it allows which stems from its "do FP or die" attitude which is again, weird for a language designed to incorporate both OOP and FP. Should I mention that in this regard D does a better job at serving the both worlds?

And finally, which threw me off completely is a real world case where we had to implement a word-entropy based algorithm to process tons of textual data and it appeared to be not much faster than a Python version despite all the optimization we tried to do. Scala is fast but there are many faster languages including Java itself. Considering the fact that its compiling times force you to leave your seat for a cup of coffee, you'd rather think of investing into another hard FP friendly language like Rust which simply has a wider applicability area. But yeah, this is all speculative but if you are thinking about what next language to pick up, these things start to matter.

Where Scala fits nicely is a small team which needs to build some business logic on top of the existing Java backend stack quickly and have a reliable working system. This is where it really shines. Scala provides a nice layer for JVM devs who have a soft spot for FP, safe and elegant solutions.

For me scala's feature set is absurdly big and there are always 10 ways todo things. Look at the spec of Scala. Its 200 pages long. That's insane.

I'd rather use Kotlin.

I am skeptical about the novelty of Scala's "OOFP" as you put it. It looks essentially the same as the original anonymous classes or SAM types in Java. Function values are objects with a single method and methods themselves are not first-class, but are wrapped in objects as required. The most important part of OO are the first-class modules; and in the literature, arguably more elegant examples of unifying first-class modules and FP exist, for example by starting with FP and adding objects as records containing functions, this way both "objects" and methods would be first-class. Subtyping also adds significant complexity to the language and weakens type inference.

Scala is, first and foremost an OO language which embraces subtyping, class hierarchies and imperative programming, see for example its own collections library. As Java gets more and more FP features, there is a danger it will struggle to differentiate itself.

I really enjoyed writing Scala code. I'd agree with your evaluation with respect to the expressiveness and power provided by the language.

...but the tooling, at least at that time, was terrible. SBT was terribly overcomplicated, and full of foot-guns. I spent far too much time debugging dependency collisions, issues created by so-called "autoplugins" and other nuances that had nothing to do with getting real work done.

Now I'm writing a lot of Go. I'll admit, it's not nearly as fun to write. There's a lot less creativity and expressiveness -- though I think this is probably a good thing. But it also feels like I'm getting a lot more stuff done, and the tooling is amazing.

> Too bad there's not really a ML/AI ecosystem around (besides Spark, which seems to be losing favor partially because of its embarrassing performance)

Compared to what? If you mean engines like Presto, I would say they have different use cases, plus Spark SQL puts them roughly in the same ballpark. Genuinely curious though, as a Spark user that is always interested in alternatives.

> Too bad there's not really a ML/AI ecosystem around (besides Spark, which seems to be losing favor partially because of its embarrassing performance), because using Python is such a drag.

I think it's not that bad. Sure, it loses to Python, but that's some tough competition.

Personally, I find that smile[1] covers most use cases. Breeze[2] also has a lot of love, but I'm not much of a fan of the `UFunc` abstraction.

I'm also really excited about polynote[3]. It's still a bit green and only supports Scala 2.11/2.12, but it's such a joy to be able to use Scala in notebooks :). You also get Python interop, in case you need to use some specific python library.

P.S.: I hope that Scala's ML/AI libraries other than Spark keep growing, because "embarassing" is a nice way to describe it's performance on everything that's not a "really-huge dataset".

1: https://github.com/haifengl/smile 2: https://github.com/scalanlp/breeze 3: https://github.com/polynote/polynote

> only one language I like more (kdb+/q), but that's a hard sell, especially because of the cost

J? It's not quite the same, but is OSS.

When Scala, IntelliJ and SBT cooperate the language is so pleasant to work with.

There are some puzzling omissions though.

For example slice method is missing step. Coming from heavy data munging Python this really bites. Sure would be nice to have some syntactic sugar for slice.

Some seemingly simple tasks have no one way of solving them.

Let's take parsing JSON. Trivial in Python, painful in Scala. (almost the reverse in Python which has painful XML parsing and Scala's built in support for XML)

So far the easiest JSON library has been Li Haoyi's uPickle: https://www.lihaoyi.com/post/HowtoworkwithJSONinScala.html

Still, it does not parse JSON where objects have uknown arbitrary value types. Arbitrary value types are extremely common in real life JSON.

Due to pattern matching you see people suggesting you write your own parser! Sure it can be done, but then the next thing you'll be rolling your own crypto...

>Too bad there's not really a ML/AI ecosystem around (besides Spark, which seems to be losing favor partially because of its embarrassing performance), because using Python is such a drag.

Even if Spark might not be the best tool for ML, it is still the tool to beat for data processing and custom ETL.

> considering the absurd productivity compared to Java/Kotlin/Python/blublang

I have not see more unproductive language than Scala.

Scala deserves all the hate. It might be a fun language for a throwaway pet project but I'd never recommend it in an enterprise setting.

It's an extremely unproductive language because it's too flexible. There are so many different ways to do the same thing which introduces unnecessary complexity.

Medium company (low hundreds of devs). My team is starting some new projects in Scala, which will be the first Scala at the company.

So far it’s going okay. But I personally am surprised at how disinterested most folks are in learning anything new.

Scala was the first serious attempt to break Java's stranglehold on the JVM that made any impact. A lot of people got very excited by it.

But then Kotlin, Ceylon, Clojure and others started to steal it's thunder and now it's just "one of the pack".

In fact, I'd say Java itself has stolen back from all those other languages to a large extent, with its language enhancements since v8.

My company uses Java for most things.. some python for scripting. There are a few of us who use Scala because of the work we do (Spark). I have to say that I prefer it over Java, and Spark is great for what we use it for. The functional features allow you to be concise and require a bit of creativity which makes it fun to work in. However, I doubt that I would use Scala outside of Spark. I think it's mostly because other typical frameworks that get used are Java-based so I would just code in that. That seems to be true of most of what I've done professionally: the framework or platform that makes your job easier (or even necessary) usually seems to require some specific language. (e.g.) When I coded a lot in IOS, it was Objective-C and then Swift (liked them both); a lot of web frameworks use Java or Python; front-end dev : javascript. At some point, they all just feel the same to me, to be honest. Some I like more, some I like less.. but the process is usually about the same. Clearly there seems to be the theme in the industry to move general-purpose development closer to machine-code (away from JVMs and the like).. Go, Rust, Swift, Lua, Dart are some examples. I think this is generally a good thing. At some point, Spark alternative will appear that will probably be written in Rust, if I had to guess... (Vega? or whatever it's called)

My experience as a freelancer is that the two camps are:

- enthusiasts who will stay with scala

- others who think they should have used kotlin/java from the beginning.

The latter camp is bigger and growing.

Enthusiasts moving to Rust (and Haskell), sure. But Go? That's definitely a language for the pragmatics, right alongside Java.

In my experience people just moved to Kotlin. Hardly seeing any new projects in Scala, except maybe for Spark and such. It is mostly just maintenance at this point.

I think the big gap between releases was part of the problem. 2.13 took forever and frankly there haven't been any must-have new features since 2.11. So Scala is no longer new and exciting. But it's still the best at what it does.

I mean, if Rust had higher-kinded types, and the established library ecosystem, and the IDE support that Scala does, then I'd move to Rust too. But it doesn't. When you have a large codebase and need to manage cross-cutting concerns, the only thing that can do that as well as Scala does except Haskell (or more obscure options like Idris), and the state of Haskell tooling is miles behind Scala. I'm not attached to Scala for Scala's sake, but it's still my first choice.

In my environment Kotlin has won the better-Java use-case quite thoroughly.

What I'm seeing is that Scala devs I know have started using Kotlin (including me). It is a much more pragmatic language that doesn't try to reinvent the wheel, like Scala does.

Same experience here. JDK11 and beyond added some more enthusiasm to base Java. If Loom lands I think a lot of people will also lose interest in Kotlin as well (because AIUI a big draw for Kotlin is the async story).

On the JVM, I think Scala won't have any major issues it is just another guest language and isn't used to sell InteliJ licenses.

Kotlin is chaining itself to Android, it will rule there thanks to Google's sponsorship, on everything else it is just yet another language to chose from with a weaker eco-system, used to sell InteliJ licenses.

Scala 3 supports braceless syntax, aka significant indentation, aka "YAML is to JSON as Scala 3 is to Scala 2"

https://dotty.epfl.ch/docs/reference/other-new-features/inde...

There was quite some debate on this, going on strong.

Yeah there are certainly some Python 2/3 fears for Scala 3, but the plan and upgrade path seem much more thought out

Is there a document with the differences between 2.13 and 3?

The crucial point here is if Scala 3 maintains backwards compatibility with Scala 2.x. If not, it's effectively a new language and then the game becomes which of the existing scala code bases will switch over and when. There's a large amount of existing Scala code out there and embarking on a migration of that stuff is going to take very long. We're talking many years here potentially. The few Scala projects I've dealt with, even updating to minor releases of Scala was a big deal.

The python 2 to 3 transition took well over a decade. You have similar discussions in what remains of the Perl community around v5 and v6. IMHO what Oracle has been doing with Java in recent years is impressive in the sense that they provide a credible upgrade path and put a lot of effort into that while still adding non trivial new language features. But it has a price of added complexity or compromises with new features and unfortunate legacy features that are not going to way. Javascript and typescript have the same issue. Javascript has a lot of weird legacy features and typescript preserves backward compatibility with that weirdness and attempts to engineers around that.

I'm currently using Kotlin across Android and Server (mostly) with an intention to also use it on IOS and Web very soon. Its multi-platform capability is increasingly a good selling point and I love how that ecosystem is booming in the last year/months. I'm definitely an early adopter of multi-platform but this seems to be one of those things where it seems like a bet worth making at this point.

Kotlin is of course a much younger language so it does not have a lot of legacy yet burdening it. Yet, Jetbrains seems to be good at managing new features while minimizing disruption, dealing with necessary deprecations, and generally not breaking compatibility. Their experience as tool makers gives them a unique edge over a lot of other languages.

Arguably Kotlin emerged as a rejection of Scala to replace Java by Jetbrains: they considered it and dismissed it as an option and then embarked on a journey to create their own language. I think the success of the language (relative to Scala) seems to indicate that that wasn't a bad choice. Scala intended to do many of the same things but it just never caught on with people actually doing those things to the extent that Kotlin seems to be catching on. The transition from Java to Kotlin is a lot less of a hard sell than the transition to Scala was. Though I know plenty of people that stubbornly stick with Java still. Of course early adoption in the Android community was a big deal. But then you could argue that that same opportunity was there for Scala to take and I don't think much serious effort ever was put in that notion. The need for something else than Java was quite big there and a big driver for this. All Kotlin did was provide a credible upgrade path to Java developers and the Android community jumped on it because it was easy to switch and obviously better. You see the same happening in the Spring community which is increasingly Kotlin centric.

Meanwhile Scala seems to be bleeding mind-share to more pure (for lack of a better word) languages Crystal, Elixir, etc. or more system oriented languages like Rust, or indeed Kotlin. It's a bit of a repeat of what happened to the Ruby community a few years ago. Certain types of people were very passionate about that language for a while and then moved on.

I have a pretty large codebase written in scala 2.12 or so (whatever the version was around late 2018). I'd like to migrate it to scala 3. Any ideas how hard it'll be?

There are many reasons why I respect him, but the fact that he laid out a time plan for Scala 3 already 2 years ago and then kept the timeline is mind-boggling.

> For example, using Http/JSON/Database libraries have always been a lot harder than they need to be due to a die hard approach to pure FP.

Hu? There are plenty of alternatives to the pure FP ecosystem.

HTTP: Dispatch, Requests-Scala, literally any Java client if that's still too FP for you

JSON: uPickle, Play JSON, or simply Jackson

DB: ScalikeJDBC. Quill and Slick do a lot more but are not particularly die-hard FP either.

Same here. Kotlin is a pragmatic language and it is a much better fit for the "Turbo Java" role that Scala originally wanted to do.

I never quite got what made python 2 -> 3 so much more complicated than say php 5 to 7.

I heard nobody complain the time I was still active in the PHP world (lucky me right?). Yet the Python2 code just kept lingering everywhere.

I've been working with Scala for 7 years now. Compilation speeds have been getting better throughout the 2.12.x/2.13.x cycles. Compilation speeds for Scala 3 are looking very good too.