More importantly, this will take me a minute to read and two minutes to make sure it’s doing the right thing every time I encounter it somewhere new.

I don’t think I will ever understand why so many go advocates seem so openly hostile to encapsulation. If go had used C-style for loops, I swear there would be people here defending the decision saying:

    sum := 0
    for (i := 0; i <= len(a); i++) {
        sum = sum + a[1]
    }

“See? Only four lines. What’s the big deal? It took me literally thirty seconds to write.”

Did you immediately notice the bug in my above code? If not, hopefully you get my point.

Compared to

    array.sum()

was the above code more or less clear? Is it more or less prone to bugs? When reading, which code will you have a quicker understanding of the intent?

And if you did notice the the first bug, did you notice the second bug?

Well played. I noticed neither until you pointed them out. Certainly would have missed it in a code review.

I think parent should've made their point with a queue instead of a stack.

This code is inefficient.

Tune in next week to find out why!

Is that an O(n) implementation of pop? I hope you realize my point..

I looked it up and it's not but the point is that you shouldn't have to worry about these things, including implementation details of trees and hundreds of other data structures.

It isn't. It re-slices the backing array and retains its capacity. (Maybe that's what you looked up at the end?)