6 ms·

Even if Goroutines were significantly heavier than threads, I would prefer them for many reasons.

• twic 6y ago
  Such as?
  • adonovan 6y ago
    Faster context switches. Vastly larger recursion depth before stack overflow.
    • twic 6y ago
      How often is recursion depth a constraint on your programming?
  • b0sk 6y ago
    Easier to reason about. easier to communicate. Threads are a low level primitive. the goroutines seemed to be designed with concurrency in mind.
    • monocasa 6y ago
      It's the channels that make goroutines easier to reason about, not the green threads. There's plenty of channel implementations on native threads.
      • dilyevsky 6y ago
        Example of c++ channel library that is easy to use? The only one I’ve seen was packaged with Google’s internal cpp fiber library that depended on custom linux kernel patches.
        • monocasa 6y ago
          I haven't done much actor model programming in C++ in nonproprietary envs so I'm not sure there. But Rust's mpsc package is a good public example of the concept off the top of my head running on native threads. They're really not that complicated and a c++ version would be on the order of a few hundred lines. I had been using the concept since the 90s, as RTOSes really love it. Pretty much every N64 game uses native threads communicating via "software FIFOs".
          • harikb 6y ago
            Rust one you mention is multiple-producer single-consumer. And it is not nearly as feature rich as a channel in Go. By the time one deals with tokio, async/await, passing the (rx,tx) to the right thread with clone()/copy(), the developer would be tired. There is a huge difference in library implementations of channel vs native language support
            • monocasa 6y ago
              You don't need any tokio or async/await to use mpsc. It's in the standard library and works just fine with a thread spawned with a closure to work on. It's split into a read half and a write half so you don't have to worry about copy or clone, as an execution context will only have one or the other. I guess you clone the write half to give it to multiple producers, but that's not a huge deal. The example here for instance doesn't look any more complicated than using go channels, and it's a full executable example you can start by clicking the run button. https://doc.rust-lang.org/std/sync/mpsc/fn.channel.html https://doc.rust-lang.org/std/sync/mpsc/fn.channel.html
            • masklinn 6y ago
              > Rust one you mention is multiple-producer single-consumer. And it is not nearly as feature rich as a channel in Go. By the time one deals with tokio, async/await, passing the (rx,tx) to the right thread with clone()/copy(), the developer would be tired. tokio and async/await have little to do with channels (other than having their own async-aware versions). If you need a real mpmc channel, crossbeam[0] provides one. The interface is similar to the stdlib's, but you can clone the receiver as well as the sender. [0] https://docs.rs/crossbeam/0.8.0/crossbeam/channel/index.html https://docs.rs/crossbeam/0.8.0/crossbeam/channel/index.html
  • pantulis 6y ago
    I'd say that they are easier to write code and to reason about when compared with, say, POSIX threads.
    • twic 6y ago
      How come? How are goroutines different from real threads such that they're easier to reason about?
      • matklad 6y ago
        In theory, they are equivalent. In practice, POSIX blocking IO does create problems around cancellation and selectability. For example, there’s no good way to cancel an outstanding blocking read call, and you might need to do weird hops to work around that. If you do goroutines, you need to redo all IO yourself anyway, and that’s a good opportunity to implement things like universal support for cancellation and timeouts.
  • tmpz22 6y ago
    You're being a massive contrarian right now - asking others for supporting evidence while providing none to support your own position.
    • twic 6y ago
      Believe it or not, it was a genuine question.
      • tmpz22 6y ago
        Right and there's nothing wrong with genuine questions - however each question is asking for the commenters time to satisfy your own curiosity and there is a threshold where asking a bunch of loosely defined open ended questions no longer contributes value to a conversation (because they become rhetorical, unanswerable, or the commenter has moved on and doesn't want to commit to a full answer), etc. In short it gets to a point where it seems like you're only asking questions to prove someone else incorrect or even inferior - versus to actually further a conversation by contributing concrete evidence. This may not have been your intention, or I could be misinterpreting it, but in your shoes I would want someone to tell me they had this impression so I could consider it going forward.