Hacker News new | ask | show | jobs
by bri3d 1619 days ago
ASN.1 struggles because the word "ASN.1" can name a lot of different implementations with different nuances, and a "complete" ASN.1 implementation is a massive and hazardous undertaking which has left many with a sour taste. Meanwhile, ProtoBufs and Thrift work off of more constrained and well-versioned interfaces.

Honestly, ASN.1 with semantic versioning at the protocol level would probably have been as robust and useful as Protobufs. If ASN.1 had been forked into "ASN.1 3.0 without 10 hazardous and awful 1980s text encodings," it could even be fairly palatable today. Whether the overly expansive nature of ASN.1 is a product of the committee / standards organization design or the timeframe in which it originated is certainly an interesting philosophical question.

3 comments

I used a subset of ASN.1 for a project, and it worked quite well.

ASN.1 versioning in particular is a work of art.

> Meanwhile, ProtoBufs and Thrift work off of more constrained and well-versioned interfaces.

Not so. Protocol buffers is just a TLV encoding, which is bad (see elsewhere in this thread) -- it's just a cut-down ASN.1 and variation on BER, so what.

ASN.1 can "well-version" everything just as well as anything else.

If I have two "proto3" implementations using the same definitions, I trust they work together, generally speaking.

If I have two ASN.1 BER implementations, I sadly can't really trust they work together, because I don't know what parts of "ASN.1" each one implemented.

ASN.1 is a specification. DER/BER were methods to encode that specification.