People constantly screw up the simplest and easiest things, especially when there are hundreds of simple and easy things in a program. And Go makes sure that you have to write a hundred simple and easy things every time you work with it to solve problems.

I just finished porting 50k loc from Java to Go: https://github.com/ravendb/ravendb-go-client

You won't find hundreds of purported simple/easy things that are exclusive to Go code.

There's probably less than 10 cases where I implemented some simple thing (like a set of strings) that Java gave for free because of library function that used generics.

Among 50k loc that's background noise.

don't forget the defer keyword:

from README:

// ... use session session.Close()

can be changed to this right after you get a session:

defer session.Close()

> Go makes sure that you have to write a hundred simple and easy things every time you work with it to solve problems.

This is precisely how I feel, could never capture it in words myself.

Point is you shouldn't have to implement a stack. I have never had to do that in any language I used except C. Sounds like a nightmare.

Luckily you can implement a stack in 10 very simple lines. And if you don't want to do that, there are many existing implementations.

Well, not ones as efficient as the one showed here, since those can't be expressed in the language as it currently stands.

>there are many existing implementations

Sounds like JavaScript/Node all over again, which shouldn't surprise anybody as many of the prominent Node developers hopped over to Go.

push:

  a = append(a, el)

pop:

  n := len(a)
  el := a[n-1]
  a = a[:n-1]

It took me, literally, 10 seconds to write.

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?)