Given how quickly AI seems to resort to manipulation and blackmail if it doesn't get what it wants on the first attempt, maybe this isn't such a great idea.

I imagine the first step would be for them to make a cross platform UI framework that's better than any existing options, and then port claude to it.

Making five different apps just to claim "native" doesn't seem like a great choice, and obviously for now, delivering new claude features takes priority over a native graphics framework, so electron makes sense. But that doesn't mean it'll be on electron forever.

Respectfully: skill issue. My employer ships software native for Windows, Mac, iOS and Android. Different codebases for all (though they share a lot of common stuff), all maintained by a shockingly small team.

It’s absolutely achievable if you give a shit about your products and I’m long over hearing the bevy of usual fucking excuses from software houses often magnitudes larger than us who struggle to even keep their electron shit working correctly.

Native is shorthand for "integrated into the platform". Lowest-common-denominator stuff that Electron gives feels correct nowhere (looking at you, Slack). The very best cross-platform applications implement their UI using the native platform idioms on the native platform technologies, and share the core of their logic. The current best example I have is Ghostty which feels perfectly at home on either macOS or Linux.

When I complain about a lack of “native” software I pretty much always mean the platform-provided defaults. Not some cross-plaform UI toolkit that happens to be “native” code. Most apps that I see using QT on Mac or whatever would provably be better as Tauri apps.

Qt is straight up much faster than Tauri, and Qt at least looks native-ish, whereas React is the wild wild West.

>> cross platform UI framework

How about Java Swing? It's already battle tested and deployed everywhere you have Java.

So, soon the sources will be out of business and the LLMs will have no information to look up.

I guess the future model is, LLMs pay for raw data and news to ingest and use on demand, and ignore the "free" internet. That seems like a good landing point, where quality info is rewarded and cheap spin is not. Of course cheap spin will continue to be produced, but hopefully won't be baked into the system.

A potential corollary: companies that offer a single service of high quality will be preferred by AI agents. Companies that cobble together low quality services will be replaced by agents that integrate high quality services on demand. The business model of "core service plus add-on services" will also be diminished, as low quality add-ons will be replaced by on-demand integration with higher quality equivalents or AI generated custom functionality.

So basically businesses who focus on maintaining best in class core services and avoid the cruft will be the winners in the AI world.

That all sounds nice, but I can't really see AI companies paying for content.

Putting morals and previous experience aside, they would need massive investment to people producing massive volumes of high quality content for training.

How's the multicore and async story these days? I remember that was one of the big draws of F# originally, that it had all (or, most of) the type safety features of OCaml but all the mutlicore of dotnet. (Plus it created async before even C# had it). Has OCaml caught up?

OCaml has full multicore support with algebraic effects now. The effect system makes things like async very nice as there's no function "coloring" problem: https://discuss.ocaml.org/t/ocaml-5-0-0-is-out/10974

But I don't believe the effects are tracked in the type system yet, but that's on it way.

The type system for effects is an ongoing research effort. For now you get unhandled effect exceptions at runtime.

With Multicore OCaml we gained thread sanitizer support and a reasonable memory model. Combined they give you tools for reasoning about data races and finding them. https://ocaml.org/manual/5.3/tsan.html

Yeah, I don't care for go but I expect it to win here. Its performance is good enough for most use cases, it has a huge ecosystem of libraries, lots of training data, and deploys as a binary so users don't need to install anything else.

I expect rust to gain some market share since it's safe and fast, with a better type system, but complex enough that many developers would struggle by themselves. But IME AI also struggles with the manual memory management currently in large projects and can end up hacking things that "work" but end up even slower than GC. So I think the ecosystem will grow, but even once AI masters it, the time and tokens required for planning, building, testing will always exceed that of a GC language, so I don't see it ever usurping go, at least not in the next decade.

I wish the winner would be OCaml, as it's got the type safety of rust (or better), and the development speed of Go. But for whatever reason it never became that mainstream, and the lack of libraries and training data will probably relegate it to the dustbin. Basically, training data and libraries >>> operational characteristics >>> language semantics in the AI world.

I have a hard time imagining any other language maintaining a solid advantage over those two. There's less need for a managed runtime, definitely no need for an interpreted language, so I imagine Java and Python will slowly start to be replaced. Also I have to imagine C/C++ will be horrible for AI for obvious reasons. Of course JS will still be required for web, Swift for iOS, etc., but for mainstream development I think it's going to be Rust and Go.

