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 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.