I don’t think this is confusing to the vast majority of people writing Go.<p>In my experience, the average programmer isn’t even aware of the stack vs heap distinction these days. If you learned to write code in something like Python then coming at Go from “above” this will just work the way you expect.<p>If you come at Go from “below” then yeah it’s a bit weird.
Go has been my primary language for a few years now, and I’ve had to do extra work to make sure I’m avoiding the heap maybe five times. Stack and heap aren’t on my mind most of the time when designing and writing Go, even though I have a pretty good understanding of how it works. The same applies to the garbage collector. It just doesn’t matter most of the time.<p>That said, when it matters it matters a lot. In those times I wish it was more visible in Go code, but I would want it to not get in the way the rest of the time. But I’m ok with the status quo of hunting down my notes on escape analysis every few months and taking a few minutes to get reacquainted.<p>Side note: I love how you used “from above” and “from below”. It makes me feel angelic as somebody who came from above; even if Java and Ruby hardly seemed like heaven.
Why have you had to avoid the heap? Performance concerns?
For me, avoiding heap, or rather avoiding gc came when I was working (at work) on backend and web server using Java, and there was default rule for our code that if gc takes more than 1% (I don't remember the exact value) then the server gets restarted.<p>Coming (back then) from C/C++ gamedev - I was puzzled, then I understood the mantra - it's better for the process to die fast, instead of being pegged by GC and not answering to the client.<p>Then we started looking what made it use GC so much.<p>I guess it might be similar to Go - in the past I've seen some projects using a "baloon" - to circumvent Go's GC heuristic - e.g. if you blow this dummy baloon that takes half of your memory GC might not kick so much... Something like this... Then again obviously bad solution long term
Garbage Collection.<p>The content of the stack is (always?) known at compile time; it can also be thrown away wholesale when the function is done, making allocations on the stack relatively cheaper. These FOSDEM talks by Bryan Boreham & Sümer Cip talk about it a bit:<p>- <i>Optimising performance through reducing memory allocations</i> (2018), <a href="https://archive.fosdem.org/2018/schedule/event/faster/" rel="nofollow">https://archive.fosdem.org/2018/schedule/event/faster/</a><p>- <i>Writing GC-Friendly [Go] code</i> (2025), <a href="https://archive.fosdem.org/2025/schedule/event/fosdem-2025-5343-go-ing-easy-on-memory-writing-gc-friendly-code/" rel="nofollow">https://archive.fosdem.org/2025/schedule/event/fosdem-2025-5...</a><p>Speaking of GC, Go 1.26 will default to a newer one viz. <i>Green Tea</i>: <a href="https://go.dev/blog/greenteagc" rel="nofollow">https://go.dev/blog/greenteagc</a>
Ha! I had not intended to imply that one is better than the other, but I am glad that it made you feel good :).<p>I also came "from above".
As someone who writes both Python and Go (and I've been using Python professionally since 2005), I remember that the scoping behaviour has changed.<p>Back in Python 2.1 days, there was no guarantee that a locally scoped variable would continue to exist past the end of the method. It was <i>not</i> guaranteed to vanish or go fully out of scope, but you could not <i>rely</i> on it being available afterwards. I remember this changing from 2.3 onwards (because we relied on the behaviour at work) - from that point onwards you could reliably "catch" and reuse a variable after the scope it was declared in had ended, and the runtime would ensure that the "second use" maintained the reference count correctly. GC did not get in the way or concurrently disappear the variable from underneath you anymore.<p>Then from 2008 onwards the same stability was extended to more complex data types. Again, I remember this from having work code give me headaches for yanking supposedly out-of-scope variable into thin air, and the only difference being a .1 version difference between the work laptop (where things worked as you'd expect) and the target SoC device (where they didn't).
I don't see how this is coming at go "from below".<p>even in C, the concept of returning a pointer to a stack allocated variable is explicitly considered undefined behavior (not illegal, explicitly undefined by the standard, and yes that means unsafe to use). It be one thing if the the standard disallowed it.<p>but that's only because the memory location pointed to by the pointer will be unknown (even perhaps immediately). the returning of the variable's value itself worked fine. In fact, one can return a stack allocated struct just fine.<p>TLDR: I don't see what the difference between returning a stack allocated struct in C and a stack allocated slice in Go is to a C programmer. (my guess is that the C programmer thinks that a stack allocated slice in Go is a pointer to a slice, when it isn't, it's a "struct" that wraps a pointer)
The confusion begins the moment you think Go variables get allocated on the stack, in the C sense. They don't, semantically. Stack allocation is an optimization that the Go compiler can sometimes do for you, with no semantics associated with it.<p>The following Go code also works perfectly well, where it would obviously be UB in C:<p><pre><code> func foo() *int {
i := 7
return &i
}
func main() {
x := foo()
fmt.Printf("The int was: %d", *x) //guaranteed to print 7
}</code></pre>
ok, I'd agree with you in that example a go programmer would expect it to work fine, but a C programmer would not, but that's not the example the writer gave. I stand by my statement that the example the writer gave, C programmer would expect to work just fine.
I think the writer had multiple relatively weird confusions, to be fair. It's most likely that "a little knowledge is a dangerous thing". They obviously knew something about escape analysis and Go's ability to put variables on the stack, and they likely knew as well that Go slices are essentially (fat) pointers to arrays.<p>As the author shows in their explanations, they thought that the backing array for the slice gets allocated on the stack, but then the slice (which contains/represents a pointer to the stack-allocated array) gets returned. This is a somewhat weird set of assumptions to make (especially give that the actual array is allocated in a different function that we don't get to see, ReadFromFile, but apparently this is how the author thought through the code.
Is that the case? I thought that it would be a copy instead of a heap allocation.<p>Of course the compiler could inline it or do something else but semantically its a copy.
A copy of what? It’s returning a pointer, so i has to be on the heap[0].<p>gc could create i on the stack then copy it to the heap, but if you plug that code into godbolt you can see that it is not that dumb, it creates a heap allocation then writes the literal directly into that.<p>[0] unless Foo is inlined and the result does not escape the caller’s frame, then that can be done away with.
This seems to be a persistent source of confusion. Escape analysis is just an optimization. You don't need to think about it to understand why your Go code behaves the way it does. Just imagine that everything is allocated on the heap and you won't have any surprises.
I am currently learning go and your comment made me sort some things out, but probably in a counterintuitive way.<p>Assuming to everything allocates on the heap, will solve this specific confusion.<p>My understanding is that C will let you crash quite fast if the stack becomes too large, go will dynamically grow the stack as needed. So it's possible to think you're working on the heap, but you are actually threshing the runtime with expensive stack grow calls. Go certainly tries to be smart about it with various strategies, but a rapid stack grow rate will have it's cost.
Makes sense. I need to rewire how I think about Go. I should see it how I see JS.
<i>> This seems to be a persistent source of confusion.</i><p>Why? It is the same as in C.<p><pre><code> #include <stdio.h>
#include <stdlib.h>
struct slice {
int *data;
size_t len;
size_t cap;
};
struct slice readLogsFromPartition() {
int *data = malloc(2);
data[0] = 1;
data[1] = 2;
return (struct slice){ data, 2, 2 };
}
int main() {
struct slice s = readLogsFromPartition();
for (int i = 0; i < s.len; i++) {
printf("%d\n", s.data[i]);
}
free(s.data);
}</code></pre>
The point the GP was making was that the following Go snippet:<p><pre><code> func foo() {
x := []int { 1 }
//SNIP
}
</code></pre>
Could translate to C either as:<p><pre><code> void foo() {
int* x = malloc(1 * sizeof(int));
x[0] = 1;
//...
}
</code></pre>
Or as<p><pre><code> void foo() {
int data[1] = {1};
int *x = data;
//...
}
</code></pre>
Depending on the content of //SNIP. However, some people think that the semantics can also match the semantics of the second version in C - when in fact the semantics of the Go code always match the first version, even when the actual implementation is the second version.
What confuses people is<p><pre><code> int *foo(void) {
int x = 99;
return &x; // bad idea
}
</code></pre>
vs.<p><pre><code> func foo() *int {
x := 99
return &x // fine
}
</code></pre>
They think that Go, like C, will allocate x on the stack, and that returning a pointer to the value will therefore be invalid.<p>(Pedants: I'm aware that the official distinction in C is between automatic and non-automatic storage.)
Yes. That's escape analysis. But this is not what OP did.<p>What you wrote is not the same in C and Go, because GC and escape analysis. But 9rx is also correct that what OP wrote <i>is</i> the same in C and Go.<p>So OP <i>almost</i> learned about escape analysis, but their example didn't actually do it. So double confusion on their side.
It's not confusing that this works in Go. (In my opinion).<p>A straightforward reading of the code suggests that it should do what it does.<p>The confusion here is a property of C, not of Go. It's a property of C that you need to care about the difference between the stack and the heap, it's not a general fact about programming. I don't think Go is doing anything confusing.
I like Go a lot, but I often wish we could be more explicit about where allocations are. It’s often important for writing performant code, but instead of having semantics we have to check against the stack analyzer which has poor ergonomics and may break at any time.<p>But yeah, to your point, returning a slice in a GC language is not some exotic thing.
I think I would like a “stackvar” declaration that works the same as “var” except my code won’t compile if escape analysis shows it would wind up on the heap. I say that knowing I’m not a language designer and have never written a compiler. This may be an obviously bad idea to somebody experienced in either of those.<p>I commented elsewhere on this post that I rarely have to think about stacks and heaps when writing Go, so maybe this isn’t my issue to care about either.
Can you elaborate on the stack analyzer? All I could figure out was to see runtime.morestack calls that affected the runtime, but as far I remember the caller timings did exclude the cost. Having a clearer view of stack grow rates would be really great.
If the functions get inlined (which they might if they're small enough), then the code won't even need to allocate on heap! That's a kind of optimisation that's not really possible without transparent escape analysis.
You can run the compiler with a flag that shows all the escapes with -gcflags “-m” and there’s also support in goland and vscode to show the escapes as inline annotations in the editor. This sort of thing IMO is one of the useful things about IDEs: showing hints from later parts of the tool chain about how things are going to turn out
Shameless plug, if one wishes to track down allocations in Go, an allocations explorer for VS Code: <a href="https://marketplace.visualstudio.com/items?itemName=Clipperhouse.go-allocations-vsix" rel="nofollow">https://marketplace.visualstudio.com/items?itemName=Clipperh...</a>
Nope, this analysis is wrong. Decompile your code and look at what's going on:
<a href="https://godbolt.org/z/f1nx9ffYK" rel="nofollow">https://godbolt.org/z/f1nx9ffYK</a><p>The thing being returned is a slice (a fat pointer) that has pointer, length, capacity. In the code linked you'll see the fat pointer being returned from the function as values. in C you'd get just AX (the pointer, without length and cap)<p><pre><code> command-line-arguments_readLogsFromPartition_pc122:
MOVQ BX, AX // slice.ptr -> AX (first result register)
MOVQ SI, BX // slice.len -> BX (second)
MOVQ DX, CX // slice.cap -> CX (third)
</code></pre>
The gargabe collection is happening in the FUNCDATA/PCDATA annotations, but I don't really know how that works.
If the variable was defined in the calling function itself, and a pointer was passed, I guess the variable will still be in the heap?
Emojis in code comments make them unreadable. Why is this a thing?
Are you sure this is what's happening? Looks to me like the slice object is returned by value, and the array was always on the heap. See <a href="https://go.dev/play/p/Bez0BgRny7G" rel="nofollow">https://go.dev/play/p/Bez0BgRny7G</a> (the address of the slice object changed, so it's not the same object on the heap)<p>Sure, Go has escape analysis, but is that really what's happening here?<p>Isn't this a better example of escape analysis: <a href="https://go.dev/play/p/qX4aWnnwQV2" rel="nofollow">https://go.dev/play/p/qX4aWnnwQV2</a> (the object retains its address, always on the heap, in both caller and callee)
Depending on escape analysis, the array underlying the slice can get allocated on the stack as well, if it doesn't escape the function context. Of course, in this case, because we are returning a pointer to it via the slice, that optimization isn't applicable.
That’s the one.<p>Since 1.17 it’s not impossible for escape analysis to come into play for slices but afaik that is only a consideration for slices with a statically known size under 64KiB.
Interesting! This could be true. I'll play around with this in a bit.
Yeah I think what you're describing, returning a slice thus copying a reference to the same array (but not copying the array), then destroying the callee slice not causing the array to be freed, is just basic garbage collection logic, not escape analysis.
Yes, this is merely the slice fat pointer being copied and returned.
Go is returning a copy of the slice, in the same way that C would return a copy of an int or struct if you returned it. The danger of C behaviour in this instance is that a stack allocated array decays into a pointer which points to the deallocated memory. Otherwise the behaviour is pretty similar between the languages.
> In C, you can't assign a value in a local function and then return it<p>I am so glad I never taken up C. This sound like a nightmare of a DX to me.
Depending on what your working on, it's actually super nice to know very clearly what lives on the stack vs the heap for performance and compactness reasons. Basically anything that didn't come from malloc or a function calling malloc lives on the stack and doesn't live past the function it was allocated in.<p>And these days, if you're bothering with C you probably care about these things. Accidentally promoting from the stack to the heap would be annoying.