Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

amazon.com

Post reply on HN
Print view View original

71–80 of 264 posts

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

#71

Post by microtonal »

WaltPurvis wrote: post #60
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…

But that is so rarely an issue... You might encounter an occasional specific circumstance where you will need do some code duplication in Go, but I've written many thousands of lines of Go and have had to resort to duplicated code once (and in that particular case all that required was a couple copy-pastes and minor edits, and I'd have to go back and revisit it but it's possible I could have solved it more elegantly…

But that is so rarely an issue...

For you...

It depends on what kind of code you are working on. If you work a lot on numeric code (e.g. in machine learning), you want to make it easy to specialize on e.g. 32-bit or 64-bit floats.

Also, since only built-in types are generic, you cannot implement other containers (you never need binary search trees?) in a safe manner.

So, yes, the lack of generics is a frequent issue for me.

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

#72

Post by baldfat »

meddlepal wrote: post #61
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.

Sounds a lot like you drank the Kool-aid.

>Sounds a lot like you drank the Kool-aid.

So anyone who likes Go is deceived? Why use words like that? How about just saying GO isn't for me. Saying any more is just you imposing your opinion on someone else and devaluing them.

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

#73

Post by microtonal »

nutate wrote: post #66
microtonal wrote: post #38

Earlier quoted context omitted.

Error handling is something that I did get used to, especially considering that one can assign and check in an if-statement. Generics I still miss every single day. But not enough to stop using Go. It's pretty much C with interfaces, a garbage collector, and safety. What more can one wish for?

Have you tried go gen? It looks clearer to me than some of the hoops I've seen set up, jumped through, etc for heavy STL generics: http://clipperhouse.github.io/gen/ It just creates the code for you, then you commit it. Easy enough.

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.

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

#74

Post by samatman »

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…

There is no "Lisp invented in the 50s" that never got widely used. This language doesn't exist. To use that level of abstraction, replace every language in your post with the word "Algol" except Haskell which you call "ML". Doesn't make sense? Neither does your reference to Lisp.

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

#75

Post by jerf »

microtonal wrote: post #58
jerf wrote: post #54

Earlier quoted context omitted.

You might find this interesting: http://www.reddit.com/r/programming/comments/2wy2qe/gos_comp... , my reply to someone's question about what is interesting and/or unique about Go. A bit much to just copy & paste in here, probably. While so many people are complaining about what it doesn't have, there are things it does have that, while not individually unique, are actually packaged into a unique bundle. Particularly…

While so many people are complaining about what it doesn't have, The problem is not really what Go does not have, it's that often fallacies are used to react to critique on Go. Another one that pops up very often is 'you just have to use it for some time to understand why Go does not need it'. This is of course nonsense. Anyone who has programmed C and C++ knows the advantages and disadvantages of generics. And despi…

Read what I linked. I'm not afraid to anti-recommend Go for given use cases.

That said, since you mentioned it, I'll reiterate what's in that link to observe that "Go doesn't have generics" is a half truth. (And I don't mean "lie"... it has non-trivial truth in it. But it is only a half-truth.) Generics are a complicated concept that encompasses at least "generic data structures" and "generic algorithms"; you can slice and dice in other things, too, but it certainly has at least those two aspects. The former I freely admit is an uncovered case, and I still believe is something Go needs to address sooner or later. The latter is covered in Go via the interfaces.

I think the reason why Go in practice doesn't need a lot of generic data structures is that its core use case, concurrent network servers, has an awful lot of byte streams flowing around, and, lo, the code I'm converting into Go has a lot of byte streams flowing around. A bajillion "generic data structures" don't much help with that use case. (Now, the natural contrarian argument here is to talk about how you might need them someday, but, seriously, you probably don't need them all the time. If you do... don't use Go.) The "generic algorithms" concept is incredibly useful, but, lo, Go actually supports it fairly well. On first read of the Go feature set it's really easy to blip over the "implicit satisfaction of interfaces" and think it's an irrelevant parlor trick, but in practice it's really very useful in surprising and profound ways.

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

#77

Post by tempodox »

jonstokes wrote: post #44
tempodox wrote: post #25

In my personal view, I find it disappointing that someone like Brian Kernighan, as a co-author of C, only got as far as Go. I would have loved it much more to see him working on a language like Rust, that actually seems to point to the future of programming languages (or does its best at it), while Go looks like a stopgap and a dead end right from the beginning. Go seems a fine piece of engineering in so far as it di…

I think this comment is awesome and makes total sense if you read it in Comic Book Guy voice. Actually, I think Comic Book Guy voice works for so many of the comments that get downvoted on HN. There should be set of tags that mods can put around a comment to signify "relevant and humorous if read with Comic Book Guy voice", so that the community doesn't miss out on comedy gold.

Your reply seems to have gotten some downvotes (probably from people who can't take everything seriously enough), so I'm making a point of giving you the one upvote I have. I did something to deserve this reply so you shouldn't be punished for it.

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

#78

Post by donatj »

mateuszf wrote: post #30
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.

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.

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

#79

Post by sbt »

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've been coding Go professionally now for about 8 months. Interestingly, it has made me appreciate C++. The reason is while the Go compiler is fast, it is mostly because it doesn't do very much work. By contrast, a C++ program takes a long time to compile because the compiler does a lot. It's obviously not as black/white as I've portrayed it here for brevity, but it is nevertheless an apparent trade off.

I like Go overall, but on balance I would prefer a slower compile-test cycle to have more language feature support.

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

#80

Post by jgrahamc »

vixen99 wrote: post #8
jgrahamc wrote: post #2

Oh. Thank goodness for that. Now I can resist every publisher that wants me to write a book on Go, and tell myself that was OK to do because I'd never write as good a book as those two.

What modesty!

What you call modesty I call self-awareness.
Post reply on HN