I think you & I are really back & forth-ing "the PLang not enforcing/strongly encouraging a very specific way of doing things that a whole ecosystem/community organizes around". Relying instead on self-organization has many pros & cons, to be sure. Lisp suffered much the same "until" Common Lisp (which still leaves many things open). My tag line lately is: delegation affords so much, but trust sure is tricky. Much of the time people seem to discount the often rather large cost of establishing/maintaining trust. (I'm not saying you are - just that it's an easy thing to do. I think it's why there is this is a big megathread on "trusting rust", even though "rust" is a veritable suffix of "trust". Lol.)

EDIT: With Cython how I mostly kept things organized was the "caller allocation" so common in C where memory was always managed the usual mostly refcounting way of CPython/NumPy, but I had dozens (maybe even 100) little "kernels" I could pass that memory into that could even use Intel/MSFT "intrinsic" asm calls (things like immintrin.h) or even just #include C code which did similar. It didn't seem too bad to me, but Nim always seemed a more complete solution (at the PLang level - not counting ecosys). (And these days there is even NimPy (https://github.com/yglukhov/nimpy) to write low-level speed-up code for Python in Nim.)

With access to inline asm, all speed is ultimately more a measure of effort applied than PLang. So those perf ideas are just "with my level of effort". Even Python via Cython has pretty direct access to asm. The "do it in pure X" that Sun popularized (even in a meta-/cross-PLang-sense) as a business attempt to define Java virtual machines as The platform has had many casualties, not the least of which is the quality of discussion of PLang practicalities, not just on HN, but everywhere.

There are other benchmarking points in that document about measurement footguns that can arise from targeting a specific duration like the 200..400ms of TFA with an easy but careless problem scale-up (like the Ben Hoyt example of footnote 4).

With that tool, in user space with just CPU freq pinning, I routinely see CPU bound times that are stable to single digit microseconds month to month on the same machine and see 0.01% to 0.2% effects on 10ms scale activity (yes, 1..20 bps) and the reported uncertainty usually captures the variation all right, but the distribution is not really Gaussian/Normal and instead has more shape parameters and/or you would want a 95% CI or some such as mentioned elsethread here.

Another lesser known wrinkle along these lines is that if more of Aristarchus of Samos' work on heliocentricity had been developed into a "calculational framework" for planetary motion by a contemporaneous Ptolemy competitor (a la Copernicus in 1543), various relativity ideas might well have started in 270BC instead of 1600 AD.

Aristarchus was already WAY ahead of a few games - making a guess that "absolute rest" was illusory and tiny stars were similar to giant Sol. If not for Archimedes' serious star power, we might not even know of Aristarchus' heliocentric ideas! Relativity ideas of various kinds are short intellectual hops from "the absolute rest of your intuition is illusory".

Aristarchus and his supporters just had to assert The Stars were very distant -- far enough for there to be NO PARALLAX! Various "coincidences" all conspired to suppress Aristarchus' plausibility, like: A) Just HOW DISTANT stars are/local galactic stellar density &| B) poor human VISUAL ACUITY relative to C) Earth ORBIT vs. Sun LUMINOSITY (parallax baseline) & maybe existence of Moon to vent atmo &| D) VERY SLOW (3 millennium) development from near prehistoric glass (1500BC) to grinding lenses for human eyes in the 1300s AD leading to Galileo's telescopes & etc. If ANY of (A)..(D) were about ~10x better (ALL of which are imaginably so), the day that universe changed could've been much earlier. Heck, even if Aristarchus just had a really good spin doctor like a major religion pushing the plausibility of "Sun=A close Star", that might've been enough.

Archimedes almost invented the underlying ideas of integration and limits and all that, too. Close but no cigar, but (had that been in hand) analytic geometry and differential equations are short steps away. I mean, Newton surely noted the equivalence of gravitational and inertial "mass" (charge vs. kinematics) which is the weak principle of equivalence of GR, after all. Like I said - "littered". ;-) There are probably whole books written on the topic (or adjacent topics) of "All the Things Humanity Nearly Figured Out Earlier" that have a more historical bent than the usual "sci-fi tilt".

