Announcing the Build Server Protocol v1.0.0

https://www.scala-lang.org/blog/2018/06/15/bsp.html

by aphexairlines • 8 years ago

53 13 8 years ago

I've used Scala for years. If this is finally the thing that gets Scala a great IDE, it will be the single best thing for the language in a while.

I'm pessimistic, but also hope I'm wrong.

CJefferson• 8 years ago

This is clearly trying to sell on the success of Microsoft's Language Server Protocol.

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.

wereHamster• 8 years ago

To be fair, LSP was TypeScript only in the beginning. You have to start somewhere.

pas• 8 years ago

And there was the sort of famous (at least in Scala circles) rant by Paul Philips about how insanely dumb the compiler is, how slow and unhelpful, as it builds up all the structures from scratch every time, just to throw a syntax/type/other error, instead of keeping the state and only processing the delta (the changes and the minimal related nodes in the tree).

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.

cosmicexplorer• 8 years ago

I disagree, it seems to be building on a lot of discussion build tool developers have been having recently. E.g. Pants (mentioned in the article) supports exporting not just scala but multiple other languages into an intellij plugin we also develop, and we are involved or familiar with the work at the scala center and I personally think this is really exciting, and that the LSP analogy is pretty reasonable for the type of operations they intend.

jitl• 8 years ago

So, what is the difference in responsibility from the Language Server Protocol that Visual Studio Code uses? I get that they’re riffing on the same concept, but why separate the two? What’s the difference, other than that “oh this one is more build-y”?

tragic• 8 years ago

LSP is specialised for static analysis of code, and aims to provide a generic protocol for doing that. However, say I want to run a single test from Vim. Currently I have, for ruby, rspec.vim so ",s" will run the test under the cursor, but all it does is shell out to an rspec command. So it seems the idea is to provide a generic interface for "run this test in this project", or "build this file", without having to care about the specific build tooling involved.

I like it as an idea. We'll see if it gets any traction outside of Scala-land.

olafurpg• 8 years ago

The main difference between the two is that BSP serves the needs of language servers and LSP serves the needs of editors. The two protocols have some duplicated functionality like build/publishDiagnostics (== LSP textDocument/publishDiagnostics), build/logMessage (== LSP window/logMessage), build/showMessage (== LSP window/showMessage), build/didChangeWatchedFiles (== LSP workspace/didChangeWatchedFiles).

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.

zimbatm• 8 years ago

Link to the spec: https://github.com/scalacenter/bsp/blob/master/docs/bsp.md

valarauca1• 8 years ago

Solutionism

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:

    sbt -version

and seeing it take 1-2 minutes to display an error message.

kod• 8 years ago

I don't think you mean 1-2 _minutes_

AheadOfTime295• 8 years ago

No opinions, just facts:

So, what's wrong with SBT? http://www.lihaoyi.com/post/SowhatswrongwithSBT.html

But there's hope: https://www.lihaoyi.com/mill/

Announcing the Build Server Protocol v1.0.0

Related Stories