Skip to content

Add blog about BSP in sbt #1166

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Oct 27, 2020
Merged

Add blog about BSP in sbt #1166

merged 2 commits into from
Oct 27, 2020

Conversation

adpi2
Copy link
Member

@adpi2 adpi2 commented Oct 20, 2020

No description provided.

@SethTisue
Copy link
Member

SethTisue commented Oct 20, 2020

I usually make this same suggestion on everybody's blog post drafts:

I'd suggest leading with the most important material. For two reasons: so someone can tell early whether they want to keep reading; and so someone gets the main takeaways even if they bail early. People are busy and the reader's attention is precious.

The most important material always answers the question: why should I, the reader, care? At the start, the reader doesn't care what BSP is, or who was involved in a collaboration on it, or when that collaboration started. And they don't know — yet! — whether they care to settle in and read a history of BSP. You haven't given them a reason to care yet. All of that material should come later.

Why should the reader care? You're the author, you know that best, but I guess it goes something like: we want Scala to have good IDE support and editor support. BSP enables that. Metals and IntelliJ already speak BSP, but there's this limitation and that limitation because sbt didn't speak BSP yet. Now that sbt speaks BSP, users will see the following improvements that will help them get their work done. Here's how you can try it yourself, and here's any especially important caveats.


Bloop still offers many advantages compared to sbt server. It can serve several build clients, on different projects, and run the requests concurrently. It also supports DAP, the Debug Adapter Protocol, which provides code editors with the ability to debug applications and evaluate code at runtime.

Choosing Bloop or sbt as the build server depends on the project you are working on and the developer experience you are looking for. In the following paragraph we describe the main characteristics of using sbt as a build server.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be nice to contrast the below to what you get when you use bloop as a build server.

@adpi2
Copy link
Member Author

adpi2 commented Oct 26, 2020

Thanks @SethTisue and @martijnhoekstra for your suggestions. I pushed an update of the blog post.

@adpi2
Copy link
Member Author

adpi2 commented Oct 27, 2020

@sjrd Could you review the last commit before merging?

Copy link
Member

@sjrd sjrd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two suggestions for the intro.

@sjrd sjrd merged commit a96952c into scala:master Oct 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants