Well before LLMs, I already ditched ORMs. What sometimes holds back SQL is not having a convenient way to call it. Statically-typed languages require you to manually set result types unless you use a compile-time query builder, but that's a whole can of worms. Besides that, many client libs aren't so convenient out of the box, so you still need a few of your own helpers.
Also, before jsonb existed, you'd often run into big blobs of properties you don't care to split up into tables. Now it takes some discipline to avoid shoving things into jsonb that shouldn't be.
It seems pretty optional in the US at least. My phone has been broken for extended periods of time before. But different story trying to use budget European airlines like Wizz that require an app to get a boarding pass.
It's also very much optional in Russia as well. Everywhere still takes cash, everything can be done on paper. And speaking of air travel, most airports actually require a printed boarding pass. IIRC you can use an electronic boarding pass in SVO since relatively recently, but I've never done that myself.
Ryanair FAQ may be out of date then. I have a Ryanair flight booked. In the portal, it says "You must download the Ryanair App. This is the only way to access your digital boarding pass, paper boarding passes are no longer issued or accepted."
The 2/3 marketshare must be almost entirely due to Android being cheap and accessible, not because those people need to install arbitrary software. A lot of mobile plans don't even give you GB/mo, they give WhatsApp messages/mo.
It also only solves that very specific problem. You don't need to side-load an app to scam someone. There's plenty of malware on the play store you can use. And, you don't need malware. There's plenty of legitimate apps you can use for scamming.
And, you don't need an app, I would imagine most scamming is done without an app.
So, really, we're solving a subset of a subset of a subset of a subset of the problem.
yes. Hence, "this isn't about keeping people safe".
The most effective means of hacking is social engineering. You can't solve that with any number of "security measures". If you require all the DNA sources in the world, a scammer will still charm a target into opening it up for them.
Is this even the reason? If Android phonemakers are simply concerned about tech-illiterate users switching to iPhone, they could sell a locked-down Android phone that requires some know-how to unlock.
I don't think Anthropic has a problem with you using a regular pay-per-token API key with opencode. The issue is letting someone use their "Log in with Claude" as if it were a regular API key.
> The big benefit is that you get concurrency without the overhead of multi-process.
Bigger thing imo is that multiprocessing is just really annoying. In/out has to be pickleable, anything global gets rerun in each worker which often requires code restructuring, it doesn't work with certain frameworks, and other weird stuff happens with it.
Go use cases overlap the most with Java. I think the reputation you mentioned comes from Google using a lot of C++ for high-level things others would likely do in Java, so they see Go as a replacement for C++ in some areas. (assuming you meant C++ not C)
It's replete with oddities and limitations that signal "ah, this is because systems language."
Go’s type system, for example, is very much a systems-language artifact. The designers chose structural typing because it was lighter weight, but provided enough type safety to get by. It sucks though for enterprise app development where your team (and your tooling) are desperate for nominal typing clarity and determinism.
The error handling is like a systems language for sure, I'll agree on that.
But where do Go's docs or founders call it a C replacement? gf000 asked where this is mentioned besides marketing, but I don't see it in the marketing either.
Thanks. I'm not surprised they called it a C++ competitor back then. All those systems-style features do make it awkward now that it's targeting the Java-like use cases. No pointer arithmetic, but pointers yeah, and it's not very clear what you're supposed to pass by value vs by ref. You can do things like a DBMS in Go that count as systems programming, but for sure it's not a competitor with C.
Go happened to be attractive for web backends too because it had good greenthreading before Java etc did, and better performance than JS, so it makes sense that they changed the marketing.
Go's runtime is thin: goroutines, a GC specialized for concurrency, networking, and little else. Java, by contrast, assumes a JVM plus massive stdlibs to handle everything from enterprise apps to big-data, making its platform genuinely "fat" and layered. Other Java-tier languages, C# included, follow the same model.
I agree Go's runtime is as thin as runtimes get. But having a runtime at all disqualifies it from being a C replacement. Rust is trying to replace C, Go is trying to replace Java and some of C++.
Pure Python code always needed mutexes for thread safety with or without ol' GIL. I thought the difficulty with removing the GIL instead had to do with C extensions that rely on it.
This is accurate and the parent commenter here seems to be echoing a common misconception. Either they are confused or they need to elaborate more to demonstrate that they have a valid complaint.
For instance, this would have been a valid complaint:
"Users who don't need free threading will now suffer a performance penalty for their single-threaded code."
That is true. But if you are currently using multiple threads, code that was correct before will still be correct in the free threaded build, and code that was incorrect before will still be incorrect.
I got it wrong too, even after reading the docs, until I just tried it for myself. Intuitively, why would Python have threads that can't run fully in parallel but also create race conditions? Seems like the worst of both worlds, and it almost is, except you can still speed up io-bound or even GIL-releasing CPU-bound C calls this way.
Some also mix it up with async JS which also can't use multiple CPUs and guarantees in-order execution until you "await" something. Well now that's asyncio in Python. Doesn't help that so much literature uses muddy terms like "async programming."
Also, before jsonb existed, you'd often run into big blobs of properties you don't care to split up into tables. Now it takes some discipline to avoid shoving things into jsonb that shouldn't be.
reply