8 ms·

Having used Kotlin on and off for the better part of a decade, the one thing I can say is that their editor support is unrivaled by any other language today. Wh

Having used Kotlin on and off for the better part of a decade, the one thing I can say is that their editor support is unrivaled by any other language today. While Kotlin's build tools leave much to be desired (looking at you, Gradle), their focus on building a "toolable" language was the right thing to lean into. You can add all the fancy type system features you want, but if the IDE does not understand them, convincing users is going to be a hard sell. Whenever I try to get into another language today, the lack of language-aware editing tools are my main source of frustration - specifically, I expect navigation, refactoring and completion to work flawlessly. I know of no other programming language that puts as much effort into context- and structure-aware refactoring - if another language does one day replace Kotlin, it will need to offer a comparable editing experience.

srcreigh 4y ago
Have you used TypeScript? Not only is it better type system than Kotlin, it has great IDE support in VSCode, AND there’s a language server so you can get IDE support in Emacs/vim.
purplerabbit 4y ago
Have you tried TypeScript? My impression having used it in both JetBrains and VSCode is that it achieves basically what you're describing. I similarly get irritated using anything else now.
- randy909 4y ago
  I've used both and Kotlin was a better overall experience for me. TypeScript has weird typing problems far more often due to the underlying runtime being dynamically typed.
  - purplerabbit 4y ago
    What problems in particular have you run into? Genuinely curious.
    - lf-non 4y ago
      While I like TS and it is my primary language currently, having worked with Kotlin in past I find the dev experience with kotlin to much better, esp. if you steer clear of libraries that lean heavily on bytecode weaving, compiler hooks etc. Kotlin's type system is nominative and so while it is not as flexible as typescript (no intersection types, conditional types etc.) it also means that you don't run into those multi-page long type errors which need 5 mins of debugging to figure that some deeply nested object is null where undefined is expected. It is particularly funny when the language server truncates the errors and it becomes impossible to infer the actual issue from the message. Every now and then I find myself extracting things out of objects and adding type annotations to simplify the errors. It is doable, but never needed in Kotlin.
- bmc7505 4y ago
  Types in TS are Turing Complete [1], so any static analysis you build ontop of that language is bound to be unsound or undecidable. You could argue this rarely occurs in practice, but I would prefer a type system that is incomplete but sound and decidable. Incidentally, this issue also affects Java, which is both unsound [2] and undecidable [3]. Kotlin does have a fairly complicated subtyping relation [4], which has caused similar issues in languages like Scala [5], however whether the same issue affects languages based on mixed use-site and declaration-site variance like Kotlin is still an open question and requires further investigation. [1]: https://github.com/microsoft/TypeScript/issues/14833 https://github.com/microsoft/TypeScript/issues/14833 [2]: https://io.livecode.ch/learn/namin/unsound https://io.livecode.ch/learn/namin/unsound [3]: https://arxiv.org/abs/1605.05274 https://arxiv.org/abs/1605.05274 [4]: https://kotlinlang.org/spec/type-system.html#subtyping https://kotlinlang.org/spec/type-system.html#subtyping [5]: https://arxiv.org/abs/1908.05294 https://arxiv.org/abs/1908.05294
  - bottlepalm 4y ago
    So your reason to avoid TypeScript is some very rarely encountered corner case? Talk about perfect being the enemy of the good. No language is perfect. Your comment is absurd, and the citations are pedantic.
  - seanmcdirmid 4y ago
    TypeScript works well because they don’t worry about soundness and completeness. The type system isn’t trying to be perfect, just useful. This scares PL theorists, but I think it has been a very profitable corner of the design space to explore. Variance rarely comes up in Kotlin because they don’t push immutability as much as Scala did. It’s like, there as an option but I’ve used it a total of two times in the last two years of full time Kotlin programming. Compared to typescript, Kotlin is fairly boring, but it is tooled well and is a vast improvement over Java.
thomascgalvin 4y ago
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.
hansonkd13 4y ago
Jetbrains and rust have brilliant refactoring. No idea how it compares to kotlin, but I can confidently move methods to other modules and files, rename anything, navigate to definition with no fear. Auto complete / auto import is also insanely good and is almost to the point where I’m auto completing almost every symbol because the IDE knows what I want precisely. I can’t recommend jetbrains rust support enough.
- radicalbyte 4y ago
  That's a JetBrains thing - they added loads of fantastic refactoring options to Visual Studio for C# which have now largely been integrated into the IDE directly. I've had an all-products subscription for close to a decade now and it's money well spent.
  - sirtomato 4y ago
    Honestly. Every JetBrains IDE is incredible.
  - bitL 4y ago
    ReShaper was what kept JetBrains alive 10+ years ago and Microsoft couldn't release a new version of Visual Studio until ReSharper was ready for it due to how many people used/depended on it.
