Metals VS Scala Native

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

You might want to look at Scala, they have proper LSP support with metals which means you can write your code in vscode, neovim, emacs, or even fleet (the new jetbrains text editor).

Please write in the comments if you know of any language servers I should test it with. Currently I tested only metals and rust-analyzer.

If you are using nvim-lspconfig you can pass the settings as a Lua table to the setup function. For example, here are may metals settings:

Bazel support in Metals. I didn't spend all that time figuring out and adjusting Emacs/Spacemacs and making my workflow (almost) mouse-free just to scrap my config and switch to IDEA's rodent infested ways.

There is one small issue involving code completion returning inappropriate completions in some cases; https://github.com/scalameta/metals/pull/4414 will fix it, once it's included in a release. Perhaps that's the PR you saw?

It is, by quite a bit.

While the "Scala IDE" project is dead for all practical purposes, IntelliJ IDEA's Scala plugin is actually pretty amazing. There's also a VisualStudio plugin that does pretty much the same and is advancing by leaps and bounds. There are also interconnecting projects that provide i.e. language server or build server that are reused by other projects. It's pretty modular. Metals (https://scalameta.org/metals/) is amazing.

In general the language has become a wee bit faster to build, there was good progress with build times during the 2.12/2.13 cycles.

With Scala3 the language got a bit simpler; concepts that were implemented explicitly using (hehe) implicits got their own keywords and a lot of the opinionated boilercode that cause a lot of debates is now generated during complication and hidden. A lot of "standardization" has occurred.

IntelliJ has its own BSP. The other one is Metals. You can use it with many IDEs (vim, emacs, vscode, atom,...). Use it with emacs if you're comfortable with it.

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

There's a plant of topics in which we might need help. To name a few, we might need some help in [porting the remaining JSR-166 types](https://github.com/scala-native/scala-native/issues/3165) to Scala Native shipped with future experimental multithreading support, but also large parts of the Java standard library need some improvements or reimplementations. Last but not least, we need people dedicated to the optimization of our current toolchain to make it use fewer resources and allow for faster builds.

Scala Native could have been this language, but at this stage I don't see it happening.

good stuff there is https://scala-native.org/ and http://www.scala-js.org/ then, I suppose?

Please vote for dropping Scala 2.11 support in Scala.js (https://github.com/scala-js/scala-js/issues/4759) and Scala Native (https://github.com/scala-native/scala-native/issues/2780)

I presume only the JVM version of Scala can use Loom but scala-native (https://scala-native.org/) and scala-js (https://www.scala-js.org/) can't use Loom. Similarly with Kotlin, the JVM Kotlin gets Loom, but the native and Javascript backends do not.

Nope. Scala Native is (still) single threaded, just like you are in e.g. Python or Node.js.

Until recently, there was only 64-bit support. 32-bit support is coming, though, see this pr. This means that you will be able to target 32-bit microcontrollers soon. Anything lower than 32-bit might not be realistic.

The release is binary compatible with previous ones, but Scala 3 on its own does not fully source compatible - more info about that in https://github.com/scala-native/scala-native/pull/2480 The full release is planned for the first weeks of January.