4 ms·
Ok so without taking away from this library, what's wrong with using a fully binary format of your own? No string parsing, no nonsense, just binary data. It se
by naikrovek 7y ago
Ok so without taking away from this library, what's wrong with using a fully binary format of your own? No string parsing, no nonsense, just binary data. It seems like people are becoming afraid of plain binary, and I don't understand why. It's so easy, plain binary is very small, and is extremely easy to parse when compared to anything with text in it, especially if you have to support multiple encodings.
1.) Decide upon a binary format.
2.) Use it.
No 3rd party libraries required; you could write writer or reader code for a Commodore 64, if you had to.
Keep it simple. I suspect any simple "type-length-value" type of binary file format would be written or read at least as quickly as this, without third party code.
- bufferoverflow 7y agoIt's unlikely you can write a serializer/unserializer that is faster than what we already have. And bug-free on complex objects.
- naikrovek 7y agoIt's unlikely that I can? That's a strong statement. Binary file formats are not difficult. Writing code that does the right thing is also not difficult. I am opposed to the blind use of libraries like this. Developers need to understand what they're doing and how what they're doing is being done at a reasonably low level if they ever hope to become better developers. Masking it all away behind a third party library is not how you understand the code that's running on your systems.
- bufferoverflow 7y agoHow about you write a simple binary substitute that covers just the standard JSON (number, string, true, false, null, array, object), see how you do compared to the existing JSON serializeres / deserializers and MsgPack.
- enitihas 7y agoCommunication. The new guy joining your team can be immediately productive with JSON, protobuf, etc, but will take some time to understand the homegrown format. Also much more error prone. Most teams don't want to be writing binary encoders and decoders as that's not where their expertise lies, and would much rather focus their time on business features.
- com2kid 7y agoBeen there, done that, switched to proto bufs because maintaining 4 different parsers in 3 different languages was a pain. Also proto bufs gave us those nice schemas, the code gen, and easy forwards/backwards compat. Was it slower? Yeah. Was it crap ton less work? Yup.
- naikrovek 7y agoI haven't had the same experience I guess. Keeping binary readers and writers maintained was a very small portion of the time I spent on the applications which used those writers and readers.
- com2kid 7y agoIn our case we were adding new APIs and expanding our format rapidly for years on end. After the 20th or so miscommunication that lead to a week+ delay because someone got a field order wrong, or in one case because we hit a bug in the C# compiler in regards to struct layouts (!!) we switched away from rolling our own.
- hyperpallium 7y agofunPOV: Text is a binary format. Just standard, with tooling.