The Go Programming Language by Brian W. Kernighan, Alan Donovan • Hacker News Board

Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan

#121

Post by jberryman » Thu, Mar 05, 2015, 5:11 PM UTC

ceronman wrote: post #35

sesteel wrote: post #26

Go, with its simplicity, is a gift from the generation of masters to today's professionals, but many of today's professionals appear too ignorant to see the wisdom of the language. It used to drive me crazy when I would read negative comments in r/programming and HN, but I don't even pay attention to the negative comments anymore. The adoption is far better than I was afraid it was going to be.

You mention the key point of Go: simplicity. I think many developers tend to underestimate the power of simplicity and overestimate the power of certain features. Every single abstraction has a price in complexity. This is why Lisp, being a super powerful language invented in the 1950s never got widely used. Even when the syntax is simple, the conceptual complexity of the language is quite big. Same thing happens wit…

Both haskell and probably most lisps are relatively simple languages, compared to python, ruby, c++, etc. I think I have some idea of what you're saying but I'm not familiar with go.

> Every single abstraction has a price in complexity.

I think the whole point of abstraction is to lessen complexity; wrap up many different things into one thing that's easy to reason about. Very few languages support creating good abstractions, unfortunately.

Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan

#122

Post by xkarga00 » Thu, Mar 05, 2015, 5:15 PM UTC

matthewmacleod wrote: post #119

sesteel wrote: post #26

Go, with its simplicity, is a gift from the generation of masters to today's professionals, but many of today's professionals appear too ignorant to see the wisdom of the language. It used to drive me crazy when I would read negative comments in r/programming and HN, but I don't even pay attention to the negative comments anymore. The adoption is far better than I was afraid it was going to be.

I think it's rather the height of hubris to accuse your contemporaries of being "ignorant" because they disagree with your assessment of this particular tool. Go is an interesting shift in language design, basically discarding many modern trends and techniques and returning to a much simpler paradigm. It's a totally valid approach with lots of merit — complexity can be a killer. In addition, the concurrency primitive…

Just a note: Go supports higher-order functions

Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan

#123

Post by jerf » Thu, Mar 05, 2015, 5:20 PM UTC

Veedrac wrote: post #94

throwawaykf05 wrote: post #84

Earlier quoted context omitted.

This is the first time I've seen the Blub Paradox [1] portrayed as ignorance from the other direction! OK, not a big believer of the "Blub" theory, personally - every language has its place in a continuum of dimensions that are more than just technical, and I actually like Go overall. But "lack of generics" is definitely not the same as "simplicity. Not in the decade we live in. 1. http://c2.com/cgi/wiki?BlubParadox

The Blub Paradox would only apply if the people using Go hadn't used languages with generics (or similar); for the most part that's not true. > But "lack of generics" is definitely not the same as "simplicity. It's not literally the same thing, but it is an aspect that keeps Go simple.

"The Blub Paradox would only apply if the people using Go hadn't used languages with generics (or similar); for the most part that's not true."

