Apparently they refuse to support the most popular web IDE because Kotlin for JS is really about selling IDEA licenses. Fair enough, but it means I don't suggest Kotlin for anything except as a Java alternative and Android.
There's better options from companies that are less adversarial to their community.
If I'm understanding correctly, the thing you found offensive in that comment was the JetBrains employee talking about "dragging" people to IDEA. If that's the case, it's important to note that the notion was first suggested by the OP:
> 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.
In this context, the JetBrains employee was not saying "it won't sell licenses and therefore we won't do it", they were saying "this won't do what you think it will do".
JetBrains is a company, and like any other company their focus will tend to lean toward where the money is. But my experience with Kotlin over the last several years is that JetBrains is very responsive to the community and their needs.
Does the LSP implementation [1] linked by the JetBrains employee in that thread not work? It pushed a new minor version release a little over a week ago.
It seems pretty reasonable to me for them to not pay employee salaries to build a plugin for a competing product, especially when they already provide a comprehensive IDE solution available for free (in both senses). What other companies are doing that? I don't mean that as a challenge. I'd love to know what the better options are.
I'm curious, how do you see this as being adversarial to their community? It's not like they are taking down kotlin language servers, there are community language servers and extensions for kotlin in vscode and they're linked here as well, by jetbrains employees.
They need users to pay for IDEA to survive, so being open about not wanting to spend developer time to make it easier for people not to use IDEA that could be used to make IDEA better seems sensible from a business perspective. Seems like the community stepped up regardless.
on the contrary, I found their response very fair and reasonable. Quoting:
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.
IMO Fleet¹ from JetBrains is their answer to VSC, and hence it doesn't make sense for them to invest in VSC. What people are arguing for is the difference between the interests of JetBrains vs the interests of Kotlin, very similar to the kinds of conversations that went on for early Rust governance.
Programmers spend an inordinate amount of time thinking about languages and tools, but don't want to pay for better ones, even when they are extremely cheap, drastically increase their productivity and save many headaches. Every other week, there is a post on HN complaining about funding open source. One of the few languages offering halfway decent tooling support is bad because... it makes users more dependent on tools? This makes no sense. Same story for Wolfram. If you want nice things, pay for them.
Seems like a no brainer - who wouldn’t want to use an awesome language like Kotlin and have it shared across iOS, Android and Frontend?
However, the actual experience is full of sharp corners. Get ready for nonexistent documentation, hacky plugins, poor debugging support, lack of proper native libraries and head spinning errors.
In general, it feels like doing carpentry using your plumber’s tools.
I use Kotlin without a license. Just the community version of the IDE, they also released an eclipse plugin that is currently unmaintained. But still open source. I think they did their best to help but without hurting their business model.
Groovy has no Netbeans support anymore. Who is to blame. Groovy? Groovy is better as a PL than Kotlin. But Kotlin is no match in terms of performance and pragmatism. I use both instead of Java and I never looked back.
We use Kotlin JS in production and like it quite well. It enabled us to easily share code with the Kotlin backend and Typescript frontend. Kotlin also generates Typescript type definitions which enables us to easily call those Kotlin methods from typescript. The multiplatform vision allows us to compile/share natively code for mobile platforms too.
I also love to see the quickly evolving Jetpack Compose which would enable to write natively executed UI code on most major platforms. (iOS is not there yet and likely depends on new memory model which is currently being developed.)
One of our lead developers at work pushed this for a rush demo job last week (he’s a Kotlin advocate). He spent the week fighting with lack of documentation and has now given up and reverted to plain old javascript.
It's really not that bad. I would start with downloading IDEA and then following the steps to select a Kotlin/Gradle project (make sure to select Kotlin Build Script) which will spit out a "Hello World" basic setup for you.
From there add a dependency by editing build.gradle.kts and you will be doing OK in no time.
> Java feels like I have to develop a whole program just to get my program to run.
Is this about the "pom.xml" files? In the simplest case, they just contain the name and version of the program, the version of Java you want to use, and the names and versions of the libraries you want to use. You would need to specify this somewhere in any language. And yes, sometimes it gets more complicated, if people want to do more complicated things. It's either this, or having a dialog somewhere in IDE that does the same.
People often overcomplicate things, but it usually doesn't need to be so. As an example of a simple Java code, see this: https://gitlab.com/kittenlord/image
Gradle and Maven are both a million times better than whatever constantly changing collection of random stuff you have to use to build a contemporary node project.
Yup, gradle is a huge barrier to entry - esp. with the whole disparity between kotlin dsl and gradle dsl.
At its core, gradle as a task runner is pretty neat. But the layers of abstraction built upon it often make things superhard when you need to deviate from the setup offered by the starters.
While the official docs have started to show examples in both, almost always a stackoverflow answer or online blog post you find while googling is in the other dsl and converting between them is non-trivial.
Kotlin/JS actually does work with Maven [1] – it's just all the MPP and Kotlin/Native stuff that is heavily Gradle-focused. I hope they eventually get to updating the Maven plugins once the multiplatform features stabilize.
I've found Gradle to be very straightforward, intuitive, and easy to use. I switched one of my projects from Maven over to Gradle, and coming from Maven XML, the Grade configuration language/DSL was amazing and a breath of fresh air.
My project is a programming language interpreted, and from the start it was written in multiplatform Kotlin. Then als to this it was trivial to create a web frontend where the entire implementation runs in the browser. All of this is done without a single line of Javascript, which helps in reducing the pain of web development.
The primary implementation is running on the JVM, but almost all code is also reusable in the web version.
It's all open source so anyone that is curious about how this looks like in an actual project is freelance to have a look here. https://kapdemo.dhsdevelopments.com
pron wrote an insightful comment on Kotlin’s future sometime ago, https://news.ycombinator.com/item?id=24197817. He has actively commented on Kotlin this past decade in good faith. The key quote:
> Kotlin's design goals are now contradictory. It seeks to be a low-overhead language, i.e. provide abstractions that don't add overhead over the target platform, give access to all platform capabilities, and at the same time target multiple platforms -- Java, Android, LLVM and JS -- over none of which does Kotlin exert much influence (maybe a bit on Android).
I agree with pron. I don’t see the longevity of the language outside of Android. Too much of drive to use Kotlin focuses on developer experience hype, which is great for starting projects but pretty bad for maintaining them a decade later.
It's well entrenched in server development. The notion that it is Android only is a myth. There are an enormous amount of Kotlin server developers out there. Speaking as someone who has done Java for 25 years and Spring/Spring boot for the last twelve years. The last five of which have been exclusively in Kotlin. I know this market. The Kotlin ecosystem outside of Android is huge. Every Java server framework that still matters supports Kotlin:
Spring, Quarkus, Javlin, Vert.x, etc. It's for a simple reason: Kotlin worked nicely with those frameworks before they even actively started supporting it and people used it for the same reason Android developers started using Kotlin. It's just way nicer to use than Java and there are no downsides to using Kotlin with a framework that is exclusively designed for Java. It just works. So several years ago, all those frameworks started adding Kotlin extension functions to their libraries and designing features specifically for Kotlin users.
Android developers got a little headstart on the transition to Kotlin for two reasons: 1) google had some issues with Oracle that caused the Android version of Java to be stuck on a version without lambda functions for quite some time 2) Android developers frequently end up doing greenfield projects and they'll grab whatever works when that happens. So, about seven years ago, Kotlin was a drop in replacement for Java on Android that had a lot of nice language features that Java simply did not have. Irresistable for Android developers stuck on the Java 5/6 feature set. Google upgraded the java language version used on the platform over time. But most of that happened after they endorsed Kotlin as the main language.
Something similar happened with Spring but just a lot slower. I used Kotlin with Spring 4.x already in 2018. It had absolutely zero kotlin support but it was a nice upgrade nonetheless. Just worked and added a lot of value (data classes, nullability, etc.). With Version 5.x they added a lot of Kotlin support and they've been iterating on that for the last four years.
Be that as it may, but a core benefit of kotlin (as a developer) is that it has actively sought out good design patterns (eg. builders, composition etc.) and codified them into the language. In Kotlin often the best approach is also the most succinct one - which doesn't hold true for most of the platform-native languages (swift probably being an exception).
As long as it keeps doing that, even at the cost of a larger API surface area (or occasional backward incompatibility), I (and I suspect many others) will be quite happy to use it.
I also agree with him, it is the same fate as all guest languages on platforms where they aren't part of the picture of the people driving the platform.
You see this in any platform, not only Java.
On Android there are some Google folks that pushed for it at the expense of updating Android Java to more modern versions, knowingly comparing Kotlin with their pseudo Java.
Actually I am quite surprised that Android 13 is actually going to support a Java 11 LTS (subset of course). Which although commendable that they are finally doing something, flies in the face of the latest version being Java 18, and they could at very least support the latest LTS version.
I wish apple realize that kotlin multiplatform is the real threat to the swift ecosystem, and that they refocus the swift project on making it a true cross-platform language
It exports typescript typing too. We are successfully using it for sharing businesses code from our backend with our frontend! Even models can be shared.
> It exports typescript typing too... Even models can be shared.
Do you know if this is possible with Kotlin/JVM, or only Kotlin/JS?
We've been sharing models via Kotlin/JVM -> Open API Spec -> Open API Generator, which is far from perfect or painless, and I was looking at alternatives like https://github.com/ntrrgc/ts-generator.
This. Kotlin is a great language with a lot of potential, but JB keeps locking it away in their own ecosystem. I used to do stuff with it before but this attitude has driven me away.
Can Rust replace C or C++ yet, atleast for green field projects? Never liked either in school but always felt bad never getting into low level code after my systems classes. Hoping I could just learn Rust one day instead.
Svelte apps aren't written in JS but in Svelte's own component syntax files. It's "HTML" but all the parts are extended (JS -> reactive, HTML -> directives, CSS -> scoping) and it needs its own compiler to transform the source to something everything else understands.
[+] [-] esprehn|4 years ago|reply
Apparently they refuse to support the most popular web IDE because Kotlin for JS is really about selling IDEA licenses. Fair enough, but it means I don't suggest Kotlin for anything except as a Java alternative and Android.
There's better options from companies that are less adversarial to their community.
[+] [-] lolinder|4 years ago|reply
> 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.
In this context, the JetBrains employee was not saying "it won't sell licenses and therefore we won't do it", they were saying "this won't do what you think it will do".
JetBrains is a company, and like any other company their focus will tend to lean toward where the money is. But my experience with Kotlin over the last several years is that JetBrains is very responsive to the community and their needs.
[+] [-] nirvdrum|4 years ago|reply
It seems pretty reasonable to me for them to not pay employee salaries to build a plugin for a competing product, especially when they already provide a comprehensive IDE solution available for free (in both senses). What other companies are doing that? I don't mean that as a challenge. I'd love to know what the better options are.
[1] -- https://github.com/fwcd/kotlin-language-server
[+] [-] meibo|4 years ago|reply
They need users to pay for IDEA to survive, so being open about not wanting to spend developer time to make it easier for people not to use IDEA that could be used to make IDEA better seems sensible from a business perspective. Seems like the community stepped up regardless.
[+] [-] zem|4 years ago|reply
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.
[+] [-] srcreigh|4 years ago|reply
[+] [-] threatofrain|4 years ago|reply
[1]: https://www.jetbrains.com/fleet/
[+] [-] bmc7505|4 years ago|reply
[+] [-] gregkerzhner|4 years ago|reply
However, the actual experience is full of sharp corners. Get ready for nonexistent documentation, hacky plugins, poor debugging support, lack of proper native libraries and head spinning errors.
In general, it feels like doing carpentry using your plumber’s tools.
[+] [-] fithisux|4 years ago|reply
Groovy has no Netbeans support anymore. Who is to blame. Groovy? Groovy is better as a PL than Kotlin. But Kotlin is no match in terms of performance and pragmatism. I use both instead of Java and I never looked back.
[+] [-] ink404|4 years ago|reply
[+] [-] Shadonototra|4 years ago|reply
[deleted]
[+] [-] whateveracct|4 years ago|reply
Kotlin the entire language is about selling IDEA licenses.
Ever tried to read Kotlin in plaintext? It's terrible. The language makes you need the IDEA hints they give you to read it.
[+] [-] jurmous|4 years ago|reply
I also love to see the quickly evolving Jetpack Compose which would enable to write natively executed UI code on most major platforms. (iOS is not there yet and likely depends on new memory model which is currently being developed.)
[+] [-] jarl-ragnar|4 years ago|reply
I’d just use Clojurescript.
[+] [-] Aeolun|4 years ago|reply
Getting started with node is a matter of downloading a single binary, writing one js file, and executing it with said binary.
Upgrading that to Typescript is a matter of downloading another binary, and running the two in sequence.
Conversely, Java feels like I have to develop a whole program just to get my program to run.
[+] [-] lokedhs|4 years ago|reply
I think we can conclude that if you have so prior knowledge, getting it working is much easier.
[+] [-] deepsun|4 years ago|reply
2. Compile it to bytecode (.class file): `javac HelloWorld.java`.
3. Run it: `java HelloWorld.class`.
If you want to use other libraries, add `-cp` parameter ("cp" stands for "classpath").
If you want to package your code as a library, run `jar HelloWorld.class` (.jar is basically .zip renamed).
[+] [-] jpgvm|4 years ago|reply
From there add a dependency by editing build.gradle.kts and you will be doing OK in no time.
[+] [-] Viliam1234|4 years ago|reply
Is this about the "pom.xml" files? In the simplest case, they just contain the name and version of the program, the version of Java you want to use, and the names and versions of the libraries you want to use. You would need to specify this somewhere in any language. And yes, sometimes it gets more complicated, if people want to do more complicated things. It's either this, or having a dialog somewhere in IDE that does the same.
People often overcomplicate things, but it usually doesn't need to be so. As an example of a simple Java code, see this: https://gitlab.com/kittenlord/image
[+] [-] saltmeister|4 years ago|reply
[deleted]
[+] [-] paxys|4 years ago|reply
[+] [-] skybrian|4 years ago|reply
[+] [-] InsaneOstrich|4 years ago|reply
[+] [-] lf-non|4 years ago|reply
At its core, gradle as a task runner is pretty neat. But the layers of abstraction built upon it often make things superhard when you need to deviate from the setup offered by the starters.
While the official docs have started to show examples in both, almost always a stackoverflow answer or online blog post you find while googling is in the other dsl and converting between them is non-trivial.
[+] [-] underdeserver|4 years ago|reply
[+] [-] ptx|4 years ago|reply
[1] https://kotlinlang.org/docs/maven.html#attributes-specific-t...
[+] [-] teg4n_|4 years ago|reply
[+] [-] anotherhue|4 years ago|reply
[+] [-] pjmlp|4 years ago|reply
[+] [-] winter_blue|4 years ago|reply
[+] [-] lokedhs|4 years ago|reply
The primary implementation is running on the JVM, but almost all code is also reusable in the web version.
It's all open source so anyone that is curious about how this looks like in an actual project is freelance to have a look here. https://kapdemo.dhsdevelopments.com
[+] [-] hitekker|4 years ago|reply
> Kotlin's design goals are now contradictory. It seeks to be a low-overhead language, i.e. provide abstractions that don't add overhead over the target platform, give access to all platform capabilities, and at the same time target multiple platforms -- Java, Android, LLVM and JS -- over none of which does Kotlin exert much influence (maybe a bit on Android).
I agree with pron. I don’t see the longevity of the language outside of Android. Too much of drive to use Kotlin focuses on developer experience hype, which is great for starting projects but pretty bad for maintaining them a decade later.
[+] [-] jillesvangurp|4 years ago|reply
Spring, Quarkus, Javlin, Vert.x, etc. It's for a simple reason: Kotlin worked nicely with those frameworks before they even actively started supporting it and people used it for the same reason Android developers started using Kotlin. It's just way nicer to use than Java and there are no downsides to using Kotlin with a framework that is exclusively designed for Java. It just works. So several years ago, all those frameworks started adding Kotlin extension functions to their libraries and designing features specifically for Kotlin users.
Android developers got a little headstart on the transition to Kotlin for two reasons: 1) google had some issues with Oracle that caused the Android version of Java to be stuck on a version without lambda functions for quite some time 2) Android developers frequently end up doing greenfield projects and they'll grab whatever works when that happens. So, about seven years ago, Kotlin was a drop in replacement for Java on Android that had a lot of nice language features that Java simply did not have. Irresistable for Android developers stuck on the Java 5/6 feature set. Google upgraded the java language version used on the platform over time. But most of that happened after they endorsed Kotlin as the main language.
Something similar happened with Spring but just a lot slower. I used Kotlin with Spring 4.x already in 2018. It had absolutely zero kotlin support but it was a nice upgrade nonetheless. Just worked and added a lot of value (data classes, nullability, etc.). With Version 5.x they added a lot of Kotlin support and they've been iterating on that for the last four years.
[+] [-] lf-non|4 years ago|reply
As long as it keeps doing that, even at the cost of a larger API surface area (or occasional backward incompatibility), I (and I suspect many others) will be quite happy to use it.
[+] [-] pjmlp|4 years ago|reply
You see this in any platform, not only Java.
On Android there are some Google folks that pushed for it at the expense of updating Android Java to more modern versions, knowingly comparing Kotlin with their pseudo Java.
Actually I am quite surprised that Android 13 is actually going to support a Java 11 LTS (subset of course). Which although commendable that they are finally doing something, flies in the face of the latest version being Java 18, and they could at very least support the latest LTS version.
ART is effectively the KVM.
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] bsaul|4 years ago|reply
[+] [-] The_rationalist|4 years ago|reply
[+] [-] richbell|4 years ago|reply
Do you know if this is possible with Kotlin/JVM, or only Kotlin/JS?
We've been sharing models via Kotlin/JVM -> Open API Spec -> Open API Generator, which is far from perfect or painless, and I was looking at alternatives like https://github.com/ntrrgc/ts-generator.
[+] [-] syzygyhack|4 years ago|reply
Ridiculous take. Waste of a good language frankly.
[+] [-] Tmpod|4 years ago|reply
[+] [-] vletal|4 years ago|reply
[+] [-] math-dev|4 years ago|reply
Swift + Kotlin + Java + C + JS + Lisp + C++ should have you covered for most things
[+] [-] Larrikin|4 years ago|reply
[+] [-] epolanski|4 years ago|reply
> Kotlin/JS provides the ability to transpile your Kotlin code, the Kotlin standard library, and any compatible dependencies to JavaScript.
What does it means "compatible dependencies"?
[1] https://arrow-kt.io/
[+] [-] xrd|4 years ago|reply
Also, what are the pros/cons over using typescript? I personally dislike typescript but used to love Kotlin when I was doing more Android development.
[+] [-] grayrest|4 years ago|reply
Svelte apps aren't written in JS but in Svelte's own component syntax files. It's "HTML" but all the parts are extended (JS -> reactive, HTML -> directives, CSS -> scoping) and it needs its own compiler to transform the source to something everything else understands.
[+] [-] vosper|4 years ago|reply
[+] [-] Svoka|4 years ago|reply