Hacker News Reader

Comment by steve_adams_86 | Hacker News Reader

Isn’t manual ser/de pretty common? I like it personally. Being explicit at program boundaries usually means far fewer bugs inside the program. In JS I can pile whatever JSON I want into an object, but eventually I need to throw Zod or something at it to tame the crazy.

Maybe a generic “pile this data into this value and pretend it’s safe” tool might be nice for prototyping.

View on HN

i dont think manual ser/de is common at all, and languages like dart where it was used is a massive pain point for people so much that they are adding macros to the language and the first macro they add is for serialization. whats not explicit about saying hey i have a struct this is the data i expect, serialize/deseralize in this shape, validation is a another but separate concern. in javascript you are not doing anything manually so i'm not sure why thats an example?

I'm a bit confused. How can you control how your data is serialized if not manually? Are there languages that use some kind of magically-figures-it-out layer that negotiates the appropriate serialization on the fly?

Many languages have some kind of macro or codegen system that allows serializing or deserializing based on type definitions. Eg (pseudocode):

    @deriving(json)
    class Person:
      id: int
      name: str

Would give you something like:

    def parse(s: str): Person: ...
    def print(p: Person): str: ...

I see, thanks. I thought maybe we were talking about the choice of json vs something else being automatic and chosen at runtime.

C# (or more precisely .NET libraries) does it using reflection. Attributes let you adjust the behaviour.

Or with build-time source generation (because this specific pattern of reflection is AOT-unfriendly). It's not as convenient if you are using default serializer options, but if you don't - it ties together JsonTypeInfo<T> and JsonSerializerOptions, so it ends up being a slightly terser way to write it. I do prefer the Rust-style serde annotations however.

  record User(string Name, DateOnly DoB);

  [JsonSerializable(typeof(User))]
  partial class SerializerContext: JsonSerializerContext;

  ...
  var user = new User("John", new(1984, 1, 1));
  var response = await http.PostAsJsonAsync(
    url, user, SerializerContext.Default.User);

Sorry I wasn’t clear; I meant to use JavaScript as an example where it isn’t manual.

Despite it being easy to use, I find I inevitably wind up requiring a lot of ceremony and effort to ensure it’s safe. I’m not a huge fan of automatic serialization in that it appears to work fine when sometimes it shouldn’t/won’t. I agree that it’s a lot of effort though. I guess the question is if you want the effort up front or later on. I prefer up front, I guess.

You either trust the input or you don't. If you don't trust your input you need validation like Zod anyway. Parsing untrusted data without validation in Rust or Go is not much better than in JS. You get the basic types checked, but that's all. You need to validate at the boundaries with Rust or Go just the same as with JS. It seems to me that many bloggers of new trendy languages are not aware of validation. A value for name is a string, but how about the length?

That’s a good distinction. I almost always include validation in the process, but you’re right, it’s not inherent to serialization.

In the JavaScript space, Effect offers an awesome package for ser/de which integrates validation. I think it’s my favourite tool in the ecosystem, but I prefer it over options in many other languages as well.

Reply on news.ycombinator.com