Probably because JetBrains only recently added native LSP to IntelliJ[0] etc.
Given that writing anything in Java/Kotlin basically requires the use of IntelliJ, it’s not really surprising that a language built on top of Truffle and GraalVM, all Java technologies, would ship with an IntelliJ plugin, _but not_ an LSP. Because such an LSP would have been useless in the primary IDE used by the language developers.
So if you wanna blame anyone, blame JetBrains for deliberately making hard to use LSPs with their IDE. Presumably to build a moat around their plugin ecosystem.
The experience with LSPs is quite underwhelming compared to what a native language plugin in IntelliJ can do. That isn’t to say the approach is bad, but it’s definitely a trade off.
How come? I don't know anything in say, pycharm, that can't be done with a LSP server and plugins. But that's probably because I don't know enough so I'm curious about what limitations an LSP would involve!
Refactorings are one example where LSP can’t match IntelliJ. A language server also takes far more skill and effort to implement than the equivalent IntelliJ plugin, where much of the heavy lifting is done by the IntelliJ framework. And you still need at least a lightweight plugin for each supported editor. That’s why a language server isn’t necessarily the best place to start but hard to avoid in the long run.
Given that writing anything in Java/Kotlin basically requires the use of IntelliJ, it’s not really surprising that a language built on top of Truffle and GraalVM, all Java technologies, would ship with an IntelliJ plugin, _but not_ an LSP. Because such an LSP would have been useless in the primary IDE used by the language developers.
So if you wanna blame anyone, blame JetBrains for deliberately making hard to use LSPs with their IDE. Presumably to build a moat around their plugin ecosystem.
[0] https://blog.jetbrains.com/platform/2023/07/lsp-for-plugin-d...