5 ms·

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 comp

• nine_k 8mo ago
  Golang makes easy-to-skim code, with all the `if err != nil` after every function call. Rust requires actual reading, like Typescript, only more detailed.
• haileys 8mo ago
  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.
  • usrnm 8mo ago
    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
• 9rx 7mo ago
  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.
  • School-Cotton 7mo ago
    Can you enlighten us to what you’re talking about instead of vagueposting like this? What’s the supposed way of simulating sum types in go?
    • 9rx 7mo ago
      I am not sure how would you would simulate them. With enums and structs, I suppose? However, it also has true sum types: type SumType interface { isSumType() } type A string func (A) isSumType() type B int func (B) isSumType() But as you can see the syntax leaves a lot to be desired and may not be all that obvious to those who are hung up thinking in other languages.
      • School-Cotton 7mo ago
        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.
        • 9rx 7mo ago
          > 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.
        • kbolino 7mo ago
          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).
      • kbolino 7mo ago
        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.
• School-Cotton 7mo ago
  Go makes it easy to read each line of code, not necessarily to understand what the system as a whole is doing.