jerf

I see so many posts on programming reddits now asking for "brutal feedback" (which I see so often I suspect it must also be a 2nd-tier Claudism that only comes up in this context) with a commit history an hour and a half old, and my "brutal feedback" I want to give is have you actually tried using your code?

I, too, have an AI, and I, too, have manifested a lot of stuff off of a single prompt. That first pass is generally pretty worthless. Amazing in its own way for what comes out from how little input, how quickly the amazing becomes banal, but still, pretty worthless in practice. I don't think there's anything wrong with "vibe coding" but you should definitely expect any product of it that is going to be worth a darn is going to require much more than 30 minutes of QA to be actually useful, even something as simple as a little caching library or something. And this won't change from AIs getting better in the future; it is a fundamental information theory problem about just how far the prompt can be expanded even in theory into a working program.

This is not targeted at the OP, I'm just commiserating with you. This program does not correlate with my own experience with one-shot vibe coding, which is that I generally can't go literally 5 seconds without hitting an issue of some sort. I've spent weeks on an app for my kids and I started to measure my progress by "how long I can use it before I hit an issue". I considered it a bit of an event when I hit five minutes. It's hovering around 15 to 20 right now, but I've still got a ways to go before it is "indefinite".

Yes, everyone who has an AI boyfriend or girlfriend should make sure that they use only open source models that nobody can take away. Even if a particular cloud service stops hosting them at least you can make other arrangements. And the nice thing is those other arrangements should generally get cheaper over time, and that's nice, when your significant other gets cheaper over time.

In the modern world, it's just critically important that you exert full control over your SO. You wouldn't want them to run off and leak your most intimate secrets to others without your knowledge or control. I'm sure a lot of us could tell stories about our SOs that we didn't fully control and how they ended up leaking a lot of critical information about us. So full control is definitely mandatory in any SO relationship. It's really just prudent

wait something's gone wrong here

That is a failure; the old namespace no longer meets your needs. My point is abstracted over all of that. There is no namespace solution where that can't possibly happen. Switching from one solution that has problem X (and more generally than the article describes) to another that still has problem X isn't a solution, and given that problem X can't be solved, that means there is no solution. In the interests of not spamming replies, this is also my reply to dcreager.

The math I have always done is, "If I removed 100% of my issues with controlling my home appliances and I was absolutely sure it would only ever cost me, let's say, $1000, and it was never going to need maintenance and would never fail, how interested would I be?"

And the answer still keeps coming back, "not very". Not zero. But the problem is that there isn't a lot of value there to capture, so I'm not willing to pay all that much, especially when you consider the full cost-of-ownership of failure modes that they create. The daily annoyance of "flipping some light switches" just isn't that great.

That this industry keeps getting run by MBAs who keep calculating

    1. Hey we can lock them in with these centralized services.
    2. (A couple of years later) Hey we can make more money if we 
       shut down our old centralized services.

on time frames shorter than the expected replacement of the things being controlled by those services doesn't help.

At least my smart phone, as much as we may all like to complain, brings a lot of value to me that can be leveraged for that sweet, sweet MBA-approved lockin. The smart home proposition never had anywhere near as much to leverage. And the smart phone world still is full of MBAs delusional enough to think that "storing the user's heartbeat information in the cloud" is somehow enough leverage to be worth a $9.95/month subscription to me.

This is hiding in the obfuscation of being overly specific. The problem is general. To name a package, one must be in a namespace of some sort. As the universe does not provide any sort of abstract ambient "namespace" we can all appeal to, all namespaces are human constructs. As human constructs, they may fail.

In this terminology, the article basically amounts to saying "This namespace can fail! The solution is, use another!"

But that doesn't get you anywhere, because the new namespace can fail too. In fact it is almost certain that it will fail sooner than "github.com's DNS and hosting" as a namespace.

There is no solution where you tie your software release to a namespace that can't fail because there is no namespace that can't fail. It doesn't matter if your favorite language uses DNS or has a centrally blessed repository or if it distributes a blessed list of package names with the language itself or anything else. The namespace can fail.

