5 ms·

I attribute this to the fact that Kotlin was developed by the same team that created IntelliJ, and fantastic IDE support was a requirement from day zero. A big

I attribute this to the fact that Kotlin was developed by the same team that created IntelliJ, and fantastic IDE support was a requirement from day zero. A big part of why Kotlin works is because IDE support is so fantastic now. And likewise, a lot of the reasons Java ties developers' hands is because there was no guarantee about the IDE they would be using. As a trivial example, declaring variables. In Java, you have `final String foo = "bar";` while in Kotlin you can just say `val foo = "bar"`. They type is implied, but if you aren't sure, you can hover over `foo` and the IDE will tell you what the type is, so there's no longer a reason to type it out every time. Also, you can now have multiple classes in a single file. When Java was created, the one-class-per-file rule made finding the source code to a file easy; just do a `find` for `Classname.java`. But with a modern IDE, you can just command-click an instance and be taken to the source code automatically. Java's boilerplate is meant to make code discoverable, but the Kotlin IDE does that work for you, allowing developers to be more flexible.

twobitshifter 4y ago
I think many of us have stale conceptions of Java formed decades ago. But some time ago, Java started evolving quickly and now isn’t that far off from Kotlin. When Kotlin started, that was not the case. People still think of Java as stuffed full of wordiness, slow startup, garbage collection seizing up code, and long compile times, but that’s all in the past.
- qw 4y ago
  I think you are right. Many also got their first experience with Java in school or at their first job. Languages like Java/C# can seem intimidating at first.
- dinvlad 4y ago
  I'm not so sure about the slow startup claim here :-) I.e. Spring apps still take several MINUTES to start (with Java or Kotlin...) Please correct me if I'm wrong, but I don't think Java's dependency discovery mechanism has evolved much (if at all) from prehistoric times (hence, the slow startup remains). Although GraalVM sort of addresses that.
vips7L 4y ago
Perfectly valid Java for the last 4 years: var foo = “bar”;
- mathisonturing 4y ago
  that's not final though, like val in Kotlin
  - spullara 4y ago
    we talked about having val as well in java but it just wasn't that interesting. if for some reason you think you need final you can use final var.
- pwdisswordfish9 4y ago
  Java supports curly quotes?
  - vips7L 4y ago
    iOS got me again!
armchairhacker 4y ago
This is funny because the other language I think of which wouldn’t be nearly as popular without an IDE, is Java. Especially older versions of Java. Java is way too verbose to be workable if I have to write out all of the class declarations and anonymous classes and “equals/hashCode/toString” boilerplate and “ExtremelyLongClassName foo = bar.extremelyLongMethodName(…)”; and there are too many pitfalls like comparing with “==“ instead of “Object.equals” and implicit null. Except that I don’t have to write out anything or worry about any pitfalls (well, implicit null still hits me sometimes, but @NotNull and @Nullable make it much less common) in IntelliJ. IntelliJ has such powerful and seamless analysis, it does aggressive code folding on Java 7 so that you are looking at code with “var”s and lambdas. It also has built-in support for popular libraries like Spring and Lombok. IntelliJ single-handedly turns Java from a verbose, legacy language into something I could actually recommend and start new projects on (although at that point I usually go with Kotlin). And Eclipse, NetBeans have very deep Java analysis as well. Java may have started off without expecting IDE support but now IDE support is responsible for a large part of its popularity.
- JAlexoid 4y ago
  Yes. You either have a language that is easy or you have tooling to make it easy. If I cannot access documentation for a library/function at a mere tap of a button - that language isn't going into my toolbelt. I have to code in like 5 languages at my dayjob, that's at least 3 different types of semantics for ==. Java, and Kotlin, are great at that. It's the major pitfall for Scala(and a laundry list of others), on the other side(hey implicits and converters, that make even IntelliJ go "wut?"). Those long names in Java are actually a godsend. Give me "int indexInTheArray" over "int x" anyday. Explicitness of Python is also a pleasant thing to work with. People forget that most software is boring website backends, business processes and similar tools. Most devs don't have mental capacity to devote to "the one and only" language+platform+ISA.
  - vendiddy 4y ago
    Are there languages out there that have done both?
  - 4y ago
