Why Go Getting Generics Will Not Change Idiomatic Go - iRi

After years of overly-acrimonious online discussion, Go is continuing down the chute towards getting generics. I'm already seeing the inevitable "functional" libraries (plural) coming out. I'm going to explain why none of these libraries are going to materially impact what the community considers good style.

They may see some use. I may even use some of them myself on small scales. Some iconoclasts will program with them extensively, and their code will work, in the sense that it will do what it was designed to do regardless of how the code reads. But they are not going to change what generally-good style is considered to be.

For context, I like Haskell. I don't get to do a lot of work in it, but I know it reasonably well, I could take a job in it if one came up. I'm not saying what I'm about to say out of ignorance of how functional programming works or how to build non-trivial programs out of those tools. If anything, it is out of an abundance of respect.

For this post, "functional programming" is the modern strain exemplified by Haskell, with strong typing, pervasive immutability, languages that have enough differences that you end up with different optimal idioms than "imperative" languages. This is as opposed to an earlier definition around functions being first-class citizens and having closures available. (This is no longer a very useful definition, because this has simply won. The only remaining languages that are not "functional" by this standard are that way only because they are legacy, and most of them have added if it was even remotely possible, leaving behind only pure C. Also Go is already "functional" by this standard, as everything else is.)

Leave a Comment