divarvel/gist:10820327

## gistfile1.txt

Tikhon Jelvis, consistency is all I ask
Votes by Jed Wesley-Smith, Scott Danzig, Gregory Popovitch, Toby Thain, and 111 more.
Most modern and well-featured? Hah! It's hard to tell it wasn't design 30 years ago. Go completely ignores most recent advances in programming languages in order to seem more similar to C. Charming.

Yes, there are drawbacks you're not seeing. But, more importantly, there are better alternatives you're ignoring. While some of the problems with Go are certainly actively detrimental, the bigger story is opportunity cost: you're missing out on some more capable, more expressive and safer languages.

So lets take your question in two parts: Go's drawbacks and then better alternatives.

Drawbacks
Go has some very concrete design problems. Many of these were added on purpose, either to make the language more like C or to make the implementation simpler. I've written about my main issues with Go's design before: Tikhon Jelvis' answer to Go (programming language): Do you feel that golang is ugly?

Since you can just read that—and many of my concerns are similar to Costya Perepelitsa's—I'll just cover them briefly.

One of the most consistent themes in Go is that most things you can make as a user are second-class citizens. The core types and constructs (arrays, error handling, primitive types, maps... etc) are all built in and magical. You simply can't build a data structure with a similar interface to Go's maps. In fact, thanks to a few language design issues, you simply can't have a good library of data structures at all without significant design compromises! That is not the hallmark of a modern or well-featured language.

I always highly recommend people watch "Growing a Language", which is the best programming languages talk I've ever seen. The best CS talk, even. This explains the above problem more eloquently as well as talking about why it's a problem and how to design languages with that in mind:
The funny thing is that Go gets half way to this philosophy. They did try to design a small core language and follow the "less is more" philosophy. They just forgot the "more" part.

Apart from this, the way Go does error handling is... decidedly odd. I'm all for not using exceptions—it makes sense to have an error returned from a function, just like a normal value. This lets you simplify the design and avoids baking error-handling into the language. Of course, Go bakes it in anyhow...

Generally, the idea behind return value error-handling is simple: you either have the correct result or and error. So what does Go do? It always gives you both. If there's an error, the return value is garbage. Right.

I could go on. And I did, just in the other answer ;).

Also, as usual, lambda-the-ultimate has a good thread discussing Go's design. I think it's very enlightening.

I hope that covers the first part of your question: Go does have serious drawbacks.

Alternatives
But even if Go fixed many of these issues, it still wouldn't be the most modern or well-featured language. There are just too many competitive alternatives!

This is especially true for the faux-systems space Go resides in: non-optional garbage collection, limited low-level access... etc. It's a server language, and we already have a ton of great server languages from Java to Scala to Clojure to Python to Erlang to C# to F# to OCaml to Haskell. There's no way Go is somehow more modern or well-featured than any of these, much less ones I forgot to name.

Moreover, some of these languages offer things that are new, innovative and very useful. Go, on the other hand, doesn't bring much new to the table at all. Some people profess to like this, but it hardly screams "modern" or "well-featured", does it? One of the reasons Go is seeing a fair amount of uptake is because many people find it easy to learn, and many people find it easy to learn because it's actually not all that different from what came before.

This list also includes a few languages that excel at Go's main strong point, concurrency (especially with green threads). Erlang is well known in the space for making extremely scalable and fault-tolerant services based on cheap processes. Haskell has an exceptional green thread system with far better concurrency abstractions than Go like software transactional memory (that actually works well!) and deterministic parallelism¹.

That's what I would expect from the "most modern" and "well-featured" language. Not a dearth of data structures and rebranded CSP. Not compromising on safety and expressiveness to make the compiler simpler.

A particularly interesting case study is OCaml, which is a good counterpoint to Go in every way except concurrency. (OCaml really sucks at concurrency for some reason.) It compiles quickly, produces fast binaries but manages to  be at a higher level than Go while retaining generics and having full type inference. It even has many of the same type-system features, like  structural sub-typing. (Which is what Go interfaces are.)

Also, to be clear, I'm not saying that Go is completely horrible, impossible to use or the worst possible choice. It's indescribably better than PHP. I agree with Costya that it's better than Java. (I'm a bit more reserved about C#, which is a surprisingly well-designed language.) It's even better than C++ for application-level tasks. But then, you shouldn't have been using C++ for that in the first place.

But I am saying that Go is flawed and that it's largely a worse choice than a bunch of alternative. It's not absolutely horrible, but it's at least below average. I find this deeply contrasted with how much it's been hyped the last few years.

