Maybe make it aggregate the data over all commits and then use that as a learning opportunity to learn about tools like cargo-bench, criterion, cargo-flamegraph and other profiling and benchmarking tools and optimization techniques to see if you can speed it up, reduce its memory usage,…?

Maybe keep maintaining the HashMap you have now and use one of these less portable mechanisms in a test to alert you when you forgot to register one?

Have you tried some tag soup parser? That should work as a last resort even if the ones building a tree structure don’t.

The thing I don’t get in these discussions is that there are people who have convinced themselves that a language we came up with in the first 20 years or so of the industry’s existence is the pinnacle of programming language development and that all those newer languages are really completely equivalent in terms of outcome once you add up their up- and downsides.

That seems based on the same misconception as the whole “fighting the compiler” view on Rust, namely that other languages are better because they let you get away with not thinking through the problems in your code up front. I am not surprised that this view is common in the C world which is pretty far on the end of the spectrum that believes that they are a “sufficiently disciplined programmer” (as opposed to the end of the spectrum that advocates for static checks to avoid human mistakes).

The problem you mention is fundamentally no different from e.g. changing some C internals in the subsystem you know well and that leads to breakage in the code in some other C subsystem you don’t know at all. The only real difference is that in C that code will break silently more likely than not, without some compiler telling you about it. The fact that the bit you know well/don’t know well is the language instead of some domain knowledge about the code is really not that special in practical terms.

Speaking of convenient things best not handled manually, do you have any plans to get support for it into crates like sqlx-postgresql, diesel or humantime where conversions need to happen but pretty much the same way for every user of the library?

If the iPhone had been hyped like AI is today people would have claimed you could replace your hammer, saw, garden hose and cooking utensils with an iPhone.

Meanwhile current AI is pretty much useless for any purpose where you actually need to rely on a decent chance to get quality results without human review.

Is it really that hard to distinguish genuine revolutions (iPhone, Rust, AI, reusable rockets, etc.) from hyped nonsense (Blockchain/web3, Metaverse, etc.)?

It is funny that you list AI under genuine revolutions while I would list it (or at least 90% of it) under hyped nonsense.

From the perspective of a library author even evaluating if a given bug could be considered a vulnerability is extra effort that is not strictly useful to the project itself, just to those using it who want to not apply every single update.

I would say this very issue is at the core of the current CVE discussions that leads more and more projects to become their own CNAs.

Security people and corporate downstream consumers of security feeds want to invest the minimum of effort while pushing as much of the evaluation what is and isn’t a vulnerability on the authors of library authors as possible. However, this does not work. A vulnerability can only ever truly be evaluated by investing significant amounts of effort in the abstract way that is required to do it in an upstream project. On the other hand, at point of use it is often trivial to discard the possibility of an exploit because the potentially vulnerable code is not even used by the project using the library that contains the code.

Funnily enough the same is true for languages that have huge standard libraries. They put anything that is convenient to solve their immediate problem in there. That is how languages like Python end up with multiple of just about everything complicated in there.

As a sysadmin I have sadly encountered too many situations where a programmer thought “oh, this will never happen” to agree with you that a code construct that provides no information to the user should be used in such cases.

No, I actually meant it as in the traditional meaning of literally. As in

[lints.clippy]
unwrap_used = "warn"
expect_used = "warn"

along with a pre-commit hook that does

cargo clippy -D warnings

(deny warnings).

There are always better ways to write an unwrap, usually via pattern matching and handling the error cases properly, at the very least logging them.

There are a few very questionable things in there. Unwrap should literally never appear in production code so if your code base uses it so often that you want a short-hand syntax for it that calls into doubt everything else you wrote.

const expressions are evaluated at compile time and can be used in locations where you would have to otherwise specify a literal (or something that amounts to a named literal like a const value).

The hated minority being inferior but also immensely powerful is a pretty standard feature of anti-minority world views of all kinds. It is pretty much required to justify the extreme actions they want to take against the minority.

A lot of software writes to log files or temporary files or lock files or database transaction logs as part of its normal function and when those writes fail due to a full disk the software doesn’t work anymore.

Python packaging and stability is a total mess. It has gotten to the point where I just look for alternative tools when I find out something new I found is written in Python.

It is not that the regular frontend doesn’t work and alternative frontends do, it is that half of the stuff on their server (including image uploads and the frontend) don’t work because the admin has no time to deal with it. The problem isn’t the software used but the lack of maintenance.

So really any tab user in any language requiring alignment then?