Richard Barrell's blog
I have a simple theory about why static typing became much less popular in the 2000s to early 2010s and started to get more popular again around the mid to late 2010s. It isn't because programming is a fashion led industry, but because the quality of the static type systems that were widely available improved.
It's really common and unfortunate to see connection pool classes that hide errors and make debugging connection problems much harder.
Let's say, hypothetically, you're running a small company, you sell software on a B2B basis, and you're just starting to really grow the number of customers you have, and they have questions for you.
Imagine we have a complicated program with a logging framework in it which puts messages on a queue. One thread is responsible for taking log messages from the queue and writing them somewhere, such as a logstash instance or local database.
Occasionally, I want to record myself playing a videogame. I use Nvidia's ShadowPlay for this, which sorta got renamed to “GeForce Experience” a while back. I don't currently attempt to stream video because the internet connection I have right now doesn't have enough upstream bandwidth.
I accuse that, in most web applications, we're probably going to end up copying the data that we produce about three times. Herein, by “copy”, I mean “read every byte of response data and then write it all back out again”.
Given that an x86 doesn't touch memory in anything less than 64-byte increments (since that's the cache line size), and that the slow part of a lock cmpxchg8/16b instruction is acquiring exclusive use of the relevant cache line rather than comparing the contents of the source and targets, how come there isn't a lock cmpxchg64b instruction, just to make lock-free algorithms easier?