Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

cekrem.github.io

Post reply on HN
Print view View original

41–50 of 84 posts

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

#41

Post by hutao »

spankalee wrote: post #36
hutao wrote: post #30

Earlier quoted context omitted.

One of the most thorough articles on error handling in programming language design that I've read is this one: https://joeduffyblog.com/2016/02/07/the-error-model/ . It was written by Joe Duffy, who worked on Microsoft's experimental Midori language. Another relevant article is Robert Nystrom's "What Color is Your Function?": https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... This article is about async/…

That Midori article looks great, I'll give that a closer read. I actually used to work with Bob, and am familiar with the (wonderful!) function color article. I think my biggest question might be addressed in the Midori article: with things like bounds checks and checked casts you already have exceptions (or panics), so should you have a way to capture them anywhere on the stack? Are they recoverable in some programs…

I'd never heard of "resumable exceptions" before, so I searched them up [1][2]. Is this another name for the language feature called "effect handlers" in OCaml 5?

[1] https://osa1.net/posts/2024-11-04-resumable-exceptions.html

[2] https://softwareengineering.stackexchange.com/questions/8033...

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

#42

Post by josephg »

HendrikHensen wrote: post #26
josephg wrote: post #24

Earlier quoted context omitted.

> why a division operator, or an array access, doesn't return a `Result` type in nice languages such as Rust? Rust has standard library functions to do this, if you want. arr.get(index) returns an Option. Integer types have .checked_div for panic-free divide. Float already doesn’t panic on an invalid division - it just returns NaN or Infinity.

That's great! Though, by making it not forced and giving users a choice, you never know which library code you call might not use those features and still panic when you use it. (Just to be clear, I don't really propose that a language should offer only panic-free operations; I just think it's a nice thought experiment and discussion to have).

True. I'd really love rust to have a nopanic annotation you can put on function calls which guarantees that nothing in the call tree can panic.

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

#43

Post by thesz »

hutao wrote: post #39
spankalee wrote: post #38

Earlier quoted context omitted.

I'm targeting only WASM at the moment. I wish I could get into Haskell, but I just can't read it. I really can't parse what's going on with types like `Result e t (Either e t)`.

The `Either a b` type in Haskell is equivalent to the `Result ` type in other languages. The only difference is in the naming: "Result" semantically implies error handling, while "Either" implies a more general usage as the alternative between two options. Either and Result are the binary sum type (the disjoint union between two types). In Haskell, Either is defined as data Either a b = Left a | Right b Note that in…

  > The `Either a b` type in Haskell is equivalent to the `Result` type in other languages. The only difference is in the naming:
This is false and misleading.

