didibus

China is working on the whole supply chain though and they're willing to compete on razor thin margins. Just look at EVs. They build great cars but the competition is so aggressive that investing in any one Chinese EV company isn't exactly an amazing ROI.

I could see AI ending up the same way where the customer captures most of the value rather than the companies. Open weight models are what make that kind of competition possible.

Ya, I think that was a bit misspoken. They mostly meant direct C and C++ interop. It feels much less like a traditional FFI and more like using C and C++ libraries from C++ itself.

Correct, the claim here is that this is better because cache locality is too big a hit and not worth the trade off. I don't know if this is true or not and likely depends on workload.

I think they might say you need to rewrite your long-compute to have explicit yield points. Say you are parsing many rows, you'd explicitly yield after every 100 rows for example.

I'm not 100% sure, but it looks like Tina forces your IO to be return values. You can't actually do IO inside the Isolate handlers, so your compute code runs and returns the next IO operation to run. That's what it meant by you need to be explicit about the state machine, you have to have a handler for before I make this IO, and a handler for after that IO has run.

Isolates are like synchronous state machines. During each handler invocation, an isolate processes one message, mutates its private state, and chooses its next scheduler action. If IO is needed, it returns an IO Effect describing the IO, the isolate is parked, and the eventual IO result is delivered through a later completion message. In the meantime it continues to handle messages of other isolates.

Edit: And I realized you asked about compute-heavy tasks, nevermind, it does not seem to solve that.

The suggested alternative is interesting, I was expecting a Rust library though, but it's an Odin one. What's missing are any sort of benchmarks or proof of the claims that it will scale beyond the issues the article discuss.

Great read, thanks for sharing!

I think number of features released to customers (not behind a feature flag or still being rolled out, but fully rolled out). And number of bug fixes (only those reported by customers).

Also just in general, customer satisfaction, acquisition, conversion, retention, etc.

Number of completed org-level roadmap items, org-level goals achievement rate, and so on.

I also think a good one would be seeing an increase in meeting estimation, like if project was estimated to take X days with Y devs, does the use of AI increased how often you met or beat those estimates in actual time/dev effort?

And you'd want to compare that against prior years, where no AI was used, within the same org, or try going 1 quarter without AI and another with and compare quarter to quarter.

Article did a decent job of showing discipline and care and human involvement to assert the automated rewrite was done diligently, as best as it can be when using AI for it. I does make me feel a bit more comfortable about it.

As an aside, I don't know why anyone would not want to use a memory-safe (and possibly race-safe) language in 2026. Rust gives you that in a performant package, so if you are turned off by GCs and immutability for performance reasons, you still have the option to use Rust.

I can understand when you need the absolute best performance and you decide to drop to down to C++, and I also relate with just personal preference, but beyond those it seems a no brainer to me.

to exhaustively come up with reasons why the changes create bugs or do not work

My biggest issue currently, is I can't seem to get a code review that's about the simplicity of the code, and no /simplify ain't it. Removing certain bugs and generally working seems to be doing alright, especially if it's following either an example code (like in the Bun rewrite case) or a well defined "spec" of how to proceed.

That's true, that's a money constraint, which hopefully would mean as they gain more paying users, they can scale their index further, and rely less and less on other indexes.

Ya, because the upstream repos already did the majority of the work to port the game to Linux and MacOS. This fork used Fable to add iOS support with touch controls.

The port to MacOS is from the parent upstream repo, which also has it working on Linux, this fork added iOS support.

It added iOS support, the upstream repo had already ported the game to Linux and MacOS.

Diff of the changes Fable added to the parent fork (which does not appear to have used AI): https://github.com/ammaarreshi/Generals-Mac-iOS-iPad/compare... for those curious.

It seems it didn't:

Built on EA's GPL v3 source release via fbraz3/GeneralsX (which did the heavy lifting of the macOS/Linux port — this fork adds the iOS/iPadOS port and a set of engine fixes)

Fable added 19 commits on top of the parent fork, which did not use AI.

You can see the diff of what Fable added here: https://github.com/ammaarreshi/Generals-Mac-iOS-iPad/compare...

I'm confused, that's just a feed?

SearXNG is different though, because it still relies on a data-harvesting, ad-driven online economy. Off course if all you care about is privacy, might be fine, not sure how good it is at hiding you, but if you care more about not having your data/attention be the revenue source and having software incentives be to offer something customers are willing to part money for, Kagi is still it.

