IMO Go has poor primitives that make even straightforward code needlessly complicated. Slices are probably the worst. Compare Python's way to inserting a value into a list:

    a.insert(i, x)

With the way that the Go docs suggest:

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

Sorting and for-range loops are other examples.

I prefer to the Go way. The python way gives people the impression that the insert operation is cheap. In fact, it is not.

WTF?! Isn't the point of an abstraction to make simple what is complex? Insert into a list should always be like the python example. If go's standard list doesn't have that, maybe it's time for someone to write a better library.

That's one of the things in my original comment.

Although I agree with you about some basic things in Go such as insertion being somewhat crazy, but there's a point I want to make about abstractions.

Abstractions that hide too many things away are not always a good thing.

If an abstraction makes something easier to write, but harder to read, that's not a very good thing.

Unfortunately Go does not exactly hit the sweet spot. It errs on the side of less expressive power.

EDIT:

Actually, for inserting into a list, the code can be simple, although the line will be split into three lines, and creates a new temporary list

// insert number 10 into position 2 var b []int b = append(b, a[0:2]...) b = append(b, 10) b = append(b, a[2:]...)

https://play.golang.com/p/ommopBd3io

Now, that _is_ overly verbose, but I don't think it's too off putting. I don't like it but I guess it's a quirk of go I'm willing to put up with.

The insertion operation on slices is expensive and is not recommended to be used frequently. If you use it frequently, please rethink and redesign your data structure, for example, use a list instead.

I tried using Go this weekend and basically just abandoned it when I learned that it only had 'generic's for three built-in types and other than that you are forced to essentially dynamic cast everywhere.

I just don't get the appeal. Go seems a lot like what you'd get if you just removed every language feature that anyone has ever complained about; for good reason or not.

It seems like the domains where Go is used often don't make heavy use of custom containers or data structures, so that makes the pressure on the language makers lower than it would otherwise be.

Or the other way around.

I venture to say that if you are casting/converting everywhere, you are likely doing it wrong. An interface{} says nothing. It should generally be avoided. However, I do find this to be a pain when working with numbers. Floats and ints mixed up is not fun. Python is so vastly easier to work with in that arena.

In Go, if you need a container which is not a built-in map or array, you end up casting to interface{}, because that's the only reasonable thing your container can accept. This is clearly not "doing it wrong", and it's an extremely common use case.