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

31–40 of 60 posts

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

#31

Post by avl999 »

This actually became a problem in Java after the streams API was introduced. A bunch of people in my company started writing Java code that looked nothing like Java with a bunch of chained functional style functions with liberal use of the Optional API where trying to decipher what was actually being done required stopping in your tracks and using the help of the IDE to figure out what type was being returned by each level of the chain. I myself fell victim to this and wrote code which made me feel clever in the moment but looking at it a couple of days later even I couldn't understand my own code.

If people want to write functional code they should use functional languages rather than writing non-idiomatic code in other languages.

Thankfully this style is unlikely to gain popularity in Go because they make the syntax for doing this verbose enough and ugly enough that most people aren't gonna bother with it except a top level map or filter.

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

#32

Post by Sytten »

tptacek wrote: post #30
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.

I used to hate the closure from rust but I learned to love it. With golang its a PITA to track down performance issues die to heap escape where it is explicit in rust.

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

#33

Post by stevekemp »

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 started my programming career with Perl, Assembly, C, and C++. Over the years I've touched Java, PHP, Lisp, Lua, TCL, Ruby, Python, FORTH, and others to a greater or lesser extent.

In all my current projects I default to starting with golang. Some things annoy me, but on the whole the benefits outweigh the annoyance.

I am very much looking forward to the pending 1.18 release - not for the generics, but for the fuzz-testing support. I've been fuzz-testing my applications/libraries for the past few years, and I think this is extraordinarily useful and I hope with a wider audience using such techniques we'll all benefit.

(golang developers already have a good culture of writing test-cases, much like Perl did back in the day with the TAP format. But fuzz testing is magical and often catches things developers didn't think about.)

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

#34

Post by tgv »

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?

Some time ago, I wrote this in JS. The function has an understandable name, and this line is commented, so the implementation isn't that important.

    return String(this.path).split(".").reduce((obj, attr) => obj[attr], this.object);
Compare that to

    let attrs = String(this.path).split(".");
    let obj = this.object;
    for (let i = 0; i
Yes, I'm a fan of Go. I've got ample experience in C, C++, Java, JS/TS, Python, and I've seriously tried Rust, and minor experience in a bunch of others (Scheme, Prolog, Perl, etc.), but I prefer Go for back-end software. The balance between abstraction and simply saying what you're doing is great. It may not be optimal, but it gets the work done, reliably and pretty fast.

The other day, there were some complaints about Celery; the OP noted that just starting the application took 280MB, after which it grows to 14.5GB. I've inherited two Python web apps, and I understand the pain. My Python apps grow to about 4GB each. The Go app I've written powers two other web apps, one of which has a higher usage than the Python apps, and it hasn't grown beyond 40MB, and barely uses CPU, on a low-powered virtual server.

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

#35

Post by nemo1618 »

37ef_ced3 wrote: post #16
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?

A bad programmer can make a mess in any language, including Go. A great example is this .map().filter().reduce() joke we're looking at today. Well-written Go is absolutely sublime.

I would argue that one of Go's strengths is its resistance to bad code.

Sure, you can still write gross Go. But I'll take gross Go over gross C++, gross Haskell, or gross Python any day.

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

#36

Post by TheDong »

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 a broad enough polyglot, and I find myself writing quite a bit of go.

I don't think go is a good language. It's not enjoyable to write. It's annoying to read. It doesn't bring me happiness.

Compared to rust, it has a ton of severe flaws. It doesn't have mutex guards, so manually releasing mutexes is the norm. Every error is returned as the 'error' interface, so your compiler can't tell you what types to check for (not that there are sum types anyway), nor can the function signature, and error handling in general is a total mess as a result. It's easy to mess up ownership with a few things, especially channels. It has its share of footguns and warts. It made the million dollar null mistake. It feels like writing code while hobbled with its intentional avoidance of macros, type-level abstractions, and a number of other "features".

But, compared to rust, it has a vibrant ecosystem of fairly mature libraries. If you want to, for example, speak some slightly obscure protocol, or interact with a somewhat unusual API, you'll usually find a pure go library that some pour soul has hacked out, one line at a time. In rust, you might find a half-completed nom parser some college kid wrote started and abandoned, if that.

There are other languages with this property (of libraries already existing for anything you might want to talk to), but these other languages are javascript and python, so if you want some semblance of speed and some semblance of a static type-system, Go's a good compromise between library support and static typing.

It's because of this reason that I begrudgingly use Go, even though as a language, I find rust, (modern) C++, and haskell to all be generally more pleasant to write and read.

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

#37

Post by saturn_vk »

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 agree, the current implementation is really not sufficient, at least for this. I played around with lazy iteration a while back and found the current restrictions would make working with it an annoyance.

I've placed some thoughts in the Readme [1] so I don't forget. Hopefully at least some of the restrictions will be dropped.

1: https://github.com/urandom/iter

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

#38

Post by jamil7 »

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 personally can’t stand the language itself but after using it a bit more I do see the appeal. A single install gets you a whole environment to compile / run / test / format backend code without dependencies. Compiler is really fast too (at least compared to Rust or Swift).

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

#39

Post by 4ad »

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?

I have a great deal of experience (decades) with assembly, C, Lisp, ML-style derivatives (Standard ML, OCaml, Haskell), shell script. Since Go is already 12 years old now and I've been doing it since day one, I guess it also belongs in this category.

I am very fluent in Rust, Prolog, Coq, Agda, Idris, Lean, Ada, Erlang.

I even have some professional experience with C++, Java, C#, Python, Objective C, Swift, APL, R, Julia, Matlab, Fortran.

And yes, Go is my language of choice in the domains where that makes sense, like servers and command-line tools.

> For example, the chainable methods are nice, but comparing to JS looks more like ES5 than modern code.

I don't know anything about JavaScript (except that I don't want anything to do with it), but the code in question is a far cry from idiomatic Go code.

> Do you find Go preferable to other languages for solo projects?

Absolutely, when that makes sense. For example, Go is a lousy language for writing a compiler in, I'd prefer to use OCaml for that. That being said, I wrote a couple of compiler targets for Go in Go. Even though ML-derivatives are a better fit for writing compilers, there's a much greater value in having the Go compiler itself written in Go.

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

#40

Post by erik_seaberg »

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.

Goto was simple and fast and did anything. We replaced that with if/then/else/while/foreach/return/throw because each of those clearly expresses what we’re currently doing and especially what we aren’t.
Post reply on HN