Hacker News Reader

Comment by pdeuchler | Hacker News Reader

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 sufficiently generic for types? I realize it's not suitable for maps, but it satisfies the OP's request for a map that can convert arrays of type Foo to type Bar

http://play.golang.org/p/jxMFq5UYs1

View on HN

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.

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

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.

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 [2] - https://github.com/BurntSushi/ty/blob/master/fun/list.go#L17

"I doubt that this impedes on programming efficiency compared to C." will not hold true if you're using reflection.

Reply on news.ycombinator.com