The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning. Learn more →
KEEP Alternatives
Similar projects and alternatives to KEEP
-
-
compose-multiplatform
Compose Multiplatform, a modern UI framework for Kotlin that makes building performant and beautiful user interfaces easy and enjoyable.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
kotlin-multiplatform-libsodium
A kotlin multiplatform wrapper for libsodium, using directly built libsodium for jvm and native, and libsodium.js for js targets.
-
-
kotlindl
High-level Deep Learning Framework written in Kotlin and inspired by Keras
-
kotlin-result
A multiplatform Result monad for modelling success or failure operations.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
kotlin-power-assert
Kotlin compiler plugin to enable diagrammed function calls in the Kotlin programming language
-
-
koin
Koin - a pragmatic lightweight dependency injection framework for Kotlin & Kotlin Multiplatform
-
swift-evolution
This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
-
jspecify
An artifact of fully-specified annotations to power static-analysis checks, beginning with nullness analysis.
-
-
kotlinx.serialization
Kotlin multiplatform / multi-format serialization
-
kotlinx-nodejs
Kotlin external declarations for using the Node.js API from Kotlin code targeting JavaScript
-
-
-
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
KEEP reviews and mentions
-
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.
-
Unchecked Java: Say Goodbye to Checked Exceptions Forever
Most other languages agree that checked exceptions are not good by not having them.
As for alternatives, Try/Result and similar monads have decent adoption even in Java, but personally I quite like the Kotlin philosophy [1] to not have generic error containers and either use runtime exceptions or make failures of the return type.
[1] https://github.com/Kotlin/KEEP/blob/master/proposals/stdlib/...
- Is runCatching in use in any of your projects ? My team is abusing it
-
More on OOP: Polymorphism this time
The nitty-gritty is in the KEEP. They show in the end how they considered to add type classes, and then discarded the idea.
-
Making Lenses Practical in Java
Lenses work today. And I think the value class feature will be awesome.
https://github.com/Kotlin/KEEP/blob/master/notes/value-class...
-
Adding Coeffect System to Java with Project Loom
Seems like Kotlin Context Receivers then (https://github.com/Kotlin/KEEP/blob/master/proposals/context-receivers.md).
-
Rust: A Critical Retrospective
Kotlin has value classes. Here's a good overview of how they work in Kotlin: https://github.com/Kotlin/KEEP/blob/master/notes/value-class...
That document is a few years old now and was intended as a design document. But Value classes shipped with Kotlin 1.5. Apparently they are compatible with the project Valhalla value objects that will be added to the JVM at some point. So, this stuff is coming.
I had to look it up because even though I write Kotlin a lot, value classes are not something I have used at all. Looks useful but not that big of a deal and doesn't really solve a problem I have. Data classes and records (in Java) are a bigger deal IMHO.
In practice, the way you deal with immutability in Kotlin is to keep most of your data structures immutable by default unless they need to be mutable. E.g. there's a List and a MutableList interface. Most lists are immutable unless you create a MutableList. Same with val vs. var variables. Val variables can't be reassigned and you kind of use var only by exception when you really have to. The compiler will actually warn you if you do it without good reason. A data class with only vals can't be modified. Java is a bit more sloppy when it comes to mutability semantics. It has records now but all the fields have setters by default. It has var but no val assignments (you can use final to force this but few people do). And so on.
Semantically this is not as strong as what Rust does of course but it's good enough to make e.g. concurrency a lot easier. Mostly, if you avoid having a lot of mutable shared state, that becomes a lot easier.
You could imagine a Kotlin like language with much stronger semantics implementing borrow checking instead of garbage collection. It wouldn't be the same language of course but I don't think it needs to be very different. Using it would not be a massively different.
-
Java record pattern matching in JDK 19
I'd be very interested in a comparison between scala 3 using/given and Kotlin new context receivers https://github.com/Kotlin/KEEP/blob/master/proposals/context...
- Why no one recommends the use of the standard library's Result class but a custom sealed class approach?
-
[Question][Kotlin] Dexter Runtime Permissions development has stopped, whats the alternative?
This will be furthermore simplified with multiple receivers coming very soon
-
A note from our sponsor - WorkOS
workos.com | 28 Mar 2024
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.