However, it only supports Scala at the moment, and having a quick look it's goofing to be an awful fit for many other languages. I really don't feel they should be "camping" on such an obvious name without support for at least a half dozen different languages.
So (type aware) programming should be a conversation with the compiler, trying to prove more and more about the code, while trying to clarify the intentions of the programmer.
I like it as an idea. We'll see if it gets any traction outside of Scala-land.
There are some methods in BSP that might merit inclusion in LSP like buildTarget/test and buildTarget/run.
However, there are some critical methods in BSP that make no sense in LSP like buildTarget/scalacOptions. This is a method to extract dependencies and other compiler flags that are necessary for a Scala language server to provide completions, navigation, etc. Currently, every Scala IDE builds its own "export" command for each supported build tool resulting in duplicated effort. With BSP, we hope that a build tool can implement the server once and in return get integrations for multiple IDEs.
SBT has an extremely non trivial start up, and spin up time. Even using a client JVM (more aggressive JITing). You need to know the hot paths, before you can JIT them.
And as a CLI tool, by the time you start optimizing your hot paths your tool will exit.
Now C/C++/Rust/Go compilers can be slow, when your compiling A LOT of crap. But the tools will spring to action extremely quickly on smaller jobs. And while build farm services exist, they’re useful for handling instances where you have GiB’s of sources, or sources which expand into GiB’s of input.
Overall a generic build server API sounds good, but this doesn’t solve the core problem Scala has which can be summarized by running:
So, what's wrong with SBT?
But there's hope: https://www.lihaoyi.com/mill/
I'm pessimistic, but also hope I'm wrong.