The Google name surely gets a lot of people's attention. But if the language actually sucked, it's not going to matter. This is a tool that you have to use EVERY DAY. The Google name is far from a guaranteed hit maker. See Google Plus, Google Wave, etc.
That's like saying Dale Earnhardt could recommend driving a Gremlin... sure, it would get a lot of people to go for a test drive, and a lot of those people would then run away.
I fully admit I clinked on the link to the Go website purely because it was from a big name... the exact same thing I did for Hack and Swift and Rust. But I don't write code in Hack or Swift or Rust. I write code in Go.
Sure, I may have missed some really great language put out by an obscure name that never made it to Hacker News. But then again, evidently so did everyone else.
So why do I write code in Go? Because the language and the ecosystem around it are really good. Because I feel like I can understand any piece of code written in it without needing a PhD from Stanford. Because I feel like it pushes people towards simple, straightforward solutions.
Past that first click, the only thing Google means to me is a guaranteed check to pay the bills of all the great people working on the project.
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
The Google name surely gets a lot of people's attention. But if the language actually sucked, it's not going to matter. This is a tool that you have to use EVERY DAY. The Google name is far from a guaranteed hit maker. See Google Plus, Google Wave, etc.
That's like saying Dale Earnhardt could recommend driving a Gremlin... sure, it would get a lot of people to go for a test drive, and a lot of those people would then run away.
I fully admit I clinked on the link to the Go website purely because it was from a big name... the exact same thing I did for Hack and Swift and Rust. But I don't write code in Hack or Swift or Rust. I write code in Go.
Sure, I may have missed some really great language put out by an obscure name that never made it to Hacker News. But then again, evidently so did everyone else.
So why do I write code in Go? Because the language and the ecosystem around it are really good. Because I feel like I can understand any piece of code written in it without needing a PhD from Stanford. Because I feel like it pushes people towards simple, straightforward solutions.
Past that first click, the only thing Google means to me is a guaranteed check to pay the bills of all the great people working on the project.
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.