4 ms·

Tangentially related: If a talented folks out there could please help out with (to the best of my knowledge) the only LSP for Kotlin out there[0], that would be

Tangentially related: If a talented folks out there could please help out with (to the best of my knowledge) the only LSP for Kotlin out there[0], that would be amazing! I'm really attracted to Kotlin as a language[1], but, last I checked, IntelliJ is the only way to get great tooling for Kotlin, which is a show stopper for me since I've invested a lot into my neovim config. [0] https://github.com/fwcd/kotlin-language-server/projects/1 https://github.com/fwcd/kotlin-language-server/projects/1 [1] What attracts me to Kotlin is that it is actually statically typed (ruling out Python/JS/TS), with a relatively expressive type system (ruling out Golang), great type inference, not verbose (ruling out Java), not too involved with low level details (ruling out Rust), not too steep of a learning curve (ruling out Rust again), and a great cross-platform community (ruling out Swift).

ZeroGravitas 5y ago
I guess you're aware but the Jetbrains folks (who do Kotlin and the IDE range) have been a bit cold towards LSP since it's basically commodifying their USP for their IDEs (rich, language specific integration) which is why kotlin LSP is a bit of a no man's land.
- Tmpod 5y ago
  Yeah, that's true. I can see their reasoning, but I'd hope they wouldn't be so cold.
- zozbot234 5y ago
  Their USP is native, efficient tooling for something that's usually implemented in managed platforms like Electron/JS or the JVM. They would in fact benefit from a rich LSP ecosystem, since their tooling would be more easily applicable across languages.
  - ZeroGravitas 5y ago
    I don't use them, but aren't their IDEs still JVM?
    - tikkabhuna 5y ago
      Yes. They use their own packaged version of the JVM.[1] [1] https://confluence.jetbrains.com/display/JBR/JetBrains+Runtime https://confluence.jetbrains.com/display/JBR/JetBrains+Runti...
    - zozbot234 5y ago
      That's their existing (and open) codebase, but I was referring to their recently announced new IDE product called Fleet.
      - krageon 5y ago
        Fleet can't be their USP, because it doesn't exist.
  - iainmerrick 4y ago
    Their USP is native, efficient tooling Why is Android Studio so slow, then?
- davidatbu 5y ago
  Yes, I'm aware.
Tmpod 5y ago
Yeah that is my pain point with Kotlin. I really like it, but the (pretty inexistent) non-JetBrains tooling is a deal breaker for me.
mike_hearn 5y ago
It seems you could also work on the IdeaVim plugin instead? NB: Using the compiler that way probably isn't the right way to go. IntelliJ is somewhat modular. You could parse Kotlin into PSI and then re-use parts of the Kotlin IDE plugin in headless mode. Other JB products do this e.g. Qodana so you don't really need the GUI to be running to do IDE type stuff with it.
- davidatbu 5y ago
  > IdeaVim I really should try that out more. But from my limited foray into using vim emulation: it's not perfect + I really don't like how resource intensive and slow IDEs are + it's not just using vim text navigation, but my neovim plugins, tmux, ripgrep, fdfind, etc. > You could parse Kotlin into PSI and then re-use parts of the Kotlin IDE plugin in headless mode I currently don't have the bandwidth to look into this kinda stuff, hence my call-to-action for "talented folks" :)
  - mike_hearn 5y ago
    Right, but part of why IDEs are resource intensive is they're doing a lot of analysis of the code. If you write an LSP you'll have the same issue because the same work has got to get done somewhere.
    - davidatbu 5y ago
      It's true that some LSPs are resource intensive too. But in my experience, the "little things" like opening the editor/IDE, and new files, quickly/instantaneously tend to be better with neovim rather than IDEs. I'd love to hear about others' experiences about this though!
nonbirithm 5y ago
I once had the idea of implementing an LSP server for Kotlin/Java by embedding it as an IntelliJ plugin and backgrounding the IDE while doing the actual coding in Emacs. It kind of worked, but once I stopped needing to use Java for my job it became too much of a hassle to flesh out. https://github.com/Ruin0x11/intellij-lsp-server https://github.com/Ruin0x11/intellij-lsp-server
- davidatbu 5y ago
  Nice!
