3 ms·

I've historically been pretty pro-Scala 'round these parts, so my response to this should be considered in that light. So, with that disclosure out of the way..

I've historically been pretty pro-Scala 'round these parts, so my response to this should be considered in that light. So, with that disclosure out of the way... =) I have to admit, I don't agree with the assertion that the cognitive dissonance associated with programming in an imperative way versus a functional way is a major problem to Scala. I realize personal preference is a very big part of this, but there are many problems which are just easier to solve in a functional way versus an imperative way. Of course, the opposite holds true as well. This is the beauty of Scala; one can write performance-critical imperative code while exposing a functional interface; or, one can consume a fluent functional interface to produce imperative code. Frankly, I guess I've become something of a functional zealot, so my problem with Go is that it's so stubbornly imperative. This is why I can't get behind Go, as much as I want to. I feel like it doesn't consider many of the lessons that have been learned about FP making life easier. Set operations (map, filter, reduce) are insanely common, yet doing them imperatively sucks to the point of discouraging them. Excessive mutability is difficult to reason about. Nobody expects the nil/null/none inquisition. We tend to forget about side effects. Without an extensible language, which requires truly first-class functions, you're at the language designer's mercy. Hell, Scala probably isn't the be-all, end-all answer to all of this. I just don't think that a doggedly-imperative, non-composable, statement-oriented language is the future of programming "in the large", not when the past has shown us that we tend to produce buggy, unmaintainable software this way. I'm pragmatic enough to realize that pure FP isn't a solution, but I feel strongly that sticking to traditional imperative because it's familiar is a costly mistake. I can't argue with your take on the syntax, though, since that's personal preference. =) If you have any thoughts on why you feel productive in Go, I'd love to hear them; as I've said, I've been really struggling with motivating myself to learn and enjoy it.

realrocker 13y ago
Have ever tried programming in Go? Edit: Functional Programming in Go 1. http://stackoverflow.com/questions/4358031/functional-programming-in-go http://stackoverflow.com/questions/4358031/functional-progra... 2. http://golang.org/doc/codewalk/functions/ http://golang.org/doc/codewalk/functions/
- rybosome 13y ago
  I'm currently in a study group at work for Go, and I'm writing a few one-off personal tools with it. This is hardly serious experience, but it's enough to get a flavor for the language. As the other answer to your question states, adopting a functional style in Go is technically possible, but practically it is so inconvenient as to be unusable. EDIT: Take a look at this article, which explores developing a library that adds runtime-checked type parametric functions. http://blog.burntsushi.net/type-parametric-functions-golang http://blog.burntsushi.net/type-parametric-functions-golang Choice quote: "There’s no such thing as a free lunch. The price one must pay to write type parametric functions in Go is rather large: Type parametric functions are SLOW. Absolutely zero compile time type safety. Writing type parametric functions is annoying. Unidiomatic Go."
- gnuvince 13y ago
  Go doesn't lend itself to functional programming, in part because of its lack of type parametrization. In a language like Scala or Haskell, using functions like map, fold, and filter is clean an idiomatic. In Go, it is so ugly and convoluted that you immediately reject this approach and use for loops instead.
  - mseepgood 13y ago
    Standing firmly in one paradigm is a good thing for a language IMHO. I've worked in multi-paradigm languages and they suffer from the fact that their communities can't find a common style. "Should I use a fold or a loop or a tail recursion?", or some library designers want to be as typeful as possible, others don't, etc.
    - eru 13y ago
      > "Should I use a fold or a loop or a tail recursion?" Neither, use a combinator, like map or traverse. (And that applies to all languages that support this style.)
caciquefun 13y ago
Maybe you would try nimrod language, it's similar to go but a bit more functional, and it has generics and the concurrence is managed using actors (also supports channel's) , and rust also is a good language for functional programmers trying to find a good system language... Go language is so different to scala or Haskell because it follow the principle what a simple language is better than a complex one (the less powerful principle). The type system is a bit weak in go, probably one simplest type system ever, nimrod has a basic oop joining with algebraic data types and something similar to clojure multi methods, rust I believe has type classes..... So yes, I if you're happy writing functional code and using powerful languages maybe you will not totally happy with go language...
- rybosome 13y ago
  I'll have to look at Nimrod. You're correct about Rust; I've only read bits and pieces, but everything I've seen so far has left me with a positive impression.
neya 13y ago
I agree with everything you say. I think functional vs imperative is a matter of taste, though. Even I tend to incline towards Functional Programming (FP) in most scenarios, but in some cases imperative languages are 'good enough'. And since my background used to be client-side Javascript mainly (I was a front-end designer), I find it fairly confusing to switch myself between the two mindsets (FP and IP), which like you said is something more of a personal preference. And like I said, I still love Scala, for the reasons you've cited. But then again, there are a couple of reasons which I have in mind for going with Go. The main problem with Scala for me: 1) Difficult to find good Scala engineers. IF you find one, you still need to figure out if he's comfortable with the Functional or Imperative model. 2) Syntax: This is an example from one of my previous commenters (dxbydt, thank you) on my thread: scala> def test1 = println ("hello world") scala> def test2(f: =>Unit) = println ("hello world") scala> def test3(f:Unit) = println ("hello world") scala> test1 hello world scala> test2() hello world scala> test3() hello world scala> val t = test2 _ scala> t apply Unit hello world scala> t() hello world scala> t(()) hello world It is mostly a personal preference, but I still feel too many ways to do one thing is a recipe for disaster. With all that said, I know of people writing a Scala program and not touching it for a year or two unless they wanted to update their OS on their servers.
- rybosome 13y ago
  Nice example. It combines aliases for the Unit type with the sort of hybrid function/value nature of Unit to produce a truly baffling array of options. =) I'll agree that this set of cases does not reflect well on Scala; at the very least, it supports your point that the syntax is too large. Still, I don't mind it too much. Although the "multiple ways to skin a cat" nature of Scala means you can get very WTF-y code like above, it also means that you can construct a list by writing `1 :: 2 :: 3 :: Nil`, or send an actor a message with the Erlang-inspired `actor ! Message("hello")`. I don't want to be an apologist for it, though. You're correct that there are some nasty corner cases. Using Scala for serious work is difficult if people don't agree on a consistent style.

