Do we need Scala 3?


#1

We certainly want Dotty. I presume that goes without saying, so I’ll just take that as read. But does this mean we want Scala 3.

I think the idea of Scala 3 has been very useful, to think how would we do things if we were starting again from scratch. What is good and what is bad about current Scala. What is essential and what is superfluous. What features could be replaced by a much more general feature. How could the language be simplified. The slogan of this approach is:

"If you’re going to break it, break it good."

I’m not an expert on Python, but my understanding is that this was the philosophy of Python 3. Break everything in one painful but short, sharp break. Get all the pain over in one go. But as time has gone on the Scala contributors seem to have shied away from this approach. More and more they seek to minimise the changes that the language user will experience, an epic language change, that won’t really be a big change at all. This seems very much in tune with the way that software infrastructure is going. For the Linux Kernel the numbering change from 2.6.39 to 3.0, and from 3.19 to 4.0, involved no meaningful technical differentiation. Systemd is now on version 239. Java is moving away from epic language changes to regular, predictable, incremental versioning.

There seems to be almost universal agreement that we want to get rid of XML literals. This is a language simplification that almost all Scala users can sign up to. I don’t use them, but as XML literals were already in Dotty, I suggested delaying their removal till 3.1, rather than trying to take on too many tasks at once. But it also became apparent that there was no migration path for XML literals. It became apparent that this simplification was going to make some peoples lives a lot more complicated. Maybe we need to beware of premature simplification. Simplification is often not a simple task. The alternative to “Break it good” is:

"No one left behind!"

But maybe there is a need to generalise this anyway. The macro community certainly can’t be left behind. But are the replacement mechanisms for Macros really ready? Would it be better give more time to find long term, sustainable solutions for the varied use cases of Macros. Might it not be better to create a temporary hack for White box macros for Dotty. I don’t see why this would have to compromise the integrity of the dotty compiler design. No doubt some changes would be necessary for macro writers, but they could be kept to a minimum. The removal of White box macros, a very desirable simplification to the language eco system could then also be deferred to after the transition to dotty.

Could the disruption of the move to dotty be reduced to the level, or even below the level of the the 2.11 => 2.12 transition. A transition it should be noted that still has not been completed by Native or Spark. Could the need for an epic version change for Dotty be removed. None of this of course would not preclude us making an epic version change at a later point if that was desirable.

One final thought. Maybe Dotty should be forked. One fork should be totally focused on replacing NSC at the earliest opportunity with the minimum pain and disruption to the Scala Community. The other fork could remove XML literals, remove anything else that is non essential and superfluous to core Scala, not attempt to support Macros, not attempt to support the whole Scala eco system, but become a nimble light weight compiler for language experimentation.


#2

I don’t think there is anyone that’s claiming any other answer than “no” and “yes” for those questions respectively.

That sounds like an interesting idea, though I’m not sure whether a full fork is needed for that.

Side note – Let’s not pretend forking dotty will make it feasible to port the scalac API to dotty, which is required to support scalac macros


#3

Don’t know about Scala 3, but:

As an ex-Python developer I can say that the problem with Python 3 is that it offered no compelling features for upgrading, coupled with major libraries not upgrading (because why bother), which is why the migration took forever, with many projects still being in limbo.

I can think of features present in Python 3.5 or 3.6 that I want, like optional typing or async functions. But these are relatively recent additions.

In other words I think Python 3 is an anti-pattern.


#4

Didn’t Python3 have proper async support (i.e. yield)?