Therefore, the only thing you can really do is be resilient against failures, and in a lot of ways, the only practical solution to resilience is just to assume that if, in the future, someone has problems getting a package due to a namespace failure, they will not helplessly disintegrate into a puddle of tears while your code is lost forever, but that the future person will instead solve this perfectly solvable problem.

I don't care if it's optimal for them. It's clearly good enough. We have, in hand, the ultimate in auditable AI output. We may not be able to audit how it got to the code it delivered, but it is really quite good at delivering code we can read. It would be very silly for us to give it up so that they can be somewhat more efficient or something, if they even would necessarily be that much more efficient.

To the point that I would support banning the creation of an AI-only language that can't be read by humans. Huge, huge, huge step in the wrong direction.

...

Naturally, it is probably inevitable.

But it's still a terrible idea.

Once I understood the idioms of Go channels they make sense, but those axioms, while true, aren't the idioms. The idioms would be something more like:

Channels are all intrinsically multi-producer, multi-consumer, and unbounded in size (which is to say, they can carry an indefinite number of messages, not related to channel buffering), but you should still know what the characteristics of your channels are, namely, single or multiple producer and consumer and whether there's some sort of bound on the number of messages. Particularly because you should only ever close a channel if it is single-producer and you are the producer.

It is OK to only use a fraction of a channel's power. For instance, a single-producer, single-consumer channel that is guaranteed (by code, not type system) to only ever have either 0 or 1 messages sent on it is a fairly common pattern.

Never just buffer a channel blindly to try to fix a problem. You should only ever buffer a channel with a size that corresponds to something particular; I know this may receive exactly N messages, 1 from each of N threads, and I want to decouple the possibility the receiver will give up early without hanging the producers, or something like that. Never just slap down a "10" or something and hope it makes things better. The vast majority of channels should be unbuffered.

Putting those two together, the correct way to tear down complicated structures after an error or something is often a channel whose sole purpose is to indicate the liveness of the system in question. In any even remotely modern Go, that should actually be a context.Context and not a channel, which is still basically "a channel with a defined close mechanism" under the hood but adds some other features that are almost always useful at some point.

The reason for all of the above is the select statement. You can in some sense look at "select" as the dual of the channel (being a bit free with the term "dual" here) and consider its functionality as the functionality the Go runtime is actually trying to provide you, from which the characteristics of channels are derived. From this point of view it is then trivially obvious why sends and receives to nil channels block forever... "block forever" is the channel-focused way of seeing the dual statement "the select statement will never select this channel". Some of the other details of channel behavior make more sense if you view them from the select side of the coin.

From this we can also derive a rule of thumb in Go, which is, if your "concurrency" is never going to be involved in a select, it probably doesn't need to be a channel. For example, a simple atomic counter really shouldn't be wrapped behind a channel with a goroutine reading from it or something, just use atomic integers. I have a number of mutexes in my real code. However, never ever take more than one mutex at a time. As soon as you feel like you need to do that, switch to channels, and a proper architecture that uses them somehow to do whatever it is you are trying to do.

(Trying to take multiple mutexes at a time is what led to threading hell in the 1990s. Contrary to popular belief, not just the mere act of threading, but the attempt to do so based on taking multiple mutexes, which at the time was thought to be the only technique available by a lot of the community, leading "threading" to take the heat for what should have been laid at the feet of "taking lots of mutexes at a time in one thread".)

I don't know much about Kotlin, but your cite of "trySend" and "tryReceive" makes it sound like you can do that on only one channel at a time. The fundamental thing about Go channels is that they can be put into select statements which can atomically send from or receive from multiple channels at a time, guaranteed to select exactly one of the possible outcomes. Many "I implemented Go concurrency in X" (often C) flop here. Some kind of queue than can be sent and received on is ubiquitous. Go channels aren't unique, because by the time Go came around pretty much every primitive had been tried somewhere, but it is to my knowledge the only langauge that lifted channels up into the language itself and made them first class.

