malloc and free are part of the C standard library. I don’t see the point in picking nits between language features you don’t have to use and standard library functions that you don’t have to use.
When you called attention to Rust you clearly understood the point of picking nits. Why pretend you have no idea what we are talking about now?
malloc/free, not being a language feature, cannot be reasoned about. Since the larger discussion is about Go, consider using malloc/free in Go. Of course you can do it. There is nothing stopping you. Since it is not part of a language it can be bolted on to any language, not just C. But if you do, it should be obvious you can no longer reason about the program in terms of how memory is used. If there was a way to reason about it, C would already have all the same memory guarantees that Rust does.
> malloc/free, not being a language feature, cannot be reasoned about.
They’re defined in the standard all the same. Of course they can be reasoned with. The defined parts at least. You may argue that the undefined parts cannot, but those are explicitly outside the scope of the C standard, no need to discuss them any further.
malloc/free, not being a language feature, cannot be reasoned about. Since the larger discussion is about Go, consider using malloc/free in Go. Of course you can do it. There is nothing stopping you. Since it is not part of a language it can be bolted on to any language, not just C. But if you do, it should be obvious you can no longer reason about the program in terms of how memory is used. If there was a way to reason about it, C would already have all the same memory guarantees that Rust does.