“Everything should be made as simple as possible, but no simpler.” I’ve often felt Go went too far trying to make everything simple, to the point that it’s wrapped around and made things complex.

"Civilization advances by extending the number of important operations which we can perform without thinking of them." --Alfred North Whitehead

Go forces writing loop for removing an element from an array even if the programmer knows it's linear time. Ruby gambles that programmer isn't ignorant - or it's not critical - but allows the convenience every time.

Designing languages is hard.

> Go forces writing loop for removing an element from an array

It does not:

copy(a[i:], a[i+1:]) // Shift a[i+1:] left one index.

a[len(a)-1] = "" // Erase last element (write zero value).

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

Having worked a lot with at least a dozen languages, this is definitely on the cumbersome side of the spectrum. And a sibling comment says it doesn't even do what it says on the tin. In what other language does it take two devs to remove an element from an array?

Your code removes by index. This can be done in one line in Go:

    list = append(list[:i], list[i+1:]...)

but to remove by value you need a loop.

This makes it very unclear what's going on. I had to test it to find that this specific use is special cased to not copy. And very surprisingly you don't even have to assign back to the same variable to get this no-copy behavior!

Edit: I didn't do my test quite right. It's not really special-cased. But it's still very surprising to see this happen:

Code:

    s1 := []int{1, 2, 3, 10, 11, 12}
    s2 := []int{4, 5, 6}
    s3 := s1[:2]
    s4 := append(s3[:2], s2...)
    fmt.Println(s1)
    fmt.Println(s4)

Output:

    [1 2 4 5 6 12]
    [1 2 4 5 6]

Yup.

Simple! But not easy. Go is absolutely filled with nuggets like this in my experience. False-simplicity is deeply ingrained in the standard library as well: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...

This is a Go idiom, one of the "slice tricks" that you are expected to just know. In fairness every language has its non-obvious idioms.

It may or may not copy.

It’s crazy that the function you call to remove an element from a list is `append`.

If you come at it with the thought that you are creating two sublists (on each side, avoiding the index) you then need to merge them back together. That append reads to just recreate the list from the two parts.

When I see that, I have no idea if it allocates a new array or if it's in place. Which one is it? At least with a delete function it's clear.

In Go it may or may not allocate a new array; it depends on the array's capacity. This means that the resulting slice may or may not alias the original slice.

See this playground for an illustration: https://play.golang.org/p/mOpuGVj2ypG

That uses append to delete, and then modifies element 0 in the result. In the first call, only the new slice is modified. But in the second call, both slices are modified, since they share the same backing array.

I consider this to be one of the worst mistakes of Go, to design a highly multithreaded language in which variable aliasing is a dynamic property. I am convinced that many Go programs have latent races and bugs, invisible to the race detector, and they have not yet been tripped because they have been (un)lucky with the runtime's capacity decisions.

you are right that a loop isn't required, but the point that kind of index / array element juggling is a headache still stands

A lot of the things in Go that seem horrible seem simple if you are used to the slice syntax used in Python and other langs, which I am not.

removing an element from a slice is trivial if you don't care about order. Just swap the element you want to remove with the last element and truncate the slice. If you want to maintain order, shift all the elements following the one you want to remove left one and then truncate. The latter can be slow if the slice is large, but it's linear time.

OP isn't asking for a solution. OP is talking about not having to implement the solution themselves and having the language provide some shortcuts for doing what you just described.

People need those shortcuts so they don't reimplement them over and over. Not having the leftpad as part of the language or standard library is what caused the problem. This is exactly the problem the article talks about.

>Not having the leftpad as part of the language or standard library is what caused the problem.

There are a few other comments in this tree making the same claim - is this what most people took away from the left-pad incident?

To me, the stdlib lacking left-pad is a fairly distant cause. You could make the same case for any popular library, but that road leads to a bloated stdlib, which forever will haunt us. The more relevant causes, in my book, are:

1. Many builds relied on pulling left-pad directly from NPM

2. NPM allowed left-pad to be unpublished

I like to compare this to the usual practice in the Java world:

1. The primary repository in use is the Maven Central Repository. Nobody can unpublish a library from it. This is specifically to avoid pulling dependencies out from under consumers of those dependencies.

2. Most Java shops run their own repository. This serves both to caches requests to the Maven Central Repository, and to provide a fail-safe in case something were to happen to Maven Central. Backing up dependencies is considered as important as backing up your own code. Sometimes vendoring is used as an alternative approach.

Leftpad was a result of making libraries (comically) small. If you have a bunch of convenience operations, you can put them all together into a single utility library (or even the standard library).

Leftpad was a result of the JS standard library being terrible and not providing built-ins for such simple, common things.

And Go is the same way...

If the leftpad functionality was part of JS by default it wouldn't have happened.