4 ms·

The languages target different use-cases and rusts ownership model does indeed slow you down vs not having to think about it at all. Esp. closures, which Go us

The languages target different use-cases and rusts ownership model does indeed slow you down vs not having to think about it at all. Esp. closures, which Go uses a lot all over the place, are quite cumbersome in Rust. (I like both languages a lot)

chlorion 3y ago
I'm not sure what you mean by closures being cumbersome in rust. Rust uses closures very heavily, for things like iterators, spawning threads, async tasks, and lots of other things. I've never felt them to be cumbersome at all. Actually, for me, closures in rust are easier to use than in any other language I have used besides for various lisps! https://doc.rust-lang.org/book/ch13-01-closures.html https://doc.rust-lang.org/book/ch13-01-closures.html
- cube2222 3y ago
  When I say closure I mean anonymous functions that capture their environment, esp. in a mutable way. Those work fine in Rust for simple use-cases, but it gets annoying quickly. With a garbage collected language like Go, closures can freely capture stuff, use it, and then once no closure (or any other code, fwiw) references it anymore, it gets freed. Escape analysis and garbage collection make even more complex (like closures that outlive the scope) use cases (where lifetimes would be hell) trivial.
erik_seaberg 3y ago
Go doesn’t have immutability or enforced synchronization, and something as simple as a read/write conflict in a map can panic. If your language (like most) has shared mutable state, you must think about ownership, and it’s better for the compiler to check your work reliably.
- cube2222 3y ago
  You must think about synchronization, really, not necessarily ownership. What you're saying is true, but it's still not an obvious choice - there's still a tradeoff. The (hypothetical, e.g. Rust) compiler can check only a subset of correct programs, which means that many correct programs can't be successfully checked. This is all good if it only affects edge cases, it's not that good if it affects common cases. It additionally becomes less of an issue (in Go) if you avoid shared mutable state and use channels for complex cases. So all in all I agree the compiler checking your synchronization is nice, but it's a tradeoff (at least for now), and with the current state of it I think most projects will be just fine without it. On the other hand, there are projects that should definitely use languages that allow for static analysis like that.
  - erik_seaberg 3y ago
    Yeah, I’m thinking of ownership as exclusive access handed off in sync, and disposal as one more duty of the final owner. I would feel a lot more comfortable with channels if a linter would verify that every message is either mutex protected or a newly created graph (maybe a deep copy) never accessed again by the sender. Go already does some escape analysis to minimize heap allocations, but doesn’t flag a goroutine receiving nested maps or array slices that may be shared.
- throwaway894345 3y ago
  You’re making an argument in favor of Go: Go only makes you think about ownership in proportion to the amount of shared mutable state in your program. Many Go programs don’t have any shared mutable state and the ones that do often limit this state to a small kernel that manages the ownership details. In Rust, every single program has to deal with ownership, and the burden is proportional to that of the total amount of state in the program (not just the shared mutable bit). Further still, “it’s better for the compiler to check your work reliably” is limited to the shared mutable state that is completely in the purview of a single process—if you have a networked resource or a file that is accessed by multiple processes, rustc won’t save you. In Go’s niche (web services, daemons, etc), this is the overwhelming majority of all state.
  - erik_seaberg 3y ago
    > networked resource or a file that is accessed by multiple processes Leases or transactions save us in that case. Transactional memory has been offered, but hasn’t gone mainstream.
    - throwaway894345 3y ago
      Yes, there are solutions to those problems, but the point is that rustc doesn’t force you to use them. For example, rustc will happily let you write to a file without first ensuring that the process has exclusive write access to the file. It is no safer than Go in this regard.

chlorion 3y ago

I'm not sure what you mean by closures being cumbersome in rust. Rust uses closures very heavily, for things like iterators, spawning threads, async tasks, and lots of other things. I've never felt them to be cumbersome at all. Actually, for me, closures in rust are easier to use than in any other language I have used besides for various lisps! https://doc.rust-lang.org/book/ch13-01-closures.html https://doc.rust-lang.org/book/ch13-01-closures.html

cube2222 3y ago
When I say closure I mean anonymous functions that capture their environment, esp. in a mutable way. Those work fine in Rust for simple use-cases, but it gets annoying quickly. With a garbage collected language like Go, closures can freely capture stuff, use it, and then once no closure (or any other code, fwiw) references it anymore, it gets freed. Escape analysis and garbage collection make even more complex (like closures that outlive the scope) use cases (where lifetimes would be hell) trivial.

erik_seaberg 3y ago

Go doesn’t have immutability or enforced synchronization, and something as simple as a read/write conflict in a map can panic. If your language (like most) has shared mutable state, you must think about ownership, and it’s better for the compiler to check your work reliably.

cube2222 3y ago
You must think about synchronization, really, not necessarily ownership. What you're saying is true, but it's still not an obvious choice - there's still a tradeoff. The (hypothetical, e.g. Rust) compiler can check only a subset of correct programs, which means that many correct programs can't be successfully checked. This is all good if it only affects edge cases, it's not that good if it affects common cases. It additionally becomes less of an issue (in Go) if you avoid shared mutable state and use channels for complex cases. So all in all I agree the compiler checking your synchronization is nice, but it's a tradeoff (at least for now), and with the current state of it I think most projects will be just fine without it. On the other hand, there are projects that should definitely use languages that allow for static analysis like that.
- erik_seaberg 3y ago
  Yeah, I’m thinking of ownership as exclusive access handed off in sync, and disposal as one more duty of the final owner. I would feel a lot more comfortable with channels if a linter would verify that every message is either mutex protected or a newly created graph (maybe a deep copy) never accessed again by the sender. Go already does some escape analysis to minimize heap allocations, but doesn’t flag a goroutine receiving nested maps or array slices that may be shared.
throwaway894345 3y ago
You’re making an argument in favor of Go: Go only makes you think about ownership in proportion to the amount of shared mutable state in your program. Many Go programs don’t have any shared mutable state and the ones that do often limit this state to a small kernel that manages the ownership details. In Rust, every single program has to deal with ownership, and the burden is proportional to that of the total amount of state in the program (not just the shared mutable bit). Further still, “it’s better for the compiler to check your work reliably” is limited to the shared mutable state that is completely in the purview of a single process—if you have a networked resource or a file that is accessed by multiple processes, rustc won’t save you. In Go’s niche (web services, daemons, etc), this is the overwhelming majority of all state.
- erik_seaberg 3y ago
  > networked resource or a file that is accessed by multiple processes Leases or transactions save us in that case. Transactional memory has been offered, but hasn’t gone mainstream.
  - throwaway894345 3y ago
    Yes, there are solutions to those problems, but the point is that rustc doesn’t force you to use them. For example, rustc will happily let you write to a file without first ensuring that the process has exclusive write access to the file. It is no safer than Go in this regard.