matklad 5y ago
> which is a show stopper for me since I've invested a lot into my neovim config. Level of confidence just 0.4, but, if you invested the same amount of time into IntelliJ platform, you might have got more out of it. The “advanced semantic features” rabbit whole is as deep as “advanced vim”, it’s just less popular :-)
- davidatbu 5y ago
  If you can share more about your reasoning here, or share blog posts etc (especially if they compare/contrast with the LSP/vim experience), I'd be very grateful! I've been looking everywhere for evidence of the value-add of IDEs as compared to my neovim_plugins+LSP setup, but haven't found anything that convinced me to do the investment.
  - matklad 5y ago
    I've wrote a bit about this in https://matklad.github.io/2020/11/11/yde.html https://matklad.github.io/2020/11/11/yde.html Some specific things which IntelliJ brings to me: 1. Rich refactors -- things like "change signature" are a huge time saver in big codebases. LSP still can't do interactive refactors which require user input. 2. Structural Search Replace -- you can grep and sed sourcecode by matching on AST and semantic information. 3. Significantly more polished basic features. When I search for a thing in VS Code, I get a flat list of 20 occurrences. When I search for a thing in IntelliJ, I have 20 occurrences, but I immediately see that 12 come from tests, and, among the remaining 8, I can clearly identify 2 write and 6 reads, and it's writes I care about. 4. Significantly better integration with language specific tooling. When I want to run a custom command in VS Code, I open terminal and type `cargo run --package foo --bin bar`. In IntelliJ, I press a shortcut and get auto-completion not only for general cargo command, but for project specific things as well (eg, IntelliJ knows that `foo` package exists and completes that). 5. Local history -- rather than maintaining a hard-to-visualize and unintuitive undo-tree, IntelliJ transparently remembers all transient version of a file and shows you a fine-grained "git log" with diffs and such. 6. Merge tool that understands semantics of the language and can resolve a lot more conflicts automatically (though, to be fair, the actual Git interface still is not as good as magit) 7. A lot of polished "small things". IntelliJ helps a lot with adding punctuation, placing the cursor in the right position and doing other small editing tasks. Subjectively, it significantly reduces the cognitive load for just typing the code in. I guess, the overall thing here is not so much as some big, flashy things, but rather than a myriad of small, polished details. Like vim has a dedicated command/keysequence for anything, IntelliJ exploits any semantic information it can get from the sourcecode to be helpful.

ZeroGravitas 5y ago

I guess you're aware but the Jetbrains folks (who do Kotlin and the IDE range) have been a bit cold towards LSP since it's basically commodifying their USP for their IDEs (rich, language specific integration) which is why kotlin LSP is a bit of a no man's land.

Tmpod 5y ago
Yeah, that's true. I can see their reasoning, but I'd hope they wouldn't be so cold.
zozbot234 5y ago
Their USP is native, efficient tooling for something that's usually implemented in managed platforms like Electron/JS or the JVM. They would in fact benefit from a rich LSP ecosystem, since their tooling would be more easily applicable across languages.
- ZeroGravitas 5y ago
  I don't use them, but aren't their IDEs still JVM?
  - tikkabhuna 5y ago
    Yes. They use their own packaged version of the JVM.[1] [1] https://confluence.jetbrains.com/display/JBR/JetBrains+Runtime https://confluence.jetbrains.com/display/JBR/JetBrains+Runti...
  - zozbot234 5y ago
    That's their existing (and open) codebase, but I was referring to their recently announced new IDE product called Fleet.
    - krageon 5y ago
      Fleet can't be their USP, because it doesn't exist.
- iainmerrick 4y ago
  Their USP is native, efficient tooling Why is Android Studio so slow, then?
davidatbu 5y ago
Yes, I'm aware.

Tmpod 5y ago

Yeah that is my pain point with Kotlin. I really like it, but the (pretty inexistent) non-JetBrains tooling is a deal breaker for me.

mike_hearn 5y ago

