HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
Kotlin
KEEP
Markdown2016–2026
Kotlin / KEEP

KEEP

Kotlin Evolution and Enhancement Process

Explore on GitHubRead Hacker News discussions
18Distinct people
26Mentions
0Explicit recommenders
3.8KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Kotlin Evolution and Enhancement Process

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 2:59:58 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year26 dated mentions

Observed mentions: 2016-04-20 17:18:24 UTC to 2026-05-22 00:03:58 UTC.

012342016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC211
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC000
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC101
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC101
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC303
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC312
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC312
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC303
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC202
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC413
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC413

What Hacker News says

4 sources
vips7L·Dec 6, 2025
Yes there was a proposal by Brian to make it into a switch expression: https://news.ycombinator.com/item?id=40088719, though that draft is already 1.5 years old and I don't expect it to be delivered anytime soon. It would alleviate some pain, but I really think we need something like try! to escape the compiler when some errors aren't possible: A a; try { a = someThrowingFn(); } catch (AException ex) { throw new IllegalStateException(ex); // not possible } becomes var a = try! someThrowingFn(); or with Brian's proposal: var a = switch (someThrowingFn()) { case A anA -> anA; case throws AException ex -> throw new IllegalStateException(ex); } ...still a bit verbose and funky You should check out Kotlin's proposal for error unions, I think it's pretty good and prevents a lot of b
Read the rest
oiler plate associated with results/exceptions: https://github.com/Kotlin/KEEP/blob/main/proposals/KEEP-0441.... They propose a similar construct to try! with !! like they have for nullable types.
In Thoughts on Go vs. Rust vs. Zig
vips7L·Nov 11, 2025
> So if you had 3 different disjoint exception types that you simply wanted to wrap and rethrow, you had to write 3 different catch blocks for them. Agreed. There's a proposal for exception catching in switch [0] which I'm hopeful will alleviate a lot of this. I think that jep plus combining exceptions with sealed types the error handling will be convenient and easy. sealed abstract class SomeException extends Exception permits AException, BException {}; void someFn() throws SomeException; // hypothetically handling in switch would let you enumerate the subtypes of the exception var a = switch (someFn()) { case A a -> a; case throws AException aex -> new A(); case throws BException bex -> throw new RuntimeException(bex); }; > As another example, the exception type hierarchy doesn't pul
Read the rest
l enough weight. Kotlin has an interesting proposal for their language that creates their own "error" type that will allow type unions [1]. The only thing I worry about is that it further puts Kotlin away from Java making interop a lot harder. [0] https://openjdk.org/jeps/8323658 [1] https://github.com/Kotlin/KEEP/blob/main/proposals/KEEP-0441...
In Error ABI
vips7L·Sep 5, 2025
They also failed because Java never made them easy to work with. If you faced a checked error that you couldn't handle it is impractical to uncheck them. You have to write a shit ton of boilerplate. A a; try { a = someThrowingFn(); } catch (AException ex) { throw new RuntimeException(ex); } It sucks. In Swift this is simply: val a = try! someThrowingFn(); Kotlin is moving towards having both unchecked exceptions (panics) and errors as values. I think its absolutely the correct decision. They're also including an easy way to panic when you can't handle an error: val a = someThrowingFn()!!; The other thing that I think made checked exceptions worse in the beginning was the lack of pattern matching and sealing with exceptions. Being able to exhaust all the different types of a particular error is really impor
Read the rest
tant if you want to properly respond. If you had a meaningless top level exception like IOException you couldn't effectively determine what actually happened and everyone just defaulted to unchecking it. Nowadays it's a little better if you seal your exception hierarchy: sealed abstract class SomeException extends Exception permits A, B { final class B extends SomeException {} final class C extends SomeException {} } try { someThrowingFn(); } catch (SomeException ex) { switch (ex) { case A a -> iCanHandleA(a); case B b -> throw new IllegalStateException(b); // can't handle this one } } Hopefully that becomes even better with the exceptions in switch [1] proposal: switch (someThrowingFn()) { case throws A a -> .. case throws B b -> .. } The real big issue like you said is that they're not completely in the type system. Especially when it comes to lambdas; you need to invent a Result<T, E> type every time you want to work with lambdas. Obviously all of these things are solvable with library code, try! is easily some static panic function; it sure would be nice to not have to write them. Overall I'm hopeful that with the overall programming community moving back towards checked errors that the OpenJdk team will invest in making checked exceptions better, but only time will tell. [0] github.com/Kotlin/KEEP/blob/main/proposals/KEEP-0441-rich-errors-motivation.md [1] https://openjdk.org/jeps/8323658
In Type-safe and user-friendly error handling in Swift 6

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.