Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I’m not leaving Python for Go

uberpython.wordpress.com

Post reply on HN
Print view View original

21–30 of 245 posts

Re: Why I’m not leaving Python for Go

#21

Post by je42 »

james4k wrote: post #19

> Verbose and repetitive error handling If you were to handle the same error cases in Python that you gave examples for in Go, it would probably be even more verbose with the try/catch wrapped around. > Errors passing silently – ticking time bombs to go Are you kidding? Unless exceptions are documented well, which they rarely are, this is a much greater problem when using exceptions.

> If you were to handle the same error cases in Python that you gave examples for in Go, it would probably be even more verbose with the try/catch wrapped around. Not sure what you are talking about:

try:

  datastore.Get(c, key, record); 

  viewTemplate.Execute(w, record);
catch e:

  appError(e);

Re: Why I’m not leaving Python for Go

#22

Post by mquander »

hasenj wrote: post #20

The error handling style is certainly different - but it's not so bad. It's a matter of style and getting used to stuff. Maybe a better error handling mechanism is needed - but I'd prefer if it's not exception handling. Perhaps lisp style error handling? What ever that is - for I'm not familiar with it - but I keep hearing lispers brag about how awesome it is!

http://www.gigamonkeys.com/book/beyond-exception-handling-co...

Think exceptions, but instead of blowing away the stack on the way up to your exception handler, it gives you the option of resuming execution in some way where you left off. It also lets you encapsulate error handling better.

Re: Why I’m not leaving Python for Go

#23

Post by wonderzombie »

je42 wrote: post #21
james4k wrote: post #19

> Verbose and repetitive error handling If you were to handle the same error cases in Python that you gave examples for in Go, it would probably be even more verbose with the try/catch wrapped around. > Errors passing silently – ticking time bombs to go Are you kidding? Unless exceptions are documented well, which they rarely are, this is a much greater problem when using exceptions.

> If you were to handle the same error cases in Python that you gave examples for in Go, it would probably be even more verbose with the try/catch wrapped around. Not sure what you are talking about: try: datastore.Get(c, key, record); viewTemplate.Execute(w, record); catch e: appError(e);

Is catching all exceptions really what you wanted to do here? A generic appError() is not equivalent to handling each possible failure more by type, as the Go example does.

Re: Why I’m not leaving Python for Go

#24

Post by wonderzombie »

je42 wrote: post #17
zik wrote: post #10

I suppose it's all a matter of taste. The error handling design decision is one thing I really like about Go. I write high reliability embedded software and "throw/catch" just doesn't cut it for me since it obscures possible error conditions thrown from subroutines. I want to have to explicitly deal with those errors whenever they might occur and error returns are a good way of doing that. For every language feature…

I cant follow. Throw/Catch is as powerful as a error return value but it does not let you ignore errors without writing any code.

Unless they're unchecked exceptions, of course. In Python, all exceptions are unchecked.

The proliferation of checked exceptions all throughout the code is a whole other ball of wax.

Re: Why I’m not leaving Python for Go

#25

Post by zobzu »

mquander wrote: post #9
bproctor wrote: post #3

I don't understand why anyone would "leave" a language that was working well for them just because of some hype. Don't get me wrong, I think we should all be striving to learn new things, but that doesn't mean we should just drop everything to jump on the next bandwagon.

Your statement seems self-contradictory. Should we strive to learn new things, or should we not jump on the next bandwagon? Are you saying that we should try new things but not really try them very hard, or what? There is such a thing as progress, and in my opinion the way you get it is by spending lots of time trying new things and seeing which ones work. So I'm in favor of "leaving a language that was working well…

Because hype != progress. Hype is basically a bag full of air.

You can try new things, but abandon the other ones because of hype (or thinking it's better cuz "ppl who don't know anything about languages said so") instead of true technical merit is pretty fucked up :)

Now then again Go ain't bad, but I don't see it being better enough than Python to switch in this case. Python in better for many things as well. Not a large step enough.

Re: Why I’m not leaving Python for Go

#26

Post by wonderzombie »

je42 wrote: post #18
cyberroadie wrote: post #13

The author of the blog post is overlooking a major feature here. Go does multiple return types, so you can do things like this: i, err := getValue() however if you want to ignore a return variable or in this case the returned error you use an underscore like this (same as in haskell): i, _ := getValue() This is Go's mechanism for handling (or ignoring errors) which imho is really nice because you don't have to learn…

That's not the same as handling an error in a central spot automatically.

Handling errors in one spot doesn't work for all situations, though, right? Especially in an OO environment an object may need context for retrying a request, or some other kind of error decision making. So in practice some exceptions percolate through the object graph, while others are handled in-house, so to speak.

Re: Why I’m not leaving Python for Go

#27

Post by ChuckMcM »

Heh, I thought the answer was "Because my blog is named uberpython and it would be way confusing." :-)

