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.
What you said would make sense, except they do build a plugin for Eclipse.
Better options would be any language where the stewards are not trying to extract money from you by forcing your IDE choice. Or where they view fostering community good will as being in their best interest. Ex. MS offers an official LS rather than saying "we don't support other IDEs because Visual Studio licenses."
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.
For me, it has basically nothing to do with being open source. Despite all the constant hate about electron apps, I've consistently found VS Code to be much snappier to use than any time I've tried using Jetbrains IDEs (whether on beefy desktop or slimmer laptop), and that's even after disabling a huge number of plugins and features that I don't want. That's not even talking about the actual features of each; I think I just prefer a smaller initial feature set with a rich, well-supported ecosystem of third-party as well as first-party plugins rather than a huge default feature set (which inevitable comes with a bunch of things I don't want) and third-party plugins being mostly an afterthought.
Yeah, I briefly tried using nvim for csharp dev and discovered that even though csharp lsp is open source, the razor lsp integration is not (or was not at the time) and the vscode plugin downloads some proprietary binary.
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.
It doesn't have anything to do with price. The point is that I've invested a lot of time knowing my IDE (vscode) very well. Switching IDEs on the basis of a language which I've never used is a huge leap. You could make that leap a lot easier by allowing me to use it somewhere I'm comfortable first.
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.
Can you elaborate on why you think it’s terrible to read in plaintext compared to other languages? I’ve been writing a lot of Kotlin recently and the only memorable extra hints (compared to other languages/IDEs) I see on IDEA are named parameters, smart casts, and the type of `it`/`this`. Sometimes I browse GitHub from my phone and I find Kotlin code very easy to read.
Huh? Kotlin code tends to be very compact, often functional, and immutable and non-nullable variables (both by default) severely reduce cognitive load when reading code.
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.)
Same here. To be fair, it has some rough edges as it is still a bit cutting edge. But it mostly works great. Worth a look if you need to share code between IOS, Android, Web, and server side.
We use the Fritz2 ui framework which has been built from the ground up with Kotlin-js. It's a reactive framework desigbed around Kotlin features like co-routines and flows. It comes with a nice component framework, great documentation, and has been rock solid for us. Worth a look if you are looking for something different.
We took some risk by betting on this admittedly risky setup one and a half years ago when I had a few junior Android developers that knew Kotlin and we needed a webapp in a hurry. I ran this as an experiment for a few weeks and then realized that I had nothing to worry about: it's fine. We were hitting all our goals. By now we are super productive with this setup and we are adding lots of features, ui polish, etc. every week. Maybe we'll have to switch at some point but so far we're good on not ending up with the usual mess of technical debt that I've come to associate with javascript projects.
Jetpack Compose looks promising. Once IOS support lands, it will be a strong competitor to Flutter and React Native. If you can do without IOS support, it's usable right now. I'm guessing IOS support would be at least another one or two years out.
Multiplatform is great and getting more usable with every release. We have an API client and some other functionality that we use across JVM on our server and kotlin-js. It should just work for kotlin native, IOS, and android as well but we have not used that so far. I'm kind of looking forward to the web assembly compiler becoming usable as well.
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.
Late last year we had some major instability with our main microservices as they didn't properly scale and it wasn't pleasant. The backend codebase was Java. In any case 2 months before that we got a dev with good Kotlin experience (he wrote a book on it) and he offered to rewrite those services in Kotlin as that instability was occurring. It took him about 5 days for each (sometimes less). And in a few weeks we had services which were rock solid. Amazing really how sometimes a person who knows his stuff can make a difference.
How does Kotlin "scale" differently than Java? I mean I'm anything but a Java fan but both languages run on the JVM, so unless your colleague also changed the architecture of those services I don't see how a switch from Java to Kotlin would help at all.
Did he report the issues back to the Kotlin JS team? My experience is that they are quick to respond in Kotlin Slack.
We use it in production and saves us quite some time sharing code with the backend.
I can imagine Kotlin JS takes some effort since it improved a lot but also changed quite a bit throughout the years. Kotlin Slack helped me a lot through this phase.
No idea. I think the demo schedule drove him to find something that he could get working.
To be fair, I think he was fighting not just Kotlin JS but using React within it and his own lack of web technology experience being predominantly an Android dev.
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.
Yeah, but I can not do that without a using the whole project template. Half of all the options in the build file mean nothing to me, much less why they’d need to be there in my starter project.
> 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
This is a terrible suggestion. IntelliJ Community Edition is enormously powerful and more than sufficient for getting started with Kotlin. I've been coding in Kotlin for years and still don't have a reason to pay for IntelliJ (sorry JetBrains!)
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.
Nah. Gradle has its advantages but it's way more complex than building a node project. The Gradle DSL is utterly incomprehensible to anyone that isn't a seasoned Java dev. Honestly, I struggle to think of a language with a more complex build system than Gradle, besides building cpp apps.
Let's not compare Maven to Gradle. One is a stable, rock-solid, decades old declarative build tool with reasonable performance and excellent backward compatibility - the other is a configuration, semantic and maintenance nightmare.
You don't need anything to build a node.js app. If you use typescript then yes you'll want typescript, but honestly the experience out of the box in node is pretty fantastic that you don't need anything else, as far as build goes.
Granted if you are talking frontend browser code then sure webpack, but that tool has been around and stable for many years now.
Added bonus too is browser adoption is way better than ever so you don't really need a transpile either, typescript being the exception.
Not sure I agree. NPM as a technology is actually pretty decent and fast. The biggest issue is that package.json doesn't allow comments. Webpack is shit. But there are good alternatives to it now - primarily esbuild.
I'd take that build system over Java's dog slow build systems any day. Just a shame about the JS ecosystem itself. Too many badly written libraries not written in Typescript (inexcusable these days) with a gazillion dependencies.
The problem isn’t necessarily the quality of gradle or maven but rather that you get one more build dependency, thus increasing complexity of the 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.
All examples in the official docs (bar a few things like custom plugin development) are in Kotlin now. Also the support for the Kotlin build scripts in IDEA itself is a ton better now, it used to break all the time and desync etc but no more.
Gradle certainly isn't great but it's crappiness is overblown especially when comparing it to stuff like npm + webpack.
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.
Technically it might work but you are fighting an uphill battle in terms of documentation, stuff that's just not supported at all, bugs, etc. With Kotlin-js especially, I would strongly recommend to not bother with maven. It's a bit cutting edge and you'll have an easier time doing what everybody else is doing.
If you go the gradle route, of course use the Kotlin Script variety. Gradle is a bit complex and having your build logic written in Kotlin seems like it is the right thing to do.
I like how, last I checked anyway, there was no way to say "install this package" with Gradle; I had to go get the URL first. There might have been a way to do it after first manually adding a repository (maven central or whatever), but I couldn't figure it out quickly.
And then to upgrade to the latest I had to manually go figure out what the latest was, and manually change the line number to the latest version. I did see there's a separate plugin you can install to now add it though, built by a third party, but still.
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.
I’m going to have to really disagree. While XML might be verbose, it’s dead simple and maven is extremely well documented. Gradle on the other hand is cryptic, relies on stack overflow to document it, and breaks your build scripts every release.
Maven to Gradle is a huge improvement, but I think a lot of people here are coming from the JS world. Package.json is incredibly simple compared to Gradle.
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 (reluctantly) agree with pron as well. Kotlin's push to become a multi-platform language -- and escape the JVM -- has taken years, and seems far from 'production ready'. Unfortunately, the facets of Kotlin that most people use and care about like language design, ergonomics, Gradle, coroutines, etc., seem to have suffered as a result of this. In the beginning they were running laps around Java with functional and quality-of-life improvements; in recent years, they've kept up with Java (sealed interfaces, records) while adding a few improvements; Loom and pattern matching will be coming to Java in the near future, and I'm worried it will be a while until Kotlin catches up.
Records is what Java calls data classes which kotlin had since 1.0
I don't think these criticisms really hold water to be honest, though Ron may have a stronger take on this because he works on the Java team on Loom, and Loom is one of the few areas where big JVM upgrades can actually drastically simplify the programming model. Most of the other things Java has been doing are just catching up. The needs of stability and their general culture prevents them moving as fast as the Jetbrains guys did when designing Kotlin.
The Java approach is always "too little, too late". Sealed interfaces are nice, but they only really shine when coupled with switch statements that the compiler checks for exhaustiveness (because that gives you actual sum types).
Unfortunately, that's still in preview in Java 17. Also, Java's decision to only check switch expressions but not switch statements for exhaustiveness still makes their usage error prone.
In Kotlin, sum types (sealed classes) are properly supported today.
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
Readit News
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.
> 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.
> The next thing is also fairly straightforward: we expect Kotlin to drive the sales of IntelliJ IDEA
https://blog.jetbrains.com/kotlin/2011/08/why-jetbrains-need...
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
What you said would make sense, except they do build a plugin for Eclipse.
Better options would be any language where the stewards are not trying to extract money from you by forcing your IDE choice. Or where they view fostering community good will as being in their best interest. Ex. MS offers an official LS rather than saying "we don't support other IDEs because Visual Studio licenses."
There's lots of choices here for compile to JS languages: https://github.com/jashkenas/coffeescript/wiki/List-of-langu...
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.
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.
[1]: https://www.jetbrains.com/fleet/
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.
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.
Dead Comment
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.
If it wasn't for Google giving wind to their sails, the Kotlin ship wouldn't have gone anywhere.
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.)
We use the Fritz2 ui framework which has been built from the ground up with Kotlin-js. It's a reactive framework desigbed around Kotlin features like co-routines and flows. It comes with a nice component framework, great documentation, and has been rock solid for us. Worth a look if you are looking for something different.
We took some risk by betting on this admittedly risky setup one and a half years ago when I had a few junior Android developers that knew Kotlin and we needed a webapp in a hurry. I ran this as an experiment for a few weeks and then realized that I had nothing to worry about: it's fine. We were hitting all our goals. By now we are super productive with this setup and we are adding lots of features, ui polish, etc. every week. Maybe we'll have to switch at some point but so far we're good on not ending up with the usual mess of technical debt that I've come to associate with javascript projects.
Jetpack Compose looks promising. Once IOS support lands, it will be a strong competitor to Flutter and React Native. If you can do without IOS support, it's usable right now. I'm guessing IOS support would be at least another one or two years out.
Multiplatform is great and getting more usable with every release. We have an API client and some other functionality that we use across JVM on our server and kotlin-js. It should just work for kotlin native, IOS, and android as well but we have not used that so far. I'm kind of looking forward to the web assembly compiler becoming usable as well.
I’d just use Clojurescript.
We use it in production and saves us quite some time sharing code with the backend.
I can imagine Kotlin JS takes some effort since it improved a lot but also changed quite a bit throughout the years. Kotlin Slack helped me a lot through this phase.
To be fair, I think he was fighting not just Kotlin JS but using React within it and his own lack of web technology experience being predominantly an Android dev.
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.
I think we can conclude that if you have so prior knowledge, getting it working is much easier.
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).
Also note that `java HelloWorld` looks for classes, so if you are in the same directory as the classfile, .class is not required.
From there add a dependency by editing build.gradle.kts and you will be doing OK in no time.
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
Dead Comment
Granted if you are talking frontend browser code then sure webpack, but that tool has been around and stable for many years now.
Added bonus too is browser adoption is way better than ever so you don't really need a transpile either, typescript being the exception.
I'd take that build system over Java's dog slow build systems any day. Just a shame about the JS ecosystem itself. Too many badly written libraries not written in Typescript (inexcusable these days) with a gazillion dependencies.
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.
Gradle certainly isn't great but it's crappiness is overblown especially when comparing it to stuff like npm + webpack.
[1] https://kotlinlang.org/docs/maven.html#attributes-specific-t...
If you go the gradle route, of course use the Kotlin Script variety. Gradle is a bit complex and having your build logic written in Kotlin seems like it is the right thing to do.
And then to upgrade to the latest I had to manually go figure out what the latest was, and manually change the line number to the latest version. I did see there's a separate plugin you can install to now add it though, built by a third party, but still.
Decades.
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
> 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.
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.
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.
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.
Deleted Comment
I don't think these criticisms really hold water to be honest, though Ron may have a stronger take on this because he works on the Java team on Loom, and Loom is one of the few areas where big JVM upgrades can actually drastically simplify the programming model. Most of the other things Java has been doing are just catching up. The needs of stability and their general culture prevents them moving as fast as the Jetbrains guys did when designing Kotlin.
Unfortunately, that's still in preview in Java 17. Also, Java's decision to only check switch expressions but not switch statements for exhaustiveness still makes their usage error prone.
In Kotlin, sum types (sealed classes) are properly supported today.