telios

Deadlock is in active development, so... I think so?

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.

That is what the article claims, but... I see it as left-aligned. Firefox 129.0.1 on MacOS.

I'm not sure that's stopped them; it would be trivial for them to find some reason, as long as it leads to the conclusion they want.

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.

But the commits will still be there even if the refs aren't, afaik? GitHub doesn't run gc that often.

A dry bar lacks water, not ethanol, and dry cleaning still uses liquids, so I'd argue even the colloquial definition is water.

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.

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.