This is a false dichotomy. One does not imply the other.
Go is also not a simple language. It is deceptively difficult with _many_ footguns that could have easily been avoided had it not ignored decades of basic programming language design.
Many things also aren't straightforward or intuitive. For instance, this great list of issues for beginners: http://golang50shad.es/
You know what's a footgun? Uncaught exceptions popping up in places far away from where they were created at which point you have very little context to deal with it robustly. Use after frees. FactoryFactoryFactories.
Uncaught exceptions -> panics, like what this nil catcher is aiming to solve
Places far away -> easy goroutine creation with no origin tracking makes errors appear sometimes very far away from source
Use after free -> close after close
FactoryFactoryFactories -> loads of BuilderFunc.WithSomething
Lots of other pains I could add that are genuinely novel to Go also, but funny that for everything you mentioned my head went “yep, just called X”
You're right, I meant to link that in reference to how Go can be difficult to learn despite how it simple it seems. Not sure how I a sentence.
The overview of that site explains its purpose/necessity quite well. Some things are footguns, many are just confusing time-wasters. Nevertheless, they are frustrating and hamper the learning process.
But that is the learning process. What else is there to learn in a language if the syntax doesn't count? They're all Turing complete and all of them can do everything. All we need to do is learn the exact magic words.
No it isn't, and yes it does. By definition, the more features I add to something, the more complex it becomes. So yes, Go achieves it's simplicity precisely by leaving out features.
> this great list of issues
I just picked three examples at random:
"Sending to an Unbuffered Channel Returns As Soon As the Target Receiver Is Ready"
"Send and receive operations on a nil channel block forver."
"Many languages have increment and decrement operators. Unlike other languages, Go doesn't support the prefix version of the operations."
All of these are behavior and operators that are documented in the language spec. So how is any of these a "footgun"?
More complex for whom? Not having generics made the compiler simple, but having to copy and paste and maintain identical implementations of a function (or use interface) adds more complexity for users.
Similarly, adding a better default HTTP client arguably makes Go more complex, but the "simple" approach results in lots of complexity and frustration for users.
> All of these are behavior and operators that are documented in the language spec. So how is any of these a "footgun"?
Perhaps I could have been clearer. I didn't mean that the entire list was of footguns, just that there are lots of confusing and unintuitive things beginners need to learn.
Some actual footguns off the top of my head:
- using Defer in a loop
- having to redeclare variables in a loop
- having to manually close the body of a http response even if you don't need it
I literally can not imagine a worse behavior than my program blocking forever. Of all of the things my program can do, short of giving remote code execution, blocking is literally the worst one I can think of.
Yes, and go opts to include features that unnecessarily increase complexity in this manner, such as nil values.
> All of these are behavior and operators that are documented in the language spec. So how is any of these a "footgun"?
By this logic, no language with a spec can have footguns. C and C++, notorious for their footguns, both specify their behavior in the spec, so do they not have any footguns?