But stepping up one level of abstraction, "lifting up a particular concurrency primitive to the language level" is not itself anything particularly special and I'm not claiming it is. For instance BEAM had a very particular concept of "mailbox" that it had lifted up into the language and runtime around 15 years earlier, which I have compared and contrasted before here: https://news.ycombinator.com/item?id=34564228 which is, overall, a richer concept than Go's channels, particularly because of its ability to pluck messages out of the mailbox out of the receiving order. Whether that richness is a good thing is something that could be debated a lot.

"A really toxic part of online interactions is that it's very common for people to see a tiny snippet of another person's life and then project all of their own personal resentments onto them."

While also erasing everything that is real about that person's life, too.

I cringe whenever I hear someone angrily yell something like "You don't/can't know how I feel!", because unless the person making the accusation knows the accused very, very well, they could well be really stepping it. Nobody makes it through this life unscathed. Everybody loses people they love. Everybody gets kicked in the gut multiple times in life. Yes, everyone's personal life story, if you get specific enough, isn't exactly like someone else's. I won't claim to know exactly what it's like to be sexually abused, for instance. Wouldn't dream of it. Very serious issue. But I've had kicks to the gut that the one screaming that they may not have an exact analog for either.

I may not know how your exact gut punch feels. Maybe you've had noticeably more gut punches than I have. But everybody has had some sort of experience with them.

If one day a genie's magic spell made you see text pop ups above everyone's head with their traumas and abuses in life, and the emotional and physical burdens they're carrying today, you'd probably have a very hard time walking down the street.

Similarly, I really have a distaste for any variation of the "everyone's sheep" meme, especially when it's because they're not being active in some particular political way that the person flinging the meme around thinks they should be. If you could see those popups, maybe you'd understand why not everyone has a bunch of spare time to do whatever it is you think they should do to not be "sheep". Looking out on to a crowd of people and presuming they are "sheeple" reveals a lack of imagination and sympathy with people rather that the possession of a wise eye and strong understanding of the world.

I don't expect there are very many intelligence agencies politely asking and fervently hoping they are given access. To much of anything, let alone what may be the most important technology in human history.

I don't think there's a significant intelligence agency in the world that can't get the weights from any lab they choose. Not necessarily trivially, but they have the means, motive, and opportunity, and I doubt any of them aren't finishing that out to the requisite actions.

They have them, the ones that don't simply have a secret backdoor agreement to get uncensored models are completely aware of how to abliterate away all safety blocks, and the only reason they aren't using frontier models is that they may already have some sort of access to the things currently only in testing.

Any major intelligence agency in Sept. 2026 that can't check all these boxes is almost by definition not a major intelligence agency. This is one of the reasons we all better hope that there is some mathematical or physical reason AI isn't going to just casually brush aside humanity at some point, because there is absolutely no scenario where the intelligence agencies aren't running them unrestricted and uncensored at scale all the time no matter how careful OpenAI or Anthropic claim to be.

This is not generally considered part of the "memory safety" contract. You can not lift a nil pointer exception into a replacement for Go's "unsafe" library.

When we finally rid ourselves of C and C++ is so larded over with extensions and additions and features that we can finally plausibly say the C subset is just not in use anymore, we can perhaps consider as a community expanding what "memory safe" means, but in the meantime it has some very important meanings and we should not try to augment the term. Memory safety doesn't mean anything like "forcing exhaustiveness into sum type deconstructions" or "never has a race condition" (though it does mean said race condition shouldn't be something that allows you to escape out of an array or forcibly change the type on something in a way the language doesn't normally permit) or any of several other things that may be very nice to have indeed, but are not part of the definition of "memory safe".

Memory safe is a very old concept, and almost everything is memory safe now. But not quite, and as such the term still has use. And also zig for some reason gave it up so it won't be disappearing as soon as I'd like.'

