Use and after 0 clause then. It will not block if there are no messages matching the patterns given.
NobbZ
0
Fl4m3Ph03n1x
I assume it would be something like this then:
alias HTTPoison
defmodule Test.Poison do
def async_get(url) do
Task.start(fn ->
case HTTPoison.get(url, [], hackney: [pool: :first_pool], stream_to: self) do
response -> IO.inspect(response)
end
end)
end
end
I do have a question though. What is the difference between this approach of yours, and the one the rest of the people are recommending?
Task.start(fn ->
HTTPoison.get(url, [], hackney: [pool: :first_pool], stream_to: self)
receive do
response -> IO.inspect(response)
end
end)
Are they pretty much the same?
0
sztosz
If I read this correctly: Processes — Erlang System Documentation v29.0.2 new process needs 309 * 64 = 19776 bits of memory which is 2472 bytes (on 64 bit machine). I don’t know how much exactly a Linux or Windows new process or thread uses memory, but I believe it’s at least orders of magnitude more. What it boils down is that Erlang processes are very cheap, isolated, and BEAM cleans them when they finished they run, and OS processes are expensive. The overhead of creating new Erlang process to execute some code that has to be run asynchronously is negligible.
Donald Knuth wrote famous words
“Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.”
I strongly believe that in your case (when we talk about writing in Erlang) having additional process (started by Task.start) when you make HTTPoision requests asynchronously goes into that 97%.
I’m not saying that there is no overhead, nor that you have to agree, but that IMHO in most cases the overhead is negligible, but allow writing much more readable code.
2
ontofractal
You can do “fire and forget” requests within the current process if you have another process that handles HTTPoison responses using stream_to option like this HTTPoison.get! "your_url", %{}, stream_to: handler_process
1
sribe
dimitarvp
I think OP wants his method of async HTTP requests to work with a process/connection pool. I don’t think he disagrees with Elixir’s philosophy.
2
sribe
Using tasks in no way interferes with Hackney’s connection pools.
I think OP’s reaction has more to do with the fact that Elixir’s concurrency is so simple, that libraries leave it up to users to choose, rather than providing some explicit async call which hides a ton of complexity.
1
Fl4m3Ph03n1x
Thank you all for the answers and explanations. There seems to be a misunderstanding that I don’t agree with the path Elixir has taken to deal with Async requests, some even generalizing that I am not a fan of the Actor model inherent to Erlang.
Such is not true. The post that illustrates almost in perfection my reaction is in fact here:
I am not a seasoned Elixir / Erlang developer. I wish I was, but truth is I came into this strange world from a Functional Javascript background. In JS, as some of you may know, you either use Promises or (the better version) Futures (and no, I am not going to mention callbacks… leave me alone!). All libraries offer you a way to handle async behavior by default.
I thought Elixir was similar. I am happy to see it isn’t. Now that I have a better understanding on how to handle async behavior in Elixir I see how much more powerful (and dangerous :D) it is.
My quest for learning hasn’t stopped yet, but I think I got what I needed from here 
Thank you everyone!
7
datadrover
You should watch Joe Armstrong’s Kent lectures on concurrency. In particular, look out for the bit on Promises in video 2. Beautifully simple and elegant.
4
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
Javascript libraries offer an “async” mode because if they don’t, then using them blocks everything. This isn’t a problem in Elixir. When a single process does a “receive” it simply blocks that process. Every other process (like other HTTP requests) are still able to happen. It’s conceptually like doing .then in javascript, but actually even better.
This is awesome because not only does it apply to IO, it even applies to CPU bound operations. If your process starts an infinite loop or starts doing a lot of math, it won’t block other processes. In javascript it will.
7