4 ms·

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

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.

deleted 7y ago
[deleted]
yobert 7y ago
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!
- _frkl 7y ago
  Totally agree, I also enjoy her posts quite a bit!
- spectramax 7y ago
  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 7y ago
    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.
- cgriswald 7y ago
  Sarcasm isn’t difficult, interesting, or particularly creative. I found this particular post very off-putting and not-at-all considerate of my time.
- pdpi 7y ago
  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.
  - notyourday 7y ago
    Wisdom is always off-putting at the first glance. That's what makes it wisdom
    - mrmonkeyman 7y ago
      That's not even wrong.
  - chillingeffect 7y ago
    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 7y ago
      > 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.
- ljm 7y ago
  I think she does The Daily WTF better than The Daily WTF sometimes.
DevKoala 7y ago
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 7y ago
  She linked none of that literature, and neither did you.
  - kragen 7y ago
    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 7y ago
      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 7y ago
        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-cascading-failures/ 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.
  - DevKoala 7y ago
    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-types-of-worker-in-gunicorn-and-respective-suitable-scenario-67b0c0e7bd62 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.

deleted 7y ago

[deleted]

yobert 7y ago

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!

_frkl 7y ago
Totally agree, I also enjoy her posts quite a bit!
spectramax 7y ago
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 7y ago
  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.
cgriswald 7y ago
Sarcasm isn’t difficult, interesting, or particularly creative. I found this particular post very off-putting and not-at-all considerate of my time.
pdpi 7y ago
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.
- notyourday 7y ago
  Wisdom is always off-putting at the first glance. That's what makes it wisdom
  - mrmonkeyman 7y ago
    That's not even wrong.
- chillingeffect 7y ago
  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 7y ago
    > 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.
ljm 7y ago
I think she does The Daily WTF better than The Daily WTF sometimes.

DevKoala 7y ago

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 7y ago
She linked none of that literature, and neither did you.
- kragen 7y ago
  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 7y ago
    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 7y ago
      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-cascading-failures/ 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.
- DevKoala 7y ago
  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-types-of-worker-in-gunicorn-and-respective-suitable-scenario-67b0c0e7bd62 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.