News for hackers. Stuff that matters.
Re:Gobs of data (2011) by lifthrasiir on Monday December 04, 2023 @08:16AM (#38516839)
Yeah, after years of dealing with language-specific serialization formats---and inadvertently learning internals of them (including Go gob, Python pickle and PHP serialize), I'm over. And gob is not even a schematic serialization format (i.e. you don't need to define a schema beforehand). There is some interesting idea, but that's all. Use a well-known extensible schemaless serialization format with some extensibility if you really need.
Re:Gobs of data (2011) by packetlost on Monday December 04, 2023 @09:52AM (#38517973)
I'm in the same boat. Not to mention security concerns that often crop up in (interpreted) language specific deserialization (I'm looking at you, pickle, thinly veiled `eval()`). I agree that CBOR should generally be the serialization tool of choice for self-describing data (ie. in places where you might otherwise choose JSON).

And if your language of choice doesn't have a CBOR lib, CBOR is fairly easy to implement and writing a encoder/decoder is very fun! I recently completed my implementation for the Gerbil Scheme language last week [0].

[0]: https://github.com/chiefnoah/gerbil-cbor

Re:Gobs of data (2011) by twotwotwo on Monday December 04, 2023 @11:46AM (#38519555)
Yep, I very much agree with this. It's probably inevitable that languages with reflection grow some kind of language-specific serialization format because a) they can and b) there's often some use case where it looks handy to have a format adapted to the quirks of the language. Plus, when some of these bespoke formats were created, the world hadn't converged as much as it has now around a few common text and binary formats.

But now the interoperable serialization formats have a lot more energy spent on tools and such, and the formats are better-specified, to the point that you probably want to use them even where interoperability with other stuff doesn't force it.