Coincidentally I've started using the Haskell LSP around two years ago, and crashing is not one of the issues I've had with it.

Since you mention F#, and C# in your previous comment, are you on the Windows platform? Maybe our experience different because of platform as well. Using GHCup to keep in sync compatible versions of GHC, Cabal and the LSP probably contributed a lot to the consistent feel of the tooling.

I use the Haskell LSP for its autocompletion, reporting compile errors in my editor, and highlighting of types under cursor. There are still shortcomings with it that are annoyances:

* When I open up vim, it takes a good 5-10 seconds (if not a bit more) until the LSP is finally running.

* When a new dependency is added to the cabal file, the LSP needs to be restarted (usually I quit vim and reopen the project).

* Still no support for goto definition for external libraries. The workaround I have to use in this case is to `cabal get dependency-version` in a gitignored directory and use hasktags to keep a tags file to jump to those definitions and read the source code/comments.

The later two have open GitHub issues, so at least I know they will get solved at some point.

I’ve been using f# in production for 4+ years and haven’t used windows in like 15 years.

Speaking of LSP, the lsp standard is developed by Microsoft so naturally any dotnet language will have good lsp support.

> Since you mention F#, and C# in your previous comment, are you on the Windows platform?

Linux Mint.

> Since you mention F#, and C# in your previous comment, are you on the Windows platform?

Since dotnet core (now dotnet 5+), the Microsoft version of dotnet has not been tied to windows outside a few exceptions like old Windows UI libraries (WPF/WinForms) and stuff like WCF once they revived it.

The Haskell LSP crashes less often now than 2 years ago. It isn't perfect yet, but pretty usable for us.

Has Scala gotten better because I remember it being quite painful in the past (tho probably mostly due to language issues more than anything)

The IntelliJ IDEA plugin for Scala is built by Jetbrains, so it has official support. It has its quirks, but so does the Kotlin plugin.

Sbt is better than Gradle IMO, as it has a saner mental model, although for apps you can use Gradle or Maven. Sbat has had some awesome plugins that can help in bigger teams, such as Scalafmt (automatic formatting), Scalafix (automatic refactoring), Wartremover and others. Scalafmt specifically is best in class. With Sbt you can also specify versioning schemes for your dependencies and so you can make the build fail on problematic dependency evictions.

Scala CLI is also best in class, making it comfortable to use Scala for scripting – it replaced Python and Ruby for me: https://scala-cli.virtuslab.org/

Note that Java and Kotlin have Jbang, but Scala CLI is significantly better, also functioning as a REPL. Worth mentioning that other JVM languages hardly have a usable REPL, if at all.

The Scala compiler can be slow, but that's when you use libraries doing a lot of compile-time derivation or other uses of macros. You get the same effect in similar languages (with the exception of Ocaml). OTOH the Scala compiler can do incremental compilation, and alongside Sbt's support for multiple sub-projects or continuous testing, it works fairly well.

Scala also has a really good LSP implementation, Metals, built in cooperation with the compiler team, so you get good support in VS Code or Vim. To get a sense of where this matters, consider that Scala 3.5 introduces "best effort compilation": https://github.com/scala/scala3/pull/17582

I also like Kotlin and sadly, it's missing a good LSP implementation, and I don't think Jetbrains is interested in developing it.

Also you get all the tooling that's JVM specific, including all the profilers and debuggers. With GraalVM's native image, for example, Scala fares better than Java actually, because Scala code relies less on runtime reflection.

I'd also mention Scala Native or ScalaJS which are nice to have. Wasm support is provided via LLVM, but there's also initial support for Wasm GC.

So to answer your question, yes, Scala has really good tooling compared to other languages, although there's room for improvement. And if you're comparing it to any other language that people use for FP, then Scala definitely has better tooling.

SBT is awful. I've never used Gradle, but if SBT is saner then I'm worried. This blogpost is a bit old, but still on-target: https://www.lihaoyi.com/post/SowhatswrongwithSBT.html

All build tools are terrible, and among the available build tools, Sbt is OK.

Let me give you an example … in Gradle, the order in which you specify plugins matters, due to the side effects. Say, if you specify something complex, like Kotlin's multiplatform plugin, in the wrong order with something else, it can break your build definition. I bumped into this right off the gate, with my first Kotlin project.

In Sbt this used to matter as well, but because Sbt has this design of having the build definition as an immutable data structure that's fairly declarative, people worked on solving the problem (via auto-loading), and since then, I've never bumped again into ordering issues.

There are other examples as well, such as consistency. In Sbt there's only one way to specify common settings, and the keys used are consistent. Specifying Java's targeted version, for example, uses the same key, regardless if the project is a plain JVM one, or a multiplatform one.

Sharing settings and code across subprojects is another area where Gradle is a clusterfuck, whereas in Sbt it's pretty straightforward.

Don't get me wrong, Gradle doesn't bother me, and it has some niceties too. Other ecosystems would be lucky to have something like Gradle. But I find it curious to see so many people criticizing it when almost everything else is pretty terrible, with few exceptions.

---

Note that Li Haoyi has great taste, and Mill is looking good, actually. But he also likes reinventing the wheel, and the problem with that for build tools is that standardization has value.

Standardization has so much value for me that I would have liked for Scala to use Gradle as the standard build tool, and for Scala folks to work with Gradle's authors to introduce Scala as an alternative scripting language for it, despite me liking Gradle a lot less. Because it would've made switching and cross-language JVM development easier.

SBT has a learning curve but it also has a nice ecosystem, for example sbt-native-packager is better than its competitors in maven or gradle.

Sbt is too complex and powerful for its own good. I had a love-hate relationship with it, and now I try to avoid it if I can.

I like scala-cli a lot. It's very promising, but I think it's too new to be proclaimed best-in-class yet. Time will tell, and I'm rooting for it.

Well, there's Intellij IDEA with the scala plugin, and it's pretty good. I regularly debug my code in the IDE with conditional breakpoints, etc.

SBT still makes me want to throw the laptop through the window.

In the pre-LSP era, I worked as a novice Scala developer, and I didn most of my Scala work in Emacs with ENSIME. It was pretty good. I imagine the language server is pretty usable by now.

Scala's has made some horrible language compromises in order to live on the JVM in my opinion.

I'd argue that Scala's "compromises" in general make it a better language than many others, independent of the JVM.

But we can talk specifics if you want. Name some compromises.