rstuart4133

That link reads like an autobiography about his love affair with Rust and subsequent breaking up after pushing the relationship a step too far: into gaming. He has been using Rust much, much longer than me, but I rekcon I already hit most of the pain points he mentions. (And I notice he left some things out, like async.)

I've come away feeling that most it looks fixable - but it won't be fixed in Rust. Some of the language choices (like favouring monomorphization to the point of making dll's near impossible) are near impossible to undo now, and in other cases where it might conceivably be fixed (like async) it won't be because the community is too invested with their current solution.

So we are stuck with the Rust we have; warts and all. That blog post convinced me those warts mean the language should be avoided for game development. Similarly sqlite developers convinced me the current state of Rust tooling meant it wasn't a good fit for their style of high reliability coding, so they are sticking with C. Which is a downright perverse outcome.

But for most of us C programmers who aren't willing to put in the huge effort Sqlite does to get the reliability up, Rust is the only game in town right now. It's the first and currently only language to implement a usable formal proof checker that eliminates most of the serious footguns in C and C++. But I am now hoping it becomes a victim of the old engineering adage: plan to throw the first one away, because you will anyway.

WWE has been a successful business model for a long time now, and shows no signs of dying out.

I haven't listened to those podcasts, but from Kate's description the recipe is the same as WWE. They appeal to the senses using only bullshit. The outcome is preordained, they are selling the hype only, the reality doesn't matter.

There is clearly customer base for this sort of thing that isn't going away. Amazingly it appeals to all age groups: https://drive.google.com/file/d/1jN2Jxp_o4OtLZl4HuK2jWAtmUyy...

It works so well the USA has president who sold himself to the voters using this very same model.

From this video's synopsis:

> Boris Cherny, creator of Claude Code at Anthropic, joins Sequoia partner Lauren Reeder at AI Ascent 2026 to talk about where coding goes from here. He explains why he hasn't written a line of code in 2026, why he now ships dozens of PRs a day from his phone, and why he believes coding is effectively solved — at least for the code he writes.

That explains a lot. I gave up on Claude Code. It's too buggy for me. I could put up with it making a mess when drawing the screen, but often basic commands like /status don't work, and occasionally it looses track of what it's doing so badly you lose the work done in a 5 how window.

Claude Code's major contribution to the profession is as an example of what happens to a product if it is vibe coded for too long without going through tight review by a human.

He made a lot of assertions beyond the one in the headline: "Tests force better structured code" and "Mutation testing makes the LLM produce code with fewer bugs" are two examples. Most sounded plausible. But the delivery style of a monologue of rapid fire assertions made the entire thing very hard to accept.

A little bit of hard evidence would be nice. In fact it would be more than nice. Firm anchors in the form of published results of real experiments on how you can make LLMs produce different styles of code would be golden right now. I'm sure I'm not the only one flailing around looking for good ways to use these newfangled tools.

> For a calculator, I can only hold myself accountable. However I cannot hold myself accountable for not knowing something I dont know.

I thought I could let this fly through keeper, but the idea keeps bugging me.

If the programmer does not vet and understand what the LLM has done, we call it vibe coding. If he takes personal responsibility for every line of code, we call it software engineering.

Lots of people use LLMs to vibe code (I do), and lots of people use them as a software engineering aid (I do that too).

The choice depends on the quality of code you need to produce. If an engineer is designing an aircraft wing, he would choose the highest grade of materials with known parameters. If he is building a kite for his son, an old newspaper would do in a pinch. Using 7075 Aluminium wouldn't just be overkill, it would mean his son doesn't get to see the fun his dad has building a flying machine in an afternoon.

A good engineer understands the properties of every tool at his disposal, and knows when to deploy each.

Others are disagreeing with you here, and I do too.

The difference is profound, and takes more than a couple of days to get your head around the implications. I'd summarise it as: "if you give a computer the same input it always produces the same output, but if you give a model the same input it always produces different output". Add to that the output is often wrong and it can't reliably follow instructions, and the difference is so great it breaks most of your intuitions.

The reward working with this piece of unreliable jelly is it can be far smarter than you (think the difference between a man with a shovel and a 20 ton excavator - they can literally find bugs in minutes that would take a human hours or days), and they know far more than you.

The engineering challenge is to make this near random machine produce a reliable product. It isn't easy.

The hype you see around them is it's trivially easy to get it to produce a feature rich but very unreliable product, as Anthropic demonstrates with their vibe coded claude-cli. I refuse to use it now. Among its other charms, it triggers a BSOD on windows: https://github.com/anthropics/claude-code/issues/30137 (Granted, it's just another Windows bug: https://learn.microsoft.com/en-ca/answers/questions/5814272/..., but if you are shipping to Windows you should be working around such bugs.)

> SF has always been a wretched hive of ads and dark patterns.

No, as others have said it wasn't always that way. And more importantly it's not that way now. But yes, for a while there it was the epitome of enshittication. How that worked out is kinda hopeful in a way: it went broke, was bought out, and went back to being something usable again. In fact they added a lot of enhancements.

I know because I was one of the ones that went back to it. I didn't like having git being forced down my throat, and sourceforge was one of the few left that supports a whole pile of VCSs. I made my Makefiles [0] support it so I didn't need to deal with the UI, and ended up very happy.

Everyone wondered why I wasn't on github, and queried my sanity at the time. But I say not liking the git cli is perfectly sane. Now jj has come along that excuse has gone, but it was a good one at the time. "github sucks" has conveniently come along as a reason to stay on sourceforge.

Seriously, if you are considering ditching github, take a look at sourceforge. The current owners BizX deserve some reward for the time they've put into it, and their patience.

[0] https://sourceforge.net/p/http-proxy-tunnel/code/ci/default/...

> Most (if not all) of these issues do not matter at all outside the scope GNU utils run in.

I suspect that attitude is how we got ourselves into this mess.

You have to assume you ultimately don't control what scope your software runs in. Obviously you do, 99.999% of the time. The other 0.0001% is when someone has found another vulnerability that lets them run your program with elevated privileges in an environment you didn't expect, and then they can use it to exploit one of these bugs. Almost all exploits use a chain of vulnerabilities each one seemingly mostly harmless - your "no one can ever exploit this weakness in my program because I control the environment" will be just one step in the chain.

That sounds far fetched. It is far fetched in the sense that it almost never happens. But nonetheless systems were and are exploited because of it. Once the solution was added in 2006 (openat() and friends), it should have never happened again. And indeed in the GNU utils it can't.

The people who build Rust's std::fs should have been aware of the problem and its solution because it was written in 2015. std::path was written at the same time, and that is where the change has to be made. It's not a big change either: std::path has to translate the path into a OS descriptor use that instead of the path - but only if it was available. I suspect the real issue was they had the same attitude as you, they thought it affects such a small percentage of programs it didn't really matter. That and it's a little bit of extra work.

It was a pity they had that attitude, because the extra work would have avoided this mess.

> No, it's because Elon understands the model of selling cars for humans to drive will be dead by the end of the next decade.

Yes, that's Elon's claim.

I own a Tesla with FSD (hardware V3, so despite Elon's promises it will never work). I would never hire it out as a taxi. The risk of malicious damage is too great. I would have to insure for it, wear not having the car available when it happens, and the emotional impact of people destroying "my stuff" for the thrill of it.

The future of taxi's is a more traditional model like Waymo.

> 1MW of 500W solar panels is 2000 panels, for example.

Or conservatively 100m x 100m of panels. About 1/5 of the roof area of a big-box store.

GLM-5.1 exists at 1/5 of the price of Opus (a Chinese open source model), and is almost as good as Opus. Organisations use Opus anyway, because it's only $200/mo. (To me GLM looks to be worse in some areas like finding bugs and making complex decisions, about the same in generating code that passes tests, and better at following instructions accurately over a long period.)

Anthropic is losing money. They need to raise that price to survive in the long term. But they can't because GLM-5.1 exists at 1/5 of the price. Not a lot of people use GLM-5.1, but they don't have to. It merely has to exist at the price it does to prevent Anthropic from becoming profitable.

I'm not sure how Z.ai pulled that off. I assume the price I see (about $4.40/M-token vs $25/M-token for Opus on openrouter.ai when I last looked) covers the margins of the inference providers, so the difference must lie in the R&D costs. The model originated at Tsinghua University, its continued development likely sustained by the Chinese model of state-backed venture capital and strategic subsidies. In effect, the public sector is paying for the R&D, allowing the commercial product to be priced at a level that private Western firms simply cannot match while seeking a profit.

You could imagine the plan always is to destroy the USA's capitalist model of R&D, if it wasn't for the fact that until a few years ago public funding of science to feed fresh ideas into capitalist enterprises (the "Vannevar Bush" model) was also used by the USA.

> I think generators should have been stabilised first - since all the problems you need to solve to make generators work well (self referential types, return values you can name, etc) are things futures need too.

Generators are an interesting case. For example, if you implemented a Vec iterator as a generator, it becomes:

    fn vec_iter(&self) {
       for index in 0..self.len() {
           yield &self[i];
       }
    }

Which is arguably easier to understand than the current event driven formulation, which required you to declare a new type to hold your state, and the code looks like:

    fn next(&self) {
       if (self.index >= self.vec.len()) {
            None
       } else {
            self.index += 1;
            &self.vec[self.index - 1]
       }
    }

Effectively the stack frame has become your type, and sequential code is always so much more compact and clearer than the event driven model. The generator could be implemented as a green thread, but you would never entertain the overhead of creating the new stack needed by the green thread implementation.

However ... the async implemented all the mechanics needed to get rid of that green thread stack allocation when the size of the stack is known, as it is in this case. The state saving stuff they created for async could be used to translate that stack to a type. It would, surprise, surprise, contain just `index` - analogous the iterator type we have to manually create for event drive code. So compiler could translate the green thread to the same implementation as the event driven code, but you get to use the compact (and very familiar) syntax of a stack machine.

I found it interesting to see what happens for a more complex generator - like something that returns every node in a tree. You can do it recursively, which is simple clear code, but you don't know the size of the stack so the trick used for the vec iterator (translating it to a type) can't be used. Or you can manually store the state you stored in the stack with a recursive implementation in a Vec<> instead. Both require a memory allocation, but they are different. One is just normal malloc that must be reallocated and moved as the allocation grows. The other can use the OS's stack implementation, that doesn't move as it grows. If you re-used stacks, the OS's stack implementation would be faster in a long running program.

Notice that the transformation from a generator to async implementation is arguably more complex than the same transformation for green threads, especially for the tree traversal.

That observation is one of the reasons I'm such a strong proponent of green threads. The other is a simpler mental model. Unlike async, you don't have to expose the inner mechanisms it depends on, like futures.

The key to understanding is green threads are semantically identical to async - just formulated a little differently. The code I gave left out a lot of details. This:

    while (char = read())
        process_the_character(char);

It may look more like this:

    element.onkeydown = window.greenThread(processKeyEvents, ...);

    ...

    function processKeyEvents(green_thread, ...) {
        while (event = green_thread.yield(...)) {
            /* process the key event */
            var foo = call_some_function_that_blocks(...);
            /* more processing */
        }
     }
  

You can only call a function that blocks (like `green_thread.yield()`) from within a green thread. Attempt it outside of a green thread and they throw an exception.

Code is effectively still coloured, because a call that can block can't be called from a context that doesn't allow block (like DOM events). async makes this colouring obvious but it comes at the expense of new keywords, new concepts like promises and futures, and manually creating the stack using linked object on the heap. A real stack is far faster than allocating stuff on the heap. But to repeat the key observation above: async and green threads are semantically near identical, it is only the implementation is different.

One selling point used for async is it makes blocking calls obvious, and that would somehow avoid bugs. The claim (willfully?) ignored that green threads (aka, cooperative multiasking) were the earliest form of multitasking - they have been around for over 50 years at this point. They were never a source of the sort of bugs they claimed would happen.

Alternative headline: "Bitcoin Dev doesn't understand why people pay money for bitcoin".

I was pissed off at the 404 article, because a paper arguing LLMs will never achieve consciousness must define what they mean by consciousness, and the 404 article didn't mention the definition. This is a paper from DeepMind, so surely they are rigorous.

Turned out 404 didn't mention it because the paper never defines what LLM's can't achieve. Quoting from the paper: "A key insight from our contribution is that resolving the present uncertainty surrounding artificial consciousness does not require a complete and final theory of consciousness."

As you say, Dijkstra neatly penned a response to arguments that don't define their terms in 1983. They are exercises in linguistics, not science or engineering.

> The avalanche of bugs I’m imagining would come from existing JavaScript code being run in a different context than that in which it was written and tested.

Oh, right. As you said, the ship has sailed. I think you could bolt green threads onto javascript now without ill effects - apart from bloating the language. I can't see anything that could go badly (certainly no avalanche of bugs). But in javascript green threads are only mildly more ergonomic than async. I wouldn't be bloating the language for such a small return.

Rust is a different position. The current async implementation has two big black hairs. Firstly, they had to come up with a type-safe way saving the functions current state. By state, I mean what a function normally stores on its stack. What they came up with is a work of art in some ways, but it doesn't work well with the borrow checker. The borrow checker insists you prove that you have exclusive use of a variable while it exists. Things on the stack have a limited lifetime (the function call), so the compiler knows they don't exist for very long. Even with that small lifetime it's a battle, but it's workable. Async persists that state, usually to the heap, which can effectively live forever. That wreaks havoc with the borrow checker, causing comments like this: https://news.ycombinator.com/item?id=37436274, quote: "Yes, async is effectively a much harder version of Rust ...".

The second issue is colouring. In the current Rust async implementation of large chunks of it is left to libraries, like tokio. Each of these libraries has to provide their own I/O. They aren't compatible. So if you want to use a cute new HTTP server, you are out of luck unless they provided a version that talks to the async library you are using.

The library writers do their best to accommodate by providing interfaces to the popular async libraries. That forces them to do a extra work. Whereas before they could just call `std::file::File::read()`, now they have to abstract all the I/O they do to a different module, and provide an implementation of that module for each async library they want to support.

The outcome can only be described as a mess, and that's putting it politely. It's harming uptake of the language. It wasn't like they didn't know it was coming either - there were comments pleading for a better implementation. And it wasn't as if weren't better solutions weren't already apparent - they had green threads before, they made some wrong turns with its implementation that needed to be fixed. And it's not like these solutions were harder to do than the async implementation they came up with. Async needed new standard library features to stabilise (like `Pin<>`) and introduced new keywords - none of which was needed for green threads. (Although some would be useful for an efficient green thread implementation - like knowing the maximum amount of stack a function could use.)

In the face of all that, they persisted with async. You'd need a sociologist to explain how that happened - to my engineering brain it's inexplicable. Unlike Javascript it isn't just mildly ergonomic implementation of the same thing, it's a serious mistake - well worth the effort of throwing out and replacing.

> I suppose all your green threads / fibers could run on a single CPU core.

yes.

> But what's the point? How would that be an improvement over what we have now?

> But its basically async/await but without declaring functions as async.

You answered your own question: yes, you get what you have now, without all the overhead of async, await, promises and futures.

> But if you do that, any function call you make could yield before returning.

A green thread could be an instance of a particular type, so `input = self.yield()` would fail if you aren't a green thread. So no, not "any function" - just ones that instances of a green thread, or are passed a reference to one.

> Does it yield to other threads before returning?

It could if you pass it an instance to a green thread, otherwise it can't.

> This would lead to an avalanche of bugs.

It doesn't. Cooperative multitasking is at least 1/2 a century old at this point. The bugs you're imagining will happen mostly aren't an issue. To the extent they do happen, it's because someone hasn't thought about two control flows modifying the same data structure. Yes, that happens, but it happens in all single threaded code - async included. It's why we hate side effects. It's what Rust famously prevents with its borrow checker even in the face of side effects. It's not avoided by async. The explicit colouring does not help to prevent it - it's just overhead.

FWIW the one issue cooperative multitasking does often introduce is that they can take a long time to execute, so other cooperative tasks don't run in a timely fashion. Exactly the same thing can happen with async of course. It's not usually a problem in browsers, but in embedded solutions where cooperative multitasking is commonly used, it's a real issue because they are often real time. Ask me how I know.

> Javascript guarantees that while my (non async) function runs, no other code gets executed.

This remains true. You are getting confused by your mental model of threads as a form of concurrency. There is no concurrency going on there. Semantically it is near identical to async / await. The principle difference is in async / await, the program is explicitly creating each stack frame on the heap using manually allocated objects. In addition to the mental overhead that creates, it slower than using a real stack like green threads do. But now for the truly bizarre twist. Can you guess how modern javascript engines get around that speed issue? Wait for it .... they create an explicit stack ... that looks like what green threads would use anyway! And as a wonderful side effect - you get real stack back traces again. The irony is almost palpable. https://v8.dev/blog/fast-async

> Threads (cooperative or preemptive) would be a massive change to JS. It would cause an endless parade of bugs, and frozen websites. To say nothing of your notion we could casually reinvent DOM events. That ship sailed a long time ago.

I agree the ship has sailed at this point. The rest of the assertions you make there are wrong.

This assertion stands out: frozen websites. Can you tell me how they are going to block? There are no blocking calls in javascript now. The things you would await on now would be passed a green thread handle. But the javascript scripts events called from the DOM have no green-thread handle, so they can't block.

> Personally, I much prefer this information to be explicit. I need to know as a programmer whether or not execution will be interleaved.

You don't. You've just been conditioned to think that because you've never done it any other way. But the reality is people have been using cooperative multitasking for a long, long time. It pre-dates threads and async. The issues and bugs you are proclaiming would happen don't arise.

Ok, you've been programming for years. But didn't learn a lot about threads, apparently.

> Multithreaded code is often much harder to reason about than async code, because threads can interleave executions and threads can be preempted anywhere.

No, green threads / fibres or whatever you want to call them explicitly don't interleave executions. They are a form of cooperative multitasking. Async/await is another form of co-operative multitasking. One former just builds on what we already have. The latter re-invents the universe.

By the by, the blocker for Javascript green threads wasn't preemption, mostly because there isn't any. It's that Javascript has a "run to completion" model. If the DOM calls a javascript event (which is effectively how all javascript is invoked in a browser), it doesn't block, so it always runs to completion. Green threads break that model. It's not a insurmountable break - the DOM events could always still return immediately, but they could start a green thread that returns to them as soon as they block. Thinking about it, the change is possibly smaller than language changes required by async/await.

If you can reason about where an await is, you can reason about where a green thread yields. The only difference is that one of them clutters your syntax and the other doesn't.

> the problems were not minor but fundamental, and had to do with C interoperability,

The interoperability problems came from a design choice they made: they wanted to invisibly swap between OS threads if a blocking call was made. That was the wrong design choice for Rust. It is not something green threads require - it's an additional burden they imposed on themselves.

> a fine choice to make in the context of Go,

Correct. It was.

> enable concurrency even on systems where threads do not exist,

And that was their mistake. Green threads are just user space stacks, which any CPU that has a stack pointer can support. They don't need OS threads. But in the initial Rust implementation they added "invisibly supports blocking calls" implementation. That does indeed need full OS thread support, and breaks the C interface.

They could have just abandoned that mistake, implemented pure green threads and they would have been done. But no, they instead they implemented async. So instead we got new keywords, had to wait years for various new language features to stabilise (like pin) and lifetime 'static. I'm sure the language designers spent many happy man months solving the problem "How do we represent a suspended function as a type-safe State Machine?".

What we got for all that effort is something so famously difficult to use, even experienced Rust programmer shy away from async. Whereas with green threads a programmer could just reuse their knowledge and mechanisms Rust has for sharing data across multiple stacks, for async they have now to battle the borrow checker on a new front - the language to absorb their function state into 'static area that has fewer lifetime guarantees. The alternate green thread implementation could have had just two colours - blocking and non-blocking, now we have a colour for every async library. Whereas with green threads they could have stabilised the interface to underlying the event loop, we are now stuck with every library writer having their I/O in their own mini API, which they swap for each async implementation.

And while the type-safe State Machine they did come up with is an engineering marvel, it's very complex and requires data copies under the hood. Green threads just reuse an existing mechanism for saving a function's state - the CPU's IP Address, the registers and the stack. It's so simple anyone can understand it, it isn't something additional to learn because the program's main already uses it, it is very, very fast because it's undergone decades of refinement, and it's also type safe!

But instead in what we got the syntax is a mess, the error messages are incomprehensible, and we re-implemented the CPU's stack management in software (invariably slower) because they didn't want to write the logic to grow a hardware stack.

The language will be better off recognising it was all a huge mistake, and moving towards standardising on a green thread implementation like mioco. Everyone who has to manage 100,000 lightweight processes would be immensely grateful for the simpler, faster API. Some of the truly impressive stuff done for async, like knowing how much stack some function calls can take, would be really useful for green threads. You know the size of the stack you need - to the byte! So it's not a complete loss.

I guess one way to address this would be industrial scale efforts in the USA to accelerate the things that gave its current lead in engineering and science. Oh, wait ....

Doh! Of course it was easier to implement. IETF wants a working open source implementation before standardising.

Have you ever tried to implement an ITU standard from just reading the specs? It's hard. Firstly you have to spend a lot of money just to buy the specs. Then you find the spec is written by somebody who has a proprietary product, and is tiptoeing along a line that reveals enough information to keep the standards body happy (ie, has enough info to make it worthwhile to purchase the specification), and not revealing the secret sauce in their implementation.

I've done it, and it's an absolute nightmare. The IETF RFCs are a breath of fresh air in comparison. Not only can you read the source, there are example implementations!

And if you think that didn't lead to a better outcome, you're kidding yourself. The ITU process naturally leads to a small number of large engineering orgs publishing just enough information so they can interoperate, while keeping enough hidden so the investment discourages the rise of smaller competitors. The result is, even now I can (and do) run my own email server. If the overly complicated bureaucratic ITU standards had won the day, I'm sure email would have been run by a small number of CompuServe like rent seeking parasites for decades.

Impressive article. He gathered a lot of data interesting in its own right, tested a lot of theories, focused on facts over assertions; and it did it in a way that was a pleasure to read.

The conclusion was somewhat underwhelming: it's a least two things hitting at once: inflation and COVID, possibly with social media thrown in.

I dunno if he's right, but I'd probably add two more factors: the latest round of the ongoing (for 4 years now) Ukraine war coincided with the start of the decline, and now the rise of AI providing a sting in the tail. In fact it was the total lack of AI writing in this piece that made it such a pleasure to read. It's a rare find nowadays.

It isn't often we Australians get to brag: I put 32kW solar, 40kWh battery, DC EV car charger, AC car charger - US$35,000.

My 4 adult household has two EVs and the house is centrally air-conditioned. Average daily usage in January-March: 100kWh per day. Average feed in price when the sun is shining: about $0/kWh (but negative if it's a bright cool day.) Average electricity bill: a small credit. Cost of electricity where I live USD$0.23/kWh. Pay back time: 4 years.

Country with the most rooftop solar installations per capita: Australia.

Country with the most household kWh of batteries installed per capita: Australia.

This is an ad:

    Our engineers are orchestrating fully autonomous digital task forces, firing off agents and accomplishing incredible things.

Who swallows this stuff? Like all marketing it's full of weasel works and unverifiable claims. I don't doubt 75% of their code started life as the output of a model mind you, it just "forgets" to mention the subsequent hours of humans put into reviewing, discarding the crap, and refining what was left.

Edit: it's slop. How did I not spot it was slop posted by the marketing department immediately? If they want engineers to pay any attention they will have to do better. Or maybe they are targeting engineers any more? blog.google used to be a reliable read.

The rest of the world is well and truly over being bullied and screwed over by Trump. Notably while they went along with the previous wars the USA fought (even when they thought they were dubious) they refuse to help Trump is his wars.

If Trump made the mistake of actually attacking Greenland of Canada, they would probably go to war with him. Fortunately, that doesn't seem like something TACO would do. He is currently getting his nose bloodied by Iran, and he doesn't any appetite for pain - even in the very short term.

From the rest of the world's perspective, it's apparent 60-70% of USA citizens share the same view. Unlike Trump, we are patient. We will wait it out, and then gladly re-unite with 60-70% of the USA who are our friends. This friendship has worked out very well for both sides for a long while, and after this blip passes will likely continue to work out.

Async is a Javascript hack that inexplicably got ported to other languages that didn't need it.

The issue arose because Javascript didn't have threads, and processing events from the DOM is naturally event driven. To be fair, it's a rare person who can deal with the concurrency issues threads introduce, but the separate stacks threads provide a huge boon. They allow you to turn event driven code into sequential code.

    window.on_keydown(foo);

    // Somewhere far away
    function foo(char_event) { process_the_character(char_event.key_pressed) };

becomes:

    while (char = read())
        process_the_character(char);

The latter is easy to read linear sequence of code that keeps all the concerns in one place, the former rapidly becomes a huge entangled mess of event processing functions.

The history of Javascript described in the article is just a series of attempts to replace the horror of event driven code with something that looks like the sequential code found in a normal program. At any step in that sequence, the language could have introduced green threads and the job would have been done. And it would have been done without new syntax and without function colouring. But if you keep refining the original hacks they were using in the early days and don't the somewhat drastic stop of introducing a new concept to solve the problem (separate stacks), you end up where they did - at async and await. Mind you, async and await to create a separate stack of sorts - but it's implemented as a chain objects malloc'ed on the heap instead the much more efficient stack structure.

I can see how the javascript community fell into that trap - it's the boiling frog scenario. But Python? Python already had threads - and had the examples of Go and Erlang to show how well then worked compared to async / await. And as for Rust - that's beyond inexplicable. Rust has green threads in the early days and abandoned them in favour of async / await. Granted the original green thread implementation needed a bit of refinement - making every low level choose between event driven and blocking on every invocation was a mistake. Rust now has a green thread implementation that fixes that mistake, which demonstrates it wasn't that hard to do. Yet they didn't do it at the time.

It sounds like Zig with its pluggable I/O interface finally got it right - they injected I/O as a dependency injected at compile time. No "coloured" async keywords and compiler monomorphises the right code. Every library using I/O only has to be written once - what a novel concept! It's a pity it didn't happen in Rust.

You trust Claude (or any AI) to do anything right? The odds are good - but never 100%.

That said, "jj new -A @", get Claude to do it's thing, "jj squash" is going to be pretty safe.

According to the guy who wrote JJ, he copied all the ideas you mentioned from hg. That included a lot of ideas from hg's add ons. So the similarities are no accident. But then he added a twist - he didn't just delete the index, he dropped "hg commit" as well.

I can't see it going anywhere. It is in many ways "just" a different porcelain for git. The plumbing is the same. It's also safer to use: no JJ command can lose data another JJ command can't recover.

Rewriting immutable commits is only "fundermental" if it's enforced upstream. You can always break the rule locally.

That said, jj will warn you if you try to edit an immutable commits, and you can configure what it considers immutable.

> I've been doing this in git for years.

You've missed a crucial detail.

You've both been doing it, but only one of you was using a tool that needed rebases to pull it off.