0x69420

to those curious, erlang abstract form[1] is the AST representation used by the erlang compiler/etc. per [1], you can see that it's canonically made of erlang terms, and you have easy access to routines for manipulating this representation from the standard library; it's really comfy when you need it! it's also the target elixir compiles down to, and the representation manipulated by parse transforms, which in base erlang are the way syntactic sugar (notably qlc[2] and some of the more cutesy pattern matches in merl[3] (which, in turn, manipulates the very same representation to do its job. very meta!)) is done.

most BEAM languages actually settle on erlang abstract format. you'd think core erlang would be more common since it feels more like a traditional functional IR, but basically only LFE does this, because it's a moving target without any particular stability guarantees from release to release.

1: https://www.erlang.org/doc/apps/stdlib/erl_parse.html#t:abst...

2: https://www.erlang.org/doc/apps/stdlib/qlc.html#q/2

3: https://www.erlang.org/doc/apps/syntax_tools/merl.html

> 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.

the formality slider (play with it at the google fonts page linked in the article[0]) is genuinely one of the coolest uses of a variable font axis i've seen in recent memory. it feels like we're witnessing the slow and steady vindication of metafont.

[0] https://fonts.google.com/specimen/Shantell+Sans

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.

hang about, the smalltalk return operator is why objc block syntax uses carets, isn't it? how did that only just click for me?

finding it increasingly difficult to summon any optimism with respect to this stuff. opposing policy, proponents of which can fall back on "think of the children", is an uphill battle with both hands tied behind your back. the way things are going, someone born today, by the time they reach my age, simply won't have been able to get in touch with 90% of interests i value and give my life meaning.

back in my time as an (inadvisably) precociously online kid, the only real age barrier was having a credit card, so i had to beg/borrow/steal my way to someone on irc giving me a shell to a vps, and pay some other rando with a steam gift card to buy a domain then transfer it to my registrar account. and like that, i could start developing a presence in whatever online communities i insinuated myself into by acting mature enough nobody gave my age a second thought. physical realities like divorce and school troubles came and went, but moving and shaking online gave me my most steadfast friends and s/o to this day.

shift the timeframe a couple decades and i would have instead been gated by an id upload. bleak.

inkscape has had a long and quiet ascent from quintessentially janky foss creative software to genuinely pleasant to use. i still wish it were a little easier to edit the individual portions of deeply nested clip/mask operations, but if you need to crank out some icons, you can use inkscape and not hate your life, which is something i'd have called someone insane for telling me a decade ago.

genuinely remarkable, the altogether perhaps even productive mischief you can get up to, especially with `__VA_OPT__` becoming a proper standard in both C and C++ so you don't have to feel dirty about using it.

i recently made use of plenty of ugly tricks in this vein to take a single authoritative table of macro invocations that defined a bunch of pixel formats, and make them graduate from defining bitfield structs to classes with accessors that performed good old fashioned shifts and masks, all without ever specifying the individual bit offsets of channels, just their individual widths, and macro magic did the rest. no templates, no actual c++, could just as feasibly produce pure c bindings down the line by just changing a few names.

getting really into this stuff makes you stop thinking of c function-like macros as functions of their arguments as such, but rather unary functions of argument lists, where arity roughly becomes the one notion vaguely akin to typing in the whole enterprise, or at least the one place where the compiler exhibits behaviour resembling that of a type checker. this was especially true considering the entries in the table i wound up with were variadic, terminating in variably many (name, width) parenthesised tuples. and i just... had the means to "uncons" them so to speak. fun stuff.

