News for hackers. Stuff that matters.
Re:Functional Programming in Go with Generics by jshen on Thursday May 27, 2021 @01:38AM (#27299751)
I have similar feelings. I’ve been coding a long time, and the longer I do it, the less sure I am about any of this stuff. The one thing I can say for sure, I find it relatively easy to jump into an arbitrary go code base and make sense of it. I can’t say this about languages with all the features people are clamoring for, and I’ve worked on large projects in Ruby, python, Java, scala, clojure, swift, JavaScript, typescript, and a few others.

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.

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
Re:Functional Programming in Go with Generics by edem on Thursday May 27, 2021 @03:21AM (#27300312)
It is no surprise that Clojure was the easiest to read. It is composed of S expressions and some syntactic sugar.