Migration to Scala 3: What is your plan?

Scala 3 is just around the corner and many of us have probably similar questions:

  1. What are your plans concerning the migration to Scala 3 for existing projects?
  2. What JDK will you most likely be using with Scala 3?
  3. Would you already start a new project already based on Scala 3?
  4. What are your thoughts concerning the tooling?

My take on that questions:

  1. I have no plans yet, but either I migrate very early or very late, depending on the tooling and eco-system.
  2. Most likely the latest LTS version.
  3. Probably yes.
  4. As I am using IntelliJ I have to wait until the Scala plugin has full Scala 3 support.
4 Likes

For libraries, I’ll keep crossbuilding. Applications will drop support for scala 2.

11

Yes

It keeps getting better and is much better than in was a few years ago. There is still room for improvement though, especially in managing the complexities and performance of sbt / cross-building and the availability of refactorings in vscode / metals.

2 Likes

My guesses for work (very much not any sort of official line):

  1. We’re going to spend the rest of 2021 strategizing that: we have hundreds of Scala 2 repos, and it’s going to take some careful thought to get a plan that makes sense without being disruptive. My suspicion is that we will start formal cross-building in early 2022 (possibly late 2021), but libraries will need to be cross-built for years – I don’t expect us to fully move off of Scala 2 any time soon. (That said, our public weePickle library is likely to try cross-building this year, and help towards that would, I suspect, be welcome.)

  2. A mix of the LTS releases – we allow projects some flexibility to decide when to upgrade.

  3. Probably not, although it wouldn’t surprise me if some applications start to dip their toes in the water late this year – given interoperability with Scala 2 libs, that seems plausible. I don’t really expect us to be building internal libraries in Scala 3 this year.

  4. Insufficient data so far, but we probably won’t do anything serious until there is solid IntelliJ support. (We have some folks using Metals, but I think the large majority use IntelliJ.)

2 Likes

I am working on migrating some libraries to Scala 3. For JDK I assume LTS or up. Tooling needs to catch up, but IntelliJ is generally usable with Scala 3.

My main problem is lack of macro annotations in Scala 3. My applications make heavy use of libraries like ScalaFXML. Without macro annotations my key projects cannot migrate to Scala 3.

1 Like

Do we know how long Scala 2.x will be supported anyways?

A long time. We aren’t even done with 2.12 yet, let alone 2.13.

We (the Scala team at Lightbend) are still:

  • actively working on Scala 2.13 and releasing new 2.13.x versions
  • somewhat less actively working on 2.12; 2.12.14 is coming soon and it won’t be the last one
  • offering commercial support for Scala 2

We expect all of that to continue for years to come. Scala 2.13 and 2.12 are still in very wide use today and will remain in wide use for years to come. (2.11 usage is declining.)

See also my recent similar remarks on Reddit about how long it takes for old Scala versions to become commercially irrelevant.

6 Likes

Thank you so much for your clarifications!

1 Like

For the active hobby code I want to move to Scala 3 quickly, to teach the kids the new stuff.

For the day-job, we’ll move at “all deliberate speed.” We are about to do our first release with 2.13. I’ll likely switch us to the 3.0 compiler once the tooling has caught up, hopefully before 2022.

For the hobby code, I’ll likely stay on the latest LTS, but need 32-bit Arm9 support. That’s JDK11 right now.

Latest LTS at the beginning of effort on a new release for the work code. That’s JDK11 right now.

For the hobby code I need a few features that aren’t quite cooked yet: @specialized, scaladoc more mature. If it were just for me I’d go ahead. I compiled a lot of code with Scala3 last week without issue.

For a new project at work - if it was going to take until September to release I’d start it in Scala3 now. I’m hesitant to put -RC of anything in production.

For the hobby I need really good tool support for the students: Intellij, plus I want to try Jupyter Notebooks. One of my best students seems OK with mill, so we’ll likely use that. ( However, mill supports some syntax that’s more advanced than I want to introduce, and turning off the spyware is awkward. )

For work - I’m sure our standard kit of Intellij, Yourkit, and maven will have caught up by the time we switch over to Scala3. I have mild concerns about maven with Scala3; we’ve been stuck on an old version of the maven scala plugin (taps directly into an internal zinc API) for performance reasons, and our support team prefers maven.

2 Likes

What are your plans concerning the migration to Scala 3 for existing projects?

We only have a few at work on 2.13 right now and I hope to get the rest for my team done in the next couple weeks. Scala 3 probably won’t happen until late this year at the earliest, though I expect I’ll start cross-building our libraries before then.

What JDK will you most likely be using with Scala 3?

Depends mostly on what’s released and supported by the compiler at the time. I’m guessing it’ll be 17, maybe 18, just given how many months it will be before I can really get into it.

Would you already start a new project already based on Scala 3?

If I were writing a personal project or a library, absolutely. For work I would consider starting a new project on 3 only after we had all our libraries cross building and all our dependencies were up to date or had replacements.

What are your thoughts concerning the tooling?

This isn’t a personal concern of mine. While I make use of certain features in IDEs, I’m pretty comfortable working in a less-than-capable, buggy, or broken environments (I often run EAP/nightly/rolling releases of things). So as long as I can get reliable feedback from the compiler via the build tool, I won’t be bothered as much by things like highlighting errors or not finding usages or whatever other quirk the IDE/plugin has.

That said, my team and especially the junior devs tend to be a lot more frustrated by finicky tools, so I’d likely be the guinea pig and only suggest that we really move once I feel the whole experience is good enough for the majority. Ideally, that would be out of the gate, but even if it’s a year from now it won’t affect us much.

3 Likes
  1. What are your plans concerning the migration to Scala 3 for existing projects?

In the short and medium term, we will probably migrate only to the extent that crossScalaVersions will work.

  1. What JDK will you most likely be using with Scala 3?

Our code is usually delivered as source and we don’t want to unnecessarily limit the Java installation that the recipient uses. Any version that we haven’t found to cause problems.

  1. Would you already start a new project already based on Scala 3?

Not unless the code will also run with 2.12 or even 2.11. We don’t have any standalone projects that don’t have a large number of dependencies, forwards and backwards, so that 2.12 needs to continue to work.

  1. What are your thoughts concerning the tooling?

We have APIs that expose classes that have disappeared in Scala 2.13 and higher. The code must change in some way, but we don’t want to branch or fork entire repos. Somehow both alternative implementations need to stay in the same file even though they won’t both compile. There needs to be some kind of annotation that says to use one version of code for this Scala (2.12 and lower) and another for that Scala (2.13 and higher). This doesn’t seem to exist. I’ve seen that android developers have a way of dealing with it. Has anyone found something reasonable for Scala?

1 Like

We’ve recently started breaking out version-specific code into separate directories so that we have the usual src/main/scala and also src/main/scala-2.11, src/main/scala-2.12, src/main/scala-2.13 where we struggle to keep the last three as small as possible. If returned types have been changed, we define a named type in those files and change the value accordingly. Sometimes it is type ReturnType = IterableOnce[Int] and other times type ReturnType = TraversableOnce[Int].