The NL Times just translates Dutch articles and editorializes them for a (mostly American) audience. They should be consistently taken with skepticism. In this case, as other commenters have pointed out, this is "just" Google Analytics.
Pretty neat! However, if you wanted to know the _probability_ of a noodle crossing any line in the long noodle case (L/W > 1), the expression is more complex (and I believe would require an integral) :).
It's interesting that the number of crossings is independent of whether L/W is less than or greater than 1, but the probability of crossings is equal to 2pi * L/W only in the short case. This makes sense since in the short case the noodle can at most cross a single line.
Proof irrelevance I don't think is accepted in constructivist situations. Those are, however, not that relevant to the recent wave of AI math which uses Lean, whose type system includes classical mathematics.
I am excited for some alternative syntax to jq's. I haven't given much thought to how I'd write a new JSON query syntax if I were writing things from scratch, but I personally never found the jq syntax intuitive. Perhaps I haven't given it enough effort to learn properly.
Perhaps I overstated how related the two were. I was pulling mostly from the Lean documentation on Universes [0]
> The formal argument for this is known as Girard's Paradox. It is related to a better-known paradox known as Russell's Paradox, which was used to show that early versions of set theory were inconsistent. In these set theories, a set can be defined by a property.
I came across this when wondering if there were any efforts to give programmers additional information via audio, similar to how colors are used in syntax highlighting.
The final comments in this text seem sobering and indicate an openness to change. I worked recently on a project to migrate RediSearch to Rust, and this was partially motivated by a decent number of recent CVEs. If SQLite doesn't have this problem, then there needs to be some other strong argument for moving to Rust.
I also think it's important to have really solid understandings (which can take a few decades I imagine) to understand the bounds of what Rust is good at. For example, I personally think it's unclear how good Rust can be for GUI applications.
It carries some weight, very roughly in the direction of formal verification. Since (assuming there isn't any unsafe), a specific class of bugs are guaranteed to not happen.
However, this repo seems like it uses quite a bit of unsafe, by their own admission.
This idea about communicating size/alignment is actually something we're doing on the port of RediSearch to Rust [0]. We have an "opaque sized type" which is declared on the Rust-side, and has its size & alignment communicated to the C-side via cbindgen. The C-side has no visibility into the fields, but it can still allocate it on the stack.
It's a bit ugly due to cbindgen not supporting const-generic expressions and macro-expansion being nightly-only. It seems like this will be a generally useful mechanism to be able to use values which are not traditionally FFI-safe across FFI boundaries.
It's kind of an exploratory phase for what works sensibly with Rust's borrow checker, especially since most UI libraries/frameworks really rely on a GC.
I used to make animations with https://pivotanimator.net/ a lot as a kid, trying to make fight scenes like these. A sort of related thing is ToriBash, which is kind of a multiplayer 3D animation game where you fight each other by making decisions on which muscles to contract at each time interval.
Loved this stuff so much. I miss my summers off from school, where I would never think of a day gone as time "spent".
When reading this project's wiki [0], it mentions that Kanal (another channel implementation) uses an optimization that "makes [the] async API not cancellation-safe". I wonder if this is the same / related issue to the recent HN thread on "future lock" [1]. I hadn't heard of this cancellation safety issue prior to that other HN thread.