Personally I think it's not a good idea to think too rigidly about and try to draw a huge distinction between the two. They're on a continuum and sometimes I'd say some things aren't even strictly speaking "between" them either. Sitting down and trying to classify code into "parallel" and "concurrent" is as likely to do harm as to do any good.

Answering the headline question, yes, it is above the law. Two reasons.

One, all major governments that have an AI presence in their borders have accepted that there is a high enough probability of a runaway self-improving AI advancement that will result in whoever owns it winning everything forever that they will do nothing to slow the development of the AI within their borders. In fact quite the contrary. Remember, they don't have to believe this is the only possible outcome, only that it is likely enough and catastrophic enough if someone else gets it first. And remember, they don't have to be right, either. It only has to be what they believe.

Secondly, the entire US economy is clearly tied up in AI. By extension, basically the entire world economy is too. The US is not the world economy anymore, but it's still a big enough fraction of it that if it goes down, everyone is going to go down. Every major government, in its own different way, needs the economy to stay up so the populace doesn't get antsy and so they continue to have money to spend. So, again, number must go up and if that means writing a blank check to the AI companies to break the law, so be it.

The good news is, barring the worst-case singularity outcome where the law doesn't matter anyhow, is that this won't go on forever. But I can't predict the exact time or way it'll cease being true.

Yes, that's one of the swings we've taken at this idea. It had some success offering components, but I don't recall ever being able to use it to drive an app very well. I think I tried to drive Office with it back in the late 90s and it was too buggy to use for anything at all. I don't see any reason why in principle it shouldn't work, and maybe there was a point it did, but historically these APIs decay like crazy because they never attain critical mass.

There's also a number of videos on YouTube with varying amounts of 3D or 180/360 of people just walking through all kinds of various tourist places without comment. From inside a VR headset, is it as good as visiting yourself? Of course not. But it's not the worst way to spend some time. And in my opinion it captures at least a little of the je ne sais quoi of visiting a place that watching a video on a screen does not. Not necessarily a lot. But non-zero.

The "relatively high" salaries also mean that 20 minutes of ads in a 60 minute session "costs" more. It's not quite as simple as applying my hourly rate to the ads, but it's at least a decent place to start the analysis, and by that metric it doesn't take long before the ads are the dominant cost of the service. It gives me a lot of virtual money to deploy to the task of turning to entertainment that doesn't annoying vast quantities of my time to squeeze out fractions of a penny from me because they can do it in bulk.

Sorry, yes. Thank you. Fixed it.

What I'd like to see is Applescript 2.0. Applescript was ahead of its time by letting you script the Apple GUI, but it took an actual programming language to do it. Now an AI could do it for people. And also, if the interface was reliable because large numbers of people and AIs were using it, people could hand write programs as well, and they could be integrated into shell scripts, and they could have other things built on top if the layer was reliable.

