There are entire categories of scams that exist only thanks to cryptocurrencies. Do you think random people in Western countries would wire money to human traffickers running pig butchering farms in Cambodia without stablecoins? Or to ransomware gangs in Russia without Bitcoin?
Not only they aren't remotely comparable, but there's obviously a huge difference when fraud goes through accounts linked to real identities, since banks and payments systems are legally mandated to deal with KYC and AML regulations.
Where coins are held is completely irrelevant. There are cryptocurrencies on real blockchains, and while the technology is dumb and mostly useless, nobody denies that PoW and properly implemented PoS are decentralized.
And then there are centrally issued and controlled coins on private, permissioned ledgers a.k.a. databases. But most cryptobros never cared about the technology nor the political goal, so anything can be called a cryptocurrency as long as it's a medium for gambling and speculation outside the regulated financial framework.
Native images shouldn't be too messy anymore, Oracle put a lot of effort into DX improvements and all major web frameworks are now aware it's an important and growing use case.
Struggling to build native images should be a sign you're reliant on libraries that are dangerously outdated and abandoned.
They can definitely be pretty messy in some ways; even the standard library doesn't work out of the box perfectly. I have certainly struggled to get image manipulation with java.awt (e.g. thumbnail generation for a fairly standard web use case) to work in a native image.
So it is an antipattern nowadays to manipulate the classpath after building? Iirc native image require static classpath, but it is quite common to inject e.g. environment specific data via the classpath. Should one just read from the filesystem instead, or what’s the strat there?
With the AOT cache, you can actually modify the classpath (or module path as is now used for modern applications) after it has started up. The names and classes for the APIs are different, but you can still load jars at runtime even with the AOT cache enabled and functional.
The AOT cache compatibility issues come when your boot module path differs between training and actual run. As long as that is not the case, you can use it without problem and load additional modules at runtime after it has started up.
With GraalVM, that is not possible. It still has the closed-world assumption.
Most of that monster ecosystem is exactly that: monstrous code in one-off throwaway libraries written by people who don't care about software, as it's not their job.
If you set a bar, any bar, there's really not much offered by Python that you cannot find in a more reasonable language. Especially if you're gluing together C++ and Rust libraries for data processing or ML workloads. Python is still disproportionately popular there but I'm also convinced its days are counted. C++ will be tremendously harder to get rid of, in comparison, if that's even possible.
No they are not? You might be thinking of cheque-style payments (recipient pulls, with proof of the sender's authorisation) versus giro-style payments (sender pushes, with their own authorisation). The latter are obviously much more secure.
Do you pay your groceries with SEPA instant transfers?
Merchants can't just slap a QR code with their banking details on their website or cash registers. Wero offers a convenient layer on top of SEPA transfers, and you can argue EPC QR codes are already enough (though most people would disagree).
Additionally, Wero provides a full payment solution that's integrated with many third party processors, and is basically an evolution of Payconiq and iDEAL. Sure, it does use SEPA rails, but there's a lot more to it. And that's the part that will need to interoperate with more than a dozen mobile wallets in Europe, inside and outside the Eurozone.
That's why it's built on SEPA instant that is written into EU law, requiring 10 second transfer times, and the banks have incentives to support these things (they often own it, but also because it creates lock-in effects of focusing business in one bank).
Yes, this is quite true. Virtual providers are quite easy to set up that way but the amount of KYC for this kind of service is substantial. Even so, these SIMs/eSIMs have turned up in all kinds of bad places such as SIM farms.
It's also more token hungry than similar models, so does it really make a big difference in the end?
With GitHub Copilot pricing, I have found no practical reason to use Gemini 3.8 Flash vs GPT 5.6 Luna. And now I'll probably find no reason to use Gemini 4 when GPT 6.1 Sol is essentially as good and a lot cheaper.
There are entire categories of scams that exist only thanks to cryptocurrencies. Do you think random people in Western countries would wire money to human traffickers running pig butchering farms in Cambodia without stablecoins? Or to ransomware gangs in Russia without Bitcoin?