[kubb]

Considering the confusion of the author, it seems like not all junior programmers can understand Go, which makes me wonder: is it simple enough?

One pitfall is when getting a slice by value in a function. You cannot be sure that someone is not going to pass you a slice into a buffer that they themselves use, so you have to be careful when appending - someone might be using that buffer and you’ll be writing over it.

[kansface]

I don't feel its a matter of complexity per se, more like bad UX. We could imagine exposing why this doesn't work to end users instead oh hiding behind a leaky abstraction.

[masklinn]

> which makes me wonder: is it simple enough?

Obviously not given Go was never simple in the first place. Go was built to be easy — for a certain value of easy.

Simple tools are often not easy, and simple programming languages are definitely not easy: they tend to be built out of a small set of very powerful concepts which are directly exposed to the language user, said language user has close to the power of the language designer in building abstractions. Lisps, and Smalltalks and Forths are simple, which means they are mind-bending and not only can you build what you want out of them (hello turing equivalence) you can build how you want.

And of course the simplest of languages (the turing tarpits) are barely usable at all.

[kortex]

Continuing that thought along the line of "Simple made easy," I think ease has a simplicity all its own.

A simple language, e.g. C or lisp, simple in that their grammar is simple, are definitely less easy for the programmer, than say Go. But C is not simple as an experience, since it forces the dev to mentally complect so many concepts in order to get things done: macros, memory management, etc. Lisp is complex in a different way: metaprogamming, DSLs, and deep abstractions are the norm. So simplicity/complexity tends to be something of a whack-a-mole. It's a lower bound, much like the uncertainty principle; you can always add complexity.

Go makes a lot of choices that try to really optimize the user_complexity * language_complexity product.

[skybrian]

There are conventions that help, but they could be made explicit:

- If you don't know where a slice came from (such as getting it passed as an argument), treat it as read-only. Any exceptions should be documented.

- If you're going to mutate a slice, make it a private member of a struct and don't give out direct access to it.

[gobookdev]

No it's not, it can be even simpler, but it's a great start and evolution