I’m not advocating this, but it is worth observing that it is yet another problem one could attempt to address with dependency injection, similar to io and allocators.
Help me understand why not? I know solar power generation in space, and "beaming" the power back, was a naive idea. But this would actually use the power up there, mostly for training, but also for inference.
That claim seems reasonable. I have zero knowledge of the economics of launching and maintaining satellites though.
The simplest example is that you can easily be wasteful in your use of threads. If you just write blocking code, you will block the thread while waiting on io, and threads are a finite resource.
So avoiding that would mean a server can handle more traffic before running into limits based on thread count.
I do something similar with Claude Code. I say, "I ate a single serving of that Toasted Beef Ravioli that Aldi sells." Claude web searches, finds it, gets its nutrition info, then uses gspread to add it to the daily food log tab of my spreadsheet.
So much less hassle, lower activation energy needed than with MyFitnessPal.
But if you are saying that a human can instruct ai agents to refactor to prevent the big ball of mud, then you are saying that clean code *is* important.
It is an interesting possibility that must be considered. Only time will tell. However I disagree.
I think complex systems will still turn into a big ball of mud and AI agents will get just as bogged down as humans when dealing with it. And even though re-build from scratch is cheaper than ever, it can't possibly be done cheaply while also remembering the millions+ of specific characteristics that users will have come to rely on.
Maybe if you pushed spec-driven development to the absolute extreme, but i don't think pushing it that far is easy/cheap. Just as the effort to go from 90% unit test coverage to 100% is hard and possibly not worth it, I expect a similar barrier around extreme spec-driven.
Clarification: I'm advocating clean code in the generic sense, not Uncle Bob's definition.
I wrote: It has a garbage collector and goroutines, so clearly it is not trying to be a systems programming language.
Then ... I saw that it does indeed pitch itself as a systems programming language. So, I guess you both are right.
If Gossamer were to drop that claim, then I'd say it looks impressive to me. I have often wanted this particular mix of language features.