So, to push back a tad on your more recent "only thing that I am aware of" and to maybe explain my above point better, I do think there was enough information/ideas in the abstract in Galileo/Newton/Leibniz' times to suggest the idea. Leibniz himself pushed back hard on Newton's absolute space/time (long before Mach). For Leibniz, it would have been counterintuitive space/time vs. counterintuitive fixed speed. So, that pushback itself could have been enough of a "clue" in your terms -- in some alternate timeline -- to drive a speculation-observation cycle starting from different inertial concepts - with Galilean moon eclipses then enough a clue that fast speeds existed to fool our slow-speed intuitions. (And all this in the "modern era".)

So, I continue to think it "not impossible" that the relativity principle could have arisen before any EM theory at all -- it just didn't. That matters for these kinds of speculative questions about what information horizons support what developments. A single "fast enough" fixed speed is is not that wild & crazy. The modern world has a zillion obscure physics theories like that (mostly just because so many more people work on that stuff, but that's a probability thing, not a possibility thing, and I suppose also partly inspired by how physics turned out - so not truly independent). History is littered with things that could have happened, but didn't.

P.S.: and apologies for "mistakes a fundamental error". I of course meant "makes a", if you wanted any evidence that I was not an LLM. ;-)

Thinking otherwise mistakes a fundamental error that the only way for something to happen is how it historically happened. Reconciling observations forced relativity historically, but it could have been sussed out without those. That there were very fast but finite speed phenomena (which could motivate relativity reducing to Newtonian models) was seen in 1676 by Rømer with the speed of light and eclipses of Io, a Galilean moon of Jupiter. It probably could have been done with Galileo's telescopes in 1610. (That is just one example of a phenomenon with a very fast yet finite speed to suggest other experiments to test that "hypothetical relativity".)

TBH, this all relates to teaching "physics without calculus" and that sort of thing. Is the most clear presentation/derivation that which mirrors the history of our muddled yet ever demuddling ideas or that which starts from our most thoroughly demuddled ideas, best notations, etc.? The momentum is certainly the historical approach, yet there are notable exceptions.

Of course, throughput at one "level of work" is often latency at a higher level (like command-to-command execution, for example). So, "what matters" might be throughput or "latency". It all depends. :-) People often fiddle with such semantics to market methods, products, ideas, ... and marketing is often at cross purposes with understanding.

My GF when I was first learning these names was convinced the Unix principals did all this quite deliberately and "finger" was her headliner argument. Evidently, even in 1971 someone complained: https://blog.robertelder.org/intro-to-pinky-command/ (relevant to that source, Usenet/Net News/mailing lists may be another social network which never exactly died and even today LKML, zsh-workers, etc. are main communication avenues).

There are a million ways to define both "top 10 language" and "weak std lib", but the C stdlib is not great and C++'s was bad enough to spawn Boost. And I'm sure many firms all but say "do not use" parts of many top10 stdlibs. In any event, we don't disagree that Nim's stdlib being stronger would be better or that poor delegation or unconsolidated discussion are problems. We disagree on very little, including I'm sure that there is more to a PLang than its stdlib.

What is present/missing in any stdlib (or really in almost anything period) is also often much more subtle and subjective than simple sales pitches one hears. To be concrete, there are "useful" (to someone) things in the Nim stdlib not in either Python's or Go's like std/critbits, std/pegs, ropes, packedsets, intsets, editdistance, etc. Nim stdlib substring search behind "xyz".find() is layered to let you, if you want, pre-build a `SkipTable` (the way regex engines let you pre-"compile" regexes). Subtle in diversity of both kind and granularity and subjective as in "who cares?"

Yes, all that and more is all available in all the ecosystems of anything "popular", but that brings you back to "trust proxies", like "prerelease" numbers, a very weak one, IMO. E.g., I have never used a neovim with a version >0.13, but it's been a trooper; one man's 0.7 is another's 7.0. TRUST IS TRICKY! A count of distinct reliers for some values of "distinct" and "rely" or various update patterns would be better (have their own issues, of course, but at least measures "company" as in "what misery loves", LOL).

