4 ms·

This is a nice take on the language; and doesn't descend into the regular lampooning ("lol no generics") that's found on languagey posts. Kudos! > The attitude

This is a nice take on the language; and doesn't descend into the regular lampooning ("lol no generics") that's found on languagey posts. Kudos! > The attitude of the decision making around the language is unfortunate, and I think Go could really take a page from Rust’s book with respect to its governance model. (I wrote part of Rust's current governance model and was a part of polishing it up; though I wasn't so involved when Rust initially started using a consensus based model. I've also tried Go, and written about it [1]) ... I don't know if this would work out so well. One of Go's strengths (also weaknesses, but it is a strength) is that the language designers can afford to just make hard decisions for everyone. This is where the simplicity comes from, IMO. Rust is complicated because it tries to cater to a wide range of needs. Go makes decisions even if they cut out use cases, and the language stays simple. Both approaches are valid; but IMO switching approaches would make Go lose one of its best plus points. [1]: http://www.polyglotweekly.com/2015/04/24/thoughts-of-a-rustacean-learning-go.html http://www.polyglotweekly.com/2015/04/24/thoughts-of-a-rusta...

bsdetector 11y ago
What they are getting at is that the Go designers are stubborn and the Rust designers are open-minded... but they don't want to just come out and say that. For instance both had green threads. Rust designers ran into all the problems with them like interop with anything else and interrupts and fairness, so like everybody else that did M:N threading they threw up their hands and said "well it looked like a good idea at first" and removed it. Go designers literally called it a "rabbit hole" and followed it down to whatever crazy lands it lead to, because they promised people green threads so they had to keep it.
- Manishearth 11y ago
  True. For the record I like the Rust model a lot more (obviously, as a contributor, I should); but what I'm saying is that there's a tradeoff and both have their good parts. The moment you're open to some community decision making, you're expected to be open to all of it -- Go doesn't get much flak from the community for unilateral decisionmaking. I bet it would if it started to allow some community consensus on some decisions. And like I said, the "let the community decide everything" model probably wouldn't work for Go, so unilateral it is :)
- NateDad 11y ago
  That's very sad for Rust, because Go's goroutines are amazingly awesome.
  - pcwalton 11y ago
    I firmly believe that moving away from M:N threading was the right decision for Rust. Even if nothing else, the fact that Rust FFI performance is thousands of times faster than cgo alone justifies the decision. There are numerous other reasons (fairness, I/O performance, performance of synchronization primitives, implementation complexity) why just using the OS scheduling is superior for a systems language. The primary benefit of M:N scheduling—fast thread spawning due to small initial stack sizes—requires GC, which Rust doesn't have, and arguably has little to do with M:N scheduling in the first place, given that thread stacks are configurable in the syscall.
    - NateDad 11y ago
      I believe you know what you're talking about, and so are right about what's best (or really, even possible) in rust, but I can still be sad that there's not some magic way to have my cake and eat it too.
    - SamReidHughes 11y ago
      How does having small initial stack sizes give you fast thread spawning?
      - pcwalton 11y ago
        Because you can pull the stack off the malloc free list bin, or even bump allocate it in a nursery.
        SamReidHughes 11y ago
        But you can allocate large stacks efficiently too. Is this something specific to how GC works? Edit: Is it about having stacks smaller than a page, maybe not aligned to 4K and not fighting for the same cache lines?

bsdetector 11y ago

What they are getting at is that the Go designers are stubborn and the Rust designers are open-minded... but they don't want to just come out and say that. For instance both had green threads. Rust designers ran into all the problems with them like interop with anything else and interrupts and fairness, so like everybody else that did M:N threading they threw up their hands and said "well it looked like a good idea at first" and removed it. Go designers literally called it a "rabbit hole" and followed it down to whatever crazy lands it lead to, because they promised people green threads so they had to keep it.

Manishearth 11y ago
True. For the record I like the Rust model a lot more (obviously, as a contributor, I should); but what I'm saying is that there's a tradeoff and both have their good parts. The moment you're open to some community decision making, you're expected to be open to all of it -- Go doesn't get much flak from the community for unilateral decisionmaking. I bet it would if it started to allow some community consensus on some decisions. And like I said, the "let the community decide everything" model probably wouldn't work for Go, so unilateral it is :)
NateDad 11y ago
That's very sad for Rust, because Go's goroutines are amazingly awesome.
- pcwalton 11y ago
  I firmly believe that moving away from M:N threading was the right decision for Rust. Even if nothing else, the fact that Rust FFI performance is thousands of times faster than cgo alone justifies the decision. There are numerous other reasons (fairness, I/O performance, performance of synchronization primitives, implementation complexity) why just using the OS scheduling is superior for a systems language. The primary benefit of M:N scheduling—fast thread spawning due to small initial stack sizes—requires GC, which Rust doesn't have, and arguably has little to do with M:N scheduling in the first place, given that thread stacks are configurable in the syscall.
  - NateDad 11y ago
    I believe you know what you're talking about, and so are right about what's best (or really, even possible) in rust, but I can still be sad that there's not some magic way to have my cake and eat it too.
  - SamReidHughes 11y ago
    How does having small initial stack sizes give you fast thread spawning?
    - pcwalton 11y ago
      Because you can pull the stack off the malloc free list bin, or even bump allocate it in a nursery.
      - SamReidHughes 11y ago
        But you can allocate large stacks efficiently too. Is this something specific to how GC works? Edit: Is it about having stacks smaller than a page, maybe not aligned to 4K and not fighting for the same cache lines?