4 ms·

EDIT: Forgot to confirm that I do, in fact, use Kotlin for a fairly large and moderately complex backend system (multiple deployed systems, including one HTTP R

EDIT: Forgot to confirm that I do, in fact, use Kotlin for a fairly large and moderately complex backend system (multiple deployed systems, including one HTTP REST-ish API). I'm of two minds about it. I started working with Kotlin back when Java was still a very ~~stagnant~~ stable language. I definitely find Kotlin's syntax to be much more comfortable, expressive, and in many ways much more simple than Java's. But at this point, the only big technical features that still put Kotlin over Java for me is the handling of nulls by the type system (which is, admittedly, mitigated decently well in practice by Java tooling configurations and ugly annotations), and value types (zero heap-allocation wrapper classes). Another thing to keep in mind is that now that Java is actually adding features again, the Kotlin developers will have to also play "catch-up" to Java in ways that it didn't have to when it first gained popularity. It puts Kotlin in an awkward spot when Java's implementation of sealed classes and interfaces was initially better and more flexible than Kotlin's, or when Java's `switch` is now more powerful than Kotlin's `when`, etc. Kotlin is also betting heavily on their multi-platform stuff, which I'm skeptical about. It seems to me that it will further slow the ability to add useful features to the language if you have to cater to the lowest-common-denominator between Java and JavaScript (and Objective-C? -is that how it works for iOS?) runtimes. Instead of being the best language for a given platform, it'll just be a pretty good language for a few platforms. I wish them all the best in dethroning JavaScript from infecting every computing platform and domain, but I'm just skeptical. So, honestly, I don't actually recommend people start new projects in Kotlin. I'd suggest going for Java, or something that's meaningfully different in semantics and philosophy like Clojure or Scala. I say this, but I'm not actually sure that I'd be able to follow my own advice, because I really don't want to have to stomach Java's syntax, idioms (way too many annotations), and stupid null handling.

clumsysmurf 1y ago
I am also worried about the concurrency side of Kotlin. Since Roman Elizarov, the architect of the coroutine / flow implementation, left JetBrains two years ago, it seems to be stagnant. Looking through the tracker conversations I almost get the impression whoever inherited it doesn't know where to take it next.
- ragnese 1y ago
  That's a whole huge can of worms, too. Coroutines and the suspend keyword were a great innovative feature at the time (very clever implementation on the JVM and good API design given the limitations of the implementation and syntax design constraints), but now that Java has so-called virtual threads, you don't "need" Kotlin for convenient(-ish), simple(-ish), scalable, structured concurrency like you used to, either. One could rightly debate over whether Kotlin's coroutines design and APIs are better than Java's virtual threads for writing asynchronous code. But, at the core, the story used to be that Kotlin had coroutines and lightweight structured concurrency "built-in" (with a blessed first-party helper library for the actual concurrency part) and Java did not have anything that accomplished the same goals. Now it does.
  - qcnguy 1y ago
    [dead]
- gavinray 1y ago
  Vsevolod Tolstopyatov (https://github.com/qwwdfsad https://github.com/qwwdfsad) is the other brain behind Coroutines, Concurrency, and Atomics in Kotlin, and he's still very much active.
esafak 1y ago
I do, because the Java ecosystem (which includes its programmers) is always going to have one foot in Java 8; it's the prototypical enterprise language.
- ragnese 1y ago
  That's a fair point. You don't have to write Java with giant graphs of objects-in-objects-in-objects and heavy mixing of (often mutable) data and logic in the same classes, but it's hard to deny that the culture, conventions, and idioms in the Java ecosystem can be quite different from the culture, conventions, and idioms in Kotlin. On the other hand, when I see Kotlin code that's not written by JetBrains (especially on the backend), it often does just look like Java code with cleaner syntax...
vips7L 1y ago
>but at this point, the only big technical features that still put Kotlin over Java for me is the handling of nulls by the type system Soon (tm): https://openjdk.org/jeps/8303099 https://openjdk.org/jeps/8303099 The one feature that keeps me in Java, albeit not popular, is checked exceptions. I far prefer checked errors over checked nulls if I have to make a choice.
- Defletter 1y ago
  While I am definitely impatiently waiting for null-restricted types, what I feel Java really needs overall is ergonomic handling syntax, notably: "safe calls" (https://kotlinlang.org/docs/null-safety.html#safe-call-operator https://kotlinlang.org/docs/null-safety.html#safe-call-opera...), "elvis operator" (https://kotlinlang.org/docs/null-safety.html#elvis-operator https://kotlinlang.org/docs/null-safety.html#elvis-operator), and inline catching (https://ziglang.org/documentation/0.14.1/#catch https://ziglang.org/documentation/0.14.1/#catch). Relevant: https://news.ycombinator.com/item?id=44672787 https://news.ycombinator.com/item?id=44672787
  - vips7L 1y ago
    Yeah I’ve writen about error handling syntax here a bit: https://news.ycombinator.com/item?id=44551088 https://news.ycombinator.com/item?id=44551088 https://news.ycombinator.com/item?id=44432640 https://news.ycombinator.com/item?id=44432640 It’s actually my #1 issue. I hate not knowing about error conditions and no one in Java uses checked exceptions because the language syntax for dealing with them sucks. Brian had a proposal for handling exceptions in switch but it seems to have died in the water. Part of me secretly hopes Swift takes over the world because they have a typed throws that works and handling errors is a breeze.
    - Defletter 1y ago
      While I am certainly a fan of Swift's error handling and think it'd be an improvement to Java's current state of affairs, I do think that using null as an error analogue is... unwise. What happens when a function is throwable but also may return null? How do you determine whether the null is a coerced error or a valid return? Or rather, how do you do this without returning to the un-ergonomic try-catch? Zig solves this by having errors and nulls be separate parts of the type system which you can deal with separately and inline.
ItsHarper 1y ago
It's not compiling to Objective-C, it's compiling to machine code with a garbage collector packaged in, (similar to go, I think it would be fair to say).

clumsysmurf 1y ago

I am also worried about the concurrency side of Kotlin. Since Roman Elizarov, the architect of the coroutine / flow implementation, left JetBrains two years ago, it seems to be stagnant. Looking through the tracker conversations I almost get the impression whoever inherited it doesn't know where to take it next.

ragnese 1y ago
That's a whole huge can of worms, too. Coroutines and the suspend keyword were a great innovative feature at the time (very clever implementation on the JVM and good API design given the limitations of the implementation and syntax design constraints), but now that Java has so-called virtual threads, you don't "need" Kotlin for convenient(-ish), simple(-ish), scalable, structured concurrency like you used to, either. One could rightly debate over whether Kotlin's coroutines design and APIs are better than Java's virtual threads for writing asynchronous code. But, at the core, the story used to be that Kotlin had coroutines and lightweight structured concurrency "built-in" (with a blessed first-party helper library for the actual concurrency part) and Java did not have anything that accomplished the same goals. Now it does.
- qcnguy 1y ago
  [dead]
gavinray 1y ago
Vsevolod Tolstopyatov (https://github.com/qwwdfsad https://github.com/qwwdfsad) is the other brain behind Coroutines, Concurrency, and Atomics in Kotlin, and he's still very much active.

esafak 1y ago

I do, because the Java ecosystem (which includes its programmers) is always going to have one foot in Java 8; it's the prototypical enterprise language.

ragnese 1y ago
That's a fair point. You don't have to write Java with giant graphs of objects-in-objects-in-objects and heavy mixing of (often mutable) data and logic in the same classes, but it's hard to deny that the culture, conventions, and idioms in the Java ecosystem can be quite different from the culture, conventions, and idioms in Kotlin. On the other hand, when I see Kotlin code that's not written by JetBrains (especially on the backend), it often does just look like Java code with cleaner syntax...

vips7L 1y ago

>but at this point, the only big technical features that still put Kotlin over Java for me is the handling of nulls by the type system Soon (tm): https://openjdk.org/jeps/8303099 https://openjdk.org/jeps/8303099 The one feature that keeps me in Java, albeit not popular, is checked exceptions. I far prefer checked errors over checked nulls if I have to make a choice.

Defletter 1y ago
While I am definitely impatiently waiting for null-restricted types, what I feel Java really needs overall is ergonomic handling syntax, notably: "safe calls" (https://kotlinlang.org/docs/null-safety.html#safe-call-operator https://kotlinlang.org/docs/null-safety.html#safe-call-opera...), "elvis operator" (https://kotlinlang.org/docs/null-safety.html#elvis-operator https://kotlinlang.org/docs/null-safety.html#elvis-operator), and inline catching (https://ziglang.org/documentation/0.14.1/#catch https://ziglang.org/documentation/0.14.1/#catch). Relevant: https://news.ycombinator.com/item?id=44672787 https://news.ycombinator.com/item?id=44672787
- vips7L 1y ago
  Yeah I’ve writen about error handling syntax here a bit: https://news.ycombinator.com/item?id=44551088 https://news.ycombinator.com/item?id=44551088 https://news.ycombinator.com/item?id=44432640 https://news.ycombinator.com/item?id=44432640 It’s actually my #1 issue. I hate not knowing about error conditions and no one in Java uses checked exceptions because the language syntax for dealing with them sucks. Brian had a proposal for handling exceptions in switch but it seems to have died in the water. Part of me secretly hopes Swift takes over the world because they have a typed throws that works and handling errors is a breeze.
  - Defletter 1y ago
    While I am certainly a fan of Swift's error handling and think it'd be an improvement to Java's current state of affairs, I do think that using null as an error analogue is... unwise. What happens when a function is throwable but also may return null? How do you determine whether the null is a coerced error or a valid return? Or rather, how do you do this without returning to the un-ergonomic try-catch? Zig solves this by having errors and nulls be separate parts of the type system which you can deal with separately and inline.

ItsHarper 1y ago

It's not compiling to Objective-C, it's compiling to machine code with a garbage collector packaged in, (similar to go, I think it would be fair to say).