How does it deal with pointers if everything is stack based? You can't really return a pointer to something on the stack because it could get overwritten between when you return it and when you access it.
Quoting the FAQ: "So itself has few safeguards other than the default Go type checking. It will panic on out-of-bounds array access, but it won't stop you from returning a dangling pointer or forgetting to free allocated memory. Most memory-related problems can be caught with AddressSanitizer in modern compilers, so I recommend enabling it during development by adding -fsanitize=address to your CFLAGS."
So saying you get the "safety of Go" is a bit of a stretch.
Yeah that's not great. It's easy to be faster than go if you haven't thought about memory management yet. I bet go with GOGC=off is faster than plain go too.
This is impossible. General words like "faster" are subjective, and useless in a technical context unless you ground the discussion by giving them specific definitions. Otherwise everyone ends up talking past each other.
That's undefined behavior in C I thought? You're addressing the memory of a stack frame that already collapsed when it returned. I think it's ok for compilers to either segfault or work like you'd think they would for that example in C.
You can pass pointers to earlier frames in the stack, they're still active, but you can't return a pointer to an expired stack frame.
I think you're basically agreeing with the person you're replying to; they're pointing out that Solod doesn't really provide the "safety of Go" since the translation trivially exposes the user to UB that would not be present in Go.
So saying you get the "safety of Go" is a bit of a stretch.