Kotlin's rich errors: Native, typed errors without exceptions • Hacker News Board

Re: Kotlin's rich errors: Native, typed errors without exceptions

#81

Post by wiseowise » Sun, Jan 25, 2026, 10:23 AM UTC

mike_hearn wrote: post #70

wiseowise wrote: post #65

Earlier quoted context omitted.

> Because Kotlin took a dumb turn about 5 years ago and decided that multiplatform was their future instead of the jvm (because they felt threatened by React Native and Flutter on Android). It’s because JB intends to make money on their investment, unlike the other two. This is the reason why Kotlin ecosystem is a half baked mess – JB tries to artificially replicate all successful ecosystems without having a communit…

How so? The Android ecosystem literally became the Kotlin ecosystem it was so successful. The multiplatform stuff came out of organic demand for re-using code at first between JVM backend and browser (Kotlin/JS), and then for re-using code between JVM, JS, Android and sharing the business logic on iOS, and then finally for being able to reuse UI code on iOS too for cases where native Swift UI can't be justified (obsc…

> The Android ecosystem literally became the Kotlin ecosystem it was so successful.

The Android ecosystem became Kotlin ecosystem because Google said so, not because it was successful. There was a small hype around Kotlin during 2016, because: cool lambdas! type inference! extension functions! null-aware by default! And all the other small improvements, but ultimately it was Google pushing Kotlin down the throat of everyone that made it "official".

Oracle v Google beef, Java moving at a snails pace, lack of mobile focus, all of this were far more major contributors than Kotlin's language features. And of course those who were screaming at the top of their lungs that Java will catch up and overtake Kotlin were right.

> The multiplatform stuff came out of organic demand for re-using code at first between JVM backend and browser (Kotlin/JS), and then for re-using code between JVM, JS, Android and sharing the business logic on iOS, and then finally for being able to reuse UI code on iOS too for cases where native Swift UI can't be justified (obscure apps, etc).

The multiplatform stuff came out because JetBrains understood that being Android-only is a death march for their language. And you can't monetize Android developers, they use free Android Studio. Kotlin/JS is dead in the water, there's literally no reason to use it and even JetBrains themselves scaled down their investment dramatically into it. The only main target they set for themselves was capturing iOS market when they saw Flutter literally consuming the niche with outstanding dev experience despite mediocre language at the time (Dart).

> Seems to me like Kotlin Multiplatform has been quite successful actually.

By which metric?

> where they could have just used GraalVM Native Image

On iOS?

Re: Kotlin's rich errors: Native, typed errors without exceptions

#82

Post by mike_hearn » Sun, Jan 25, 2026, 2:42 PM UTC

wiseowise wrote: post #81

mike_hearn wrote: post #70

Earlier quoted context omitted.

How so? The Android ecosystem literally became the Kotlin ecosystem it was so successful. The multiplatform stuff came out of organic demand for re-using code at first between JVM backend and browser (Kotlin/JS), and then for re-using code between JVM, JS, Android and sharing the business logic on iOS, and then finally for being able to reuse UI code on iOS too for cases where native Swift UI can't be justified (obsc…

> The Android ecosystem literally became the Kotlin ecosystem it was so successful. The Android ecosystem became Kotlin ecosystem because Google said so, not because it was successful. There was a small hype around Kotlin during 2016, because: cool lambdas! type inference! extension functions! null-aware by default! And all the other small improvements, but ultimately it was Google pushing Kotlin down the throat of e…

Sure. The hard part of iOS is the JIT ban, Native Image can make macOS binaries just fine.

> The Android ecosystem became Kotlin ecosystem because Google said so, not because it was successful

This is not how I remember events unfolding. I used Kotlin before Google ever talked about it and it was doing fine as a language for desktop and backend JVM apps. When Google started officially supporting it, it was just recognizing that Android developers were already organically adopting it at scale.

Re: Kotlin's rich errors: Native, typed errors without exceptions

#83

Post by pjmlp » Mon, Jan 26, 2026, 7:00 AM UTC

zaphirplane wrote: post #78

pjmlp wrote: post #59

Earlier quoted context omitted.

There is the whole fit into the same UNIX compiler toolchain as C, without additional changes to the linker, include files, object and archive files.

Oh like how gnu compiler includes an ada compiler ? Or the C++ name mangling ? Obviously there a common heritage and the shared ancestor is c.

C++ name mangling was exactly designed to be able to link C++ code with a standard UNIX linker that only knows C.

GNAT has zero compatibility with C source, doesn't even make sense.

Re: Kotlin's rich errors: Native, typed errors without exceptions

#84

Post by mr7uca » Wed, Jan 28, 2026, 12:48 AM UTC

guelo wrote: post #58

armchairhacker wrote: post #5

These remind me of checked exceptions in Java. Ironically, Kotlin removed checked exceptions because they tend to be annoying more than useful: there's no clear guideline to whether an exception is checked or unchecked, some functions like IO and reflection have them while others don't, they're verbose especially when closures are involved, and lots of functions simply catch and rethrow checked exceptions in unchecke…

Because Kotlin took a dumb turn about 5 years ago and decided that multiplatform was their future instead of the jvm (because they felt threatened by React Native and Flutter on Android). Point being, they don't want to tie themselves to the jvm anymore. The language has been stagnant for years as they've had to reimplement tons of java libraries and also shoehorn the extreme complications of multiplatform into the a…

You can argue the tooling is still immature... but kmp really has been taking off since cmp has gone stable on ios. The kmp library ecosystem is even getting quite large. Also, kmp has very distinct advantages over React Native and Flutter, they didn't just copy-paste from RN or Flutter.