4 ms·
Hmm ... to each their own I guess. But while developing backends with Kotlin I attempted to ditch all annotation/reflection/code-generation based libraries for
by lf-non 3y ago
Hmm ... to each their own I guess. But while developing backends with Kotlin I attempted to ditch all annotation/reflection/code-generation based libraries for a while, opting for functional libraries like ktor, exposed etc. But the end result always ended up being a lot more verbose and repetitive.
I now feel that some form of behind-the-scene code-generation or reflection support is generally good to have so that the bulk of the application stays focussed on application logic instead of various dto conversions, mappings, transformations etc. I don't shy away from Quarkus, MapStruct etc. now a days and I think my code is easier to follow because of what they enable.
Typescript is a bit of an exception here because the type system is quite powerful with various type transformation capabilities but Gleam's type system also appears to be quite minimal.
- brabel 3y ago> opting for functional libraries like ktor, exposed etc. KTor kind of relies on Kotlin serialization which uses code generation behind the scenes (which is why you need to apply a plugin on your build system).
- lf-non 3y agoYeah its there by default but then there is nobody forcing the consumer to use it. So in theory we could get the raw body, and then use something like Jackson's ObjectMapper.valueToTree to get an untyped object hierarchy and then convert that to properly typed domain objects through some manually authored utility methods. Nobody does that though because it is super convenient to have a library take care of that boilerplate for you with codegen or reflection which was basically the point of my original comment.