Brian Anderson, a former lead of the Rust project, writes about Rust, open source maintenance and testing.
HN cites his post on being a minimally-nice maintainer for reducing contributor burnout, and his Rust embedding and archaea test-history projects.
You might be referring to this, which I think is even more accurate. Dave Herman quotes him:
https://www.thefeedbackloop.xyz/stroustrups-rule-and-layering-over-time/
One of my favorite insights about syntax design appeared in a retrospective on C++ by Bjarne Stroustrup:
For new features, people insist on LOUD explicit syntax.
For established features, people want terse notation.
I call this Stroustrup's Rule. Part of what I love about his observation is that it acknowledges that design takes place over time, and that the audience it addresses evolves. Software is for people and people grow.
Side note: Dave Herman is Rust's most unrecognized contributor: https://brson.github.io/2021/05/02/rusts-most-unrecognized-contributor
I often notice that the actual Rust authors and designers respect and are influenced by C++ very much. (Niko M is another C++ fan)
It's only the randoms online that like to start C++ vs. Rust arguments.
Another thing to note is that the Mozilla Rust is MUCH closer to C++ than Graydon's Rust was. Graydon's Rust was not at all about zero-cost abstraction, the shared motto of C++ and Rust.
for FOSS the reference implementation is co-created by the consumers of the software. the users will only accept a new release if it fits their functional needs and passes their verifications.
the Linux kernel, the toolchain, or libraries like ssl libs are co created by the very organisations that consume the software. FB, Google, Amazon, Microsoft, IBM with red hat, Suse, Oracle, SAP they all concrete the Linux kernel, and for each kernel release they validate, each of them, the technology.
that's how the reference implementation _is_ the standard.
same goes for rust, which brilliantly leverages build automation of the cargo package repository to protect the compiler and toolchain from regressions:
https://brson.github.io/2017/07/10/how-rust-is-tested
the more crates have sound test suites, the better the quality statement of the compiler is.
Rust does this with cargobomb: https://brson.github.io/2017/07/10/how-rust-is-tested
> Rust has a standard testing facility that most Rust crates use, and Rust has a standard repository of Rust crates in crates.io. GitHub further contains repositories of Rust crates that are not published to crates.io.
> These factors allow us to treat the entire world of open source Rust code as our test suite.
> As new nightlies and betas are published, we use the cargobomb tool to test this corpus of Rust code (as of 2017/07/10 over 13,000 crates) against both the stable release and a nightly or beta release, comparing the results for regressions.
In a similar vein, one of the articles that has more influenced my interactions has been The Minimally-nice OSS Maintainer [0]. It doesn't produce an instant slipstream where all your collaboration is suddenly super-fluid, but niceness does help reduce those abrasive moments which, in my experience, can slow a community down a lot more than working well speeds it up. It goes hand-in-hand with good community curation - so long as you're trimming out bad actors, you have to be able to acknowledge bad behaviour in yourself.
0. https://news.ycombinator.com/item?id=14051106
https://brson.github.io/2017/04/05/minimally-nice-maintainer
I think this highlights that while there are easy solutions to the problem the OP faced, they're difficult for a newcomer to discover. (I have been using Rust for a couple of months and I'd also have reached for serde and maybe serde_derive to solve the problem).
Hopefully this is something the Libz Blitz[0] will solve with their Rust Cookbook[1]. (You could almost but not quite arrive at as simple a solution from chapters 1 and 2).
[0] https://blog.rust-lang.org/2017/05/05/libz-blitz.html
[1] https://brson.github.io/rust-cookbook/intro.html
> engines might always be done in C/C++ simply because it
> gives them the ability to easily make bindings to the
> majority of languages
Just like C++, it will be possible to expose a C-compatible interface to Rust code that will allow any language that can call into C to call into a library written in Rust. See http://brson.github.io/2013/03/10/embedding-rust-in-ruby/ for a rather dated proof-of-concept, or http://bluishcoder.co.nz/2013/08/08/linking_and_calling_rust_functions_from_c.html for something more recent.