SaaSHub helps you find the best software and product alternatives Learn more →
KEEP Alternatives
Similar projects and alternatives to KEEP
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
Moby
The Moby Project - a collaborative project for the container ecosystem to assemble container-based systems
-
-
Roslyn
The Roslyn .NET compiler provides C# and Visual Basic languages with rich code analysis APIs.
-
cockroach
CockroachDB — the cloud native, distributed SQL database designed for high availability, effortless scale, and control over data placement.
-
-
-
-
-
-
-
jspecify
An artifact of fully-specified annotations to power static-analysis checks, beginning with nullness analysis.
-
-
-
-
swift-evolution
This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
-
kotlin-multiplatform-libsodium
A kotlin multiplatform wrapper for libsodium, using directly built libsodium for jvm and native, and libsodium.js for js targets.
-
-
-
KEEP discussion
KEEP reviews and mentions
- Design Notes: Local Lifetimes for Kotlin
- Kotlin Context Parameters in Practice
-
Kotlin's Rich Errors: Native, Typed Errors Without Exceptions
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 unchecked exceptions.
Which leads me to: why is Kotlin implementing this in a non-JVM compatible way, instead of introducing checked exceptions with better language support?
From the GitHub discussion, I see this comment (https://github.com/Kotlin/KEEP/discussions/447#discussioncom...):
> The difference between checked exceptions from java and error unions in this proposal is how they are treated. Checked exceptions are exceptions and always interrupt the flow of execution. On the other hand, errors in this proposal are values and can be passed around as values or intentionally ignored or even aggregated enabling the ability to use them in async and awaitAll etc.
But is this a real difference or something that can be emulated with syntax sugar? Checked exceptions are also values, and errors can be caught (then ignored or aggregated) but by default interrupt the flow of execution.
-
Thoughts on Go vs. Rust vs. Zig
...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 boiler 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.
-
Error ABI
> As another example, the exception type hierarchy doesn't pull 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...
- Rich Errors, a.k.a. Error Union Types: Motivation and Rationale
-
Pattern matching across different languages
Let's translate Java's code to Kotlin. For that, we must activate the experimental Xwhen-guards compilation feature described in KEEP-371.
-
Coroutines, Distributed Cache, Resilience, and Replication in Kotlin — Making a VMA’s application
Kotlin Coroutines Design Document
-
JEP draft: Exception handling in switch
`Either foo()` and `Foo foo() throws MyError` and are pretty much isomorphic.
https://github.com/Kotlin/KEEP/blob/master/proposals/stdlib/...
-
Project Valhalla: A look inside Java's epic refactor
Nice. So for example, it looks like Kotlin has a nearly identical feature at the language level which will be optimizable when Valhalla ships: https://github.com/Kotlin/KEEP/blob/master/notes/value-class...
> In the future, in a Valhalla-capable JVM, JVM primitive classes will enable efficient representation of Kotlin value classes with an arbitrary number of underlying fields on JVM.
-
A note from our sponsor - SaaSHub
www.saashub.com | 9 Jun 2026
Stats
Kotlin/KEEP is an open source project licensed under Apache License 2.0 which is an OSI approved license.
The primary programming language of KEEP is Markdown.