4 ms·

Kotlin really got lucky with Google choosing it for Android dev. While Google is known for relegating some of its tech to the dust bin, Android is too big at th

Kotlin really got lucky with Google choosing it for Android dev. While Google is known for relegating some of its tech to the dust bin, Android is too big at the moment. Flutter + Dart was a little surprising though. If they hadn't chosen Kotlin, I couldn't have seen a real path forward for JetBrains. It was basically a much nicer Scala (and I'd argue, a really nice Java) But they keep it locked up with IntelliJ. This, by the way, is why none of us are writing SmallTalk these days. Having to purchase and use a particular IDE is not how we do software these days. (Feel free to tell me how AMAZING IntelliJ is... it's not my cup of tea)

sorokod 1y ago
It is a nicer Java and works really well as a pure backend language.
- nobleach 1y ago
  Oh no doubt it's my favorite backend way to build an API. Just toss in SpringBoot or Quarkus and it's very nice. The only thing that bothers me is that it's a pain to use with NeoVim.
  - sorokod 1y ago
    Yes, I believe that the constraints on Kotlin features are determined to a large extent by the capabilities of IDEA. At the risk of mixing cause and effect, Kotlin is IDEA shaped.
gengstrand 1y ago
I recently blogged about the developer experience with server-side Kotlin at https://glennengstrand.info/software/coding/csharp/kotlin https://glennengstrand.info/software/coding/csharp/kotlin so you should know that the IntelliJ folks offer a community edition of their IDE that works great with Kotlin. You don't even need the IntelliJ IDE at all. I was able to code up that Kotlin service using VS Code which was also a great experience. Nothing felt limited or dummied down at all.
- mike_hearn 1y ago
  Nice writeup, but it's kinda meaningless to consider import statements when comparing LOC as they're written for you in both C# and Kotlin. Also, just because the default code style doesn't like glob imports doesn't mean you have to roll with it - Kotlin isn't like Go where there's One True Style and everyone is expected to follow it. You can just turn on import globbing and optimization. That would presumably cause LOC to be much more similar.
- nobleach 1y ago
  The entire JVM ecosystem is built around "we all know you're using an IDE, right?" I among most folks who use Kotlin are aware of the Community Edition of IntelliJ. The price isn't the thing keeping me from using it. 1. an employer _should_ be covering that cost. 2. The tools is truly outstanding and well worth the 500 bucks (I'd argue it's not worth 500 bucks a year but...) With all of that said, I really don't enjoy the IDE experience. I do tend to write Kotlin + Quarkus in NeoVim... but the LSP is a volunteer effort. Meanwhile Rust and Go's LSPs are incredibly. My biggest complaint against the JVM community will alwyas be, "don't expect that we can auto-import... document where methods/constant/imported vars come from".

sorokod 1y ago

It is a nicer Java and works really well as a pure backend language.

nobleach 1y ago
Oh no doubt it's my favorite backend way to build an API. Just toss in SpringBoot or Quarkus and it's very nice. The only thing that bothers me is that it's a pain to use with NeoVim.
- sorokod 1y ago
  Yes, I believe that the constraints on Kotlin features are determined to a large extent by the capabilities of IDEA. At the risk of mixing cause and effect, Kotlin is IDEA shaped.

gengstrand 1y ago

I recently blogged about the developer experience with server-side Kotlin at https://glennengstrand.info/software/coding/csharp/kotlin https://glennengstrand.info/software/coding/csharp/kotlin so you should know that the IntelliJ folks offer a community edition of their IDE that works great with Kotlin. You don't even need the IntelliJ IDE at all. I was able to code up that Kotlin service using VS Code which was also a great experience. Nothing felt limited or dummied down at all.

mike_hearn 1y ago
Nice writeup, but it's kinda meaningless to consider import statements when comparing LOC as they're written for you in both C# and Kotlin. Also, just because the default code style doesn't like glob imports doesn't mean you have to roll with it - Kotlin isn't like Go where there's One True Style and everyone is expected to follow it. You can just turn on import globbing and optimization. That would presumably cause LOC to be much more similar.
nobleach 1y ago
The entire JVM ecosystem is built around "we all know you're using an IDE, right?" I among most folks who use Kotlin are aware of the Community Edition of IntelliJ. The price isn't the thing keeping me from using it. 1. an employer _should_ be covering that cost. 2. The tools is truly outstanding and well worth the 500 bucks (I'd argue it's not worth 500 bucks a year but...) With all of that said, I really don't enjoy the IDE experience. I do tend to write Kotlin + Quarkus in NeoVim... but the LSP is a volunteer effort. Meanwhile Rust and Go's LSPs are incredibly. My biggest complaint against the JVM community will alwyas be, "don't expect that we can auto-import... document where methods/constant/imported vars come from".