> But I think the reason for that is strictly orthogonal to type safety - rather it's because Rust's approach to memory management is a lot more demanding on the programmer than GC.
Rust lacks a GC so it uses its type system (namely its borrow checker) to compensate. I don’t know that this can be considered “orthogonal to type safety” in a meaningful way.
> Speaking only in terms of type systems, I think Rust's features - like algebraic types and explicit nullability - are strictly better than Go and make it easier to write correct code. It just happens to be that this benefit is eclipsed by all the ceremony required to satisfy the borrow checker.
Yeah, I completely agree. Go with ADTs would be a significant improvement. I would really like to see someone write a language like this that is interoperable with Go (compiles to idiomatic Go to the extent possible).
> I actually think Swift as a language is plenty ready for general purpose programming. The problem is the tooling.
Hmm, well I hope it finds its feet. It certainly seems like it would be a welcome addition.
> Rust lacks a GC so it uses its type system (namely its borrow checker) to compensate.
Ok fair enough. I guess mentally I separate the ownership/lifetime system from the type system, but I suppose it's true that borrows, mutable borrows etc. are actually part of the type system.
Rust lacks a GC so it uses its type system (namely its borrow checker) to compensate. I don’t know that this can be considered “orthogonal to type safety” in a meaningful way.
> Speaking only in terms of type systems, I think Rust's features - like algebraic types and explicit nullability - are strictly better than Go and make it easier to write correct code. It just happens to be that this benefit is eclipsed by all the ceremony required to satisfy the borrow checker.
Yeah, I completely agree. Go with ADTs would be a significant improvement. I would really like to see someone write a language like this that is interoperable with Go (compiles to idiomatic Go to the extent possible).
> I actually think Swift as a language is plenty ready for general purpose programming. The problem is the tooling.
Hmm, well I hope it finds its feet. It certainly seems like it would be a welcome addition.