Openapi can do that too. But the real benefit is that it forces a simplification of the interface. XML has too many outs for architectural astronauts. JSON has close to none.

Anyone on HN can write a Swift alternative protocol in a few days. XML documents signed with public keys is a good start. The trick is to get the banks to use them and to integrate them in their systems, but the EU is capable of writing banking regulations.

Operating systems are even easier - pick your flavour of Linux - devices are all made in China anyway.

Its the cloud and software part that sucks. VPSes aside, almost any managed service is US based.

AI has made this even worse.

Expect mistral to keep getting large cash infusions until they get competitive.

Managed services weren’t needed because big tech was bending to EU regulations and buying out alternatives. The services aren’t rocket science; plenty of euro devs participated and still participate in building them, they’re just on US big tech payrolls. Expertise is there, money isn’t, yet.

Good point. The data center hardware is there and there's plenty of open source for things like PaaS and AWS compatible systems. Bewildering that this does not exist and everyone just used AWS.

AWS, etc has datacenters in the EU.

Microsoft relies on the EUs courts to recognise their property rights.

It is absolutely true, with the interesting caveat that the basic (spelling grammar) doesn’t matter. Clarity and detail of your ideas do.

I was reading through the documentation and it seems like these are writing directly to storage not on the machine where the sprite lives? That makes me worry for how slow the storage is. npm install writes a lot of files.

It's tiered, they have local nvme that gets written back to object storage.

npm install hasn't bothered me, but I know of people with massive npm issues that would like faster first installs. Fortunately, it's incrementally quicker after that.

The storage performs pretty well for running claude + my dev. It'll improve immensely in the next few months, though. We should be able to get near native NVMe speeds for the working storage set on reads/writes/flush/fua.

That argument is pretty close to what people used to say about photography.

In reality its more about the candler maker seeing gaslighting down the road. You are not going to compete.

I use writing to think - I also happen to be really good at typing so fast my hands don't coordinate. And I am a terrible speller.

If I wanted to publish my writing, people would focus on that, and not the content of the writing. If I run it through Kimi K2, people will focus on my ideas.

its more like I buy Visual studio, it will crash at random time, and I get a response like you don't know how to use the ide.

It's not like that though.

It's like you buy Visual Studio and don't believe anyone who tells you that it's complex software with a lot of hidden features and settings that you need to explore in order to use it to its full potential.

I feel it's not worth the effort to spend time and learn the hidden features. whenever I use it to plug something new into a existing codebase it either gives something good at first shot or repeat the non working solution again and again. after such session I only get a feeling instead of spending the last 15 minutes on prompting this, I should have learnt these stuff and this learning would be useful for me forever.

I use LLMs as a better form of search engines and that's a useful product.

> I feel it's not worth the effort to spend time and learn the hidden features.

And that's the only issue here. Many programmers feel offended by an AI threatening their livelihood, and are too arrogant to invest some time in a tool they do deem below themselves—then proceed to complain how useless the tool is on the internet.

I'd really suggest taking antirez' advice at heart, and invest time in actually learning how to work with AI properly. Just because Claude Code has a text prompt like ChatGPT doesn't mean you know how to work with it yet. It is going to pay off.

> I should have learnt these stuff and this learning would be useful for me forever.

Oh, if only software worked like that.

Even a decade ago, one could reasonably say that half of what we proudly add to our CVs becomes obsolete every 18 months, it's just hard to predict which half.

It will certainly help - but its an extremely high bar. Almost all formal verification of software today is "does this pass the typechecker"?.

Now this captures some errors, but it doesn't really capture high level ones (is this program guaranteed to not deadlock is a hard one), and it doesn't capture the one that is important for business purposes (does this do what the customer wants). That requirement is more important than correctness (vitness all the software that is described as "crap", but is nonetheless widely used).

I don't think this is a required key to unlocking vibe coding. That seems to be easy: does this provide business value? And there the answer seems roughly to be "yes".