This is an interesting approach especially if you factor in that re-minting a key is usually a lightweight task compared to what most API calls have to interact with.
If the re-minting happens transparently with a user interaction then you spread out some of the request velocity that can come with that (if you're operating at a large enough scale for it to matter for this to be a concern).
Calendar Versioning (CalVer, YYYY.Release.Patch) fulfills the same need and you can see it in practice with Jetbrains (e.g. the latest version of IDEA is 2025.3.6).
The only difference is Jetbrains uses YYYY.R for marketing, see: "What's new In 2025.3"[1]
>But before I did so I researched first. I asked a few instances to analyse the project in terms of gains of complexity, stability, testability, etc., and while (obviously) stability would drop (no types in Ruby) it’s not that awful (Sorbet has types in Ruby!).
Is it not a rage-bait argument to say that not having types implies less stability?
Ah, I was using GH's webui instead of downloading to view the PDF and it stopped loading at slide#47...rereading it now paints a much better picture. Thanks!
If I followed, Rust's memory safety guarantee means sacrificing roughly ~3% performance with some worst case paths being ~15% (compared to C++ performance)?
Is it too much to ask for a not-vibe-coded billing system? In my opinion, we need better systems to hold these companies accountable as I don't believe the $20/dispute they're paying means much given how common other customers are complaining about billing irregularities just in this thread alone.
Could you share why?