KEEP VS kotlinx.serialization

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.

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/...

The nitty-gritty is in the KEEP. They show in the end how they considered to add type classes, and then discarded the idea.

Lenses work today. And I think the value class feature will be awesome.

https://github.com/Kotlin/KEEP/blob/master/notes/value-class...

Seems like Kotlin Context Receivers then (https://github.com/Kotlin/KEEP/blob/master/proposals/context-receivers.md).

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.

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...

This will be furthermore simplified with multiple receivers coming very soon

Have you tried this:? https://github.com/Kotlin/kotlinx.serialization/blob/master/docs/serializers.md

It might be possible with a value class

I think kotlinx.serialization might come close, but looks like custom Encoders and Decoders are still experimental.

This is the issue to +1 https://github.com/Kotlin/kotlinx.serialization/issues/1931

Kotlin Serialization

Kotlin Serialization is also a newer option, but doesn't have as much traction.

``` see the docs

It makes sense for some use cases but the vast majority of use cases, parsing overhead is simply not a concern. Mobile phones are fast, networks have plenty of bandwidth (and the savings are marginal), parsers are pretty good.

But done right, binary protocols are sometimes worth the marginal savings they provide. We switched over one of our APIs to use CBOR instead of json. It's a search API that we hit a lot and I wanted to cut down on the bytesize of the responses a little. The savings are not that impressive. But I'll take 10% when i can get it.

Otherwise, this was a pretty simple change. We use kotlinx serialization in a multi-platform library. Basically, all we did is configure it to use CBOR instead of json. https://github.com/Kotlin/kotlinx.serialization/blob/master/... Half hour job. Haven't looked at it since; just works. It supports protobuf as well but it looked like more hassle to set up so we went with CBOR instead.

I'm very much with you on kotlinx.serialization's pain points. And unfortunately, there just doesn't seem to be much of a willingness to fix them. They seem very tied to their polymorphic/contextual serialization model, despite all the problems it causes.