Can you explain all the annoying stuff in go to me?

Can you explain all the annoying stuff in go to me?

I kinda like many ideas of go and the feel of go and understand the reasoning behind many decisions but there are a bunch of things I just can't deal with because the seemingly stupid reasoning enrages me.

  • Why do closed channel writes panic? The explanation goes like "there's a bug in your code if something writes to a closed channel". But aren't channels supposed to be synchronization helpers? It seems like saying this car has no reverse gear because it is supposed to drive forward. If you need to drive backwards that's an error, just get you another car that pulls the fist one backwards. How is that good reasoning and why is everyone just fine with this? It results in unnecessary complex code where you have to keep track of additional synchronization primitives for no apparent reason.

  • Why are unused variables and imports errors by default? I understand that go is supposed to be used in big companies and clean code bases are very important but most code in development is getting changed and recompiled over and over again by every normal developer. Why is there not just a "strict" or "production" flag that enforces this and maybe even other things useful for big projects instead of slowing every development down by forcing you to always cleanup everything immediately e.g. after a rework of a section even if you don't even know if this will run as it is supposed to. In the end you might have to revert your changes and just wasted a few minutes with cleanup just to please your compiler for no reason every time. I don't care if my binary is a meg bigger with an unused import or if there are a few bytes of memory wasted at runtime while I work on the code! I know there are tools to deal with unused imports etc. but why do they even have to exist?

  • Why are there so many bad std lib apis with stupid stuff and just forced redundancy everywhere e.g. the aes cbc cipher the block length check. Of course you can only crypt data blocks equal to a multiple of the blocksize but why is that a panic?


if len(src)%x.blockSize != 0 { panic("crypto/cipher: input not full blocks") } 

everything that this accomplishes is that I have to do:

if len(buf)%aes.BlockSize != 0 { // handle error } mode.CryptBlocks(buf, buf) 

this is just bad design in my opinion.

Encryption is directly coupled with networking in most cases and you typically have no control over what your client sends you. The lib just enforced a redundant code section in almost every aes cbc implementation ever. There are many more examples of this just bad api design e.g. the gzip reader that prevents the use of Multistream false completely in certain cases and the only ways around are to either copy-paste the parts of the library you need because the necessary properties and functions you need to access aren't exposed or write a really stupid and even more redundant wrapper.

It feels like the language tries to babysit its own developers and does a really bad job with that. A programming language is arguably the most powerful tool on earth right now and programmers need to shoulder the implications. There is no amount of babysitting that can prevent dumb stuff from happening or being written anyway.

Many people start arguing "just use c or asm then" in response. Why is it forbidden to have the wish for performance and convenience in the same toolkit especially if it is not a technical limitation but just ideological?

I still like to think that I'm just not getting something fundamental about these things and hope someone can explain these things to me in a way that I can recognize that there is more than just stupid or selfish reasoning and a bunch of lemmings following.

Submitted July 18, 2017 at 12:03PM by geeek2go
via reddit


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s