You can generate those conversions, most people do.

But also, you shouldn’t think of it as writing the same type twice! If you couple your external API and your internal data model you are greatly restricting your domain modelling cability. Even in languages where JSON serialisation works with reflection I would recommend having a distinct definition for the internal and external structure so you can have the optimal structure for each context, dodging the “lowest common decimator” problem.

I understand your point, and I agree with it in most contexts! However, for the specific use case where one assumes that the client and server are running the exact same code (and the client auto-refreshes if this isn't the case), and where serialization is only used for synchronizing between the two, decoupling the state from it's representation on the wire doesn't really make sense.

Totally. This is where I would generate them.

>You can generate those conversions, most people do.

Hi, what do people use to generate them, I found gserde (edit: and glerd-json)

There’s several options, depending on what you want. The most commonly used option is the language server.

Oh nice, didn't know about it. (I have migrated from vim to neovim and half of it doesn't work for me yet)

I wonder why this is preferred over codegen (during build), possibly using some kind of annotations?

We've not had any proposals for a design like that. We are open to proposals though! I wrote a blog post detailing the process here: https://lpil.uk/blog/how-to-add-metaprogramming-to-gleam/

The language server code action :)

This is also what really annoyed me when I tried out Gleam.

I'm waiting for something similar to serde in Rust, where you simply tag your type and it'll generate type-safe serialization and deserialization for you.

Gleam has some feature to generate the code for you via the LSP, but it's just not good enough IMHO.

Multiple of such tools exist and have done for years. Serde isn’t a Rust-core project, and similarly the Gleam alternatives are not Gleam-core.

Rust has macros that make serde very convenient, which Gleam doesn't have.

Could you point to a solution that provides serde level of convenience?

Edit: The difference with generating code (like with Gleam) and having macros generate the code from a few tags is quite big. Small tweaks are immediately obvious in serde in Rust, but they drown in the noise in the complete serialization code like with the Gleam tools.

> Rust has macros that make serde very convenient, which Gleam doesn't have.

To be fair, Rust's proc macros are only locally optimal:

While they're great to use, they're only okay to program.

Your proc-macro needs to live in another crate, and writing proc macros is difficult.

Compare this to dependently typed languages og Zig's comptime: It should be easier to make derive(Serialize, Deserialize) as compile-time features inside the host language.

When Gleam doesn't have Rust's derivation, it leaves for a future where this is solved even better.

In Gleam code generators are most commonly used, similar to in C#, Go, or Elm.

Yes, my point is that it's not a good experience.

I would be very interested in hearing about your experience writing Gleam and the problems you have!

We regularly collect feedback and haven’t got problems reported here, so your feedback saying otherwise would be a useful data point.

I might try to collect my thoughts somewhere when I get some time over.

Thank you for Gleam btw, I do really like the rest of the language.

Also. The lisp cam now generate serialisers and deserializers for some types iirc.