cargo-raze VS Metals

The same reason Bazel builds avoid using Cargo when building Rust software, so I'll describe why Bazel would do this:

- Bazel wants to cache remote resources, like each respective crate's source files.

- Bazel then wants to build each crate in a sandbox, and cache the build artifacts

This is an established practice, and Nix wants to drive the build for the same reasons.

See:

- https://github.com/bazelbuild/rules_rust

- https://github.com/google/cargo-raze

I can make much more sense of C++ code to ensure that two build systems produce the same effect than I can parse and learn two completely unconnected programming languages deeply enough to do the same. I can unit-test core routines. I can as easily extract core logic into shared (configuration) files etc. The benefit of a standard is not to discourage alternatives but rather to agree on definitive semantics and shared and common needs (that is: in this case needs for interfaces to the compiler/linker). The implementation and general availabilty is just one of the by-product. The ability to do introspection in common terms is maybe the most consequential other product, and this is critical for 'transpiling' to other build systems and writing automated adapters such as the one that bazel is recommend for cargo's dependency management.

Cargo is not that tightly coupled with Rust. You can absolutely use bare rustc, and in fact people do that with other build systems like Bazel.

Interesting, aren't the community-driven crates for these areas satisfactory enough? There's PROST and tonic, and quite well-used. I don't know about Bazel though, but I found this. Feel free to correct me on this subject, I admit I don't know that much about it.

There is a project to generate Bazel BUILD files from Cargo.toml.

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.