[_ph_]

And I am so happy that they won't do anything but the right thing.

Over the decades as a programmer I have seen a lot of language come and go. A lot of languages suffer from "features". Where either a language is designed with advanced concepts getting either directly in the way of writing simple programs, or even worse, getting bolted on later on, creating something very different from the initial language.

I love the dependable simplicity of Go. It contains everything I need for a surprisingly large part of my work and not offering more than that is an asset. Few things in Go feel like they had been thrown in without proper consideration.

[richardwhiuk]

> And I am so happy that they won't do anything but the right thing.

That's clearly not true - they've made plenty of mistakes.

[_ph_]

My statement was obviously inverting the statement the poster made I answered to and was meant abstractly. They did very hard try to only do the right thing and did not include a feature just for the sake of having that feature.

Of course, any humans are making mistakes in the process nevertheless, but overall I think they got it pretty much right.

Having said that, I would be curious what you have in mind when saying that they made plenty of mistakes?

[jagger27]

The only big one that comes to mind is GOPATH. What are you thinking of?

[int_19h]

No immutability. Nullability by default, and weird corner cases like nil slices and interfaces. Language semantics requiring weird stack discipline that is incompatible with normal ABIs, and causes overhead when you need to interop.

But frankly, just the design of append() alone should be a warning sign. If it were a low-level facility, fine, it's only needed to be understood by whoever's writing a library to wrap it for general consumption. But it's the idiomatic Go way of maintaining a sequential mutable collection! How is such a basic operation is so non-obvious that people still write articles to explain it, and so verbose that you must reference the collection twice to make it work right?

(Indeed, the language itself kinda acknowledges how clumsy it is, by making it an error to ignore the return value of append(). But, as usual with Go, it's hardcoded - i.e. you can't do the same for your own function. And IIRC, it wasn't there from the get go, but got added somewhere along the line.)

[_ph_]

Besides never being an issue for me, GOPATH isn't strictly speaking a langauge issue, but an issue of the build environment, which will no longer be the default with Go 1.13.

What is your issue with GOPATH, that you call it a big one?

[flavio81]

>I love the dependable simplicity of Go.

If you like Go, you'll love the simplicity of Brainf-ck, a clean design which is easy to learn, simple syntax, and supported in almost all computing platforms.

[_ph_]

Sorry, I don't see how your comment contributes to the discussion. You have heard of C? A language which most of the Unix infrastructure is built upon? It turns out, Go is a language, which keeps a lot of virtues of C, adding just enough to it to fix some of the shortcomings of C, adding more safety and convenience.

[flavio81]

>You have heard of C?

I'm an experienced C developer.

>which keeps a lot of virtues of C

No, C doesn't have many virtues. It's major virtue was getting close to being a macro assembler, and Go removes that completely. Go tries to be a higher-level-than-C language with good execution speed, but that goal was already achieved perfectly by Object Pascal, D, Ada, and Common Lisp.

[joelfolksy]

The brainfuck quip is a bit more potent when the Go advocate in question has made it clear that they think language simplicity and code simplicity are equivalent. That didn't happen here, but it's tempting to assume that's what the advocate is thinking when they praise language simplicity so much.