Thing is that's a question for the market to decide. Which is why we have anti-trust / anti-monopoly laws in the first place. We don't want the state setting "fair" prices for anything, it always backfires. We want them ensuring the market is free to set prices. Monopolies granted by the state (trademarks, copyright, patents) are specific and limited, and ideally we want monopolies that arise naturally to be similarly limited, or broken up if they are being weaponised against the public.
Claude is (in my limited experience so far) more useful after a bit of back and forth where you can explain to it what's going on in your codebase. Although I suspect if you have a lot of accurate comments in your code then it will be able to extract more of that information for itself.
The idea that what's needed is for these alternative platforms to switch to "free with ads" is amazingly short sighted and disheartening. Everything bad YouTube does is driven by this business model. Switching to it might make a few people rich at the top of these alternative platforms, but it won't make anything better for any user or creator.
Race cars have heaps of safety systems not present in road cars. They don't have ABS and traction control because they don't actually increase safety on track with a professional driver. SRS airbags also offer no additional safety when in a 6 point harness and wearing a helmet and neck brace.
The wasted time and money in construction comes entirely from two places: a small percentage of crooked builders (and their local council mates), and the bureaucracy that is trying to protect the citizens from same. Big brother puts in a lot of hoop-jumps standards and supposed checks and balances that end up creating massive delays and costs for the consumer, but the actual standards (while usually quite sensible) are easily sidestepped by the crooked builders, so the war continues, and the overhead constantly increases with the usual expansion-only government regulation ratchet.
None of these things are susceptible to "AI" and other such automation. We have had prefab construction for decades.
I very much enjoy reading and writing TS code. What I don't enjoy is the npm ecosystem (and accompanying mindset), and what I can't stand is trying to configure the damn thing. I've been doing this since TSC was first released, and just the other day I wasted hours trying to make a simple ts-node command line program work with file-extension-free imports and no weird disagreements between the ts-node runner and the language server used by the editor.
And then gave up in disgust.
Look, I'm no genius, not by a long shot. But I am both competent and experienced. If I can't make these things work just by messing with it and googling around, it's too damned hard.
They complain that Go is too low-level for their needs. Zig, with its explicit allocators, is definitely even lower-level.
Rust seems low-level too, but it isn't the same. It allows building powerful high-level interfaces that hide the complexity from you. E.g., RAII eliminates the need for explicit `defer` that can be forgotten
True, but I think the "low-level" complaint against Go in the article was just referring to all the stupid repetitive ceremony required for error handling, which Zig mostly skips over.
However errors do not seem to commonly wrapped, tagged or contextualized as is the case in Rust. This might weight lower verbosity as more important than extremely structured error handling which definitely constitutes an interesting approach.
