4 ms·

> I don't see how Rust can approach a GC language with respect for productivity for anyone My domain is games, and while this usually prioritizes performance t

> I don't see how Rust can approach a GC language with respect for productivity for anyone My domain is games, and while this usually prioritizes performance that's not really what I care about (so I could be using Python for instance and it would be 'ok'). My take is this: When it comes to productivity even if writing the same code is easier in Python than Rust, working over time in a Python project (or any dynamic language really) is just a nightmare for me. No matter how many tests I write or how I structure my code when I have to add a new feature that touches large parts of the existing system I just have 0 confidence it is correct. I have to run my code through all the branches to make sure I didn't forget to, idk, add the new parameter to all function calls or something. Rust on the hand is just reliable. I can start updating my code with a half baked idea, start adding types to things, removing parameters from functions, changing variables names and I KNOW nothing will sneak on me during runtime. This is more of a feature of strong type systems than Rust itself, but still this is what productivity means to me. (Also, to me lifetimes were the hardest concept to grasp, but I think once you really get what they mean that's when the language clicks and you get the same productivity you would elsewhere)

throwaway894345 7y ago
Fully agree that (all else equal) static type systems are more productive than dynamic type systems; however, that's mostly orthogonal to GC vs Rust's ownership model. I agree that Rust's ownership model provides for more correctness than GC, but at the expense of a whole lot of productivity (which was my original point). I also think the returns on static type systems (and static analysis in general) diminish quickly after (roughly) Go's position on the axis. To be clear, I would like to see Go have a more expressive type system (generics and sum types), but I think Go recoups upwards of ~90% of the quality difference between untyped Python and Rust (for example) while still allowing you to be at least as productive as with Python (which is still about 90% more productive than with Rust IMO). Disclaimers: this is all super subjective, error margins are huge, and YMMV.
- dpc_pw 7y ago
  I would take Go over Python, any day. It is productive, especially if your program is a relatively typical network service: get request, poke here and there, transform this into that, return a result. It looses steam when the code is abstract logic or generics/macros heavy. Also, I personally loose quite a bit of time on debugging these couple of pesky issues that I always get introduced by `nil`, lack of sum types, some Go gotchas etc. In practice the most important things for general productivity are always: what is your team familiar with, what are you familiar with, and are the types of libraries that you need available. Quite often these are skewed in Go's favor.

throwaway894345 7y ago

Fully agree that (all else equal) static type systems are more productive than dynamic type systems; however, that's mostly orthogonal to GC vs Rust's ownership model. I agree that Rust's ownership model provides for more correctness than GC, but at the expense of a whole lot of productivity (which was my original point). I also think the returns on static type systems (and static analysis in general) diminish quickly after (roughly) Go's position on the axis. To be clear, I would like to see Go have a more expressive type system (generics and sum types), but I think Go recoups upwards of ~90% of the quality difference between untyped Python and Rust (for example) while still allowing you to be at least as productive as with Python (which is still about 90% more productive than with Rust IMO). Disclaimers: this is all super subjective, error margins are huge, and YMMV.

dpc_pw 7y ago
I would take Go over Python, any day. It is productive, especially if your program is a relatively typical network service: get request, poke here and there, transform this into that, return a result. It looses steam when the code is abstract logic or generics/macros heavy. Also, I personally loose quite a bit of time on debugging these couple of pesky issues that I always get introduced by `nil`, lack of sum types, some Go gotchas etc. In practice the most important things for general productivity are always: what is your team familiar with, what are you familiar with, and are the types of libraries that you need available. Quite often these are skewed in Go's favor.