4 ms·

Fair points. I haven't worked with Go in a few years, and I remember hating it when I did, but I feel like I remember hating Java more. It's possible that part

Fair points. I haven't worked with Go in a few years, and I remember hating it when I did, but I feel like I remember hating Java more. It's possible that part of the Java hate is not from the language itself, but from the ecosystem. Can you elaborate on Java streams vs Go's containers? I assume you mean things like List and Heap in Go? I'm not sure why you'd compare those to Java's stream API rather than Java's collections. In any case, I do agree that Java's standard library has WAY better collections than Go does, and Go doesn't have the excuse of wanting a minimal standard library. However, I'll push back a bit on the complaint that working with Go's containers/collections/whatever requires imperative code for everything. Now, I'll remind myself that one of your original points was that Go was "actively hostile toward functional programming" and I retorted to imply that Java was just as bad at all of the things you mentioned. I'll concede that Java isn't actually quite as hostile toward functional programming as Go. But, I'll move the goalposts a bit and claim that supporting some few functional programming patterns isn't inherently good and doesn't automatically make a language better. > And endless `if err != nil return err` every time you want to call a function - which actually destroys useful stack information. I agree and disagree. I'm one of the few people who still thinks that checked exceptions are a good idea for a language. I have my complaints about how they're implemented in Java, but I think the concept is still a good one and I honestly think that even the Java implementation of checked exceptions is mostly fine. The issue, IMO, is with training and explaining when to use checked vs. unchecked exceptions and how do design good error type hierarchies. Go's idiomatic error handling is mostly stupid because Go doesn't have sum types. But, I'd argue that if you are wanting stack information, it means that you shouldn't be returning error values at all- you should be panicking. Error values are for expected failures, a.k.a. domain errors. You can and should attach domain-relevant information to error values when possible, but generally, there shouldn't be a need for call-stack information. A bug should be a panic.

stickfigure 5y ago
Here's a Java example that sums the populations of a list of Countries: int population = countries.stream().mapToInt(Country::getPopulation).sum(); The Go implementation: var population = 0 for _, country := range countries { population += country.Population } It gets more perverse if you need to flatMap, or transmute components of map types, etc. If you want even more power, take a look at https://github.com/amaembo/streamex https://github.com/amaembo/streamex. This sort of container manipulation is bread and butter for business processing. I use it every day, sometimes with a dozen operations. This (with liberal use of `final` values) makes for some pretty functional-looking code. I'll grant you the Kotlin or Scala version is slightly more compact. But not fundamentally different, like the Go version. I (and the pretty much every language designer in the post-Java era) disagree with you about checked exceptions, but that's a whole different thread...
- ithrow 5y ago
  The go version looks perfectly fine to me (saying this as someone who uses clojure every day) ;) Something else to consider is performance, in most implementations the for loop is going to be more efficient.
  - ragnese 5y ago
    That's exactly my complaint- most languages have eager, mutable, non-persistent, collections because they were not designed with functional programming in mind. Then FP became the hot new shit, so they all added some of the lowest hanging fruit so that people can say absolutely weird things like "I do FP in C#". The problem is that the majority of these implementations just eagerly iterate the collection and make full copies every time. So, you're much better off with a for-loop. To be fair to GP, though, Java has legit engineering behind it, and the way they did it was to introduce the Stream API, which is lazy sequences, and they made the compiler smart enough to avoid actually allocating a new Stream object per method call (which is what the code nominally does, IIRC- each method wraps the original Stream in a new Stream object that holds on to the closure argument and applies on each iteration).
    - stickfigure 5y ago
      If you really want to go wild, take a look at https://www.vavr.io/ https://www.vavr.io/ (formerly jslang). You can make programming in Java as functional as you want.
      - ragnese 5y ago
        I have to admit, that looks pretty slick. Have you used it? I'd be curious to hear how well it works in practice. It seems like the only "big" things Scala has over this is its implicits (which so many people hate, but have been really improved in version 3) and its for-comprehension syntax. It's so interesting to see a bunch of projects converge on really similar things. You look at Scala, at this Vavr stuff, and at Kotlin + Arrow.kt, and they're implementing all of the same stuff over Java.

stickfigure 5y ago

Here's a Java example that sums the populations of a list of Countries: int population = countries.stream().mapToInt(Country::getPopulation).sum(); The Go implementation: var population = 0 for _, country := range countries { population += country.Population } It gets more perverse if you need to flatMap, or transmute components of map types, etc. If you want even more power, take a look at https://github.com/amaembo/streamex https://github.com/amaembo/streamex. This sort of container manipulation is bread and butter for business processing. I use it every day, sometimes with a dozen operations. This (with liberal use of `final` values) makes for some pretty functional-looking code. I'll grant you the Kotlin or Scala version is slightly more compact. But not fundamentally different, like the Go version. I (and the pretty much every language designer in the post-Java era) disagree with you about checked exceptions, but that's a whole different thread...

ithrow 5y ago
The go version looks perfectly fine to me (saying this as someone who uses clojure every day) ;) Something else to consider is performance, in most implementations the for loop is going to be more efficient.
- ragnese 5y ago
  That's exactly my complaint- most languages have eager, mutable, non-persistent, collections because they were not designed with functional programming in mind. Then FP became the hot new shit, so they all added some of the lowest hanging fruit so that people can say absolutely weird things like "I do FP in C#". The problem is that the majority of these implementations just eagerly iterate the collection and make full copies every time. So, you're much better off with a for-loop. To be fair to GP, though, Java has legit engineering behind it, and the way they did it was to introduce the Stream API, which is lazy sequences, and they made the compiler smart enough to avoid actually allocating a new Stream object per method call (which is what the code nominally does, IIRC- each method wraps the original Stream in a new Stream object that holds on to the closure argument and applies on each iteration).
  - stickfigure 5y ago
    If you really want to go wild, take a look at https://www.vavr.io/ https://www.vavr.io/ (formerly jslang). You can make programming in Java as functional as you want.
    - ragnese 5y ago
      I have to admit, that looks pretty slick. Have you used it? I'd be curious to hear how well it works in practice. It seems like the only "big" things Scala has over this is its implicits (which so many people hate, but have been really improved in version 3) and its for-comprehension syntax. It's so interesting to see a bunch of projects converge on really similar things. You look at Scala, at this Vavr stuff, and at Kotlin + Arrow.kt, and they're implementing all of the same stuff over Java.