4 ms·

> I prefer multi threaded programming Then you had sheltered and privileged career which I am finding out applies to a lot of folks on HN, apparently. So hold

> I prefer multi threaded programming Then you had sheltered and privileged career which I am finding out applies to a lot of folks on HN, apparently. So hold on to your cushy job because if you leave it you might find out the world has moved on long ago. Especially Rust's async/await are instrumental to services that literally saturate their network link and would go higher if the link allowed more bandwidth. Normal multi-threaded code is folding under pressure somewhere at the 50_000 requests / sec mark on an average small-ish VPS. In the meantime the async/await code is saturating a 10GbE link. Both Golang and Rust didn't make the perfect design choices though -- that much is true, sadly. But they are a big improvement over the status quo. I'll grant you that Golang replaced one class of problems with another -- something I dislike as well. Wish it was stricter but it's good enough for 95% of all projects everywhere, if we have to be brutally honest with ourselves.

roguecoder 3y ago
Most of the world shouldn't be writing services that saturate their network links (actually, no one should: if you don't have slack in the system, it becomes incredibly error-prone. But even running at 80% saturation, most people shouldn't be writing those services.) There are a small number of very large companies where their architecture is based on that sort of thing. But in most cases in most places the right approach in that situation is to ask, "why is this a thing you think you need?" And then to either inline the service or employ horizontal scaling strategies instead of trying to stuff more cycles onto one network card. I do agree that these language choices are very likely a symptom of the misuse of service architectures. People are treating services like objects (or worse, Singletons) that live on a different machine, relying on the network stack as their interpreter. It makes "modern" software buggy and fragile. Neither of these languages solve that problem, but they do capitalize on it.
- pdimitar 3y ago
  > Most of the world shouldn't be writing services that saturate their network links Very strange hill to die on, and feels like a side attack towards a point that you chose to ignore: namely that classic multi-threading is fragile and does not scale well. Doing the async/await thing is objectively better. I get why people don't want to admit that they invested so much in something and are grumpy that this skill is now not as needed -- I was one of them in fact, I am coming from C pthreads and Java after -- but being a curmudgeon and trying to do a torpedo attack on a discussion about multi-threading vs. async/await is something that I can't endorse. > "why is this a thing you think you need?" And then to either inline the service or employ horizontal scaling strategies instead of trying to stuff more cycles onto one network card. Very often false, having stuff being only on one machine with 1-2 hot backups and a load balancer is the lowest maintenance I've done on systems for all of my 22 years of career. Feel free to disagree but (1) most programmers will never work on the scale of AWS and Facebook and (2) horizontal scaling / distribution comes with many, many new failure modes. KISS is an art that is being forgotten, it seems.
  - iforgotpassword 3y ago
    On that note, I'd argue KISS is the multi-threaded approach. I'm maintaining a server software that is multi-threaded with plain old blocking I/O and it easily saturates a 10GBit/s link without breaking a sweat on quad-core CPUs from a decade ago.
    - pdimitar 3y ago
      I guess it really depends. In all my practice with C pthreads and Java threads, this code always spiraled to unholy messes due to constantly adding to requirements.
      - iforgotpassword 3y ago
        Yes, as an example, if you look at something like PostgreSQL or MySQL the code is absolutely intimidating because they use crazy data structures and synchronization techniques to squeeze out another nanosecond under heavy load. But I couldn't tell if async/await would make this any better while still delivering similar performance.

roguecoder 3y ago

Most of the world shouldn't be writing services that saturate their network links (actually, no one should: if you don't have slack in the system, it becomes incredibly error-prone. But even running at 80% saturation, most people shouldn't be writing those services.) There are a small number of very large companies where their architecture is based on that sort of thing. But in most cases in most places the right approach in that situation is to ask, "why is this a thing you think you need?" And then to either inline the service or employ horizontal scaling strategies instead of trying to stuff more cycles onto one network card. I do agree that these language choices are very likely a symptom of the misuse of service architectures. People are treating services like objects (or worse, Singletons) that live on a different machine, relying on the network stack as their interpreter. It makes "modern" software buggy and fragile. Neither of these languages solve that problem, but they do capitalize on it.

pdimitar 3y ago
> Most of the world shouldn't be writing services that saturate their network links Very strange hill to die on, and feels like a side attack towards a point that you chose to ignore: namely that classic multi-threading is fragile and does not scale well. Doing the async/await thing is objectively better. I get why people don't want to admit that they invested so much in something and are grumpy that this skill is now not as needed -- I was one of them in fact, I am coming from C pthreads and Java after -- but being a curmudgeon and trying to do a torpedo attack on a discussion about multi-threading vs. async/await is something that I can't endorse. > "why is this a thing you think you need?" And then to either inline the service or employ horizontal scaling strategies instead of trying to stuff more cycles onto one network card. Very often false, having stuff being only on one machine with 1-2 hot backups and a load balancer is the lowest maintenance I've done on systems for all of my 22 years of career. Feel free to disagree but (1) most programmers will never work on the scale of AWS and Facebook and (2) horizontal scaling / distribution comes with many, many new failure modes. KISS is an art that is being forgotten, it seems.
- iforgotpassword 3y ago
  On that note, I'd argue KISS is the multi-threaded approach. I'm maintaining a server software that is multi-threaded with plain old blocking I/O and it easily saturates a 10GBit/s link without breaking a sweat on quad-core CPUs from a decade ago.
  - pdimitar 3y ago
    I guess it really depends. In all my practice with C pthreads and Java threads, this code always spiraled to unholy messes due to constantly adding to requirements.
    - iforgotpassword 3y ago
      Yes, as an example, if you look at something like PostgreSQL or MySQL the code is absolutely intimidating because they use crazy data structures and synchronization techniques to squeeze out another nanosecond under heavy load. But I couldn't tell if async/await would make this any better while still delivering similar performance.