Live data from Hacker News

Bebop: An Efficient, Schema-Based Binary Serialization Format

rainway.com

21–30 of 60 posts

Re: Bebop: An Efficient, Schema-Based Binary Serialization Format

#21
Some feedback - maybe I’m being picky but I feel you’ve chosen poorly with regard to the “readonly” keyword in your IDL. Or least I’d prefer if you used the normal type/interface naming conventions. “readonly” and “immutable” are different concepts although often confused. I’m pretty sure “immutable” better describes the behavior in your case.

Re: Bebop: An Efficient, Schema-Based Binary Serialization Format

#22

The article doesn't mention at all how those speedups have been achieved, what tradeoff the format makes and what it is optimized for - which would be the actually interesting part. A link to the benchmark code and description of the data would be nice. It also doesn't show data for FlatBuffer, which is often a lot faster and leaner than ProtoBuf, or for Capt'n Proto. ProtoBuf is not exactly known for amazing perform…

Designing a serialisation format has a lot similarities with designing a programming language: data types, declarative/ease-of-use versus full control, abstractions, static versus dynamic memory areas, optimising representations etc. There is definitely room for a variety of formats depending on the use cases; and many are unhappy with the current incumbent: https://reasonablypolymorphic.com/blog/protos-are-wrong/

But yes, it's a lot of work and they probably should document what the trade-offs are that they have made.

Re: Bebop: An Efficient, Schema-Based Binary Serialization Format

#23

This year's ASN.1 BER. Again

Speaking of which, I’ve never seen a marshaling protocol with as sophisticated a message versioning scheme as ASN.1. The amount of thought that went into specifying how to allow “implementations from the future” to interoperate with those of the past is impressive.

Re: Bebop: An Efficient, Schema-Based Binary Serialization Format

#25

This year's ASN.1 BER. Again

Speaking of which, I’ve never seen a marshaling protocol with as sophisticated a message versioning scheme as ASN.1. The amount of thought that went into specifying how to allow “implementations from the future” to interoperate with those of the past is impressive.

And yet outclassed on any meaningful metric by generic serialization languages? ASN.1 is a programming language in addition to a data transport format opening up many opportunities for security vulnerabilities. Performance is shit because it’s using text to encode everything so that it’s human readable. Similarly parsing is extra complicated and slow for that reason. Serialization/deserialization requires a dedicated library rather than one that can be reused across all tasks. Finally the data representation itself is extremely bloated vs the binary data. It’s impressive in the same way that cassette technology and the neat things people did with them. I really wish some reasonable IDL would just get adopted for standards purposes rather than each standard developing their own.

All other serialization formats using an IDL seem strictly better.

Re: Bebop: An Efficient, Schema-Based Binary Serialization Format

#26

This year's ASN.1 BER. Again

Speaking of which, I’ve never seen a marshaling protocol with as sophisticated a message versioning scheme as ASN.1. The amount of thought that went into specifying how to allow “implementations from the future” to interoperate with those of the past is impressive.

Isn't it amazing? ASN.1 seems like such a low bar to pass, and yet.

Re: Bebop: An Efficient, Schema-Based Binary Serialization Format

#29

This year's ASN.1 BER. Again

I've never done a proper read up on ASN.1 to know when and if to apply it. But i think its biggest obstacle apart from a flashy website is its wikipedia page (https://en.wikipedia.org/wiki/ASN.1). It is just overloaded with concepts that don't seem to be solving my problem, and its not clear what is a must-know and what is not.
Post reply on HN