To be fair, in practice people don't choose gRPC as a protocol and serialization standard so much as they choose preexisting gRPC libraries and code generators. Open source ASN.1 tooling sucks while Google maintains gRPC tooling for a great many languages. This is why gRPC, Thrift, etc have so much more mindshare than ASN.1 in the open source community. The only good open source ASN.1 (DER, PER, etc) code generator for C is asn1c. I believe Java has a couple of good libraries. But other than that ASN.1 tooling is a horrible train wreck of broken or abandoned projects that don't provide adequate ASN.1 tooling. Many people rely on OpenSSL's DER library, but its far too low-level. AFAICT, the same is true for Python and other high-level languages--no open source projects where can you pass an ASN.1 specification to generate (at compile-time or run-time) a full serializer and deserializer.

There are plenty of commercial, proprietary ASN.1 tooling solutions out there. Presumably it's why ASN.1 has persisted as long as it has in industry. Even Fabrice Bellard sells a commercial solution: https://bellard.org/ffasn1/ When you have access to good tooling ASN.1 is arguably superior to the open source alternatives as there aren't as many broken corner cases that can cause interoperability problems.

We only have ourselves to blame. If I ever have time I want to write an ASN.1 spec parser using LPeg that can generate LPeg-based DER parsers. I already have a fairly comprehensive LPeg-based DER parser for PKIX messages, but generating that from an ASN.1 spec is a significant step up in conceptual complexity. While I've written more than my fair share of parsers before, I've never written a proper parser generator, so it's a steeper hill to climb for me even though I already have more ASN.1 experience than most.

I gather the protobuf/gRPC implementations are quite good for a lot of languages, but I can tell you typescript doesn't seem to be one of them. There's an etcd client for node which doesn't seem to be actively maintained, and I only needed a few things out of etcd, so I figured I'd just generate a gRPC client and build my own library [0] to do what I needed. This was not fun. I got all kinds of crazy errors about missing definitions, and I ended up having to copy paste .proto files from a bunch of random google projects into my repo to make this all work. Maybe I'm just doing it completely wrong? :P

[0](https://github.com/jwalton/etcd3-ts)

Do you have any code samples that demonstrate the code generator, instrumentation, and observability tools for ASN.1?

How do I code gen clients/servers for Java, Python, Golang, C++, Node, PHP, etc. How can I instrument distributed tracing for requests? How do I talk to these services from my web frontend (grpc web equivalent)? How do I talk to these from my embedded system (proto lite equivalent)?

How is Protobuf 'overly complicated'? I'm not talking about gRPC here - because trying to compare bare ASN.1 and gRPC is just dishonest.

This is especially rich when you're comparing protobuf to ASN.1 - which is probably mostly known for having dozens of competing, obscurely-named encoding formats to choose from. And for them being so complex to implement that it regularly causes bugs and security issues in software...

This seems like a very high level spec, not a library or toolkit. There's also zero mention of practical concerns like protocol evolution, a canonical wire encoding etc.

ASN.1 is indeed a spec. You'd need to find a library to use it, and there are more in C than in whatever fancy modern language you're probably using. But, there are lots to choose from.

There's multiple canonical wire encodings. XER is the "XML encoding rules" if you want something human readable. "BER" is the binary format, although it has some ambiguities so there's "DER", the Distinguished Encoding Rules, which resolves a lot of that by using essentially a subset of BER and specifying how you should behave in various corner cases. In practice, you want to write your messages as DER, but accept messages from other parties using the full BER.

It's an older standard, but it's used heavily in telecom. To pick an example, if you make a cell phone call, especially out in the sticks somewhere, there's probably going to be a media gateway controller that figures out how to route your call without decompressing and recompressing it a bunch of times, and it talks to the various devices routing your call over H.248, which is specified entirely in ASN.1.