But at the cost of performance; Go is not (yet?) optimized for functional programming constructs, and its function syntax adds a LOT of mental overhead to reading the code; http://www.jerf.org/iri/post/2955 was a good post on that. Remember the Go proverb: clear is better than clever. In this case, not only for readability but also performance.
I have no objections to your point #2 though, I always found Go's constructs like `len(slice)` or `slice = append(slice, value)` a bit awkward. With generics support, `slice.len()` and `slice.append(value)` should now be possible. Actually I'm not sure why the latter was not possible all along, I'm sure there's a reason somewhere. I know you can implement the latter yourself as well, even before generics.
As for #3, I got nothing; I sorta followed along with a Big Discussion about different error handling in Go a few years ago, but it basically ended with "Well... actually how it is now is absolutely fine"; all the offered alternatives added complexity, magic behaviour, or reduced readability to the language. As it is, error handling is obvious. I wouldn't mind some syntactic sugar though; a one-line error handler at the moment is `if err := doSomething(); err != nil {` which is a bit awkward. The other Issue I have is with variable reuse and shadowing, it's a risk that may cause unhandled errors.
For example the line
return Filter(string)(func(s string) bool { return len(s) <= 2 },...
Is there any alternative technique for functional style in Go?
Same. It felt freeing to just say "fuck it, I'll use a struct" and have the built-ins required to automagically marshall json on the wire to structs in memory. That was pretty cool. You're spawning threads^H^H^H^H^H^H^Hgoroutines and passing messages and not giving a fuck because the language protects you.
Then I wanted to make v2 of my package.
Go's packaging (and module) system is just so indescribably, generally, and thoroughly bad that it put me off the language and I won't be back. I spent more time fucking around with dependencies and wondering why `go get` was giving me cryptic and unhelpful errors that were unaddressed by the docs than I did writing my code.
Deleting go was the best move I've made.
I'd love to see less verbose error handling too, but Rust's ? IMHO is not the best way to go - it adds quite a bit of magic and makes debugging difficult, when a question mark at the end of a line "injects" an unexpected return statement.
I'd guess with generics we can expect a generic "Must" to replace them.
``` const map[uint8]string { 0: "thing1", 1: "thing2", } ``` That way tables of data can be made immutable at compile.
Folks are left to invent stupid hacks, that don't really work. For example, a function that defines a template and returns:
``` func my_data() map[uint8]string { return map[uint8]string { 0: "thing1", 1: "thing2", } } ```
And then we have folks running silly function calls for the sake of avoiding mutability.
Don't get me wrong, I understand why this hasn't been done. We've all read the arguments against adding things to the language, but I accept in part, and reject in part that argument. Complexity always increases, so it's understandable to put the brake on run-away complexity. But GO is slightly pathological when it comes to the avoidance of adding sensible language features. The thing is most folks would rather have a slightly more complex compiler than a limiting programing language.
Why though? it doesn't even save you much space compared to standard use:
if _, ok := m[key]; ok { }
vs
if contains(m, key) { }
I'm not strictly against it, but it can open pandora's box of all kinds of weird sugar flavors.
Of course this is all guesswork based on similar stuff i've seen elsewhere, so i might be off, but i think despite not knowing the language it still looks readable if you know any other mainstream language (and exercise some guesswork/imagination :-P).
I can say the same about Fennel, List or Haskell.
The first example is the way to go in Go. It's idiomatic, not a hack. And it works the same way for many things (for example checking if a channel's closed)
you could write this in Go
if m[key] { }
Hopefully that helps explain the matter...
GP wasn't discussing the language in general, just a small feature that depends on an idiomatic pattern used in many other places, saying "it looks gibberish." Of course it does, because it isn't idiomatic for you.
It's less about length of code and more about cognitive load; this is why functional programming constructs are frowned upon in Go code, because the cognitive load per line of code is much higher.
Also `if m.contains(key) { }` is even more obvious IMO.
Where they actually trying to copy other's well-known-to-be mistakes?
That said, there are other languages with proper sum-types and pattern matching, if that's what you need; I think it's a bad thing that some people advocate for every language to have every feature from every other language. Take Javascript; someone Decided that it should have classes, but the implementation has never been good (e.g. field access levels) and it's always felt bolted on. Take Scala, which borrowed every feature from every other language ever, and now you can't have two people work on one Scala codebase without them having endless discussions about which flavor or pattern to use.
Not what I'm saying. I'm saying when smart people created Go, the forgot that null is a mistake, and sum-types are simply too useful in modelling the world to miss out on (pattern matching makes them a joy to use).
This was both well understood in the 20XXies; and I have never seen any reason from the creators of Go as to why...
> Scala
Scala is a multi-paradigm lang; that sucks on whole different levels. I'm not advocating at all that Go should be multi-paradigm.
1. Functional operators like map/filter/reduce - all of these would be optional but would save SO many lines of code.
2. Add simple conveniences - e.g. "contains" to check if a key is present in a map. Again those who don't want to use these, don't have to.
3. Error handling boilerplate - something to the tune of "?" operator in Rust