
Announcing the Build Server Protocol v1.0.0 - aphexairlines
https://www.scala-lang.org/blog/2018/06/15/bsp.html
======
CJefferson
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
To be fair, LSP was TypeScript only in the beginning. You have to start
somewhere.

~~~
pas
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.

~~~
jvican
FWIW, this has nothing to do with BSP and it's also not true technical wise.

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

------
valarauca1
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
I don't think you mean 1-2 _minutes_

~~~
AheadOfTime295
No opinions, just facts:

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

But there's hope:
[https://www.lihaoyi.com/mill/](https://www.lihaoyi.com/mill/)

------
zimbatm
Link to the spec:
[https://github.com/scalacenter/bsp/blob/master/docs/bsp.md](https://github.com/scalacenter/bsp/blob/master/docs/bsp.md)

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

