Things from Python I'd miss in Go • Hacker News Board

Re: Things from Python I'd miss in Go

#11

Post by drdaeman » Tue, Jun 10, 2014, 1:43 PM UTC

nkozyra wrote: post #5

The error handling one is an area I've never understood - in a well-designed Go app errors will be returned from functions/methods and you'll either deal with them or not _/err. I love try/catch/finally but I fail to see how doing either a _ or writing a simple log function to do something with returned errors necessarily represents "more code" than handling exceptions.

That creates some mostly unnecessary boilerplate. I.e., if an error happens down the stack in function to read config, which calls a function to parse a file, which calls a function to read a file, you'll have to either propagate (or otherwise handle) that `err` manually or lose the precious information.

On the contrary, Java-like pattern of functions like `Config readConfig() throws IOError, ParseError` simplifies code quite a bit. No need to deal with IOError in parseConfig - if an exception happens there it'll be propagated automatically. And `throws` clause allows for static checking and warning whenever you forgot to handle something. And sane code analysis tools would also warn you whenever you really wanted overly-broad `catch Exception(e)`, too.

There's a panic/recover in Go, but they aren't serious. At least, to my limited knowledge of Go, there are no guidelines on using them properly, so everyone panics with whatever they fancy, and this lack of conventions is a bit problematic, like `raise "Failed to open file"` in Python.

Re: Things from Python I'd miss in Go

#12

Post by atilaneves » Tue, Jun 10, 2014, 1:44 PM UTC

I've been waiting for someone to weigh in on this from the Python side for a while now. I'm a C++ and Python programmer (amongst other things) and I can't ever see myself switching to Go. I'd sooner switch to Rust or Swift, but D has been my favourite language by far since I picked it up last year.

I actually don't understand why, in the absence of niche use-cases, how and why Python programmer would write Go code and _like_ it. Are these Python coders who've never heard of itertools??

Re: Things from Python I'd miss in Go

#13

Post by gbog » Tue, Jun 10, 2014, 1:48 PM UTC

When I read go specs or go vs python comparison, nearly every diff is a specific pain point of our big python code base.

No keyword argument? to hell with them. Strict formatting? That should be in python interpreter. No unused import: would have saved our lives. No cyclic dependencies? No inheritance? No exceptions? Great, all of them are maintenance nightmares.

Re: Things from Python I'd miss in Go

#14

Post by RBerenguel » Tue, Jun 10, 2014, 1:49 PM UTC

drdaeman wrote: post #11

nkozyra wrote: post #5

The error handling one is an area I've never understood - in a well-designed Go app errors will be returned from functions/methods and you'll either deal with them or not _/err. I love try/catch/finally but I fail to see how doing either a _ or writing a simple log function to do something with returned errors necessarily represents "more code" than handling exceptions.

That creates some mostly unnecessary boilerplate. I.e., if an error happens down the stack in function to read config, which calls a function to parse a file, which calls a function to read a file, you'll have to either propagate (or otherwise handle) that `err` manually or lose the precious information. On the contrary, Java-like pattern of functions like `Config readConfig() throws IOError, ParseError` simplifies c…

The standard is usually

    if err != nil {
        return (whatever null type), err
    }

The error will propagate up, since all calls to a function returning err should be checking for the err. In a not-so-ideal world, just return err up. In a relatively more sane world, you can send "up" extra information along the error (just creating a new error with extra info) to know the error path. The first caller will/should handle this error then.

Re: Things from Python I'd miss in Go

#15

Post by baldfat » Tue, Jun 10, 2014, 1:51 PM UTC

There is no one best language.

Numpy is not something Go is going to do (Correct em if I am wrong). Julia would be the faster language to switch to, but personally I switched from Python to R due to the fact that I like languages that are made for what I am doing. Python always feels second best to whatever I am doing and I have branched away from Python. So R for statistics is great for me.

Re: Things from Python I'd miss in Go

#16

Post by rogerdpack » Tue, Jun 10, 2014, 1:51 PM UTC

Did he say that people looking for faster build times than C++ went to java? They may not have found what they were looking for, in that case...

Go does lack a quality [IMO] IDE [re: REPL use is for development], but that can still come with time.

