Towards Scala 3


#1

We just released a blog post announcing Scala 3. Happy to take any questions people might have on this here.


#2

Thank you for the good news Martin.

Could you say something about the speed of dotc vs scalac?
And what backends will be supported?
Will JVM remain the default?


#3

Compile speeds are comparable, and there are efforts to improve them for both Scala 2 and Scala 3. The only backend currently supported is JVM. It would be great to include Scaja.js and Scala.Native as well, for sure, and I don’t think it would be very hard to do this.


#4

I am pleased by the new presentation compiler design, but I think it is a mistake to design an LSP server from scratch, bless it above all others, and couple it to the compiler release cycles. This will kill off ensime and its community, whilst reducing the mission of the LSP-WG to a tactical solution.

If your goal is an excellent beginner experience, e.g.:

  • user installs the Scala plugin from the vscode / atom / etc marketplace
  • prompt to install the JVM and sbt using the OS package manager (automated when approved)
  • prompt to setup an example project that will
    • download an example project using g8
    • opens “my first scala program” source file annotated with documentation, showing off language features and how to build / run the code.
    • Completion, red squigglies, and classpath search all work here.

We can do all of this on vscode with ensime, with only a small amount of work. The reason nobody wants to do this as a volunteer is because it means having to deal with angry and confused beginners. The support needs to be commercially funded. If this is something that Lightbend or the Scala Center wants to fund, I can show them what needs to be done on the ensime side to make it a reality.

The point is that we do not need an LSP to be baked into the standard distribution to work like this. If we throw away everything in ensime, and collaborations in LSP-WG, and start from scratch then EPFL will just be rediscovering all the same problems we’ve been facing and solving in the wild. I wrote up my recommendations for the LSP-WG and they are equally applicable to Dotty’s LSP http://ensime.org/lsp-wg/

Everybody involved with LSP met at Scalasphere, we discussed the more general problem of service discovery. Although this is not a conclusion of the LSP-WG, a new architectural design was proposed in https://github.com/ensime/ensime-server/issues/1941 that solves all of these problems.

As far as I can tell, Dotty’s LSP will not be capable of supporting anywhere near the wide range of usecases that ensime has been designed for (multiple projects open at one time, multi-million line corporate projects, editor independent, build tool independent).

I expected the Dotty LSP to be a proof of concept, to help design the new presentation compiler and TASTY depickler. I did not expect this to become what it has become and I’m concerned that the Dotty LSP will kill off community innovation.

In addition, please note that Dotty’s LSP uses the Eclipse License, which is explicitly incompatible with the GPL and therefore ENSIME.


#5

Thanks for the information!

I’m confused about this statement:

“Scala 3 and Scala 2 share the same standard library.”

I mean, even 2.11 and 2.12 have different APIs, how can 2 and 3 be the same? Or do you mean to say that 3.0 uses 2.14 API?

Thanks!

Best, Oliver


#6

I’m confused by

Scala 3 code can use Scala 2 artifacts because the Scala 3 compiler understands the classfile format for sources compiled with Scala 2.12 and upwards.

When it is also the case that

Scala 3 is not binary compatible with Scala 2

Which in the past has meant that new versions can’t use code compiled by older versions.

Can you say a bit more about what the first statement means?


#7

It’s the difference between consuming and producing. Scala 3 can link against Scala 2 artifacts because it understands the pickling format. But binaries produced by Scala 3 use a completely different format based on Tasty that Scala 2 does not currently understand.


#8

We’ll standardize on the 2.14 standard library, which I expect to be very close to 2.13.


#9

We worked on LSP because we need it ourselves. I am personally at least 2 times more productive with an IDE that works well. And since the core of our LSP server is quite small, I can go in there and improve it myself!

Overall I want a zero-hassle to install lightweight solution that runs in less than 4G. I don’t think ENSIME can provide that as it is, and it would be much more cumbersome for us to interface with it. But I don’t speak for others.

I believe the Eclipse license comes from the interface layer that does the JSON serialization. If that turns out to be a problem, it would be easy to swap it out. I leave the discussion of licenses to others, it’s just too time consuming for me to engage in this.


#10

I’ve run ensime on less than 500MB of heap, on industry projects that have more than 3 million lines of scala code, with instant responses, while IntelliJ users are waiting for a long time for anything. ENSIME is highly optimised for large codebases. I consider the scalac / dotty codebases to be very small: they don’t stress the binary indexing mechanisms at all and I would encourage you to test the new LSP on much larger codebases before we should call to abandon ensime.

Of course ensime will not work with dotty for your own development, but for scala 2.11 and 2.12 development, it is quite easy to get ensime to the point where you can have “zero hassle install” from any text editor you want. I intentionally have not made a “single click” install because when I did things like this, we got too many users, and too many abusive messages from people who expected me to help them with both ensime and scala development at all times of the day and on all social media channels.

The 3.0 branch is about a week of developer effort away from being a fully compliant (all features) LSP server. Since we are volunteers, it may take several months, and I am not personally working on LSP.


#11

Ok, sounds like it should be worded “Scala 3 binaries are not backward compatible with Scala 2”?


#12

Extraordinary news.
Thanks a lot.


#13

As an enduser developer I’m really looking forward to having a scala compiler with an LSP.
It’s something that I’ve experienced for a while now with Typescript and it’s a really nice developer experience: feedback in the IDE is always correct (unlike now with IntelliJ), performant and easy to setup.
In my mind it’s just what modern compilers offer.


#14

It’s been rather unfortunate, but I think that perhaps the performance of Ensime has been judged, generally, by the introduction of a feature (find usages of) that put the performance to an unusable state. Recent releases of Ensime have disable this feature by default. With its removal, Ensime performs very well, and, in my experience, better than both IntelliJ and Eclipse.


#15

It will perform even better when you disable syntax and error highlighting!


#16

Does Scala 3 introduce Kotlin’s JvmName annotation?


#17

I hope the official rendition is Scala <3.


#18

Correction: since Dotty currently bootstraps with Scalac (not with existing Dotty), ensime is applicable there, and I managed to do a basic setup, tho I haven’t spent significant time to configure it correctly.


#19

There has been a lot of activity in this area, so here are some updates given by Martin O. on the future of Scala 3 and how Scala 2 - Scala 3 compatibilty will work. https://twitter.com/odersky/status/997059263309795328

Important: the goal is to have Scala 2 reuse Scala 3 artifacts and viceversa via Tasty. This property is what makes this case completely different from Python 2 and Python 3.