No, database servers solve that problem. That the unnecessarily COBOL-like SQL ended up being the primary interface to them is simply an unfortunate accident of history.
If you want to make ultra-complicated clients, I assume that's what WebAssembly is heading towards. And it doesn't limit you to a poorly evolved language that wasn't intended for ultra-complicated software in the first place, or even force you to use that poorly evolved language on a server if you need to run the same logic in both places.
Jevons' paradox still exists. Making X cheaper (usually by needing fewer people to do one unit of X) can and often does lead to more people being needed for X.
Merchant shipping contributes around 3% to CO₂ emissions. That is smaller than, e.g., electricity and heat generation, road transportation, manufacturing, construction, and agriculture.
Nobody decided that it's a crime, and it's unlikely to happen. Question is, what do you do with mandatory snooping of centralized proprietary services that renders them functionally useless aside from "just live with it". I was hoping for actual advice rather than a snarky non-response, yet here we are.
> Use Signal. Or Wire, or WhatsApp, or some other Signal-protocol-based secure messenger.
That's a "great" idea considering the recent legal developments in the EU, which OpenPGP, as bad as it is, doesn't suffer from. It would be great if the author updated his advice into something more future-proof.
It gives you arbitrarily complex control flow even in presence of modularity. A tail call is a state transition. Without them, you'd have to resort to a big loop (which breaks modularity), or some sort of trampoline (which works but it's a bit clumsy).
There's one obvious potential application, which is caching of common requests. If something like segments of streams or any CDN contents is cached on the satellite, it reduces communication to a single hop for a large portion of traffic (IIRC, 70% or so?). Storage is very lightweight these days and failure to read cached data is not critical, so putting lots of SSDs on a LEO constellation satellite seems like a no-brainer to me if you're trying to optimize bandwidth usage.
You don't HAVE to boot RPi4+ from an SD card. RPi4 and RPi5 can boot from an external SSD just fine. I don't recall the last time I used an SD card in an RPi but it must have been years.
I too need to thank you for the very first C compiler I ever had access to in 1999, after 10 years of having a book on C in my possession that I couldn't use until then.
Yes, but compile-time evaluation in Zig doesn't require the "comptime" keyword. Only specific cases such as compile-time type computation do (but these specific cases are not provided by compile-time function evaluation in D anyway, so language choice wouldn't make a difference here).
I'm pretty sure the "comptime" keyword only forces you to provide an argument constant at compile time for that particular parameter. It doesn't trigger the compile time evaluation.
But Zig doesn't need a keyword to trigger it either? If it's possible at all, it will be done. The keyword should just prevent run-time evaluation. (Unless I grossly misunderstood something.)