Go isn’t Java. It’s easy to bring our biases in from other languages, but when you use a language you should be buying into the philosophy, conventions, and style of the language as much as the rules of the language.
Go focuses on code, not data and concrete solutions, not generic ones. It’s a language designed for the 90%. If that doesnt fit your requirements, it’s ok to use C++, Haskell, or Java, or some other equally good language. But Go is really, really good when you give it a fair chance.
>Go isn’t Java. It’s easy to bring our biases in from other languages, but when you use a language you should be buying into the philosophy, conventions, and style of the language as much as the rules of the language
Only if those make sense. "The philosophy, conventions, and style of the language" could very well be BS.
Take Java for example: the mid-2000s J2EE code with the endless abstractions, XML everywhere, patterns galore, etc, was accepted and used as the default Java "idiomatic style", but it was understood later to be cargo cult BS.
Similarly, Java didn't have Generics either pre 1.5 iirc. One could say like you now, writing without generics is part of the "philosophy, conventions, and style of the language".
But it wasn't. It was just a missing feature. Now that Java added it, nobody feels it was better before, and nobody feels like they're sacrificing some part of the "style of the language" for using it.
Java has had that feature for.. 3 years? out of 20?
This is not about Java, this is about a multitude of languages having these features and Go not having this is a valid criticism.
I'm not saying you're wrong that there might be good reasons for it to be focused on different things, but I didn't read OP as "meh this is not Java" at all.
He’s talking about generics, you’re talking about streams.
Though ML was invented in 1973, so the idea of map/fold is pretty old.
The generalization into monoids/monads/functors didn’t happen until the early 90’s.
If we want to talk about the JVM, Scala was created 15 years ago and had those features.
I respect K&R, Rob Pike, C, and Unix a lot, but you have to understand that even when they were in their prime, they were considered a backwards. This can be traced toward the New Jersey style vs MIT style [http://dreamsongs.com/WorseIsBetter.html]
Not surprisingly, the New Jersey style originated at a company, Bell Labs, and while MIT style, not surprisingly, originated at... MIT.
But at this point, Go just feels antiquated, designed by a guy who strikes me as a “get off my lawn” kind of person.
Personally having had to transition from Scala to Go for one project at my old company, it felt like I was programming “blind, deaf, and dumb.”
Things I could do in 2 lines of Scala (though those lines were admittedly dense), would literally take hundreds of lines of Go. Sure, maybe it would have taken even more lines of C, but not much.
Go is probably just a tad more expressive than C with boehm GC. And frankly, that’s unexcusable for a language created in the 00’s, much less 2009.
I worked with Scala and just the compile time / deployment / SBT nightmare was really a bad experience, I'm glad I don't have that kind of problems with Go.
You're right - I forgot about this. I still don't think it's a valid point in this part of the discussion. Guava was/is widespread as far as I know but it's far from "everybody uses this" and while I've not worked in many Java projects, I've not seen much of this functional style. The people who wanted this badly switched to Scala. The features don't seem to be inherent, or at least not readily available to the language itself.
This is a cheap way out. I don't think most people are putting down Go as an outright terrible language.
So, when so many engineers with lots of experience say that, for instance, no-generics is a problem with Go, it's worth considering that may be it really is a problem.
I wonder what you will say if Golang introduces generics in a future release.
> I don't think most people are putting down Go as an outright terrible language.
Beware of evaporative cooling. All the people who can't put up with a lack of generics will wander off, and you'll only be left with people who are okay with the status quo. That doesn't mean you don't have a problem.
No, not quite. Rob Pike said in a video about a year or so ago that now they have enough experience to start thinking about generics. That the process is now just starting and you shouldn't expect them any time soon.
The Go core team has to decide if there's a way to add them to the language in a "Go way." If they can't they won't be added to Go at all, despite what other people want or don't want.
They started making early proposals, with syntax and the associated semantics. It will take a long time, but I'd be very surprised if they changed their mind now.
Map filter and reduce are generic tools that can be accomplished through constructs Go already has. The point of Go is that most applications do not need a high level of abstraction, they are bounded problems. Go is also reflecting the Unix philosophy, no surprise given its authors, of building small focused tools. Therefore framing problems in terms of generic data transformations facilitated by mapping and filtering is drawing attention away from the concrete solution and making the code less clear.
I would actually argue that map and filter are perfect examples of unix-style, focused tools. They are the programmatic equivalents to sed and grep. Of course more specific tools can be used, such as cut or tr, but in most cases sed is fine and you just go with that. I definitely understand people wanting the same ease of use, even as a Gopher myself.
Reduce is a bit different though because the closest equivalent on the cli is awk with a BEGIN and END block, so it's a bit more high-level. But there is still value in it.
The thing is most people who complain about the lack of those functions are not looking for fancy transformations: in most cases you want something as simple as "extract a field in each struct" or "keep if this field has this value". There even is sort.Search in the stdlib that has something in the same vein; surely something like
>Map filter and reduce are generic tools that can be accomplished through constructs Go already has.
They can also be accomplished through constructs Brainfuck already has. Actually any Turing complete language will do.
>Map filter and reduce are generic tools that can be accomplished through constructs Go already has. The point of Go is that most applications do not need a high level of abstraction, they are bounded problems.
map, filter and reduce are not "high levels of abstraction" any more than for or channels are.
>Therefore framing problems in terms of generic data transformations facilitated by mapping and filtering is drawing attention away from the concrete solution and making the code less clear.
The "concrete solution" being copy pasting code with a different type to filter a list for your types, and using a for loop instead of filter or map? Sounds more like Stockholm Syndrome.
I can’t really see how it can fit anyone requirements given that you said in another comment that it encourages copying code around. That is the only sure way to ensure that your code is full of bugs and multiplies the hurdle of the maintenance for each of the copied implementations.
And yet in practice Go is delightfully robust. It’s not THE most robust—it’s not Rust or Haskell[^1]—but (in my experience) it’s certainly less buggy than Java and friends, C/C++, or virtually any dynamic language. It’s quite possible that copying is a liability as you claim, and that OOP, generics, and/or dynamic typing are simply greater liabilities, but I think that means you should evaluate languages on balance and not on the presence or absence of one feature or idiom.
[^1]: Rust and Haskell pay for their marginal increase in robustness with a massive decrease in productivity.
Go focuses on code, not data and concrete solutions, not generic ones. It’s a language designed for the 90%. If that doesnt fit your requirements, it’s ok to use C++, Haskell, or Java, or some other equally good language. But Go is really, really good when you give it a fair chance.