[Alupis]

> there is almost no difference with latest versions of Java, and the feature gap closes with every release

Java may be implementing features that Kotlin has had since day 1 (or close-to), but Java's syntax will always be what it is due to it's legacy. It's not "modern" syntax, and the way it handles fluent expressions will always be kludgey.

There is nothing special about Kotlin that required IDEA, other than it's convenient. Kotlin is a bundle of libraries and gradle plugins - so it can work on any IDE, including Eclipse or whatever you prefer.

Java's Optional is also much more kludgey than Kotlin's nullable types

Also, generally when writing Kotlin you don't need to make sure your code is interoperable with Java code - usually you are consuming Java code in your Kotlin code... so things like the suite of `@JVMxxx` annotations are not used. If you are writing a library or framework - then obviously concerns are different.

[bcrosby95]

> but Java's syntax will always be what it is due to it's legacy. It's not "modern" syntax, and the way it handles fluent expressions will always be kludgey.

Good. If you're constantly learning something new about your language, there's something wrong with your language. There's 2 good ways to design a language: simple and powerful, or simple and simple.

Modern languages go for complex and powerful, which I personally dislike. Instead of building a simple but powerful language, they build special case upon special case until they have a powerfully complex language. The unfortunate thing is it's only powerful in the blessed ways, hence the complexity, rather than being generally powerful.

All the above is IMHO of course.

[lye]

I really don't think a slightly different syntax is enough of an argument to bring a separate language, introduce another massive dependency (and another vendor) into your supply chain, and create additional problems with hiring people, but to each their own.

I don't mean Optional, it was never intended for widespread use, according to its own author. It's solvable by using annotations; uber has a solution that allows you to only annotate nullable fields, and the rest is assumed to be (and checked at runtime) as not null. There are never that many nullable fields in sanely designed applications.

Writing Kotlin in other IDEs is about as good as writing it in vim. Java experience is closer to the same level regardless of which of the big three (or two…) you prefer.