4 ms·

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

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.

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.