jahewson 4y ago
> I expect navigation, refactoring and completion to work flawlessly. Same, but this was the case for C# in Visual Studio 20 years ago. > I know of no other programming language that puts as much effort into context- and structure-aware refactoring TypeScript + VSCode do all this and more.
- goto11 4y ago
  C# also have great IDE support in VisualStudio especially with the ReSharper extension. Which is also developed by JetBrains.
- IshKebab 4y ago
  Dart is also extremely good from a tooling point of view.
- williamdclt 4y ago
  what do you have in mind about refactoring support with Typescript and VSCode? Maybe I'm missing something obvious but the only "refactoring" functionalities that VSCode provides me are "rename this variable", "rename this file" and "move this export to a new file" (can't move to an existing file, and can't even chose the name of the new file)
  - sixbrx 4y ago
    In VSCode what's in the refactoring menu depends a lot on what you have selected or under the cursor. For example with a selection of a block of code you should get the "extract to method" menu item appear in the refactoring menu, etc. I don't remember there being quite as many as what IntelliJ has for Java though.
baby 4y ago
Back when I was doing audits, the only languages that really had good IDE support for that were objective-C / swift using XCode. You could get a caller hierarchy and get some sort of recursive dropdown menu to go through the entire call stack, it was magical.
t-writescode 4y ago
I would argue that C# and Visual Studio (and maybe Rider) has as good, if not better tooling integration compared to Kotlin, especially considering nuget and sln files solve the “build system leaves things to be desired” part of your comment. This isn’t to say that Kotlin isn’t absolutely incredible, but I do not want to undersell the pleasure that C# is to work in with its tooling.
Rapzid 4y ago
Last I was looking into Kotlin (couple years ago) they seemed hostile towards efforts to bring a similar level of support to editors outside the Idea family; basically they weren't going to do or support anything that threatened their "walled" garden of Kotlin + Idea. Is that still the case? As a huge fan of Jetbrains products (I maintain a personal IDEA Ultimate subscription) this was still a huge turn off to me. > I know of no other programming language that puts as much effort into context- and structure-aware refactoring Do you mean JVM language? TypeScript, C#, and F# at least come to mind.
- bmc7505 4y ago
  > Do you mean JVM language? TypeScript, C#, and F# at least come to mind. As I mentioned in another comment [1] on this thread, soundness and decidability are non-negotiable for me. Types in C#, F# and TS are all Turing Complete [2], and therefor these languages are tooling-adverse in the sense that static analysis is fundamentally unreliable. [1]: https://news.ycombinator.com/item?id=33329509#33332183 https://news.ycombinator.com/item?id=33329509#33332183 [2]: https://3fx.ch/typing-is-hard.html https://3fx.ch/typing-is-hard.html
  - lmm 4y ago
    > As I mentioned in another comment [1] on this thread, soundness and decidability are non-negotiable for me. Types in C#, F# and TS are all Turing Complete [2], and therefor these languages are tooling-adverse in the sense that static analysis is fundamentally unreliable. How on earth do you consider Kotlin acceptable then? Kotlin's type system has never been shown to be sound or decidable and is visibly a lot more ad-hoc than any of that list (and if by some miracle it was sound or decidable last week, I'm sure whatever new feature they added this week broke it). I suspect the only reason it hasn't been formally proven to be Turing Complete is that Kotlin's developers haven't bothered to write a specification for it - as far as I can see your link's example for C# would translate directly into Kotlin with the same properties.
    - bmc7505 4y ago
      Try it! I certainly have. You may find encoding a typelevel TM or λ-calculus more difficult than it appears... > link's example for C# would translate directly into Kotlin T() is not possible for a generic T in Kotlin.
jbellis 4y ago
I was actually very disappointed to find the kotlin refactorings lagging what for Java in IntelliJ. A few examples: https://youtrack.jetbrains.com/issue/KTIJ-12496/Provide-intention-to-convert-from-extension-function-to-member https://youtrack.jetbrains.com/issue/KTIJ-12496/Provide-inte... https://youtrack.jetbrains.com/issue/KTIJ-10606/Support-moving-a-function-to-an-instance-class https://youtrack.jetbrains.com/issue/KTIJ-10606/Support-movi... https://youtrack.jetbrains.com/issue/KTIJ-5063/Extract-property-does-not-work-on-local-variable-with-no-usages https://youtrack.jetbrains.com/issue/KTIJ-5063/Extract-prope...
ctvo 4y ago
Kotlin has one of the poorer LSP implementations out of the popular JVM languages. Last I tried it was buggy, and slow. Developers are pushed into using JetBrains products directly or indirectly (Android Studios) I suspect leaving the wider ecosystem poorly supported.
- anotherevan 4y ago
  I was evaluating Kotlin for a Spring Boot project a few years ago and would have loved to have programmed in it, but this was exactly why I stuck with Java.

