4 ms·

I took a couple minutes to whip up a quick map function, to be honest I didn't quite believe you. This may be my naivete, but is there any way it's not sufficie

• burntsushi 13y ago
  Here is something that is less onerous on the caller, but probably slower. [1] Here's the source. [2] [1] - https://github.com/BurntSushi/ty#examples https://github.com/BurntSushi/ty#examples [2] - https://github.com/BurntSushi/ty/blob/master/fun/list.go#L17 https://github.com/BurntSushi/ty/blob/master/fun/list.go#L17
• drewolson 13y ago
  I think the point is, if you write map like this you might as well be using a dynamically typed language in the first place because you're deriving no benefit from the type checker. In fact, you're just using casting to completely circumvent it.
  • pdeuchler 13y ago
    Of course. If the main cornerstone of your project is map it's probably not the greatest idea to use Go, but if you're using Go for other reasons and happen to need a quick map function there's no reason to change languages just because Go doesn't have a standard library implementation
    • bad_user 13y ago
      But then it's pretty odd to use Go because you like the language, while not being able to design a proper map(). And map() btw is only the tip of the iceberg in functional programming. But then again, Go is not a functional programming language.
• pcwalton 13y ago
  "I doubt that this impedes on programming efficiency compared to C." will not hold true if you're using reflection.