Pretty sure more than 3.5% of the people in Hong Kong was protesting a couple weeks after the article came out. It took the CCP about two years and a COVID lockdown to get things under control.
Developing in Hong Kong has been much harder and expensive than before. The high speed rail that connected Hong Kong to the mainland system was (IIRC) the most expensive rail project per kilometer. (They did it anyway since it was a national objective from the central authorities.) And, given the recent tragic fire in Tai Po, there has been a lot more worry about people not being able to afford to renew aging infrastructure (as in residential buildings).
I couldn't find it, I'm starting to think it might have been a hn comment thread.
At the time I read this article but I don't completely agree with some of the points. For one it's too certain for some things and also seems AI generated, but it was somewhat interesting
Yes I do remember reading and agreeing much with your comments on this topic!
I wouldn't say it's a mistake. Distributed algorithms that depend on wall clock time generally give better guarantees. Usually you want these guarantees. The downside is of course you need to keep accurate time. In the cases you don't need them (eg. for the case you described), sure, but as an engineer you don't always get to choose your constraints.
The curious thing about the article is that, it's definitely premature optimization for smaller databases, but when the database gets to the scale where these optimizations start to matter, you actually don't want to do what they suggest.
Specifically, if your database is small, the performance impact is probably not very noticeable. And if your database is large (eg. to the extent primary keys can't fit within 32-bit int), then you're actually going to have to think about sharding and making the system more distributed... and that's where UUID works better than auto-incrementing ints.
I agree there's a scale below which this (or any) optimization matters and a scale above which you want your primary key to have locality (in terms of which shard/tablet/... is responsible for the record). But...
* I think there is a wide range in the middle where your database can fit on one machine if you do it well, but it's worth optimizing to use a cheaper machine and/or extend the time until you need to switch to a distributed db. You might hit this middle range soon enough (and/or it might be a painful enough transition) that it's worth thinking about it ahead of time.
* If/when you do switch to a distributed database, you don't always need to rekey everything:
** You can spread existing keys across shards via hashing on lookup or reversing bits. Some databases (e.g. DynamoDB) actually force this.
** Allocating new ids in the old way could be a big problem, but there are ways out. You might be able to switch allocation schemes entirely without clients noticing if your external keys are sufficiently opaque. If you went with UUIDv7 (which addresses some but not all of the article's points), you can just keep using it. If you want to keep using dense(-ish), (mostly-)sequential bigints, you can amortize the latency by reserving blocks at a time.
Note that "nearly all" isn't "all". I have some side project that require rendering of very uncommon CJK characters, and Unifont does not display them as expected. (For that project, I used https://kamichikoichi.github.io/jigmo/ which was the font that was most complete in terms of CJK glyphs )
Unifont seems to have about the same glyph coverage as my system default CJK font (unfortunately I don't know what it is).
Do you know if those characters are in supplemental planes? The BMP would only be glyphs from U+0000 through U+FFFF (though the first 32 and last two aren't printable, and wouldn't be included in this font).
Another example would be emoji, which would probably now be considered "basic" by most people but have always been in a supplemental plane.
https://en.wikipedia.org/wiki/Whataboutism
reply