6 ms·

Two words: error handling and generics.

• NateDad 12y ago
  I agree, those are two great reasons to use Go.
  • NateDad 12y ago
    Totally worth the downvotes for my own amusement. :)
  • baldfat 12y ago
    Why down vote some who likes the fact that he likes the error handling method in Go and that he doesn't like generics?
• touristtam 12y ago
  that's 4 words .... and if you are not comfortable with those two aspect of the language and have the choice, I don't see why you need to use golang.
• danieldk 12y ago
  Error handling is something that I did get used to, especially considering that one can assign and check in an if-statement. Generics I still miss every single day. But not enough to stop using Go. It's pretty much C with interfaces, a garbage collector, and safety. What more can one wish for?
  • monocasa 12y ago
    No garbage collector so I can actually use it in embedded situations.
    • jksmith 12y ago
      Easy target response I know, but hey it's open source so fork it.
    • NateDad 12y ago
      That's not really what Go is for. Look at Rust if that's what you want - memory safety without a garbage collector.
    • danieldk 12y ago
      I should stop using rhetorical questions :). But indeed, such embedded applications are not Go's domain.
  • nutate 12y ago
    Have you tried go gen? It looks clearer to me than some of the hoops I've seen set up, jumped through, etc for heavy STL generics: http://clipperhouse.github.io/gen/ http://clipperhouse.github.io/gen/ It just creates the code for you, then you commit it. Easy enough.
    • danieldk 12y ago
      It just creates the code for you, then you commit it. Easy enough. Except that it does not provide the same thing. If I provide a package with e.g. a container datatype, I would have to generate for every possible data type that any user wants to put in the container. Obviously, that is not going to scale.
      • NateDad 12y ago
        Not really.. you provide the base code, and the consumer of your package generates the specific types they need. As the package author, you don't actually generate any of the concrete implementations.
        • danieldk 12y ago
          Which defies the whole point of easy go-gettable packages. gen is a good contribution, but it only works for a subset of cases. E.g. I follow a comparable approach in my Java library for finite state dictionaries because Java does not provide generics over primitive types (luckily, that is a closed class). But it's less than ideal.
    • ufo 12y ago
      Code generation tools like go gen are good for those situations where you have boilerplate code based on the structure of your type, like serializers, comparison functions, etc. On the other hand, these tools do not help you create abstractions or decoupled interfaces. An analogy would be the "deriving" system in Haskell. It doesn't replace the generics system, it just complements it.
• donatj 12y ago
  Go's error handling is honestly the best I've ever used. No errors go unhandled. Period. get an error? Return it or deal with it. Makes much more sense than exceptions suddenly breaking the behaviour of the language.
  • sfk 12y ago
    How are errors in deferred functions handled? How about division by zero?
    • NateDad 12y ago
      errors in deferred functions are handled just like they would be if the function were not deferred. There are some things like division by zero and array index out of bounds that cannot be used with this method without making the language incredibly cumbersome... for those, there are panics (basically like exceptions in other languages)... but they happen quite rarely in practice.
    • Jayschwa 12y ago
      Deferred functions can pass along errors by using a closure. http://play.golang.org/p/_ZqSk470-b http://play.golang.org/p/_ZqSk470-b
  • politician 12y ago
    It's not actually true that no errors go unhandled. func foo() error { return errors.New("whoa!") } func bar() { _ := foo() // onward! }
    • NateDad 12y ago
      Uh yes? This is you telling the compiler specifically that you don't care about the error. It's equivalent to try { foo() catch {} In other languages. That's not a problem, that's the computer doing what you explicitly told it to do.
  • kornish 12y ago
    Not quite: here's an example of code which returns an error but for which the return value is never even captured. http://play.golang.org/p/EL2-2gl7wh http://play.golang.org/p/EL2-2gl7wh