It seems you could also work on the IdeaVim plugin instead? NB: Using the compiler that way probably isn't the right way to go. IntelliJ is somewhat modular. You could parse Kotlin into PSI and then re-use parts of the Kotlin IDE plugin in headless mode. Other JB products do this e.g. Qodana so you don't really need the GUI to be running to do IDE type stuff with it.

davidatbu 5y ago
> IdeaVim I really should try that out more. But from my limited foray into using vim emulation: it's not perfect + I really don't like how resource intensive and slow IDEs are + it's not just using vim text navigation, but my neovim plugins, tmux, ripgrep, fdfind, etc. > You could parse Kotlin into PSI and then re-use parts of the Kotlin IDE plugin in headless mode I currently don't have the bandwidth to look into this kinda stuff, hence my call-to-action for "talented folks" :)
- mike_hearn 5y ago
  Right, but part of why IDEs are resource intensive is they're doing a lot of analysis of the code. If you write an LSP you'll have the same issue because the same work has got to get done somewhere.
  - davidatbu 5y ago
    It's true that some LSPs are resource intensive too. But in my experience, the "little things" like opening the editor/IDE, and new files, quickly/instantaneously tend to be better with neovim rather than IDEs. I'd love to hear about others' experiences about this though!

nonbirithm 5y ago

I once had the idea of implementing an LSP server for Kotlin/Java by embedding it as an IntelliJ plugin and backgrounding the IDE while doing the actual coding in Emacs. It kind of worked, but once I stopped needing to use Java for my job it became too much of a hassle to flesh out. https://github.com/Ruin0x11/intellij-lsp-server https://github.com/Ruin0x11/intellij-lsp-server

davidatbu 5y ago
Nice!

matklad 5y ago

> which is a show stopper for me since I've invested a lot into my neovim config. Level of confidence just 0.4, but, if you invested the same amount of time into IntelliJ platform, you might have got more out of it. The “advanced semantic features” rabbit whole is as deep as “advanced vim”, it’s just less popular :-)

davidatbu 5y ago
If you can share more about your reasoning here, or share blog posts etc (especially if they compare/contrast with the LSP/vim experience), I'd be very grateful! I've been looking everywhere for evidence of the value-add of IDEs as compared to my neovim_plugins+LSP setup, but haven't found anything that convinced me to do the investment.
- matklad 5y ago
  I've wrote a bit about this in https://matklad.github.io/2020/11/11/yde.html https://matklad.github.io/2020/11/11/yde.html Some specific things which IntelliJ brings to me: 1. Rich refactors -- things like "change signature" are a huge time saver in big codebases. LSP still can't do interactive refactors which require user input. 2. Structural Search Replace -- you can grep and sed sourcecode by matching on AST and semantic information. 3. Significantly more polished basic features. When I search for a thing in VS Code, I get a flat list of 20 occurrences. When I search for a thing in IntelliJ, I have 20 occurrences, but I immediately see that 12 come from tests, and, among the remaining 8, I can clearly identify 2 write and 6 reads, and it's writes I care about. 4. Significantly better integration with language specific tooling. When I want to run a custom command in VS Code, I open terminal and type `cargo run --package foo --bin bar`. In IntelliJ, I press a shortcut and get auto-completion not only for general cargo command, but for project specific things as well (eg, IntelliJ knows that `foo` package exists and completes that). 5. Local history -- rather than maintaining a hard-to-visualize and unintuitive undo-tree, IntelliJ transparently remembers all transient version of a file and shows you a fine-grained "git log" with diffs and such. 6. Merge tool that understands semantics of the language and can resolve a lot more conflicts automatically (though, to be fair, the actual Git interface still is not as good as magit) 7. A lot of polished "small things". IntelliJ helps a lot with adding punctuation, placing the cursor in the right position and doing other small editing tasks. Subjectively, it significantly reduces the cognitive load for just typing the code in. I guess, the overall thing here is not so much as some big, flashy things, but rather than a myriad of small, polished details. Like vim has a dedicated command/keysequence for anything, IntelliJ exploits any semantic information it can get from the sourcecode to be helpful.