Go Chainable: .map().filter().reduce() in Go
1–10 of 60 posts
Re: Go Chainable: .map().filter().reduce() in Go
#2Now that generics are in beta, here's a library for those who want ergonomic slice/map wrappers that make chainable operations easy.
Or, a gateway drug for ECMAscripters who can't drop their `.map(x => y).filter(x => y).reduce(x => y)` habit.
Re: Go Chainable: .map().filter().reduce() in Go
#3https://github.com/AlexanderYastrebov/stream is my take on this that does not re-allocate full slice on every filter/map operation
Re: Go Chainable: .map().filter().reduce() in Go
#4Are there people with experience in a wide variety of languages that prefer Go?
I've only used it in passing, but everytime I see examples they're verbose and look clunky.
For example, the chainable methods are nice, but comparing to JS looks more like ES5 than modern code.
Do you find Go preferable to other languages for solo projects?
Re: Go Chainable: .map().filter().reduce() in Go
#5Are there people with experience in a wide variety of languages that prefer Go? I've only used it in passing, but everytime I see examples they're verbose and look clunky. For example, the chainable methods are nice, but comparing to JS looks more like ES5 than modern code. Do you find Go preferable to other languages for solo projects?
People who prefer golang use it _because_ it is verbose. Nothing is implicit and that makes good easy to read.
Re: Go Chainable: .map().filter().reduce() in Go
#6Hmm. Implemented on a custom type that wraps []T, so you have to create a List to get the methods, meaning more boilerplate (a common theme in Go); eager, like JavaScript’s Array methods rather than like the iterator methods in Rust or most/all functional programming languages; and since methods can’t have generics (which really surprised me in the Go generics proposal), Map() can only work on the same type (T → T, rather than T → U), and Reduce()’s output type is a generic parameter on the list, so you can only ever reduce to one type (unless you deconstruct and reconstruct the List) which must be specified at instantiation time.
As one who works mostly in Rust and JavaScript and is passingly familiar with Go (I used it for a couple of projects eight and nine years ago), these seem some pretty severe limitations.
Rust’s trait-based iterator system is delightful, so that you can map, filter, reduce, &c. on any iterator, lazily, and even define an extension trait to define your own methods on any iterator, thereafter accessible by just importing that trait.
In the end, I think the current scope of generics and interfaces won’t be enough to produce any feeling other than “shoehorned” for this functional style in Go. It’s just not a style that works well in all types of programming languages.
Re: Go Chainable: .map().filter().reduce() in Go
#7Now that generics are in beta, here's a library for those who want ergonomic slice/map wrappers that make chainable operations easy. Or, a gateway drug for ECMAscripters who can't drop their `.map(x => y).filter(x => y).reduce(x => y)` habit.
Yep, nobody pipes data through any processing in say Haskell or Clojure.
Re: Go Chainable: .map().filter().reduce() in Go
#8I hate this. I don't know why people insist on forcing this programming style into every language. Loops exist for a reason. They are simple, they work, and nine times out of ten, they are faster than this crap.
Not every program needs to be golfed down to one line.
Re: Go Chainable: .map().filter().reduce() in Go
#9Are there people with experience in a wide variety of languages that prefer Go? I've only used it in passing, but everytime I see examples they're verbose and look clunky. For example, the chainable methods are nice, but comparing to JS looks more like ES5 than modern code. Do you find Go preferable to other languages for solo projects?
People who prefer golang use it _because_ it is verbose. Nothing is implicit and that makes good easy to read.
There are definitely people who prefer to use Go who think the verbosity is a downside. Someone had to craft the proposal for generics after all.
Re: Go Chainable: .map().filter().reduce() in Go
#10Are there people with experience in a wide variety of languages that prefer Go? I've only used it in passing, but everytime I see examples they're verbose and look clunky. For example, the chainable methods are nice, but comparing to JS looks more like ES5 than modern code. Do you find Go preferable to other languages for solo projects?
>Are there people with experience in a wide variety of languages that prefer Go?
Other than Go, I have varying levels of experience in C, C#, Common Lisp, Python, (embedded) assembler, Fortran, Tcl, PHP, and maybe a few other languages I screwed around with for fun.
At first I really really liked Go, and I grew to loathe it. I still think Go probably excels in large software development shops where some of its design decisions make a little bit more sense. For a solo project, unless you're trying to get hired to write Go professionally, I would avoid it.
Some complaints in no particular order:
- An unused import is a compile error, which means every time you comment out a variable while debugging, you also have to go fuck with your imports
- SemVer is baked right into the language, but Go simply cannot handle major versions > 1.x in any sane way. The documentation[0] actually recommends that you copy-paste your entire codebase into a separate v2/ subdirectory and then maintain that.
- No function overloading
- Annoying type/interface system
- Smug, snotty community (mostly #go-nuts on freenode/libera)
That's about all off the top of my head but it was enough to turn me away from go for good. If I was writing an httpd or something similar, as part of a large team, I might choose Go. For just about any other use case I would not, because it sucks for those use cases.