5 ms·

What sort of tools can I create in Go? Say I'm someone who programmed six years ago and since then has only a cursory exposure to Python, some Scala and Perl. W

What sort of tools can I create in Go? Say I'm someone who programmed six years ago and since then has only a cursory exposure to Python, some Scala and Perl. What "real" applications, desktop, server, web or otherwise, should I attempt to build? I've heard good things about Golang, then I hear things like its lack of generics make it useless for a lot of cases.

betadreamer 12y ago
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.
jmulho 12y ago
Rob Pike shows some of go’s strengths in this video: https://www.youtube.com/watch?v=f6kdp27TYZs https://www.youtube.com/watch?v=f6kdp27TYZs
vardump 12y ago
Lack of generics is not really significant. Other advantages in golang are worth much more than this minor deficit. Such as very fast compilation time, goroutines, channels, taggable structs (makes XML or JSON a breeze) and multiple return values -- one can get rid of bug inducing complicated control flow, that exceptions typically cause. Exceptions tend to be very hard to maintain and reason about and they tend to move the code dealing with the errors far away from where the exceptions are thrown. Probably a lot of people disagree about this, but humor me -- I write C++ as my dayjob. Oh, and I prefer golang's "defer" over RAII. It gets most of the job done in a way simpler fashion. Even when generics are available, they're about a fraction of one percent of code. Other languages have been doing just fine without generics. Even Java has just syntactic sugar compile time type erasure hack instead of the real deal. Those List<String>s are just List<Object>s in bytecode. I don't remember any C-programmer complaining either. What's very cool about golang in general, is that rather than including all the possible features you can think of (looking at you, C++!), it's more of how few features you can have while still having an expressive and powerful language. I don't mean to talk down other languages or to praise golang, but I do want to point out one should look at the big picture and not let small details distract. Such as lack of generics.

betadreamer 12y ago

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.

jmulho 12y ago

Rob Pike shows some of go’s strengths in this video: https://www.youtube.com/watch?v=f6kdp27TYZs https://www.youtube.com/watch?v=f6kdp27TYZs

vardump 12y ago

Lack of generics is not really significant. Other advantages in golang are worth much more than this minor deficit. Such as very fast compilation time, goroutines, channels, taggable structs (makes XML or JSON a breeze) and multiple return values -- one can get rid of bug inducing complicated control flow, that exceptions typically cause. Exceptions tend to be very hard to maintain and reason about and they tend to move the code dealing with the errors far away from where the exceptions are thrown. Probably a lot of people disagree about this, but humor me -- I write C++ as my dayjob. Oh, and I prefer golang's "defer" over RAII. It gets most of the job done in a way simpler fashion. Even when generics are available, they're about a fraction of one percent of code. Other languages have been doing just fine without generics. Even Java has just syntactic sugar compile time type erasure hack instead of the real deal. Those List<String>s are just List<Object>s in bytecode. I don't remember any C-programmer complaining either. What's very cool about golang in general, is that rather than including all the possible features you can think of (looking at you, C++!), it's more of how few features you can have while still having an expressive and powerful language. I don't mean to talk down other languages or to praise golang, but I do want to point out one should look at the big picture and not let small details distract. Such as lack of generics.