Problems with Go's design

In fact, that enabled automatic tool to convert Go compiler written in Google's C++ to Go.

In other words, click-bait. Oh, you think I use the term lightly? For an article that boils down to "things about Go that aren't particularly wrong, but I don't like", the author concludes with "I hate the language: it’s absolute crap". Really? Because when you throw the kitchen sink into your imports "just in case", it won't compile? (I pick on this particular example because dragging along imports you're not even using just strikes me as sloppy, hence coloring my view of the author.)

It's one thing to state, "I would have done this differently for these reasons", but to call the whole bundle "absolute crap" just reeks of some n00b who learned a single dynamic language, switched to Go, and had a hard time figuring out why his crap code wouldn't compile.

Like most other languages, Go is neither great nor bad; it's just another tool designed by people to solve a specific set of problems -- in Go's case, people who in the past have had to develop very, very large, complicated systems with lots of concurrency. For projects like that, Go would be a great choice; for other projects, it might not be.

In some circumstances even Ruby can be a better choice than Go for high concurrency. I recently read a post on HN in which the author (someone with an Erlang background) lays the reasons why he chose Ruby for a highly concurrent application. When I first saw the link, my immediate thought was, Ruby!!?? But then I read the post and the reasons were all very sensible and practical-minded, so in that case Ruby was arguably a much better choice than Go, Erlang, Scala, Rust, and the like.

Here's the post: https://news.ycombinator.com/item?id=10394450 (direct link: https://github.com/rustyio/super-imap#why-ruby) -- I really liked the rational, practical, 'non-religious' tone.

Suggestion: don't call Go or any other popular language "poorly designed" with a short blog post. Instead, say "it doesn't fit my current needs."

So given an interface Foo and a struct FooImpl which implements Foo, why can't we pass a slice of []FooImpls to []Foo? It's because the creators of Go are lazy and arrogant and incompetent and don't care right?

No. Consider the situation where a []FooImpl is passed to a function F(f []Foo). This function decides to change one of the elements of the slice to a different implementation, say FooImpl2, eg. f[0] = FooImpl2{}. Now the original slice of []FooImpl's has a FooImpl2 in it. Oops, we broke type safety. Now consider what it would take to make this work - you'd have to somehow guarantee that functions which take []Foo don't mutate the slice. Is that possible? Is it possible to do quickly, and still have a language that compiles very quickly? Or we could introduce "const" and all those things from C++ but that's a whole new level of complexity to the language. And what about the performance penalties? A struct is a different size than an interface, so what code is emitted during compilation, something that can handle iterating over []your_interface and []your_struct?

So next time you think "Gosh, this bit of Go really sucks" take a moment and think about why it was designed that way. Because the fact is, it was almost definitely designed that way, as opposed to just overlooked or neglected. You may not agree with the choice that was made, but with the people who work on Go, I can guarantee that there was a conscious choice that was agonized over and discussed endlessly, just not with you in the room.