I really think that golang makes it easy to read code, rust makes it easy to write code. If Golang had sum types it would be a much nicer language to write complex applications with
I find Go code mind numbing to read. There's just _so much of it_ that the parts of the code that should jump out at me for requiring greater attention get lost in the noise. Interfaces also make reading Go more difficult than it could be without LSP - there's no `impl Xyz for` to grep for.
It's the complete opposite for me. Rust code, especially async Rust code is just full of noise the only purpose of which is to make the borrow checker shut up
Go does have sum types — but the syntax is awkward and a bit transparent, so many don't recognize it as being there, and those that do don't love using it.
This forms a closed set of types (A, B, nil -- don't forget nil!) but the compiler doesn't understand it as such and complains that the following type-switch is not exhaustive ("missing return"):
func Foo(s SumType) bool {
switch s.(type) {
case A: return true
case B: return true
case nil: return true
}
}
Also, you, the package author, may know what constitutes SumType, but the consumers of your package don't, at least not without source. Moreover, you can spread A, B, and any other implementations of SumType across many source files, making it hard to answer the question even with source. This is even a problem for the standard library, just consider go/ast and its Decl, Expr, and Stmt interfaces, none of which document what types actually implement them.
Right — While it does has sum types, it doesn't have some other features found in other languages.
But, of course, if one wanted those features they would talk about those features. In this discussion, we're talking specifically about sum types, which Go most definitely does have.
> nil -- don't forget nil!
This is why alternative syntax has never been added. Nobody can figure out how to eliminate nil or make it clear that nil is always part of the set in a way that improves upon the current sum types.
interfaces in go aren’t types, so no, that’s not a sum type, it’s just an interface.
The set of objects that can fulfill that interface is not just string and int, it’s anything in the world that someone might decide to write an isSumType function for.
Interfaces in Go are structurally typed but they're still types. A variable of an interface type has two components: a pointer to its dynamic type information, including virtual method table, and a pointer to its value. When you consider that any compiled Go program has a finite set of known types concretely implementing each of its interfaces, they essentially become discriminated unions, albeit without Rust's compact inline representation (unless the dynamic type is itself a thin pointer).
> it’s anything in the world that someone might decide to write an isSumType function for.
No. Notice the lowercase tag name. It is impossible for anyone else to add an arbitrary type to the closed set.
Unless your argument is that sum types fundamentally cannot exist? Obviously given a more traditional syntax like,
type SumType tagged {
A | B
}
...one can come along and add C just the same. I guess that is true in some natural properties of the universe way. It is a poor take in context, however.
No software? DaVinci Resolve? Affinity Designer? Final Cut, Procreate, AUM, Logic Pro etc etc etc. As the processors get more powerful more demanding software can be made for it. Running multiple physical modeling AUVs along with FX loops eat up clock cycles. Final Cut Camera on iPhones along with Final Cut on an iPad allow for full multi camera controls and recording from 4 different iPhones with ProRes and log shooting at the same time.
If Apple hadn't continually upgraded the processing power then none of those programs would work. It's up to Apple to make compelling hardware. Better hardware allows more advanced programs. iPads are amazing.
The Procreate UI literally tells us otherwise. When you create a new image, it tells you exactly how many layers it will allow you to have based on the dimensions you set. This number is smaller for older iPads.
Thats the one I would buy if I were thinking of upgrading right now. We expect new models every year at this point, thats been the strategy of Apple for many years at this point
reply