I would say this if this step was taking early while Kotlin is still a new language in the market, but I think their late decision to develop an official LSP for Kotlin is because of reasons you just mentioned, but maybe they changed their minds because they saw other benifits including a wide adoption of Kotlin.

It was extremely shortsighted to think that a single language would sway people to IntelliJ instead of just limiting Kotlin’s growth.

https://www.tiobe.com/tiobe-index/

The vertical integration from an Apple product tailored for a specific experience, versus the jigsaw from Linux desktop distributions.

i thought the mainly maintained editor plugin was the one on vs code

I think the overlap between "people who use Eclipse" and "people interested in Kotlin" is pretty small, though. I've only seen Eclipse in use with companies and teams stuck working on legacy applications.

The full quote ...

Instead of working on this behind closed doors for the next year or so and then open sourcing everything, they are releasing some open source now with the intention to open source the rest later. I see no problem with that. Seems pragmatic. More companies should do that.

Bottom line, you are getting free stuff now. Some of it OSS now. All of it OSS later. No need to get upset.

Red-Hat/Microsoft ship Eclipse headless, and Oracle ships Netbeans headless, they don't ship an Apache 2 copy of IntelliJ.

And really, just get the full deal instead of running them headless alongside Electron package.

Previous commenters nailed it -- it's much better to make the LSP generally accessible now -- to use it, to explore, to iterate on the actual feedback and not on the internal echo-chamber instead of cooking it internally for ~one year to make it fully OSS.

And not having to fight an uphill battle with the internal codebase (we have plenty of experience here -- Kotlin itself is fully OSS while IDEA part is mirrored through the internal monorepo) makes wonders.

> smuggles some kind of binary

These are basically IJ parts. No new dependencies, no statistics, no internet access from this code. It is also not obfuscated, so if you really worry about the contents -- any public bytecode decompiler will do.

"The next thing is also fairly straightforward: we expect Kotlin to drive the sales of IntelliJ IDEA. We’re working on a new language, but we do not plan to replace the entire ecosystem of libraries that have been built for the JVM. So you’re likely to keep using Spring and Hibernate, or other similar frameworks, in your projects built with Kotlin. And while the development tools for Kotlin itself are going to be free and open-source, the support for the enterprise development frameworks and tools will remain part of IntelliJ IDEA Ultimate, the commercial version of the IDE. And of course the framework support will be fully integrated with Kotlin."

-- https://blog.jetbrains.com/kotlin/2011/08/why-jetbrains-need...

Why? Two main reasons:

- On the projects I tend to work on, IntelliJ has a habit of breaking its internal configuration a few times a year—not just for me, but for my colleagues as well. When it does, it can take the better part of a day to sort out. Often I end up getting frustrated, deleting anything not under version control, reimporting the project, and end up having to reconfigure all the database connections and other bits manually.

- I also just prefer the more straightforward feel of NetBeans and VSCode. It’s a bit like my old car: less automation, fewer clever electronics. Sure, the new one is objectively better in many ways—but the old one was easier to get out of the snow, and it rarely surprised me.

I begrudgingly use IDEA because it was the only option if you wanted a decent IDE experience. The fwcd VS Code LSP for Kotlin that existed somewhat works, but it's very barebones and hasn't seen much development.

Before there was VS Code, I used Atom, so I've been on the VSC train for about as long as you can get.

I’m not terribly enthused with VS Code either but I’ll probably give this plugin a try, and since this has a standalone LSP it should be reasonable to write Kotlin plugins for other editors.

so being strictly emacs, will really limit your choices, and honestly waste your time

- Java handling of mutability of variables and collections

- Java is still more verbose and with less powerful utilities

- Much better for functional programming

-Some things were done right with all the learnt lessons. E.j. equals Vs ==

I respect preferring free languages. But I love Kotlin

In what sense is Kotlin a proprietary language? It's Apache 2.0 licensed AFAIK. And there are many projects that use Kotlin which are not legacy projects.

But to answer your question that is loaded to the brim with false assumptions/claims directly: https://kotlinlang.org/docs/comparison-to-java.html

Having to use Java again when Kotlin exist

Recent Java features like records, pattern matching, sum types via sealed interfaces have certainly made it a much more ergonomic and modern language.

But having to wrap everything in "class" feels ludicrous to me.

The other ones are lack of explicit null types (meant to be addressed by JEP "Null-Restricted and Nullable Types") and inability to write anonymous types for functions.

For example, something like:

   fun withCallback(
      handler: (A, B, C) -> D
   )

- First class, fully functional closures. - Non-abstract classes and methods are final by default. - Named parameters. - Easy to write iterators via sequence { ... } - First class support for unsigned types.