sbt-native-image VS dotty

Take a look at sbt-native-image or sbt-native-packager for building the native image.

The reason seems to be Scala 3's new encoding for lazy vals, where a reflective access to a variable called bitmap takes place. To demonstrate this, I took the http4s g8 template, set it up with Scala 3.1.0, added sbt native-image, started the nativeImageRunAgent and ran a single request against GET /joke. After stopping the server, the native-image run agent generated the reflective configs that are required for this path of execution. Comparing the generated Scala 2.13 with the Scala 3 configs, yields a bloated version for Scala 3 that contains these additional rules:

Sbt plugin: https://github.com/scalameta/sbt-native-image

IIRC, the sbt-native-image plugin can abstract that away, too: https://github.com/scalameta/sbt-native-image#nativeimagerunagent https://github.com/scalameta/sbt-native-image

Assembly, however, has some disadvantages so you may also want to look into other alternatives like sbt-native-packager. You may even want to produce a binary using sbt-native-image (which uses GraalVM under the hood) so your users do not need to install anything at all, not even a JRE.

Dotty? Was it still the name later?

http://dotty.epfl.ch/

I think this might be related to this issue.

You can look (and EPFL collect feedback) about EPFL implementation of async/await: https://github.com/lampepfl/async. Also you can look at dotty ticket about this: https://github.com/lampepfl/dotty/pull/16739

The reason I’m not currently an opaque type user as they do not play well with the tagless final style we use, though I am patiently awaiting some attention on my bug report: https://github.com/lampepfl/dotty/issues/17281

Links: - https://dotty.epfl.ch/ - https://scala-native.org/en/stable/ - https://www.scala-js.org/ - https://typelevel.org/ - https://zio.dev/ - https://github.com/scala-native/scala-native/pull/3120 - https://github.com/lampepfl/dotty/pull/16517 - https://dotty.epfl.ch/docs/reference/experimental/index.html - https://scala-cli.virtuslab.org/ - https://scalameta.org/metals/ - https://docs.scala-lang.org/scala3/guides/migration/compatibility-intro.html - https://www.scala-lang.org/blog/2023/04/18/faster-scalajs-development-with-frontend-tooling.html - https://www.scala-lang.org/blog/2022/08/17/long-term-compatibility-plans.html

Scala Native has much more control on how the Scala AST is compiled, and can easier workaround platform limitations, eg. lazy vals in Scala 3 required reflection config for Native Image (see this and that), while in Scala Native we could mitigate problems with unsupported usage inside in other ways within the compiler plugin.

By the way, you might be interested in this recent PR which overhauls the scala 3 macro docs: https://github.com/lampepfl/dotty/pull/17060.

For example, this issue (https://github.com/lampepfl/dotty/issues/12840) was blocking the migration, it was reported more than a year ago and the fix was finally released a month ago (https://github.com/lampepfl/dotty/releases/tag/3.3.0-RC2).

For the record, there is an implementation of :javap which is close to being done but might need a volunteer to get it over the finish line: https://github.com/lampepfl/dotty/pull/12210

im glad to tell you that in 3.3.0 a lot of these -Wunused lints will be supported: see https://github.com/lampepfl/dotty/pull/16157