Alupis 4y ago
> but the Kotlin IDE does that work for you So long as everyone on your team uses IntelliJ, then no problems. But not everyone uses IntelliJ, and now you've written code that is only easy to parse in a particular IDE... For this reason, and being able to read my own code outside of just my IDE (say, in Github, etc), I've found it more necessary to be explicit with my typing in Kotlin for all but the most trivial snippets.
- Jenk 4y ago
  This is not a compelling argument. I'm not going to stop using a powersaw to cut beams just because another contractor refuses to use anything but his handsaw. Besides, reading implicit types has _never_ been an issue on any team or collaboration effort in the 30 years of my programming experience and I find it _really_ hard to believe anyone that claims it is a bonified problem for readability. In fact the complete opposite is true for me, personally, that too much information in front of me becomes noise and the signal gets lost.
  - psd1 4y ago
    "bonified" is a particularly satisfying bone apple tea
    - Jenk 4y ago
      yeah I've no idea why I spelled it that way.
  - derefr 4y ago
    They're not talking about someone using a hand-saw, they're talking about someone using a powersaw from a different manufacturer. Or, y'know, a table saw, or a CNC machine. Kotlin has tight integration with one particular IDE, not with all IDEs; let alone with things that are powerful in ways orthogonal to the ways IDEs are powerful, e.g. Emacs.
- vkou 4y ago
  Eclipse has feature-parity with IntelliJ in this space, it just has questionable usability and performance.
danudey 4y ago
> As a trivial example, declaring variables. In Java, you have final String foo = "bar"; while in Kotlin you can just say val foo = "bar". They type is implied, but if you aren't sure, you can hover over foo and the IDE will tell you what the type is, so there's no longer a reason to type it out every time. This is something I've learned about Groovy that I really like. You can declare variables in multiple ways (terms are my own): foo = 1 # normal assignment var foo = 1 # declared assignment int foo = 1 # typed assignment A lot of our current code used the first "normal assignment" that you would see in shell scripts, Python, whatever. There's nothing interesting about this. I started using the second kind consistently. The "declared assignment" says "I am creating a new variable foo and its value is 1". If you are not creating a new variable (i.e. if the variable exists already) your program fails. This is a great way to ensure you're not overriding variables from earlier in the program or from another scope. My experience tends to be that this throws errors "now" for mistakes you're currently making (at this point in the control flow) by overwriting a variable that existed before. The last is a "typed assignment", where you're not just saying "I am creating a new variable", but specifically the type of variable is important. This errors if you ever try to misuse a variable down the road, and helps with ambiguity. It solves the "somestring = somestring.split()" issue of discounting a variable as the potential issue due to "it can't be this one, that's a string" being right for a while and then wrong for a while (or vice-versa). Anyway, all that to say: not having to specify data types is nice in some circumstances, but I've been leaning into adding data types to my code just to make absolutely sure I know what everything is all the time. Not having to in Kotlin sounds nice, but I hope there's a way to be explicit about everything.
spullara 4y ago
You realize that Java has either released or has in preview most of the Kotlin features? Your example in Java 10+ is: var foo = "bar"; // you can add final if you feel like it You could always have multiple classes in a Java file as long as there was only one public class.
urbandw311er 4y ago
As a long time Visual Studio and C# .Net developer it’s always fun to hear people wax lyrical about these “amazing new” IDE features that have been pretty much standard in the toolchain for more than a decade…

twobitshifter 4y ago

I think many of us have stale conceptions of Java formed decades ago. But some time ago, Java started evolving quickly and now isn’t that far off from Kotlin. When Kotlin started, that was not the case. People still think of Java as stuffed full of wordiness, slow startup, garbage collection seizing up code, and long compile times, but that’s all in the past.

qw 4y ago
I think you are right. Many also got their first experience with Java in school or at their first job. Languages like Java/C# can seem intimidating at first.
dinvlad 4y ago
I'm not so sure about the slow startup claim here :-) I.e. Spring apps still take several MINUTES to start (with Java or Kotlin...) Please correct me if I'm wrong, but I don't think Java's dependency discovery mechanism has evolved much (if at all) from prehistoric times (hence, the slow startup remains). Although GraalVM sort of addresses that.

vips7L 4y ago

Perfectly valid Java for the last 4 years: var foo = “bar”;

mathisonturing 4y ago
that's not final though, like val in Kotlin
- spullara 4y ago
  we talked about having val as well in java but it just wasn't that interesting. if for some reason you think you need final you can use final var.
pwdisswordfish9 4y ago
Java supports curly quotes?
- vips7L 4y ago
  iOS got me again!

armchairhacker 4y ago

This is funny because the other language I think of which wouldn’t be nearly as popular without an IDE, is Java. Especially older versions of Java. Java is way too verbose to be workable if I have to write out all of the class declarations and anonymous classes and “equals/hashCode/toString” boilerplate and “ExtremelyLongClassName foo = bar.extremelyLongMethodName(…)”; and there are too many pitfalls like comparing with “==“ instead of “Object.equals” and implicit null. Except that I don’t have to write out anything or worry about any pitfalls (well, implicit null still hits me sometimes, but @NotNull and @Nullable make it much less common) in IntelliJ. IntelliJ has such powerful and seamless analysis, it does aggressive code folding on Java 7 so that you are looking at code with “var”s and lambdas. It also has built-in support for popular libraries like Spring and Lombok. IntelliJ single-handedly turns Java from a verbose, legacy language into something I could actually recommend and start new projects on (although at that point I usually go with Kotlin). And Eclipse, NetBeans have very deep Java analysis as well. Java may have started off without expecting IDE support but now IDE support is responsible for a large part of its popularity.

