You don’t need a car in Singapore. Very good public transport and affordable taxis.

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.

Did twitter consider to affiliate with @musicfan, @musicmusic, @music123, or @musiclover instead?

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

Do they agree on the definition of the false information?

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.

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