Go was designed to write systems-y back-end services. Functional languages are a terrible mismatch for this. 'No side effects' is great for certain types of coding, and terrible for systems integration where side effects are the whole point of what you're doing.

Could you please explain what you mean when you say they don't understand functional languages as well as you? The lack of eval() and code-as-data in Go? Something else?

I'd like to use map/fold/filter idioms instead of for loops, because this encourages me to write reusable functions instead of embedded blocks of code. To do this in Go, I need to write type-specific functions for every combination of passed function, source collection, and return-collection type. The alternatives I see in Go are to lose type checking or to fumble around with introspection and casts.

That sounds like it's actually a complaint about strong typing -- if everything's the same type, you can do that now by passing around first class functions.

There are plenty of strongly, statically typed languages which do not have this problem because they have parametric polymorphism, i.e. generics.

Reread the comment. It's a complaint about the lack of generics.

Aka polymorphic function parameters. If I manage to abstract a bit of functionality into a function, I don't care what the type is as long as the operations within the function work on it. Haskell uses typeclasses to provide this guarantee for specific types. Go seems to try to do something like this with interfaces, but it doesn't seem to apply to the map/fold/filter style of programming

Agreed, I think navel gazing about functional programming for a systems language is ill guided at best.

Go seems to be pegged as a complement/replacement for C/C++/D(maybe no experience)/misc assembly. I don't see how functional languages will help at all for these tasks. You could argue maybe that security would be improved to a degree, but I really am having a hard time at imagining a low level driver being written in purely functional code. I know of only forth being used for some of those tasks in things like boot proms but that is a bit different in that it wasn't really an entire os built on top of things.

I find this somewhat ironic as I'm currently looking to replace a number of ruby/perl/shell scripts at work with go this winter. Not for any reason of maintainability, but the horrible task it is to deal with gems/cpan/"extras". And rather than program in pain with C I was thinking go would be a decent compromise as I can make rpm's rather easily for deployment and a makefile. Go seems to be perfect for these glue level things that escape the basic confines of most scripting.

But I don't know yet, this weekend is my "learn go and find a test framework like rspec in it" task. It looks similar enough to C that I could get up to speed ish in a day.

'go test' is pretty straightforward. Not so much a framework as a tool -- I think you'll find that most of the language carries the opinion 'Frameworks are a straightjacket, libraries are a tool'.

Gotcha, i've only bought the pragmatic programmers ebook so far. Past that i've really not done much.

I take it the go vein is more akin to: everything a framework(insert noun here) does for you it does to you?

I wholeheartedly agree, note i've used ruby for about 10 years aka: before rails, and there are times I want to strangle rails with a garrote for some of its choices in how it does things.

Ranting done, do you/anyone have any specific codebases I should look to for a good example of go programming methodology?

The scripts that will be replaced tend to be fairly heave with i/o and other stupid process manipulation, i.e. detect that some subprocess sigtermed etc... pretty boring stuff normally but I use threading rather heavily in ruby at the moment. So doing concurrency a bit more easily would be nice, especially since most of the things are just i/o derivatives of pack/unpack calls on things across many many devices. I've tested out celluloid with ruby and its great, but again that gets to gem/dependency management horror.

Guessing I just need to work with it and I'll find things out. Should hop into a go irc channel if there is one on freenode.

#golang-nuts on freenode. The effective go document is pretty good for basics, especially concurrency.

Functional languages are not about having no side effects.

It's a major characteristic, often cited as a positive. I included a reference to eval(), as well. Please enlighten me as to what they're really about, then?

It is a major characteristic and it is positive. I work with backend services in clojure, we have a huge codebase and many programmers working in parallel in the project (6 right now). The code is straight forward, short and elegant with immutable functions and some few macros. It's the first time in my 10 years programming career that I can say that about the codebase I'm working in. I agree that it's hard to understand the benefit if don't know FP to some degree and don't have much experience working with it (Paul Graham blub paradox).

FP has many characteristics—at its core it's about programming with functions as first class values—but it was never about having no side effects, just about controlling side effects.

Go has first-class functions and closures.

Every pure FP approach to side-effects I've seen has been a mess, stuff like with-open-file. It's fine if that's the minority of your code and you're getting enough out of being able to pass code around as lists of nested statements to make that worth it. For go's stated use case, it's not worth it.

WITH-OPEN-FILE is not about controlling side effects at all; it's about making it hard to forget to close the file. Go's analogue is "defer".

In any case, I don't even know what we're arguing about anymore. My point is simply that FP is not about having no side effects, and saying "side effects are important" does not argue against the value of other FP innovations, such as HM-style type inference, option types, pattern matching, first-class functions, algebraic data types, etc.

When you say having no side effects is not a FP characteristic, then I say Hindley-Milner type inference, option types, pattern matching and algebraic data types aren't either. Many functional programming languages aren't even statically typed.

I'd go a step further and say that controlling side effects, as a consequence of pure-functional design, is a bigger part of FP than any given type system. But hey, what do I know, I just did the SICP exercises a decade ago and forgot about it afterwards.

We're in agreement that functional programming encompasses a range of characteristics and is hard to define.

You're saying that the type system has something to do with functional programming.

I'm saying that if Scheme, LISP and Haskell are all functional languages, obviously the type system is besides the point -- they're radically different in that aspect. Functional programming is about functions.

I'd say Scheme and Haskell are functional languages, as they emphasize programming in a functional style: Composing functions to process values. "Value-oriented programming".

I never understood why anyone classified Lisp (typically CL) as a functional language, as it isn't any more functional than Python, Ruby or Perl.

>Functional languages are a terrible mismatch for this

How? That is precisely what I use haskell for, and it has been by far the least terrible programming experience of my life.

>'No side effects' is great for certain types of coding

That comment shows a very superficial understanding of functional programming. Side effects are never the whole point of what you are doing. You are assuming "no side effects" means you are limited in some way. That is incorrect.

You seem to be under the impression that the only reason why someone would design or prefer an imperative language is that he doesn't understand functional languages.