4 ms·

Rust doesn't have escape analysis like Go (or Java, etc.), it is all done at compile time and any failures are flagged, meaning one has a stronger idea of the a

by dbaupp 10y ago

Rust doesn't have escape analysis like Go (or Java, etc.), it is all done at compile time and any failures are flagged, meaning one has a stronger idea of the actual runtime behaviour of the code. Additionally, reference counting is used far less than GC pointers in languages like Go, even accounting for their escape analysis. In terms of integration with native code, the concurrency model of Go means calling native functions has high overhead because it has to switch to a native stack (thi iss one possible motivation for why Go does syscalls directly on Linux: avoid the stack switching overhead).

endorphone 10y ago
Rust doesn't have escape analysis like Go (or Java, etc.), it is all done at compile time Go makes the stack/heap decision at compile time as well. It is far closer to C++ than Java. To your other point, cgo calls indeed have a high overhead in an absolute sense, and ideally you do fatter, more meaningful calls. I am not advocating for Go, it just seems that these discussions often pigeonhole technologies, and a common one is the strange belief that Go is just another Java/C#, and Rust is the next low level language.
- dbaupp 10y ago
  I was unclear: the key bit from that first sentence is "any failures are flagged". Go does give more static control over stack vs. heap than Java, but it's still perfectly happy to implicitly promote things to the heap to make code work. This means that Go offers less control over memory (one of the things needed in a low-level language) than Rust. When, for instance, variables are being passed between threads/goroutine-equivalents, Rust will notice that things are trying to escape and tell the programmer that they need to decide how they want to handle it, rather than make the decision implicitly. (The Go approach isn't like C++ either, which also doesn't implicitly allocate, like Rust.) There are many other aspects in which Go does not offer as much control as Rust, e.g. the former incorporates a runtime and garbage collector. This isn't disagreeing that Go offers more control than Java, but Rust (and C++) offers even more than Go.
- pcwalton 10y ago
  > Go makes the stack/heap decision at compile time as well. No, it doesn't! This is even in the FAQ: https://golang.org/doc/faq#stack_or_heap https://golang.org/doc/faq#stack_or_heap
  - endorphone 10y ago
    How do you think that refutes what I said? Go absolutely makes that decision at compile time (of course it does -- Go does not have a VM). Is your point that they say that you shouldn't sweat it? Because of course you shouldn't, and ideally it is making the right choice, which most of the time is the stack.

by dbaupp 10y ago

endorphone 10y ago

Rust doesn't have escape analysis like Go (or Java, etc.), it is all done at compile time Go makes the stack/heap decision at compile time as well. It is far closer to C++ than Java. To your other point, cgo calls indeed have a high overhead in an absolute sense, and ideally you do fatter, more meaningful calls. I am not advocating for Go, it just seems that these discussions often pigeonhole technologies, and a common one is the strange belief that Go is just another Java/C#, and Rust is the next low level language.

dbaupp 10y ago
I was unclear: the key bit from that first sentence is "any failures are flagged". Go does give more static control over stack vs. heap than Java, but it's still perfectly happy to implicitly promote things to the heap to make code work. This means that Go offers less control over memory (one of the things needed in a low-level language) than Rust. When, for instance, variables are being passed between threads/goroutine-equivalents, Rust will notice that things are trying to escape and tell the programmer that they need to decide how they want to handle it, rather than make the decision implicitly. (The Go approach isn't like C++ either, which also doesn't implicitly allocate, like Rust.) There are many other aspects in which Go does not offer as much control as Rust, e.g. the former incorporates a runtime and garbage collector. This isn't disagreeing that Go offers more control than Java, but Rust (and C++) offers even more than Go.
pcwalton 10y ago
> Go makes the stack/heap decision at compile time as well. No, it doesn't! This is even in the FAQ: https://golang.org/doc/faq#stack_or_heap https://golang.org/doc/faq#stack_or_heap
- endorphone 10y ago
  How do you think that refutes what I said? Go absolutely makes that decision at compile time (of course it does -- Go does not have a VM). Is your point that they say that you shouldn't sweat it? Because of course you shouldn't, and ideally it is making the right choice, which most of the time is the stack.