> First, functional programming is particularly difficult in Go. In fact the language discourages functional programming.<p>Then it seems that Go isn't the language for you. With that Go nor any language, unless intended, is suppose to be a one-all solution for every problem. We can accomplish a majority, if not all, problems in a language, but this shouldn't assumed that a language is intended to do so.
OK, go will never have generics (except that it does in "make", "range", "chan", ok whatever...). That's fine with me. But including even just a few suggestions in the parent article would make Go a more approachable language to everybody.<p>* Pattern matching is intuitive and can be extremely powerful.
* It's pretty clear that Null should not exist anymore.
* Multiple return values, but no tuples?!<p>The go designers seem to not have a problem with special cases so why didn't they include special cases for an Option<T> and Result<T,E>, two things that, with pattern matching, would fit right into Go's explicit error checking philosophy.
These are the changes that if made Go wouldn't be language it is. Go is simple, straightforward if little verbose. To me Go fits perfectly for business apps that I write currently in Java.
Like C, Go is a small language. Given that the creators of go like its smallness and simplicity, all those features are never going to be added to Go.<p>When Bjarne Stroustrup wanted to add OO features to C, he created C++, initially as a translator that output C. If someone wants to add features to Go, they can create a "Go++" to Go translator, with pattern matching, generics, tagged unions. Clearly it's guaranteed to be very popular! /s
> First, functional programming is particularly difficult in Go. In fact the language discourages functional programming.<p>Well, if I were the king of the forest, I'd move functional programming from Rust to Go. With Rust, there's a lot of this higher level stuff in a supposably lower level language that would be more at home and useful over in the two letter language.
For Go people: How (learning) Go made you better programmer?<p>I haven't written any of these two languages but I have read Rust doc few times in depth and I constantly miss many of it's features in my daily .net work since then.<p>Example:
-Optional over null
-Union types
-Trait implementation is independent from source and target models
It seems to me golang and Rust are often being compared with each other. Given that Swift starts to be used on server side, I would love to see some comparison between golang and Swift, or Rust and Swift.
Just another generic complaint about Go's lack of bloat. It's all completely naive, never understanding why Go doesnt want generics beyond a simple "b-b-but look, the pattern matching of Rust is simple too!" No it isnt simple just because you say it is. It is the opposite of simple. I've read the Rust docs on it several times and I still dont have a clear mental picture of how to read a match statement out loud. "match result with Some(number) .. then do..? But match HOW?"
I've been thinking of a clearer syntax/naming for match and in my humble opinion it should literally just be called 'if' and any inconsistency that doesnt align with that be removed from the language.
Calling 'match' match is haskell programmers gone wild. Programmers in the real world dont have a clue how to read 'match'