What I think is wrong with the direction of Go language development чавка Follow Jun 2, 2019 · 5 min read

In my own personal experience working with Go, my issues are not the same as the ones that, in my opinion, while these people might be accomplished in other programming languages, they are not qualified to really comment about the flaws in Go, until they understand it.

It’s really important to drive that point home. If I can find your idea via google as a Golang improvement proposal, it does not qualify. Golang is not a democracy, at least I was hoping it would not be, and it’s starting to become a bit too democratic for my taste.

There is no way I am adopting Go 2.0, and I don’t think I will be alone either.

The biggest issues I see with Go are really low level and not obvious to anyone who hasn’t dealt with a lot of code and tinkered with different patterns, beyond the established ‘idiom’, which is far from settled anyway.

1. Scoping

package scope

The biggest source of errors that I encounter when writing Go code have to do with scoping. I think in part linters and other tools are helping, as it is becoming more recognised in the community that …

PACKAGE SCOPE IS BAD, M’KAY

This is a really big problem, specifically. Every time you write code that uses anything in package scope that is not a constant, or a variable you don’t mutate, or a function, God drowns a little kitten in a well. Seriously.

Don’t use package scope mutable variables, ever. When you do, you make a lot of work for yourself later when you need to use the same, probably huge bit of work you spent hours writing, somewhere else and then you have to build a new, state variable, gather all the things that are hiding not just in package scope but inside functions that relate to the overall state, and it’s just a pain in the ass.

block scope

Second issue with scoping in Go has to do with the possibility to initialise new variables within if, switch, select, and other statements.

I’m not saying this is a bad thing. I am a huge fan of :=

Not just because it looks like a skull, but I don’t see why I should make more lines of code for nothing, for a variable used twice all inside a switch or if/else block.

In fact, to be honest, I’m more contra the ‘var’ statement than the shortened declaration assignment. It was never a feature of the pascal-family languages that I ever liked, and oh yeh, back to the previous point about scoping, if it weren’t for package scoped mutable variables, nobody would hardly even use ‘var’ at all.

2. Interfaces

I love interfaces. I always remember years ago seeing the ad-hoc use of type identifies embedded in struct definitions in C, and actually, I never really spent that much time in anything other than ducktyping languages anyway.

Vala, Python, C, Basic, none of these languages really give you much scope to make dynamic variables, but these are at the centre of how you implement containers in Go. The problem all these ‘gib generix kthxbye’ newbies coming to Go, pestering and corrupting the Republic of Golang’s legal system, is they don’t understand one simple principle:

if you don’t know what it is at compile time, what makes you think at runtime anything will be different????

There isn’t a magic pixie who will run around your code while it is running and magically write a handler for a type you didn’t plan to have thrown at a function.

Amazing, but true!

So, this is not the interface you are looking for, move along.

I mean the interface method set.

First of all, the word ‘set’ should give away a serious issue. Go does not give you easy ways to deal with sets. There is very little required to turn maps into sets. But this is not how interface method sets are implemented. All the magic is hidden from you, and you will learn, as you see more and more Go code, that almost every decent piece of software that uses an interface, has to assert the interface is valid. So what is all that implicit voodoo going on in the background even for?

If it were up to me, I would throw interface method sets off the bus, yesterday.

It is more robust, simple, and obvious, to just define a set of methods inside a struct. Then you can embed it. Instead of getting cryptic ‘does not implement blah’ errors, which are really hard to track down, you get a nil panic because you didn’t fill in a method in the struct with an actual function.

Simple and obvious, does the same thing, and removing it would cut at least 5% of the complexity of the language.

There’s not really any big clangers I would say that I would point out, except to discuss the topic of Closures.

Fortunately, Go basically doesn’t too much get in your way with closures, and fortunately, its clever function signature syntax makes chaining them into generators a lot simpler than it would otherwise be.

However, in my opinion, this is the one thing that the language needs, and needs a simple macro-aliasing system for. Sometimes the generator type signature functions take up a full two lines, and in this, they are not excessive, one function has two or three parameters, the second function it returns has one or two, and then maybe it returns a tuple type, unless you are like me, I hates these things, give me a predeclared proper single struct type or map or slice.

I never write ‘idiomatic’ returntype, error returning functions. Ever.

What I do instead, is mostly, you only need yay! or boo!

If the variable is a pointer, then Boo can be indicated by nil.

If the error state is caused by me, the programmer, and not by the user, then I should suffer a panic(). Because it’s my fault, and because such an error should not exist in production code, full stop.

If for whatever reason, I really have a complicated error variable, then I would want to predefine them. There is numerous libraries that use this strategy, as well as cascading the returns so that when the logger prints it out, it has several layers of error data that lets me as the programmer nail down exactly how I let the user break my code.

Conclusion

Well, not really the conclusion, but these are just the salient things I see that nobody who has really taken Go as a serious programming language seriously, have any real understanding of, and gib generix people should just be laughed out of the peanut gallery. It should not be a topic anyone needs to discuss. The Go 2.0 upgrade process discussion is, in my opinion, going to make Go so indistinguishable from Java that its not going to be the raging popular and growing more popular language that it is anymore.

What’s gonna be the advantage if we lose all that interactivity from Go’s simple, fast compilation engine, by raising its complexity back to the level that Go was designed to eliminate in the first place???