4 ms·

Go is often judged (and praised) based on it's concurrency. But I use map/filter/reduce, etc. far more often than I use concurrency. So no matter how great the

• kyrra 12y ago
  This was actually fairly heavily discussed on the Golang mailing list a few months ago[0]. For now I believe the designers of the language would rather keep things as simple as possible. For something that can be done with a fairly simple for-loop, they would rather have you write that out. If there is certain functionality that requires a complex amount of code, the would consider adding either a package to help or changing the language if needed. [0] https://groups.google.com/d/topic/golang-nuts/RKymTuSCHS0/discussion https://groups.google.com/d/topic/golang-nuts/RKymTuSCHS0/di...
  • Touche 12y ago
    They make a very poor argument against functional programming. They completely miss the composability it enables.
    • codygman 12y ago
      Wow, I saw this in that thread: " Functional programming languages don't have for loops, and so need to provide assistance to perform iterative tasks."
• NateDad 12y ago
  Loops make your life worse, really? Loops are trivial code that are nearly impossible to screw up. Writing a loop and writing map/filter probably take nearly the same time. If this is the biggest problem you have in coding, you're luckier than most.
  • Touche 12y ago
    Loops are very easy to screw up loops because it throws mutation into the mix.
    • kyrra 12y ago
      How do you mean exactly? Go has an iterable for map, slices, arrays, strings, channels with the "range"[0] keyword. The values returned by range are copies of whatever is in the structure so they should be immune to mutation (unless you're messing with pointers). [0] http://golang.org/ref/spec#RangeClause http://golang.org/ref/spec#RangeClause
      • rakoo 12y ago
        He means that what you actually want to do is modify some state outside of the loop when you're iterating, which means that your loop doesn't provide a "safe" context where you know what to expect. Are you sure you're modifying the correct outside variable ? Are you sure you really are modifying it: bar[i] = f(foo[i]) and not creating a new one: bar[i] := f(foo[i]) ? Are you sure you're not also modifying another variable that you didn't know was "linked" somehow ? Given the direction Go has taken, it would make very little sense to introduce functional programming bits. But you must admit that the immutability/lack of side effects of the FP gives you a lot of assurance on what to expect.
        • kyrra 12y ago
          I think you need to provide an example of what you're trying to say, as the syntax you showed above is not valid. the := operator is for defining a new variable, not for creating a new instance of some type. The := operator is just shorthand. foo := 5 is shorthand for: var foo int foo = 5 the "range" keyword over an array gives you the index and the value at that index. If you don't need the index or the value, you can put a "_" in it's place (to save on the allocation). http://play.golang.org/p/Z2ejUlN5An http://play.golang.org/p/Z2ejUlN5An You'll notice that foo[i] is still printing "0", because range always creates a copy of the object assigned into v. Unless you start using pointers, you'll never have mutation issues.
• findjashua 12y ago
  Same here - weak collections api is the main reason I'm sticking with Python for now.