This page is in group Technology.
Intro
This note got triggered by a discussion at golang-nuts [2] called «Should we be responding to Go: a nice language with an annoying personality» because a user there wasn’t sure how the golang-nuts community should respond to a rant by Cortesi [1]. This also has caused a thread in Hacker News [3].
The initial rant by Cortesi gives some examples of how the Go compiler seems to get in his way while he’s in the processes of writing and debugging a Go program. Go issues error when an import is not used and when variables are declared and not used. So, when he needs lines for debug and testing, he has to both remove and change to get rid of it and both add and change again to take it back. It’s a quite nice rant. Cortesi ends with three points, the third being that:
«Why don’t we have a word for this? By «unit of hacking», I mean the work that goes on between starting to hack on a change-set and doing a commit. At the beginning and at the end, the code is in a clean state, but in between there are many periods of transition where cleanliness requirements are relaxed.» [1]
Yes, we need a word for that! But do we need a language for it?
Trust
Of course, Go doesn’t have conditional compilation with #ifdef or #if.. – which I use too much when I program in C.
The golang-nuts thread presents me with some sensitive programmers feeling that the Go compiler (i.e. the Go language or language designers) doesn’t trust them. Like, if they make a good meal in a kitchen and find this kitchen tool in that (always!) too remote drawer was the kitchen designer’s fault. Until a new boss arrives to the kitchen and this tool is finally moved to a more practical position. Of course, some kitchen designs are bad, but some tool is also in the wrong drawer.
However, the Go designers made a comment here that
«What I took from the blog post is that we have not done a good job of explaining how to silence the errors using the blank identifier. The next version of Effective Go will contain a section something like the text below.»
So he goes on to say how the documentation in http://golang.org/doc/
A comment
Any language designer will try to make the language as suitable as possible. It should be easy to write (incrementally?), read and explain. It should map between cognitive and runnable matters.
But more importantly, the final result should be safe to use. If it runs in a breaking system, a fire detection system or is a text editor, the user must trust it. In the ISO 61508 world of safety critical systems they talk about risk, which is the product of probability and consequence. And back to the text edtor, you take a risk that a letter is not lost, and hope that a lost letter would have a small consequence. Not to talk about a programmer’s editor!
Even if 61508 talks a lot about the programming languages and what they should have and not have, it’s seen as what is safe for the user. How much the programmer feels he’s trusted or not is not the question.
A statement like «The airplane crashed because the programming language trusted the programmers» would be a huge misunderstandning. If we, the programmers, have such a view of ourselves and what we’re here for, I would not send my daughter with that airplane.
There may be matters with any language that would not suit this thinking (also for Go – even Ada needed the Ravenscar profile (see my blog note 035)), but I refuse the idea that on these matters it’s an a offense not being trusted.
Disallowing pointer operations probably means that the language designers didn’t trust that I always would do it correctly. Having channels between processes could mean that they didn’t trust that I handled semaphores that correctly. Verifying part of a program or protocol could mean that I didn’t trust myself to have coded (or designed) it correctly.
The best thing is if we designers could say «Trust me, it’s safe» to our customers. It may be easier to say this if we some times may have felt not trusted by our language designers.
References
- By Corte.si (Aldo Cortesi): «Go: a nice language with an annoying personality», a Go rant at http://corte.si/posts/code/go/go-rant.html
- «Should we be responding to «Go: a nice language with an annoying personality»» https://groups.google.com/d/topic/golang-nuts/xbFLvvvvyUo/discussion
- At Hacker News: http://news.ycombinator.com/item?id=5076461