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?
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.<p>[1] <a href="https://golang.org/doc/faq#principles" rel="nofollow">https://golang.org/doc/faq#principles</a>
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.
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.<p>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.<p>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.
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.
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: <a href="https://rosettacode.org/wiki/Sorting_algorithms/Merge_sort" rel="nofollow">https://rosettacode.org/wiki/Sorting_algorithms/Merge_sort</a>
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 <a href="https://github.com/robpike/filter" rel="nofollow">https://github.com/robpike/filter</a> :P<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.<p>But the library ecosystem is good and 'just using forloops' is fine.
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.<p>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.
It isn't purely functional, I don't think, but functions are a first-class thing in Go, aren't they?<p>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?
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.
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.
><i>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?</i><p>1) Who said that what you "keep reading" about functional language is true?<p>2) Even if true, who said that what you "keep reading" about functional language is true in all cases?<p>3) Who said other factors don't come at play, and might be even more important?<p>4) Who said a language has to adopt functional principles wholesale, and isn't it enough that it has some (as languages increasingly get)?<p>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?<p>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?<p>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.<p>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.<p>9) Who said the Go team has kept with the times (or even with older but still relevant PL research)?<p>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.