4 ms·

You can pretty much build whatever you want. The main advantages of Go is that it's Concurrent and it's a compiled language. Performance wise its faster than Py

You can pretty much build whatever you want. The main advantages of Go is that it's Concurrent and it's a compiled language. Performance wise its faster than Python and coding wise its faster than C. Basically its somewhere in between compiled languages and high level languages. In my experience programming in Go is very nice. It feels like you are coding in a scripted language but compiles. I don't recommend it for production unless you are one of those master coders. Its still a fairly new language and a lot of time I had trouble finding easy solutions that normally can be found on google / stackoverflow. I also wished the error handling was different. Although Golang community loves the error handling methods (you are suppose to handle the error like this), my code tend to be overflown by it.

Dewie 12y ago
> Basically its somewhere in between compiled languages and high level languages. High level languages and compiled languages are pretty orthogonal. A language being interpreted/running on a VM# is not a prerequisite for being at a certain level or higher. # And someone will complain that these are implementation details, not something to do with the abstract specification of the language itself.
kyrra 12y ago
Rob Pike made an interesting comment at the q&a for Gophercon I believe. Basically saying that error handling isn't anything special and he didn't want to create special syntax for handling error cases. Instead the syntax of the entire language is at your disposal to deal with errors. It was sort of a quick answer, so not really detailed. As well, panic/recover is there if you would prefer that, but err seems to work just fine.
- oelmekki 12y ago
  I got Pike's point on that, and love go overall, but this is really the topic on which I can't agree. The biggest problem with that is that throwing exceptions has a purpose : it makes errors interrupt program by default. With errors in go, that's the reverse : errors are ignored by default. Maybe it's just I'm too new in go, but I feel like I'd rather have my errors taken cautiously by default, with the possibility to ignore them (catch) than having to use variable and put if statement everywhere I care about errors (which pretty much means everywhere, in my current design style). Am I missing something, here, than can allow to avoid this verbosity ? (as for panic / recover, that's good for functions you implement yourself, but you still have to deal with errors from core / lib functions).
  - Matrixik 12y ago
    > Maybe it's just I'm too new in go, but I feel like I'd rather have my errors taken cautiously by default, with the possibility to ignore them (catch) than having to use variable and put if statement everywhere I care about errors (which pretty much means everywhere, in my current design style). That's what you should do. > With errors in go, that's the reverse : errors are ignored by default. To ignore errors in Go you need to explicitly ignore them because most functions return error.
    - oelmekki 12y ago
      > To ignore errors in Go you need to explicitly ignore them because most functions return error. What. If user has to write something explicitly, then it's not a default. That's pretty much the definition of "default". Or else, C has garbage collection, you just have to write it (and you explicitly ignore proper memory management by not writing it).
    - NateDad 12y ago
      So, most functions return two things - output data and an error. You have to assign both to something, like this: data, err := foo() and go forces you to use variables somehow, or it'll give you a compile time error, so you can't just assign it and never look at it. There are some functions which only return an error, and yes, for those, you can simply not assign the result to anything. However, in general, you should be suspicious of functions that get called that don't seem to return anything. Can they really never fail? Note that there are linters which will warn you if you are ignoring errors (google errcheck, I don't have the URL handy). Yes there's a lot of error checking code in Go, but that's a good thing. It's explicit, and it makes you actually think about the error case. My Go programs are WAY more robust than my programs from other languages.
      - oelmekki 12y ago
        Forcing you to think about your errors is a good point, there's nothing more painful than discovering that an exception is thrown on production. I still feel it's getting in the way of the "Go allows you to be more productive" stance, though. Also, it makes it very dangerous for people not rigorous enough that will not take enough care of their errors. Granted, "it allows bad developers to do bad things" should not be an argument, but I wouldn't be surprised we hear in a few years of big fails that will be imputed to go error handling (with headlines like "Foo.com tragic fail was due to go forgetful position on handling errors").

Dewie 12y ago

> Basically its somewhere in between compiled languages and high level languages. High level languages and compiled languages are pretty orthogonal. A language being interpreted/running on a VM# is not a prerequisite for being at a certain level or higher. # And someone will complain that these are implementation details, not something to do with the abstract specification of the language itself.

kyrra 12y ago

Rob Pike made an interesting comment at the q&a for Gophercon I believe. Basically saying that error handling isn't anything special and he didn't want to create special syntax for handling error cases. Instead the syntax of the entire language is at your disposal to deal with errors. It was sort of a quick answer, so not really detailed. As well, panic/recover is there if you would prefer that, but err seems to work just fine.

oelmekki 12y ago
I got Pike's point on that, and love go overall, but this is really the topic on which I can't agree. The biggest problem with that is that throwing exceptions has a purpose : it makes errors interrupt program by default. With errors in go, that's the reverse : errors are ignored by default. Maybe it's just I'm too new in go, but I feel like I'd rather have my errors taken cautiously by default, with the possibility to ignore them (catch) than having to use variable and put if statement everywhere I care about errors (which pretty much means everywhere, in my current design style). Am I missing something, here, than can allow to avoid this verbosity ? (as for panic / recover, that's good for functions you implement yourself, but you still have to deal with errors from core / lib functions).
- Matrixik 12y ago
  > Maybe it's just I'm too new in go, but I feel like I'd rather have my errors taken cautiously by default, with the possibility to ignore them (catch) than having to use variable and put if statement everywhere I care about errors (which pretty much means everywhere, in my current design style). That's what you should do. > With errors in go, that's the reverse : errors are ignored by default. To ignore errors in Go you need to explicitly ignore them because most functions return error.
  - oelmekki 12y ago
    > To ignore errors in Go you need to explicitly ignore them because most functions return error. What. If user has to write something explicitly, then it's not a default. That's pretty much the definition of "default". Or else, C has garbage collection, you just have to write it (and you explicitly ignore proper memory management by not writing it).
  - NateDad 12y ago
    So, most functions return two things - output data and an error. You have to assign both to something, like this: data, err := foo() and go forces you to use variables somehow, or it'll give you a compile time error, so you can't just assign it and never look at it. There are some functions which only return an error, and yes, for those, you can simply not assign the result to anything. However, in general, you should be suspicious of functions that get called that don't seem to return anything. Can they really never fail? Note that there are linters which will warn you if you are ignoring errors (google errcheck, I don't have the URL handy). Yes there's a lot of error checking code in Go, but that's a good thing. It's explicit, and it makes you actually think about the error case. My Go programs are WAY more robust than my programs from other languages.
    - oelmekki 12y ago
      Forcing you to think about your errors is a good point, there's nothing more painful than discovering that an exception is thrown on production. I still feel it's getting in the way of the "Go allows you to be more productive" stance, though. Also, it makes it very dangerous for people not rigorous enough that will not take enough care of their errors. Granted, "it allows bad developers to do bad things" should not be an argument, but I wouldn't be surprised we hear in a few years of big fails that will be imputed to go error handling (with headlines like "Foo.com tragic fail was due to go forgetful position on handling errors").