4 ms·
These digs at Go are so vacuous. You don’t just drop a union type into a language with some syntax and semantics. There’s an impact on how the runtime works. E
by klodolph 2y ago
These digs at Go are so vacuous.
You don’t just drop a union type into a language with some syntax and semantics. There’s an impact on how the runtime works. Every language’s design is somewhat impacted by runtime considerations. For Go, the runtime consideration is the concurrent garbage collector, and the data race that you would have between the garbage collector and the union tag. You have to solve that problem in order to have unions in Go in a way that would make sense in Go.
Go unions would not look like unions in ML.
You could trivially implement unions in Go by having union values be pointers to structures, and it could be a different structure for each variant. This is basically just sugar around "any" and typecasting. The problem? You’re now allocating for every assignment.
- noelwelsh 2y agoI agree that one cannot simply hand wave a language feature into existence. What I don't understand is why you consider a requirement to change the runtime to disqualify a new feature. In this case, if I understand your complaint correctly, what you are saying is there is a race condition between setting the tag of a variant / union / sum type and the GC reading that tag to interpret the memory layout. I agree this is an issue, but it's an issue with any memory write. This is why garbage collectors have a write barrier, and the Go GC is no different (e.g. [1]). So ultimately I don't see the problem as unsurmountable. Yes, it will require some thought and some runtime changes, but the foundation (i.e. type tags, the write barrier) is already in place. [1]: https://ihagopian.com/posts/write-barriers-in-the-go-garbage-collector https://ihagopian.com/posts/write-barriers-in-the-go-garbage...