romshark
commented
6 years ago I'd like to begin my answer with a quote of Russ Cox, one of the core Google Go team members, from his speech at the GopherConSG in May 2018:
https://youtu.be/F8nrpe0XWRg?t=3m12s
Software engineering is what happens to programming when you add time and other programmers. Programming means getting a program working. You have a problem to solve, you write some Go code, you run it, you get your answer, and your done. That's programming, and that's difficult enough by itself.
But what if that code needs to keep working day after day? What if 5 other programmer need to work on the code too? What if the code must adapt gracefully as requirements change? Well, then you start thinking about:
- version control systems, to track how the code changes over time and to coordinate with the other programmers.
- you add unit tests to make sure that the bugs you fix are not reintroduced over time, neither by you 6 months from now, nor by that new team member who's unfamiliar with the code.
- you think about modularity and design patterns to divide the program into parts that team members can work on mostly independently.
- you use tools to help you find bugs earlier.
- you look for ways to make programs as clear as possible, so that bugs are less likely.
- you make sure that small changes can be tested quickly even in large programs.
You're doing all of this, because your programming has turned into software engineering.
Nearly all of Go's distinctive design decisions were motivated by concerns about software engineering.
The concept of immutable types fits the goals of the Google Go team just perfectly:
- It's a tool that helps find bugs earlier (those type of bugs that are otherwise really hard to find)
- It's a way to make programs as clear as possible through clearly defined intentions, so that bugs are less likely
- It also makes sure that small changes can be tested quickly, because you don't need to write extensive automated tests, just to verify that you have no shared mutable state running amok. Your compilation will just fail and tell you what you're doing wrong (your code linter could tell this even earlier).
- It makes sure that something that was initially meant to be immutable - remains immutable over time (over thousands and thousands of commits and hundreds of pull requests) and doesn't get mutably aliased or directly mutated...
- neither by you 6 months from now
- nor by that new team member who's unfamiliar with the code
- nor by the open source contributor, who's totally unfamiliar with the code.
We just need to refine the proposal to take into account past mistakes made by other languages which are described in more detail below.
Simple Languages vs Software Engineering
Humans are prone to errors! Engineering always tries to remove the human factor from an equation. Making humans responsible for remembering what's safe to be mutated and what's not is inherently error-prone and not a proper engineering approach. Human-written documentation can't be relied on either.
Bugs caused by mutable shared state may be rare, but they're of the most nasty ones because you might not even know you have them! They can remain undiscovered for years corrupting your data. Race detector and static code analyzers won't help you. In fact, any algorithmic intelligence won't be able to deduce your intentions, while humans could misinterpret them because both machines and humans can't make any assumptions based on ambiguous code:
- did you mean to alias this pointer/slice and then mutate it on the other end of the program at an unspecified point in time?
- did you mean to copy all items of a slice except the last one or is it just because you're tired of writing copying code over and over again?
A good programming language should provide instruments to fight mutable shared state, especially one that focuses on concurrency. Go was designed for both, experienced software engineers and less experienced programmers, thus:
- It must give experienced engineers a way to define clear APIs enforced by the compiler without sacrificing performance and adding lots of boilerplate code.
- It must protect less experienced programmers from shooting themselves in the foot (aliasing and shared state is a very complex and very dangerous problem, especially for those unexperienced programmers).
Consistency is Key
I wrote this proposal because I was frustrated by how other proposals tried to introduce exceptional behavior only for certain situations like arguments or only certain types like slices and maps (completely leaving out pointer types).
If you think about arguments, variables, return values, fields, package-scope variables and receivers differently, then you'll end up with a very inconsistent and complex concept with more exceptions than rules. Inconsistency leads to much greater complexity and frustration, that's why immutability should be a property of types in general, no matter where those types are used, so whenever you see an immutable composite/scalar/interface type you know those rules universally apply:
- You can't assign to it.
- You can't call mutating methods on it.
- You can't assign to any of its fields (fields of immutable object are always contextually immutable).
- You can't cast it to its mutable counterpart.
Those rules consistently apply to any immutable arguments, variables, return values, fields, package-scope variables and function receivers. This gives the code authors a high level of accuracy when describing his/her intents to both other developers and him-/herself, which increases safety, readability and performance.
Performance Sacrifice
The most common way of safely passing a slice as a function argument I saw - involved copying, but copying is horribly inefficient. Consider the following benchmark: https://play.golang.org/p/X4ARzdqqDal
goos: darwin
goarch: amd64
pkg: test
BenchmarkRef-8 2000000000 0.90 ns/op
BenchmarkCopy-8 300000 4152 ns/op
PASS
ok test 3.187sCopying is almost x4.613 times slower than passing the slice by reference (it's passed by value, but this value is essentially just a pointer). Even with a small slice of 10 items it's still x100 times slower.
Sometimes you can fix this by wrapping the slice in a wrapper-struct that protects access to it: https://play.golang.org/p/ZRbGaGbP9us
goos: darwin
goarch: amd64
pkg: test
BenchmarkRef-8 2000000 851 ns/op
BenchmarkCopy-8 300000 5165 ns/op
BenchmarkWrapper-8 1000000 1097 ns/op
PASS
ok test 5.270sBut not only is this still always slower - it's not even always possible. Sometimes you have no control over the reader function and you can't just make it accept a custom wrapper type. In those cases you have no option but to either rely on the function to not accidentally mutate your slice (which is dangerous) or create a copy (which is verbose and slow). You also lose the ability to iterate on the slice using the range operator.
Making Immutability Great Again
I should really have called this proposal "Make Immutability Great Again", not because of the current political agenda though, but because of the many mistakes other languages have done before.
JavaScript
JavaScript for example has a const qualifier, which is totally useless in the most cases. It doesn't prevent objects from being aliased and then mutated later on from a different part of the program:
const a = {name: "John"}
a.name = "Joe"
let b = a
b.name = "Jessy"
console.log(a.name) // JessyBut most common bugs are caused by aliasing and shared state, not because somebody reassigned a variable. To solve this issue, one would make use of Object.freeze() which basically freezes an object making any further modifications to it impossible, but this approach has it's downsides too: It freezes the object only shallowly, meaning that any of the object references inside the frozen object are still mutable! This issue can also be solved by deep freezing, which has a significant effect on runtime performance and shall thus be used with utmost caution!
C/C++
C made const overcomplicated and unreadable.
Both C and C++:
- suffer from
const-poisoning - make casting of immutable- to mutable types possible which basically voids it's entire usefulness.
- make immutable type definitions very verbose and hard to both read and write.
Conclusion
The concept of immutable types offers a consistent set of rules with almost no exceptions and perfectly fits the design philosophy of the Go programming language and the motivations of the its core developer team at Google. It just needs to take into account the experiences of other, failed implementation attempts from other languages. If we manage to solve the problems mentioned above then immutable types could become an integral part of Go and make software engineering in Go both safer and more efficient.
P.S. Check out #20, it proposes a potential solution to the qualifier verbosity problem.
200sc
beoran
This proposal covers a lot of ground, and would add a lot of complexity to Go, and that is why it is likely to be not accepted unless you can make the engineering case that in large code bases the benefits outweigh the complexity.
Alsom, it coveres several types or use cases of "immutability" whcih are actually different. It might be a good idea to split this proposal up between those different use cases.
The first use case I see is preventing accidental mutation of function argument values for types passed by pointer, indirectly for arrays, slices, maps and structs that contain pointers, though function argument variables. as I said before, I think the engineering case for this is relatively weak, since in my experience accidental mutation is rare.
The second use case I see, though is solving the string and []byte duplicity we now have in Go, because the former has immutable values while the latter hasn't. A proposal that could simplify the language, so we could do something like
type string = immutable_value []byte, and then make it so that we can do away with the duplication of the strings and bytes package, on the other hand would be awesome. For that, though this proposal would have to solve the problem of result type co-variance somehow. You would need to be able to say something likefunc Split(s, sep immutable_value_or_mutable_value []byte) mutable_only_if_argument_where_mutable(s, sep)[]byte... I think that is a very hard nut to crack though.Ediit:
A third use case would be immutable variables, that is, variables that can be assigned to only once. I don't thing that that is a very useful use case inside functions, but it might be useful to avoid re-assignments to package scope public variables.