For more brain flipping try looking into hardware description languages (Verilog) or proof assistants (Coq).

Not quite. Suppose instead of a single version of serde there’s now 46 versions like in https://crates.io/crates/parquet to be able to use instances derived in some other crate X you have to use the same version of serde. Now, how should a crate decide which versions of serde to support?

All 46 and all optional? Supporting that would be painful. Just the last one? crates.io is a cemetery full of dead crates, with this support strategy any handful of crates picked at random are not going to be serde-compatible with each other.

A better solution would be a better support for compile time reflection so serde doesn’t have to exist in its current state, but that’s got delayed (by big macro conspiracy :)

When adding a new dependency I almost always go over the source code to see what kind of performance to expect. If build.rs is there - checking it takes a single click so yes to that too. Derive macro - less frequently, but you have to do it when documentation is non existent.

No, serde_derive contains the binary and if you are on linux it will try to run it without asking the user. In fact there’s no way to make it so it won’t run.

Serde is incredible though

Sure. Fork of it can be incredible too. In fact the only difference can be traditional approach to building the derive macro. All it takes is for people to switch.

You can read a build.rs script.

Then there’s this: http://cm.bell-labs.co/who/ken/trust.html

Not sure, possibly. You still need to be pretty smart maintaining and extending all those tools.

serde is maintained by dtolnay, he is not the original author.

It seems it was done to marginally improve serde_derive build times? And just on x86_64-unknown-linux-gnu?

Indeed. If you use nix instead of compiling in 8 seconds it fails to compile almost instantly.

Encrypted data don’t compress well.

Then there’s Haskell that would remove (well, used to at some point) your source code file if you made any errors: https://gitlab.haskell.org/ghc/ghc/-/issues/163

It’s an improvement over crates.io, but I stopped using it after BurntSushi removal a while ago - I prefer data as is rather than having to double guess every search result. You got a bunch of good suggestions already. Going closed source is not going to help long term. I hate crypto stuff too, but calling them names is not helping to educate users. I will probably be fine with “this crate/category exists, it is bad because (insert some legit third party links), if you want to know more - proceed at your own risk” and remember the decision to proceed.

Who gets to decide if a project deserves to live or not? You don’t like the quite - there’s more…

“Colored people don’t like the book “Little Black Sambo”. Burn it. White people don’t feel good about “Uncle Tom’s Cabin”. Burn it. Someone’s written a book on tobacco and cancer of the lungs? The cigarette people are weeping? Burn the book. Serenity, Montag. Peace, Montag. Take your fight outside. Better yet, into the incinerator

Showing the code and the errors compiler gives to you would help a bunch.

While I share the sentiments about cryptocurrency being a solution that is in search for a problem - libs should not editorialize the contents while still claiming to be “more complete and accurate crate information than crates.io”

Today the came for cryptocurrency, if we don’t speak up - tomorrow they will come for monads and other category theory goodies.

There’s a language field next to each comment or post for whatever reason, I noticed I have to set those to English for it to work too.

Ouch. That’s what you get by trying to make them by hand :) Fixed in github, will publish a new version some time later, thanks!

Thank you good bot.

If you want more of the same, about what was before ASCII and after it - there’s a great talk by Dylan Beattie https://www.youtube.com/watch?v=gd5uJ7Nlvvo

I’d recommend adding the markers on a line below the text, in a similar way to how rust compiler output indicates errors.

It is easier for the rust compiler to do so since rust files are always valid utf8 and formatted to be of reasonable size. Doing the right thing with OsString is harder, plus lines can be long and trimming it enough that it still fits on a line above all that while also dealing with unicode shenanigans… That’s why I’m trying to do things inline where most of those things

Also WIN isn’t really clear to me what it’s supposed to mean, does it mean that flag “wins” and takes precedence over the other conflicting flag?

Right. Wording can use more work :)

Does that even matter if the program exits with an error anyway?

Hmm… Interesting question. I guess it is less useful in this case but I can imagine some stranger situations. Plus I’m trying to create more detailed/user friendly error messages - one is text description “FOO is required” and the other one shows place where exactly this “FOO” is required.