5 ms·

Doesn't some of this depend on the performance needs of your application. Go appears to be faster and use less memory the Erlang in this popular microbenchmark:

• jerf 13y ago
  I didn't say anything about performance, and that's because I don't think performance has much to do with it. If Go used asynchronous mailboxes, its performance at most would be ever so slightly worse, it would still be much better than Erlang, and Go's performance loss would probably entirely disappear in microbenchmarks anyhow. Indeed, that's one of my frustrations with Go, one of the big reasons I chose to leave it alone. The ways in which it is much less safe to use concurrently than Erlang or Haskell aren't performance related, they're related to the choice of primitives. (In particular, I can't see how to build an OTP equivalent for Go. This is a big problem for me, since I was looking at it to replace Erlang, but I'm not ripping out something that has demonstrated how bullet-proof it is to replace it with something more fragile like Go, when performance is not my problem.) To be clear, I'm just talking about the concurrency primitives, and I do not believe that Go's concurrency primitives are better than Haskell or Erlang's, full stop. That does not mean Go is not a better language for some tasks, and I further believe Go's concurrency primitives are a step up over most current "conventional" languages, equally full stop. For one thing, to program in Erlang or Haskell requires programming in Erlang or Haskell, which is why I mentioned the fact that 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. So much... whining.
  • 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 ago
      Sure 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.
  • jemfinch 13y ago
    > I do not believe that Go's concurrency primitives are better than Haskell or Erlang's, full stop. Unless I'm mistaken (and please correct me if I am!), synchronous primitives can be used to implement asynchronous primitives, but the converse isn't true. If that's the case, why would Erlang's asynchronous primitives not be inferior to Go's synchronous primitives?
    • voidlogic 13y ago
      Its worth pointing out that in Go something like a channel read can also be non-blocking. As can placing a value on a channel be.
• danieldk 13y ago
  Go vs Haskell/Erlang has a similar showing in TechEmpower's Web Framework Benchmarks Many servers solve the c10k problem (not that it is an issue for many users anyway), but it always seemed as much interesting to me how your code is structured with a highly concurrent server. E.g. Yesod and Snap (via WAI) allow you to stream the request and response with conduit (and enumerator) and build nice and composable pipelines. Play 2 is also moving in that direction with their iteratee implementation: http://www.playframework.com/documentation/2.1.1/Iteratees http://www.playframework.com/documentation/2.1.1/Iteratees Iteratee/pipe-based processing would never be possible in Go, since it does not offer parametric polymorphism and typeclasses. Sure, you could write transformations to take and produce interface{}s, but it will give you as much type safety as a dynamic languages and type switches in every function.
  • voidlogic 13y ago
    >>Go vs Haskell/Erlang has a similar showing in TechEmpower's Web Framework Benchmarks As in similar to the above benchmark, as in spanked by Go in Erlang's case.