Safe by default, dangerous by responsible choice.
C#, for example, doesn't let you modify objects passed in as parameters, unless you highlight that behavior on the method signature and the call itself with the appropriate keywords. There are many other examples in many other languages. "Do what you want, use convention to keep safe" is a recipe for trouble that has caused innumerable very serious defects in software (buffer overflows, security vulnerabilities, etc.) "Do what you want, and you have all these tools to keep track of it" is a much better choice, even if in the end the code does the same exact thing. Banking on humans not making mistakes is not robust.
This should be expressed as a bumper sticker. How about: Human Error: Bet on it!
If you're debugging a sharing problem, and relying on convention, you don't even know where to start looking for it in a large codebase.
which means you should have the choice to do efficient things, if you know what you're doing.
That directly clashes with other design choices in Go. For example, taking the address of a variable on the stack implicitly puts it on the heap (at performance cost) to protect you from accidentally using the pointer after that function returns.
If you're worried about it and you really care: don't pass a pointer, pass a value.
...and pay the performance penalty of doing not just a copy, but a deep copy, simply because the language doesn't have const.
I don't have the time to watch the video right now, so maybe I'm reading this out of context, but how does compiler-enforced immutability change this? I'm not asking for everything to be immutable (not even in Haskell is that true) -- I'm just asking for the ability to mark an object as immutable and have the compiler make sure that it isn't modified. I'd prefer that non-local objects be immutable by default, but I'm willing to live with mutable by default.
Really, immutable state gives you the efficiency of pointers coupled with the nice semantics of copy-by-value. It's the best of both worlds -- not having it is denying the programmer "the choice to do efficient things".
http://confreaks.net/videos/115-elcamp2010-go
Check out the video, but here's a rough transcription of part of it:
"This is a systems language, which means you should have the choice to do efficient things, if you know what you're doing. You shouldn't be told "you can't do that because you might get it wrong." Let me explain. The model for sharing and locking all that stuff is like having a big piece of paper and we all gather the paper and we make notes on it about who owns what, when -- and we scribble and erase and rewrite and work on it. This model is: you don't have one piece of paper, you have lots of pieces of paper. And you write a message on a piece of paper, and you give him that piece, and he goes away, and you don't have it anymore. He'll bring it back to you if it's relevant to you; he won't if it's not. And because the individual pieces are broken up, there's no concern or worry about who owns what at any one time -- it's whoever's got ahold of it at the moment. And once you understand that, it just doesn't come up as an issue, that for efficiency reasons, I want to pass a pointer on a channel, because once I've passed it I forget it. The only person who has it is the person whose business it is to deal with it now. If you're worried about it and you really care: don't pass a pointer, pass a value. Make it a channel of struct, rather than a channel of pointer to struct. It will be a copy, and there's no way you can share it. But that's your decision, not the language's."