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.
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.
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.
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.
I don't quite follow the algorithm here, but I'm not sure the `gensym` Rust implementation works as expected. `RefCell::clone` does not return a copy of the reference; it returns a new `RefCell` with the current `RefCell`'s value, resulting in duplicate IDs. However, a `RefCell` isn't even necessary here, since a `Cell` would do just fine - and you'd pass around a reference to that `Cell` instead of cloning it.
It does feel like the code was ported as-is to Rust, and only adjusted slightly to compile; there are going to be pain points as a result of this process. I suspect this is the source of some of the author's complaints, especially given:
> Although it provides us with a greater sense of how the code is executing, it brings very little value to the algorithm itself.
Rust is, in general, for people who find value in having that information; it is okay to not want to have to worry about ownership, borrowing, safety, etc., but it seems a bit odd to complain about this when that's what Rust is for? If you want to focus on just the algorithm, and not how it's executing, then OCaml is definitely a valid choice.
However, the point about GADTs - can Rust's recently-stabilized GATs not work in the same way? Though I will admit that Rust's GATs don't seem nearly as powerful as OCaml's GADTs in this regard.
Something tangentially related, but something I'm unaware of - if I do run into an ICE on nightly, what is the current process for reporting that? I've run into one or two before (and I've generally assumed it was me doing something dumb with the environment, and I couldn't replicate it), but I wouldn't mind trying to report them in the future.