Whilst support for the language server protocol has been requested previously, would it be possible to reconsider official support for Visual Studio Code? VSCode has been ranked number 1 amongst the most popular IDEs on stackoverflow and could massively benefit Kotlin adoption.
This would not only be beneficial to developers using this editor, but could drag a lot of developers to IDEA when seeking out for a full-blown IDE eventually.
Support for Visual Studio Code is exactly the same thing as support for Language Server Protocol.
I don’t quite see how support for Visual Studio Code could help drag developers to IDEA. I think the effect of providing that support will be exactly the opposite.
If Kotlin is intended to replace Java at a similar scale, support for different tooling is essential to sustain the adoption. I find IDEA to be an absolutely amazing IDE (honestly the best free IDE around), but many developers will simply not give up the tools they are familiar with just to try a new language. Once they discover that Kotlin is a much nicer language to work with than Java, they are much more likely to move to an ecosystem where Kotlin is perfectly integrated.
You could replace the current Eclipse plugin by a language server providing a very basic level of Kotlin support to attract developers outside of the IDE world and then point them towards first-class support for refactoring, different frameworks and much more in IDEA.
I can fully understand that JetBrains is not willing to spend money to drag users from IntelliJ away. On the other hand they are doing exactly that with the Eclipse Plugin (although it is a very small team, as far as I know).
Maybe the best thing would be, if the community would create a language server protocol implementation. That would help Eclipse and VS Code users.
There is one already. GitHub - fwcd/kotlin-language-server: Kotlin code completion, linting and more for any editor/IDE using the Language Server Protocol
Also, the situation with Eclipse and Visual Studio Code is different. Over the years, the Eclipse ecosystem has gained a huge array of integrated tools, and many such tools have become essential parts of the development process at many organizations; people simply cannot afford to lose those integrations. With Visual Studio Code, the situation is different: the desire to use VS Code rather than IntelliJ IDEA is a matter of personal preference, nothing else, and we do not want to encourage people whose personal preference is not to use JetBrains development tools.
Well, Java has reached Java’s level of popularity without Sun or Oracle ever investing anything into the development of alternative IDEs or support in alternative text editors. C#, same thing, Swift, same thing.
Support for different tooling is good to sustain the adoption indeed, but there is no reason why the support has to be provided by JetBrains.
Well, NetBeans was really good few years ago. I had to move to IDEA because better support of alternative languages and gradle. But development seems to be dead at the moment.
Also I think that it is better to have one IDE with great support, than few different IDEs with average support. Gives other a quality level to refer to.
I agree with this especially with regard to the Kotlin eclipse plugin. However, you do not make money with developing a programming language. It only costs money. Sun hoped they could make money with java, but in the end Java did not help them at all fighting against their losses in their server business. For that reason programming languages and compiles are made by companies that sell some OS such as Microsoft or Apple to support their platform or by companies that indirectly profit from supporting some programming lanague such as Oracle, because many Java server side applications use Oracle databases.
For a company like JetBrains it is very important that their source of income remains undamaged. Otherwise the company might disappear and their language as well. Maybe, Google decides to fight against Oracle by acquiring JetBrains and use Kotlin as their arm against the domination of Java. Then they might pull money into developing first class Kotlin plugins for eclipse and Visual Studio Code. But that is another story (and I won’t mind if it becomes true one day as the chance to using Kotlin at work would rise significantly ;-)).
In other hand, having a Language Server can give the road to the cloud IDEs. Such as Eclipse Che, that enforced by RedHat and Co.
The progress is never stops. And today’s trends is in moving to clouds more and more in any aspects. Even in code production.
One more use case we have recently in our application.
To configure complex custom logic we develop nice DSL in Kotlin. But customers become want to editing this DSL by self. They are don’t want to use IDE at all, but our’s application interface only.
With language server we will can to make editor in place with editing powers almost like in big IDE.
But without it we can only embed CodeMirror. It solve part of problems, but not all. And ebedding is not easy task for this component. If want to want to give functional interface to customers.
With Visual Studio Code, the situation is different: the desire to use VS Code rather than IntelliJ IDEA is a matter of personal preference, nothing else, and we do not want to encourage people whose personal preference is not to use JetBrains development tools.
FWIW, this sounds like Strategy Tax to me.
What’s best for Kotlin may at times be in tension with what’s best for JetBrains. From the perspective of what could help Kotlin, it wouldn’t surprise me to discover that Kotlin could benefit somewhat from VSCode support. I don’t have any trouble believing it might not benefit JetBrains.
@diathesis Thanks for sharing the link - I’ve never heard the term “Strategy Tax” before.
You only have to look at Scala to see how hard it is to make money from a programming language. Typesafe should have been the commercial entity driving Scala, but now it is called Lightbend and tries to make money with Java software like Lagom, just like Pivotal does with the Spring Framework. They still contribute to Scala, but I think Scala is no longer what they hope to earn a relevant part of their money with.
Remembering this, I think that kotlin community is interested in keeping JetBrains and kotlin team afloat. If VS code plugin contradicts to JB financial strategy, then it should be developed by community.
I’ve recently moved to VS Code from atom and I am quite satisfied with it for auxiliary tasks, but it definitely lacks the level of complexity of full IDE like IDEA.
Does it have context aware auto-complete and refactoring? Maybe I’ve missed something?
Yes, it does. In fact, the reason why language servers were used in the first place, is because context-aware AST analysis is potentially computationally intensive and should be outsourced in a separate process - thus keeping the editor running smooth.
Refactoring is nowadays just a matter of support - it allows you to rename, move refactor, extract methods and variables and much more (officially these features are supported by C, C++, C#, Java and TypeScript, but in the end it mostly depends on how much of the language server protocol has been implemented)
It is exactly this response that is why my company isn’t going to adopt Kotlin for JavaScript apps. As great as Kotlin is, I can’t afford to have my fate and the fate of my clients bound up with JetBrains. This is a classic walled-garden vendor lock-in strategy that the whole world is moving away from.
Of course I would be willing to pay for first class support for my team if it adds more business value than forcing me into yet another annual license subscription, by holding my project ransom. This business model is scary and outdated IMO.
For the record, what you’re doing with Java and Android is great. Providing basic service in the open source version, and selling an enhanced experience for premium clients who want to buy it. If you do the same with JS we’ll abandon typescript for Kotlin in a heartbeat.
Sorry, I’m not sure I get your point. Kotlin/JS is fully open-source, and supported in the (free and open-source) IntelliJ IDEA Community Edition. How exactly is that different from what we’re offering with Java and Android?
Actually, JavaScript is marked as “SUPPORTED ONLY IN ULTIMATE EDITION” on the comparison page: JetBrains Products Comparison
The Node JS plugin is also only supported in Ultimate Edition.
I get no intellisense, Typescript support, or JS interop in CE. I can view and edit JS files, that’s about it (So can VS Code, Sublime, Atom, Notepad++, VIM, and even MS Notepad).
VS Code has JS and Typescript support out of the box, and it’s free and open source. That’s why I’m sticking to VS Code and Typescript for now. (Though I would love to write Kotlin and compile to JS with TS type definitions for running in a Node or Webpack environment)
To summarize, here are two scenarios which would enable me to consider Kotlin:
I seriously love Kotlin, and your IDEs, but I can’t risk tying my clients to a single proprietary IDE that costs $500/year per developer. As a side-note, managing licenses for contractors is a nightmare. Besides, I don’t have any assurances that this IDE would survive a JB meltdown, or that you won’t crank the price to $1,000/year on me 
.
I hope that explains my dilemma a little more. Helping clients avoid vendor lock-in, and problematic dependencies is core to our offerings and business model. If you’d like to talk in more depth, I’d be happy to provide more feedback.
JS interop for Kotlin/JS (navigation/completion between Kotlin and JS code) is simply a non-existing feature at this time.
You can code Kotlin on any device, using any IDE, anywhere, at any time, thanks to the fact that Kotlin source code is stored in plain text files and not in a proprietary binary format. You do have a language server for that. The language server happens to be not developed by JetBrains, but it doesn’t actually restrict you from being able to use it in any way.
In my book, “lock-in” means “you have to pay a single vendor or you can’t use the tool”. You seem to be defining it as “you have pay the vendor or live with maybe slightly worse code completion and no refactorings, until someone else supports these features in a free tool”. I don’t believe your definition to be justified.