4 ms·

Go's concurrency story isn't great compared to other languages tbh. Combining channels, wait groups and mutexes (because sometimes you do need to use all three

Go's concurrency story isn't great compared to other languages tbh. Combining channels, wait groups and mutexes (because sometimes you do need to use all three or mix/match) leads to confusion on when exactly to use what, when.

tptacek 5y ago
It's more or less the same as the story with Tokio programs in Rust; they just spell the word "channel" differently.
- Matthias247 5y ago
  Yes. And if the metric is "confusion when to use what" then Rust (and especially async Rust) might fare even worse: Now there's multiple types of Mutexes, Semaphores, Channels: Awaitable ones and not awaitable ones. And one needs to understand how they fit into programs, and interact with all the other stuff. Most people which just pick an async Rust runtime because they read it's a great thing are having a rather hard time with this.
  - kaba0 5y ago
    I just so don’t get the comparison of a high level language like Go to a goddamn system programming language like Rust. They are nowhere in the same league. Rust’s solution has to account for the true variability and complexity of the underlying platform, as otherwise it would be a bad low level language, while go can/could easily hide it behind a supposedly clever abstraction.
    - tptacek 5y ago
      I don't understand this weird, embarrassing subset of Rust programmers who talk as if they're working for the first time with manual memory allocation and it's a revelation that somehow sets the language apart from all others. In fact, the overlap between problem domains for Go and Rust is immense. There is no language that has done more to halt and roll back the progression of memory-unsafe C/C++ than Go, which is, in fact, a systems programming language --- a term that does not in fact mean "usable in the Linux kernel" (a definition that would also have excluded C++ at times). They are eminently comparable languages. Go gets some stuff very right, and so does Rust.
      - kaba0 5y ago
        Then you can just as well expand the definition of systems programming languages to JS, Java and Python.. sure, don’t get me wrong, there are very very few niches where a managed language can’t be applied (a whole OS can be written in GCd languages) but there is a few and in these cases Go is simply a no-go (sorry for the pun).
        tptacek 5y ago
        Java, yes: I have worked on systems, as have others on HN I'm sure, where Java is the bottom level language: there's a JVM, and below that there's hardware, and that's the whole story. JS and Python, not so much. This isn't complicated: there is a general agreement about what "systems programming" is, and the only people who make a huge deal out of the divide between managed languages and unmanaged languages are, again, this weird embarrassing (tiny!) subset of Rust people. I think the Rust core team people must wince about these arguments. It's not as if Java and Go programmers don't understand the value of "zero-cost abstractions" (a term from the same 1990s vintage as the first version of Java) and manual memory management. I don't see a lot of serious energy being applied to getting Go running in the Linux kernel. To my eyes, the only people who really seem uncertain about Rust's value are the "those aren't systems programming languages!" people. Rust is not good because we finally have a language to do systems programming in; it's good because it's a good, interesting language on its own merits.
        tptacek 4y ago
        Just by way of example: pay attention to how Niko Matsakis answers the first question ("what is systems programming") on this panel with Bjarne and Alexandrescu and Rob Pike: https://video.ch9.ms/ch9/6596/ed57ccc9-2cbb-42b0-b4f0-70909f486596/LangNext2014PanelSystemsProgramming.mp4 https://video.ch9.ms/ch9/6596/ed57ccc9-2cbb-42b0-b4f0-70909f... (It's hard for me to disagree with any of them, except maybe that I don't at all agree with Alexandescu's argument that systems programming is defined in part by being able to forge pointers from integers --- something, of course, that you can do in both Go and Rust [unfortunately]).
Karrot_Kream 5y ago
I always find myself reaching for the same constructs in other languages. In Rust I go with crossbeam channels and use mutexes or RwLocks when I don't need the channel synchronization overhead.

tptacek 5y ago

It's more or less the same as the story with Tokio programs in Rust; they just spell the word "channel" differently.

Matthias247 5y ago
Yes. And if the metric is "confusion when to use what" then Rust (and especially async Rust) might fare even worse: Now there's multiple types of Mutexes, Semaphores, Channels: Awaitable ones and not awaitable ones. And one needs to understand how they fit into programs, and interact with all the other stuff. Most people which just pick an async Rust runtime because they read it's a great thing are having a rather hard time with this.
- kaba0 5y ago
  I just so don’t get the comparison of a high level language like Go to a goddamn system programming language like Rust. They are nowhere in the same league. Rust’s solution has to account for the true variability and complexity of the underlying platform, as otherwise it would be a bad low level language, while go can/could easily hide it behind a supposedly clever abstraction.
  - tptacek 5y ago
    I don't understand this weird, embarrassing subset of Rust programmers who talk as if they're working for the first time with manual memory allocation and it's a revelation that somehow sets the language apart from all others. In fact, the overlap between problem domains for Go and Rust is immense. There is no language that has done more to halt and roll back the progression of memory-unsafe C/C++ than Go, which is, in fact, a systems programming language --- a term that does not in fact mean "usable in the Linux kernel" (a definition that would also have excluded C++ at times). They are eminently comparable languages. Go gets some stuff very right, and so does Rust.
    - kaba0 5y ago
      Then you can just as well expand the definition of systems programming languages to JS, Java and Python.. sure, don’t get me wrong, there are very very few niches where a managed language can’t be applied (a whole OS can be written in GCd languages) but there is a few and in these cases Go is simply a no-go (sorry for the pun).
      - tptacek 5y ago
        Java, yes: I have worked on systems, as have others on HN I'm sure, where Java is the bottom level language: there's a JVM, and below that there's hardware, and that's the whole story. JS and Python, not so much. This isn't complicated: there is a general agreement about what "systems programming" is, and the only people who make a huge deal out of the divide between managed languages and unmanaged languages are, again, this weird embarrassing (tiny!) subset of Rust people. I think the Rust core team people must wince about these arguments. It's not as if Java and Go programmers don't understand the value of "zero-cost abstractions" (a term from the same 1990s vintage as the first version of Java) and manual memory management. I don't see a lot of serious energy being applied to getting Go running in the Linux kernel. To my eyes, the only people who really seem uncertain about Rust's value are the "those aren't systems programming languages!" people. Rust is not good because we finally have a language to do systems programming in; it's good because it's a good, interesting language on its own merits.
        tptacek 4y ago
        Just by way of example: pay attention to how Niko Matsakis answers the first question ("what is systems programming") on this panel with Bjarne and Alexandrescu and Rob Pike: https://video.ch9.ms/ch9/6596/ed57ccc9-2cbb-42b0-b4f0-70909f486596/LangNext2014PanelSystemsProgramming.mp4 https://video.ch9.ms/ch9/6596/ed57ccc9-2cbb-42b0-b4f0-70909f... (It's hard for me to disagree with any of them, except maybe that I don't at all agree with Alexandescu's argument that systems programming is defined in part by being able to forge pointers from integers --- something, of course, that you can do in both Go and Rust [unfortunately]).

Karrot_Kream 5y ago

I always find myself reaching for the same constructs in other languages. In Rust I go with crossbeam channels and use mutexes or RwLocks when I don't need the channel synchronization overhead.