4 ms·

The type system in Go is as important as the concurrency system. Sure, Erlang can do concurrency as well as (or better than) Go, but it doesn't have the type s

by zemo 13y ago

The type system in Go is as important as the concurrency system. Sure, Erlang can do concurrency as well as (or better than) Go, but it doesn't have the type safety that Go offers.

tptacek 13y ago
Can it do concurrency better than Go? How so?
- pcwalton 13y ago
  For one, a shared-nothing design makes migration to different machines easier and doesn't require a stop-the-world garbage collector. Erlang is memory safe in the presence of many-core (or many-system) parallelism. Go is not (you can segfault, possibly in an exploitable way, if GOMAXPROCS > 1). Erlang unbounded channels reduce deadlocks because your sender can continue execution without waiting for a receiver.
  - tptacek 13y ago
    Have we heard a lot of stories about deployed Golang apps having problems because of garbage collection? It's true that this is a significant designed-in advantage for Erlang, which can run it's collector on a process-by-process basis. What's also true and potentially compensatory is the C-like degree of control Golang gives you over how you allocate memory and lay it out. I'm not sure the unbounded channel thing is a real advantage for Erlang. I'm happy to be convinced I'm wrong. What's a real, correct design which would be hard to realize in Golang (without unbounded channels) that relies on unbounded channels?
    - pcwalton 13y ago
      > Have we heard a lot of stories about deployed Golang apps having problems because of garbage collection? It's true that this is a significant designed-in advantage for Erlang, which can run it's collector on a process-by-process basis. In general most Go apps that have been deployed are Web apps and server infrastructure, where concurrent garbage collection is not too much of a problem in practice. So Go's choice makes sense in Go's context. It does limit parallel scalability in some contexts—which of course are not the contexts that most people have been using Go for at this point. > What's also true and potentially compensatory is the C-like degree of control Golang gives you over how you allocate memory and lay it out. Go doesn't give you C-like control over allocation of memory. Language constructs will allocate memory in ways that are not immediately obvious, to quote Ian Lance Taylor [1]. It does give you control over layout of memory. > I'm not sure the unbounded channel thing is a real advantage for Erlang. I'm happy to be convinced I'm wrong. What's a real, correct design which would be hard to realize in Golang (without unbounded channels) that relies on unbounded channels? Suppose you're pulling down images from the network and printing out a sorted list of URLs of all the images you find. You might structure it as two goroutines A and B. Make two channels, "urls" and "done". Goroutine A is the network goroutine and simply crawls looking for images to stream to B over the channel "urls". When it's done it sends "true" on "done". Goroutine B is the sorting goroutine and first blocks on the channel "done" before it proceeds, after which it drains the "urls" channel and sorts the results. This program contains a deadlock due to synchronous message sends. If there are more URLs to be downloaded than the buffer size of "urls", then the program will deadlock. If "urls" were an asynchronous channel, however, this would be fine. Of course this can be structured to fix it, by doing the send in another goroutine for example (although that costs performance). But hopefully that's a good illustration of the subtleties of synchronous message sending. [1]: https://groups.google.com/forum/#!msg/golang-nuts/LoJJ1bICduA/AQFtD8_VI0sJ https://groups.google.com/forum/#!msg/golang-nuts/LoJJ1bICdu...
      - tptacek 13y ago
        Go doesn't give you C-like control over allocation of memory. Language constructs will allocate memory in ways that are not immediately obvious, to quote Ian Lance Taylor [1]. It does give you control over layout of memory. These are two sides of the same coin. Having control over memory layout allows you to implement what are in effect allocators.
        pcwalton 13y ago
        But it doesn't give you control over when you allocate. (Also, if you implement memory pools, the GC still has to trace the pointers within at mark time.)
        tptacek 13y ago
        You are playing with the definition of either "allocate" or "when" in that sentence, or ignoring what I wrote. :)
  - karaziox 13y ago
    go func(){ channel <- data }() Here, you will never actually block on your send since it runs on it own goroutine. I can't see an actual use case for this kind of thing but since you are using this argument over and over then.. :)
  - _ak 13y ago
    Do you have any sources on the exploitable segfault claim, or is that just FUD?
    - tptacek 13y ago
      It's mostly FUD, but it's a rathole of an argument since nobody has defined what "exploitable" means. Rather than nail down the term so we can all have ourselves an even more pointed language war, we should probably just let this go.
    - pcwalton 13y ago
      Sure. http://research.swtch.com/gorace http://research.swtch.com/gorace In general I consider segfaults exploitable, because of heap spray and virtual method calls. Even if not "exploitable", I consider it "very very scary".
      - tptacek 13y ago
        This is far fetched. The threat scenario that page contemplates is "what happens if you're trying to safely run untrusted Golang code, as if it was content-controlled Javascript and you were a browser". It's not the case that Golang in its natural environment gives attackers the ability to paint the heap with malicious addresses and then provide themselves with a statistically significant shot at corrupting memory to exploit those addresses. Your point is a reason that Golang couldn't be dropped in as a browser Javascript replacement. But nobody has ever suggested that it could be; it can't, just like Java (which was designed for the purpose but failed at it) and Erlang (which wasn't) can't.
        pcwalton 13y ago
        > It's not the case that Golang in its natural environment gives attackers the ability to paint the heap with malicious addresses and then provide themselves with a statistically significant shot at corrupting memory to exploit those addresses. What if a Go program allowed Go objects to be scripted by untrusted user code written in JavaScript? In browsers it is very possible to corrupt the Frame (Gecko)/RenderObject (WebKit) tree, which is in a C++ heap that is separate from the JavaScript heap. The memory safety issues in C++ are a problem not because they mean that untrusted code written in C++ can't safely be executed (although it does mean that). It also means that safe languages become easily weaponizable. JavaScript (or Lua, or whatever) embedded in a Go program could paint the heap with malicious addresses.
