Hacker News new | past | comments | ask | show | jobs | submit login

Floating point numbers are INCREDIBLY complicated to scan (and print).

https://code.woboq.org/userspace/glibc/stdio-common/vfscanf-...

Compare that with reading 4 bytes directly into an ieee754 float32.

If your messages are short, the benefits of fast codecs are outweighed by the inefficiencies in the communication system (most of your time, processing power and bandwidth are taken up by setting up and tearing down the communication medium). If it takes 7 "administration" packets to send 1 data packet, your codec won't be your bottleneck (in which case you probably don't care about efficiency anyway, and this discussion is not for you).




It's not that bad, maybe 10x of nothing.

There are much bigger fish to fry when building a large network solution, most prominently getting the thing to be debuggable on live machines!


>large network solution

You basically restrict networking to big monopolists, like Google, but Google likes binary protocols, like grpc, http2 and quic. And if you have a bug in a complex parser, having text won't help debuggability, because the bug is not in text.


I make my own open-source systems, google is going down a very wrong path recently with defaulting to HTTPS and deprecating HTTP.

GRPC, HTTP2, HTTPS, WebSockets, QUIC (HTTP3) are all desperate attempts for job safety. HTTP/1.1 is good enough for 99% of human network requirements.

If you are depending on google, make sure you have alternatives because they are VERY unreliable long term.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: