XAMPPRocky

Correct, the compiler allows you to generate the Rust bindings automatically. Worth noting that the compiler is at an earlier stage of development (the library was started six years ago, the compiler started roughly two years ago). So there are features that aren't used or supported by the compiler that are available in the library.

Yes writing the definitions by hand can time consuming and error-prone, but I designed the library in mind around the declarative API to make it easy to both manually write and generate, I also personally prefer writing Rust whenever possible, so nowadays I would sooner write an ASN.1 module in Rust and then if needed build a generator for the ASN.1 textual representation than write ASN.1 directly since I get access to much better and stronger tooling.

Also in my research when designing the crate, there are often requests in other ASN.1 or X.509 libraries to allow decoding semantically invalid messages because in the wild there are often services sending incorrect data, and so I designed rasn to allow you mix and match and easily build your own ASN.1 types from definitions so that when you do need something bespoke, it's easy and safe.

Which part do you think is not substantiated?

They did write about compile-time reflection, their talk was part of the conference[1], and now they’re not doing the talk. That’s enough to me take what they say at face value, especially now that in the wake of this there have been resignations in the leadership.

[1]: https://web.archive.org/web/20230523045330/https://rustconf....

People are free to speak their mind, they don’t have to justify that to you or anyone else.

> Attempting to shame people, without explaining what exactly happened, suggests a hissy fit.

Feels like self-projecting given how much you’re commenting in multiple threads to say “it’s not a big deal”, I don’t think someone who thinks it’s not a big deal would comment and try to argue so much if they actually thought it was.

Whether it’s malice or clumsiness isn’t relevant, it’s poor communication and process, which is the responsibility of leadership.

The project leadership has continuously failed in these areas, and there has only been an effort to improve those things when they’ve been publicly called out. Without people openly communicating leadership failures, problems have often been ignored and maligned.

The "bureaucrats" are elected officials so if people weren't in favour of it, they would stop electing MEPs that vote in favour of it.

All standards about ASN.1 (not including standards that use ASN.1 like MMS) are available for free from the ITU under the X.680 to X.697 series of standards.[0]

[0]: https://www.itu.int/rec/T-REC-X/en

> What are the projects this is used in?

I don't know of any third-party projects that are using it, though from talking to users and looking at the download numbers there are quite a few, they're just closed-source. You can look at the dependent downloads[0] to get an idea of whose using the implementations included with rasn.

> How easy is it to use as a codec layer from other programming languages?

It's as easy as using any Rust code from other programming languages. Rasn is completely IO-agnostic, it works entirely using byte slices (`&[u8]`). So all that should be required is writing a C-friendly layer if doing this by hand, or using a language specific binding library like PyO3 to generate more friendly bindings.

[0]: https://crates.io/crates/rasn/reverse_dependencies

> would be really happy to see some good open source compilers with extensible encoding support being listed here

This is a shameless plug, and not a compiler per se, but it's pretty close[0]. It's a codec framework for ASN.1 in Rust similar to `serde` for other formats if you're aware of that. It uses Rust's traits to define seperate layers for the codec model, and the encoding rules, allowing you to have one model used with many encodings, and share one decoder & encoder for all models. Extensibility just uses the regular Rust `#[non_exhaustive]` attribute. It doesn't support formats like A/UPER yet, but that is coming in the next year. :)

[0]: https://github.com/XAMPPRocky/rasn

> also ASN.1 does not solve futute-extending out-of-the-box. In JSON/bencoding/XML, it's trivial to add another key/element to a dictionary/array/element and allow applications to use it if they can and ignore it otherwise. Okay, TLV looks like it could handle that, but there's nothing about it in the description language itself.

This is wrong. ASN.1 has always had support for "extensibility" out of the box. See section 52 of X.680[0] for complete details but I've included a couple of examples below. Also ASN.1 unlike other IDLs allows encodings to optionally take advantage of whether a type is considered in extensible. For example in PER, a type is a smaller encoding when it is not extensible.

    A ::= INTEGER (0..10, ..., 12) -- A is 0 to 10, or 12.

    -- V1 of B contains `a, b`, V2 contains `a, b, c`
    B ::= SEQUENCE {
        a INTEGER,
        b BOOLEAN,
        ...
        c OCTET STRING,
    }

[0]: https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.68...

Shameless plug, but you may be interested in my library (which is MIT/Apache-2.0) that offers decoding from BER/DER/CER all from a single model in code, there's no UPER/APER support at the moment, but it's coming in the next few months. :)

https://github.com/XAMPPRocky/rasn

Condemn me all you like, but considering the fact this is my firsthand account and that I've worked directly with these people for the past few years, and others who have worked them have said that their experience with these people was similar. And considering that you have not worked with these people or in the rust-lang organisation, which of us is really wildly speculating here? :)

That list is there because I fought and pushed for that change to be there against the core team.

> If they aren't coders and are "toxic" on top of that, get rid of them? Looks like a no-brainer to me.

The issue is that, there is no process to do that within the Rust-lang organisation. The core team is only accountable to themselves at this point.

Your ideas are intriguing to me, and I wish to subscribe to your newsletter.

Some of us in the Rust community wrote a letter of support for the actix maintainer. In case anyone else thinks what happened sucks and wanted to show support.

https://github.com/actix-support/letter