3 ms·
>>I didn't say anything about performance, and that's because I don't think performance has much to do with it. Sure but that is why I brought it up. Performan
by voidlogic 13y ago
>>I didn't say anything about performance, and that's because I don't think performance has much to do with it.
Sure but that is why I brought it up. Performance and safety are very often two sides to the same tradeoff. You were saying you thought the concurrency of Erlang was safer, and I was proposing that depending on the problem domain, a little risk can be worth the performance gain. That being said, I think Go makes concurrency easy to get right (much less risky than say C/C++), it just doesn't ensure correctness.
>>...Go is still an Algol-esque language. That's a legitimate advantage. I've paid the price of learning the alternate paradigms, but I would generally recommend Go to a larger corporate deployment before I'd recommend trying to convince a couple dozen people to learn Erlang.
Wise man :)
- danieldk 13y agoSure but that is why I brought it up. Performance and safety are very often two sides to the same tradeoff. Haskell is pretty much the counter example. But Haskell will always to be weird to most imperative programmers. This is why I am far more exited by Rust than by Go, it promises to deliver performance and safety in an imperative language. Also, there are actor implementations on top of languages that are more performant than Erlang. E.g. see Akka for Java and Scala.
- voidlogic 13y ago>>Haskell is pretty much the counter example. I said "very often" for this reason, there is always an exception to the rule. I do love Haskell too. >>This is why I am far more exited by Rust than by Go, it promises to deliver performance and safety in an imperative language. To be clear we were talking about concurrency safety, not type and memory safety; Go is type and memory safe. If an organization using Go chose to tell programmers they could not send pointers between goroutines or share global state, Go would be just as communication safe as Rust. Just in Go, this communication safety is optional.
- pcwalton 13y ago> To be clear we were talking about concurrency safety, not type and memory safety; Go is type and memory safe. Not if you're using parallelism (GOMAXPROCS > 1). > If an organization using Go chose to tell programmers they could not send pointers between goroutines or share global state, Go would be just as communication safe as Rust. Just in Go, this communication safety is optional. It is in Rust as well. You just have to declare that you're opting into data races; safety is the default and enforced by the compiler if you don't opt in.