I don't think Rust vs. Zig has anything to do with why people are talking about this. It is a large piece of "real software" that underwent a full language transition in ~1 week using LLMs. That is a big deal regardless of the language and will be a case study regardless of how it turns out.
> On the other hand, Rust is a complex language prone to refactoring avalanches, where a small change in a component forces refactoring distant code.
Are you saying this out of personal experience or just hypothesizing? I am working on a large, complex rust project with Claude Code and do not experience this at all.
The most common reason is that a quick manual step is needed before publishing. Nothing malicious. Often it is just removing paths used during dev from Cargo.toml. Should it be automated? Sure, but that is extra work.
I agree that position is nonesense. I mean, the single best defense against supply chain attacks is to bring everything in house. Is that reasonable? No…
Help normalize saying no? As an OSS maintainer, the sense of entitlement many have is quite frustrating. After years in OSS, I have built up a thick skin and am fine saying no, but many aren't.
You are very confidently incorrect. So incorrect, it is hard to even start correcting you.
* Inflation is not caused by "putting your money somewhere" What on earth.
* At a high level, inflation is caused by either "too much money chasing too few goods" and/or the cost of producing the goods rising. Money supply can increase without causing inflation if the supply of goods can also increase. In short, the supply of money can increase without causing inflation if productivity rises to match it.
* Most people do not "put money" in loans what are you even talking about there?
* Bank loans do not automatically increase the supply of money. When a loan is taken out, it is (mostly) deposited to another bank, resulting in a net-zero change in money. Increasing the supply of money requires the federal reserve to take steps.
Replying here since I can't reply to your deeper comment.
A client can never know with certainty that it has successfully acquired the lock because, for example, the process could freeze between reading the current time from hardware and the steady_time function returning.
You can not rely on time, for safety. Only for advice.
In short, either the storage layer provides enough guarantees to ensure safety without redlock OR it is not possible to ensure safety.
I believe that antirez's proposal is the former, but if he has a safe algorithm that does not require a linearizable CAS operation in the storage layer and is safe w/ redlock, I would love to hear it.
I also provided an example of how to use Cassandra which is eventually consistent safely with a locking service that provides monotonic tokens.
Martin made no mention of strong vs. eventual consistency.
If you write to a store like cassandra using a monotonic token, the result will converge correctly. If you require to never read "stale" data, you can read / write w/ quorum. There is no linearization in the storage layer in this case.
In this case the lock is not superfluous and you have safety.
Regarding CAS, I said that your argument (in support of redlock) was wrong. I would be happy to respond to a proposed algorithm, but as someone else mentioned, either the storage layer can provide a CAS operation, in which case your lock is not required and the workers read, mutate, CAS, OR if the storage layer has any weaker semantics then it is not possible to ensure safety with a token.
This response is incorrect at a very fundamental level.
First, Antirez claims that requiring the "materialization" store to be able to tie break with a monotonically increasing token requires linearization? This is completely false. The monotonically increasing token allows for eventual consistency. That's the entire point of it. It's monotonically increasing.
For anyone who claims that once you have coordination (locking) in your system you already lost is completely ignoring the research coming out of BOOM (Berkeley Orders of Magnitude). You can design your system to push the coordination out to the edge and way from your "choke points" and use these monotonically increasing tokens to keep your bottlenecks coordination free.
Secondly, Antirez's argument that you can use a compare & swap in a transactional storage layer is also wrong. This is not possible to write safely.
I'm not even going to touch his argument that using system clocks in a distributed locking algorithm is safe...