I believe this is what "Cargo-Cult Programming" is.

https://en.wikipedia.org/wiki/Cargo_cult_programming

Using 'copy' as a clipboard script tells me OP never lived through the DOS era I guess... Used to drive me mad switching between 'cp' in UNIX and 'copy' in DOS. (Same with the whole slash vs backslash mess.)

I believe this is why all modern digital watches use a 32768.0Hz crystal resonator, it's a power-of-2 frequency above the 20Khz top end of the range of human audio perception, to avoid the whole 'tinnitus on your wrist' thing.

Also a tuning fork cut for a lower power-of-two would be a bit bulky for a compact wrist watch.

The old 1980s computers also had no equivalent of flash storage though, the RAM had to store the program being run as well as act as scratch-space.

I believe youtube still uses 40 mel-scale vectors as feature data, whisper uses 80 (which provides finer spectral detail but is computationally more intensive to process naturally, but modern hardware allows for that)

that's not true, consumerism is only growing, people are not giving up anything in that regard.

The planet is getting trashed and 'the children' are doomed.

Individually We try and help, driving less, recycling and so on, but it kinda gets diluted by a billion Chinese moving into the middle-class and burning coal like there's no tomorrow.

Reminds me of the Pentium FDIV bug from 1994.... a half-billion-dollar 'ouch' for Intel were many hard lessons were learned.

Surely math libraries and optimizations have been a solved problem for the last 20+ years.

I would disagree. The dark ages were hundreds of years ago, the electric grid is much less than a century old. Plenty of countries have unreliable supply and rolling blackouts and have adapted to it or have just never became accustomed to the luxury of 24/7 electricity on demand. Being without juice is not the end of the world.

Those places generally have the luxury of 24/7 electricity, normally via diesel gensets, for key parts of their infrastructure, such as fuel transfer, hospital, food supply.

The places that don't have the fallback ready access to fallback diesel genset, like rural South Sudan or Burundi, are pretty close to an end of the world scenario.

Don't romanticise disaster. If a developed country indefinitely lost power, a huge swathe of the population would die, starting with the infants, elderly, and chronically ill. Then hunger and disease would come for the rest. Nonsense ideas that we'd MacGyver or bushcraft our way out of trouble are infantile.

Bit ironic when the path to ketosis is fasting (i.e. not using products).

The path to ketosis is by not eating carbohydrates AND/OR fasting.

Pardon my ignorance, but I thought the whole point of Rust was to be a 'safe' modern alternative to C, so all new buffers would be zero'd at a neglible-these-days cost. Why is rust half-assing this?

The cost might not be negligible for everyone?

Rust is being used and is designed to be able to be used everywhere from top of the line PCs, to servers to microcontrollers to virtual machines in the browser.

Not all tradeoffs are acceptable to everyone all of the time

Other languages can easily achieve this kind of safety. What makes Rust different is that it tries to provide this level of safety without doing extra work at runtime (because otherwise people will put it in the same pile as Java/C#, and continue using C/C++ for speed).

It’s not. That is the case. But in cases where “negligible-these-days” isn’t quite negligible enough, this still matters and unsafe + MaybeUninit is the escape hatch to accomplish it.

Also not every type has a valid "all zeroes" value in the first place.

Rust provides all the safety guarantees of managed languages with none of the performance drawbacks. It’s precisely intended to replace C/C++ because the unsafe parts of Rust are used very sparingly and result in significantly fewer bugs and security vulnerabilities.

Safe abstractions for dealing with uninitialized memory efficiently are important in very niche scenarios to get optimal code out of the compiler and for reducing the ability to make a mistake when writing such code.

Reaching for C to do this is an emotional overreaction instead of calmly dealing with a small corner case that already has workarounds even if it does involve using unsafe

This is why we're spending substantial energy building better abstractions that don't require you to write any unsafe code.

what if your buffer is 64 GiB? (ok, in practice it will be zero'd on demand by the OS but still)

I’d love to know the actual performance impact of zeroing out memory. I bet the performance cost of zeroing out memory ahead of time is negligible in almost all programs.

Here is a really dumb example:

  $ cat bigbuf.c 

  #include <stdlib.h>
  #include <stdio.h>
  #include <string.h>

  #define DEFINITELY_BIG_ENOUGH 2U*1024*1024*1024
  int main(int nargs, char ** args)
  {

    char * definitely_big_enough = malloc(DEFINITELY_BIG_ENOUGH);

    if (nargs > 1)
    {
      memset(definitely_big_enough,0, DEFINITELY_BIG_ENOUGH);
    }

    sprintf(definitely_big_enough,"%s",args[0]);

    return 0;
  }
  
  $ /usr/bin/time ./bigbuf 
  0.00user 0.00system 0:00.00elapsed 100%CPU (0avgtext+0avgdata 1356maxresident)k
  0inputs+0outputs (0major+80minor)pagefaults 0swaps

  $ /usr/bin/time ./bigbuf 1 
  0.05user 1.25system 0:01.31elapsed 99%CPU (0avgtext+0avgdata 2098468maxresident)k
  0inputs+0outputs (0major+524369minor)pagefaults 0swaps

YMMV on different operating systems. Of course this is a program only an idiot would write, but things like caches are often significantly bigger than the median case, especially on Linux where you know there is overcommit.

A non-idiot would use calloc(DEFINITELY_BIG_ENOUGH), and that will likely erase the difference because the impl will be able to rely on mmap(ANONYMOUS) creating zero pages for such a large allocation. A more realistic test would be to have a large number of small allocations that get calloc'd and then free'd repeatedly, because a) free'ing a small allocation will not free the underlying page and thus reallocation will not be able to rely on it already being zero, and b) zeroing small allocations doesn't amortize the cost of zeroing as well as zeroing large allocations does.

c) SIMD won't be as helpful when you are zeroing small buffers of non-round sizes

That's what (b) is about.

The point of rust is explicitly not 'safety at the price of performance', quite the opposite. The whole point was to create language where safety doesn't cost performance like it does in most other languages.

It is not. If it were, it wouldn't even have raw pointers, for example.

`unsafe` is just a barrier between what compiler proves and what programmer proves.

People should really read more on safety semantics in Rust before making comments like this, it's quite annoying to bump into surface level misunderstandings everytime Rust is mentioned somewhere.

In normal safe code, the compiler ensures your code has no UB. In an unsafe block, the programmer ensures the code has no UB.

Safe abstractions are created out of unsafe operations by making sure it's impossible to violate the operations' preconditions. Either by checking at runtime and returning an error or aborting the program if they're violated, or by using the type system and borrow checker to verify them at compile time (writing the code such that any program that could violate the preconditions must have a type error.)

If Rust didn't have unsafe, the only way to access the underlying unsafe operations would be dropping down to C/C++/Assembly, or hardcoding them in the compiler. This is what other languages do, and it's ergonomically worse because the barrier to adding a whole new language and build system to your project is quite high.