Live data from Hacker News

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

amazon.com

61–70 of 264 posts

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

#61
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.

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

#62

Earlier quoted context omitted.

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…

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.

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

#64

Earlier quoted context omitted.

I've had tons of fun with Go, and I've also used it in real production code! I don't think it is really fair to say he "only" made it this far. It's something that actually brings enjoyment and productivity to possibly millions of people!

BASIC brought enjoyment and productivity to possibly millions of people. That doesn't mean there's nothing better.

That's true, but it also doesn't mean BASIC wasn't an accomplishment!

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

#65
It has been a long time since I bought a hardcopy programming book. Alternate forms of documentation and a Safari subscription have replaced these semi-frequent purchases. And although I can't argue against the practicality and economics of this new way, it certainly evokes none of the excitement of getting the new language book home, cracking the binding, and spending the rest of the evening curled up on the couch.

Go has been my most used new language and the timing of this book is good. I'm looking forward to adding it to my (real) bookshelf.

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

#66

Earlier quoted context omitted.

Two words: error handling and generics.

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.

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

#67
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…

> Even when the syntax is simple, the conceptual complexity of the language is quite big.

Lisp is a very simple language conceptually. The problem is that it allows you to build insane amounts of complexity in a very "free for all" way. No "one sane default way to do it".

The problem is now how complex a language is, but how much needless complexity it allows you to build yourself.

Go seems great because it doesn't easily allow you to build needless complexity. Though I've never coded anything meaningful in it, so my praise for it would be armchair thinking...

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

#68

Earlier quoted context omitted.

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…

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…

This exactly what I mean when I say that people underestimate simplicity and overestimate features. Yes, generics are a nice feature. Yes they help you to avoid code duplication. Yet, not having them is not a stopper at all. Programs are shipped without generics. Code bases remain clean enough without them. On the other hand, every time I read a generic function in C# or Java I feel I have to double think everything. That's the price of of adding an abstraction layer.

Don't get me wrong, I like generics. I think they would be a nice addition to Go. But I understand Go designers when they try to be conservative about it. I like that they only add features when it's absolutely obvious that the pros overcome the cons.

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

#69
post #43

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…

Brian is not the co-author of C, he wrote most of K&R however.

C was created by Thompson and Ritchie. The book was written by Kernighan and Ritchie. As a result Thompson's contribution is often forgotten, which is a shame.

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

#70
post #32

Earlier quoted context omitted.

Two words: error handling and generics.

I agree, those are two great reasons to use Go.

Why down vote some who likes the fact that he likes the error handling method in Go and that he doesn't like generics?
Post reply on HN