> Apple takes QA very seriously and invests in high quality QA engineers
Willing to bet this is worth 80% of the value to the task, especially if your QA testers can write enough code to have good instincts about why something might break & control for a test environment / create novel test situations.
From my personal experience: system languages are really, really good at interacting with operating systems. When you have things deployed on a server that machine generally has one task, and it makes sense to optimize as many layers as possible. For example on a windows system I used MS's `FILE_FLAG_SEQUENTIAL_SCAN` flag to triple read performance; you could of course do the same in python by dipping into ctypes but it doesn't make for a pleasant development experience.
The big trade-off is you're specifying the task more precisely and as a result of that extra labor you get better performance for the life of the tool. SQLITE has a good story of putting together dozens of small optimizations, each <1% performance change, and at the end the library's throughput doubled in pretty much all tests. It's not worth it for research, but it is everywhere else.
My favorite variant of this is copyright issuance costs double/multiply by some X>1.0 every year after some N years of a flat rate. If your product is actually amazingly profitable you'll have the money to keep the copyright longer than most people, but eventually the costs will catch up with you. Unless you've invented a product that can double in price every year, guaranteed.
Mozilla has to make statistical assumptions about their users, and statistically any random person's DNS will be set to resolve using their ISP. Mozilla may see this as predatory (ISPs in general are not exactly great companies who care for their customers), and so from their perspective comparing "Average DNS use" to "We vetted a company & trust them & we feel good making this decision for our users" sounds worth doing. There may be some latent assumptions about "well power users will just turn this off like they do everything we build" which would also support the action taken.
With that defense in mind, it's still a shitty thing to do to your users. I don't like it, but 99% of the world doesn't even understand what the change means.
Lame but powerful option: `tail -f /logfile.log | grep -A10 -B10 <interesting thing>`. (prints 10 lines before & after search lines). The most powerful feature I've had in log management is the ability to search for what was interesting, and no tool can provide you a "this is interesting" button. If you've got performance concerns ripgrep is a drop-in grep replacement that's very fast.
JNI is the only escape hatch in the JRE. JNA leverages JNI and so has a better API while still keeping the terrible performance. This is like JNA, but more robust, and while also being an escape hatch of its own so that you can finally get performance similar to P/Invoke when making native calls.
This is apparently focused on efficiently accessing off-heap memory. In Jni lot of things require copies. Only JNI API that's reliably copy-free is ByteBuffer API.
Willing to bet this is worth 80% of the value to the task, especially if your QA testers can write enough code to have good instincts about why something might break & control for a test environment / create novel test situations.