Warp is great - I use it as my daily terminal. The best features are being able to edit commands, chunking the output into blocks and AI generated commands at your fingertips.
Another implementation is still unlikely to have the exact same bugs. Especially rewrite in Rust will force the code to be structured differently (Rust is very opinionated about that).
The spec is big enough that the team won't be able to just write the exact same implementation from memory.
I don't disagree that it's sufficient, but also, ideally different people would implement the spec. If you have a particular mental model or understanding of a part of the spec that doesn't match what the spec actually says, that is likely to translate identically when writing a second implementation.
Many organizations are stuck on Java 8 because Java 9 made breaking changes. (Java 11 also made breaking changes.) Many of these changes also broke some popular libraries at the time that hacked into the JDK internals, so it meant a significant refactor for software that might be in maintenance mode already.
To clarify Java made changes to things they never promised would be a part of backward compatibility. Libraries were using things from JDK internals/implementation details, things that were never guaranteed to be there.
It isn't that severe of a break. Most of the friction was with the libraries with transitive dependencies, like ASM, that depend on a particular bytecode version, using internal classes that were removed (e.g. sun.misc.BASE64Encoder), or the new module system encapsulating APIs that were intended to be internal-only (usually fixable with JVM runtime flags.)
A lot of organizations that use Java are very conservative with their tech changes, and didn't see a compelling reason to upgrade. This was especially true since Android Java still used Java 8, so many popular libraries continued to support Java 8 for their Android userbase.
Java's version history crawled along at a snail's pace until Java 10, when they switched from a feature-based to a time-based release schedule. The release cycle has been pretty quick after that, since that happened only after 2017 or so.
That, combined with some pretty large changes in the underlying security model, mean that a lot of places have been stuck on Java 8 for a real long time. It's much harder to move from Java 8 to Java 9/10/11 in a lot of places than it is to then go from 9/10/11 to 17, for multiple overlapping tech debt cleanup reasons.
On another note, I dislike how “Zero-Knowledge Proofs” are called proofs. It’s not a proof. You iteratively increase your belief that the result is true, like in experimentation, but that’s not a proof.
If someone has signed something cryptographically, wouldn't you say that the signature was a proof of someone with the private key signing it? (Even though it is possible to construct a valid signature without the private key - you just have to be very very very lucky)
I guess you also don't like the name Proof of Work.
It might help to think of the sense of "proof" that's synonymous with "trial", rather than a specific formal math sense of proving a theorem from axioms by formal transformations.
zero knowledge corroboration isn't the same thing as a zero knowledge proof. If the provided evidence isn't enough, then you keep iterating until it's proven.
COP or CoP means co-efficient of performance. An electric heater has a CoP of 1. New heat pumps usually have a CoP of 4 or higher. My 11 year old heat pumps have a CoP of 3. This means they can produce 3 or 4 times as much heat as an electric heater, assuming the same amount of electricity, or produce the same amount of heat with 1/3 or 1/4 of the electricity.
At a CoP of 3, they are more efficient than electric heaters down to -15C. At a CoP of 4, down to -25C. There are better heat pumps coming with a CoP of 5.
I’m sure it’s down to use case and circumstances but I frequently find it useful to be able to read and edit text based data formats (JSON/YAML/TOML). If you are concerned about data size you can easily use on-the-fly compression at little cost nowadays.
