I just thought it an amusing anecdote until COVID, and then realized it’s less that said virus would be developed here and more that we have the business idiots to let it loose.

I'll note that COVID-19 "broke out" in Wuhan a city which has a virology laboratory nearby - the Wuhan Institute of Virology, who perform research on viruses.

I'm sure that is completely incidental to the pandemic of 2020-21. Clearly, some rather nasty live food markets are to blame.

It wasn't your numpties wot did it then, it was another lot that time!

Because of the existence of Class B shares.

> Something like it is basically a requirement if you want to see digital ads.

So to summarize, yes, it should be illegal.

Instant messaging and calling is extremely valuable. Algorithmic social media is extremely noxious. Unfortunately, they both live on the same device.

I can text my wife when I leave home telling her to meet in the park. I can call for help in an emergency. I can talk to my family, back in my home country, whenever I want and wherever I am. My grandparents emigrated when "seeing your family" meant a month's journey by sea, so I'm quite sensitive to this. It's a miracle we take for granted.

Rust is concerned about memory-safety, yes, but the only strict requirement for memory-safety when it comes to const-evaluation is as follows: "The only guarantee the type system needs is that evaluating `some_crate::SOME_CONST` will produce consistent results if evaluation is repeated in different compilation units" ( https://rust-lang.github.io/rfcs/3514-float-semantics.html ).

Beyond that, from a philosophical standpoint, Rust takes great pains to ensure that const functions produce identical results regardless of whether or not those functions are called at compile-time or at runtime. Rust has adopted this stance because it wants to reserve the right to opportunistically evaluate const-capable functions at compile time, as a performance optimization, even if the user has not explicitly asked for it (for that matter, Rust also does its best to const-evaluate non-const functions when it can). Because of this, Rust's assumption is that users would be annoyed if their program's visible behavior depends on whether or not the optimizer has exercised its discretion to evaluate a specific function at compile-time.

However, this is only a guideline, not a strict guarantee. There is one exception to the above rule: "when a floating-point operation produces a NaN result, the resulting NaN bit pattern is some deterministic function of the operation’s inputs that satisfies the constraints placed on run-time floating point semantics. However, the exact function is not specified, and it is allowed to change across targets and Rust versions, and even with compiler flags. In particular, there is no guarantee that the choice made in const evaluation is consistent with the choice made at runtime."

In other words, calling the `.to_bits()` function on a floating-point value that happens to be NaN is allowed to produce a different result at runtime than it does at compile-time (note that all compile-time evaluations are guaranteed to always produce the same result for a given toolchain version for a given target, as required above).

This exception is made because otherwise otherwise it would be basically impossible to support floating-point math at all, thanks to the way various platforms have implemented their floating-point functions in practice.

In contrast, Zig doesn't have such a philosophical compunction against a function's result being determined by whether or not it's being evaluated at compile-time, as shown by the existence of the `@inComptime` builtin. But Zig does still broadly attempt to make comptime deterministic, including going so far as to forbid I/O, though I don't see where any specific guarantees are documented in the Zig reference.

    let mut arena = Bump::new(); // create arena
    
    let foo = arena.alloc(Foo { x: 42 }); // allocate item in arena
    
    bump.reset(); // clear arena
    
    foo.x += 1; // compiler error preventing use-after-free

    let x; // declared, but uninitialized variable
    loop { // control flow is guaranteed to enter this loop
        if some_condition() {
            x = 42; // initialize x
            break;
        }
    }
    foo(x); // Rust knows that x is initialized as of here in all possible paths

Interestingly, this all suggest that, in C-like languages, the more natural implementation of an infinite loop should not be `while(true)` nor `for(;;)`, but rather `do {} while(true)`, because do-while are also guaranteed to enter their body (and note that Rust doesn't feature do-while loops).