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

171–180 of 264 posts

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

#171

Post by coldtea »

NateDad wrote: post #169
coldtea wrote: post #167

Earlier quoted context omitted.

Yeah, fuck this type safety and performance thing...

It's type safe and there's little performance hit. Please note that the "Interface" there is not "interface{}" ... it is a somewhat unfortunately named interface: http://golang.org/pkg/sort/#Interface The Go authors were following a practice that seemed like a good idea at first, and they've now admitted was probably a mistake... i.e. if your package is mostly about a single interface, name the package something info…

OK, thought you meant the interface{} thing people go for, since Go doesn't have generics.

This Sort.Interface thing is indeed safe and performant. On the other hand its not a solution to the problem we're discussing (that, to quote the parent, due to lack of generics "it is tedious to write library code in the language"). You still have to implement it all the time for all types despite having identical implementations.

So this doesn't show how it's not tedious. It just shows that it can be done in some way, which nobody doubted.

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

#172

Post by curun1r »

WorldWideWayne wrote: post #116
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.

Regardless of how I feel about Go as a language... I don't trust Google to perform well as the steward. It may be open source, but that means nothing if people stop working on it. If it doesn't become popular, I think they will just let it die. If they start trying to make it popular, I think there will be a big push back from the great unwashed masses of people who want obvious features and then it will die. Only ti…

I don't think you have to trust Google, you just have to trust the core team. While they all work for Google now, the language is open source and they have reputations that extend well beyond their time at Google. I share your distrust of Google, but I trust Ken Thompson, Rob Pike and the rest of the team enough that I don't worry about choosing Go. I have faith that if Google kills it or starts to misbehave, the team will leave and figure out a way to keep the language moving forward.

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

#173

Post by mseepgood »

zaphar wrote: post #113
frou_dh wrote: post #49

Anyone know if Kernighan has written a lot of Go code himself, or is he onboard more for his technical writing skills? (There's the Bell Labs connection of course)

Kernighan is one of the core authors of the language. So I'd say it's for more than just his technical writing skills.

You're mixing up the Bell Labs / Unix greybeards.

- Ken Thompson: Bell Labs, B, Unix, Plan 9, Go

- Dennis Ritchie: Bell Labs, C, Unix

- Rob Pike: Bell Labs, Unix contributor, Plan 9, Limbo, Go

- Brian W. Kernighan: Bell Labs, Unix contributor, AWK, AMPL

Books:

- "The C Programming Language" - Kernighan & Richie

- "The AWK Programming Language" - Kernighan & Aho

- "The Elements of Programming Style" - Kernighan & Plauger

- "The Unix Programming Environment" - Kernighan & Pike

- "The Practice of Programming" - Kernighan & Pike

- "The Go Programming Language" - Kernighan & Donovan

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

#174

Post by fauigerzigerk »

AnimalMuppet wrote: post #146
jberryman wrote: post #121

Earlier quoted context omitted.

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

> 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. Abstraction lessens complexity, and also adds complexity. Take monads in Haskell, for instance. Let's oversimplify and say that absolutely everything is done through monads. Great; we've now wrapped up many dif…

That would be true if abstraction were a cosmic force that radiated in all directions equally, a Hegelian horror trip anihilating all meaning so to speak.

But most of the time, we are abstracting away something specific in order to make something else more concrete and less obscured by irrelevant detail, hence reducing complexity.

Of course abstraction can go wrong, because sometimes we abstract away things that are very relevant, perhaps in futile pursuit of future code reuse. But having the tools for abstraction does not make abstraction go wrong. We do.

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

#177

Post by recursive »

Retra wrote: post #164
daviddaviddavid wrote: post #154

Earlier quoted context omitted.

"Ignorance is not a prerequisite for disagreement." This is a very memorable and useful quote. Thanks for saying it. It deserves to be a classic, in my opinion.

Except that it is not always true. Ignorance is a prerequisite for disagreement if you assume entirely rational decision-making. Without ignorance, if you have disagreement, you very likely have irrationality instead.

Is rationality incompatible with subjectivity?

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

#178

Post by pjmlp »

gnuvince wrote: post #159
nemo1618 wrote: post #151

Earlier quoted context omitted.

Technically true, but the point is that arrays were the only collection type in Pascal, whereas Go also has slices (which, in my experience, outnumber arrays 10-1 in most codebases).

When did Pascal gain dynamic arrays?

Depends which Pascal you mean.

The Extended Pascal ISO standard which does include dynamic arrays is from 1990.

Turbo Pascal and other Pascal dialects also had them.

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

#179

Post by pjmlp »

nemo1618 wrote: post #151
gnuvince wrote: post #143

Earlier quoted context omitted.

In a funny twist of history, Kernighan is now writing a book on a language where the length of an array is part of its type: http://play.golang.org/p/jrbSgKFZ_1

Technically true, but the point is that arrays were the only collection type in Pascal, whereas Go also has slices (which, in my experience, outnumber arrays 10-1 in most codebases).

Not true, otherwise Wirth would have had an hard time to write "Algorithms and Data Structures".

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

#180

Post by pjmlp »

joelwilliamson wrote: post #139
taeric wrote: post #136

Earlier quoted context omitted.

Not that I can completely disagree with your point, but there are many reasons outside of the intrinsics of a programming language that can and will influence ones success. The marketting muscle that was put behind Java certainly helped it in its time. Same for the actual market that backs objective c. C probably benefited as much from the open distribution as it did anything else. Combined with a relatively high qua…

I don't think GCC can take any credit for C becoming a popular language. GCC 1.0 was only released in 1987, and prior to that most people were stuck using proprietary compilers. I would rather say C succeeded because it was tied to Unix, and Unix was very successful. GCC certainly contributed to C continuing to be widely used.

Quite right.

Before UNIX became part of the enterprise workforce very few cared about C.

Post reply on HN