Hacker News Reader

Comment by lawn | Hacker News Reader

I'm not sure that I like choice to generate decoder code instead of introducing a macro system that can be used to generate the code behind the scenes.

Consider what would happen if you have a larger json object you want to decode (which is often the case). This would require a substantial amount of code that you later would have to read through (being vary of minor changes).

In contrast to Rust's approach where you just have a few notations you can quickly scan through and identify anything unusual.

This is honestly a major turnoff for me with Gleam and doesn't make me want to use the language for anything where I need to handle json (despite all the other things I appreciate about the language).

View on HN

I like comptime concept over macros, because on Rust you need to annotate a type with the macro derive or manually implement the encoder or decoder, while in Zig for example, (I'm not experienced with Zig, but it seems that is possible to do this) it should be possible to have the encode and decode method to implement the logic to do the work, that means that the boilerplate is generated only when needed and also should work for third party types where you don't have control over.

You might be interested in this: https://lpil.uk/blog/how-to-add-metaprogramming-to-gleam/

> and identify anything unusual.

What strangeness are you expecting to encounter?

The type system should help you if you change any fields. It's hard for me to image this causing anything beyond slight annoyance at the small additional maintenance required as your types evolve.

Rust's serde crate defines a bunch of attributes that are commonly used: https://serde.rs/attributes.html

For example:

* Rename keys to lowercase, uppercase, snake_case, etc.

* Deserialize incoming data with a "type" field that specifies what enum variant it should target.

* Default to a value if the key doesn't exist.

* Skip serializing if it's None (or include it).

* Skip a field completely.

And the list goes on.

With a declarative macro system all attributes are immediately visible so I know what to expect but with Gleam I'd have to carefully read through the code every time to understand what it does. There's a ton of cognitive overload here that doesn't have to exist.

Remember that it's user data we're parsing so we'd have to maintain (update and debug) the code continually, which means reading through the boilerplate again and again.

Reply on news.ycombinator.com