Underscore.go(tobyhede.github.io)
tobyhede.github.io
Underscore.go
http://tobyhede.github.io/underscore.go/
16 comments
Totally agreed. I'd probably prefer to see one or two alphabetic characters as the package name (i.e., us). But that's just me.
> 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.
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.
It's possible to 'go get' this package using the import path "github.com/tobyhede/underscore.go/src". This import path does not follow Go conventions because the last element of the path is not the same as the package name. Otherwise, the path "github.com/tobyhede/underscore.go/src" follows Go conventions.
Yeah. The packages isn't correctly formatted ... fixing that.
It looks like the underscore naming is used to benefit from recognized branding of the JS library, not because it's the best name for a Go package.
It's Python all over again.
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?
But unfortunately, from a quick glance it looks like Go's doesn't, is that correct?
You can rename the package on import http://play.golang.org/p/V01jD_EZyX
Yeah, that's the general feedback I've had. Happy to take suggestions.
"un" or "us" might be preferable?
"un" or "us" might be preferable?
Then my hat's off to you. So many times I've critiqued some awful names, just for the package author to dig in and stand on their "rights" or whatever. It will be to your benefit, I think.
My only suggestion would be a meta one, which is that I would suggest using a nice, full name and letting people shortcut it themselves. "un" is hard to search for.
My only suggestion would be a meta one, which is that I would suggest using a nice, full name and letting people shortcut it themselves. "un" is hard to search for.
I went with "un" refactoring last night. But yeah, maybe a longer name is better.
un.Map, un.Reduce have a certain ring to them.
un.Map, un.Reduce have a certain ring to them.
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.
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?).
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?).
It depends on the level of abstraction with which the language was designed.
Go was designed for systems programming, and the code is intentionally verbose. A few extra characters, brackets, and syntactic constructs are a small price to pay for more control in performance-critical applications.
JavaScript was designed for the web to make authoring interactive pages easier. The web benefits as an ecosystem to have commonly-used abstractions for lower-level data transformations and common tasks.
So yes, there are reasons why a map shorthand is not needed. Mostly because it doesn't do anything a loop cannot, and the ecosystem in which it was developed does not benefit from it.
Go was designed for systems programming, and the code is intentionally verbose. A few extra characters, brackets, and syntactic constructs are a small price to pay for more control in performance-critical applications.
JavaScript was designed for the web to make authoring interactive pages easier. The web benefits as an ecosystem to have commonly-used abstractions for lower-level data transformations and common tasks.
So yes, there are reasons why a map shorthand is not needed. Mostly because it doesn't do anything a loop cannot, and the ecosystem in which it was developed does not benefit from it.
A systems programming language would never come with a baked-in, hardcoded garbage collector incapable of soft realtime applications and such a limited scope in utility, not such a constrained set of concurrency primitives and such a basic type system.
Seriously; LuaJIT achieves greater performance and has more abstractions in place; Rust fills the niche of systems programming languages easily.
I just fail to see the long-term utility of Go in a space where you have upcoming, high-performance languages like Julia and Rust, all while V8 and asm.js continue to improve in performance, LuaJIT wipes the floor in sheer speed for a dynamically typed language, C++ gets saner abstractions every day and the Erlang VM gets such a nice language as Elixir in the space of critical distributed apps.
Go would be interesting if you were at least getting something interesting out of that garbage collector in terms of type system goodness; as it stands Go is only slightly safer than C in that regard.
And by the way: what the hell does not having a Map() function have anything to do with performance? C++11 has std::transform which goes as fast as anything else. Any functional traversal of data structures can be trivially turned into an internal representation with the same performance characteristics as a loop. It's the biggest cop out ever.
Seriously; LuaJIT achieves greater performance and has more abstractions in place; Rust fills the niche of systems programming languages easily.
I just fail to see the long-term utility of Go in a space where you have upcoming, high-performance languages like Julia and Rust, all while V8 and asm.js continue to improve in performance, LuaJIT wipes the floor in sheer speed for a dynamically typed language, C++ gets saner abstractions every day and the Erlang VM gets such a nice language as Elixir in the space of critical distributed apps.
Go would be interesting if you were at least getting something interesting out of that garbage collector in terms of type system goodness; as it stands Go is only slightly safer than C in that regard.
And by the way: what the hell does not having a Map() function have anything to do with performance? C++11 has std::transform which goes as fast as anything else. Any functional traversal of data structures can be trivially turned into an internal representation with the same performance characteristics as a loop. It's the biggest cop out ever.
> A systems programming language would never come with a baked-in, hardcoded garbage collector incapable of soft realtime applications and such a limited scope in utility, not such a constrained set of concurrency primitives and such a basic type system.
- Mesa/Cedar (Xerox PARC)
- Modula-3 (Compaq/Olivetti)
- Oberon/Active Oberon (Swiss Federal Institute of Technology)
- Sing# (Microsoft Research)
- D (Digital Mars)
- Mesa/Cedar (Xerox PARC)
- Modula-3 (Compaq/Olivetti)
- Oberon/Active Oberon (Swiss Federal Institute of Technology)
- Sing# (Microsoft Research)
- D (Digital Mars)
Presumably you're contesting the garbage collection point? However, the statement was a conjunction of that and:
- not such a constrained set of concurrency primitives
- such a basic type system.
I imagine those languages have a good type system and/or good concurrency primitives (i.e. possibly making up for their GC "penalty").
- not such a constrained set of concurrency primitives
- such a basic type system.
I imagine those languages have a good type system and/or good concurrency primitives (i.e. possibly making up for their GC "penalty").
My main point was GC, yes.
Actually the original Oberon type system is simpler than Go's. Its later revision Oberon-07 is even simpler.
All the other ones I mentioned, have better type systems than Go, even support for some form of generics.
Concurrency depends on the language, but you get a mix of threads, co-routines, tasks, active objects and processes, overall.
Actually the original Oberon type system is simpler than Go's. Its later revision Oberon-07 is even simpler.
All the other ones I mentioned, have better type systems than Go, even support for some form of generics.
Concurrency depends on the language, but you get a mix of threads, co-routines, tasks, active objects and processes, overall.
Something that gets lost in the use of "System Language" is that the language was intended to make systems like a web server. This can have a garbage collector since it can pause a bit.
My point exactly is that Go provides nothing in this domain that hasn't been extensively traversed by other languages.
Language war? Really?
[deleted]
> It depends on the level of abstraction with which the language was designed.
> Go was designed for systems programming, and the code is intentionally verbose. A few extra characters, brackets, and syntactic constructs are a small price to pay for more control in performance-critical applications.
Rust offers more fine-grained control over memory, and things like map, filter etc. are more idiomatic than straight for-loops. They are implemented in a way that makes it a zero-cost abstraction compared to regular for-loops.
Generally I think Rust and Go gets compared too much, since they are very different languages both technically and philosophically. But the claim that things like map, filter etc. is unsuitable in a systems programming language (and Rust's definition of 'systems' has more stringent requirements than Go's definition of 'systems') is clearly false.
> Go was designed for systems programming, and the code is intentionally verbose. A few extra characters, brackets, and syntactic constructs are a small price to pay for more control in performance-critical applications.
Rust offers more fine-grained control over memory, and things like map, filter etc. are more idiomatic than straight for-loops. They are implemented in a way that makes it a zero-cost abstraction compared to regular for-loops.
Generally I think Rust and Go gets compared too much, since they are very different languages both technically and philosophically. But the claim that things like map, filter etc. is unsuitable in a systems programming language (and Rust's definition of 'systems' has more stringent requirements than Go's definition of 'systems') is clearly false.
It really is a foreign world to me where a loop is considered a "verbose idiom".
It's less about verbosity and more about the lack of clarity. `for (i = 0; i < myContainer.length; i++) { ... }` vs. `myContainer.map( ... )` - which tells the reader more about what the code does? Which of these lets the writer focus more on domain logic?
And something like groupBy is even worse.
But is there any reason to program in Go if you don't like idiomatic Go code (which seems to favour for-loops over higher-level abstractions)?
I can understand programmers wanting FP concepts and techniques in languages like C++; there is a lot of legacy C++ code, libraries and overall a large ecosystem. Some C++ programmers might either
1) have started programming in C++ many years ago (let's say 8+ years ago), and they might have thought that procedural and OO concepts where all that they wanted in C++. Now they might see some benefit in FP concepts, and want to see them used in C++, too. They don't want to switch languages because they already like C++ overall, and they have invested a lot of time into it.
2) They are "stuck" with C++ because of libraries, legacy code etc.
But the Go language is, what, 5 years old? It probably also has less legacy code, and I guess also relatively lacking ecosystem of libraries compared to other more established (or just older) languages. Why shoehorn FP concepts into Go instead of just moving on to a language where these concepts aren't seemingly going against the grain of the design of the language? Do most people really have a lot to lose from "ditching" Go?
I can understand programmers wanting FP concepts and techniques in languages like C++; there is a lot of legacy C++ code, libraries and overall a large ecosystem. Some C++ programmers might either
1) have started programming in C++ many years ago (let's say 8+ years ago), and they might have thought that procedural and OO concepts where all that they wanted in C++. Now they might see some benefit in FP concepts, and want to see them used in C++, too. They don't want to switch languages because they already like C++ overall, and they have invested a lot of time into it.
2) They are "stuck" with C++ because of libraries, legacy code etc.
But the Go language is, what, 5 years old? It probably also has less legacy code, and I guess also relatively lacking ecosystem of libraries compared to other more established (or just older) languages. Why shoehorn FP concepts into Go instead of just moving on to a language where these concepts aren't seemingly going against the grain of the design of the language? Do most people really have a lot to lose from "ditching" Go?
I almost, but not quite, entirely agree.
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.
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.
I like the philosophy here of "Move fast, optimize later". It is faster even if it isn't perfect for golang
What is the term for unpythonic in the Go community? This seems to be it. By the way it isn't using gofmt. https://github.com/tobyhede/underscore.go/blob/master/src/un...
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.
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.
goop. just kidding, i made that up, but i hope it sticks
It won't because "goop" is already a dependency manager for Go.
idiogomatic
I just disagree with some of the idioms :)
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".
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".
> What is the term for unpythonic in the Go community?
stoppy
stoppy
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!
http://blog.codegangsta.io/blog/2014/05/19/my-thoughts-on-ma...
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...
Oh hello. Library author here.
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.
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.
Not quite as interesting to see an _ clone after watching this critique of _ https://www.youtube.com/watch?v=m3svKOdZijA
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.
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.
It doesn't appear that it is complete when compared to the listed functionality on the site.
Yes, but gen is more general for type-driven code generation. It’s implemented as pluggable ‘typewriters’, which anyone can create: https://github.com/clipperhouse/gen/blob/master/CHANGELOG.md
The default ‘genwriter’ package does LINQ/underscore stuff. If someone wanted to go further with it, they could create a new package (or extend that one).
The default ‘genwriter’ package does LINQ/underscore stuff. If someone wanted to go further with it, they could create a new package (or extend that one).
Yeah. WIP that wasn't quite news-ready. :D
If there's a `src` folder in your repo, you're doing it wrong.
Yes, noted.
Love how the library takes advantage of Go's generics to expose parametric functional programming.
https://github.com/tobyhede/underscore.go/blob/master/src/un...
https://github.com/tobyhede/underscore.go/blob/master/src/un...
https://github.com/tobyhede/underscore.go/blob/master/src/un...
https://github.com/tobyhede/underscore.go/blob/master/src/un...
As a shameless, related plug, here's a clojure-like seq library I wrote for go:
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.
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.
I have done something similar in the past: http://ahmetalpbalkan.github.io/go-linq/ (https://github.com/ahmetalpbalkan/go-linq) this also has filter/map functions (where/select in LINQ) I haven't used reflection but callers should make type assertions needed.
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/
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.
Thanks that's an interesting idea
Ew, now you can have an awkward weak implementation of some FP ideas in Go too.
Yeah, I'm a bitch.
Yeah, I'm a bitch.
yo dawg, i heard you like FP...
really cool, thx for this. just what go needs imo.
The approach is interesting, but I'd really rather see a better name.