5 ms·

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 experi

by mholt 12y ago

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.

stock_toaster 12y ago
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.
Artemis2 12y ago
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. I love Go, because it fits in my head.
- randallsquared 12y ago
  > 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
rakoo 12y ago
> Tell me again that Go does nothing new for us. 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.
- stcredzero 12y ago
  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...
  - axman6 12y ago
    The newest, shiniest gadgets? Like generics? You're kidding right?
    - stcredzero 12y ago
      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?
    - stcredzero 12y ago
      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.
cgag 12y ago
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.
liveoneggs 12y ago
> I can deploy my app by copying a single, self-contained binary. I don't think golang invented static linking. ;)
Peaker 12y ago
> Tell me again that Go does nothing new for us 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.
- AnimalMuppet 12y ago
  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.
  - Peaker 12y ago
    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.

by mholt 12y ago

stock_toaster 12y ago

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.

Artemis2 12y ago

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. I love Go, because it fits in my head.

randallsquared 12y ago
> 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

rakoo 12y ago

> Tell me again that Go does nothing new for us. 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.

stcredzero 12y ago
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...
- axman6 12y ago
  The newest, shiniest gadgets? Like generics? You're kidding right?
  - stcredzero 12y ago
    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?
  - stcredzero 12y ago
    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.

cgag 12y ago

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.

liveoneggs 12y ago

> I can deploy my app by copying a single, self-contained binary. I don't think golang invented static linking. ;)

Peaker 12y ago

> Tell me again that Go does nothing new for us 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.

AnimalMuppet 12y ago
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.
- Peaker 12y ago
  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.