From my initial dabblings with the language, it feels like its constraints may not actually be a big deal in practice, and may even be more of a help than a hindrance in large projects. It would be nice to get some commentary from more experienced go users.
Initially I felt the same as you: Go was much easier to get things done in, and I could be reasonably productive quite quickly (moreso than Haskell, which I found very difficult to learn).
However, after some time I found many of the same problems mentioned in this article. Particularly, in many cases I had to fall back to the kind of nasty unsafe code mentioned in this article (like using interface{}). Often, I felt that my code was needlessly verbose. I would frequently write code and feel that the language was preventing me from doing what I wanted directly. Ironically, this is exactly how I felt with Haskell at first (not anymore).
Ultimately, I ended up switching to Haskell, and although it was significantly harder to learn, I felt like it has a lot more flexibility, safety, and importantly lends a clarity to thinking when designing a program.
The author's conclusion:
· Go doesn't really do anything new.
· Go isn't well-designed from the ground up.
· Go is a regression from other modern programming languages.
Go makes concurrent programming safe and easy (with a nice syntax) -- something that we frankly should have done 30-40 years ago when we first started thinking about multiprocessing. Go was invented by folks like Ken Thompson (who created Unix) and Rob Pike (who created the Plan 9 operating system and co-created UTF-8). Tell me again that there isn't good engineering behind Go.
Finally, Go attacks the needs of modern programming from a different paradigm than we have been using for the last 10-20 years. From the first paragraph of Effective Go:
> ... thinking about the problem from a Go perspective could produce a successful but quite different program. In other words, to write Go well, it's important to understand its properties and idioms.
So of course it's different than a lot of other aged languages. Go tackles newer problems in a newer way. Tell me again that Go is a regression from other programming languages.
None of the things you mentioned are new.
> Go makes concurrent programming safe and easy
Mutability & concurrency, nils, interface casts -- these things all go against safe.
> Tell me again that there isn't good engineering behind Go.
You seem to think that a language that has baked in syntax for concurrency, or that has famous people behind it necessarily has "good engineering" behind it. I don't understand how one leads to the other.
When so many mistakes and regressions go into a language, one shouldn't care that famous names are behind it.
> Go tackles newer problems in a newer way
Go is essentially Algol 69 with baked in concurrency syntax.
> Tell me again that Go is a regression from other programming languages
Losing null safety, sum types & pattern matching, parameteric polymorphism and type-classes, all form a huge regression in PL design from the state of the art.
You're thinking in terms of "here's this set of bullet point features that I think a language has to have to be a proper, modern language." But the grandparent was asking you to consider that a different set of features might have value form some real-world problems that Go's authors had really bumped into. You reply, "Nope, couldn't have - it doesn't have my bullet point features!"
There are more things in programming than are dreamt of in your philosophy of what a programming language should be.
He said Go makes concurrency safe & easy, when Go emphasizes features that contradict safety and ease.
He said Go tackled problems in a newer way, when Go is really Algol69 + coroutines.
He denied Go regressing from other languages, when it throws away decades of PL research.
In none of this did he say "Here's an alternate set of features that ...". No. He said concrete, specific, wrong things.
What you are saying is a different thing -- and I also disagree with you.
These "bullet list" features weren't invented for the lols. They were created to solve real problems. Problems that Go doesn't have an alternate solution to.
Go programs dereference null. That is a bad thing. Languages with my "bullet point features" do not dereference null.
Go programs duplicate code to handle different types. Ditto.
Go programs can (and thus do!) mutate some data after it was sent to a concurrent goroutine. Ditto.
Go programs can cast down to incorrect types. Ditto.
The "bullet point features" are important. There are alternatives, but Go doesn't sport any of them.
I do agree with the author here: Go the language does nothing new. Go the platform, on the other hand, is a really pleasant new experience when compared with other languages.
The language is a regression in features compared to what other languages can do, but that is totally understandable when you look at what Go is aimed at.
Like putting words into people's mouths as a discussion tactic? You're kidding, right? So it also lacks some not-new "old dependable" gadgets as well. So what? I don't see what point you're making. Did you write that comment just to overlay in indefensible position on me?
As an exercise: Name a language feature Go doesn't have that's newer than generics.
Like putting words into people's mouths as a discussion tactic? You're kidding, right? So it also lacks some not-new "old dependable" gadgets as well. So what?
I love Go, because it fits in my head.
This. I love Go's simplicity. Coming back to Go code I wrote months ago, I can immediately understand what it does virtually every time, which required lots of discipline I didn't always have in other languages. Lots of languages have obscure corners that allow you to do really cool things that aren't obvious, but for the most part, Go doesn't have these; what you see is what's happening.
Are there things that would make Go a better language? Sure! Should the type system be improved? Yup! One thing that makes me cringe is when I open up library code and see interface{} and calls to the reflection package all over the place, but general solutions often require that in Go, and that's a problem. In practice, though, this is almost a feature: if you see that stuff in code you're reading, it's a giant red flag that this code is tricky and possibly slow, and care is needed.
Edit: speeling
I don't think golang invented static linking. ;)
Go does, however, have a very pragmatic feel to it. The creators, in general, seem to take a very measured look at things before adding them, and are very careful to keep the compatibility promise for 1.x. The overall result feels very "engineered" (especially when using the tooling).
Go clearly isn't perfect, but yet it feels rather robust for such a young language.
And while the Hindley Milner type system is a wonder to behold and I love working in languages that have them sometimes those same languages introduce a non-trivial amount of friction to development.
Go's single best feature and the one around which almost every decision in the languages is centered is an almost total lack of developer friction. If Go has a slogan that slogan is "Frictionless Development". It's easily the simplest, least annoying, and most "get out of your way" language I've ever used.
[EDIT: some wording was incorrect]
I suspect this is where many philosophical differences in these discussions originate. I appreciate the value of having quick and easy tools, but for production software where I care about quality, I don't want the language to get out of my way if I'm doing something silly, like treating data as if it's a different type to what it really is or assuming there is data to work with at all if a null value is a possibility. The web is plagued by security problems, so it seems odd to me that anyone would promote a new language for writing web-based software that retains obvious and entirely avoidable ways to introduce vulnerabilities.
(I'm sure it also goes without saying that having code that can crash with a the equivalent of a null pointer dereference is still highly undesirable in a public-facing web server, even if it doesn't actually risk things like data leakage/loss.)
This has nothing to do with shiny features of the newest language or whether language A or B is someone's favorite. This has to do with program correctness.
Unless you want to do generics. Of extend the language to have custom operators, for things like scientific computing. Or tons of other things.
But, you know, bad for a teaching language.
Author here. Depends on what I'm doing. For most simple programs, the things I listed in the article don't really get in the way. So writing my web server in Go was not that bad at all. It was pretty good, in fact.
It's when I start making larger programs that I start feeling the constraints of the things I listed in the article. Having a strong, capable type system really helps me keep track of large projects.
Compared to other popular programming languages aimed at web programming, such as Python, Ruby and PHP, Go provides more type safety. Comparable to Java's but for less code.
Go's runtime and development tools are very lightweight, which is important to me as I use multiple, often dated computers with limited memory.
It is very easy to learn, a low investment. This means that it is conceivable for a student previously only exposed to Java to get on board on your software project on short-time notice.