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

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 :)

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.

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

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

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!

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.

You need to tell the user that this is an error, otherwise they don’t know if it succeeded or not.

So add “Error:” at the beginning? Looks a bit better, right.

Last line is more or less copy of the command line user gave with markers indicating bits parser does not like.

https://patents.google.com/patent/US2950048A/en - more images and explanations here

I am :)