There are lots of guides, tutorials and documentation. The responsibility is no longer on someone else, it is up to the individuals to actually read any of them. And to be honest, if you are unable to use them to learn rust, maybe your c++ skills isn't that impressive either.

https://bpbonline.com/products/rust-for-c-programmers?variant=42560853639368 is one if found using a tool called search engine...

Had to test with Kagi also, leads with official documentation, after that tutorials and unofficial things. Nothing obviously irrelevant. The only thing with the Kagi results, was that there were a few very simmilar official documentation links (for different postgresql versions) at top. But, still good search results. Not sure why anyone is still using google, when there are quite a few better alternatives availale

https://firstdonoharm.dev/

That is wezterm which have builtin Nerd Font fallback, and I actually think WezTerm renders it to wide to fit it better with other fonts. But the rest of the font is JetBrains Mono

I think there are so much issues with historical dates, that it is probably not worth fixing it in general purpose libraries. Not only do you need to special case everything like this in relation to dates, but you would also need to keep track of all historical territories (like Prussia and such) and what was part of what. In this particular case, I think that the timezone Europe::Helsinki was part of Sweden and should be included (possibly some cities from current Poland). There is no need to add that kind of complexity to general purpose libraries, that should probably be in some special historical date / region library if needed.

Also, there was not really a concept of time zones before the railway, then the time was floating. The time was not the same in the whole country, because that was not a problem before people started to travel faster and in a way that needed time tables. So, that also fits poorly in a modern general purpose date/time library.

Flameshot has wayland support, however there seems to be some issues that might need to be worked around. Like https://github.com/flameshot-org/flameshot/issues/3326#issuecomment-1854902229

Ok, after reading some comments on other places, I think I get it now. While you are free to use their open sourced tool chain, which is what they have certified, you still doesn't fulfilling the legal requirements unless you buy the certified tool chain. Just because it is open source, doesn't legally guarantee that is what's certified.

So, you pay to get the legal status of the certification. Did I understand this somewhat correct?

But isn't it kind of obvious that if you are able to do 180k times improvement, then the baseline is probably not very impressive to begin with. Still, that doesn't take away that the optimizations were impressive, and that it was interesting to read about it.

That depends on the job I want to do. But generally my selection is something like this.

1. Is it a short simple script: Bash
2. Longer script, then a more competent dynamic language like Perl/Python.
3. Backend, a strong typed compiled language, with as few runtime errors as possible. If it depends on some particular API, the language with good enough bindings.

Preferred backend language, Rust, since that have the least runtime errors, thanks to its strong typing and the great error handling. But I also use Go if it have better libs for what I do, or Java for situations where that is more suitable.

If that works for you and you are happy with it, fine. But sudo-rs seems to have a bit of a different usecase since it is intended as a drop in replacement for sudo, hence it must be able to handle the sudoers file aso. It still removes some of the never-used obscure functionality that sudo had, so it is probably a lot smaller code base than original sudo.

A bit about passkeys https://www.yubico.com/blog/a-yubico-faq-about-passkeys/

But even there a TcpStream, a FileStream and a StringStream might have quite differen behaviour, since they all abstract very different things. So, even this simple example may fall apart very fast if you need to care about those. I'm not saying that Inheritance is always bad, but it is quite rigid and might cause problems in a large codebase if you suddenly run in to the corner cases where the assumptions the abstraction is based upon is no longer upheld.