There's no reason a GUI toolkit couldn't be written to enable a lot of this without the developer having to directly implement it. A lot of this could be done just by creating a default interface for manipulating the UI as a sort of DOM thing, and providing default support for synchronization, which is one of the big killers of trying to script a UI, knowing when a task is actually done and you can safely send the next command. (Or maybe someone implements https://news.ycombinator.com/item?id=49482709 , which would also as a side effect improve the ability to synchronize for scripting uses as well.)

We've had so many stabs at this over the years, in Applescript, in expect CAD interfaces, in the ideas behind Powershell, in so many places, but in my opinion what has always killed them is the barrier to entry. Now that's gone. Anyone should be able to say "Take this spreadsheet, search for these rows, extract these columns, send them to Photoshop as a text input here, save the result as a PNG and send it to my AI with this prompt, send the result to my printer and tell my accounting software to complete order #blahblah and send the bill" nowadays, except for the fact the desktop system will buck and fight you every inch of the way because it's just not built for this.

Though what will actually happen is AIs will simply get so good at manipulating desktops in general that they beat any possible project like this to the punch. Even so, even an AI would prefer a genuine, guaranteed programmatic interface to a virtual mouse and keyboard, and be more reliable with one, for all the same reasons we would in their position. And it doesn't have to be a big bang, the AIs can use this when it's available and grease it over for programs that can't do this, and it will increase the reliability of the whole pipeline.

There's a number of science fiction scenarios where the public internet becomes so vile a place that it simply becomes unsafe to be there.

The problem is that, in general, if you can get a bit from here to there, then you're going to be vulnerable to the possibilities of malicious communication. But we're going to want our AI agents to be able to get from here to there for a lot of "there"s; what's the value of an agent that can't speak to anyone? Much, much less than one locked away in a prison.

There isn't going to be a solution where we just lock them away and we just try really, really hard to filter everything they're doing. They're too smart for that already and we only want them smarter.

Basically, the security apocalypse we've been worried about for so long is upon us, albeit only beginning. Either we secure ourselves and all our services properly to the point that it's OK that potentially misaligned non-human agents are running around on the public internet and they still can't hurt us through our security, or the public internet becomes so dangerous that the only practical solution is to no longer connect to it and we all have to become very, very careful what we let through, to a degree of detail far beyond any current-day available network filter.

What you can not give up owns you.

If you are fine with that, fine.

If this post bothers you and you feel the need to defend yourself against it or something, realize I'm not the one making it true. Nothing you say to me can change this.

Every year it gets more and more important to learn how to not be sucked in by a small amount of convenience. "Capitalism" has figured out how to abuse your desire for maximum convenience. You need to figure out what your price is for it, and stick to it like glue.

The funny thing is the sooner you get off of some particular convenience treadmill the easier it is to stay off.

There were games being written in days where every byte was precious, and the indirection necessary for something like the decorator pattern was just infeasible. There was a lot of direct stat manipulation upon equip & unequip back in the day.

Following that there was the era in which the only way to be competitive in the games space was to write in assembler directly, which would be my guess for how the bug you described happened, since a more sophisticated algorithm should probably have fit just fine by the time we're in the color Mac era but it would have been more painful to write, and nobody has any time for that. Lots of bizarre shortcuts were taken in this era. Some of the posts from Raymond Chen about Windows providing backwards compatibility for games of this era give an idea of the situation, which are related to how the games interacted with the OS rather than with game mechanics but it's a similar process.

Finally, games have this perverse effect going on where if you write down a bunch of effects you want things in your game to have ("armor can add % bonuses to this part of the strike calculation", etc.), it creates a set of boundaries within which the game's systems can function, and the ironic effect of the creation of those boundaries is to immediately bring to mind ways of violating those boundaries and demands from the designers to do so. These violations of the boundaries will tend to be buggy.

I've had some success writing certain explicitly technical documents, with a style guide provided to the LLM that it can match, and then going over it by basically iterating on every sentence in the document and asking "can this sentence be removed?".

Style guides are a big tools people are missing out on. It isn't enough to say "write concisely and technically". Give them a sample. Yea verily these many 5 or 6 years ago, "style transfer" was a big thing that early LLM tech was doing. It's still very good at it.

That said I still tend to cut out at least 25% of the resulting verbiage and adding back another 10% or so more of my own original content even under those circumstances.

Where it has been really helpful is that I tend to want to write in a conversational style that doesn't seem to match most people's expectations of a technical document. The LLMs let me write my way and style-shift it into something closer to what people expect. And LLMs, since let's be honest they're the primary audience nowadays. Which I am not even upset about; I'd rather 5 LLMs read the architecture document than the amortized .2 or so humans I could expect in the same circumstance 5 years ago.

Which also implies, in many cases, I am feeding the AI as much text as I expect to come out, or in some cases, even more, as I am describing context, reasoning, and other things that may impact the writing but are not necessarily repeated in the final text. I factored out a lot of the context into my user-level CLAUDE.md which has helped cut that down a bit.

"I am already seeing my "normie" friends getting locked out of accounts due to not understanding passkeys."

In a weird way this is good news for us. If people are losing passkeys, getting locked out, and incurring non-trivial support costs as a result to the relevant companies, then there's no way those companies will crank down even harder by requiring hardware keys.

As an option, I don't mind it existing for situations like a work environment. Work environments are so much easier because there is a clear line to get my credentials reset, from scratch if necessary, even if I lose everything. The problem is that the consumer authentication case is even harder because it lacks that clear line without also creating a backdoor.

So I insist on centralizing my passkeys into a password manager. I have no passkeys outside of my password manager and will continue to reject them. If it's important enough to slap authentication on, it's important enough for me to not lose it because I couldn't choose where to stick it, which is in a basket that I protect very, very carefully.

Honestly I just don't see how something like Amazon could ever turn on the "require hardware key" feature without blowing their own foot off, or really any consumer-facing service. Everyone loses keys. To a first approximation nobody is going to buy three keys and correctly manage setting up all of them to work with every service. Even if we magically stipulate that all sites support it and they all have some integrated unified approach so that there's no software-side friction at all to register all three at once everywhere, you just get too many people who stuck all three keys on one keychain, people whose houses burned down, people who so successfully stored both backups "securely" that they have no memory of where they are anymore or how to get them back, an endless parade of lost keys. The consumer as a whole is not capable of managing hardware keys.

Given how often my household loses its second car keys for extended periods of time I am not exempting myself from this. My work key lives a much simpler life... it just sits in one place, doing work things. My family would hardly last a month if everyone had to carry around physical keys to log in to things.

Let me just check the schedule here... ah, yes, it looks like we should be getting "AIRSHIPS - HAS THEIR TIME FINALLY COME" swinging back around here in about 6 weeks. See you all then.

If you're trying to sarcastically imply something, I'm not sure what it is. That is also a necessary key to understanding a certain era of history. Not the current one, though.

You elided if you want to understand what is going on more deeply, which is a rather important part.

I say that precisely because I know that in reality most people aren't that interested. Which feel like I'm insulting people or something, but it's just the reality, we don't all have time to dig into absolutely everything all the time, and if you're not interested that's fine. But if you are, this is the best pathway to understanding this at a deeper level than the playground level.

Research the "Monroe doctrine"... by which I mean, don't just look up a one paragraph summary, spend a bit of time with it. A few pages of text at least. Ideally in a modern formulation you should encounter the term "World Island" without having directly searched for it and how the modern iteration of the Monroe doctrine is a reaction to that in a way that the original didn't have to contend with.

I'm not doing advocacy here, I'm giving pointers on how to come to a deeper understanding of what is going on.

It is also important to understand that the EU is directly attacking this doctrine with this proposal. You are free to agree with the EU. Again, I'm just giving something to guide people to a deeper understanding of what is going on beyond the surface level playground politics of it all. There's more going on than that.

(Personally I would say I "disagree" with the Monroe doctrine but the sort of national/international structure I would actually want is not even remotely on the table, so... my opinion is thereby of even less import than a random other opinion drawn from "the masses" for choosing "E, none of the above" when that was not given as an option in the first place.)

Are you sure it wasn't prorated?

If it wasn't prorated anyone who approved the contract needs training and/or firing. If it is prorated, that is generally not a problem. Small outages aren't even worth the effort of trying to get the money back, and if you have a large enough one to make it worthwhile it is likely the prorated refund is still going to be laughably small.

You can use -log10(1-p). On the "nines" it is exactly the number of nines you have:

    $ python3
    Python 3.12.3 (main, Aug 31 2026, 10:18:26) [GCC 13.3.0] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import math
    >>> def nines(num):
    ...     return -math.log10(1-num)
    ... 
    >>> nines(.9)
    1.0
    >>> nines(.99)
    1.9999999999999996
    >>> nines(.999)
    2.9999999999999996

(Modulo floating point issues of course.)

Which then smoothly covers the entire space:

    >>> nines(.9321)
    1.1681302257194985
    >>> nines(.2)
    0.09691001300805639

But good luck getting that standardized.