0x69420

> The mentioned proposal was also accepted as a defect report, so implementations may apply the fix to earlier C++ modes as well. That is why you might not be able to reproduce the old behaviour on a recent compiler even in C++20 mode.

brutal. hope major compiler vendors throw in a flag that can bring some sanity to this

victor has courted a very llm-enjoyer audience and such people are famously prone to hype (which is kinda brutal in its own way cause the language itself is cool and i dont wanna make it sound like im taking away from that). but yeah, fan activity as you put it easily accounts for the missing order of magnitude, if you like.

victor's legit and people have been excited about his work for years; squashing the history was just a bit of an optics oopsie on his part. the star to fork ratio makes perfect sense for something like bend.

- fstar: 3k stars, 267 forks

- coalton: 1.8k stars, 111 forks

- carp: 6k stars, 267 forks

- c3: 5.8k stars, 400 forks

when something is novel/young (not having had time to grow large and accumulate issues in the vein of "1 doc page out of 1000 is worded incorrectly") and (as of yet) niche (innate barrier to entry for contribution because you have to learn from square 1 what all the moving parts look like), you don't see the same activity patterns on public source hosts as with a general-purpose language.

now imagine how many other devs and maintainers are contemplating this but just haven't been pushed to their personal breaking point yet. or take note of how many, when asked about the spam problem, just nervously go "yeah it's kinda rough haha...". or how many will vent about it on their twitter-like of choice with increasing frequency.

remember hacktoberfest 2020? that's just all public-facing source 365 days a year now, except instead of "updated README.md" it's some vaguely-plausible fix... then you read the PR body and someone couldn't even be bothered to, or, just as likely couldn't explain it themselves. and that sort of sinking dread sets in.

just like cvdazzle before it, this is bound to do bugger all one model into the future, and in the meantime you'd still really want to stick a pebble in one shoe and wear platforms or something to mess with gait analysis

you should read this less as convincingly adversarial fashion and more fashion inspired by the vague concept of computer-vision-aided surveillance, which, mind you, is still pretty rad, just more vogue material, less ieee spectrum material

not that it was necessarily the intent, but you laid on the "PS: you have intrinsic value" with the exact same tone and cadence as someone trying to work in a "you are loved/valued" while trying to talk someone off the tenth-floor railing. jesus, it's really bleak out there, huh.

the obvious llm tells make this infinitely less funny than natural-language esolangs from 2 decades ago sorry

"did you see what the president just microblogged"?

come now, surely you understand why it would be beneficial to the commons to have a snappy, catchy term that already has purchase in the public imagination be free to use, right?

but our dwindling attention spans are caused by a deluge of material sapping our energy before we can devote it to something worthwhile. developing a fast and frugal mental filter for insubstantial walls of slop is a new prerequisite for not being so exhausted that you default to saying tl;dr to the real, good stuff.

    2. Fork the upstream project (optionally remove other -- now useless :^) -- build scripts),

oh god, it's meson wrapdb all over again. my heart goes out to all the library maintainers who'll have zig users go into their issue tracker like "and if you don't want this patch, don't worry, i'll just submit it to allyourcodebase" implicitly threatening upstream with a perpetual drip-feed of issues pertaining to a questionably-maintained fork they don't control.

    Make / GNUMake / CMake / autoconf / bash scripts / batch scripts / powershell scripts: Zig is a complete build system that works on all supported platforms and can do everything those other tools do.

this bodes well.

i am begging people to please stop doing this genre of "compatibility" initiative.

look at inspect source. the comments like

    <!-- EXACT setup from working simple-test.html -->

    <!-- Chiptune3 now loaded via Vite build system -->

are pretty stark llmisms. also the random emojis in front of the duplicate and triplicate "Browse Music" links, the corny tagline in the footer, yeah nah. if this was made by human hands, it could only have been as elaborate satire. bad/inexperienced human code does not look like this.

nixos is already, from a certain perspective, an exotic take on gentoo. take away cache.nixos.org and it becomes a source-based distro. it's not even too out-of-the-question to do traditionally gentoo stuff like globally set -funroll-loops -O3 and rebuild your whole system, but the operational benefit of staying standard is getting to use binary caches since reproducibility lets them substitute transparently for local builds in the standard environment with the standard settings. one thing nixos lacks is an elegant analogue to gentoo USE flags; "tell package A to use optional package B" has like two different conventions in nixpkgs for individual packages, alongside bespoke things like configuring everything to use cuda or not. furthermore, pkgsrc, gentoo prefix, and nix are three of a kind in terms of "third-party package manager on a non-native OS"

personally, i used gentoo throughout most of my teenage years, and now use nixos viewing it as a successor, since you can screw around using the thing as a meta-distribution, but roll back when you hose your system.

gentoo freebsd existed for a while for funsies but nobody cared and now it's dead, same with gentoo openbsd. each was portage integrated a little more intentionally on top of a respective bsd than just "bung it in /usr/local/bin and call it a day". practically speaking, they were implementations of gnu/k*bsd.

nixbsd similarly exists (nix deeply integrated into freebsd), with heroic efforts made to transfer nixos's abstraction over init systems for system-wide configuration; last commit was two months ago so i guess not dead yet?

you can run nix on gentoo, or gentoo prefix on nixos with nix-ld turned on if you feel like it

void's claim to fame with xbps is a bunch of sandboxing and bind mounts for build environments. nix already has to sandbox just to get off the ground wrt reproducibility.

void, gentoo, and nixos all offer some degree of libc freedom. on void it's first-class, on gentoo it nearly is, and on nixos it's here be dragons. libc freedom doesnt really jive with using a bsd as a base; vertical integration is kind of one of the contemporary selling points.

so to answer your question, the result would be nixbsd in an alternate timeline where nixpkgs's analogues to USE flags/eselect/profiles are not hot garbage (i say this with love as a user), and void would fail to exert a phenotype.

the consequentialist "may as well" or "for all intents and purposes" is implicit. of course you can't ascribe literal teleology to something like a megacorp; diffusion of accountability is a defining trait of any sufficiently large organisation. but, "misaligned incentives" and hatred look the same from the sole of the boot. in both cases, you probably want to get your head off the curb before it comes down.