Is there any chance that Jetbrains would consider absorbing <benasher44/uuid> into a first party `ko...

# multiplatform

[kevin.cianfarini]

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 🙂

[Big Chungus]

Maybe not in stdlib, but official kotlinx side lib would be nice to have

[kevin.cianfarini]

yes! I totally agree. There are plenty of complications with it living in the stdlib that a first party library would solve

[Sebastian Sellmair [JB]]

Just out of curiosity: what is wrong with using the library maintained by Ben? Seems pretty well maintained to me!

[Big Chungus]

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.

[Big Chungus]

Otherwise you end up with multiple transitive uuid implementations in the project.

[Big Chungus]

It could be just you forking Ben's lib and renaming it (assuming Ben is ok with it) to begin with.

[kevin.cianfarini]

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

[Oleg Yukhnevich]

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

[Big Chungus]

Totally agree. For logging especially, I'd love yo at least see some common interfaces in stdlib. Actual implementations can be 3rd party then.

[Big Chungus]

That way one can create expect actuals and mix'n'match different implementations to cover their target set

[kevin.cianfarini]

While I agree with all of this, these are pains of an immature ecosystem. Can we keep this thread relevant to uuid?

[Big Chungus]

One step at a time...

[kevin.cianfarini]

Exactly :)

[hfhbd]

BTW: https://youtrack.jetbrains.com/issue/KT-43042