throwawayninja

> 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.

And this is why my code is GPLv2 and nothing more, I even remove the auto-upgrade clause the FSF wants everyone using v2 to include.

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.

ADA is also very hot in those markets

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 => "I write C code & after compilation java can access it as com.package.ClassName"

JNA => "I write java code & load libsomething at runtime, asking for FuncName(int, int) which java can then call into native code."

You want JNA for your use case.

Nope, never. I run Arch Linux with projects under nspawn containers, the only AV tool I keep around is ClamAV so when coworkers have USB drives I can slap `clamscan /mnt/auto-sda1` and let them know if it's clean.

I love this! computer science is all about abstractions and guarantees, and it's great to have an option for more control. One thought about graceful degradation: would it be easy/possible to build in configuration to "when guarantee cannot be met, only throw an error x% of the time"? This keeps the situational awareness (errors about different query plans) while having an escape hatch: if postgres is updated & the new version decides to never generate good queries, the queries will still happen for some ~95% of users, just slower until the team can read through the new version's instructions to get the plan they need.

If they're escaping, it raises interesting questions about where they might be going / possibly merging? What a strange view of the universe if two particles under pressure could combine and have different attributes (less mass?).

The QA team brings something significant that developers (myself) will never have: their machines closely represent the customers machines. They use a well-polished methodology to push the models we ship to their limits and provide relatively detailed information about how to reproduce failures.

I can't count the number of times I've tested something 5 times, convinced myself that the code handled tons of error cases, shipped it, and in 10 minutes a customer types "five" into a field expecting an integer which causes the next step to use "0" for processing.

Important distinction to make, most people just think "more money means interest" but the mechanics of the two financial instruments differ and this is the entire selling point for these ISAs, and the reason why one may be a good / bad idea in a situation.