The Value in Go’s Simplicity

Re:The Value in Go’s Simplicity by millstone on Saturday November 16, 2019 @07:16PM (#21555772)

I don't know Go, but from my outsider's perspective it doesn't look simple!

For example compare inserting into a list in Python:

    list.insert(index, obj)

with apparently idiomatic Go:

    a = append(a[:i], append([]T{x}, a[i:]...)...)

Or compare Python's `list.reverse()` to Go's recommendation:

    for i := len(a)/2-1; i >= 0; i-- {
        opp := len(a)-1-i
        a[i], a[opp] = a[opp], a[i]
    }

This seems quite error prone.

Idiomatic Go taken from https://github.com/golang/go/wiki/SliceTricks

[ Parent | on HN ]

Re:The Value in Go’s Simplicity by andrenth on Saturday November 16, 2019 @07:23PM (#21555800)

One of the things to keep in mind with Go is that in general it doesn’t try to hide possibly costly operations under simple to use interface.

So in your example, append may need to allocate, and the fact that it returns a new pointer makes that clear.

For the second example, you could use sort.Reverse, but the loop makes the cost of the operation clear.

[ Parent | on HN ]

Re:The Value in Go’s Simplicity by CAMLORN on Saturday November 16, 2019 @10:48PM (#21556455)

In the insert case call the function InsertWithAllocqation, and also provide an Insert variant that doesn't allocate but can fail. In the reversing case, call the function ReverseInPlace, then require the user to make a copy either before or after. This gets you the same goal--not hiding the costly allocation--while also making it convenient to use and removing the possibility of mistakes.

The real problem is that without generics, such functions actually have to be written in the same fashion as sorting where you provide a function for reading and writing both, as opposed to just working--so the "simple" loops which are indeed error prone actually become less code, and we all use them instead. I highly, highly doubt even the best Google programmer will always get the boundary condition on that reverse a list loop right especially in an emergency or at 3 AM, and this is a very simple case where Go just can't abstract on par with anything-with-generics.

But my point is that you can meet the goal of not hiding operations just with good naming, if that's what you consider a terminal value of good pl design, and don't need to forego abstraction to do it.

[ Parent | on HN ]

Re:The Value in Go’s Simplicity by xyzzy_plugh on Saturday November 16, 2019 @08:10PM (#21555934)

Additionally, at least in my experience, you don't ever want to just "reverse a list", you want to do something, like print it in a certain order. Writing the loops yourself makes it simpler to accomplish the task at hand, I find.

[ Parent | on HN ]