[gorgoiler]

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.

[DevKoala]

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.

[CameronNemo]

She linked none of that literature, and neither did you.

[DevKoala]

This might help you, but honestly, if you want literature that will help you arrive at the same conclusions, you should read docs.

https://medium.com/@genchilu/brief-introduction-about-the-ty...

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.

[kragen]

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

[bshanks]

By the way, what is "selective LIFO"? I googled it and couldn't find it. Also, I couldn't find anything on queue depth determination.

[kragen]

It's a new term to me, but I think “selective LIFO” means switching to LIFO scheduling under overload conditions as a load-shedding measure: https://landing.google.com/sre/sre-book/chapters/addressing-...

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.

[yobert]

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!

[pdpi]

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.

[chillingeffect]

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.

[eropple]

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

[notyourday]

Wisdom is always off-putting at the first glance. That's what makes it wisdom

[ljm]

I think she does The Daily WTF better than The Daily WTF sometimes.

[_frkl]

Totally agree, I also enjoy her posts quite a bit!

[cgriswald]

Sarcasm isn’t difficult, interesting, or particularly creative. I found this particular post very off-putting and not-at-all considerate of my time.

[spectramax]

So much fun and so little substance. Fun should be sprinkled here and there with a healthy 95% dose of substance.

Everything Rachel writes is a convoluted mess that’s impossible to follow.

[spectramax]

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.