11–20 of 20 posts
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?
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.
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…
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.
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 buil…
And the result is not "just good enough". It's actually quite good for their problem set.
> 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"…
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).
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…
I like that they aren’t trying to hide that it’s a beginner language.
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?
"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.
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…
Yes, less repetition and more
x, err := dostuff();
if err!=nil { return nil, err; }
y, err := otherstuff(x);
if err!=nil { return nil, err; }
z, err := morestuff(y);
if err!=nil { return nil, err; }
w, err := alsodo(x,y);
if err!=nil { return nil, err; }