Re:Functional Programming in Go with Generics
by kaba0 on Thursday May 27, 2021 @05:04AM
(#27300774)
Making sense of a small, detailed part of a codebase is meaningless. But too much detail will make it much harder to see the big picture, something that may be more apparent in more expressive languages.
On a deliberate hyperbole, reading assembly, each line is trivial, but it is very very hard to make sense of what does it do compared to a line of a high level language.
Re:Functional Programming in Go with Generics
by gher-shyu3i on Thursday May 27, 2021 @08:28AM
(#27302183)
> I’m not sure exactly which qualities/features of Go make it so much easier to read,
In my experience, golang is harder to read. It's overly verbose that it's hard to figure out the underlying logic. What can be written as
items.filter(|n| n.price >= 10)
.groupBy(|n| n.source)
.mapValues(|v| v.sum()/v.length())
would be over a dozen lines of code in golang, with potentially one off functions everywhere. This only gets more obnoxious with larger code bases.The problem is that even if golang added generics, they won't be composable. In their proposal, they proposed adding map/filter/etc functions in a separate package, not as functions on slices as a proper language would do. The same mistake they did with not having any functions on strings, but kept them in a separate package.
Also, they need to improve their anonymous function syntax.
foo("param1", func(a int, b string) bool { return len(b) < a }
is verbose, more advanced languages simply shorten it to foo("param1", |a, b| b.length() < a)
or something equivalent
I’m not sure exactly which qualities/features of Go make it so much easier to read, but I worry that change will lead to the Go losing what makes it unique and special.
Side note: clojure was oddly the second easiest for me to read.