Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go Chainable: .map().filter().reduce() in Go

github.com

Post reply on HN
Print view View original

21–30 of 60 posts

Re: Go Chainable: .map().filter().reduce() in Go

#21

Post by ovao »

adam_arthur wrote: post #4

Are 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?

I’m fluent in JS/TS, Python, C++ and Go. Despite that I legitimately love all these languages for different sets of reasons, Go is, by a fair margin, my go-to.

After 15 some-off years of writing code, to me, the most key component to a language is the ability to grok a new codebase written in it quickly and be able to contribute with as little fuss as possible. The potential network effects to this are huge, and Go’s level of simplicity is central to that: there’s generally only a small handful of ways to implement a solution in Go, and the built-in testing, benchmarking (and now fuzzing) are really the icing on the cake for me. That the standard library is mostly comprehensive doesn’t hurt either.

TypeScript is probably a close second for me, but there’s a fair amount of complexity involved in testing and in choosing libraries to fill certain gaps. Feels like that’ll get more and more solved over time, but with Go there are really few arguments about it.

Re: Go Chainable: .map().filter().reduce() in Go

#22

Post by na85 »

seanp2k2 wrote: post #15
na85 wrote: post #10

Earlier quoted context omitted.

>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…

We're using go for some projects at work and I'm not a huge fan. I don't like things like the compiler just exiting 0 when a build completes with absolutely zero output by default. Things like logging feel too complicated for what they are. Errors that I ran into tended to be cryptic and hard to resolve. One of the main reasons we went with go for a particular project was the ease of distribution and being able to bu…

>I would have just used python or node

I've always stayed away from node because the ecosystem looks like such a shitshow from the outside, but the speed of V8 appeals to me.

Python is great for quick stuff that doesn't need to be performant. I use magic-wormhole and pgAdmin4 probably every day and they're great, but I shy away from Python for anything that needs threading.

One thing I will say in go's defense is that I found goroutines to be a fairly pleasant and straightforward experience (at least as far as multithreading can be straightforward and pleasant)

Re: Go Chainable: .map().filter().reduce() in Go

#23

Post by bouncycastle »

adam_arthur wrote: post #4

Are 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?

Of of the best things I like about is how all the source files are always following the same formatting rules. Also the idioms make it easy to read.

Re: Go Chainable: .map().filter().reduce() in Go

#24

Post by bobbylarrybobby »

svnpenn wrote: post #8

I 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.

The point of these functions is to give names to common operations that happen in loops so that you can read the code more quickly. Map: we're transforming values. Filter: we're dropping values. Reduce: we're accumulating. Yes you can write these out explicitly in a loop but then you actually have to read all of the associated noise to grok what's happening.

In addition, the method-based approach scopes the variables to each individual call so there's no risk of, say, transforming the loop variable but then accidentally filtering based on the original instead of the transformed.

Re: Go Chainable: .map().filter().reduce() in Go

#25

Post by erik_seaberg »

adam_arthur wrote: post #4

Are 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?

Never, but it’s steadily harder to avoid at my day job, so I’m in favor of at least having a dialect that is less obstinately broken.

Re: Go Chainable: .map().filter().reduce() in Go

#26

Post by mindwok »

throw_m239339 wrote: post #12
mohanmcgeek wrote: post #5

Earlier quoted context omitted.

People who prefer golang use it _because_ it is verbose. Nothing is implicit and that makes good easy to read.

> People who prefer golang use it _because_ it is verbose. I don't prefer Go because it is verbose, error as values without constructs to manage them is a pain in the ass. I'd use go over language X,Y or Z because of its standard library and ease of deployment. The language itself has great things but is verbosity, mainly when it comes to dealing with error C style, its absolutely not a feature. Now that we have gene…

For me, it is a feature.

Coming from languages with exceptions, where you have no idea if a function call is going to explode without praying that the library has its exceptions documented or reading the source code, having error values that you cannot (easily) ignore is a blessing. It's not as good as something like Rust's Result sum type, but it's pretty close. It makes you explicitly handle, or bubble up, every error in your program which in my experience is a huge cause of unexpected exits in other languages.

Re: Go Chainable: .map().filter().reduce() in Go

#27

Post by ovao »

na85 wrote: post #10
adam_arthur wrote: post #4

Are 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…

> No function overloading

In my experience, non-type-specific function/operator overloads ultimately end up being a pain point. They’re generally wonderful —- until they’re abused, for which there’s a tendency. That’s certainly true of C++, and likely true in other languages which support overloading to varying degrees. With generics, the potential value of overloading in Go should now almost always be (hopefully) close to zero, so I think this criticism may be less notable than it was before.

> Smug, snotty community (mostly #go-nuts on freenode/libera)

I wonder if that’s not specific to those communities rather than the Go community as a whole. My general pulse on things is that the community Go isn’t less inclusive than others, but that may be a biased viewpoint.

Re: Go Chainable: .map().filter().reduce() in Go

#28

Post by tptacek »

adam_arthur wrote: post #4

Are 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?

C, C++, Tcl, Python, Ruby, ES6, Common Lisp, Go, Rust. Go's my favorite of all of these, though not the best tool for every job.

I'd be unlikely to use a library like this in my Go code.

Re: Go Chainable: .map().filter().reduce() in Go

#29

Post by na85 »

ovao wrote: post #27
na85 wrote: post #10

Earlier quoted context omitted.

>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…

> No function overloading In my experience, non-type-specific function/operator overloads ultimately end up being a pain point. They’re generally wonderful —- until they’re abused, for which there’s a tendency. That’s certainly true of C++, and likely true in other languages which support overloading to varying degrees. With generics, the potential value of overloading in Go should now almost always be (hopefully) cl…

>I wonder if that’s not specific to those communities rather than the Go community as a whole.

Maybe. My experience with IRC communities, especially tech-focused ones, is that they tend to be pretty welcoming and friendly. For example #lisp and its sibling channels, on libera, are some of the nicest places around.

By contrast everyone I interacted with on #go-nuts seemed to have a huge chip on their shoulder and a quick snarky answer always at the ready for why Go is always better than $language in every way, no matter what.

Re: Go Chainable: .map().filter().reduce() in Go

#30

Post by tptacek »

chrismorgan wrote: post #6

Hmm. 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, r…

I don't love libraries like this and feel like they work against the idiom in Go; I'm skeptical that things like this will be part of the idiom going forward. But Rust isn't all wine and roses with this stuff either; obviously, it's a much more powerful generics system, but closures are much more annoying to work with than they are in Go, where everything just magically escapes to the heap when you need it to.
Post reply on HN