3 ms·

All those deal with threads. Rust 1.0 will have multi-threading just like C++, Java, etc. It is very different from how Goroutines work and do not offer similar

All those deal with threads. Rust 1.0 will have multi-threading just like C++, Java, etc. It is very different from how Goroutines work and do not offer similar benefits at all (specifically for network services). libgreen while it existed scaled very poorly and consensus among rust developers seemed to be that, it cannot be improved without compromising some of the core features of rust like no-GC and zero-overhead calls to C libraries.

krenoten 12y ago
Even with Go it's a fairly bad idea not to use Goroutine pools for request handling if you're writing low-latency services. You can get isomorphic results with a future pool and channels.
- tuxychandru 12y ago
  It is not about whether goroutines need to be pooled. Goroutines work very differently from how OS threads. They are scheduled at the user-level by using non-blocking system calls to perform network IO on multiple OS threads. They are also partially pre-empted on function calls. Whether goroutines need to be pooled depends on the application. For example, the default HTTP creates ones per connection and seems to be used without any problem in production at a lot of places. Creating them is much cheaper than creating OS threads. In fact, libgreen threads were faster to spawn than libnative ones in rust when it existed. Rust and Go have different trade-offs when it comes to concurrency and each has its benefits and drawbacks.
  - krenoten 12y ago
    I'm not saying that a Goroutine is a thread. My point was, you have the ability to write your own systems for your own tradeoffs. Feel free to write a schedulerless coroutine system or an Erlangesque reduction counting scheduler, or even a full reimplementation of the Go scheduler. You can pin Goroutines to threads to ask them to act a little more like them, but that's about as far as you can go. While you are right that Go's system is great for some tasks, there is no reason why Rust can't form a superset of its functionality, in time.
    - tuxychandru 12y ago
      Whether goroutine-like mechanism is possible in rust without compromising its core values is not clear, since libgreen attempted it and failed. Something like async..await is in the cards and I guess rust does have plans to implemented it sometime in future, but that will require compiler support and can't be done just in libraries like you claimed in the first comment of this thread. While it will not have same runtime characteristics of goroutines, it'll provide similar benefits to program structure. All that said, rust definitely offers a lot. I'm only contending the claim that the language is flexible enough to implement something similar to goroutines purely as a library.
      - jaekwon 12y ago
        Huh interesting... how does Go do it under the hood?
        tuxychandru 12y ago
        This is a good read on the Go scheduler. http://morsmachine.dk/go-scheduler http://morsmachine.dk/go-scheduler
        pcwalton 12y ago
        There is nothing that would prevent an implementation of Go's scheduler in Rust, and libgreen duplicated its functionality pretty comprehensively. Rust's scheduler was more advanced than Go's scheduler in some ways—it did work-stealing in a completely lock-free way, for example. The only fundamental difference between Rust and Go here is in stack management. In Go, goroutines start off with a small stack, and they can grow because the language is now pervasively, precisely garbage collected and all of the pointers into the stack can be rewritten. In Rust, that wasn't an option because it isn't garbage collected; it used to use the old Go approach of split stacks, but the same problems were encountered. There was also significant backlash against the problems that continue to be an issue in Go and were an issue in Rust—the FFI (cgo in Go's case) was slow due to having to perform stack switches, most importantly.
- deleted 12y ago
  [deleted]

krenoten 12y ago

Even with Go it's a fairly bad idea not to use Goroutine pools for request handling if you're writing low-latency services. You can get isomorphic results with a future pool and channels.

tuxychandru 12y ago
It is not about whether goroutines need to be pooled. Goroutines work very differently from how OS threads. They are scheduled at the user-level by using non-blocking system calls to perform network IO on multiple OS threads. They are also partially pre-empted on function calls. Whether goroutines need to be pooled depends on the application. For example, the default HTTP creates ones per connection and seems to be used without any problem in production at a lot of places. Creating them is much cheaper than creating OS threads. In fact, libgreen threads were faster to spawn than libnative ones in rust when it existed. Rust and Go have different trade-offs when it comes to concurrency and each has its benefits and drawbacks.
- krenoten 12y ago
  I'm not saying that a Goroutine is a thread. My point was, you have the ability to write your own systems for your own tradeoffs. Feel free to write a schedulerless coroutine system or an Erlangesque reduction counting scheduler, or even a full reimplementation of the Go scheduler. You can pin Goroutines to threads to ask them to act a little more like them, but that's about as far as you can go. While you are right that Go's system is great for some tasks, there is no reason why Rust can't form a superset of its functionality, in time.
  - tuxychandru 12y ago
    Whether goroutine-like mechanism is possible in rust without compromising its core values is not clear, since libgreen attempted it and failed. Something like async..await is in the cards and I guess rust does have plans to implemented it sometime in future, but that will require compiler support and can't be done just in libraries like you claimed in the first comment of this thread. While it will not have same runtime characteristics of goroutines, it'll provide similar benefits to program structure. All that said, rust definitely offers a lot. I'm only contending the claim that the language is flexible enough to implement something similar to goroutines purely as a library.
    - jaekwon 12y ago
      Huh interesting... how does Go do it under the hood?
      - tuxychandru 12y ago
        This is a good read on the Go scheduler. http://morsmachine.dk/go-scheduler http://morsmachine.dk/go-scheduler
        pcwalton 12y ago
        There is nothing that would prevent an implementation of Go's scheduler in Rust, and libgreen duplicated its functionality pretty comprehensively. Rust's scheduler was more advanced than Go's scheduler in some ways—it did work-stealing in a completely lock-free way, for example. The only fundamental difference between Rust and Go here is in stack management. In Go, goroutines start off with a small stack, and they can grow because the language is now pervasively, precisely garbage collected and all of the pointers into the stack can be rewritten. In Rust, that wasn't an option because it isn't garbage collected; it used to use the old Go approach of split stacks, but the same problems were encountered. There was also significant backlash against the problems that continue to be an issue in Go and were an issue in Rust—the FFI (cgo in Go's case) was slow due to having to perform stack switches, most importantly.
deleted 12y ago
[deleted]