3 ms·

It's curious how people associated with the Rust project will vocally complain about unfair/shallow criticism then turn around and post something like this.

tln 6y ago
Out of curiosity, how is this unfair/shallow? It's not obvious to me
- platinumrad 6y ago
  Given the domains where Go is most likely to be used, any comparison of goroutines vs threads should include the netpoller vs blocking socket i/o.
  - derefr 6y ago
    Why would using threads imply using [thread-]blocking socket IO? Most HLL runtimes (that you’d ever want to use for writing a server) have some async IO completion mechanism using scheduler-reserved “async IO waiter” threads, exactly akin to netpoll. (Or they plug into the OS in a less-portable way that avoids blocking IO syscalls to begin with, like Node’s libuv.) Or, if the language’s runtime doesn’t do it for you, then the popular connection-pooling abstractions that the language’s server libraries are built on top of do it for you, by spawning their own AIO completion threads. Jetty’s worker pool in Java, Tokio in Rust, etc. Honestly, who’s out there writing code in 2021 where there are worker POSIX threads, and those threads are (directly or indirectly) calling read(2)?
    - matklad 6y ago
      I do :) I don’t write web services, so I have low O(1) things to communicate with, for which threads with blocking read work OK. They are not perfect, as there is no cancellation, but working around lack of cancellation in a couple of places is less costly than bringing dependency on a relatively fresh Rust async ecosystem.
    - platinumrad 6y ago
      Threads and blocking calls is the programming model exposed by Go and the fact that it can do this efficiently is the few notable accomplishments of an otherwise unremarkable language. Many people find threads and blocking calls to be much easier to reason about than the async model of, for example, libuv.
      - derefr 6y ago
        Well, I mean, you can eat your cake and have it too (i.e. have a language without the non-determinism of preemptively-scheduled green threads, while still having “blocking” call semantics.) .NET Orleans, for example: technically cooperative-scheduled tasks/fibers, but where yield points (i.e. generated state-machine transition points) are decided at compile-time; and where the inability to place such a yield-point within a soft-real-time-bounded distance from the previous one is a compile-time error. You don’t have to place the yield points yourself (like explicit async code), but they’re right there to see when you debug or disassemble the program, and you can use pragmas to adjust where or if they’re placed. Technically the Erlang runtime is this way as well (cooperatively-scheduled, with “explicit” yield points) but since one of those explicit yield-points is use of the CALL or RET ops—and since there are no looping ops, only tail-CALLs—it’s kind of hard to write an explicit atomic-CPU-blocking hard-realtime task-segment in Erlang. (You can, but you have to unroll all your loops. Which Erlang has no tooling support for. Much easier to just push the problem to C through a NIF. At least the Erlang scheduler has explicit design support for these long-running blocking NIF operations through “dirty schedulers”, so it’s not like you’re breaking the runtime’s operational tolerances by trying to do hard-realtime things in it.)
  - matklad 6y ago
    I don’t think every benchmark should be a benchmark of everything. Targeted micro benchmarks are valuable, if they are explicit about their applicability scope. The post is very direct about looking only at the memory usage, and literally says that using the results to reason about overall performance would be wrong. I see how the article could be read as “goroutines bad, threads good”, as it doesn’t go to extraordinary lengths to prevent that. But I prefer to cater to a careful reader, and not add loud disclaimers repeatedly.
    - platinumrad 6y ago
      Yes, I think I read a little too much into your piece. I had on my mind at the time a certain prominent former Rust contributor's repeated bashing of M:N threading as well as the silly firestorm that erupted from that (admittedly not great) recent blog post critical of async Rust.
geodel 6y ago
Exactly!. Just few days there was criticism of Rust's async story. Now it could be most likely wrong on some technical details, but Rust folks took it so personally and called it an attack on folks to who developed async system for Rust. This time and again shows they really hate any criticism which is not approved by Rust cultists.
- dang 6y ago
  Please don't post flamewar comments to HN. It's not what this site is for. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
dang 6y ago
Please don't post in the flamewar style to HN. It leads to flamewars, which are predictable, nasty, and dumb. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
deleted 6y ago
[deleted]

