[littlestymaar]

> Unlike C, you don't need to worry about the heap-vs-stack in Go. […] It's an implementation detail.

I'm really surprised to read that: yes a beginner can get his code working without wondering about stack vs heap (and that's one of the big reason why Go is easier to learn than Rust for people coming from non-system language), but as soon as you care about performance (which many Go users do!), you need to write code that reduces allocations to the minimum, because Go's allocator is really slow (compared to Java for instance). Interestingly enough, doing so forces you to think about the ownership and lifetime of your objects, like you'd do in C (or Rust).

[weberc2]

The great thing about Go is that you don't need to think about allocations or lifetimes until you care about performance. Memory management is optimization in Go, while in C, C++, Rust, etc it's required to get a program to compile (of course you can "opt in" to easy memory management in those languages by using some kind of GC library, this is vanishingly rare--presumably developers would rather just use a language that was designed for GC). If you're at the point where your Go code is so performance sensitive that you're optimizing memory more often than not, it probably makes sense to be using Rust, but these cases are rare for the kinds of applications I tend to write (which is sad because I actually really enjoy using Rust).

[littlestymaar]

Absolutely (well at least for Rust, because for C it's not required for it to compile: the code will compile to some broken garbage that will either crash at runtime, be vulnerable to exploits or burn your hard drive, depending on the mood ;).

I just found surprising to see a core person of Go declaring heap vs stack allocation to be “implementation detail”. Because if it was, that would mean that my carefully crafted zero-alloc code could become full of allocations one day because the underlying implementation changed! Obviously they don't want their users to be afraid of that.