footnotes
¹ Last time I mentioned "deterministic parallelism" in an answer, people were a bit confused by what I meant. Basically, Haskell lets you evaluate an expression in parallel and guarantees that the result is correct. No nondeterministic bugs, no deadlock, no race conditions, nothing. It might not actually be faster for being parallel, but it won't be wrong.

	Tikhon Jelvis, consistency is all I ask
	Votes by Jed Wesley-Smith, Scott Danzig, Gregory Popovitch, Toby Thain, and 111 more.
	Most modern and well-featured? Hah! It's hard to tell it wasn't design 30 years ago. Go completely ignores most recent advances in programming languages in order to seem more similar to C. Charming.

	Yes, there are drawbacks you're not seeing. But, more importantly, there are better alternatives you're ignoring. While some of the problems with Go are certainly actively detrimental, the bigger story is opportunity cost: you're missing out on some more capable, more expressive and safer languages.

	So lets take your question in two parts: Go's drawbacks and then better alternatives.

	Drawbacks
	Go has some very concrete design problems. Many of these were added on purpose, either to make the language more like C or to make the implementation simpler. I've written about my main issues with Go's design before: Tikhon Jelvis' answer to Go (programming language): Do you feel that golang is ugly?

	Since you can just read that—and many of my concerns are similar to Costya Perepelitsa's—I'll just cover them briefly.

	One of the most consistent themes in Go is that most things you can make as a user are second-class citizens. The core types and constructs (arrays, error handling, primitive types, maps... etc) are all built in and magical. You simply can't build a data structure with a similar interface to Go's maps. In fact, thanks to a few language design issues, you simply can't have a good library of data structures at all without significant design compromises! That is not the hallmark of a modern or well-featured language.

	I always highly recommend people watch "Growing a Language", which is the best programming languages talk I've ever seen. The best CS talk, even. This explains the above problem more eloquently as well as talking about why it's a problem and how to design languages with that in mind:
	The funny thing is that Go gets half way to this philosophy. They did try to design a small core language and follow the "less is more" philosophy. They just forgot the "more" part.

	Apart from this, the way Go does error handling is... decidedly odd. I'm all for not using exceptions—it makes sense to have an error returned from a function, just like a normal value. This lets you simplify the design and avoids baking error-handling into the language. Of course, Go bakes it in anyhow...

	Generally, the idea behind return value error-handling is simple: you either have the correct result or and error. So what does Go do? It always gives you both. If there's an error, the return value is garbage. Right.

	I could go on. And I did, just in the other answer ;).

	Also, as usual, lambda-the-ultimate has a good thread discussing Go's design. I think it's very enlightening.

	I hope that covers the first part of your question: Go does have serious drawbacks.

	Alternatives
	But even if Go fixed many of these issues, it still wouldn't be the most modern or well-featured language. There are just too many competitive alternatives!

	This is especially true for the faux-systems space Go resides in: non-optional garbage collection, limited low-level access... etc. It's a server language, and we already have a ton of great server languages from Java to Scala to Clojure to Python to Erlang to C# to F# to OCaml to Haskell. There's no way Go is somehow more modern or well-featured than any of these, much less ones I forgot to name.

	Moreover, some of these languages offer things that are new, innovative and very useful. Go, on the other hand, doesn't bring much new to the table at all. Some people profess to like this, but it hardly screams "modern" or "well-featured", does it? One of the reasons Go is seeing a fair amount of uptake is because many people find it easy to learn, and many people find it easy to learn because it's actually not all that different from what came before.

	This list also includes a few languages that excel at Go's main strong point, concurrency (especially with green threads). Erlang is well known in the space for making extremely scalable and fault-tolerant services based on cheap processes. Haskell has an exceptional green thread system with far better concurrency abstractions than Go like software transactional memory (that actually works well!) and deterministic parallelism¹.

	That's what I would expect from the "most modern" and "well-featured" language. Not a dearth of data structures and rebranded CSP. Not compromising on safety and expressiveness to make the compiler simpler.

	A particularly interesting case study is OCaml, which is a good counterpoint to Go in every way except concurrency. (OCaml really sucks at concurrency for some reason.) It compiles quickly, produces fast binaries but manages to be at a higher level than Go while retaining generics and having full type inference. It even has many of the same type-system features, like structural sub-typing. (Which is what Go interfaces are.)

	Also, to be clear, I'm not saying that Go is completely horrible, impossible to use or the worst possible choice. It's indescribably better than PHP. I agree with Costya that it's better than Java. (I'm a bit more reserved about C#, which is a surprisingly well-designed language.) It's even better than C++ for application-level tasks. But then, you shouldn't have been using C++ for that in the first place.

	But I am saying that Go is flawed and that it's largely a worse choice than a bunch of alternative. It's not absolutely horrible, but it's at least below average. I find this deeply contrasted with how much it's been hyped the last few years.

	footnotes
	¹ Last time I mentioned "deterministic parallelism" in an answer, people were a bit confused by what I meant. Basically, Haskell lets you evaluate an expression in parallel and guarantees that the result is correct. No nondeterministic bugs, no deadlock, no race conditions, nothing. It might not actually be faster for being parallel, but it won't be wrong.