- MetaCosm 13y ago
  The processes are first class and can be killed and monitored from the outside.
- zemo 13y ago
  honestly, I don't know. I know Go does concurrency well and I like it, the only reason I said it was equivalent or better was to avoid a flamewar. I've never even used Erlang.

by zemo 13y ago

The type system in Go is as important as the concurrency system. Sure, Erlang can do concurrency as well as (or better than) Go, but it doesn't have the type safety that Go offers.

tptacek 13y ago

Can it do concurrency better than Go? How so?

pcwalton 13y ago
For one, a shared-nothing design makes migration to different machines easier and doesn't require a stop-the-world garbage collector. Erlang is memory safe in the presence of many-core (or many-system) parallelism. Go is not (you can segfault, possibly in an exploitable way, if GOMAXPROCS > 1). Erlang unbounded channels reduce deadlocks because your sender can continue execution without waiting for a receiver.
- tptacek 13y ago
  Have we heard a lot of stories about deployed Golang apps having problems because of garbage collection? It's true that this is a significant designed-in advantage for Erlang, which can run it's collector on a process-by-process basis. What's also true and potentially compensatory is the C-like degree of control Golang gives you over how you allocate memory and lay it out. I'm not sure the unbounded channel thing is a real advantage for Erlang. I'm happy to be convinced I'm wrong. What's a real, correct design which would be hard to realize in Golang (without unbounded channels) that relies on unbounded channels?
  - pcwalton 13y ago
    > Have we heard a lot of stories about deployed Golang apps having problems because of garbage collection? It's true that this is a significant designed-in advantage for Erlang, which can run it's collector on a process-by-process basis. In general most Go apps that have been deployed are Web apps and server infrastructure, where concurrent garbage collection is not too much of a problem in practice. So Go's choice makes sense in Go's context. It does limit parallel scalability in some contexts—which of course are not the contexts that most people have been using Go for at this point. > What's also true and potentially compensatory is the C-like degree of control Golang gives you over how you allocate memory and lay it out. Go doesn't give you C-like control over allocation of memory. Language constructs will allocate memory in ways that are not immediately obvious, to quote Ian Lance Taylor [1]. It does give you control over layout of memory. > I'm not sure the unbounded channel thing is a real advantage for Erlang. I'm happy to be convinced I'm wrong. What's a real, correct design which would be hard to realize in Golang (without unbounded channels) that relies on unbounded channels? Suppose you're pulling down images from the network and printing out a sorted list of URLs of all the images you find. You might structure it as two goroutines A and B. Make two channels, "urls" and "done". Goroutine A is the network goroutine and simply crawls looking for images to stream to B over the channel "urls". When it's done it sends "true" on "done". Goroutine B is the sorting goroutine and first blocks on the channel "done" before it proceeds, after which it drains the "urls" channel and sorts the results. This program contains a deadlock due to synchronous message sends. If there are more URLs to be downloaded than the buffer size of "urls", then the program will deadlock. If "urls" were an asynchronous channel, however, this would be fine. Of course this can be structured to fix it, by doing the send in another goroutine for example (although that costs performance). But hopefully that's a good illustration of the subtleties of synchronous message sending. [1]: https://groups.google.com/forum/#!msg/golang-nuts/LoJJ1bICduA/AQFtD8_VI0sJ https://groups.google.com/forum/#!msg/golang-nuts/LoJJ1bICdu...
    - tptacek 13y ago
      Go doesn't give you C-like control over allocation of memory. Language constructs will allocate memory in ways that are not immediately obvious, to quote Ian Lance Taylor [1]. It does give you control over layout of memory. These are two sides of the same coin. Having control over memory layout allows you to implement what are in effect allocators.
      - pcwalton 13y ago
        But it doesn't give you control over when you allocate. (Also, if you implement memory pools, the GC still has to trace the pointers within at mark time.)
        tptacek 13y ago
        You are playing with the definition of either "allocate" or "when" in that sentence, or ignoring what I wrote. :)
