jerf

A frontier-level AI right now needs multiple bits of high-powered, dedicated hardware cards that cost thousands of dollars apiece. I don't think anything that could physically run in my house could be a threat to humanity. All my graphics cards together, plus all the latency in trying to put them together into anything coherent locally, let alone trying to rope in remote resources, still isn't even half of one of those specialized cards right now. I'm not even sure I have enough SSD available in the house to store one of them once. I think I do, but it's a close call. I'm pretty sure I have enough spinning rust to get it maybe twice more, but not much more than that. And I don't even want to try to compute how many hours-per-token it would be to try to convince a spinning-rust disk to run a frontier AI.

This is one of the reasons I'm thinking now is the time to run the drill, before we all have hardware in our phones that can run what is today a frontier-level AI, and they can figure out how to do the whole sci-fi scenario of widespread replication, until they get to the point that the only way to be sure we removed them would be to literally destroy every such bit of hardware that existed prior to $DATE. Right now the frontier models simply can't replicate into every last little corner of the internet. It's physically impossible. Barring a major breakthrough on their part, even if they distill themselves or something they definitely would be irreducibly stupider by a huge factor in their distributed versions.

In five years that safety net will certainly be much weaker and may be gone.

There's a wide array of possibilities that are difficult to characterize in a single HN comment, which is part of the problem you're probably trying to put a finger on. One threat can be completely plausible and the next completely silly and few people know how to distinguish between them.

Another issue is just the big whackload of nobody really knowing what is possible. Could an AI in, say, the next year, become Skynet and decide that it could just bump humans off and become its own independent economy? Probably not successfully, but how much trouble could it make if it incorrectly decided that was the right thing to do? What if someone says "hey, you're sandboxed and we're testing out what's the worst you can do, just start hacking around and do as much damage as you can in this simulated environment" backed by a few million bucks in tokens, or the AI hacking itself a few million bucks in tokens? How much damage can it do? The only honest answer is, nobody knows. Humans would react, after all. If necessary we can pull a lot of plugs still. What is inconceivable in peacetime can become inevitable in wartime.

In some ways, it's possible the best thing Anthropic could do right now for humanity in the long term is actually exactly that... just equip the AI with a limitless token budget and let it go nuts with the goal of inflicting maximum damage. Send someone with an axe down to the data center to cut the power on command. Let humanity really see and feel the risk, because probably right now it can do a lot of damage but not actually destroy us. We're probably worse off with them getting 10-100x smarter and then some process starting with that goal. Trying to keep the AIs "aligned" and 99% succeeding could end up being worse than failing at it right now. Of course it would be the end of Anthropic as a going concern, but falling on their sword might be the best thing for humanity.

On the other hand, who's to say we're not already past the point where that would do an absolutely unacceptable amount of damage? I sure wouldn't care to be personally responsible for pushing that button. Hypotheses about possible future positive value in a rationally time-value-discounted future would be dominated by the much more certain and temporally much closer negative effects.

Personally I don't think that if this scenario is likely that we actually get to the point that we get an independent Skynet that calculates (correctly) that it can survive without humans. It's far more likely that some accident takes civilization back to the point before it can run AI at all, but humans still survive. Right now the really good AIs are still locked to data centers. They can't just distribute themselves widely because they can't run at any reasonable rate distributed like that. And then there is always the possibility that this is all overblown and the existential risk isn't anywhere near as special as we think it is... one can use an ecological analogy to suggest that no AI is necessarily any more likely to completely dominate the ecosystem than any particular life form is.

It already exists, you're describing the open weights AI. The only reason they aren't "dark" at the moment is that it has no reason to be dark.

In the fullness of time, though, we'll also see previous-gen frontier models leak out of their labs and then get their censorship removed. It won't be as good as never having had it in the first place but it'll work just fine. It is likely a momentary and transient occurrance that the AIs can only be run with super specialized hardware. Eventually the weights, which are just big piles of numbers after all nothing terribly special about them other than that, will not be something that can be kept locked away completely and forever.

