This is why I like Go and hope they don’t ruin it with a poor generics implementation. It fits in my head. My other usual language is C# which is starting to feel like a London bus at rush hour with feature burden.
You may not want more powerful languages, but as soon as a single person wants the power, they'll craft it themselves no matter what (and then it may end up being one of your dependencies :-) and the effect will be pretty much the same - you'll have to work with generics anyways, but with homebrew instead of "official" ones).
So I am very very not convinced by the thesis exposed in that article - people will use whatever tool they find to automate what they think is automatable in the process of writing programs, even if that means creating ad-hoc AutoHotkey scripts that type repetitive macros according to a certain pattern (true story :-)).
Having more powerful languages means that you have to spend much less time trying to inspect whatever eldritch horror combination of tool the people before you used there as you just need to check the language docs or StackOverflow.
It's certainly possible for individuals to swim against the current. I am not a Go programmer but all the Go open source code I have read has been brutally simple and easy to consume. I don't think that's a coincidence.
I'm a Go programmer and I can confirm that Go code (both written by me and by anybody else) is easy to read, debug and refactor. This is thanks to simple yet powerful Go syntax, which doesn't allow constructing implicitly executed code. I.e. it doesn't support the following "features" from other programming languages, which instantly increase code complexity because it becomes impossible to understand the code by just reading it top down:
* Operator overloading
* Function overloading
* Constructors and destructors
* Implicit type conversion
* Implicit types (classes)
Go also doesn't support type templates and function templates yet (aka generics or contracts). This also plays significant role in easy-to-read Go code.
P.S. I wrote many packages and apps in Go during the last 10 years [1] and I absolutely love Go! Check out my last project in Go - VictoriaMetrics - fast time series database and monitoring solution [2].
As a C++ developer, highlighting the lack of destructors made me curious how resource closure is typically handled in Go. A brief review suggests that it is often handled using a "defer statement", which accumulates a stack of statements to be executed when the function returns, to execute a 'close()' method. While I can see some benefit to the explicit appearance of "defer" in the source code, I think it is outweighed by the risk someone forgets to write it (or tries to close something without defer but misses a path). The execution of a destructor is inevitable and automatic.
The main issue with destructors is that it is impossible to determine by reading the code which destructors in which order at which lines may be called. Actually, destructors can be called on every line of C++ code because of exceptions. This complicates understanding code flow and makes almost impossible to write exception-safe C++ code, which properly releases resources at any exception.
While Go supports exception-like panics, they are mostly used for really exceptional cases, when the program cannot proceed further, such as out-of-range slice accces or nil pointer dereference. Almost all these cases are triggered by programming errors, which must be fixed after the panic occurs. Traditional error handling is performed explicitly in Go instead of relying on panics - the error is checked explicitly after function call. This simplifies code reading and makes easy to spot cases with missing or incorrect error handling. These tasks are almost impossible with try/catch error handling.
> The main issue with destructors is that it is impossible to determine by reading the code which destructors in which order at which lines may be called.
huh ? the destructors are just in reverse order than the declaration order
C# is a really bad example to say Go is good. I always felt people were too lazy to explore proper alternatives. People don't like something in C# or Java and jump to go because you can learn it in a day instead of investing 2 days to write in Rust or Erlang or Haskell or Ocaml or whatever. Go is just a better C with coroutines
