It's not that golang is bad, just that it's not good. Understanding the difference between those two is understanding why golang is popular, why Java is popular, why C is popular, why any number of other mediocre things are popular. Golang gets a lot of stuff right, but most of the stuff it gets right isn't to do with the intrinsic design of the language.
Golang is good only insomuch as C is good, because it's clearly inspired by C. That's why golang is popular, because it's very similar to something everyone already knows. The switching cost is low and the tooling is really nice. Some things are nicer than in other C-like languages, some things aren't. The bottom line is that language innovation these days is largely not happening in C-like languages, so most language innovations aren't popular. Languages like Swift subvert this rule, however Swift has its own (arguably more influential) corporate backing.
Go isn't bad, it's easy. Very easy. Easier than almost everything else. That's why it's popular.
Because it has a few fundamental quirks that make it a poor choice for enormous systems. It uses mutable data by default, the type system is not all that strong, and it has no facilities for making abstractions due to it being too simple. The developers of golang consciously throw out like 30 years of research in programming language theory because the idea of a language that gets "back to the basics" is appealing to a large group of (mostly good, experienced) programmers even though it's not a particularly good idea.
The first answer to this Quora question by one of the developers of D explains a few other points and also what golang is really good at:
All of the most popular languages have mutable data by default. 99.99% of all enormous systems were written with mutable by default languages.
The type system not being "strong" simply means that you put logic in functions and methods instead of magic parts of the type system.
And Go can absolutely make abstractions. The standard library is full of abstractions. Every Go package is an abstraction. Hell, every function is an abstraction.
Not so bad. And the one I'm working on in Go is definitely helped by being in a simpler language. I don't really think immutable data would be a huge boon to maintainability. Some sure, but I think it would also complicate some of the code.
So you think syntactical simplicity is more important to the maintainability of a large system than whether or not it uses immutable data? Ok.
Because immutability is a massive boon to horizontal scaling and maintainability in ways that are simply unattainable in languages where it's not encouraged. It makes concurrency and parallelism observably trivial, it makes your code safer. Assuming you're using a strictly evaluated (AKA eager, greedy, whatever else you know to mean not-lazy) language with immutable data, race conditions are eliminated.
Let's review that again. In a large distributed codebase written in an immutable language, (let's say Elixir, it's fashionable at the moment and good for doing this kind of stuff) concurrency and parallelism are trivial and race conditions are nonexistent. This is even before we get to type safety and stuff like the actor model. That's huge. That's the immutability advantage. I could go on but it's late and I have school tomorrow.
Comments
It's not that golang is bad, just that it's not good. Understanding the difference between those two is understanding why golang is popular, why Java is popular, why C is popular, why any number of other mediocre things are popular. Golang gets a lot of stuff right, but most of the stuff it gets right isn't to do with the intrinsic design of the language.
Golang is good only insomuch as C is good, because it's clearly inspired by C. That's why golang is popular, because it's very similar to something everyone already knows. The switching cost is low and the tooling is really nice. Some things are nicer than in other C-like languages, some things aren't. The bottom line is that language innovation these days is largely not happening in C-like languages, so most language innovations aren't popular. Languages like Swift subvert this rule, however Swift has its own (arguably more influential) corporate backing.
Go isn't bad, it's easy. Very easy. Easier than almost everything else. That's why it's popular.
The Go language is an excellent tool for shipping maintainable server-side applications.
Maintainable in the short-term.
What makes you say that?
Because it has a few fundamental quirks that make it a poor choice for enormous systems. It uses mutable data by default, the type system is not all that strong, and it has no facilities for making abstractions due to it being too simple. The developers of golang consciously throw out like 30 years of research in programming language theory because the idea of a language that gets "back to the basics" is appealing to a large group of (mostly good, experienced) programmers even though it's not a particularly good idea.
The first answer to this Quora question by one of the developers of D explains a few other points and also what golang is really good at:
https://www.quora.com/Which-language-has-the-brightest-futur...
All of the most popular languages have mutable data by default. 99.99% of all enormous systems were written with mutable by default languages.
The type system not being "strong" simply means that you put logic in functions and methods instead of magic parts of the type system.
And Go can absolutely make abstractions. The standard library is full of abstractions. Every Go package is an abstraction. Hell, every function is an abstraction.
And are they easy to maintain?
Not so bad. And the one I'm working on in Go is definitely helped by being in a simpler language. I don't really think immutable data would be a huge boon to maintainability. Some sure, but I think it would also complicate some of the code.
So you think syntactical simplicity is more important to the maintainability of a large system than whether or not it uses immutable data? Ok.
Because immutability is a massive boon to horizontal scaling and maintainability in ways that are simply unattainable in languages where it's not encouraged. It makes concurrency and parallelism observably trivial, it makes your code safer. Assuming you're using a strictly evaluated (AKA eager, greedy, whatever else you know to mean not-lazy) language with immutable data, race conditions are eliminated.
Let's review that again. In a large distributed codebase written in an immutable language, (let's say Elixir, it's fashionable at the moment and good for doing this kind of stuff) concurrency and parallelism are trivial and race conditions are nonexistent. This is even before we get to type safety and stuff like the actor model. That's huge. That's the immutability advantage. I could go on but it's late and I have school tomorrow.
I very much dislike that invalid states are left representable in idiomatic go error handling.