https://kotlinlang.org logo
Join SlackCommunities
Powered by
Is there any chance that Jetbrains would consider ...
# multiplatform
k
Is there any chance that Jetbrains would consider absorbing benasher44/uuid into a first party 
kotlinx.uuid
library? I know we want to keep the Kotlin stdlib small, but not having an ecosystem default for utilities as universal as UUID makes fragmentation within the ecosystem annoying for library maintainers. I know in the past there was a prior discussion about absorbing the above library into the stdlib, which Jetbrains was receptive to, but it didn't seem to go anywhere. I'd like to revisit this issue 🙂
➕ 16
b
Maybe not in stdlib, but official kotlinx side lib would be nice to have
👍 6
k
yes! I totally agree. There are plenty of complications with it living in the stdlib that a first party library would solve
s
Just out of curiosity: what is wrong with using the library maintained by Ben? Seems pretty well maintained to me!
b
Mainly the fact that it's 3rd party. It's fine for niche functionality, but since UUID is such a crucial part of any language ecosystem, it would be awesome to have a single 1st party library that all the other third party libs link against.
🙏 1
➕ 1
👍 1
Otherwise you end up with multiple transitive uuid implementations in the project.
➕ 1
🙏 1
It could be just you forking Ben's lib and renaming it (assuming Ben is ok with it) to begin with.
🙏 1
k
Agreed. We're looking at using Ben's library in SQLDelight for PostgreSQL functionality. Having a single solution that most (if not all) kotlin devs agree on makes this nicer for library APIs. For example, we're exposing pg date time types through 
kotlinx.datetime
and there was no second thought about it. We'd like to do the same for uuid
🙏 1
o
Otherwise you end up with multiple transitive uuid implementations in the project.
same happens now with both logging and IO libraries in Kotlin ecosystem, which are also crucial part 😔 everyone who need to use multiplatform IO or Logging, create it’s own wrapper… logging: • https://github.com/korlibs/klogger - for korge • https://github.com/MicroUtils/kotlin-logging - ‘slf4j’ wrapper with added later MPP • https://github.com/AAkira/Napier - for android/ios • https://github.com/touchlab/Kermit - for android/ios mainly • https://github.com/Kodein-Framework/Kodein-Log - for kodein stack • https://github.com/ktorio/ktor/tree/main/ktor-utils/common/src/io/ktor/util/logging - for ktor stack io: • https://github.com/korlibs/korio - for korge • https://github.com/caffeine-mgn/pw.binom.io • https://github.com/Kodein-Framework/Kodein-Memory - for kodein DB • https://github.com/square/okio - for okhttp • https://github.com/ktorio/ktor/tree/main/ktor-io - for ktor stack And in addition to multiple dependencies in projects, next problem is target sets. Some libraries supports one set of targets, f.e android + ios, other supports only jvm/js/native, other supports only desktop native targets and so on and so forth IMO, such dependency split is the main problem in Kotlin Multiplatform ecosystem
b
Totally agree. For logging especially, I'd love yo at least see some common interfaces in stdlib. Actual implementations can be 3rd party then.
That way one can create expect actuals and mix'n'match different implementations to cover their target set
k
While I agree with all of this, these are pains of an immature ecosystem. Can we keep this thread relevant to uuid?
👍 1
👌 1
b
One step at a time...
k
Exactly :)
h
6 Views
Open in Slack
PreviousNext
Powered by