JAlexoid 4y ago
Yes. You either have a language that is easy or you have tooling to make it easy. If I cannot access documentation for a library/function at a mere tap of a button - that language isn't going into my toolbelt. I have to code in like 5 languages at my dayjob, that's at least 3 different types of semantics for ==. Java, and Kotlin, are great at that. It's the major pitfall for Scala(and a laundry list of others), on the other side(hey implicits and converters, that make even IntelliJ go "wut?"). Those long names in Java are actually a godsend. Give me "int indexInTheArray" over "int x" anyday. Explicitness of Python is also a pleasant thing to work with. People forget that most software is boring website backends, business processes and similar tools. Most devs don't have mental capacity to devote to "the one and only" language+platform+ISA.
- vendiddy 4y ago
  Are there languages out there that have done both?
- 4y ago

Alupis 4y ago

> but the Kotlin IDE does that work for you So long as everyone on your team uses IntelliJ, then no problems. But not everyone uses IntelliJ, and now you've written code that is only easy to parse in a particular IDE... For this reason, and being able to read my own code outside of just my IDE (say, in Github, etc), I've found it more necessary to be explicit with my typing in Kotlin for all but the most trivial snippets.

Jenk 4y ago
This is not a compelling argument. I'm not going to stop using a powersaw to cut beams just because another contractor refuses to use anything but his handsaw. Besides, reading implicit types has _never_ been an issue on any team or collaboration effort in the 30 years of my programming experience and I find it _really_ hard to believe anyone that claims it is a bonified problem for readability. In fact the complete opposite is true for me, personally, that too much information in front of me becomes noise and the signal gets lost.
- psd1 4y ago
  "bonified" is a particularly satisfying bone apple tea
  - Jenk 4y ago
    yeah I've no idea why I spelled it that way.
- derefr 4y ago
  They're not talking about someone using a hand-saw, they're talking about someone using a powersaw from a different manufacturer. Or, y'know, a table saw, or a CNC machine. Kotlin has tight integration with one particular IDE, not with all IDEs; let alone with things that are powerful in ways orthogonal to the ways IDEs are powerful, e.g. Emacs.
vkou 4y ago
Eclipse has feature-parity with IntelliJ in this space, it just has questionable usability and performance.

danudey 4y ago

> As a trivial example, declaring variables. In Java, you have final String foo = "bar"; while in Kotlin you can just say val foo = "bar". They type is implied, but if you aren't sure, you can hover over foo and the IDE will tell you what the type is, so there's no longer a reason to type it out every time. This is something I've learned about Groovy that I really like. You can declare variables in multiple ways (terms are my own): foo = 1 # normal assignment var foo = 1 # declared assignment int foo = 1 # typed assignment A lot of our current code used the first "normal assignment" that you would see in shell scripts, Python, whatever. There's nothing interesting about this. I started using the second kind consistently. The "declared assignment" says "I am creating a new variable foo and its value is 1". If you are not creating a new variable (i.e. if the variable exists already) your program fails. This is a great way to ensure you're not overriding variables from earlier in the program or from another scope. My experience tends to be that this throws errors "now" for mistakes you're currently making (at this point in the control flow) by overwriting a variable that existed before. The last is a "typed assignment", where you're not just saying "I am creating a new variable", but specifically the type of variable is important. This errors if you ever try to misuse a variable down the road, and helps with ambiguity. It solves the "somestring = somestring.split()" issue of discounting a variable as the potential issue due to "it can't be this one, that's a string" being right for a while and then wrong for a while (or vice-versa). Anyway, all that to say: not having to specify data types is nice in some circumstances, but I've been leaning into adding data types to my code just to make absolutely sure I know what everything is all the time. Not having to in Kotlin sounds nice, but I hope there's a way to be explicit about everything.

spullara 4y ago

You realize that Java has either released or has in preview most of the Kotlin features? Your example in Java 10+ is: var foo = "bar"; // you can add final if you feel like it You could always have multiple classes in a Java file as long as there was only one public class.

urbandw311er 4y ago

As a long time Visual Studio and C# .Net developer it’s always fun to hear people wax lyrical about these “amazing new” IDE features that have been pretty much standard in the toolchain for more than a decade…