I see, so just major refactor, or almost live-rewrite of a very messy code base, but mostly in the medium/small design space. Ya that makes total sense. It's mostly we already did this and have figured out the ambiguities, we just need to clean it up to basic coding standard and code structure/patterns.

I don't have too much unknowns in my work, I simply have way too much to do.

Interesting, I'm curious what work you do? My software engineering career has never been in that situation, it's always so much ambiguity and unknown that trumps everything.

I'm getting a bit tired of these disguised adverts.

Here's how non robotics engineers used AI to do a short robot integration task faster than other non robotics engineers without AI.

Where "better" mostly means faster, and who knows what happens on longer horizons, with actual robotics experts, robustness requirements, or tasks where the hard part is control rather than API spelunking.

Same, I use Spacemacs in holy mode, which is spacemacs with normal emacs key bindings and not vi modals, but still I wish there was a good config that was straight up emacs bindings and didn't pull in evil at all.

Has something changed since you last told me:

I think Gloat/Glojure has the best hosted runtime story because of its AOT to Go src pipeline - you can grab anything Go at compile time. OTOH let-go can roundtrip any Go value including structs, functions and channels but it does not allow pulling arbitrary go libs without wrapping them up first - they'd need to be built into the runtime for this.

I believe this is the most promising Clojure hosted on Go, as their has been a few recently, this is the only one with full proper interop.

For sure, we'd need to be careful about implementation. Maybe we can't come up with a good version and decide not to do it.

But we should at least be able to discuss the problem.

Some people seem to think it's totally fine for wealth accumulation to be effectively uncapped, and for ownership to keep concentrating gains no matter how large the numbers get.

Past some point, that seems hard to justify.

Why do you think ownership should be uncapped and allowed to capture majority of wealth?

PG is absolutely right, if you want to be a billionaire, you need accelerated growth, you need to find something that a large number of people will pay for and you need to make sure you own equity into it as it grows, equity that grows with it.

And that's exactly the source of the debate, this trick to billionaire-level wealth, is that a good thing? Because it wasn't earned through labor, no one can earn a billion dollar through labor, you can only accumulate it through vast equity into market capture of a large market.

Not really. That's why I said no one can work a billion times smarter.

There is a "hack" to wealth, and PG has explained it here. You need a large addressable market with little competition where you can capture a small amount of value from a huge number of people at scale.

Individually, that value is often not worth much. A surgeon can save your life, and you'd give up most of your fortune for it. A starving person would do almost anything for food. Most startups don't create that kind of value for any one customer. They create a little bit of value for a lot of customers, and at scale that turns into enormous wealth.

That's what people are arguing when they say scale is a form of cheating. Maybe you got into the position to own it through harder work, smarter decisions, more risk taking, more grit, or more luck. But not a billion times more. Once you own it, you've locked yourself into a growth curve that scales with little additional work. In many cases, it gets easier as it grows.

Past a certain point, wealth is no longer tied to your work. It's tied to your ownership.

That's also why CEOs want equity. They don't want to be paid solely for their labor. They want ownership in large scale production so they can benefit from the growth of the system itself and eventually sell that ownership for far more than they could ever earn through wages alone.

This is why, as a software engineer, I favor equity compensation and have benefited from it myself. But I don't think I've worked harder than countless people in jobs that don't have this characteristic.

I wasn't paid more because I worked more. I was paid more because I owned something that scaled.

That's the "cheat."

On what?

On the business income, on the sale of shares, on their wealth, on loans, on estate and inheritance, etc.

Breaking up the company is another avenue, it could increase competitiveness and make the markets freer, open up more options for employees to shop around for employer, etc.

Raising minimum wage, stronger overtime rules, paid family leave, mandatory paid vacation and sick leave, non-compete restrictions, profit-sharing requirements, and other regulation that favors the employee is yet another avenue...

There are ways if the will is there.

Uh, pay cuts due to financial problems of the business happens all the time.

You make the law whatever you want and those become the terms. Either agree to them or you're not allowed to operate a business here. That's how taxation and other regulation work. You're free to operate a business in another country if you don't like it, just as an employee is free to look for work elsewhere.

The disagreement is whether a founder who owns 20% of a company that grows from $1M to $100B should personally receive $20B of the resulting value while thousands of employees and customers contributed to creating that value.

That's the debate.

She's saying nobody can truly work a billion times more, a billion times harder, a billion times smarter, so nobody can actually earn a billion dollars.

Given that, how can some people be worth as much? There has to be some capture of wealth somewhere such that even though nobody can actually earn as much, they can be worth as much.