1. This isn’t standard practice for high reliability systems. Lots of highly reliable systems don’t prohibit dynamic dispatch, dynamic memory, etc.
2. Most programs (especially Go programs) aren’t embedded, so this isn’t much of a criticism.
3. If you can statically analyze a C program and make sure it doesn’t overflow the stack, why can’t you statically analyze a Go program and make sure it doesn’t grow the stack beyond a certain size? I’m not arguing that Go is a good fit for embedded, but I don’t see why throwable stacks are a major problem.
2. Most programs (especially Go programs) aren’t embedded, so this isn’t much of a criticism.
3. If you can statically analyze a C program and make sure it doesn’t overflow the stack, why can’t you statically analyze a Go program and make sure it doesn’t grow the stack beyond a certain size? I’m not arguing that Go is a good fit for embedded, but I don’t see why throwable stacks are a major problem.