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

231–240 of 264 posts

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

#231

Post by pjmorris »

"Good Programming is not learned from generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify, human-engineered, efficient, and reliable, by the application of common sense and good programming practices. Careful study and imitation of good programs leads to better writing." - [1]

I'm a huge fan, have nearly everything Kernighan's been involved with, and have profited greatly from his writing. I look forward to picking up the Go book, and modernizing a bit.

[1] 'Software Tools', Brian Kernighan, P.J. Plauger, 1976

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

#232

Post by coldtea »

sesteel wrote: post #216
coldtea wrote: post #213

Earlier quoted context omitted.

> For the record, ignorant does not equal stupid, being a master does not mean you are old, and ignoring negativity (which I should have done here) does not mean I refuse to listen to you. Ignorant might not mean stupid literally, but it still means "you don't know about programming languages" in the context of the comment, which is also bad. Being a master might not mean you are old, but the masters we're talking ab…

Thank you for trying to educate me on what I meant by my own comment. Contrary to what you might think, ignorant, in the context of my comment does not mean "you don't know about programming languages" and I know this because it was my comment. I was simply referring to people not having the same professional experiences such that they would appreciate a language like Go. The crux of the issue is that Go is a local m…

>Thank you for trying to educate me on what I meant by my own comment. Contrary to what you might think, ignorant, in the context of my comment does not mean "you don't know about programming languages" and I know this because it was my comment.

What one means and what one writes/communicates can be two totally different things. The "I know because I wrote it" is a valid argument regarding intent, but doesn't hold the same power regarding what the written thing means to others who read it.

>The crux of the issue is that Go is a local min in a field of possibilities, you may value differently the attributes of various programming langauges which would lead you to some other alternative or local min.

Why would one want a "local min" though?

If anything one would prefer the global maximum or at least a local maximum.

Or is the "min" meant in some dimension that one would actually want to minimize?

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

#234

Post by sytelus »

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…

Go seems to have designed to make compiler beautiful and simple. There was even a brag post about how one of the authors saved few bytes by making a change in the language. My view is that language should be designed to take away repetitive tasks from developer rather than make language pretty or compiler super efficient. It's OK to make compiler complex to meet the demand of important feature that developers would enjoy and want every day.

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

#235

Post by tuxychandru »

tome wrote: post #129
jbooth wrote: post #62

Earlier quoted context omitted.

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.

How do sum types make error handling safer (without also adding exhaustive pattern matching) or easier (without adding do notation or macros)?

The point I am trying to make is that adding some features from other languages doesn't provide sufficient value without also adding other features. Adding all of them can make the language significantly more complex that you wonder whether the benefits gained are worth it.

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

#236

Post by dilap »

marvy wrote: post #229
dilap wrote: post #102

Earlier quoted context omitted.

Here's rsc (one of the core Go dev's page) on generics. http://research.swtch.com/generic They do believe it's a useful feature, they just don't think the tradeoffs justify it yet. (People who loudly clamor for generics tend to ignore these tradeoffs.)

Unfortunately, that thing is a false trichotomy. The fact is, choosing option 1 does not save you from the consequences of options 2 and 3. The reason is that the programmer now has to make a choice between boxing things manually, or implementing the same algorithm multiple times, just as the compiler would have done. So in reality there is a dichotomy: slow compiles, or slow runtimes.

Definitely some truth to this, but in practice, the fact that you have to manually do things means that you'll make decent choices -- you'll use interfaces for most stuff, and specialize the stuff that needs to be concrete, and life will be OK, if a bit clumsy.

With generics, it's easy to end up in a situation where just by instantiating some simple-seeming class, you get a whole giant pile of stuff, more than any sane programmer would create by hand.

(I wish I had it at hand, but there was an excellent post from a .NET/CLR guy a while back that went into all the crazy stuff that got instantiated just by creating one specialization of List, the associated performance overheads, and the things the compiler and runtime tried to do to avoid those.)

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

#237

Post by [deleted] »

mike_hearn wrote: post #170
gknoy wrote: post #128

Earlier quoted context omitted.

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 havin…

I think this can be misleading. The guys who designed Go have not designed any other popular languages in the decades between C and Go. They have not produced any modern developer tools or toolchains. Rob Pike's last language before Go was a quasi-DSL called Sawzall, which is a Google internal language for logs processing. I had to use it when I was at Google and frankly, I would have preferred other languages to hav…

[deleted]

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

#238

Post by threeseed »

enneff wrote: post #192
mike_hearn wrote: post #170

Earlier quoted context omitted.

I think this can be misleading. The guys who designed Go have not designed any other popular languages in the decades between C and Go. They have not produced any modern developer tools or toolchains. Rob Pike's last language before Go was a quasi-DSL called Sawzall, which is a Google internal language for logs processing. I had to use it when I was at Google and frankly, I would have preferred other languages to hav…

> Both things that Go has a notable poverty of. It surprises me that you say this, since we (the Go team) spend a huge amount of time and energy talking about our design decisions. But you must have missed it, because the examples you give are wrong. > For example Google's C++ style guide bans exceptions, partly because writing exception safe code in the absence of garbage collection is very hard. So not having them…

> When you're programming with exceptions you need to keep in mind a second hidden path of control flow

So ? Developers are completely used to it. Every time there is a conditional statement e.g. if/else we have to think about the other control flow. Likewise every time a method calls another method. And if that method is in a different class then you again have completely lost visibility. Developers are constantly dealing with control flows that go everywhere but straight down.

Java is the 2nd most popular language in the world so pretty sure developers have managed to cope with exceptions just fine.

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

#239

Post by enneff »

sytelus wrote: post #234
matthewmacleod wrote: post #119

Earlier quoted context omitted.

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…

Go seems to have designed to make compiler beautiful and simple. There was even a brag post about how one of the authors saved few bytes by making a change in the language. My view is that language should be designed to take away repetitive tasks from developer rather than make language pretty or compiler super efficient. It's OK to make compiler complex to meet the demand of important feature that developers would e…

Citation needed. This is flat out wrong.

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

#240

Post by marvy »

dilap wrote: post #236
marvy wrote: post #229

Earlier quoted context omitted.

Unfortunately, that thing is a false trichotomy. The fact is, choosing option 1 does not save you from the consequences of options 2 and 3. The reason is that the programmer now has to make a choice between boxing things manually, or implementing the same algorithm multiple times, just as the compiler would have done. So in reality there is a dichotomy: slow compiles, or slow runtimes.

Definitely some truth to this, but in practice, the fact that you have to manually do things means that you'll make decent choices -- you'll use interfaces for most stuff, and specialize the stuff that needs to be concrete, and life will be OK, if a bit clumsy. With generics, it's easy to end up in a situation where just by instantiating some simple-seeming class, you get a whole giant pile of stuff, more than any sa…

That bad? Wow. I would love to read that.
Post reply on HN