>>61
Where the above assertion is true, yes, they're the same thing. But indexing a safe array is not as fast as arithmetic, and the difference is bounds-checking.
Why does everyone keep saying this? It's not true. Once allocated, Go's arrays and slices are fixed size; you do the bounds check *once* at the start of the loop, and the compiler can then transform it into pointer arithmetic. There is no overhead. For all its faults, Java has solved this particular problem a decade ago.
You can't easily use an array+index as a callback for another function that expects the user function to take one argument; you have to wrap it in a struct first -- increasing the program's complexity. You can't return an array and index from a function without special language support for it -- increasing the language's complexity.
Uh, folks? Go does have this. It's called slices. It's a built-in language feature that creates a reference to a portion of an existing array.
This is a very minor increase in the complexity of the language for a rather massive reduction in complexity in the resulting libraries. Every goddamn function in the entire Java library that takes an array also takes offset and length. Every function in the C library that takes a pointer for an array also takes count. Go solves this elegantly in a way no other language does; not Lisp, not C, and not even Python, whose slices are actually array copies.
The extra variable and internal state needed in order to keep track of the index and array boundary increases the size of any function that handles arrays, and hogs up cache line space in memory -- thus, if these languages are ever to be as fast as C they will need ever-larger CPU caches to hold all this superfluous data.
Total bullshit. Under the hood, slices are probably implemented as a small struct passed by value containing a pointer to the first element of the slice and the length of the slice. This is the same exact overhead as if the function just took a count parameter (like they ALL do in C, aside from the brutal string functions).
And this is insignificant compared to the size of the array itself! You are absolutely grasping at straws here.
I am really surprised at how much bullshit is being spewed here, and how much you are all worrying about insignificant and trivial overhead for pointer safety. You guys honestly think the extra four bytes for an array size, the one extra jne instruction at the start of a for loop are going to make a difference here? You really think that THIS is the thing about Go worth arguing about, and not anything else about the actual semantics of the language?