Quality GUI bindings can also come with time [how often do you actually use Python for GUI stuff, though...but still nice to have, just not its major use I doubt]

Another thing you'll miss from Python is accidentally typo'ing variable names and having to discover that only at runtime :)

Just my rebuttal :)

Re: Things from Python I'd miss in Go

#17

Post by moreentropy » Tue, Jun 10, 2014, 1:53 PM UTC

drdaeman wrote: post #11

nkozyra wrote: post #5

The error handling one is an area I've never understood - in a well-designed Go app errors will be returned from functions/methods and you'll either deal with them or not _/err. I love try/catch/finally but I fail to see how doing either a _ or writing a simple log function to do something with returned errors necessarily represents "more code" than handling exceptions.

That creates some mostly unnecessary boilerplate. I.e., if an error happens down the stack in function to read config, which calls a function to parse a file, which calls a function to read a file, you'll have to either propagate (or otherwise handle) that `err` manually or lose the precious information. On the contrary, Java-like pattern of functions like `Config readConfig() throws IOError, ParseError` simplifies c…

OTOH, if you follow Go's idioms and handle every error where it happens, your code will look like having a lot of boilerplate at first, but you end up with better error handling. It's the same as putting a try-except catchall around every single call in python, because in python you can never be sure (without reading the source) what kind of exceptions something will throw.

For request based services and something where some big ass operation will either fail in some way (and i don't care where exactly) or be successful, exceptions are fine. If something goes wrong somewhere, log it and reply with HTTP 500. But for servers with data i care about, i most likely want to recover right where the error happened, and actively decide if i want to abort and push the error to the next layer. Not having exceptions makes this more intuitive.

Re: Things from Python I'd miss in Go

#18

Post by drdaeman » Tue, Jun 10, 2014, 1:54 PM UTC

atilaneves wrote: post #12

I've been waiting for someone to weigh in on this from the Python side for a while now. I'm a C++ and Python programmer (amongst other things) and I can't ever see myself switching to Go. I'd sooner switch to Rust or Swift, but D has been my favourite language by far since I picked it up last year. I actually don't understand why, in the absence of niche use-cases, how and why Python programmer would write Go code an…

There are some Python programmers who sometimes regret Python doesn't have some static typing.

Go has that and also provides an easy way to be quite dynamic when that's wished for (or even when not - without generics one'll have to resort to `interface{}` even if that's not desired, huh).

Re: Things from Python I'd miss in Go

#19

Post by zimbatm » Tue, Jun 10, 2014, 1:54 PM UTC

drdaeman wrote: post #11

nkozyra wrote: post #5

The error handling one is an area I've never understood - in a well-designed Go app errors will be returned from functions/methods and you'll either deal with them or not _/err. I love try/catch/finally but I fail to see how doing either a _ or writing a simple log function to do something with returned errors necessarily represents "more code" than handling exceptions.

That creates some mostly unnecessary boilerplate. I.e., if an error happens down the stack in function to read config, which calls a function to parse a file, which calls a function to read a file, you'll have to either propagate (or otherwise handle) that `err` manually or lose the precious information. On the contrary, Java-like pattern of functions like `Config readConfig() throws IOError, ParseError` simplifies c…

The readConfig example is not really an issue in go. Just return the io error and type switch after the readConfig.

    if config, err := readConfig(ioReader); err != nil {
      switch err.(type) {
      case io.ErrClosedPipe:
        // do one thing
      case ParseError:
        // do something else
      case ...
      }
    }

Re: Things from Python I'd miss in Go

#20

Post by adwn » Tue, Jun 10, 2014, 1:58 PM UTC

It's ironic that the author dismisses C++ to a small niche:

> Those who still stick to C++, after all these years, either really can't live with the "overheads" (real time apps - those are waiting for Rust to mature), or think they can't (and nothing will convince them except a competitor eventually forcing their employer out of business).

Yet later he gives a good example for an important area where C++ is still unbeaten: scientific computing libraries.

If you want/need maximum performance, then right now, there's no other language that has no overhead and zero-cost abstractions (to the degree that C++, especially C++11, has them). Hopefully Rust will get there eventually, but as of today, you have three choices: Fortran, C, and C++ – and neither C nor Fortran offer any abstractions worth mentioning.