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

81–90 of 264 posts

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

#81

Post by NateDad »

microtonal wrote: post #73
nutate wrote: post #66

Earlier quoted context omitted.

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.

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.

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

#82

Post by theseoafs »

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 can't even believe this is the kind of comment that gets upvoted on HN nowadays. "Go was made by smart old people and is therefore good. If you don't understand it's good, you're stupid and I refuse to listen to you."

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

#83

Post by jksmith »

CatDevURandom wrote: post #46
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 agree. And not for nothing, I'm shipping production code, at a real company, with real customers, with real revenue (250m+). Here's the deal -- all programming languages are just tools. Go's great because it's small enough to keep in your head, and simple. It's fast. It promotes composition. And it has sane concurrency. And quite honestly, I am more productive for the things Go left out then it includes. That's not…

>>it's small enough to keep in your head

This. And the additional effect is that you can keep more of the problem domain in your head as well. I've been in this game a long time, and my experience has been that the simpler the dev tools, the more likely the programmers working on a particular domain will be SME's in that domain.

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

#84

Post by throwawaykf05 »

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.

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

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

#85

Post by logicallee »

theseoafs wrote: post #82
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 can't even believe this is the kind of comment that gets upvoted on HN nowadays. "Go was made by smart old people and is therefore good. If you don't understand it's good, you're stupid and I refuse to listen to you."

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 famous Unix book with Kernighan (of Kernighan and Ritchie fame), authored UTF-8 together, etc. They happen to be actual old masters.

They created Go in 2007, from what I heard cleaning up a lot of their old mistakes along the way.)

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

#88

Post by jksmith »

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.

My low content response is that you are brutally correct.

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

#89

Post by WaltPurvis »

microtonal wrote: post #71
WaltPurvis wrote: post #60

Earlier quoted context omitted.

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…

Yes, and that does not conflict with what I was saying. There are specific problem domains where generics would simplify matters, but in the overall universe of problems those domains are rare, i.e., most of the code that most programmers will write in Go will not involve duplicating code because of the absence of generics.

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

#90

Post by nsnick »

sp332 wrote: post #76
kylek wrote: post #55

Awesome. For those who don't know, Kernighan is the "k" in "awk" :)

Also the "K" in "K&R" https://en.wikipedia.org/wiki/The_C_Programming_Language

Also, the K in Kernighan Lin (Graph min cut) and the Lin-Kernighan heuristic (Traveling salesman)
Post reply on HN