<i>Go has a way of programming. Go is totally optimized for that way of programming, in fact. Programming any way other than Go’s way, with Go, will be that recipe for frustration I bounced my skull against. Go’s way is not pretty to someone indoctrinated with the modern functional aesthetic, but it works, and works well. Really well.</i><p>A good summary of programming in Go.<p>However I would like you to give some examples of inconsistencies in Go. And I believe that leaving features out ("anything a modern programming language is supposed to include") makes Go cleaner, safer and more understandable than any other language I know of (IMO).
"Go has a way of programming. Go is totally optimized for that way of programming, in fact. Programming any way other than Go’s way, with Go, will be that recipe for frustration I bounced my skull against."<p>I think this is something a lot of people think when they first come to Go. Especially if you come from a higher lang like ruby or js or something since on other places on the net its kind of being marketed as a nodejs alternative. However, in my experience the "frustration" hasn't been there at all. I came from c and I think you get basically just a vamped up "better" (I know bad word) c. I love having multiple return vals and error handling in my returns and message passing and threading to any types is so easy in Go it just makes life nicer.<p>These are all my biased opinions as an avid Go user of course, but honestly I find the language extremely expressive and powerfull, and not really that it forces you to do something the Go way, other than the sense that yes you need to know the syntax and not have type errors etc, but this is the case with every language.
Woo Woo Woo...Am I missing something or isn't PHP also a back-end language?<p>About the article, I think you are just doing it wrong. I personally never used Go, like I never used many other languages, but I tried many. Everyone has it's own way, just because one does things differently and not your way doesn't mean it's wrong. It means is different. You know...taste...
>Idiommatic Go is to have several lines of boilerplate after every single function invocation which can possibly fail.<p>This is an issue in every language. If you want to do something that might fail, you have to handle the possibility of failure. There are only two ways to handle this - return values and exceptions - and they differ in style more than in functionality.<p>So what is this guy suggesting? Does he want Go to have exceptions? Or does he want every function to magically succeed somehow? I don't enjoy writing error handling either but I see no way around it.
>PHP is horribly inconsistent, breaks all the rules about programming language design, and is infuriating.<p>Some say that rules are made to be broken. In the context of Go, Rob Pike argues exactly that in this short talk on why they made Go: <a href="http://www.youtube.com/watch?v=5kj5ApnhPAE" rel="nofollow">http://www.youtube.com/watch?v=5kj5ApnhPAE</a>
Rarely do I get to read articles that are that low on substance, facts or concrete examples. What is a "Go's particular way" and how does it differ from the author's way? What are these 'particular' structures and behaviour? What is this "particular way", and again "particular way", of solving design issues? Is it like Fight Club?
>PHP is horribly inconsistent, breaks all the rules about programming language design, and is infuriating.<p>I stopped reading upon the first bold statement.
I enjoyed the article but came away frustrated by one thing -- it offers <i>specifics</i> about the problems with Go, but only <i>generalities</i> regarding what is good about Go.<p>I haven't tried Go, but I'm aware of things that seem like short-comings to me (most especially, the lack of exceptions). So I understood the first part of the article.<p>The second part was vague ... I could tell that the author decided that all those problems were OK, but I don't really know how that happened. He chalked it up to the "way of Go". I'd really like to hear some concrete descriptions of what that is.
> [go] gets out of your way and make building [services] easy<p>> stop programming <i>my</i> way, and start programming Go’s way<p>These are inconsistent assertions fundamental to the point the article tries to make.