srcreigh 4y ago

Have you used TypeScript? Not only is it better type system than Kotlin, it has great IDE support in VSCode, AND there’s a language server so you can get IDE support in Emacs/vim.

purplerabbit 4y ago

Have you tried TypeScript? My impression having used it in both JetBrains and VSCode is that it achieves basically what you're describing. I similarly get irritated using anything else now.

randy909 4y ago
I've used both and Kotlin was a better overall experience for me. TypeScript has weird typing problems far more often due to the underlying runtime being dynamically typed.
- purplerabbit 4y ago
  What problems in particular have you run into? Genuinely curious.
  - lf-non 4y ago
    While I like TS and it is my primary language currently, having worked with Kotlin in past I find the dev experience with kotlin to much better, esp. if you steer clear of libraries that lean heavily on bytecode weaving, compiler hooks etc. Kotlin's type system is nominative and so while it is not as flexible as typescript (no intersection types, conditional types etc.) it also means that you don't run into those multi-page long type errors which need 5 mins of debugging to figure that some deeply nested object is null where undefined is expected. It is particularly funny when the language server truncates the errors and it becomes impossible to infer the actual issue from the message. Every now and then I find myself extracting things out of objects and adding type annotations to simplify the errors. It is doable, but never needed in Kotlin.
bmc7505 4y ago
Types in TS are Turing Complete [1], so any static analysis you build ontop of that language is bound to be unsound or undecidable. You could argue this rarely occurs in practice, but I would prefer a type system that is incomplete but sound and decidable. Incidentally, this issue also affects Java, which is both unsound [2] and undecidable [3]. Kotlin does have a fairly complicated subtyping relation [4], which has caused similar issues in languages like Scala [5], however whether the same issue affects languages based on mixed use-site and declaration-site variance like Kotlin is still an open question and requires further investigation. [1]: https://github.com/microsoft/TypeScript/issues/14833 https://github.com/microsoft/TypeScript/issues/14833 [2]: https://io.livecode.ch/learn/namin/unsound https://io.livecode.ch/learn/namin/unsound [3]: https://arxiv.org/abs/1605.05274 https://arxiv.org/abs/1605.05274 [4]: https://kotlinlang.org/spec/type-system.html#subtyping https://kotlinlang.org/spec/type-system.html#subtyping [5]: https://arxiv.org/abs/1908.05294 https://arxiv.org/abs/1908.05294
- bottlepalm 4y ago
  So your reason to avoid TypeScript is some very rarely encountered corner case? Talk about perfect being the enemy of the good. No language is perfect. Your comment is absurd, and the citations are pedantic.
- seanmcdirmid 4y ago
  TypeScript works well because they don’t worry about soundness and completeness. The type system isn’t trying to be perfect, just useful. This scares PL theorists, but I think it has been a very profitable corner of the design space to explore. Variance rarely comes up in Kotlin because they don’t push immutability as much as Scala did. It’s like, there as an option but I’ve used it a total of two times in the last two years of full time Kotlin programming. Compared to typescript, Kotlin is fairly boring, but it is tooled well and is a vast improvement over Java.

thomascgalvin 4y ago

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.

hansonkd13 4y ago

Jetbrains and rust have brilliant refactoring. No idea how it compares to kotlin, but I can confidently move methods to other modules and files, rename anything, navigate to definition with no fear. Auto complete / auto import is also insanely good and is almost to the point where I’m auto completing almost every symbol because the IDE knows what I want precisely. I can’t recommend jetbrains rust support enough.

radicalbyte 4y ago
That's a JetBrains thing - they added loads of fantastic refactoring options to Visual Studio for C# which have now largely been integrated into the IDE directly. I've had an all-products subscription for close to a decade now and it's money well spent.
- sirtomato 4y ago
  Honestly. Every JetBrains IDE is incredible.
- bitL 4y ago
  ReShaper was what kept JetBrains alive 10+ years ago and Microsoft couldn't release a new version of Visual Studio until ReSharper was ready for it due to how many people used/depended on it.

jahewson 4y ago

> I expect navigation, refactoring and completion to work flawlessly. Same, but this was the case for C# in Visual Studio 20 years ago. > I know of no other programming language that puts as much effort into context- and structure-aware refactoring TypeScript + VSCode do all this and more.

