If you squint a bit (well, a lot really), Win32S on 3.1 and Windows 95’s Win32 implementation are Windows NT emulators running on top of 16 bit Windows.
Core solo/duo was the last in the P3 heritage (but that heritage itself traced all the way back to the Pentium Pro initially) via the 2 generations of Pentium-M (even if Core2 had parts they were 64bit so more of a major upgrade).
Whoever convinced the execs at Intel to put Pentium-M into production as a "mobile" chip really saved them when NetBurst reached it's end of line, I owned a first-generation Pentium-M laptop and it was really superb (seeing the Macbook Air introduced was a big meh).
It was really a turning point though, I remember posting some compile time and people didn't believe me, but the Pentium-M chips were good at compiling (since compilers are kinda "branchy" when it comes to execution in a way P4 didn't "like") but also because I had maxed out the RAM on the machine (1.25gb when 256mb was the base for the machine and similar for many desktops) so much of the code and libraries could be retained in disk caches.
With portable performance like that, why do you need a desktop?
In particular, students of Hindu Philosophical Schools will find lots of parallels here. Bohm was heavily influenced by Jiddu Krishnamurti which inspired his take on quantum theory.
Bohm also wrote a great book, "Quantum Theory" based on the Copenhagen Interpretation which contains separate parts on "Physical Formulation" and "Mathematical Formulation" of quantum theory.
With Lisp you can use iterative algos and get that under a second too.
SBCL can be ridiculously fast; and if you optimize the compilation for integers... the speed gets really close to your solution.
Dog slow but the old n270 netbook (32 bit) handles big factorials >20 fine, and OFC it's instant under Common Lisp (SBCL) and Scheme (both S9 and Chicken).
Ori B. it's a great programmer, he fixed a small bug on the earlier GeFS on 9front versions in no time. It worked fine in my n270 based Atom netbook under 9front, so it will run perfectly well under OpenBSD in a near future.
It isn't as resource heavy as ZFS, and it will be more reliable than FFS, for sure.
Rust wasn't made to replace C, C is to be there at low level and as a glue code for everything.
Rust was made to replace C++ because the language it's a behemoth, it tries to do everything and the syntax it's a Lovecraftan nightmare, full of legacy incompatibilities. For small games such as Cataclysm:DDA I'd use Go (and for system tools and internet services OFC) and for game engines Rust it's or even GC based languages (not Java) can do it well (C# with AOT).
Even Common Lisp it's fine (just look up Trial/Kandria) with SDL2/3 and/or OpenGL bindings (Vulkan ones should be somewhere). Pick SBCL for speed, learn CL, learn about SIMD and optimizations. It can beat C on performance.
There are times that JIT'd C# out-performs AOT C#, so I'd avoid defaulting to recommending AOT. Assuming that AOT is faster is the same trap that C advocates fall into when thinking that other languages can only ever equal C on speed.
If a language can produce the same machine code (including dynamic patching) as a second language, that second language can at best only equal the runtime characteristics of the first. The development and maintenance costs can be very different.
I am not certain if C (apart from inline assembly) can generate all possible machine code, and some translations can be fragile (autovectorization, e.g.).
Well indeed, which is why I don't really like talking about the "speed" of a language at all. What really matters is the characteristics of the idiomatic usage.
I would guess that rate of benefit relative to divergence from idiomatic purity might also be significant. If a little clutter gains a 50% improvement with language A but only a 10% improvement with language B, language B having a 15% advantage under idiomatic expression may not be that significant.
But, yes, terms like "the speed of C" do not seem especially useful.
Even "equal effort" ignores the complexity of the effort-to-benefit function as well as maintainability issues and other considerations like finding good programmers who want to use the language.
reply