Yeah, seems pretty stable by now. There are quite a few official libraries, and I'm sure they all took a back seat to K2 until earlier this year. The roadmap shows a focus on ktor, exposed, kotlinx-datetime, and kotlinx-io. So this one might stay in its current state for a bit.
Haha, it sure does! It tripped up the transcribing software at least once, but I think I caught them all, so hopefully the subtitles are all correct. 😂
I'm guessing that's the approach that most developers take. Just gotta watch out for that shared mutable state - thankfully if you're targeting JVM, you've at least got some options for synchronized or concurrent collections.
Its not Kotlins Design, its Javas Design. Kotlin was designed with the intention to give java developers a smooth opportunity to switch to Kotlin. So you have those Java elements in Kotlin still today. Everything Kotlin designed completely on its own has a much higher quality level. But as company you cant throw the industry standard java with all its existing libraries and products away when you want people to take you serious. And they did a great job in solving the dilemmas between Java and Kotlin, as best as possible.
This is why Compose by default does not treat `List` as stable since it may actually be mutable.
And that’s the reason I use it in my app state - to get stable.
why is this api still unreleased?
Yeah, seems pretty stable by now. There are quite a few official libraries, and I'm sure they all took a back seat to K2 until earlier this year. The roadmap shows a focus on ktor, exposed, kotlinx-datetime, and kotlinx-io. So this one might stay in its current state for a bit.
Awesome 👍
"a MutableList" sounds awfully similar to Immutable list 😅
Haha, it sure does! It tripped up the transcribing software at least once, but I think I caught them all, so hopefully the subtitles are all correct. 😂
Yeah, "ReadOnly" is a better choice imho.
I just treat my mutable list carefully and that's it. Immutability is mental 😅
I'm guessing that's the approach that most developers take. Just gotta watch out for that shared mutable state - thankfully if you're targeting JVM, you've at least got some options for synchronized or concurrent collections.
Yeah, but you never know what other users of your code/API might do. 😄
just one more example of how kotlin is badly designed
Its not Kotlins Design, its Javas Design. Kotlin was designed with the intention to give java developers a smooth opportunity to switch to Kotlin. So you have those Java elements in Kotlin still today. Everything Kotlin designed completely on its own has a much higher quality level. But as company you cant throw the industry standard java with all its existing libraries and products away when you want people to take you serious. And they did a great job in solving the dilemmas between Java and Kotlin, as best as possible.
@@teenriot-de ahaha, very funny
@@teenriot-de True.