this is worth it, imo, in precisely one context, which is: you want a single source of truth that defines fiddly but formulaic implementations spread across multiple files that must remain coordinated, and this is something you do infrequently enough that you don't consider it worthwhile introducing "real" "big boy" code gen into your build process. mind, you usually do end up having to commit to a little utility header that defines convenient macros (_Ex and such in the article), but hey. c'est la vie. basically x macros (https://en.wikipedia.org/wiki/X_macro) on heart attack quantities of steroids.

please keep the erlang ecosystem out of the llm griftosphere. jesus christ.

multiple services depending on different outputs of a single acme client can be expressed, right now, in 2025, within systemd unit definitions, without deeply integrating a systemd-certd-or-whatever-as-such.

which is basically ideal, no? for all the buy-in that the systemd stapling-svchost.exe-onto-cgroups approach asks of us, at the very least we have sufficiently expressive system to do that sort of thing. where something on the machine has a notion of what wants what from what, and you can issue a command to see whether that dependency is satisfied. like. we are there. good. nice. hopefully ops guys are content to let sleeping dogs lie, right?

...right?

also the namesake of the unit fwiw

the nonprofit line has not been believ{ed,able} or relevant for what, in tech, may as well have been a century by now. had this happened around the time the veil was lifted, that would have been something worth discussing, but this was announced last month. it is now only meaningfully addressable along the same avenue as any other american tech giant getting comfy with the us govt's controversial foreign relations.

linking old discussions is considered good style and is not making the implication you think it is.

i remember looking through these during a deep dive on type selection -- naturally radon, krypton, and arguably xenon come across as a bit gimmicky, argon has stiff competition in its genre as it's the rough style of most “modern” monospace faces, but neon is actually kind of spicy. this is the closest to the “mona” in “monaspace”, being similarly derived from helvetica and its ilk, and sits at just that right level of regularity that it's easy on the eyes after a long day in a way that i previously thought was only the purview of sf mono.

if argon tickles your fancy, you might also be interested in fragment mono (https://github.com/weiweihuanghuang/fragment-mono) a similar free software “helvetica mono”.

the tragedy of both argon and fragment mono, though, is that the latter comes in one width, and the former inexplicably supports obscenely wide proportions without letting you condense it down from the bog-standard 1x2ish. most condensed options out there are these pill-shaped straight-walled monstrosities that blur together (the iosevkas and pragmatas of the world), with a few notable exceptions (the old osdn releases of mplus).

i wonder what would happen if you went in and extrapolated the width scaling for monaspace backwards into super narrow range.

another one? was one inflicted upon the world not enough?

for starters, toolbox grouping and icon theme changes are reversible in settings, and in fact the "legacy" icons have gotten a lot of love in 3.0. they look nice at high dpi now! (it's a shame we moved away from the tango aesthetic in linux land too early because god the style can look so right and crisp on hires screens)

having used all the 3.0 RCs up till now, i can assure you all gtk3 has done is made life nicer on all major platforms. for gimp's faults (now markedly fewer) it's an image editor, a thing with a distinct purpose and pretty immediate feedback on indulgent changes nuking productivity. the cancerous low-information-density, look-over-feel trends that we associate with new gtk versions by way of gnome's visionless bikeshedding blessedly does not translate to this new gimp. pinky promise. go use it. you'll like it.

you can slap a hash on a binary distribution and it becomes "reproducible" in the same trivial sense as any source tarball. after that, the reproducibility of whatever "build process" takes place to extract archives and shuffle assets around is no more or less fraught than any other package (probably less considering how much compilers have historically had to be brought to heel, especially before reproducibility was fashionable enough for it to enter much into compiler authors' consideration!!)

i frequently generate something resembling this and/or the hamming distance texture in a fairly dumb manual way, by just doing blend mode overlay on progressively smaller checkerboards.

it's my go-to for lining up pixel-perfect uv maps for more geometric/mechanical 3d assets -- the recursive nature means you can have an easy time hitting, say, the exact corners or centers of luxels if you feel the need.

there is a very real sense in which nix has been riding on a good idea while ergonomics elsewhere in the field have advanced, yes. make no mistake, the technical work, getting programs to behave themselves in a fairly alien environment etc, has been impressive, but it's like in the marathon to get there, the idea of making that process somewhat nicer has been subject to constant procrastination. which sucks since in some sense the lay packager is working with the exact same tools as the people bringing the whole system together. not just nixpkgs dx has fallen down the list of priorities, but technical debt down to nix itself has accrued as well. the tvix effort emerged from dissatisfaction with instability (the same dissatisfaction that kept the actual version of nix used in a typical nixos install well behind master) well before any administrative/sponsorship struggle snuggle, and i still maintain that an effort more conservative in scope such as lix would have emerged politics aside, as again, what the end user sees switching to that is mostly "oh hey this random thing that repeated segfaults conditioned me out of attempting just... works now lol?" or various ux papercuts just ceasing to be. nix-at-large has a ways to go but i am optimistic