Out of curiosity what is the current state of Helios Is ther kotlinlang #arrow-contributors

Atm, I don't think there are no plans to finish Helios. It was put on hold because there was not strong strategy to automatically derive `Encoder`/`Decoder` at compile time. I was planning to port the Json DSL to KotlinX Serialization (it should also be possible to port it to any library that has a

Json

model) since that is the library I've been using mostly as an alternative. What are the things, in particular, you like about Helios? I assume the type-safety in the `Encoder`/`Decoder` ?

😢 1

mitch

05/13/2021, 9:08 PM

Yeah i really like the typesafety and explicitness that Helios gives. We are mainly using Jackson at the moment and tbh all the runtime magic that it does really scares me. I created a small

DecodeJson<out A>

typeclass, pretty much stolen from helios, to operate on Jackson's JsonNode. It's to be used for decoding classes like this. Jackson would've just happily bypass the validation.

@JsonDeserialize(using = EmailAdress.Companion.Deserializer)
class EmailAdress private constructor(val value: String) {
  companion object {
    fun fromString(value: String): Validated<Nel<Violation>, EmailAdress>
    val decodeJson: DecodeJson<EmailAdress> = DecodeJson.string().flatMap { ... }
    class Decoder : DecodeJackson(decodeJson)
    
  }
}

With Helios it would have to be compiled instead

I remember looking into kotlinx.serialization and i wasn't sold either.

simon.vergauwen

05/19/2021, 7:37 AM

Yes, they all have the same issue of blowing up at runtime afaik. This is sadly still blocked by better compiler plugin support afaik.

KotlinX Serialization should however also be compile-time-safe. While it's not enforced in its API like in Helios, it's still verified at compile time that all serializers are present. So that prevents the runtime surprises you can encounter with Jackson.

2 Views

#arrow-contributors Join Slack