There has never been much prog.lang. benefit from being "in the stdlib/core" in Nim (unlike Python or Go, say). The benefit is more "software distribution" for the dependency allergic, but the Nim culture is much less micro-deps than seems in vogue lately. All that said, I think having a more batteries core distribution is valuable - just less than you might guess - and practically that needs delegation.

    #!/usr/bin/awk -f
    BEGIN {
      # Split on spaces so multi-byte utf8 works
      nText  = split("♥ P E A C E ♥ F O R ♥ A L L", tmp, " ")
      for (i = 0; i < nText; i++) text[i] = tmp[i + 1]
      color0 = 12; color1 = 208  # xterm-256 color cube range
      nColor = color1 - color0   # Could be a pretty gradient
      w = ENVIRON["COLUMNS"]; if (w == "") w = 80
      h = ENVIRON["LINES"];   if (h == "") h = 24
      freq = 0.2
      for (t = 0; 1; t++) {
        x     = int(w/2 + w/4*sin(t*freq) + 0.5)  # x pos ~ sine
        color = color0 + int((nColor*t)/h)%nColor # cycle colors
        ch    = text[t % nText]                   # cycle chars
        printf("%*s\033[38;5;%dm%s\033[m\n", x, "", color, ch)
        fflush()
      # system("sleep 0.1") # awk has no builtin sleep
      }
    }

FWIW, I think ancient practice to reach for `bc` instead of `awk` or even the arithmetic built into shells often annoys. The only reason I keep `bc` installed at all is to compile Linux kernels. Someone had some patch set to Linux to eliminate this very dependency many years ago now.

[1] https://news.ycombinator.com/item?id=48830669

Anyway, he seems like a very nice fellow and I wish him and almost all T-shirt designers well. That bash script just gave me a lot of pause. (And even that seems possibly downstream of him being nice and doing it himself to spare his team from what he called a "FrankenProject".)

{ Also, it was my own Py version which I mostly did in case anyone wanted to actually run the thing after such interest was expressed on this thread. :-) }

I already said regular devs and LLMs can both gen copy-pasta. That said, being "mostly" a Python dev, asking some LLM to translate to bash for him seems even more likely to me. Only he or those close to him knows for sure. You & I cannot settle it here conclusively (as also said).

I also noted from the video that the ♥s (hearts) worked on whatever version of bash he tested with though it failed for me (which is why I wrote that Python). And his terminal title bar is switching between `tput` and `bc` and such meaning that what he was demoing was not some Python script. ¯\_(ツ)_/¯

EDIT: Ah..another resolution of the hearts is to not run in an LC_ALL=C environment. Oops! `LC_ALL=en_US.UTF-8 bash ..` fixed it. Oh well, I think the Python script is nicer in almost every way. E.g., you could |head -n60 and send it to a line printer/dot matrix reminiscent of the 1980s computers he shows in the video, although your printer driver would have to strip the color escapes with a `sed` or maybe https://github.com/c-blake/bu/blob/main/noc.nim. ;-)

    #!/usr/bin/env python3
    from os   import environ; E = environ.get
    from math import sin
    from time import sleep
    text = "♥PEACE♥FOR♥ALL" # The text to sine-scroll animate
    nText  = len(text)      # Number of utf8 chars
    freq   = 0.2            # Frequency scaling factor
    color0 = 12             # xt256 Color cube segment 12..<208
    color1 = 208; nColor = color1 - color0
    (w, h) = (int(E("COLUMNS", 80)), int(E("LINES", 24)))
    t = 0
    while True:
        x = (w/2) + (w/4)*sin(t*freq)           # x pos via sine value
        x = max(0, min(w - 1, int(x + 0.5)))    # bound to tty width
        color = color0 + ((nColor*t)//h)%nColor # cycle colors
        ch = text[t%nText]  # Get char & Use xterm-256 color escs
        print("%*s\033[38;5;%sm%s\033[m\n" % (x, "", color, ch))
        t += 1
        sleep(0.1)   # original used bc shell outs to rate-limit