4 ms·

What do you mean by sync being hard to implement in Erlang? Simple synchronous requests can easily be implemented: Server ! {request, Request}, receive

What do you mean by sync being hard to implement in Erlang? Simple synchronous requests can easily be implemented: Server ! {request, Request}, receive {reply, Reply} -> {ok, Reply} end. This is also the default way when using the built-in gen_server library.

jerf 11y ago
In Go, sending a message on a channel is actually a sync point between the sender and the receiver; a channel blocks until it has both. (Buffered channels may not necessarily block, but you have to treat them as if they do anyhow in general.) Thus, the send itself is synchronous, not just the fact that we're "waiting until we get an answer". If the sender proceeds past the line that sends on a channel, we know a receiver has received it. I don't know of an efficient way to emulate this in Erlang. Suppose you have a pool of 10 undistinguished server processes in Erlang and you just want "a" process to answer. If you use Go channels, you have all 10 listen on a channel, and you automatically get the behavior where as long as one is available, that one will pick up the request. You also automatically get backpressure; if none are available, the attempt to send will hang. (There are ways of turning that into a timeout if you need to.) In Erlang, you could try to create an 11th coordinator process, but you'll create a lot of additional traffic and take a latency hit on every request. (Plus, some of the naive ways you might implement that will get you in further performance trouble with mailbox scanning. This is going to be a non-trivial thing to build correctly.) Or you could just randomly pick and send, but if you pick one that's currently answering a slow request while others are available, you get spurious latency. It hasn't been a killer in my system, but it's been an annoyance. And to be clear, let me reiterate that having using both systems, I actually still like Erlang's behavior as a better default. It's really hard to deadlock Erlang... it's much easier to deadlock Go. The async message passing is, in my experience, much easier to use correctly without much thinking. But it would be nice to also have a "channel" in Erlang, despite the limitations it would have to have with not being able to go across nodes. In fact, technically speaking, subject to that limitation (and there are already a couple of other functions limited to the current node), there's no reason I could see why this couldn't be added to Erlang. See for instance: https://github.com/inaka/worker_pool https://github.com/inaka/worker_pool , particularly the section discussion "strategy", and the discussion about "available_worker" and its discussion on performance implications, and its specific references to the other tricky edge cases to consider. Of course, programming languages being programming languages, someone else can do the work and you can just use it, but in Go, this behavior is quite trivial. (By contrast, in Go, proper asynchronous messaging in the Erlang style is a challenge. Whacking together a "slice" and some "messages" isn't that hard, but you've got other edge cases to consider... to say nothing of network transparency!)
- felixgallo 11y ago
  What in particular about gen_server:call is not working for you?
  - jerf 11y ago
    All I can really do in reply to this is ask you to reread the post I wrote more carefully. If you have a more specific clarification, let me know.
    - felixgallo 11y ago
      I read it, I'm asking pragmatically; although in theory using worker pools can have problems at the edges, in practice erlang's message processing speed is quite high, and, e.g., worker_pool in production at many thousands of messages per second is working great for me. The latency of a single message pass is submillisecond. You're having problems, despite that?
      - jerf 11y ago
        I covered that. If you have high variance in how long message processing takes, which is very easy to do accidentally, then if you something simple like "random" you can easily block up the message latency. (Of course, "don't do that". Easier said than done.) If you're at a scale at which you're seriously using Erlang, "fast" isn't really a concept that applies anymore. You really end up with "enough performance" or "not enough performance", with an at-times surprisingly sharp transition from one to the other, and while the base performance of the underlying language is certainly a major factor in whether you have "enough", it isn't the only factor, or even necessarily the most important. (Which is good for Erlang, because it's actually quite slow at most conventional things.) It doesn't matter if I've got "sub-millisecond message processing" if I'm trying to run more messages through a box than it can handle, or if I've got an external response handler that sometimes clogs up. There's no way that Erlang can possibly be "fast" enough that somebody won't throw a task at it that's still a performance challenge.
- josevalim 11y ago

jerf 11y ago

In Go, sending a message on a channel is actually a sync point between the sender and the receiver; a channel blocks until it has both. (Buffered channels may not necessarily block, but you have to treat them as if they do anyhow in general.) Thus, the send itself is synchronous, not just the fact that we're "waiting until we get an answer". If the sender proceeds past the line that sends on a channel, we know a receiver has received it. I don't know of an efficient way to emulate this in Erlang. Suppose you have a pool of 10 undistinguished server processes in Erlang and you just want "a" process to answer. If you use Go channels, you have all 10 listen on a channel, and you automatically get the behavior where as long as one is available, that one will pick up the request. You also automatically get backpressure; if none are available, the attempt to send will hang. (There are ways of turning that into a timeout if you need to.) In Erlang, you could try to create an 11th coordinator process, but you'll create a lot of additional traffic and take a latency hit on every request. (Plus, some of the naive ways you might implement that will get you in further performance trouble with mailbox scanning. This is going to be a non-trivial thing to build correctly.) Or you could just randomly pick and send, but if you pick one that's currently answering a slow request while others are available, you get spurious latency. It hasn't been a killer in my system, but it's been an annoyance. And to be clear, let me reiterate that having using both systems, I actually still like Erlang's behavior as a better default. It's really hard to deadlock Erlang... it's much easier to deadlock Go. The async message passing is, in my experience, much easier to use correctly without much thinking. But it would be nice to also have a "channel" in Erlang, despite the limitations it would have to have with not being able to go across nodes. In fact, technically speaking, subject to that limitation (and there are already a couple of other functions limited to the current node), there's no reason I could see why this couldn't be added to Erlang. See for instance: https://github.com/inaka/worker_pool https://github.com/inaka/worker_pool , particularly the section discussion "strategy", and the discussion about "available_worker" and its discussion on performance implications, and its specific references to the other tricky edge cases to consider. Of course, programming languages being programming languages, someone else can do the work and you can just use it, but in Go, this behavior is quite trivial. (By contrast, in Go, proper asynchronous messaging in the Erlang style is a challenge. Whacking together a "slice" and some "messages" isn't that hard, but you've got other edge cases to consider... to say nothing of network transparency!)

felixgallo 11y ago
What in particular about gen_server:call is not working for you?
- jerf 11y ago
  All I can really do in reply to this is ask you to reread the post I wrote more carefully. If you have a more specific clarification, let me know.
  - felixgallo 11y ago
    I read it, I'm asking pragmatically; although in theory using worker pools can have problems at the edges, in practice erlang's message processing speed is quite high, and, e.g., worker_pool in production at many thousands of messages per second is working great for me. The latency of a single message pass is submillisecond. You're having problems, despite that?
    - jerf 11y ago
      I covered that. If you have high variance in how long message processing takes, which is very easy to do accidentally, then if you something simple like "random" you can easily block up the message latency. (Of course, "don't do that". Easier said than done.) If you're at a scale at which you're seriously using Erlang, "fast" isn't really a concept that applies anymore. You really end up with "enough performance" or "not enough performance", with an at-times surprisingly sharp transition from one to the other, and while the base performance of the underlying language is certainly a major factor in whether you have "enough", it isn't the only factor, or even necessarily the most important. (Which is good for Erlang, because it's actually quite slow at most conventional things.) It doesn't matter if I've got "sub-millisecond message processing" if I'm trying to run more messages through a box than it can handle, or if I've got an external response handler that sometimes clogs up. There's no way that Erlang can possibly be "fast" enough that somebody won't throw a task at it that's still a performance challenge.
josevalim 11y ago