
Ask HN: Why Isn't Go Functional? - acolytic
One of the things I keep reading about functional languages is how they make reasoning about code easier and how this is particularly useful for distributed systems. Given that Go was built by Google specifically for the purposes of building distributed systems, why isn&#x27;t it functional?
======
mjfs
As discussed in the Go FAQ relating to the design principles of Go, the
language was designed with the idea of using it in situations as an
alternative to older object-oriented/procedural languages like C, C++, and
Java.[1] So they chose to make a language with less "book keeping and
repetition", and with a focus on ease of entry to the language itself.
Creating a purely functional or even mainly functional language to replace or
start new services and programs written or designed by people familiar with
the OO/procedural paradigm would be to add another entry barrier or level of
complexity to adopting the language. I believe this would be counter to their
goals for the language.

[1]
[https://golang.org/doc/faq#principles](https://golang.org/doc/faq#principles)

~~~
danielscrubs
I like that they aren’t trying to hide that it’s a beginner language.

------
tetraca
Go was built by Rob Pike and based upon the work that was done for the
distributed operating system Plan 9 and the Limbo programming language that
was built along with it. When these things were being developed, functional
programming techniques were not in vogue in the mainstream software
engineering world. It likely might not have been practical.

------
RamonSecora
Go was designed by some of the most gifted engineers of our time. In
particular, Rob Pike, and Ken Thompson had been working in distributed system
for more than 40 years, and before Google they worked for one of the most
renewed research facilities in the whole world.

Murray Hill gathered together people focused on solving real problems for the
most distributed industry in the last 150 years. They had the opportunity to
witness technologies and solutions that worked. And I quite sure that they
suffer those that doesn’t.

From my humble point of view, Go is a compromise of what works in real life,
the first time I see the go compiler, I traced it back to the good things of
Limbo, C, object oriented programming and the adding of a simple syntax to
create CSP concurrency made it a killer application.

------
lacker
The idea that functional languages are overall superior is just not accepted
by the majority of software developers. In practice, most popular languages
borrow many concepts that originated in functional languages, but don't
restrict themselves to being purely functional.

------
bjourne
They definitely make automated reasoning about code easier. But perhaps they
don't always make it easier for humans. See for yourself by comparing
functional and non-functional versions of various algorithms on this site:
[https://rosettacode.org/wiki/Sorting_algorithms/Merge_sort](https://rosettacode.org/wiki/Sorting_algorithms/Merge_sort)

------
a-saleh
I think Rob Pike, one of the inventors doesn't see the value of the functional
style, at least that is what I gather from the readme of
[https://github.com/robpike/filter](https://github.com/robpike/filter) :P

Personally, I would love if the language design was a step closer to I.e.
ocaml, especiall if I see the 'this is a struct, but only one of the fields
should be not-null' hack to implement sum-types, or when I see how closely
select over a channel resembles pattern-matching.

But the library ecosystem is good and 'just using forloops' is fine.

------
isacikgoz
There is no silver bullet for any kind of problem in software engineering.
And, distributed systems is no exception. Also, when designing a large system
e.g. a distributed system, the fact of selecting a language for its
functional, procedural or object oriented capabilities is not much important
afaik.

Hence, I think the first sentence of your question has no effect on the
question. For the question of >why isn't it functional? I think current state
of Go is performing enough for Google's problems.

------
naikrovek
It isn't purely functional, I don't think, but functions are a first-class
thing in Go, aren't they?

I mean, I've returned functions from functions, and passed functions as
parameters.. and there's no requirement that a function modify state
anywhere.. what else is required to be purely functional?

~~~
ninjaaron
In a purely functional language, functions apply inputs to a single expression
to produce an output (though there is usually a way to add some declarations
inside the function to keep the expression from getting to hairy). Side
effects are possible, but they are wrapped up as values that still have to be
passed around as functions and possible errors must be handled.

"Purely functional" means that pure functions are not only possible, but that
they are the only kinds of functions in the language.

While it might be theoretically possible to write purely functional code in
Go, it doesn't have mechanisms for treating side effects as values, and the
heavy reliance on arrays and channels and things would make it unnatural. Pure
functions don't contain loops because a loop is only used to generate side
effects. That would be hard in Go, but it's pleasant in languages that support
pure FP.

If this explanation sounds weird, learn some Haskell to get an idea of what
pure FP is like. It's fun stuff.

------
0815test
Go isn't functional because if it was, it wouldn't be Go; it'd be Haskell, ML
or Ocaml. Google didn't want to make a clone of Ocaml or the like; they wanted
something different. Hence, Go.

------
julienfr112
Because it's a language build by engineers with a pragmatical mindset ?

------
JaimeThompson
Because they wanted it to be actually usable by the vast majority of
programmers developing real world solutions? Not saying that functional
programming doesn't have a place but if it was as wonder as some people say it
is it would take over the world because the shops that used it would way
outperform those who don't but for most things that doesn't appear to happen.

~~~
beatgammit
That's a pretty poor argument. Functional programming isn't as popular because
it's more difficult to learn, not because it's not as good. Sometimes the
easier, almost as good solution is better than the technically superior
option, especially if you need a ton of people to learn.

Functional programming is certainly better in a lot of ways, but Google wasn't
trying to build a "good" language, they were trying to build a "good enough"
language, which is why it doesn't really innovate, but merely pulls in
familiar features into a simple package. Go isn't the best at anything, it's
just good enough at several things, and very simple to learn, and that's
exactly why Google uses it.

~~~
AnimalMuppet
No, they were trying to build a good language _for their set of problems_.
Their set of problems include huge numbers of engineers, and code bases in the
tens of millions of lines. They wanted short compile times, and ease of
reading code. They weren't going to get either of those by something in the
direction of Haskell.

And the result is not "just good enough". It's actually quite good _for their
problem set_.

------
coldtea
> _One of the things I keep reading about functional languages is how they
> make reasoning about code easier and how this is particularly useful for
> distributed systems. Given that Go was built by Google specifically for the
> purposes of building distributed systems, why isn 't it functional?_

1) Who said that what you "keep reading" about functional language is true?

2) Even if true, who said that what you "keep reading" about functional
language is true in all cases?

3) Who said other factors don't come at play, and might be even more
important?