> But for whatever reason it never became that mainstream

Syntax. Syntax is the reason. It's too foreign to be picked up quickly by the mass of developers that already know a C style language. I would also argue that it's not only foreign, it's too clunky.

The syntax is ridiculously simple, and I can't in good conscience allow OCaml to be called clunky in a thread about a language that solved error handling with record-like interfaces and multiple return types.

Yeah I half think Haskell is a big reason it's not more popular. If Haskell didn't exist, maybe OCaml would be better recognized as a good all-purpose language that makes safe practices the default, rather than just a gateway drug for Haskell.

ReasonML easily fixes that particular issue.

I think so. If nothing else, when you deploy and see a bug, you can have a script that revives the LLMs of the last N commits and ask "would your change have caused this?" Probably wouldn't work or be any more efficient than a new debugging agent most of the time, but it might sometimes and you'd have a fix PR ready before you even answered the pager, and a postmortem that includes WHY it did so, and a prompt to prevent that behavior in the future. And it's cheap, so why not.

Maybe not a permanent part of the commit, but something stored on the side for a few weeks at a time. Or even permanently, it could be useful to go back and ask, "why did you do it that way?", and realize that the reason is no longer relevant and you can simplify the design without worrying you're breaking something.

Nah, it makes teams useless. Maybe not quite yet, but soon, one engineer will be able to do a few sprint teams' worth of work, and deliver features orders of magnitude faster than a team working in parallel. Yeah, generally at first this will be seniors only. But before long, a junior will be able to come in and learn to manage one sprint team's worth of work under the guidance of a senior and partnered with a PM, and grow the product from there. Long term, I imagine 90% workforce reduction will be the norm. Just about all software is a rinse and repeat of some other software, not much true innovation, so picking and choosing and implementing some other software's feature into your own will start to become trivial single-day projects from start to finish. Hopefully AI creates some new industries that SWEs can roll into, but I'm feeling more doomer every day.

Yeap, and people are still forcing juniors to make small code changes when they should be learning by creating entire apps on their own, deploying them, etc. WITH a senior giving them feedback occasionally. I think people are going to take a while to catch on though, for better or worse....

Yeah, IMO one of the first things we'll see change is more of a migration back to monoliths. Right now adding a feature has to go through multiple teams, a dozen services, a coordinated implementation and deployment schedule, a Byzantine and often manual set of integration tests, etc. Yeah AI can help with that, but the point is that AI doesn't need it. On a monolith, it sucks for dev teams because parallel development at large scale is difficult and other teams' bugs can delay the launch of your unrelated project. Hence, microservices became popular. With AI, development happens so fast that it's largely serial. So there's no real coordination needed. A whole feature is one PR, one set of tests, one app to run locally if you want, one deployment, one thing to look at and roll back if there's a bug. Creates a virtuous cycle all the way up.

I imagine lots of established companies will struggle migrating back to that pattern, but I have to think most new companies will head in that direction, which should let them catch up quickly.

Anyway that's my take. We'll see.

Thanks for saying that! I was worried I was the only one. I mean, I'm glad I tried it, but I was happy to get back to a little more determinism in my day to day.

Yeah, hopefully an outgrowth of this will be new amazing applications like that, that we never could've dreamed of before. I imagine "distributed services" will be "solved" by EOY, and the days of glorified CRUD app coders making 200K straight out of college are over for good.

But I think there will be new opportunities for people who are willing and able to learn. Entirely new fields will pop up and somebody will have to work on them. Most likely, the CS grads who are out of a job, or just frustrated and want to do something else.

So I don't think the opportunity to do innovative things and make a difference in the world is gone. But the opportunity to do so by typing code into a text editor may have breathed its last.

Or just reincorporate in Finland or something. If the US is going to be this hostile to business, time to gtfo.

Or they can just not sign contracts with the DoD. They landed themselves in this situation by making a deal with the devil. At any rate, unless Finland is about to announce a massive surge in funding for their military this doesn't solve Anthropic's desire to suckle sweet taxpayer money off the military industrial complex's teat while simultaneously pretending to have principles.