WingNews logo WingNews
top | item 18126176

Go 1/2 Proposal: Immutable Types

19 points| romshark | 7 years ago

Hey guys, I just published the Go 1.x / Go 2.x proposal to "Immutable Types" that I've been working on for the past month and it's now official:

https://github.com/golang/go/issues/27975

Please be sure to check it out and feel free to join the conversation! Even if this feature is never introduced to the language specification - reading the design document will make you a better Go developer, that I guarantee!

original design document: https://github.com/romshark/Go-1-2-Proposal---Immutability

26 comments

order

x0re4x|7 years ago

Hi,

my humble opinion: how much would "Immutable Types" add to the language? How much complexity would it add? Things can already be made immutable from outside by hiding them in private variables/struct elements.

The question is: why did Go became successful without having "Immutable Types"? (or "Reference Types", ADTs too please?) Maybe those things are just frills, "nice to have" features.

Example like "type ImmutableMapAndKey const map[const * const Object] const * const Object" looks like really ugly Go to me... this is starting to look like C++...

https://www.youtube.com/watch?v=cQ7STILAS0M (why Golang is Sucessful by Creator of Golang Rob-pike)

P.S.: I wouldn't mind having "Immutable Types", "Reference Types", ADTs, etc. in Go. But not if it means abandoning simplicity of the language.

noncoml|7 years ago

I don’t know exactly why Go become successful but it is not because it’s a great language.

romshark|7 years ago

It'd rather reduce complexity. It'll make Go code less ambiguous leading to fewer bugs that you'll have to spend your time debugging. When working in big teams on big projects you better describe your intentions clearly.

Yes, you can hide state behind interfaces and opaque types, but you don't take into account, that the implementations of those types and interfaces need to be reliable as well. An interface with read-only types, for example, can declare its methods immutable enforcing an immutable receiver type on the implementing functions which makes sure that it's always correctly implemented and doesn't mutate its object for sure! A field can be declared immutable to make sure it remains immutable after the object is initialized, and so on. Immutable types allow you to better express your intentions when implementing something because in a month from now you'll be a different person too and you won't remember certain implementation details like "why you shouldn't mutate this inner slice in this struct" etc.

The whole concept is actually composed of 5 fundamental rules that are relatively easy to pick up. It also shouldn't be compared to C++ or even C style const qualification, because it's easier and safer.