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

71–80 of 84 posts

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

#71

Post by mike_hearn »

pjmlp wrote: post #50
andrekandre wrote: post #40

Earlier quoted context omitted.

> 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 Kot…

Rumour has it Google tried many times but JetBrains isn't for sale.

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

#72

Post by vips7L »

sirwhinesalot wrote: post #6
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…

Exceptions are cheap on the happy path and super expensive on the error path. Checked exceptions only make sense for errors that are relatively common (i.e., they aren't really exceptional), which calls for a different implementation entirely where both the happy path and the error path have around the same cost. This is what modern languages like Rust and Go do as well (and I think Swift as well though don't quote m…

Exceptions are cheap. Stack trace collection is the expensive part; if you make use of checked exceptions for domain errors you can just turn that off if you hit a performance problem.

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

#73

Post by vips7L »

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…

> JetBrains does not owe two-way interop to the Java ecosystem.

They owe their users and customers. Many of them are asking for this and were lead to believe it was a priority when adopting the language.

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

#74

Post by vips7L »

HendrikHensen wrote: post #25
Tyr42 wrote: post #17

Earlier quoted context omitted.

Sounds like checked and unchecked exceptions. I mean, this could be a syntax wrapper for java checked exceptions right? Those are isomorphic to Result in that you must handle or propagate the error. The syntax is different, sure.

Correct. Although the performance characteristics are different. An exception in Java generates a stack trace, which is relatively expensive. So not a great idea in un-exceptional code paths that need to perform well.

Stack trace collection is optional. If you actually hit a performance problem on a checked exception path you just override the stack trace collection not to happen. I do this in most of my projects that use checked exceptions as domain errors. Only once you have to panic, i.e wrap in an unchecked exception, stack trace collection happens.

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

#76

Post by brabel »

noelwelsh wrote: post #64
brabel wrote: post #57

Earlier quoted context omitted.

Of course Elm has union types, it’s like one of its main features! https://guide.elm-lang.org/types/custom_types.html

I mean union types in the programming language theory sense, not in the "we called this language feature union types" sense. Elm's union types are algebraic data types (ADTs). Union types in the PLT sense are what Typescript has. The main difference is that an ADT must be declared upfront, whilst a union type can be constructed in an ad-hoc manner based on whatever types are used together at a particular point in the…

I used to think the same but after having many discussions just like this I accepted that there’s no agreed upon formal definition for what is a union type and what isn’t. Being created ad hoc or not seems like a made up on the spot distinction. If you do think there is a definition that most researchers agree on that’s distinct from ADT, do provide some sources.

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

#77

Post by noelwelsh »

brabel wrote: post #76
noelwelsh wrote: post #64

Earlier quoted context omitted.

I mean union types in the programming language theory sense, not in the "we called this language feature union types" sense. Elm's union types are algebraic data types (ADTs). Union types in the PLT sense are what Typescript has. The main difference is that an ADT must be declared upfront, whilst a union type can be constructed in an ad-hoc manner based on whatever types are used together at a particular point in the…

I used to think the same but after having many discussions just like this I accepted that there’s no agreed upon formal definition for what is a union type and what isn’t. Being created ad hoc or not seems like a made up on the spot distinction. If you do think there is a definition that most researchers agree on that’s distinct from ADT, do provide some sources.

Here's Types and Programming Languages on union types. My take away is that the preferred terminology is union types for non-disjoint unions and sum types for disjoint unions.

"Sum and variant types are sometimes called disjoint unions. The type T1+T2 is a “union” of T1 and T2 in the sense that its elements include all the elements from T1 and T2. This union is disjoint because the sets of elements of T1 or T2 are tagged with inl or inr,respectively, before they are combined, so that it is always clear whether a given element of the union comes from T1 or T2. The phrase union type is also used to refer to untagged (non-disjoint) union types, described in §15.7." p142

"The dual notion of union types, T1 ∨ T2, also turns out to be quite useful. Unlike sum and variant types (which, confusingly, are sometimes also called “unions”), T1 ∨T2 denotes the ordinary union of the set of values belonging to T1 and the set of values belonging to T2, with no added tag to identify the origin of a given element." p207

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

#78

Post by zaphirplane »

pjmlp wrote: post #59
zaphirplane wrote: post #49

Earlier quoted context omitted.

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

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.

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

#79

Post by brabel »

noelwelsh wrote: post #77
brabel wrote: post #76

Earlier quoted context omitted.

I used to think the same but after having many discussions just like this I accepted that there’s no agreed upon formal definition for what is a union type and what isn’t. Being created ad hoc or not seems like a made up on the spot distinction. If you do think there is a definition that most researchers agree on that’s distinct from ADT, do provide some sources.

Here's Types and Programming Languages on union types. My take away is that the preferred terminology is union types for non-disjoint unions and sum types for disjoint unions. "Sum and variant types are sometimes called disjoint unions. The type T1+T2 is a “union” of T1 and T2 in the sense that its elements include all the elements from T1 and T2. This union is disjoint because the sets of elements of T1 or T2 are ta…

They seem to both agree that union types are about being possibly non-disjoint, and ADT being always disjoint, with values tagged as of a single type. I can accept that since it defines union as the same concept as in set theory. There’s nothing there regarding types being ad hoc, though that is arguably a consequence of the syntax since using a symbol between different types to “union” them cannot be expected to result in a disjointed type union. So, I think that’s a useful and defensible position, but I don’t think many people will use these definitions consistently given there’s already a lot of confusion in the use of these terms.

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

#80

Post by simon_void »

rileymichael wrote: post #29
simon_void wrote: post #2

Rich Errors look promising to me, but what about interop with Java? What will the return-type of a function be on the Java side be, if the return type on Kotlin side is: Int | ParseError | SomeOtherError? Background: unions aren't restricted to one normal type and one error type, but to one normal type and any number of error types, so this can't be modelled as syntactic sugar on top of an implicit Either/Result type…

by default it'll be exposed as a `java.lang.Object` and they've thought about using compiler plugins to generate methods returning `Optional ` or `Result ` instead https://www.youtube.com/watch?v=IUrA3mDSWZQ&t=2626s

thank you for the link to the talk! I actually witnessed the talk live, but must have completely missed this or simply forgot that this was answered :D
Post reply on HN