Here's a great talk given by Martin Odersky, "A Tour of Scala 3" https://www.youtube.com/watch?v=_Rnrx2lo9cw

That talk is almost a year old now :) a lot of progress has been made towards launching Scala 3. The latest Dotty release was March 18 https://dotty.epfl.ch/blog/index.html

Scala 3 combined with Scala.js and GraalVM native compilation will be a killer stack :). You can write code that's as high level as python and typesafe as Haskell. Use the same code on the backend and in-browser with Scala.js. Compile your code to statically linked native executables with instant startup time, great for CLI tools.

In terms of developer experience, Scala 3's compiler is much faster than Scala 2 because the data structure representing incremental compilation is not rebuilt for each compiler phase. The faster compiler can be used with Microsoft's Language Server for a delightful IDE experience, especially in VS Code which is the current recommended editor for Scala 3.

Interesting you refer to C++. Both languages, IMHO, became too big to be practical. You need to, as a team, choose a subset of C++ (or Scala) and a style for it to become manageable.

I dont think this looks good on a language, I prefer a language that comes with a small, concise set of features that are broadly understood and applied. But different folks different strokes.

I would disagree here. Scala's language spec is smaller than javas, it's problems are akin to Lisps. Too many dsls, extensions and so on. It really opened the doors for FP concepts to go mainstream. Unfortunately, some people went way too far with it.

Brainfuck's spec fits in one page. As does Whitespace's spec.

These two languages are impossible to write code in because of their complexity.

It's completely mystifying to me that even today, Martin still uses the "spec size" argument in his keynotes to attempt to demonstrate that Scala is a simple language, and it demonstrates a complete ignorance of what language design actually is, or a troubling disingenuity meant to deceive.

The intention should matter. Brainfuck's is self descripted. I can come up with a few things that are genually confusing about scala, like implicits resolution rules and quirks of the type system, but I cannot claim they are intentional, and they are getting fixed. On the other hand, having things like functional collections futures years before Java made life easier for the whole lot of us

Creator of Scala believes, and advocates, Scala is simpler than Java?

Wow.

Because it is simpler than Java, in particular when you limit it to the subset of features covered by Java only. Many Scala features that do exist in Java are more complicated in Java. And some do not exist at all, which means you have to emulate them by writing more boilerplate code.

So does creator of spring who sat on lightbends board for a while

To me, the question is who is allowed to make the choice?

Is it the language designer's place to say what can or cannot be done with it or the person/team who chooses what they do with it?

Personally, I would rather work with programming languages which allow me/the team to choose. YMMV.

A word of caution on Scala 3:

Scala 3 still in beta, lacks clear roadmap, allows choosing between two syntaxes (python-style vs braces).

Dotty Community Build lacking Lightbend frameworks (no Akka, no Play, no sbt)

With the recent layoffs at Lightbend of Scala 2.x core contributors, a full endorsement of Scala 3 would certainly help.

As an outside observer (and professional Akka user), comments like this really help put the changes in perspective. Thanks.

Scala made lots of Java patterns builtin language features, and it appears Scala 3 will do the same thing with all the patterns that emerged in Scala 2. As long as the tooling keeps up to par, Scala 3 will be one of the most pleasant to use languages out there.

Unfortunately, I slowly got frustrated reading the what's coming for Scala 3.

* True intersections and union types -- use them sometimes, not something you can't live without though.

* Trait parameters -- slightly easier life for OOP, ok I guess.

* Function types and implicit function types -- right, will make your code even harder to read (subjective).

* Generic tuples -- again, I can't remember we ever had problems with tuples in Scala.

* Opaque types -- another small OOP improvement.

* Type lambdas -- I've never seen them used.

* Erased parameters -- probably useful if it improves performance even at the cost of readability right?

* Enums -- finally something practical, good.

And that's all about major changes in Scala 3. Ah, yes, we get a new compiler. Are you excited?

These changes look like a quarterly release than a major version shift. Now, imagine a project manager who's estimating the migration downtime for Scala 2 for the sake of the above.

Trait params have little to do with OOP.

Opaque types are not a "small OOP improvement", they finally bring zero-cost newtypes to Scala, superseding value classes. Now you can finally ensure that object Ids, people's names, meters, feet, and degrees Celsius all have different types - without any extra boxing at runtime.

Your list is also missing typeclass derivation, which is going to be a fantastic quality of life improvement. Yes, even for people who don't care about what a typeclass is.

This is a point I want to stress the most, I think. Features like type lambdas, or libraries like Shapeless - they can possibly be extremely beneficial to you even if you don't use them directly in your code. Ask your nearby Haskell programmers about the virtues of `deriving (Eq, Ord)` and they'll talk your ear off. And that's before they even get to things like `deriving (FromJSON, ToJSON)`. Don't have a Haskell programmer nearby? It's ok, ask a Rust programmer about Serde instead. Typeclass derivation is just such a massive, massive feature to have in your language's repertoire.

Well. You also get better binary compatibility and the possibility to do whole program analysis.

Edit: oh. And this is on top of a rewritten, faster, compiler, a unified base paradigm making it easier to learn the language, and better error messages for compile errors. I think dismissing this as as minor release is disingenuous to how much effort goes in such a large scale rewrite. Granted, most of it is under the hood but it will pay off dividend.

Scala 3 could improve on 2.x struggles with supporting JDK 9 and up:

Support features of JDK 11+ https://github.com/scala/scala-dev/issues/139

Support Java Module System https://github.com/scala/scala-dev/issues/529

In comparison language features seem to attract much more attention:

Removing existential types https://contributors.scala-lang.org/t/proposal-to-remove-exi...

Significant indentation syntax https://github.com/lampepfl/dotty/pull/7083

That is a good example why betting on the platform languages is always a long term safer bet than betting the house on guest languages,

Eventually they won't keep up with the underlying platform.

It's not like it isn't working. Scala runs fine on JDK13 (probably 14 too, but we currently run one Play project in prod on 13).

Java is a pretty safe bet, as it has an outstanding backward compatibility track record.

Yup. I jumped ship for Swift a while ago.

I always thought scala native to be a bit of distraction after graalvm went mainstream. Don't know why people do not like working with language that can combine better parts of Java Haskell Ruby and Erlang. Having said that, Scala is Scala, and people who are writing Haskell or Java code in Scala certainly not writing Scala

> people who are writing Haskell or Java code in Scala certainly not writing Scala

For me, one of the joys of Scala is that you can use different paradigms and mix them up as convenient. Haskell Scala is still Scala and so is Java Scala!

I do that too, but to a degree. For example, I avoid monad transformers, fully automatic derivations, pretty much anything that requires line long type signatures

> Martin Odersky is for me in the top three language designers of our time

I don't know about that.

To me, the criteria he uses to allow incorporation of features in both Scala 2 and Scala 3 is "Will this feature allow me and my students to apply papers for conferences and fund my PhD students?".

Language design seems to have very little to do with that. As long as you can derive multiple papers to multiple conferences from a proposed feature, it's in.

That sounds like an accusation. Could you back it up by something, perhaps examples?

for the record, instantiating case classes in scala does not require "new"

Or any other class if you write an apply method in companion object