Monomorphisation is the name of the technique of producing a different version of the code for each set of type parameters that are used in the program. C++ and Rust use monomorphisation instead of doing runtime checks because they're trading off slightly bigger binaries for greater speed.
By not doing runtime checks you get to skip that work at runtime, obviously, but you also get to enable other optimizations like inlining the monomorphised version.
My first thought was Lumosity [1]. I'd love for these claims to be real, but I'm just not willing to believe claims like these until I see a significant result in a randomized controlled trial.
Professional ethics of software engineering is definitely something we're going to have to grapple with more and more. Another aspect is being asked to use Dark Patterns in a UI or build a skinner box into a game or app. There's evidence that these things do harm to people and having a professional organization that could help stand up to such things could be part of a solution.
The way I remember it: the product was still overwhelmingly better than everything else. Missing copy&paste was an "oh well" compared to owning an iPhone in 2007.
I would define the term "high-level language" to mean that it's possible to write programs in the language without needing to worry about the specific hardware that the program is running on.
I would consider systems programming to be things like writing operating systems, drivers, high-performance native applications (for many difference definitions of high-performance), and databases.
I consider rust to be a high-level language and I further consider it to be suitable for systems programming using my definitions.
However, I don't consider go to be suitable for a lot of systems programming tasks because it has a significant runtime system that includes a garbage collector. Just because they describe themselves as a "systems programming language" doesn't mean that I believe them (at least as far as I understand that term). That said, there are certain applications that work fine with GC, and in those cases it can be a very nice way to achieve memory safety without programmer burden.
Granular permissions have only been in iOS since version 6.0, which came out 3 years ago. The first version of iOS was 8 years ago. For a feature that's "as common sense as it gets" we sure got along fine without it for half a decade.
You should become skeptical of languages that compile to C. I can't get into the details because I don't know them very well, but take a look a pcwalton's comment history for a fairly technical discussion of why it makes a poor compilation target.
Why? Because their applicant pool is too small? Or because the cost of doing that many interviews is so steep? Or something else?
I intuitively had the exact opposite reaction: most companies can't afford to hire any bad people, but large companies with lots of resources actually can. If google's rate of poor hiring was higher than average, they'd still survive, at least in the short term, because they're so large and profitable.
Wifi is not too slow for RAWs. I backed-up my entire library to the cloud over wifi. I would bet most people don't need to transfer their files on a fast enough timescale that wifi is too slow for them.