[pcwalton]

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.

[tuxychandru]

Yes, that's what I meant when I said it not clear whether goroutines can be replicated as a library in rust "without compromising rust's core values". In fact, I mentioned no-GC and zero-overhead C calls.

Since libgreen did have massive stacks and one could not spawn 100s of thousands of tasks without changing system limits like overcommit, it was not really a comprehensive duplication of goroutines.

[pcwalton]

> Since libgreen did have massive stacks and one could not spawn 100s of thousands of tasks without changing system limits like overcommit

Well, you could customize the stack size, and we did when running stress tests like that. You don't need to change system settings. The only difference is that you have to know how much stack your "goroutine" is going to need up front.

[jaekwon]

This is really interesting. One or both of you all should write a blog post on it because I'm eager to learn more.

I love C. Love Go. Love the idea of Rust though I've never tried it, and I just want to know more.