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.
I've used diesel async for personal projects, and while it does work seamlessly with diesel at times, there are some rough edges - I ran into an odd issue where the order of imports from the base diesel package and diesel async mattered, and it would compile with one above the other, but not the other way around.
Now, I'm not a lawyer, so this isn't legal advice, but...
A derivative work is not fair use. If you end up with a significant portion of another person's program in yours, (such that a substantial portion of your program is in some way related to their program), that will likely be a derivative work - but the definition of a derivative work depends on your jurisdiction and use-case. If you're unlawfully using the source material to produce a derivative work, you cannot copyright that derivative work under 17 U.S.C. § 103(a), and under the same section, you can only copyright your modifications, not the original.
It would be hard to argue fair use in this case; fair use only really applies for parodies/criticism, reporting, and scholarly works - and generally that's an affirmative defense, rather than an express or implied right you have.
Honestly, Copilot is difficult because Copilot can't be the author of the code; the person who used Copilot is the "author" of the code, and I think they'd be the ones liable for copyright infringement if copyrighted content ends up in their code.
To argue someone performed copyright infringement, all you need is to prove (1) a valid copyright exists; (2) that the person had access to the work; (3) the person had the opportunity to steal the work; and (4) that protected elements of the work had been copied (afaik generally under a "substantially similar" standard). Copilot offers an easy way to check both (2) and (3) - a copyright holder could argue that people had access to their code through Copilot, and that Copilot offered an opportunity to steal the work.