kotlindl VS kotlinx.serialization

This is a really nice sample app (works out of the box) that Jetbrains have made to showcase the capabilities of this Kotlin Deep Learning library https://github.com/Kotlin/kotlindl

There are Java bindings for TensorFlow, but that's quite low level. I tried to see if I can get some Keras API for Scala, but I'm no expert and haven't had enough time to invest in this, so it's stuck in alpha. Maybe I develop it slow burning over the next year. A bit envious that Kotlin has a Keras-like library.

Could you please add an issue with your use-case and proposed solution? Or write here more details. Do you need just serialization to objects in memory? or just in bytes?

Introducing version 0.3 of our deep learning library, KotlinDL.

The answer to the second question (from the GitHub page):

I'm not in Machine Learning but maybe KotlinDL ?

While KotlinDL seems to be a good solution by Jetbrains, I would personally stick to Java frameworks like DL4J for a better community support and likely more features.

For deep learning this is your best bet: https://github.com/jetbrains/kotlindl

Please, visit our tutorials and examples for KotlinDL. It covers all possible use-cases for AI implementation at this moment.

Regarding AI: currently, you implement neural networks for solving classification and regression tasks for tabular data, or in Computer Vision with Kotlin Deep Learning Library (KotlinDL).

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.