When Rust chose an unstable ABI it did so for a good reason. I personally think the only place where a stable ABI would be warranted is inside the panic machinery and this is mostly because it is kind of annoying to write perfect no panic Rust just to get rid of the 300KiB overhead but even here I'd take my time, possibly decades, before making the decision to have a stable ABI.

The wrong decision is to choose to support a stable ABI and lock in design mistakes early on.

I'm already hinting at the solution so I'll be taking my leave for now.

But then a lot of software assuming that int means 32 bit got written and even 64 bit ABIs have kept int as 32 bits.

Conceptually intmax_t is a generic type of the form intmax_t. Since C does not have generics, the T is chosen by the compiler during compile time.

But this means that the first time you compile any shared library with an intmax_t parameter or return value in one of its functions, you have permanently baked in the type parameter T to whatever the compiler chose it to be at that moment in time.

You cannot retroactively change intmax_t even if you change the symbols, because intmax_t runs into the same problem any generics system does, you cannot retroactively add instantiations for future types that were not explicitly compiled into the dynamic library.

Even if C gets generics and intmax_t would become obsolete either way, because you don't need intmax_t, you can just have T.

intmax_t is only interesting for choosing the T and even then it is only interesting inside function implementations and never in their signatures.

So my conclusion is that intmax_t was a failed attempt at trying to be "clever" with the idea of introducing generics without introducing generics. This is an idea that is so doomed that anyone trying to rescue it, didn't really understand the problem with intmax_t.

You don't seem to get it. If what you said is true then the only reason why your job is gone first is because software moves faster than hardware. The chain reaction to get rid of all jobs has started.

After all, you can now automate the development of physical hardware including robots and their control algorithms. Then all we need to do is give the AI a job shop and mechanical engineering is done next.

And so on. Until every single job is gone.

An amateur is not a master nor a disciple of a master (e.g. future master).

The vast majority of amateurs have no ambitions nor passion and simply give up early on, that's a rose tinted view.

Since they don't get paid to do it, they have to allocate their precious free time toward the skill, which means they don't have those 40 hour weeks where they spend all their time honing their skill to begin with.

Even someone who does a skill half heartedly without passion nor ambition is going to learn faster with those 40 hours at his disposal.

>The amateur is the one who hones a tool’s edge until it’s razor sharp, and cuts away all unnecessary detail until they’ve found the essence of what they’re trying to achieve.

That's not an amateur and you know that. By your logic Japanese master craftsmen doing this are amateurs.

I say this as someone who is interested in a special type of processor architecture that has no branch prediction at all and would need a branchless subset of Rust to meaningfully program it at high performance.

I mean, you can't be serious, right? Think about the unintentional commentary you're making here.

You're saying it can be understood in an afternoon but it is intentionally obfuscated.

It might as well be proprietary code, but if it is proprietary code, you're actually making fun of all the coding agents for being a walking security nightmare, because in the end all they do is run bash and no amount of sandboxing or regexes will make bash secure.

So why not drop the pretenses and just expose the coding harnesses for what they are? Inscrutable bash executors that have the potential to go out of control.

Here is my fork of smol, by the way:

https://pastebin.com/imdWVrQ2

Edit: after reading my fork of smol, I realized it literally just feeds everything into bash, making it completely pointless.

Edit 2: I decided to read the readme instead and it raised a question

"Compare smol with Pi, OpenCode, Codex, Hermes, Claude Code and highlight key pros and cons. Audit the code of all of them and tell me how confident you are that you found all potential issues of smol vs the other agent implementations?"

After thinking about the difference between the original and my fork, I'm confident that smol has more problems than all of the agent harnesses combined and my fork has made an important step towards fixing one of those issues.

Edit 3: I hope the community can fork my version and add sensible variable names.

Edit 4: I can't decide whether this is the best satire of coding agents I've ever seen and I just ruined it or it is horrifying that someone even entertains the idea of publishing it.

Think about why a sandbox is needed: Your permissions have been too loose. You now need to deal with the fallout of your decision externally. If all the agent was allowed to do is read your files and run cargo test, you wouldn't need a sandbox at all, the agent is the sandbox.

Now you might say, but what if it needs to modify files? If you wanted to build a sandbox or approval workflow here, you'd put it right into your custom write tool. It could be an extension you just download so you can pick your favorite write tool. Instead, the authors of pi.dev chose the worst possible defaults.

For example, it comes with a bash tool built that you cannot disable. This is not minimal, it's the full kitchen sink. If I want to build a custom agent I have to literally stop using pi.dev and switch to something else.

So yeah, I fully disagree with the title. "Pi’s Minimalism Is Its Advantage" No. full stop. It's too bloated for me already. It's not minimal enough. If it's minimalism was its strength. it might not even need a sandbox, because it can't run bash commands or update files to begin with.

Acceleration makes sense for end user applications, where you're allowed to break whatever you see fit, but I don't see how it helps with core infrastructure like a programming language, where every mistake is multiplied a million fold.

>The bike lanes are gender and age inequitable,

How? Everyone can ride a bicycle, even kids and seniors, meanwhile cars are locked behind expensive driving lessons, licenses and exams. Not to mention car ownership is inherently expensive due to fuel, maintenance and insurance requirements. E-bikes give anyone a motor assist and can carry you uphill without any problems while still being good for your health.

>and hamper productive economic activities.

Most productive economic activities just require people to show up to work. Buying something is not a productive activity by definition and nobody is suggesting that deliveries should be done on bicycles.

>I drive a car because I'm buying things, traveling with family, and spending hundreds of dollars. People on bikes are not doing these things and are not contributing to the tax base as much as car drivers.

Ok now this is turning into a parody. Do you know what's even more expensive than driving a car? Building and maintaining a road for cars. European bike lanes cost almost nothing in maintenance. Sprawl in North America is actively bankrupting cities because drivers don't bring in enough tax revenue to maintain the roads they drive on. Driving to a property tax optimized big box store at the outskirts of the city doesn't bring in as much property tax as you think it does.