It’s an interesting post to read. Have another go if you can, but I very much agree with you on the tone issue. Imagine if these were ones own notes that had to be read through the next time something like this happened. A more succinct operational — dare I say: positive! — way of writing would really be welcome.
There is a lot of literature on the subject if you want more pragmatic notes. You read Rachel’s blog not only for the tech experience, but for her storytelling skills.
I particularly enjoy her blog.
The problem is that a solution for I/O bound workloads has become generalized as the solution for all concurrency needs when in reality, that’s just half the picture.
She mentioned a hell of a lot of googlable terms: epoll_wait, Apache thundering herd, EPOLLONESHOT, EAGAIN, idempotent requests, userspace threads, copy-on-write, queue depth determination, selective LIFO, strongly typed RPC, ...
Presumably “queue depth determination”, another new term for me, means determining how big the queue of pending requests for a service is allowed to get before further requests are refused (another load shedding measure) rather than being enqueued.
I would counter-argue that dry, positive, informational writing is great for Wikipedia but can also be very boring. This blog has a lot of snark and that's what makes digesting the great information so much fun!
There's a middle term, and you can avoid dryness with tones other than condescension. While I always read Rachel's posts whenever they come up because they're jam packed with wisdom, I always find them a bit off-putting.
if i could put a point on it, it would be the implied entitlement and absence of gratitude. Sure, this architecture is not 100% efficient. But step back for a moment, take a breath and consider the number of human-hours spent to get it where it is today. Consider how many people are busting their humps, many volunteers, to keep improving it. We arw not _owed_ any of this. Just the miracle of elastic server config and multicore processors... Buying into the pessimistic viewpoint is dangerous: When these issues get improved, will we feel grateful and adequate? or will we find new flaws and get snarky about them?
Anyway, what i do really like abt this post is it shows the chain of technical details across the call chain. it connects together info on dozens of man pages, etc. I also appreciate how it points out the inefficiency is quite convenient for service providers.
> Consider how many people are busting their humps, many volunteers, to keep improving it.
I think criticism about gratitude is strange when the author is pretty clearly coming from the standpoint that it was a bad idea to use this in the first place (and, to be fair and with regards to Python specifically, I tend towards that standpoint myself) that labor begins to look like it's being set on fire. No Purple Hearts for self-inflicted wounds and all that.
For the downvoters - I also do not like Paul Graham and Sam Altman - they're the same as Rachel in every way. Little substance, lots of unsubstantiated filler material.
To extend this further, I also don't like NewYorker for this reason alone - I don't have time for convoluted novel-like stories that has the important bit buried somewhere in the middle of 6 pages. If I want to read beautiful and creative prose, I need to be in that mindset. Not when discussing Python innards.
