This was a good read. Can anyone comment on whether they find the problems outlined in the article to really be painful in day-to-day go development?
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.
I chose between Go and Haskell for a project some time around 2012. I was a beginner to both, but came from a background of imperative languages (C, C++, Java, etc.)
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.
This sounds strikingly similar to my experience! Though my imperative language experience was mostly with dynamic and/or scripting languages aside from C#.
In practice, Go has caused me less frustration than any other language I've used. I feel like the author's complaints here aren't really grounded in much experience, or maybe he's trying to use the wrong tool for the job.
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.
is hardly sustainable. Go was production-ready in 2011 with a stable version 1.0. It has a surprisingly mature tool chain and vibrant community. Go cross-compiles from my 64-bit Mac to a 32-bit Raspberry Pi or ARM Android phone on a whim. I can deploy my app by copying a single, self-contained binary. Tell me again that Go does nothing new for us.
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.
Ok, I'll point out again that it emphasizes both concurrency and mutability which is a match made in hell and has a type system that's constantly subverted by null pointers and casts to interface which drastically reduce safety. It has a static type system released in the 2010s that doesn't have generics and deploying static binaries is not a new technology.
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 wrong. You're also proving the grandparent's point.
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 had something new to offer, and listed old things.
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.
Hmm, so some people are bent out of shape because of feature regression and over the fact that Go doesn't have the newest, shiniest gadgets. However, fans keep saying that their overall experience is great. Reminds me of something else...
The newest, shiniest gadgets? Like generics? You're kidding right?
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.
The newest, shiniest gadgets? Like generics? You're kidding right?
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?
Go packs together a lot of nice things that previously existed in other languages. It still has room for improvement though, as IMHO the language is pretty basic ATM - but exhaustive enough to cover most needs (whether they require stuff like generics or not) in a very painless way.
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.
As much as I like Go, in many ways Go is not what I would consider "beautiful" in an esthetic sense.
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.
I'm an experienced Go user. I'm also a lover of Haskell and Hindley Milner type systems. and in practice these complaints are not that big of a deal. Generics may or may not get added in the future but in practice you can go a long way with just slices and maps.
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.
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.
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 doubt that null pointers lead to security vulnerabilities. Panics, yes; worse performance, yes; vulnerabilities, unlikely. Null pointers are not dangling or wild pointers, which are the problematic ones.
I suppose that depends on how broadly you define a security vulnerability. Almost anything that can crash a process on a server -- either literally at OS level or figuratively by requiring something to reset itself before it can continue to do its job -- is probably a DoS attack waiting to happen. That might or might not be as dangerous as something like a remote root vulnerability, but I would argue that it is a serious security issue just the same.
(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.)
Interesting response... Do the multiple people downvoting not realise that even in Go a null dereference might trigger some sort of automatic reset in your server process (if the unexpected panic is only recovered by some high-level generic error handling logic) or even crash the program entirely (if you didn't have anything up the stack that recovered at all)? Or maybe not realise how these kinds of behaviours might allow denial of service attacks?
What if e.g. a programmer calls some normalize function on data before hashing it? Then if the normalize function sometimes returns null and the programmer hasn't handled this case, an attacker could use this to generate collisions.
You might want to google dereference null pointer code execution. Go regresses language design, because it allows constructs that have been proven to fail and are already fixed in other languages.
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.
Those have to do with the undefined nature of null pointer dereference in C. In Go, accessing a null pointer is guaranteed to produce a panic on every architecture.
>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.
Unless you want to do generics. Of extend the language to have custom operators, for things like scientific computing. Or tons of other things.
The generics thing turns out to not really be a problem. Yes, writing 100% Abstract Data Types is unsatisfying. However, when I'm actually writing custom data structures, I generally have an interface that I want to use because I want the data structure to take advantage of a peculiarity of the data being stored.
>can anyone comment on whether they find the problems outlined in the article to really be painful in day-to-day go development?
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.
Been writing Go at least weekly for a while now - no, none of these things are painful in daily usage - they seem like items that are painful in theory but not so much in everyday use, especially in the realm it is intended for.
I've been using Go in a large web application for a few months now. I only skimmed the article, but I didn't notice anything that's caused me problems. I quite enjoy working with it, although I like the idea of adding generics (not that I've needed them yet)/operator overloading/range extension.
I would not say that I am particularly experienced, but I will tell my point of view from a not particularly sophisticated programmer. I am interested in seeing what objections others may have to what I write.
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.
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.