Yes, and when used in an immutable way, the GoLang approach is very powerful and efficient, because it allows one to pass large (parts of) immutable data-structures without copying.
Since it's not like I'm trying to sell this as a solution to all immutable data requirements, I didn't worry too much about that detail. In the end it's all about effort, anyhow; with the right invocations in Haskell I can mutate "immutable" data just fine. So even an interface in the package that declared it is still nontrivial protection against accidentally mutating it.
Isn't it a lot simpler to just say that Go has no feature support for immutable data? The fact that you can hide accessors in a package is small comfort if I have to read all the source code in that package to know the actual semantics.