bloop VS dotty

Here's the links: * bloop: https://scalacenter.github.io/bloop/ * terminal to IDE (iTerm only): https://alexn.org/blog/2021/07/18/iterm-open-file-cmd-click-ide-semantic-history.html * Switching between JetBrains' and standard typechecker in IDEA: Options -> Languages and Frameworks -> Scala -> Editor tab -> Error highlighting

If you look at the Build Tools section of the Metals documentation, you'll see how Metals supports sbt. It is admittedly a bit of a roundabout process: Metals first imports the sbt build definition into a tool called bloop that implements the Build Server Protocol that Metals relies on for metadata, compilation, etc. for the project.

Jorge Vican had finished some work on this in the past, but this feature was abandoned (for now). As u/tgodzik has pointed out, there is not enough interest for this in the community (thanks for replying btw.).

Bloop -- https://github.com/scalacenter/bloop

> 1) The language is too unstable

Thankfully not anymore. They got their act together and have been maintaining compatibility since Scala 3.0.0 has been released in May 2021, which is almost 4 years and counting.

https://github.com/scala/scala3/releases/tag/3.0.0

Scala 3.x is to remain compatible for the whole 3.x series (think of semantic versioning). There's no Scala 4 (breaking with Scala 3) in sight.

Also, Scala 3 and Scala 2.13 JARs are also compatible with each other, which helped with the transition.

> 2) The tooling around it is not the best

sbt may not be good. But Mill is much better than either Maven or Gradle. Especially Gradle. Bleep is also promising.

Scalafmt is widely used and liked. Scalafix -- the linter/fixer -- is used a bit less, but still of a good quality.

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).