Should Go language die?

Should Go language die?

Should Go language die? No, of course it shouldn't. I don't think so, despite the catchy title. I love Go and... I hate it occasionally. The language has its moments but few things in the language design are a bit... contradictory, to put it politely. I respect Go authors and Go community I am a part of, and I love many things about Go, but here I would like to skim over few things I wish were different in Go.

Sometimes I don't understand how a modern language could be so outdated, as though deliberately ignoring many good things that have happened in software development over the last 30 years. And even more unfathomable is how some interesting features in the language could coexist with other awkward counterparts. From Go wikipedia page I know that Go design was a collective effort of 3 guys. I am thinking that maybe 1 of them was sabotaging the process undermining all good in the language with his old-fart ideas? That's a joke, of course. All 3 of them are great, I love them.

I understand the purpose of building a simple, easy-to-learn, easy-to-read language but being simple should not be a synonym for being dumb. When writing code in Go I sometimes find myself in situations when I feel, well... dumb, or rather that Go designers squeezed my balls forcing me to forget all good I have learned about software development up to now. I know that I should not compare Go with other languages. Go is Go, it's opinionated, it's unique, I should not complain and I should take it the way it is, like my grandma. And so I am focking trying.

Thanks god, generics were just added... By the way, I have no idea how Go developers lived without generics for 10 or so years and didn't blow their brains out. Luckily, I joined Go after generics were finally added, so I survived. I survived but sometimes I wish I hadn't, because the support for generics is so limited that I often want to cut my hand off, so I have an excuse for not writing another workaround in my code. One example, is that generic type parameters are not supported in methods. Here is a proposal on GitHub to finally add this support to Go. And you know what's funny? What's funny is comments in the proposal like "This will add so much complexity" etc. Come on... Having this feature is such a basic thing you would expect from generics, that not having it would initially cause a shock. How the hell was it implemented in other languages then? Right, I remember, I should not compare, Go is opinionated, unique, I should not complain...

Another shocking discovery waiting new-joiners with a garden pruner around the corner is a lack of support for function/method overloading feature (I doubt if I should even call a "feature" something you are just used to take for granted). There is a special section dedicated to that in the official FAQ defending this decision: "Experience with other languages told us that having a variety of methods with the same name but different signatures was occasionally useful but that it could also be confusing and fragile in practice". Well, "occasionally useful" are not the words you would nervously mutter when you have to name functions like SumInt2, SumInt3, SumFloat2, SumFloat3 etc. for summing a different number of arguments of different types, instead of having just 1 overloaded Sum. Probably it was the idea of that sabotaging guy...

Multiple return values... This one is just a weirdo. It's a unique feature, indeed. Most other languages don't have it, indeed. And that's for a reason - because it's silly. Why not to add a native support for Tuples (maybe just as a syntax sugar around structs), so that we can return 1 Tuple value e.g. with 2 constituents like (a, b)? Tuples can be constructed and deconstructed, essentially behaving like multiple return values. And on top of that, Go developers would get another useful construction to work with, helpful in many other cases. Win-win? No, the whole new syntax was hard-coded into the compiler for no reason, instead of spending this energy on fixing other basic issues in the design.

Ok, I finished smoking my virtual joint (kids, never smoke a real one unless... your mam asks you to write too much idiomatic Go code - then smoking is the only way you could survive). Probably it's time to wrap up... But I still have so much to say, I just scratched the surface... Should I make it a series? Just kidding, I love Go, love you guys. Thanks for reading! By the way, I develop a library for Go called Go4Fun, join me if you wish: github.com/ialekseev/go4fun