3 ms·
I don't agree and my job requires that I program in C++. It's different, yes, but it's only strange if you learn about C or C++ first. Whether you agree or not
by uluyol 3y ago
I don't agree and my job requires that I program in C++. It's different, yes, but it's only strange if you learn about C or C++ first.
Whether you agree or not, I definitely think that promoting loop variables to be heap allocated is consistent with the rest of Go.
- woodruffw 3y agoI don't disagree that it's consistent! Consistency and weirdness are separate dimensions; it's possible to be consistently weird, and IMO Go's pattern of returning local-looking-but-actually-heap addresses is pretty weird, especially when you consider that they could have made return-by-value a transparently optimized move instead.
- xyzzy_plugh 3y agoIt's only weird because you are expecting a local variable to not be on the heap. If local variables were always on the heap, you wouldn't notice. That's precisely what is happening here.
- amscanne 3y agoThere is such thing as "local-looking" in Go. That's the point -- the compiler and runtime make the decisions as needed and the programmer doesn't care. (Obviously there are some consequences to this, wherein you may find yourself with heap-based allocation in hot paths that you didn't expect. But in terms of productivity, I think that not caring and having no distinction certainly reduces one thing that the programmer has to think about.) I think there would be analogous design decisions that remove various low-level concepts in many languages. For example, Python ints are arbitrary precision, which removes a whole set of concerns from the programmer. Rather than being "weird", I think this is just optimizing for a particular kind of programmer productivity.