4) Who said a language has to adopt functional principles wholesale, and isn't
it enough that it has some (as languages increasingly get)?

5) Doesn't the IT industry always find some methodology to hype as the silver
bullet, much akin to the diet industry? Maybe functional programming is one of
them?

6) If you don't have personal experience with functional languages or can't
personally appreciate whether they really do make "reasoning about code
easier", why take what you read about them at face value? Perhaps they miss
something?

7) To argue on the other side, who said that when a large company builds
something, they get it right? Often it's the inverse.

8) Who said Go was built "by Google" in the strong sense? Go was a rogue
project from a small team AT Google. It wasn't an official Google effort (the
way Java was for Sun, .NET for MS, and so on) to make an official Google
language. It's just that that group was concerned with "what language features
would be a good fit for the work with do here at Google" \-- but the inverse
is not true, Google as a company/management/etc wasn't concerned with building
such a language. They just went ahead with people devoting time to the
project.

9) Who said the Go team has kept with the times (or even with older but still
relevant PL research)?

What I write above are not answers and are not meant to be "the truth",
they're meant to make one see the situation more critically.

~~~
AnimalMuppet
Re 1: Who said? Those who wrote the stuff being read, of course. (You're
muttering "self referential" like that's some kind of a problem... /s)

Re 2 and 3: I think this is the big one. Functional language are great _in
some situations_. Non-functional languages are great _in some other
situations_. The problem is, someone who doesn't know functional languages
gets into a situation where they're good, finds out about functional
languages, starts using them, and a large number of their problems go away.
They _experience_ functional languages being wonderful. But they conclude
"functional languages are wonderful" rather than "functional languages are
wonderful _in that situation_ ", and they proceed to try to sell the world on
how wonderful functional languages are. (Not just functional - ditto for other
language styles and development techniques.)

The trick is, given the problem, to pick the right languages, tools, and
techniques, rather than to have One Right Answer.

Re 9: I'd say, given Pike's background, that he almost certainly knew at least
the older PL research. Ditto Kernighan (who didn't design the language, but
did write the book).

