> You do not know what you are talking about. It is very clear (based on the above statements) that you have minimal, if zero real computer science education.

> You do not know what you are talking about. It is very clear (based on the above statements) that you have minimal, if zero real computer science education. I don't know why you're attacking me personally. I went to a UC school with a great computer science program and have a masters degree... does that count? > Not having generics / sum types, etc., do not disqualify Go, as those are merely semantic conveniences in other languages. Sure, and Go is merely a collection of semantic conveniences over Brainfuck, it's Turing Complete, so what do we need Go for? The point is that Go heavily limits a programmers ability to create new abstractions and write reusable algorithms. For writing glue code, cli tools, or web services, that's probably fine. But there's a purpose behind those pesky data structure and algorithms they teach you in school, and when you run into what I consider to be the "real problems" Go is not a "real language" that can tackle those problems without the same pain as Brainfuck. > actually their presence in a language would cause me to reevaluate said programming language This is completely ridiculous. I hope you realize this statement is completely ridiculous. Just because a language has something you don't understand or don't find useful doesn't disqualify it from being a better language than Go. You have your own blinders on. > Go is a breath of fresh air that is badly needed. Go appeals to the lowest common denominator. In fact, one of the goals was to come up with a language that new grads coming in to Google could easily pick up. It's designed to appeal to new people. This is fine, Go is a great language for a lot of small tasks. But as you grow as a developer, you need to tackle larger problems. Go is not a language that facilitates tackling larger problems. > Please stop with un- or ill- informed FUD. You certainly need a dose of skepticism. Radically following one language or one technology isn't a good move for an engineer. Go has flaws, and if you can't discuss them then you're not separating the technology from an argument from emotion.