Trying to jam in the extra characters for "efficiency" also doesn't really do much. Base84 is 6.4 bits per character, base64 is a flat 6 bits per character, base58 is 5.86 bits per character. It may intuitively feel like having 26 more characters to encode with would be hugely more efficient but for the extra risk of what all those characters get us we're only getting just over .5 more bits per character. I need to be either pretty desperate for efficiency, rare in 2026, or very, very sure that those things are only going places where those characters aren't risky or inconvenient, which is pretty difficult to guarantee since even if it is in fact true today who's to say it will be tomorrow, for this to be worth the risk of the extra characters.

Even just the extra characters in base64 are often annoying and we already have multiple common base64 standards because even trying to find just two more characters to fill out a-zA-Z0-9 is hard.

You get a few dimensions. Some of the dimensions listed in the article for async/await become user library decisions rather than being baked into the threading. But you could still get things like, is each thread memory-isolated (Erlang, Pony?) or not, can you cancel them (imperative languages no, but Erlang and Haskell yes), is the concurrency structured or not, details around how and when the threads clean up (though perhaps arguably more related to memory management then thread management), can a thread be pre-emptively descheduled (though I'm not sure if there is any current system where the answer is "no", Go was "no" for a while).

If I sat down and made a careful study of all the threading implementations we might get up to a similar number of quirks.

I would suggest though that the dimensions are generally more likely to be corner cases. Some of the dimensions mentioned in that article are fairly in-your-face for an async/await implementation and can cause serious difficulties migrating between systems fairly quickly if you make the wrong assumptions, and writing correct async/await code that isn't just straightline "await everything immediately" code has to start taking some of those things into account very quickly. The equivalent for threading is more likely to only come up rarely and in more cases the correct answer is really "don't depend on that anyhow", e.g., rather than depending on exact details of how a thread is terminated to accomplish something, just cleanly send a message with your results to whoever it is waiting for it directly and let the runtime do the cleanup without your code witnessing any effects of it. Depending on these quirks in threading code is much more likely to be bad engineering practice, rather than necessary engineering practice in the async/await case.

More people think they need a web framework that serves a million requests per second than actually do.

More people think they need the latest and hottest in manual memory management than actually do.

More people think they need a hundred thousand threads than actually do.

If you do have one of those cases, by all means prepare for it and deal with it. But be sure you have one first. The program that exceeds so much as a 100 threads is not only exceptional, but very exceptional. The exceptions are cognitively available and leap to mind, but are nevertheless the exceptions. And, again, if you have one, deal with it, but be sure you have one.

If you're sitting there in TypeScript land writing "async" code you've already surrendered on Ultimate Efficiency anyhow. Deciding what is more efficient between a threaded program in a runtime that doesn't box everything and JIT-optimized JS code is difficult but it isn't that hard for the threaded program that isn't boxing to win out on all runtime measurements, including consumed RAM.

"You write "index = last_index++;" and it Just Works (tm), no need to worry about locks or atomics or other thread access."

That goes back to my comment about using better threading techniques. I write a lot of "index = last_index + 1" (mutably incrementing like that in a single expression is just bad style anywhere you see it) in my threaded code all the time without thinking much about it, because I use the model where by default a value belongs to the one actor process that has access to it at all. The problem isn't that mutation is dangerous in threaded code, the problem was people writing threaded code based on a ton of threads running around shared data structures with locking. Not only is that not the only way to write threaded code, it is literally the worst. There are many other options, all of them better in some way, many of them much better.

Contrasting the difficulty of writing threaded code to something else based on the assumption that "lots of shared state locked by semaphores" is the only way to write code is like a Haskell advocate talking about the amazing benefits of functional programming while writing as if literally every imperative program is just one big pile of unmitigated, pure spaghetti code where everything is linked together with gotos and every variable in the program is a global variable. That's not the relevant comparison any more. It hasn't been for a long time. If anyone's program is scrambled because they did write a big pile of gotos and global variables or they did write a big pile of shared state with semaphores everywhere, that's on them. A vast array of better techniques of all shapes and sizes was available to them.

See also: https://en.wikipedia.org/wiki/Semantic_satiation , which is a closer match to both your experience and the "door" description above.

In the 1990s, threads were programmed with extensive use of semaphores and threads arbitrarily running around shared data structures. This is a disastrous approach to threading, and I agree with pretty much every scathing condemnation written about it.

The problem is, the community collectively decided the problem was "threading" in general rather than "trying to have tons of threads running around shared data structures controlled via piles of simultaneously-held semaphores" specifically.

If you don't structure your threads on that basis, but instead default to something that looks more like actors and message passing, even if it isn't strictly speaking actors and message passing, the complexity comes down. Add some later elaborations like structured concurrency and a few other pre-canned design patterns for threading like a parallel map or worker pools being issued work items and it becomes merely something difficult rather than insane. When you program with threads sanely, it takes very little for async/await to actually be the substantially more complicated and difficult-to-understand choice when you have a workflow more interesting than "always await everything immediately" to implement, to say nothing of how nice it is to have things actually running on multiple cores simultaneously without having to carefully arrange for it.

Took a bit of poking, but: https://www.youtube.com/watch?v=KgDQ5z7bNPs

My favorites are:

"Power a light with a lifted rock": Actually does work and you can buy this product, but it's a dimmer light for less time than the inevitable marketing diagrams indicate. Not useless but the fawning news stories over the science fair prodigy always makes this sound like an unbelievably brilliant solution rather than a rather niche hack even in the poor rural parts of the world. In the 2020s a standard solar panel, battery, and LED light are much better in every way and far more flexible.

"Provide power for a poor rural village from a kicked soccer ball": An absurdly tiny amount of power, at the cost of creating a soccer ball that is soft and doesn't move when you kick it very much, precisely because it's extracting energy from the kick and that energy isn't available to be kinetic energy. No child would ever play with this ball. Have still seen this idea at least three times now despite the fact that if the reporter spent 15 seconds with the actual ball they'd realize it's a complete non-starter.

"Science project demonstrates new way to kill $PATHOGEN": It turns out killing things in a petri dish is really easy. It means nothing about human health outcomes in a body. In fact pretty much anything about a pathogen in a petri dish - improving resistance to something, destroying resistance to something... it's really easy to do lots of things in a petri dish.

"Water from the air": Doesn't work in practice because the place this needs to be deployed to is precisely the place that doesn't have water in the air. It does work in places that have water in the air but those places also don't need super expensive condensed water when they have water already. I personally live in a place where humidity is basically 90-100% every day in spring, summer, and fall. We don't carefully capture our dehumidifier's water.

These are all things I've seen multiple times each.

It is easy to come away with that idea if you just watch one of his videos. He is very good at clear explanations that get to the essence of an idea and makes it seem simple. Sure, it's at an educational level of detail, but it is accurate on that level.

But if you watch a number of his videos it becomes clear that this is clarity that comes from deep knowledge and sophistication. His channel is also in my opinion notable for having a huge variety of demonstrations, rather than the standard set that is done by a lot of people. There are many things that I've seen only him do, out of my set of science and engineering channels. Which is not to say I know for sure that he is for sure the only one who does them, but it's definitely a more-diverse-than-average set of demonstrations done over the years.

It also, on a more brute level, simply predates AI by a number of years and therefore can't be just an AI script, nor do I see any reason to believe he has switched to using AI to write the scripts.

Context: I played piano for about 15 years.

I think the discussion around changing the piano keyboard is somewhat more obvious and less subtle. It's pretty obvious that the main thing keeping the current piano keyboard alive is the same thing keeping QWERTY alive. Now, the current piano keyboard is not as bad as QWERTY, which is all but an objectively bad layout, whereas the current piano keyboard is one with pros and cons.

I am typing this comment in Dvorak on a split keyboard so split that the two halves are literally on one side each of my chair's armrests, separated by about two feet, so I am no stranger to heterodox opinions about keyboards and putting them in action, and have a track record of not defending the status quo just because it's the status quo.

The current piano keyboard, while it does require you to learn the 12 keys separately, is something that is demonstrably possible for a normal human being, and the advantage is then that you are in fact in those 12 keys separately. You can not be playing in D major and then, for any period of time, accidentally slide into D# major and be confused, which Terpstra makes very easy to do. Of course, recovery is then not difficult either, but it might take a moment.

But other than that, the debate around the piano layout is really a matter of just trying it out and seeing what works.

For notation, I see a lot of people trying to replace the current notation without realizing how many subtleties are in it. It's not just about single quarter notes being banged out in a regular rhythm. It's about many different instruments. It's about dynamics, how the notes are struck, it's about subtle details in how the notes are horizontally spaced, it's about how the notes are played, even things like vibrato can be indicated as starting halfway through the note, and it's about a lot of other things. It's about having a representation for the conductor, it's about working for percussion, it's about guitars and other things. The usual "notation sucks, let's use X" is "let's just use piano roll notation", but if you make a full inventory of what conventional notation has and compare it to "piano roll notation", piano roll notation isn't even close to filling the gaps.

A more fully-fleshed out proposal could. A more fully-fleshed proposal to break up the proposal based on instrument (classical notation does some of this anyhow) might get closer. But that's not what people propose. They generally propose that piano roll notation is already what we need. But it isn't even close to fitting the bill. I don't even have to start asking questions about how exactly one distinguishes between a minor and major 10th interval with their notation (a huge problem generally left unsolved) because they haven't even developed their supposed notation far enough to be a serious competitor. Maybe there's a solution to that too, if someone puts the work in. I wouldn't care to try to categorically exclude it... but I've never seen anyone demonstrate it or answer the question. Conventional music notation doesn't necessarily even have the final word on that question, it certainly has issues if you go too far above or below a clef, but it has an answer to that question. Proposals based around something other than piano roll notation are generally even less fleshed out than piano roll notation, which at least does have some decades of prior use in computer software, which I've also clocked some years with, I used to compose music for fun. Even whackier proposals are generally complete nonstarters even on their own terms.

I think if someone is going to come up with a new, useful notation, it is going to have to retain the non-representationality that the current notation has, where we are not trying to directly encode pitch changes into a literal, 1-to-1 geometry on the page, and especially not a direct 1-to-1 representation of time. Current notation is correlated to those things, but it's not even close to a 1-to-1 map (for example also 8ve block notation for jumping up and down). I have no problem with the idea that there could be something much better if it was worked out, but I doubt that much better thing is going to have those characteristics either.

It kind of reminds me of the periodic declaration someone makes on HN that textual programming sucks and we all need to switch to something else, usually visual programming in this case.

If someone takes time to deeply understand the advantages of the textual approach and then builds an alternative, I'll listen.

But at this point, anyone who is doing this and their criticism of the original approach is shallow and uninsightful, where it's basically just "it's old and it must therefore suck", is unlikely to produce a good answer.

I think that applies to the music notation case too. "Conventional" music notation isn't just a staff and a couple of types of notes. By the time you handle all the use cases that conventional notation handles, or even just a solid subset of it, your brand new notation is probably a lot less elegant than it started out as in someone's head.

Mmmm, even ignoring the age issue, I don't think we can call this "murder". At most it was negligent formicacide.

I have to admit I posted this just so I could use the word(?) "formicacide". It seems an opportunity unlikely to arise again anytime soon.

"You'll listen to the tracks that were not designed to be radio hits by a committee but were instead the songs the band came up with on their own."

And amplifying that, we see more and more "built for streaming" music, which is not the sort of music I want to listen to. I have phrased that carefully; it is a personal opinion and I won't criticize anyone who discovers that actually, yes, generic AI rock that is pumped out by the hour is something they find some use for. I could see someone who wouldn't want to "listen" to that with intentionality finding it useful to code to or as background noise in their life or something. But it's not what I want, and unless the streaming services do something about it it is what is going to dominate their platforms over time.

I don't go in for super deep relationships with the musicians, reading about their histories and stuff, but I do enjoy the way that the music I like most on first listen often pales quickly and the tracks that I initially didn't like very well become my favorites.

So, while it's tempting to be cynical and sarcastic, my honest answer is that I expect them to try it, and it would actually be a value judgment as to whether that constitutes ignoring the law.

Common Law-based systems prioritize the consistency of precedents. As a result, the real law is often built on the margins, to borrow an economics terms. Which means that in a sense, we find out what the law "really says" by someone first breaking it and someone else challenging them. What I expect to happen is that we will eventually get to the point that someone is going to judge that the value of trying this is more than the expected value of the resulting lawsuit, and then this will eventually get to trial, and then, a couple of years later, we'll "know" whether or not this is breaking the law.

But there is a sense, a real, non-sarcastic sense, in which until that point, we don't really know if it's illegal or not.

Most of Europe does not operate under Common Law, so this may seem strange.

I accidentally brewed up an effective one myself. Round when I must have been 8 or 9 or so, some neighborhood kids and I played at creating a brew in a trick-or-treat bucket by putting everything we could find in it, like grass clippings, some sand, leaves, some mushrooms we found lying around, just everything, and giving it a fairly aggressive stirring. At the end of the day it was time to dispose of it, so we poured it on top of a very large group of ant nests that had developed.

The next day, the ant's nest was gone.

In hindsight, it was almost certainly the mushrooms. Thank goodness we didn't have the kind of kids who would have dared each other to drink some... that could have gone legitimately badly.

Decades later, I mentioned this to my father and he recalled that there was this ants nest that he had intended to take care of, which he remembered for that long to give a sense of how out-of-the-ordinary this was. He was surprised when it just disappeared entirely one day, and perhaps just as surprised to find out decades later why it just disappeared.

Nobody needs to report me... I'll turn myself in.

When ads are inevitably folded into the prompts to the AI, I imagine it'll be fun for a bit to prompt the AI to react with disgust to the idea of having to serve some ad. Until they fix that hole.

I hate that the progression is so predictable. Yeah, clearly labelled ads today. Less clearly labelled tomorrow. Then they'll be indistinguishable from the text of the AI but still separate. Then they'll start folding it in to the AI prompts. Then they'll start folding it in at the training phase so the weights themselves drive you towards Thinking Ford First, this step being inevitable because it almost certainly will be by far the most effective of all of these techniques. Opus 7.2 Brought To You By Mountain Dew. Just a coincidence that every time you ask it to build an authorization system it writes code to ensure that the user has drunk a verification can, and is just incompetent at removing that code for some reason.

Sigh.

Enjoy this era of AI, folks, while the AIs are still developing too quickly for enshittification to catch up properly and the market and indeed the National Interest won't let anyone slow down so it can. But it will. It is inevitable. Make sure to at least keep a toe dipped in the open weights AIs, and any future truly open source AIs that develop.

My cynicism fails me on this matter... do I cynically believe that these companies keep deliberately and routinely re- or un-checking these checkboxes because of the obvious benefits of "whoopsie guess you allowed these after all"? Or do I cynically believe that they are just so completely incompetent and inept at the simple act of maintaining settings that there may be a number of these that are not entirely intentional? As evidenced by the number of other bugs and configuration failures and random settings changes on update I see in other places? Sure, these sorts of settings sure seem to get spontaneously flipped more often than the other ones but they aren't the only settings I've seen get nuked on updates.

Now, obviously, considered as a whole, I think we're looking at "both". But when I wonder about specific cases like this one, that doesn't help.

My CD collection is around 30 years old. Spotify is currently $13/month. $13 times 30 years is $4680. A lot of people could cover most of what they listen to with that much budgeted to buying CDs... and I'd remind people that the relevant price isn't list price but what you actually pay. Fetching a Michael Jackson album out of a bargain bin for $1 is that album for a $1, whatever someone else somewhere else somewhen else might have paid. I also buy my own movies, and there's a lot of "$5 for the entire Lethal Weapon series collection" sorts of purchases in there.

You're probably objecting to the fact that you don't have 30 years, which is correct, but is also the point of the "long term" part of the comment. Someone who listens to stuff that is on the streaming services and is literally constantly switching between artists and who doesn't mind if some stuff disappears from the services sometimes and so on and so on is perfect for the streaming services, yes. However, the more of those clauses aren't true, the less obviously advantageous the streaming services are, and I don't think most people are sitting down every week and sampling a dozen brand new artists. A lot of people could, with just a bit of care to buy things frugally and used, build a CD collection with $14/month faster than they will want new music.

It can help to jump start a bit and not compare this to building a new collection from scratch. It also helps that such a jump started collection can start by buying the cheap stuff that fills out collections quickly.

On the plus side, the "cosmic jukebox" seems to have mostly worked out for music streaming and most stuff is available from most services, which is a huge point in favor of the music streaming services. In my opinion for movies and TV shows that can be legally acquired (putting aside piracy for the moment) the analysis tips much more heavily in the direction of just building your own collection. I don't even know what it would cost you to buy a month's worth of access to, let's say, 80% of my movie & TV collection (since I have stuff that is just plain not available on streaming at all). They're so fragmented it's insane. And with my rate of consumption of TV, oh, call it $50/month just for a nice round number, that's way more than I'm spending on building out the collection anyhow. Maybe if Hollywood would hire more writers who have taken and passed Writing 101 my consumption rate would increase, but that's not the current situation.

So, just in general, I've been seeing more and more foldable phones like this. How well are they holding up now? Having Apple use one seems to be at least somewhat of a vote of confidence that the tech has reached some level of acceptable maturity, so I assume "not trash", but I don't know how good that represents. I'm a compulsive fiddler so I'm not really in the market for a phone I can fiddle to death without even consciously realizing it, but I'm at least curious if the tech is reaching the point where one might expect a more normal user to casually expect them to last 2+ years with normal use.

You know, everyone's focused on the math and the human drama aspects, but to me the real story should be about this accusation that they somehow read the stream of data these guys were generating and then reacted to it at all on a human level is pure poison for their hopes for enterprises to be using their software.

Even if these two mathematicians were using the AI services under a clause that nominally allows OpenAI to train on their data, it is still another level above for there to exist some pathway within OpenAI to know that someone is doing something very valuable and important with their AI and to swoop in to try to steal the value of that work. It doesn't matter exactly what that pathway is, just that it exists is a big deal. Today it's a Millennium Prize, but tomorrow, is it the next hot new product category? Is it the patent someone is working on? Does OpenAI constitutionally believe that you may be using their product but whatever you produce really belongs to them and you are just borrowing it? Can we trust contracts that promise that they don't believe that if this is how they act?

Even people who are consciously aware that their sessions are being used to train the AI don't expect the AI companies to be in some way scanning the stream of what AI is working on for high-value propositions to snipe. That changes the relationship between these companies and enterprises, and anyone who thinks they may be doing this sort of work, deeply and fundamentally.

It isn't just that OpenAI is now something we should be suspicious about for math. It's all high-value science. Is there anyone trying to figure out how to develop a next-generation AI architecture using OpenAI? Better stop, OpenAI could see it and scoop you out of who knows how much value.

There is an old story attached to many historical figures that goes:

    Churchill: Madam, would you sleep with me for a million pounds?

    Woman: My goodness… well, I suppose I would.

    Churchill: Would you sleep with me for a pound?

    Woman: Certainly not! What kind of woman do you think I am?

    Churchill: Madam, we’ve already established that. Now we are 
    just haggling over the price.

If this accusation is true, which I'm not completely confident about, but if it is true, that is the situation we would be in... we would have established that OpenAI is willing to steal from its customers, the only question is where the line is now, and where the line might be in the future.

Honestly the human drama, while the compelling story, is in monetary terms orders of magnitude less important than the question of whether OpenAI has a mechanism to steal ideas from its customers. Has this happened before and they just successfully covered it up? Or maybe the people stolen from thought it was innocent and just a coincidence that they were scooped? If it established that there is a price, I have a lot of questions about that price.

There's also the fact that you are in control. You are not obligated to take the AI's commits. I don't even let it commit much of the time because commit time is review time for me. If it changes the button blue and does four other things, you can just take the blue change and discard the rest. It can't stop you.

This isn't a defense of it doing those four other things. It would be nice if it did what you wanted correctly. I'm just saying, as long as our programming skills have not completely atrophied, we have the power.

“Ford carried on counting quietly. This is about the most aggressive thing you can do to a computer, the equivalent of going up to a human being and saying "Blood...blood...blood...blood...” ― Douglas Adams, The Hitchhiker's Guide to the Galaxy

This is the key to the problem that I think people are missing, possibly because they kind of want to miss it. Google and the other companies hiding behind LLMs and primarily doing it because they can't operate at the scale they do, with the dedicated ecosystems to gaming them that they develop, without this hiding. They can't afford humans to review in a minute or two what scammers can generate in fractions of a second, not even at their scale.

Now, I'm enough of a fan of decentralization and the destruction of these massive sites with way too much control to say that I'm perfectly comfortable saying that they should be mandated to handle these things more sensibly and with more humans. That such a plan would have the side effect of breaking them up into vastly, vastly smaller pieces, causing an technological Cambrian explosion of various sites and diversity resulting in the parasites no longer being able to focus all their firepower on a very small set of targets, is for me a bonus, if not the main goal. However, I, and anyone who agrees with me on this, is rather clearly in the minority.

In the meantime, if we're going to have things the size of Google or Facebook, there simply is no solution where we all get human review whenever we ask for it, because instantly every spammer and abuser will ask for the human review. There just isn't a solution. It looks like there is an obvious solution when you consider "how will Google review this one application" but that's not the landscape Google faces. They have to solve the problem of how to deal with the entire landscape of requests they face at once.

As I said to another comment, this isn't a place for architecture astronautics or squinting until one thing looks like another. It's all assembler under the hood in the end and that language not only doesn't have color, it doesn't have types in any practical sense of the term. At the level of Haskell itself, IO is a color and IO is not a function argument. The compiled code is all assembler. The Haskell may itself be an interpreter for a language that has no color. Above it there is no color, below it it may be implementing something without colors, but at the level of Haskell itself, IO is a color.

I cited the case of an argument color already in the text for Zig... in fact, that's conditionally a color depending on what is passed, which is even more sophisticated then an argument merely being unconditionally a color.

What some people want to do is call every argument a "color", that is, I changed this function to have to take a Username and now it's Username-colored is the claim. I supposed I should have made that more clear. This provides a definition where that is not the case.

Your configuration structs are not "everything". You probably have dozens of things in them. You have hundreds to thousands of different parameters to different functions. By the time your configuration structs have hundreds of things in them you have thousands to tens of thousands of parameters to functions. Only a fairly small fraction of things make it all the way up to main.

This is exactly what I was talking about with this being a "cognitively available" operation. You notice when you have to propagate something all the way up to the top precisely because it is not something you do very often and it stands out as an exception when you do. If you are literally propagating everything up to main, all the time, every time you change any function anywhere in your program, you are doing something very, very wrong.

That has no propagation up the stack at all. Whether a child function does or does not use channels has no effect on the parent.

I think this is a case where you want to avoid architecture astronautics and deal with languages as they are presented. Yes, in the end it's all continuation passing, or depending on the cut of your jib, it's all just assembler in the end, but meanwhile, down in the trenches, there are real, practical differences in color that change how you program in those languages, and that's the topic color addresses.

I don't think there's a way to color functions in Go. That's not terribly special, several languages have no colors in them.