3 ms·

Gleam looks very interesting. However I don't see any support for annotations (metadata based code generation) or reflection. I am curious if these are things t

by lf-non 3y ago

Gleam looks very interesting. However I don't see any support for annotations (metadata based code generation) or reflection. I am curious if these are things that just haven't been implemented yet or it is an explicit goal to avoid such features to keep the language simple.

transfire 3y ago
I think it is intentional, which personally I like.
- 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 ago
      Yeah 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.
lpil 3y ago
We're interested in some form of metaprogramming or code generation in future, but we do not yet have a design yet that we're happy enough with to make the official one. It's important to us to keep the language easy to understand and compilation very fast. It's very much an area of R&D, and we hope that folks share any ideas they may have. For example, I'm unfamiliar with Kotlin's system and it would be useful if folks could share any vision for how it could be applied to Gleam.
- lf-non 3y ago
  That's great to know. Will be looking forward to what you come up with. Kotlin recommend ksp [1] but underlying platform's reflection is also available. I am not sure it (or something similar) will be a great fit for gleam but have been planning to explore it deeper for some time. [1] https://kotlinlang.org/docs/ksp-overview.html https://kotlinlang.org/docs/ksp-overview.html

by lf-non 3y ago

transfire 3y ago

I think it is intentional, which personally I like.

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

lpil 3y ago

We're interested in some form of metaprogramming or code generation in future, but we do not yet have a design yet that we're happy enough with to make the official one. It's important to us to keep the language easy to understand and compilation very fast. It's very much an area of R&D, and we hope that folks share any ideas they may have. For example, I'm unfamiliar with Kotlin's system and it would be useful if folks could share any vision for how it could be applied to Gleam.

lf-non 3y ago
That's great to know. Will be looking forward to what you come up with. Kotlin recommend ksp [1] but underlying platform's reflection is also available. I am not sure it (or something similar) will be a great fit for gleam but have been planning to explore it deeper for some time. [1] https://kotlinlang.org/docs/ksp-overview.html https://kotlinlang.org/docs/ksp-overview.html