The Result usually (C#, at the very least, most probably C++ and many other languages) should always be fully instantiated. One usually cannot construct a type "function" like Result that needs a single type argument to instantiate a full type. The partial application on type level is not there in most languages, including Rust (a result of a little googling).

The Haskell's Either type can be instantiated to Be a two-type-arguments function, one type argument function and, finally, a fully instantiated type like Either String Int.

This means that Result type effectively has a single type argument, namely pair of types. The Either type has two type arguments and can be partially applied.

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

#44

Post by spankalee »

hutao wrote: post #41
spankalee wrote: post #36

Earlier quoted context omitted.

That Midori article looks great, I'll give that a closer read. I actually used to work with Bob, and am familiar with the (wonderful!) function color article. I think my biggest question might be addressed in the Midori article: with things like bounds checks and checked casts you already have exceptions (or panics), so should you have a way to capture them anywhere on the stack? Are they recoverable in some programs…

I'd never heard of "resumable exceptions" before, so I searched them up [1][2]. Is this another name for the language feature called "effect handlers" in OCaml 5? [1] https://osa1.net/posts/2024-11-04-resumable-exceptions.html [2] https://softwareengineering.stackexchange.com/questions/8033...

Yes, afaiu at least, effects and resumable exceptions are nearly the same, and you can implement one with the other.

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

#45

Post by thesz »

spankalee wrote: post #38
thesz wrote: post #32

Earlier quoted context omitted.

> But I'm unsure if there's a strong argument that resonates with me yet that the language shouldn't have exceptions at all. Result is the type Either e t in Haskell. And Either is a Monad: https://hackage-content.haskell.org/package/base-4.22.0.0/do... This means you can have a computation inside Either e monad (notice missing result type) which can occasionally produce an exception, and these exceptions are checked…

I'm targeting only WASM at the moment. I wish I could get into Haskell, but I just can't read it. I really can't parse what's going on with types like `Result e t (Either e t)`.

The paper about type classes [1] includes exceptions as an example.

[1] https://web.cecs.pdx.edu/~mpj/pubs/springschool95.pdf

This [2] paper generalizes exceptions, allowing them to be first class citizens of a language and even to be a exceptions-as-a-library.

[2] https://raw.githubusercontent.com/nbenton/nbenton.github.io/...

In (not only) my opinion, Haskell's greatness is in "what is a language feature in most languages is a library in Haskell." One can model type system of a language by embedding it as a library into a Haskell and then develop it further as a standalone language if one prefers such path.

I did that embed-as-library thing several times. It was of great help, especially in the embedded systems and hardware circuits domains.

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

#46

Post by hutao »

thesz wrote: post #43
hutao wrote: post #39

Earlier quoted context omitted.

The `Either a b` type in Haskell is equivalent to the `Result ` type in other languages. The only difference is in the naming: "Result" semantically implies error handling, while "Either" implies a more general usage as the alternative between two options. Either and Result are the binary sum type (the disjoint union between two types). In Haskell, Either is defined as data Either a b = Left a | Right b Note that in…

> The `Either a b` type in Haskell is equivalent to the `Result ` type in other languages. The only difference is in the naming: This is false and misleading. The Result usually (C#, at the very least, most probably C++ and many other languages) should always be fully instantiated. One usually cannot construct a type "function" like Result that needs a single type argument to instantiate a full type. The partial appl…

You are right, in Haskell type constructors may be partially applied. In my opinion, this feature has less to do with any fundamental difference between `Either` in Haskell and `Result` in other languages, and more to do with Haskell's more powerful type system. In the same way, the pair type (a, b) in Haskell is also different from the pair types in other languages. This feature is called "higher-kinded types."

In particular, higher-kinded types are necessary to abstract over functors (or functions from types to types, * -> *). The list type constructor is a functor, and the partially applied type constructor `Either a` is also a functor. However, in languages without higher-kinded types, type variables can only be "ground types" (of kind *).

I don't agree with this statement:

> This means that Result type effectively has a single type argument, namely pair of types. The Either type has two type arguments and can be partially applied.

The Result type still takes two type arguments. The main distinction, in my view, is that Haskell allows types to be "higher-order." In fact, to be really pedantic, you could argue that the `Either` type in Haskell really takes one type argument, and then returns a function from types to types (currying).

This is kind of like the type-level equivalent to how many programming languages support some notion of function or procedure (and functions may have multiple arguments), but only more modern languages support higher-order functions, or allow variables to be functions.

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

#47

Post by pjmlp »

tadfisher wrote: post #35
pjmlp wrote: post #8

Earlier quoted context omitted.

Kotlin folks seem to mostly care about Java as bootstrap to their own ecosystem. The anti-Java bias, against the platform that made it possible in first place and got JetBrains a business, is quite strong on Android, fostered by the team own attitude usually using legacy Java samples vs Kotlin.

This is needlessly divisive. JetBrains does not owe two-way interop to the Java ecosystem. There are many Kotlin features that do not have clean interop with Java; Compose, coroutines, and value classes come to mind. And it turns out that this mostly benefits Java, because these features are not built with the kind of engineering rigor that Java language features enjoy, and some of these features would behave way bet…

I know it is divisive, yet many Kotlin folks don't appreciate the platform that makes their ecosystem possible in first place.

From all the JVM guest languages, possibly fostered by Android team, they are the most anti-Java ecosystem.

Clojure folks appreciate being a hosted language, Scala is kind of they would rather have Haskell but still JVM is kind of cool, Groovy was usually a way to script applications.

Kotlin, well those behave as if ever the JVM would be one day rewriten in Kotlin, they have Android for that.

The features you mention will never be supported in Android by the way, at least I don't believe Google will ever bother to do so.

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

#48

Post by pjmlp »

pianoben wrote: post #33
pjmlp wrote: post #28

Earlier quoted context omitted.

Lies, damm lies. They cherry pick whatever they feel like from OpenJDK. And even though Oracle was right, given that Android is Google's J++, in this case they had better luck than Microsoft. They don't take more from OpenJDK because then their anti-Java narrative doesn't work out. But there is some schadenfreund, to keep Kotlin compatibility story relevant they are nonetheless obligated to keep up with is mostly use…

Maybe I'm wrong about the state of Java in Android today - it's been a few years since I did that work full-time. But I do remember when Kotlin broke on to the scene in 2015, and most of us were thrilled to finally move beyond Java 7! The embrace of a non-Java language was grassroots and genuine; Google's adoption came several years later. J++ though, now that is a blast from the past! I think I still have a J# book…

ART is updatable via PlayStore since Android 12, however in 2026 the latest is a Java 17 subset, while the latest LTS is Java 25.

Kotlin only worked properly on Android after some folks pushed it from inside, and then they used Java 6 vs Kotlin samples to advocate for it.

In 2015 the latest Java version was 8, which never was properly supported on Android, the community had to come up with RetroLambda, before Google created desugaring support, think Babel but for Java.

Naturally it also meant that the performance of Java 8 features wasn't the same, e.g. lambdas make use of invokedynamic on the JVM, on Android they used to be rewriten into nested classes.

Even today, although Android documentation has Java and Kotlin tabs for code snippets, the Java ones are hardly taking advantage of modern features.

Naturally who learns Java on Android gets an adulterated view on the matter.

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

#49

Post by zaphirplane »

pjmlp wrote: post #31
zaphirplane wrote: post #27

Earlier quoted context omitted.

That is more interoperability than guest language situation. I don’t think c++ is a c guest. Ts has a different approach to the js self.

C++ started as a C macro preprocessor, designed to work as C in UNIX, and by CFront 2.0 there was already too much compatibility to throw away. Ts is basically a linter, everything else is JS.

c++ bootstrapping as a transpiler back when it was a 1 man show is hardly where it’s at today. The point about self handling in ts should demonstrate there is more than just strip the types going on

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

#50

Post by pjmlp »

andrekandre wrote: post #40
pianoben wrote: post #33

Earlier quoted context omitted.

Maybe I'm wrong about the state of Java in Android today - it's been a few years since I did that work full-time. But I do remember when Kotlin broke on to the scene in 2015, and most of us were thrilled to finally move beyond Java 7! The embrace of a non-Java language was grassroots and genuine; Google's adoption came several years later. J++ though, now that is a blast from the past! I think I still have a J# book…

> But I do remember when Kotlin broke on to the scene in 2015, and most of us were thrilled to finally move beyond Java 7! n=1 but i was there with android studio v0.01 (or thereabouts) using kotlin for a production app cause i was so sick of old-java + eclipse... google was asleep at the wheele imo and android development would be nowhere near where it is today without jetbrains

Compared to Apple and Microsoft, Android development is mostly outsourced.

None of the development environments is from Google, none of the languages as well, or the build tools for app developers (Internally they use Bazel and Soong).

Naturally having gone into bed with JetBrains for the IDE, after leaving NDK users without IDE tooling for almost two years during the IDE transition, the deal was in place to push Kotlin as well.

I am surprised Google hasn't yet bought JetBrains.

Post reply on HN