goto11 4y ago
C# also have great IDE support in VisualStudio especially with the ReSharper extension. Which is also developed by JetBrains.
IshKebab 4y ago
Dart is also extremely good from a tooling point of view.
williamdclt 4y ago
what do you have in mind about refactoring support with Typescript and VSCode? Maybe I'm missing something obvious but the only "refactoring" functionalities that VSCode provides me are "rename this variable", "rename this file" and "move this export to a new file" (can't move to an existing file, and can't even chose the name of the new file)
- sixbrx 4y ago
  In VSCode what's in the refactoring menu depends a lot on what you have selected or under the cursor. For example with a selection of a block of code you should get the "extract to method" menu item appear in the refactoring menu, etc. I don't remember there being quite as many as what IntelliJ has for Java though.

baby 4y ago

Back when I was doing audits, the only languages that really had good IDE support for that were objective-C / swift using XCode. You could get a caller hierarchy and get some sort of recursive dropdown menu to go through the entire call stack, it was magical.

t-writescode 4y ago

I would argue that C# and Visual Studio (and maybe Rider) has as good, if not better tooling integration compared to Kotlin, especially considering nuget and sln files solve the “build system leaves things to be desired” part of your comment. This isn’t to say that Kotlin isn’t absolutely incredible, but I do not want to undersell the pleasure that C# is to work in with its tooling.

Rapzid 4y ago

Last I was looking into Kotlin (couple years ago) they seemed hostile towards efforts to bring a similar level of support to editors outside the Idea family; basically they weren't going to do or support anything that threatened their "walled" garden of Kotlin + Idea. Is that still the case? As a huge fan of Jetbrains products (I maintain a personal IDEA Ultimate subscription) this was still a huge turn off to me. > I know of no other programming language that puts as much effort into context- and structure-aware refactoring Do you mean JVM language? TypeScript, C#, and F# at least come to mind.

bmc7505 4y ago
> Do you mean JVM language? TypeScript, C#, and F# at least come to mind. As I mentioned in another comment [1] on this thread, soundness and decidability are non-negotiable for me. Types in C#, F# and TS are all Turing Complete [2], and therefor these languages are tooling-adverse in the sense that static analysis is fundamentally unreliable. [1]: https://news.ycombinator.com/item?id=33329509#33332183 https://news.ycombinator.com/item?id=33329509#33332183 [2]: https://3fx.ch/typing-is-hard.html https://3fx.ch/typing-is-hard.html
- lmm 4y ago
  > As I mentioned in another comment [1] on this thread, soundness and decidability are non-negotiable for me. Types in C#, F# and TS are all Turing Complete [2], and therefor these languages are tooling-adverse in the sense that static analysis is fundamentally unreliable. How on earth do you consider Kotlin acceptable then? Kotlin's type system has never been shown to be sound or decidable and is visibly a lot more ad-hoc than any of that list (and if by some miracle it was sound or decidable last week, I'm sure whatever new feature they added this week broke it). I suspect the only reason it hasn't been formally proven to be Turing Complete is that Kotlin's developers haven't bothered to write a specification for it - as far as I can see your link's example for C# would translate directly into Kotlin with the same properties.
  - bmc7505 4y ago
    Try it! I certainly have. You may find encoding a typelevel TM or λ-calculus more difficult than it appears... > link's example for C# would translate directly into Kotlin T() is not possible for a generic T in Kotlin.

jbellis 4y ago

I was actually very disappointed to find the kotlin refactorings lagging what for Java in IntelliJ. A few examples: https://youtrack.jetbrains.com/issue/KTIJ-12496/Provide-intention-to-convert-from-extension-function-to-member https://youtrack.jetbrains.com/issue/KTIJ-12496/Provide-inte... https://youtrack.jetbrains.com/issue/KTIJ-10606/Support-moving-a-function-to-an-instance-class https://youtrack.jetbrains.com/issue/KTIJ-10606/Support-movi... https://youtrack.jetbrains.com/issue/KTIJ-5063/Extract-property-does-not-work-on-local-variable-with-no-usages https://youtrack.jetbrains.com/issue/KTIJ-5063/Extract-prope...

ctvo 4y ago

Kotlin has one of the poorer LSP implementations out of the popular JVM languages. Last I tried it was buggy, and slow. Developers are pushed into using JetBrains products directly or indirectly (Android Studios) I suspect leaving the wider ecosystem poorly supported.

anotherevan 4y ago
I was evaluating Kotlin for a Spring Boot project a few years ago and would have loved to have programmed in it, but this was exactly why I stuck with Java.