- karaziox 13y ago
  go func(){ channel <- data }() Here, you will never actually block on your send since it runs on it own goroutine. I can't see an actual use case for this kind of thing but since you are using this argument over and over then.. :)
- _ak 13y ago
  Do you have any sources on the exploitable segfault claim, or is that just FUD?
  - tptacek 13y ago
    It's mostly FUD, but it's a rathole of an argument since nobody has defined what "exploitable" means. Rather than nail down the term so we can all have ourselves an even more pointed language war, we should probably just let this go.
  - pcwalton 13y ago
    Sure. http://research.swtch.com/gorace http://research.swtch.com/gorace In general I consider segfaults exploitable, because of heap spray and virtual method calls. Even if not "exploitable", I consider it "very very scary".
    - tptacek 13y ago
      This is far fetched. The threat scenario that page contemplates is "what happens if you're trying to safely run untrusted Golang code, as if it was content-controlled Javascript and you were a browser". It's not the case that Golang in its natural environment gives attackers the ability to paint the heap with malicious addresses and then provide themselves with a statistically significant shot at corrupting memory to exploit those addresses. Your point is a reason that Golang couldn't be dropped in as a browser Javascript replacement. But nobody has ever suggested that it could be; it can't, just like Java (which was designed for the purpose but failed at it) and Erlang (which wasn't) can't.
      - pcwalton 13y ago
        > It's not the case that Golang in its natural environment gives attackers the ability to paint the heap with malicious addresses and then provide themselves with a statistically significant shot at corrupting memory to exploit those addresses. What if a Go program allowed Go objects to be scripted by untrusted user code written in JavaScript? In browsers it is very possible to corrupt the Frame (Gecko)/RenderObject (WebKit) tree, which is in a C++ heap that is separate from the JavaScript heap. The memory safety issues in C++ are a problem not because they mean that untrusted code written in C++ can't safely be executed (although it does mean that). It also means that safe languages become easily weaponizable. JavaScript (or Lua, or whatever) embedded in a Go program could paint the heap with malicious addresses.
MetaCosm 13y ago
The processes are first class and can be killed and monitored from the outside.
zemo 13y ago
honestly, I don't know. I know Go does concurrency well and I like it, the only reason I said it was equivalent or better was to avoid a flamewar. I've never even used Erlang.