Out of curiosity, what is the current state of Hel...
# arrow-contributors
m
Out of curiosity, what is the current state of Helios? Is there any plans to support that in newer arrow versions? That is such a great library..
s
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
m
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.
Copy code
@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.
s
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.