Yes, speaking for myself as someone often in the position of defending Go on HN (even though as a computer language polyglot it isn't part of my personal identity), I also speak several other languages that do have generics in them, along with substantial usage of the "dynamically typed" languages, and most relevantly, including reasonable fluency in Haskell, a language where the generics are so deep and fundamental they aren't even given a name, they just are. What Haskell calls "Generics" is actually more like what other languages call "reflection".

Yes, there are a ton of programs that you can usefully write without "generics", especially since interfaces are about half of "generics", and arguably the more useful half in general. Yes, there are a ton of programs that you can't really write without them. We could do with a lot more sensible discussion about which programs are which and a lot less "Oh, you think it's OK for Go to not have generics? Well you must be an idiot then." (e.g., my frequent observation that if you need a rich numeric hierarchy you really need generics... but those cases really are exceptions compared to programs that are just fine on integers and floats, and, frankly, in many cases just fine on integers alone.)

Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan

#124

Post by ansible » Thu, Mar 05, 2015, 5:29 PM UTC

meddlepal wrote: post #63

I look forward to the time when Go adds generics and all the people who told me that you don't need generics in Go start telling me how awesome and super-duper useful generics are.

I predict that there will be some kind of support for generics... eventually. Not explicitly in the language itself, but some added 'go generate' style tooling support. You will be able to define containers and such to use the empty interface, and add in some comments saying you want a version for strings, or floats. And the generate step will run to create the type-specific versions, which will then be compiled as usual.

There's definitely work to be done in the details.

This is my general read on where I think the community and developers are going... that's all.

Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan

#125

Post by sesteel » Thu, Mar 05, 2015, 5:30 PM UTC

matthewmacleod wrote: post #119

sesteel wrote: post #26

Go, with its simplicity, is a gift from the generation of masters to today's professionals, but many of today's professionals appear too ignorant to see the wisdom of the language. It used to drive me crazy when I would read negative comments in r/programming and HN, but I don't even pay attention to the negative comments anymore. The adoption is far better than I was afraid it was going to be.

I think it's rather the height of hubris to accuse your contemporaries of being "ignorant" because they disagree with your assessment of this particular tool. Go is an interesting shift in language design, basically discarding many modern trends and techniques and returning to a much simpler paradigm. It's a totally valid approach with lots of merit — complexity can be a killer. In addition, the concurrency primitive…

I agree, I should have grounded the claim of ignorance in a long list of specific instances or made no comment at all; sometimes less is more.

Aside, I use and enjoy languages other than Go; it is simply a tool to solve problems, and I don't want to detract people from using other tools. We all develop opinions with regards to what does and does not work well. I never intended to devalue others' experience or perspective. I was simply pointing out that many people seem to not have suffered through enough bad work experiences to appreciate Go's main feature of simplicity.

If you haven't run across horrible, insanely overcomplicated, code written by those that think they are the top 1% intelligence-wise, you might not appreciate Go. Likewise, if you write horrible, insanely overcomplicated, code and think you, yourself, are brilliant, you probably won't appreciate Go. If you only work alone or on small teams and projects, you might not appreciate Go.

Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan

#126

Post by politician » Thu, Mar 05, 2015, 5:31 PM UTC

donatj wrote: post #78

mateuszf wrote: post #30

Earlier quoted context omitted.

Two words: error handling and generics.

Go's error handling is honestly the best I've ever used. No errors go unhandled. Period. get an error? Return it or deal with it. Makes much more sense than exceptions suddenly breaking the behaviour of the language.

It's not actually true that no errors go unhandled.

    func foo() error { return errors.New("whoa!") }
    func bar() { 
        _ := foo()
        // onward!
    }

Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan

#127

Post by yomism » Thu, Mar 05, 2015, 5:32 PM UTC

matthewmacleod wrote: post #119

sesteel wrote: post #26

Go, with its simplicity, is a gift from the generation of masters to today's professionals, but many of today's professionals appear too ignorant to see the wisdom of the language. It used to drive me crazy when I would read negative comments in r/programming and HN, but I don't even pay attention to the negative comments anymore. The adoption is far better than I was afraid it was going to be.

I think it's rather the height of hubris to accuse your contemporaries of being "ignorant" because they disagree with your assessment of this particular tool. Go is an interesting shift in language design, basically discarding many modern trends and techniques and returning to a much simpler paradigm. It's a totally valid approach with lots of merit — complexity can be a killer. In addition, the concurrency primitive…

Minor corrrection: Go supports higher-order functions

(They even have a codewalk that mentions this in its introduction)

https://golang.org/doc/codewalk/functions/

Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan

#128

Post by gknoy » Thu, Mar 05, 2015, 5:44 PM UTC

theseoafs wrote: post #92

logicallee wrote: post #85

Earlier quoted context omitted.

fwiw, I found sesteel's comment useful and informative. (by the way, you might have misread it. I think he didn't mean "generation of masters" as "old smart people" but probably specifically the creators of Go, since they happen to include Rob Pike and Ken Thompson - two people who had separately created the B programming language (immediate predecessor of C), co-created Unix at Bell Labs in the 70's, co-authored a f…

I know who created Go, because everyone does. Being created by Pike, Thompson, and whoever else does not in and of itself make Go better than any other language. It also does not make it immune to criticism in such a way that you should brush off anyone who has anything negative to say about it.

It doesn't make it better, but it's a __very strong hint__ that perhaps I should look more closely at Go. Experts matter, and it would be foolish of me as a developer to discount the experience of these guys -- they've literally been programming for longer than I have been alive.

I respect the creators of Go deeply, because they have been so formative of the industry. It's like being an electrical Engineer, and having Nikola Tesla make a suggestion -- I might not understand all of the lessons, but there's a distinct possibility that these guys are addressing problems I don't yet fully understand.

Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan

#129

Post by tome » Thu, Mar 05, 2015, 5:47 PM UTC

jbooth wrote: post #62

microtonal wrote: post #52

Earlier quoted context omitted.

In the end people realize you can actually build things up without paying this complexity tax with simpler languages. This is why languages like Go succeed. Of course, you pay the tax somewhere else and that is code duplication. You see this in Go due to the lack of generics, which often results in duplication of code for different types or reliance on reflection (which is slower and can lead to runtime errors). This…

Yeah, but aside from the singular issue of generics (which are not exactly cutting edge), I can't think of a single 'advanced' feature that would add nearly enough utility to pay for its additional complexity. Everyone who shows up complaining about how it isn't "moving forward" by embracing features of high complexity and dubious utility is really missing the point IMO.

What about sum types (discriminated unions)? Sounds like that would help make error handling a lot safer and easier.

Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan

#130

Post by microtonal » Thu, Mar 05, 2015, 5:53 PM UTC

NateDad wrote: post #81

microtonal wrote: post #73

Earlier quoted context omitted.

It just creates the code for you, then you commit it. Easy enough. Except that it does not provide the same thing. If I provide a package with e.g. a container datatype, I would have to generate for every possible data type that any user wants to put in the container. Obviously, that is not going to scale.

Not really.. you provide the base code, and the consumer of your package generates the specific types they need. As the package author, you don't actually generate any of the concrete implementations.

Which defies the whole point of easy go-gettable packages.

gen is a good contribution, but it only works for a subset of cases. E.g. I follow a comparable approach in my Java library for finite state dictionaries because Java does not provide generics over primitive types (luckily, that is a closed class). But it's less than ideal.