Live data from Hacker News

Go at SoundCloud

backstage.soundcloud.com

21–30 of 112 posts

Re: Go at SoundCloud

#21

  especially, as most new engineers on Go projects lament, during error handling
Does any have pointers to reading material or care to explain the lack of error handling in Go?

Re: Go at SoundCloud

#22

especially, as most new engineers on Go projects lament, during error handling Does any have pointers to reading material or care to explain the lack of error handling in Go?

it's not there there's no error handling; it's that there's no exceptions. Instead, you use multiple return values, one of which is an error, and you check the return value for an error. It forces you to handle errors at the call site and makes diapers unimplementable.

Re: Go at SoundCloud

#23

especially, as most new engineers on Go projects lament, during error handling Does any have pointers to reading material or care to explain the lack of error handling in Go?

Go doesn't "lack error-handling." They're referring to the fact that Go doesn't have exceptions; you check return codes to detect and handle errors. For some this is tedious, but has advantages (mentioned in the article) with respect to understanding an entire program.

Re: Go at SoundCloud

#24

Earlier quoted context omitted.

But Go doesn't get rid of OOP, it just fixes it.

Does it? Seems like Go just has somewhat weak structural typing and a poor (by 2012 standards) type system. No parametric polymorphism? Whaaaaaaa

Parametric polymorphism has nothing to do with OOP.

Re: Go at SoundCloud

#25
post #4

The way they describe Go as a WYSIWYG language makes me think of functional programming languages (e.g. mostly of elimination of side effects.)

It makes me think of getting rid of OOP and saying goodbye to the overengineering overhead it involves. It took us 25 years to begin to see that the king is naked! UPDATE: I have a feeling that in 25 years we'll be dissing the current fad du jour - functional programming.

...Go still has objects. It's not the notion of binding functions to data that's flawed; it's classical inheritance that's flawed.

Re: Go at SoundCloud

#26

especially, as most new engineers on Go projects lament, during error handling Does any have pointers to reading material or care to explain the lack of error handling in Go?

Go doesn't "lack error-handling." They're referring to the fact that Go doesn't have exceptions; you check return codes to detect and handle errors. For some this is tedious, but has advantages (mentioned in the article) with respect to understanding an entire program.

The problem is it's no better than C - the correct way is to return sum types, either values or errors. A good language would statically check that any returned values are only used when there are no errors, preventing invalid values being accessed.

This requires some flow analysis, but brings real benefit and safety.

Re: Go at SoundCloud

#27
post #22

especially, as most new engineers on Go projects lament, during error handling Does any have pointers to reading material or care to explain the lack of error handling in Go?

it's not there there's no error handling; it's that there's no exceptions. Instead, you use multiple return values, one of which is an error, and you check the return value for an error. It forces you to handle errors at the call site and makes diapers unimplementable.

How does it force you to handle errors? Cant you choose to ignore the return value?

Re: Go at SoundCloud

#28
post #22

especially, as most new engineers on Go projects lament, during error handling Does any have pointers to reading material or care to explain the lack of error handling in Go?

it's not there there's no error handling; it's that there's no exceptions. Instead, you use multiple return values, one of which is an error, and you check the return value for an error. It forces you to handle errors at the call site and makes diapers unimplementable.

> It forces you to handle errors at the call site and makes diapers unimplementable.

I don't see how the latter is true. What's the practical difference between wrapping a function call in a try/(no-op)catch and entirely ignoring the error return value?

Re: Go at SoundCloud

#29
What sort of development environment are others here using for go (if using it at all, of course) ? I've had reasonably good experience with the go-mode in emacs.

Re: Go at SoundCloud

#30

What sort of development environment are others here using for go (if using it at all, of course) ? I've had reasonably good experience with the go-mode in emacs.

Sublime Text 2 + GoSublime has been a really great experience for me.

http://www.sublimetext.com/2

https://github.com/DisposaBoy/GoSublime

Post reply on HN