realrocker 13y ago

Have ever tried programming in Go? Edit: Functional Programming in Go 1. http://stackoverflow.com/questions/4358031/functional-programming-in-go http://stackoverflow.com/questions/4358031/functional-progra... 2. http://golang.org/doc/codewalk/functions/ http://golang.org/doc/codewalk/functions/

rybosome 13y ago
I'm currently in a study group at work for Go, and I'm writing a few one-off personal tools with it. This is hardly serious experience, but it's enough to get a flavor for the language. As the other answer to your question states, adopting a functional style in Go is technically possible, but practically it is so inconvenient as to be unusable. EDIT: Take a look at this article, which explores developing a library that adds runtime-checked type parametric functions. http://blog.burntsushi.net/type-parametric-functions-golang http://blog.burntsushi.net/type-parametric-functions-golang Choice quote: "There’s no such thing as a free lunch. The price one must pay to write type parametric functions in Go is rather large: Type parametric functions are SLOW. Absolutely zero compile time type safety. Writing type parametric functions is annoying. Unidiomatic Go."
gnuvince 13y ago
Go doesn't lend itself to functional programming, in part because of its lack of type parametrization. In a language like Scala or Haskell, using functions like map, fold, and filter is clean an idiomatic. In Go, it is so ugly and convoluted that you immediately reject this approach and use for loops instead.
- mseepgood 13y ago
  Standing firmly in one paradigm is a good thing for a language IMHO. I've worked in multi-paradigm languages and they suffer from the fact that their communities can't find a common style. "Should I use a fold or a loop or a tail recursion?", or some library designers want to be as typeful as possible, others don't, etc.
  - eru 13y ago
    > "Should I use a fold or a loop or a tail recursion?" Neither, use a combinator, like map or traverse. (And that applies to all languages that support this style.)

caciquefun 13y ago

Maybe you would try nimrod language, it's similar to go but a bit more functional, and it has generics and the concurrence is managed using actors (also supports channel's) , and rust also is a good language for functional programmers trying to find a good system language... Go language is so different to scala or Haskell because it follow the principle what a simple language is better than a complex one (the less powerful principle). The type system is a bit weak in go, probably one simplest type system ever, nimrod has a basic oop joining with algebraic data types and something similar to clojure multi methods, rust I believe has type classes..... So yes, I if you're happy writing functional code and using powerful languages maybe you will not totally happy with go language...

rybosome 13y ago
I'll have to look at Nimrod. You're correct about Rust; I've only read bits and pieces, but everything I've seen so far has left me with a positive impression.

neya 13y ago

I agree with everything you say. I think functional vs imperative is a matter of taste, though. Even I tend to incline towards Functional Programming (FP) in most scenarios, but in some cases imperative languages are 'good enough'. And since my background used to be client-side Javascript mainly (I was a front-end designer), I find it fairly confusing to switch myself between the two mindsets (FP and IP), which like you said is something more of a personal preference. And like I said, I still love Scala, for the reasons you've cited. But then again, there are a couple of reasons which I have in mind for going with Go. The main problem with Scala for me: 1) Difficult to find good Scala engineers. IF you find one, you still need to figure out if he's comfortable with the Functional or Imperative model. 2) Syntax: This is an example from one of my previous commenters (dxbydt, thank you) on my thread: scala> def test1 = println ("hello world") scala> def test2(f: =>Unit) = println ("hello world") scala> def test3(f:Unit) = println ("hello world") scala> test1 hello world scala> test2() hello world scala> test3() hello world scala> val t = test2 _ scala> t apply Unit hello world scala> t() hello world scala> t(()) hello world It is mostly a personal preference, but I still feel too many ways to do one thing is a recipe for disaster. With all that said, I know of people writing a Scala program and not touching it for a year or two unless they wanted to update their OS on their servers.

rybosome 13y ago
Nice example. It combines aliases for the Unit type with the sort of hybrid function/value nature of Unit to produce a truly baffling array of options. =) I'll agree that this set of cases does not reflect well on Scala; at the very least, it supports your point that the syntax is too large. Still, I don't mind it too much. Although the "multiple ways to skin a cat" nature of Scala means you can get very WTF-y code like above, it also means that you can construct a list by writing `1 :: 2 :: 3 :: Nil`, or send an actor a message with the Erlang-inspired `actor ! Message("hello")`. I don't want to be an apologist for it, though. You're correct that there are some nasty corner cases. Using Scala for serious work is difficult if people don't agree on a consistent style.