…but I hate that you can practically only use it with IntelliJ. Trying to use it with just Gradle and vscode is such a pain and maybe even impossible to get anything more than basic syntax highlighting. That is all.
Kotlin has a major benefactor in Jetbrains, buy they are also a major gate keeper with no interest in adding support for anything but IntelliJ. Quite to the contrary, they are actively blocking extensions to their compiler API that would improve development of open language servers.
If you want to develop in Kotlin, you should really just stick with IntelliJ. Or make your peace with not having the greatest language support in your editor.
Honestly, because of the whole situation, I’ve started considering Kotlin as a proprietary product by now.
Not to upset anybody, but after I installed the JetBrains toolbox some months ago, I started having an idea about where their business model is going to. We should be ready to subscribe and pay for the IDEs we use. And considering the amazing work they are doing to maintain the whole ecosystem, it’s worth it. But then I expect customer care for when Gradle builds are broken 🤣
I mean that has been their business model for some time now, just like with most other software nowadays. But unlike most other software their prices are extremely reasonable; when you buy it consecutively for years you get progressive discounts. I actually *need * only one editor but I pay for them all because the cost of the full package is just slightly higher and their IDEs are amazing. A few times a year I use one of the “other” editors for personal projects and such.
I don’t have a problem with people paying for the tools they use. I also “pay” for Neovim in the senst that I donate regularly to the project. My grievance is with the way Jetbrains markets Kotlin as “Open Source” with an “Open Community” when in reality they are blocking access to anyone trying to make it work more smoothly with tools that are not Jetbrains endorsed. That, in my opinion, is openwashing as we have seen for decades from companies trying to act in bad faith, like Microsoft or VMWare.
Have you reviewed this article at all?
https://in-kotlin.com/ide/vscode/setup-vscode-for-kotlin-development/
That article tells you how to set up syntax highlighting and run the command-line compiler by hand, not really comparable to IntelliJ… The article feels like a generic SEO post
I just hate using Gradle with it. Or at all.
10 minutes after migrating from Maven to Gradle…
“Wow, I can do the same I did with Maven with such a small configuration and a few lines of code”.
2 months later…
“Wtf is broken!!? Wtf is going on?”
2 hours later…
“Wtf is broken!!? Wtf is going on?”
Gradle only exists for legal reasons, so maven doesn’t have a monopoly.
Gradle is fantastic, but there is this mantra you have to chant while tinkering with it:
I hate Gradle, I hate Gradle, I hate Gradle, I hate Gradle, I hate Gradle
But once you get it to do whatever you want it’s way more powerful than Maven, since it’s actual code. Also you will never get me to voluntarily define my project structure in XML.
Yes, but at the end there should be a single all lowercase “i love gradle”
Disclaimer: I work for JetBrains.
Genuinely curious, why do you prefer using VS Code over IntelliJ? What do you get there that you don’t get in IntelliJ, or in other words, and what would IntelliJ need to do for you to choose to use it?
Also, have you tried Fleet yet? If you’re a VS Code fan, it might appeal to you.
Not OP, but a pretty common reason is having a super-modular and hackable IDE that can be used to develop pretty much anything. Everything is JSON-configurable, all editors are webviews, so adding stuff like HTML rendering in Jupyter notebooks is almost trivial from a technical perspective. Fleet might be a step in the right direction, but still feels like a layer on top of IntelliJ, which is a beast in of itself, plus it is closed-source.
Also the approach of decoupling editors from the language support via LSP might be one of the biggest innovations in this space in recent years, IMO. Having a widely adopted and open protocol for language support effectively made Neovim, Emacs etc. a viable choice. It has spawned several high-quality LSP implementations, often directly supported by the compiler vendors, e.g. clangd or rust-analyzer.
Arguably Microsoft has been monetizing a bunch of services on top of VSCode too and they haven’t always stuck to their own principles (see Pylance, a closed-source language server that only runs in official VSC builds), but the LSP itself was still a pretty big net positive.
