4 ms·

> type safety and correctness simply aren’t nearly as important as velocity from an economic perspective In my experience type safety is one of the most factor

by skohan 6y ago

> type safety and correctness simply aren’t nearly as important as velocity from an economic perspective In my experience type safety is one of the most factors in terms of being able to produce code quickly, at least once a project grows beyond a couple hundred lines. I agree with your overall point, and I think the advantages of Go are especially relevant in a team setting: Go's categorical aversion to complexity makes it much more difficult to write code that someone else will not understand, where Rust projects can become relatively impenetrable when they wade too far into getting "clever" with the more esoteric aspects of the type system. Also the learning curve is real: you can take a Javascript developer and get them writing Go code in a couple of weeks. If you hire someone who's not experienced with Rust for a Rust project, you may be paying them for months just to get up to speed. Don't get me wrong, I'm a huge fan of Rust and use it for almost all of my personal projects currently. But I think the idea that Rust can become the main programming language in all settings comes from a place of heavy bias. Rust is definitely on one extreme when it comes to complexity, and it's a more relevant trade-off for some use-cases than others. aside - I know it's a minority opinion, but I actually think that Swift is a sweet-spot language in terms being simple to program in like Python (by aggressively obviating away low-level details), but giving you many of the powerful tools for correctness which Rust has, like algebraic types. It's a shame that it's painful to use in all but a few "blessed" applications.

throwaway894345 6y ago
> In my experience type safety is one of the most factors in terms of being able to produce code quickly, at least once a project grows beyond a couple hundred lines. I think it depends on your domain. If you are working in a mission-critical space where every bit of static analysis saves hours or days of testing, then yeah, the more static analysis the better. If you’re building web systems software (things like Kubernetes) or even ordinary application software, then you get benefit from a little static analysis, but returns quickly diminish beyond a certain point. I think Go hits the sweet spot and Rust is generally excessive (development is slowed down much more than necessary). Swift might also hit that same sweet spot; I haven’t used it much. I have heard that it has some maturing to do before it’s ready for more than Apple GUI apps, but that might be dated information.
- skohan 6y ago
  Yeah I agree - Rust does have more static checking than is strictly needed for many domains. 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. 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. > Swift ... has some maturing to do before it’s ready for more than Apple GUI apps I actually think Swift as a language is plenty ready for general purpose programming. The problem is the tooling. It's supposedly being worked on, but last time I checked it's possible but not at all simple to get it running on anything other than Apple platforms and a few blessed linux distros. Also I had the experience that every time I would uprgade the toolchain, it would pretty much break all my larger projects. Even though I like Swift as a language more than Rust in some ways, I've pretty much abandoned it on new projects, because with Rust I can just run `cargo run` on any system and be pretty confident it's going to work, and Swift is very far from this. Also you always feel like the language is a bit at Apple's whim. Like when SwiftUI was released, they shoe-horned a number of features into the language which seemed pretty half-baked because of iOS's priorities. It makes one hesitant to invest too much in a language which is so heavily influenced by a single stakeholder who may have different interests than you.
  - throwaway894345 6y ago
    > 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.

by skohan 6y ago

throwaway894345 6y ago

> In my experience type safety is one of the most factors in terms of being able to produce code quickly, at least once a project grows beyond a couple hundred lines. I think it depends on your domain. If you are working in a mission-critical space where every bit of static analysis saves hours or days of testing, then yeah, the more static analysis the better. If you’re building web systems software (things like Kubernetes) or even ordinary application software, then you get benefit from a little static analysis, but returns quickly diminish beyond a certain point. I think Go hits the sweet spot and Rust is generally excessive (development is slowed down much more than necessary). Swift might also hit that same sweet spot; I haven’t used it much. I have heard that it has some maturing to do before it’s ready for more than Apple GUI apps, but that might be dated information.

skohan 6y ago
Yeah I agree - Rust does have more static checking than is strictly needed for many domains. 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. 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. > Swift ... has some maturing to do before it’s ready for more than Apple GUI apps I actually think Swift as a language is plenty ready for general purpose programming. The problem is the tooling. It's supposedly being worked on, but last time I checked it's possible but not at all simple to get it running on anything other than Apple platforms and a few blessed linux distros. Also I had the experience that every time I would uprgade the toolchain, it would pretty much break all my larger projects. Even though I like Swift as a language more than Rust in some ways, I've pretty much abandoned it on new projects, because with Rust I can just run `cargo run` on any system and be pretty confident it's going to work, and Swift is very far from this. Also you always feel like the language is a bit at Apple's whim. Like when SwiftUI was released, they shoe-horned a number of features into the language which seemed pretty half-baked because of iOS's priorities. It makes one hesitant to invest too much in a language which is so heavily influenced by a single stakeholder who may have different interests than you.
- throwaway894345 6y ago
  > 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.