The Go Programming Language by Brian W. Kernighan, Alan Donovan • Hacker News Board

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

#101

Post by NateDad » Thu, Mar 05, 2015, 4:27 PM UTC

sfk wrote: post #93

donatj wrote: post #78

Earlier quoted context omitted.

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.

How are errors in deferred functions handled? How about division by zero?

errors in deferred functions are handled just like they would be if the function were not deferred. There are some things like division by zero and array index out of bounds that cannot be used with this method without making the language incredibly cumbersome... for those, there are panics (basically like exceptions in other languages)... but they happen quite rarely in practice.

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

#102

Post by dilap » Thu, Mar 05, 2015, 4:27 PM UTC

meddlepal wrote: post #63

I look forward to the time when Go adds generics and all the people who told me that you don't need generics in Go start telling me how awesome and super-duper useful generics are.

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.)

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

#103

Post by tree_of_item » Thu, Mar 05, 2015, 4:29 PM UTC

WaltPurvis wrote: post #89

microtonal wrote: post #71

Earlier quoted context omitted.

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.

I think you slipped in a subtle but annoying mistruth here: "in the overall universe of problems those domains are rare" is just not true. What is true is that the kinds of programs Go programmers typically write may end up not needing this sort of polymorphism, which is very different from saying "domains where this sort of polymorphism is important are rare".

I only point this out because I've seen a lot of Go programmers defend Go by saying parametric polymorphism is only really important in particular niche domains, when really they want to say that Go only focuses on a particular niche domain where it isn't important.

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

#104

Post by wbl » Thu, Mar 05, 2015, 4:29 PM UTC

nnq wrote: post #67

ceronman wrote: post #35

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…

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

Are you talking about Common Lisp, or are you talking about Scheme? Common Lisp does provide primitives for just about everything, in ridiculously generic forms. Scheme forces you to code it yourself.

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

#105

Post by NateDad » Thu, Mar 05, 2015, 4:30 PM UTC

monocasa wrote: post #57

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?

No garbage collector so I can actually use it in embedded situations.

That's not really what Go is for. Look at Rust if that's what you want - memory safety without a garbage collector.

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

#106

Post by rdegges » Thu, Mar 05, 2015, 4:31 PM UTC

YES. I read and re-read the original K&R (The C Programming Language) book many times as a child. It's one of my favorite tech books ever written: clear, concise, challenging, useful.

I've recently started writing more and more code in Go, for simple performance reasons, and it'd be amazingly great to relive the K&R wonders of my childhood with a new language =)

Just pre-ordered a copy, can't wait.

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

#107

Post by sangnoir » Thu, Mar 05, 2015, 4:31 PM UTC

meddlepal wrote: post #63

I look forward to the time when Go adds generics and all the people who told me that you don't need generics in Go start telling me how awesome and super-duper useful generics are.

As far as I recall, the apologists don't say generics are bad - but rather, not necessary (at times conceding they are useful). Which sounds reasonable to me.

Who needs generics? 'Need' in it's dictionary sense. i.e. is there an algorithm you can't write in a language because the language lacks generics? Great to have? Yes. Need? No.

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

#108

Post by NateDad » Thu, Mar 05, 2015, 4:35 PM UTC

tempodox wrote: post #77

jonstokes wrote: post #44

Earlier quoted context omitted.

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.

Good for you. I upvoted this reply. We need more humor in the world, and someone who can take a joke deserves the upvote.

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

#109

Post by taeric » Thu, Mar 05, 2015, 4:37 PM UTC

wbl wrote: post #104

nnq wrote: post #67

Earlier quoted context omitted.

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

Are you talking about Common Lisp, or are you talking about Scheme? Common Lisp does provide primitives for just about everything, in ridiculously generic forms. Scheme forces you to code it yourself.

I think the criticism leveled would go to both. If what you say is true, moreso to Scheme. But the criticism is more that it allows this. To many, it even encourages it.

For myself, I still like it, a lot. To the point that the more I learn of it, the more I'm confused on how it hasn't taken off better.

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

#110

Post by Jayschwa » Thu, Mar 05, 2015, 4:38 PM UTC

sfk wrote: post #93

donatj wrote: post #78

Earlier quoted context omitted.

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.

How are errors in deferred functions handled? How about division by zero?

Deferred functions can pass along errors by using a closure. http://play.golang.org/p/_ZqSk470-b