6 ms·

Agreed, but they also complained about map() and flatMap(). I have to think that eventually every developer can understand the more straightforward monads, fun

Agreed, but they also complained about map() and flatMap(). I have to think that eventually every developer can understand the more straightforward monads, functors, and Either - which, along with type aliases, IMO, can make code a lot more readable. I think the more esoteric features should be reserved for complex code, especially if it's possible that those features can prove runtime correctness at compile time and result in easily-composable modules. I wouldn't expect more than one or two developers to need to develop such a subsystem, however, so the "clever" is used in isolation.

faitswulff 10y ago
The full comment is actually: > No map, no flatMap, no fold, no generics, no inheritance… Do we miss them? Perhaps we did, for about two weeks. So they weren't complaining about map and flatMap, they just missed them.
- nine_k 10y ago
  They only missed these features for 2 weeks? Good for them! Their problem domain is likely so simple and neat that it fits the Go's limited built-in types well, and does not lead to frequent copy-paste programming. If so, Scala has been an overkill.
  - kjksf 10y ago
    As simple as a distributed, horizontally scalable SQL database, perhaps? (https://github.com/cockroachdb/cockroach https://github.com/cockroachdb/cockroach). Those dumb Go programmers and their toy programs (https://quicknotes.io/n/1XB0 https://quicknotes.io/n/1XB0).
    - nollbit 10y ago
      Software can be complex without having very complex types
    - nine_k 10y ago
      The guys who wrote CockroachDB never, afaik, tried to write it in Scala, and never told us whether they miss flatMap, generics, or something like that. They guys from Movio did; their problem domain is likely different.
    - pjmlp 10y ago
      I program since the mid-80's, many of the features in modern languages weren't always available outside research institute walls, and yet we managed to deliver any sort of software with the tools we had at our disposal. However, now that those features are part of the majority of mainstream languages, I surely don't want to go back to how I used to write software in the first two decades of my career.
    - unscaled 10y ago
      Developers have been using C and a bunch of other imperative languages for years. They obviously, created software two order magnitudes more complex than CockroachDB (or Docker, or Kubernetes, or etcd). We used to write entire operating systems in assembly, heavens forbid. Just look at the PostgreSQL codebase (all C) and compare that to cockroach DB. Being "a better C" was the original battle cry of Go. It's definitely better than C (well, at least for some thing), but it doesn't mean all of these complex C software people used to write are toys. Go is obviously not a useless toy language either. But that doesn't mean you won't miss features from more expressive languages. The amount of calls for generics from Go users tell a different story.
      - geodel 10y ago
        > The amount of calls for generics from Go users tell a different story I think it is from Non-Go users who would use Go if only it had generics.
        sanjayts 10y ago
        I do competitive programming using Go and sorely miss "generics" so I'm pretty sure that your thought is not entirely correct.
        unscaled 10y ago
        Some of it, probably. But some are probably using Go out of necessity (your company enforces Go), or because they still think Go is their best pragmatic option, lack of generics notwithstanding.
  - unscaled 10y ago
    Lucky bunch indeed. I'm 9 months in and still missing map(), flatMap(), let alone more advanced FP. I guess this is a matter of personal preference, but I definitely consider: users.filter(_.active).map(_.email) to be easier to read (and not a pain in the ass to type) than: emails := make([]string, 0) for _, u := range users { if u.active { emails = append(emails, u.email) } } return email The first style is more explicit about what you want to do, the second style is more explicit about how you want to do it. Go made imperative vogue again, but for me it feels like a throwback all the way to Turbo Pascal. Sure, the Go compiler is really fast, but Turbo Pascal would beat it hands down - on 20Mhz machines with 1MB of RAM.
    - pjmlp 10y ago
      > Sure, the Go compiler is really fast, but Turbo Pascal would beat it hands down - on 20Mhz machines with 1MB of RAM. With more features (TP 7)!
    - nunobrito 10y ago
      The second example is vastly more readable in terms of understanding what it is supposed to do. I mention this as neither a programmer on either Scala nor Go. If it is of any relevance, I've been writing code for about 20 years across C, Java, Javascript, PHP and shell scripts. I'm sure other FP developers will roll their eyes to a traditional developer like me but the one-liner you mention is simply not self-explanatory for an outsider when reading it.
      - spdionis 10y ago
        "I've been speaking italian, french and spanish for 20 years. I'm sure people who speak germanic languages will roll their eyes to a traditional latin-languages guy like me, but the german sentence you mention is simply not self-explanatory for an outsider when reading it."
      - kaoD 10y ago
        The second one is so readable it contains a subtle bug nobody noticed.
skybrian 10y ago
A for-each loop is only slightly longer, more familiar (just about every language has it), and more flexible - it covers map, flatMap, and reduce. So why have three or more specialized constructs when one will do? There are cases when the restrictions of map() and reduce() are necessary, most famously for a map-reduce in distributed programming, but that's not really relevant for implementing a simple function.
- macintux 10y ago
  I would argue that for loops are imperative, map/fold/etc are more declarative. That leads to various benefits such as less code, fewer bugs, fewer off-by-one errors. And, man, tail recursion in a language with function head pattern matching (ML family, Erlang) is so much easier to read than any complicated for loop. (Update: realized afterwards that "foreach" isn't quite the same as "for", but the larger point still stands, mostly.)
- jghn 10y ago
  When I was first introduced to scala my very favorite thing was the existence of map. I'd been using java for a while and missed it dearly
  - pjmlp 10y ago
    Not allowed to use Java 8?
    - jghn 10y ago
      Didn't exist at the time. While I still prefer scala to java 8, had the latter been available at the time I likely never would have dabbled in scala in the first place, if that makes sense
      - pjmlp 10y ago
        Sure it makes sense. I dabble in what sorts of programming languages, but when comes to work, it is mostly C#, Java, JavaScript and some occasional C++, because that is what customers pay for. Hence why I see a big value in mainstream languages slowly evolving into multi-paradigm ones, as many of us don't have the luxury to move beyond the first class languages of each platform.

faitswulff 10y ago

The full comment is actually: > No map, no flatMap, no fold, no generics, no inheritance… Do we miss them? Perhaps we did, for about two weeks. So they weren't complaining about map and flatMap, they just missed them.

nine_k 10y ago
They only missed these features for 2 weeks? Good for them! Their problem domain is likely so simple and neat that it fits the Go's limited built-in types well, and does not lead to frequent copy-paste programming. If so, Scala has been an overkill.
- kjksf 10y ago
  As simple as a distributed, horizontally scalable SQL database, perhaps? (https://github.com/cockroachdb/cockroach https://github.com/cockroachdb/cockroach). Those dumb Go programmers and their toy programs (https://quicknotes.io/n/1XB0 https://quicknotes.io/n/1XB0).
  - nollbit 10y ago
    Software can be complex without having very complex types
  - nine_k 10y ago
    The guys who wrote CockroachDB never, afaik, tried to write it in Scala, and never told us whether they miss flatMap, generics, or something like that. They guys from Movio did; their problem domain is likely different.
  - pjmlp 10y ago
    I program since the mid-80's, many of the features in modern languages weren't always available outside research institute walls, and yet we managed to deliver any sort of software with the tools we had at our disposal. However, now that those features are part of the majority of mainstream languages, I surely don't want to go back to how I used to write software in the first two decades of my career.
  - unscaled 10y ago
    Developers have been using C and a bunch of other imperative languages for years. They obviously, created software two order magnitudes more complex than CockroachDB (or Docker, or Kubernetes, or etcd). We used to write entire operating systems in assembly, heavens forbid. Just look at the PostgreSQL codebase (all C) and compare that to cockroach DB. Being "a better C" was the original battle cry of Go. It's definitely better than C (well, at least for some thing), but it doesn't mean all of these complex C software people used to write are toys. Go is obviously not a useless toy language either. But that doesn't mean you won't miss features from more expressive languages. The amount of calls for generics from Go users tell a different story.
    - geodel 10y ago
      > The amount of calls for generics from Go users tell a different story I think it is from Non-Go users who would use Go if only it had generics.
      - sanjayts 10y ago
        I do competitive programming using Go and sorely miss "generics" so I'm pretty sure that your thought is not entirely correct.
      - unscaled 10y ago
        Some of it, probably. But some are probably using Go out of necessity (your company enforces Go), or because they still think Go is their best pragmatic option, lack of generics notwithstanding.
- unscaled 10y ago
  Lucky bunch indeed. I'm 9 months in and still missing map(), flatMap(), let alone more advanced FP. I guess this is a matter of personal preference, but I definitely consider: users.filter(_.active).map(_.email) to be easier to read (and not a pain in the ass to type) than: emails := make([]string, 0) for _, u := range users { if u.active { emails = append(emails, u.email) } } return email The first style is more explicit about what you want to do, the second style is more explicit about how you want to do it. Go made imperative vogue again, but for me it feels like a throwback all the way to Turbo Pascal. Sure, the Go compiler is really fast, but Turbo Pascal would beat it hands down - on 20Mhz machines with 1MB of RAM.
  - pjmlp 10y ago
    > Sure, the Go compiler is really fast, but Turbo Pascal would beat it hands down - on 20Mhz machines with 1MB of RAM. With more features (TP 7)!
  - nunobrito 10y ago
    The second example is vastly more readable in terms of understanding what it is supposed to do. I mention this as neither a programmer on either Scala nor Go. If it is of any relevance, I've been writing code for about 20 years across C, Java, Javascript, PHP and shell scripts. I'm sure other FP developers will roll their eyes to a traditional developer like me but the one-liner you mention is simply not self-explanatory for an outsider when reading it.
    - spdionis 10y ago
      "I've been speaking italian, french and spanish for 20 years. I'm sure people who speak germanic languages will roll their eyes to a traditional latin-languages guy like me, but the german sentence you mention is simply not self-explanatory for an outsider when reading it."
    - kaoD 10y ago
      The second one is so readable it contains a subtle bug nobody noticed.

skybrian 10y ago

A for-each loop is only slightly longer, more familiar (just about every language has it), and more flexible - it covers map, flatMap, and reduce. So why have three or more specialized constructs when one will do? There are cases when the restrictions of map() and reduce() are necessary, most famously for a map-reduce in distributed programming, but that's not really relevant for implementing a simple function.

macintux 10y ago
I would argue that for loops are imperative, map/fold/etc are more declarative. That leads to various benefits such as less code, fewer bugs, fewer off-by-one errors. And, man, tail recursion in a language with function head pattern matching (ML family, Erlang) is so much easier to read than any complicated for loop. (Update: realized afterwards that "foreach" isn't quite the same as "for", but the larger point still stands, mostly.)
jghn 10y ago
When I was first introduced to scala my very favorite thing was the existence of map. I'd been using java for a while and missed it dearly
- pjmlp 10y ago
  Not allowed to use Java 8?
  - jghn 10y ago
    Didn't exist at the time. While I still prefer scala to java 8, had the latter been available at the time I likely never would have dabbled in scala in the first place, if that makes sense
    - pjmlp 10y ago
      Sure it makes sense. I dabble in what sorts of programming languages, but when comes to work, it is mostly C#, Java, JavaScript and some occasional C++, because that is what customers pay for. Hence why I see a big value in mainstream languages slowly evolving into multi-paradigm ones, as many of us don't have the luxury to move beyond the first class languages of each platform.