Hacker News Reader

Comment by egorfine | Hacker News Reader

> import JSON (something I use as little as possible)

This makes me wonder what world of development she is in. Does she prefer SOAP?

JSON is slow, not particularly comfortable for humans to work with, uses dangerous casts by default, is especially dangerous when it crosses library or language boundaries, has the exponential escaping problem when people try to embed submessages, relies on each client to appropriately validate every field, doesn't have any good solution for binary data, is prone to stack overflow when handling nested structures, etc.

If the author says they dislike JSON, especially given the tone of this article with respect to nonsensical protocols, I highly doubt they approve of SOAP.

> JSON is [...]

What would you suggest instead given all these cons?

Fixing all of those at once might be a bit too much to ask, but I have some quick suggestions. I'd say for a more robust JSON you could try Dhall. If you just want to exchange lumps of data between programs I'd use Protobuf. If you want simple and freeform I'd go with good old sexps.

https://github.com/dhall-lang/dhall-lang

https://protobuf.dev/

https://en.wikipedia.org/wiki/S-expression

Suggesting protobuf as alternative to JSON is crazy talk.

You must not have seen the abject misuses of JSON I've seen then

And this is why I was asking the question in the first place.

Not that I'm a fan of JSON, but I fail to conceive anything better as a general purpose protocol.

Her webserver outputs logs in protobuf, so I think she likes binary serialization.

Given her experience and work history, it's much more likely that she views any text-based protocol as an unnecessary abstraction over simply processing raw TCP.

Is this a joke? I don't even know where to begin with this comment... It reads like a joke, but I suspect it's not?

TCP is just a bunch of bytes... You can't process a bunch of bytes without understanding what they are, and that requires signaling information at a different level (ex - in the bytes themselves as a defined protocol like SSH, SCP, HTTP, etc - or some other pre-shared information between server and client [the worst of protocols - custom bullshit]).

parent mentioned SOAP as an alternative to JSON. I was being glib about the fact that the engineer who wrote this blog post is a highly-regarded sysadmin and SRE who tinkers on things ranging from writing her own build systems to playing with RF equipment.

Sure. Between the two comments, I think the SOAP joke is a lot better.

> or some other pre-shared information between server and client [the worst of protocols - custom bullshit])

Why is this worse than JSON?

"{'protected': {'protected': { 'protected': 'QABE' }}}" is just as custom as 66537 imo. It's easier to reverse engineer than 66537 but that's not less custom.

__attribute__(packed) structs with an enum at the front indicating their type. The receivers use a switch to figure out which sub-message to interpret the strict as...

It isn't pretty and you better be able to control the rollout of both sides because backwards compatibility will not be a thing. But I'll take it over a giant pile of code generation in many circumstances

Reply on news.ycombinator.com