One of the reasons we don’t use PostScript so much any more.

Yeah, I certainly wouldn't trust it to run any distance unattended, and I started this project with strong ideas about the parameters of the design, so I know what I want and what won't fly. But as you say, it can help tease out unexpected pros and cons of certain choices along the way.

> In summary: obviate experts, receive correct guidance, save time —- pick any two.

It's simpler than that: it can't do the first, nor reliably the second, but it has saved me time.

In 10m Gemini correctly diagnosed and then fixed a bug in a fairly subtle body of code that I was expecting to have to spend a couple hours working on.

I spent much of the past week using Gemini to build a prototype of a clean new (green field) system involving RPCs, static analysis, and sandboxing. I give it very specific instructions, usually after rounds of critical design discussions, and it generates structurally correct code that passes essentially valid tests. Error handling is a notable weakness. I review the code by hand after each step and often make changes, and I expect to go over the over the whole thing very carefully at the end, but it has saved me many hours this week.

Perhaps more valuable than the code has been the critical design conversation, in which it mostly is fluent at the level of an experienced engineer and has been able explain, defend, and justify design choices quite coherently. This saved time I would otherwise have spent debating with coworkers. But it’s not always right and it is easily led astray (and will lead astray), so you need a clear idea in mind, a firm hand, and good judgment.

- “The Pledge”:…

- “The Turn”:…

- “The Prestige”:…

(For this particular example I used real terms from the stage magic world, at least according to Christopher Nolan’s film, as it captures the same meaningless-to-the-uninitiated quality.)

Nowadays we tend to write in a plainer style demanding a smaller “parser stack”. Some style manuals have excellent examples of sentences of equal length but very different “stack depth” and thus ease of comprehension.

People have been fantasizing about this scenario throughout the industrial era--read William Morris' News from Nowhere (1890) for example--but it has failed to come to pass so many times, and the reasons are pretty obvious. The benefits of technology are spread unequally, and increasingly so over time, so only a wealthy few get the option of a post-labor existence. Also, our demands for the products of labor change as labor productivity increases; we prefer (or have been persuaded to act as if we prefer) material riches over lives with less stuff and more time.

We still haven't seen that AI actually replaces labor, as opposed to amplifying it, like a power saw or CNC mill used by a carpenter, so all these discussions about the end of labor seem like unwitting sales pitches for AI.

> “what would be the role of humans in an AI-first society”

The real question is why would anyone want, or want to help build, such an obscenity.

Even with only about 1 in 1000 users enabling telemetry, it has been an invaluable source of information about crashes. In most cases it is easy to reconstruct a test case that reproduces the problem, and the bug is fixed within an hour. We have fixed dozens of bugs this way. When the cause is not obvious, we "refine" the crash by adding if-statements and assertions so that after the next release we gain one additional bit of information from the stack trace about the state of execution.

However there was always a stubborn tail of field reports that couldn't be explained: corrupt stack pointers, corrupt g registers (the thread-local pointer to the current goroutine), or panics dereferencing a pointer that had just passed a nil check. All of these point to memory corruption.

In theory anything is possible if you abuse unsafe or have a data race, but I audited every use of unsafe in the executable and am convinced they are safe. Proving the absence of data races is harder, but nonetheless races usually exhibit some kind of locality in what variable gets clobbered, and that wasn't the case here.

In some cases we have even seen crashes in non-memory instructions (e.g. MOV ZR, R1), which implicates misexecution: a fault in the CPU (or a bug in the telemetry bookkeeping, I suppose).

As a programmer I've been burned too many times by prematurely blaming the compiler or runtime for mistakes in one's own code, so it took a long time to gain the confidence to suspect the foundations in this case. But I recently did some napkin math (see https://github.com/golang/go/issues/71425#issuecomment-39685...) and came to the conclusion that the surprising number of inexplicable field reports--about 10/week among our users--is well within the realm of faulty hardware, especially since our users are overwhelmingly using laptops, which don't have parity memory.

I would love to get definitive confirmation though. I wonder what test the Firefox team runs on memory in their crash reporting software.

Second smallest, after monatomic Helium molecules (which have similar problems of storage, embrittlement, and leakage).