Hacker News Reader

Comment by t8sr | Hacker News Reader

When Go first started to get traction at Google, I saw it mostly replacing Python (and some Java), but not a whole lot of C/C++. As the adage goes, you can write Java/Python in any language, and a lot of people did, and from that time we have a lot of Go code with two specific smells:

1) A lot of channels, because Python coders wanted iterators. (This got so bad I've seen memos circulated about channels not being allowed to cross public API boundaries.) 2) A lot of interfaces, because of Java

I am really happy about the recent trend towards a more functional style in the language, it's so much closer to what I think the authors intended the language to look like.

View on HN

> I am really happy about the recent trend towards a more functional style

There is no such trend, at least not from the Go maintainers' side. Trying to write Haskell in Go is just as misguided and futile as trying to write Java in Go.

> in the language, it's so much closer to what I think the authors intended the language to look like.

I don't think so. The wanted it to be imperative like C or Pascal/Modula/Oberon, otherwise they would have started the design with ML or Lisp instead of C.

I think you're responding to something I didn't (intend to) say.

It is a lot closer in the sense that it is less indirected and simpler. The Go team have circulated style guidance to groups I was part of about how to properly structure public APIs, and for example functional callbacks are nowadays preferred over channels.

I completely agree that Go is not designed to be Haskell, and I personally cringe every time I see a library of map/reduce/filter functions. I still prefer this over the older sins of stuff like ITreeIterator.

When I say "functional style" I don't mean lambda calculus. I mean more recent libraries don't tend to return interface-typed values as much or use channels as iterators.

There's a widening generational gap in what "functional programming", in a practical sense, means. "Back in the day" a language got called 'functional' if it had anonymous closures, upwards funargs, tail calls, you could implement a decent `reduce`, etc. Today it means purity and immutability, monadic comprehensions, and type systems to support all that.

Go's the first kind of functional language. But so is almost everything else, even Java, now.

"Back in the day" we didn't call a language functional. The 1967 Lisp 1.5 Primer on my desk for example doesn't use the term at all. The widespread use of language categorization came with object oriented languages which used that as a marketing term.

OK boomer.

IIRC lisp was already called "functional" in the 1980s. It was in contrast to purely procedural languages. I cannot comment on the 1970s.

The functional Lisp (Lisp without assignment) was called "Pure Lisp" back then. Sometimes also there was the term "applicative language".

"Lisp, an acronym for list processing"

> “Back in the day” a language got called ‘functional’ if it had anonymous closures, upwards funargs, tail calls, you could implement a decent `reduce`, etc.

Back in the day, we talked about programming paradigms and whether or not a language supported them; we didn’t usually label languages by paradigm unless there was a fairly tight association of the paradigm with the language.

Reply on news.ycombinator.com