But error handling is one of those topics that really gets people going. From ABEND in the old IBM batch days, to uncatchable signals like SEGV in unix and uncaught exceptions in C++ or Java.

I tend to come down on the "decide what you are going to do in the code, right where the error occurs" flavor of the argument. So checking for errors when they occur is important to me, what to do next gets to be sticky.

So there are three things you want to do:

1) Easy - you just want to quit/die/exit pretend you never existed. This is pretty easy and most OS'es and embedded toolkits have something along the lines of 'exit' or 'exit_with_dump.' So that later you can try to reconstruct what happened.

2) Is "this is bad, but it might be ok later" where you want to unwind to the point where this started but not completely exit. Exceptions are pretty good for this if used well since you can catch them at the 'unwind' point and if you can attach the unwinding actions (closing files, freeing memory, etc) to the return stack then it can be managable.

3) You want to plod along in a degraded mode, which means you need some way of communicating with the rest of your code that you're damaged goods at some level.

Go has an interesting mix which I haven't used extensively but I wouldn't dismiss it out of hand. The folks writing it run services that continue through partial outages so if it were too egregious folks would rebel inside of Google.

Re: Why I’m not leaving Python for Go

#28

Post by d0m »

Jabbles wrote: post #7

It's not "tempting to ignore errors". You're the programmer, if you want to ignore it, do so. I don't know why you'd want to ignore the returned value and possible error on a GET request - given that 1) it can fail for so many reasons, and 2) the suggestion that you might be "GETTING" something. Ignoring the error of a print statement is more acceptable since it's unlikely to occur and there's rarely a lot you can do…

That's his whole point. He doesn't want to ignore errors but feels like Go is so verbose about it that it's a pain for programmers to deal with it. Example in case, print. Would you check its return value every time you call it? No.

Contrast that to other languages, such as python, where you don't ignore the errors because you know that if something goes wrong, an exception will be raised.

It lets you do stuff like:

def whatever(request): my_int = int(request.POST['some-param'])

Note that, in that case, we don't check if 'some-param' is in POST. Neither what happens if it's not a number.. Basically, an exception will be raised and a 404 will be shown.

Re: Why I’m not leaving Python for Go

#29

Post by tptacek »

I'm not in love with this aspect of Go either, and I also find that the idiom for dealing with it (multiple return values and multi-statement if conditional clauses) doesn't play well with Go's scoping rules, so that I find myself regularly having to decide between cleaner conditional or an explicit variable declaration. I also don't love how it makes my code look like my teenage-years C code.

But I also think this is a very silly reason to adopt or not adopt a tool. No other approach to error handling is less fraught.

If Python is your only language, Go or something like Go is probably a very useful thing to have in your back pocket: compiled native binaries, fine-grained control over memory layout, and a simple and effective concurrency model is a good thing to have in one package.

There are a lot of things that annoy me about Go (and for that matter Python, which irritates me for very similar reasons). What I tell myself to get over that and keep an open mind is, Go may not be my idea of an elegant language (yet; I'm still learning to appreciate it), but it is an excellent tool. I can get over the language stuff if the tool works well enough, and Go seems to for me.

Incidentally, who "leaves" a language? I have a very hard time seeing how, even from the label on the tin, anyone could believe Go is a great solution for every problem. Python sure as hell isn't either.

Re: Why I’m not leaving Python for Go

#30

Post by je42 »

wonderzombie wrote: post #23
je42 wrote: post #21

Earlier quoted context omitted.

> If you were to handle the same error cases in Python that you gave examples for in Go, it would probably be even more verbose with the try/catch wrapped around. Not sure what you are talking about: try: datastore.Get(c, key, record); viewTemplate.Execute(w, record); catch e: appError(e);

Is catching all exceptions really what you wanted to do here? A generic appError() is not equivalent to handling each possible failure more by type, as the Go example does.

My bad. Good point. I looked at what he meant - not what he wrote. :)
Post reply on HN