tln 6y ago

Out of curiosity, how is this unfair/shallow? It's not obvious to me

platinumrad 6y ago
Given the domains where Go is most likely to be used, any comparison of goroutines vs threads should include the netpoller vs blocking socket i/o.
- derefr 6y ago
  Why would using threads imply using [thread-]blocking socket IO? Most HLL runtimes (that you’d ever want to use for writing a server) have some async IO completion mechanism using scheduler-reserved “async IO waiter” threads, exactly akin to netpoll. (Or they plug into the OS in a less-portable way that avoids blocking IO syscalls to begin with, like Node’s libuv.) Or, if the language’s runtime doesn’t do it for you, then the popular connection-pooling abstractions that the language’s server libraries are built on top of do it for you, by spawning their own AIO completion threads. Jetty’s worker pool in Java, Tokio in Rust, etc. Honestly, who’s out there writing code in 2021 where there are worker POSIX threads, and those threads are (directly or indirectly) calling read(2)?
  - matklad 6y ago
    I do :) I don’t write web services, so I have low O(1) things to communicate with, for which threads with blocking read work OK. They are not perfect, as there is no cancellation, but working around lack of cancellation in a couple of places is less costly than bringing dependency on a relatively fresh Rust async ecosystem.
  - platinumrad 6y ago
    Threads and blocking calls is the programming model exposed by Go and the fact that it can do this efficiently is the few notable accomplishments of an otherwise unremarkable language. Many people find threads and blocking calls to be much easier to reason about than the async model of, for example, libuv.
    - derefr 6y ago
      Well, I mean, you can eat your cake and have it too (i.e. have a language without the non-determinism of preemptively-scheduled green threads, while still having “blocking” call semantics.) .NET Orleans, for example: technically cooperative-scheduled tasks/fibers, but where yield points (i.e. generated state-machine transition points) are decided at compile-time; and where the inability to place such a yield-point within a soft-real-time-bounded distance from the previous one is a compile-time error. You don’t have to place the yield points yourself (like explicit async code), but they’re right there to see when you debug or disassemble the program, and you can use pragmas to adjust where or if they’re placed. Technically the Erlang runtime is this way as well (cooperatively-scheduled, with “explicit” yield points) but since one of those explicit yield-points is use of the CALL or RET ops—and since there are no looping ops, only tail-CALLs—it’s kind of hard to write an explicit atomic-CPU-blocking hard-realtime task-segment in Erlang. (You can, but you have to unroll all your loops. Which Erlang has no tooling support for. Much easier to just push the problem to C through a NIF. At least the Erlang scheduler has explicit design support for these long-running blocking NIF operations through “dirty schedulers”, so it’s not like you’re breaking the runtime’s operational tolerances by trying to do hard-realtime things in it.)
- matklad 6y ago
  I don’t think every benchmark should be a benchmark of everything. Targeted micro benchmarks are valuable, if they are explicit about their applicability scope. The post is very direct about looking only at the memory usage, and literally says that using the results to reason about overall performance would be wrong. I see how the article could be read as “goroutines bad, threads good”, as it doesn’t go to extraordinary lengths to prevent that. But I prefer to cater to a careful reader, and not add loud disclaimers repeatedly.
  - platinumrad 6y ago
    Yes, I think I read a little too much into your piece. I had on my mind at the time a certain prominent former Rust contributor's repeated bashing of M:N threading as well as the silly firestorm that erupted from that (admittedly not great) recent blog post critical of async Rust.

geodel 6y ago

Exactly!. Just few days there was criticism of Rust's async story. Now it could be most likely wrong on some technical details, but Rust folks took it so personally and called it an attack on folks to who developed async system for Rust. This time and again shows they really hate any criticism which is not approved by Rust cultists.

dang 6y ago
Please don't post flamewar comments to HN. It's not what this site is for. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

dang 6y ago

Please don't post in the flamewar style to HN. It leads to flamewars, which are predictable, nasty, and dumb. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

deleted 6y ago

[deleted]