4 ms·

Speaking of overinflated egos. While there's no question pike, thompson, and k are a cut above, I think they made assumptions that engineers cannot be trusted.

Speaking of overinflated egos. While there's no question pike, thompson, and k are a cut above, I think they made assumptions that engineers cannot be trusted. Garbage collection is another such example. Compare that to e.g. rust's model which hoists the understanding of lifetime to the engineer, while encumbering the compiler with the dirty work. Whereas golang asks the engineer to do neither (granted golang came later, so maybe they didn't think it was possible).

Yasuraka 3y ago
Even if they can be trusted (I wouldn't trust myself), GC is a big time saver and I'd say well worth the trade-off. There's far more performance to be had elsewhere (compiler) but wherever that's or manual memory management is needed, there is a language to fit that need.
throwaway894345 3y ago
This seems like a silly argument. By the same token, we can argue that Rust doesn’t think engineers can be trusted because it pushes a bunch of type and memory safety onto the compiler instead of letting the engineers manage it as their ancestors did. Of course, they were right to do so—we shouldn’t trust engineers with all of these tedious, error-prone processes. And while Rust solves for memory safety with borrow checking, that turns out to be a pretty limited solution from a productivity perspective (or at least that seems to be the majority opinion among people who have extensive experience with both languages) compared to borrow checkers—sometimes it’s appropriate to trade productivity for performance/correctness, but many times it isn’t.
cube2222 3y ago
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.
scruple 3y ago
> I think they made assumptions that engineers cannot be trusted. Having spent ~2 decades working with engineers, I'm inclined to agree... Past, present, and future self included!
kaashif 3y ago
> I think they made assumptions that engineers cannot be trusted. I disagree, if you don't think engineers can be trusted, you wouldn't want to trust engineers to remember to close files or connections, you'd have some language feature to do that automatically. C++ and Rust solved this with RAII and destructors. In my opinion, this is on the same level as "just remember to check bounds" or "just remember to free memory".

Yasuraka 3y ago

Even if they can be trusted (I wouldn't trust myself), GC is a big time saver and I'd say well worth the trade-off. There's far more performance to be had elsewhere (compiler) but wherever that's or manual memory management is needed, there is a language to fit that need.

throwaway894345 3y ago

This seems like a silly argument. By the same token, we can argue that Rust doesn’t think engineers can be trusted because it pushes a bunch of type and memory safety onto the compiler instead of letting the engineers manage it as their ancestors did. Of course, they were right to do so—we shouldn’t trust engineers with all of these tedious, error-prone processes. And while Rust solves for memory safety with borrow checking, that turns out to be a pretty limited solution from a productivity perspective (or at least that seems to be the majority opinion among people who have extensive experience with both languages) compared to borrow checkers—sometimes it’s appropriate to trade productivity for performance/correctness, but many times it isn’t.

cube2222 3y ago

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.

scruple 3y ago

> I think they made assumptions that engineers cannot be trusted. Having spent ~2 decades working with engineers, I'm inclined to agree... Past, present, and future self included!

kaashif 3y ago

> I think they made assumptions that engineers cannot be trusted. I disagree, if you don't think engineers can be trusted, you wouldn't want to trust engineers to remember to close files or connections, you'd have some language feature to do that automatically. C++ and Rust solved this with RAII and destructors. In my opinion, this is on the same level as "just remember to check bounds" or "just remember to free memory".