All this may become much easier when we manage to merge proof assistants with automatic provers.

Here is how you can prove the first theorem in Dafny. https://rise4fun.com/Dafny/GxplK

One author of Xoroshiro has written a detailed (and harsh) analysis of PCG.

http://pcg.di.unimi.it/pcg.php

Ouch. I did not know this was a competitive field: this description you linked is very harsh, while the table on the front page (from OP) is the exact opposite. As if both are trying to sell their product by trying to discredit the competition.

There's more, too. That seems to be a response to this: http://www.pcg-random.org/posts/implausible-output-from-xosh...

And there's a response to the response: http://www.pcg-random.org/posts/on-vignas-pcg-critique.html

Rumors say he writes code in zcat to go faster.

They may not do user studies like this, but for sure they adapt to user feedback.

https://thefeedbackloop.xyz/stroustrups-rule-and-layering-ov...

Peter Norvig explains why.

http://norvig.com/chomsky.html

Gabriel Synnaeve was already working on this long before joining FB.

http://emotion.inrialpes.fr/people/synnaeve/

Don't forget the "up to". Your app may be in another section of the statistics.

Glad to see someone point this out. "There are three kinds of lies: lies, damned lies, and statistics."

OCaml is GCed and can infer more type annotations than Rust, so its code feels closer to Python.

Rust is best for complex systems where tight control of resources is required.

Such specialized filters can improve compression a lot. For instance, the e8e9 transform converts relative jumps to absolute jumps in x86 EXEs, increasing compression because lots of jumps actually point to the same address.

http://mattmahoney.net/dc/dce.html#Section_571

CPUs have gotten so complex that mastering their language (and behavior) is a skill on its own. Most people can get on with compiled/interpreted languages.

I agree with the "most people" part. On a tangential note, While it's true that nobody can be expected to master and write a large and well performing application in assembly language anymore (or better than a compiler could optimize it), there's something to be said for learning the deepest and most basic building blocks (ok, if we have to go even deeper, then learning the actual opcodes for assembly language instructions). IMO, it makes it easier to understand many higher level concepts as well as different kinds of technologies (the latter to some extent). This in turn helps with different kinds of thinking when designing and debugging a program written in a high level language. Something similar could be said for "closer to the machine" languages like C.

Additionally, for those interested in the area of software security, this is a very useful layer to know well about, even if one has learned assembly language in another (popular) processor family. Knowing what features processors provide (like the support for virtual memory, among other things), and how they work, are also quite useful.

This is a fundamental distinction between true geeks who grew up hacking 6502, Z80, 68000 etc etc, and wannabes who jumped on the bandwagon later and think Javascript is "low level"...

No, it's not. It's a fundamental distinction between those who have learned to operate at that level, and those who haven't. That is it. People who started out on HLLs can gain those skills, because it's ultimately just another paradigm.

Saying those of us who didn't grow up on asm aren't true geeks rings of No True Scotsman to me.

In addition, just because we weren't born a decade earlier doesn't mean we think JS is low level. That's just a flat-out mischaracterization.