> Yes writing the definitions by hand can time consuming and error-prone

With the proper environment, this isn't that time consuming or error-prone anymore, based on my recent experiments. When I initially started exploring with the library, it was a bit difficult at first (mostly because back then there was no reference documentation and you had to rely on tests), but after some time API gets easy to understand. Actual type definitions remain very small because of the derive macros.

Nowadays LLMs are pretty good at handling ASN.1 definitions. If you provide the context correctly, by giving e.g. the reference from the rasn's README, maybe even some type definitions from the library itself, and just give the ASN.1 schemas, LLMs can generate the bindings very accurately. The workflow switches from being the manual writer to be just the reviewer. Compiler is also already good at generating the basic definitions on most cases.

I really like the idea that then standard can be published as a crate, and nobody needs to ever touch for the same standard again, unless there is a bug or standard gets an update. Crates can be then used with different open-source projects with the same types. What I known about commercial ASN.1 usage, different companies buy these products to compile the same standards over and over again.

I bet that there are no many companies that define their internal APIs with ASN.1 and buys commercial tool just to support ASN.1 usage in their own business, without any international standards included.

> > Yes writing the definitions by hand can time consuming and error-prone

> With the proper environment, this isn't that time consuming or error-prone anymore, based on my recent experiments.

If you have modules with automatic, and manual IMPLICIT and EXPLICIT tagging and you fail to translate those things correctly then you can trivially make mistakes that cause your implementation to not interoperate.