Comment by pyrolistical

Comment by pyrolistical 2 days ago

22 replies

Compressed JSON is good enough and requires less human communication initially.

Sure it will blow up in your face when a field goes missing or value changes type.

People who advocate paying the higher cost ahead of time to perfectly type the entire data structure AND propose a process to do perform version updates to sync client/server are going to lose most of the time.

The zero cost of starting with JSON is too compelling even if it has a higher total cost due to production bugs later on.

When judging which alternative will succeed, lower perceived human cost beats lower machine cost every time.

This is why JSON is never going away, until it gets replaced with something with even lower human communication cost.

barremian 2 days ago

> When judging which alternative will succeed, lower perceived human cost beats lower machine cost every time.

Yup this is it. No architect considers using protos unless there is an explicit need for it. And the explicit need is most times using gRPC.

Unless the alternative allows for zero cost startup and debugging by just doing `console.log()`, they won't replace JSON any time soon.

Edit: Just for context, I'm not the author. I found the article interesting and wanted to share.

  • duped a day ago

    Print debugging is fine and all but I find that it pays massive dividends to learn how to use a debugger and actually inspect the values in scope rather than guessing which are worth printing. It also is useless when you need to debug a currently running system and can't change the code.

    And since you need to translate it anyway, there's not much benefit in my mind to using something like msgpack which is more compact and self describing, you just need a decoder to convert to json when you display it.

    • themafia a day ago

      > rather than guessing

      I'm not guessing. I'm using my knowledge of the program and the error together to decide what to print. I never find the process laborious and I almost always get the right set of variables in the first debug run.

      The only time I use a debugger is when working on someone else's code.

      • duped a day ago

        That's just an educated guess. You can also do it with a debugger.

    • bdavisx a day ago

      Debuggers are great when you can use them. Where I work (financial/insurance) we are not allowed to debug on production servers. I would guess that's true in a lot of high security environments.

      So the skill of knowing how to "println" debug is still very useful.

theshrike79 a day ago

Also: debugging

You (a human) can just open a JSON request or response and read what's in it.

With protobuf you need to build or use tooling that can see what's going on.

  • generativenoise 15 hours ago

    It is only "human readable" since our tooling is so bad and the lowest common denominator tooling we have can dump out a sequence of bytes as ascii/utf-8 text somewhat reliably.

    One can imagine a world where the lowest common denominator format being a richer structured binary format where every system has tooling to work with it out of the box and that would be considered human readable.

[removed] 2 days ago
[deleted]
esafak 2 days ago

It won't go away in the same way COBOL won't. That does not mean we should be using it everywhere for greenfield projects.

morshu9001 2 days ago

I've gone the all-JSON route many times, and pretty soon it starts getting annoying enough that I lament not using protos. I'm actually against static types in languages, but the API is one place they really matter (the other is the DB). Google made some unforced mistakes on proto usability/popularity though.

  • almosthere a day ago

    why are you against static types in languages?

    I once converted a fairly large JS codebase to TS and I found about 200 mismatching names/properties all over the place. Tons of properties we had nulls suddenly started getting values.

    • MobiusHorizons a day ago

      Sounds like this introduced behavior changes. How did you evaluate if the new behavior was desirable or not? I’ve definitely run into cases where the missing fields were load bearing in ways the types would not suggest, so I never take it for granted that type error in prod code = bug

      • sevensor a day ago

        The most terrifying systems to maintain are the ones that work accidentally. If what you describe is actually desired behavior, I hope you have good tests! For my part, I’ll take types that prevent load-bearing absences from arising in the first place, because that sounds like a nightmare.

        Although, an esoteric language defined in terms of negative space might be interesting. A completely empty source file implements “hello world” because you didn’t write a main function. All integers are incremented for every statement that doesn’t include them. Your only variables are the ones you don’t declare. That kind of thing.

      • almosthere 21 hours ago

        it was desirable because our reason for the conversion was subtle bugs all over the place where data was disappearing.

    • morshu9001 a day ago

      It costs time, distracts some devs, and adds complexity for negligible safety improvement. Especially if/when the types end up being used everywhere because managers like that metric. I get using types if you have no tests, but you really need tests either way. I've done the opposite migration before, TS to JS.

      Oh I forgot to qualify that I'm only talking about high level code, not things that you'd use C or Rust for. But part of the reason those langs have static types is they need to know sizes on stack at compile time.

DyslexicAtheist 2 days ago

> People who advocate paying the higher cost ahead of time to perfectly type the entire data structure AND propose a process to do perform version updates to sync client/server are going to lose most of the time.

that's true. But people also rather argue about security vulnerabilities than getting it right from the get-go. Why spend an extra 15 mins effort during design when you can spend 3 months revisiting the ensuing problem later.

  • jstanley 2 days ago

    Alternatively: why spend an extra 15 mins on protobuf every other day, when you can put off the 3-month JSON-revisiting project forever?

    • OccamsMirror a day ago

      I use ConnectRPC (proto). I definitely do not spend any extra time. In fact the generated types for my backend and frontend saves me time.