Underscore was chosen in JS presumably because it is a valid variable name that isn't used for anything. Underscore in Go actually means something, which is why this is actually double-underscore, which makes it even visually more confusing.
The approach is interesting, but I'd really rather see a better name.
Module systems really ought to allow renaming on import. (Such as: rename individual functions, add a prefix to all of the functions, or even do a regexp style replace of all existing prefixes if any.)
But unfortunately, from a quick glance it looks like Go's doesn't, is that correct?
> Underscore in Go actually means something, which is why this is actually double-underscore, which makes it even visually more confusing.
It also breaks the conventions for Go package names. Except for the standard library, packages should be in hostname.tld/path/to/repo
e.g.: github.com/ChimeraCoder/anaconda
This is convenient because the import identifier, the relative path to the package on the filesystem (using $GOPATH as the root), and the location of the package on the Web are all the same.
If I saw this as an import, I would be confused as to where to go to find the canonical URL for the package.
Underscore is not a perfect fit for JS, but it's close enough; if you like coding in the style Underscore promotes, Underscore.js makes Javscript programming simpler.
Underscore seems like it would not at all be a good fit for Golang. Golang really wants you to just use a for-loop.
It seems that enough people are tired of such a verbose idiom in 2014 to merit a library like this.
I really dislike being that guy, but there's no reason why a language, today, shouldn't implement a decent map shorthand construction. For loops and unnecessary visual burden for a large variety of tasks and give no hint to the semantics of the code within a loop (is my loop doing a map, a transform, a reduction?).
This has come from some work I have been doing in Go. I was finding it very repetitive to constantly create basic constructs for common operations and patterns.
The approach I have been working with is using reflection based helpers to move fast, especially while exploring a problem space, and then refactor as appropriate when the design has solidified.
One advantage of underscore.go is you can create typed functions, so you aren't losing the compiler's help. The performance is generally OK, it is obviously slower than raw loops, but I think the tradeoff in many cases is worth it. In my experience, development time is a scarcer resource than cpu cycles. And nothing about this prevents you from gaining those cycles back when you need to.
It shows that the author knows how to code go, but I get the impression that go programmers are more picky about idiomatic code than even python programmers, so if the author wants to get into go development, the author should probably stop that and work on something more idiomatic.
The Go community is still small enough that any packages like this that get promoted become cringe-worthy if they are not idiomatic. If someone is coming from a javascript background and this is the first package they see, it might give them the wrong idea about Go.
While this could be considered pedantic idolatry by some, Codegangsta's very public admission on his experience with Martini (and now Negroni) show that this is a something to be considered when launching shiny new baubles.
In my opinion, the more attempts at stuff like this, the better. This is how we all learn!
Underscore.go is a mostly WIP that I hadn't intended to go live on HN :)
The general feedback so far is __ is annoying, I thought it was cool and if people were annoyed they could fix it on import. But I might be quite wrong on this one.
The directory layout is going to change and I am working on a branch at the moment that splits the whole thing into a file per algorithm, which makes things much easier to work with.
Neat.
I like that you can add your own type specific functions.
I was interested in seeing the implementation of the Parallel Map, but on a quick browser through the source, could not find it.
If you're interested in other works in the same space, I think think the the Gen library (http://clipperhouse.github.io/gen/) goes a long way towards providing type-safe, idiomatic, Go code to achieve the same effects.
This doesn't make things very slow but not very faster either. When you need performance, a code generator like this can help: http://clipperhouse.github.io/gen/
Using the function as the first argument and the iterable as the second, makes it easy to curry functions. A port of Ramda (https://github.com/CrossEye/ramda) would be better for this reason.
[+] [-] jerf|11 years ago|reply
The approach is interesting, but I'd really rather see a better name.
[+] [-] shurcooL|11 years ago|reply
[+] [-] tobyhede|11 years ago|reply
"un" or "us" might be preferable?
[+] [-] msutherl|11 years ago|reply
[+] [-] Toddward|11 years ago|reply
[+] [-] 6cxs2hd6|11 years ago|reply
But unfortunately, from a quick glance it looks like Go's doesn't, is that correct?
[+] [-] chimeracoder|11 years ago|reply
It also breaks the conventions for Go package names. Except for the standard library, packages should be in hostname.tld/path/to/repo
e.g.: github.com/ChimeraCoder/anaconda
This is convenient because the import identifier, the relative path to the package on the filesystem (using $GOPATH as the root), and the location of the package on the Web are all the same.
If I saw this as an import, I would be confused as to where to go to find the canonical URL for the package.
[+] [-] tptacek|11 years ago|reply
Underscore seems like it would not at all be a good fit for Golang. Golang really wants you to just use a for-loop.
[+] [-] Daishiman|11 years ago|reply
I really dislike being that guy, but there's no reason why a language, today, shouldn't implement a decent map shorthand construction. For loops and unnecessary visual burden for a large variety of tasks and give no hint to the semantics of the code within a loop (is my loop doing a map, a transform, a reduction?).
[+] [-] tobyhede|11 years ago|reply
This has come from some work I have been doing in Go. I was finding it very repetitive to constantly create basic constructs for common operations and patterns.
The approach I have been working with is using reflection based helpers to move fast, especially while exploring a problem space, and then refactor as appropriate when the design has solidified.
One advantage of underscore.go is you can create typed functions, so you aren't losing the compiler's help. The performance is generally OK, it is obviously slower than raw loops, but I think the tradeoff in many cases is worth it. In my experience, development time is a scarcer resource than cpu cycles. And nothing about this prevents you from gaining those cycles back when you need to.
[+] [-] cnaut|11 years ago|reply
[+] [-] benatkin|11 years ago|reply
It shows that the author knows how to code go, but I get the impression that go programmers are more picky about idiomatic code than even python programmers, so if the author wants to get into go development, the author should probably stop that and work on something more idiomatic.
[+] [-] lalaqpqp|11 years ago|reply
stoppy
[+] [-] tobyhede|11 years ago|reply
But yeah. This is all WIP and I haven't done any real cleanup. I posted it to some go friends on Twitter, it wasn't quite meant to become "news".
[+] [-] nestlequ1k|11 years ago|reply
[+] [-] shanemhansen|11 years ago|reply
[+] [-] ChikkaChiChi|11 years ago|reply
While this could be considered pedantic idolatry by some, Codegangsta's very public admission on his experience with Martini (and now Negroni) show that this is a something to be considered when launching shiny new baubles.
In my opinion, the more attempts at stuff like this, the better. This is how we all learn!
http://blog.codegangsta.io/blog/2014/05/19/my-thoughts-on-ma...
[+] [-] tobyhede|11 years ago|reply
Underscore.go is a mostly WIP that I hadn't intended to go live on HN :)
The general feedback so far is __ is annoying, I thought it was cool and if people were annoyed they could fix it on import. But I might be quite wrong on this one.
The directory layout is going to change and I am working on a branch at the moment that splits the whole thing into a file per algorithm, which makes things much easier to work with.
[+] [-] enneff|11 years ago|reply
[+] [-] alexpw|11 years ago|reply
[+] [-] garfij|11 years ago|reply
I was interested in seeing the implementation of the Parallel Map, but on a quick browser through the source, could not find it.
If you're interested in other works in the same space, I think think the the Gen library (http://clipperhouse.github.io/gen/) goes a long way towards providing type-safe, idiomatic, Go code to achieve the same effects.
[+] [-] ktsmith|11 years ago|reply
[+] [-] jprob|11 years ago|reply
[+] [-] tobyhede|11 years ago|reply
[+] [-] Kiro|11 years ago|reply
[+] [-] ankurpatel|11 years ago|reply
[+] [-] pjmlp|11 years ago|reply
https://github.com/tobyhede/underscore.go/blob/master/src/un...
https://github.com/tobyhede/underscore.go/blob/master/src/un...
[+] [-] mediocregopher|11 years ago|reply
https://github.com/mediocregopher/seq
It isn't quite as pretty as this one is, but it does support (thread-safe) lazy sequences.
As someone who writes lots of go code, I don't think either of these are actually necessary, although they may be fun to use in some cases.
[+] [-] ahmett|11 years ago|reply
This doesn't make things very slow but not very faster either. When you need performance, a code generator like this can help: http://clipperhouse.github.io/gen/
[+] [-] findjashua|11 years ago|reply
[+] [-] tobyhede|11 years ago|reply
[+] [-] Randgalt|11 years ago|reply
[+] [-] tobyhede|11 years ago|reply
[+] [-] maninalift|11 years ago|reply
Yeah, I'm a bitch.
[+] [-] igl|11 years ago|reply
[+] [-] mc_hammer|11 years ago|reply