I thought NATS was a project under the CNCF, with the trademarks being transferred to the Linux Foundation, which is why they couldn't relicense NATS, and why they can't relicense it in the future.
Largely in part due to regulatory capture; it is not necessarily innate of a government to cause this. Maybe restrictions on how corporations are able to influence governments to act against their constituency might solve this problem, rather than giving corporations carte blanche to do anything...
Very rarely do you need to pass around a lifetime-bound struct or enum that isn't _also_ meant to be temporary. (One database pool has database connections lifetime bound, for example, but the pool still owns the connection.) When I do, I generally eat the cost and put it behind a Rc/Arc, where cloning is cheap.
It is 'borrowing' because you don't own it, not because you don't want to clone/copy it. Sometimes it is cheaper to borrow than it is to clone/copy; sometimes it is not.
Water itself isn't wet, but it makes other things wet by sticking to surfaces and creating a layer of liquid on them. Wetness is the ability of a liquid to adhere to the surface of a solid, and since water can do that, it makes things feel wet.
The reason it works is because they've done the research to make it work. It isn't a coincidence DAUs increase. I think it is important to recognize that it can impact you, and take steps to account for that, even if - or especially if - you don't want it to. You are not immune to propaganda, and all that.
In German the DAU is the "dumbest assumed user", the worst case consideration when designing UI. My impression is that if you try to increase DAUs, you often increase both types.
For reference, the terminology they use for their API is "guilds." But since most other services in the space used the term "servers" (e.g. TeamSpeak and Mumble, where they were actual distinct servers), I can see why the UI doesn't say guilds.
Yes, I too can see why a dishonest corporation would knowingly use incorrect labels to mislead you about how their product compares to the competition. That doesn't excuse that behavior though, quite the opposite.
The post makes mention of B-tree de-duplication that is present in PostgreSQL 13, but not 12, the version they're using; at the same time, they're noting that the vast majority of values in some of their foreign key indexes are NULL.
I have to wonder if B-tree de-duplication would have helped with that particular case? The PostgreSQL 13 documentation seems to imply it, as far as I can tell[0] (under 63.4.2):
> B-Tree deduplication is just as effective with “duplicates” that contain a NULL value, even though NULL values are never equal to each other according to the = member of any B-Tree operator class.
I don't think it would be as effective as a partial index as applied in the post, I'm just curious.
In previous discussion of this article, an HN user did the math: pg12 is 16 bytes per NULL and pg13 is 6.32 bytes per NULL. https://news.ycombinator.com/item?id=25989467 So definitely some pretty significant savings there.
