[erlang-questions] Erlang and Akka, The Sequel

[Youngkin, Rich]

Thanks Fred for clarifying the example in your original response.  Thanks
too to OK for the additional information, more below.

Cheers,
Rich

On Mon, Mar 30, 2015 at 7:39 AM, Fred Hebert <mononcqc@REDACTED> wrote:
> On 03/31, Youngkin, Rich wrote:

>    try
>>        {ok, Cs} = adventure:collect_coins(),
>>        Res = lists:flatmap(fun(Coins) ->
>>            {ok, Val} = adventure:buy_treasure(Coins),
>>            Val
>>        end, Cs),
>>    of
>>        SuccessValue ->
>>            %% Do something like continue to next challenge
>>    catch
>>        Type:Reason ->
>>            %% Do something like maybe repeat the previous challenge
>>    end.
>> ...
>>    try
>>        lists:flatmap(fun(Coins) -> adventure:buy_treasure(Coins) end,
>>                      adventure:collect_coins())
>>    of
>>        SuccessValue -> % Keep going
>>    catch
>>        _:_ -> % alt path
>>    end
>>
>>
> >> I don't see a difference between the previous 2 Erlang
> implementations. Can
> >> you elaborate?
>
>
> One of them matches on `{ok, Value}' to cause a failure, which makes the
assumption 'bad' cases are returned
> as `undefined' or `{ok, Error}'. In the latter case it is expected that
the called code raises exceptions when something
> goes wrong.

Got it, thanks!

On Wed, Apr 1, 2015 at 5:56 PM, <ok@REDACTED> wrote:

>
> I find the Java example compelling:  if I want some threads
> communicating in a particular way in Java, as of 1.8 it is
> easier to go back to basics than to read all the library
> documentation and figure out what's going on.
>
> What saves the OTP behaviours from the same fate?
> Mainly the fact that there aren't very many of them,
> and the number isn't growing.  Erlang/OTP seems to strike
> a very nice balance between a core of simple Erlang
> primitives and a limited palette of "big" behaviours that
> take a lot of the work off your hands.  Futures fall into
> the "much needed gap".
>

Interesting point. One of the things I like about Erlang is it's
simplicity. I don't quite follow what you mean by "Futures fall into the
"much needed gap"". Are you saying that futures should, or should not, be
added to Erlang/OTP? I'm thinking not.


>
> When you might reach for a FutureTask<T> in Java, in
> Erlang you would think about what the processes are
> doing and how they communicate and you would look at the
> constellation of communicating processes and you might
> very well end up thinking that the Future-style
> communication pattern was *not* after all the best.
>
>
Agreed. Understanding the problem and picking an appropriate solution is
always the best approach. Blindly implementing a solution, either because
you don't really understand the problem or because something is cool (e.g.,
futures), is never good.


> > Garrett Smith gave a great presentation at last week's Erlang conference
> > about "The Timeless Way of Building Erlang Apps" (see [3] and
> > erlangpatterns.org). What I think could be useful is a "pattern"
> > description for futures that incorporates the implementation using RPCs.
> I
> > may just do this if someone doesn't beat me to it.
>
> For me, the single most important piece of advice is
> DON'T THINK IN TERMS OF FUTURES AND THEN ENCODE THAT IN ERLANG.
> Think in terms of processes and the communication between them.
> Consider alternative communication architectures.
>

One of my motivations in starting this email thread is due to my relative
newness to Erlang. As might be apparent from some of my questions, I don't
necessarily have a good understanding of the best practices for solving a
given class of problems. For someone like me it would be good to at least
have code examples of how to implement certain best practices. These
examples could also include information on what problems they might not be
appropriate to for. Regarding futures, I'm assuming, perhaps mistakenly,
that they could be useful in some Erlang applications. Regarding best
practices, this is the area that I believe erlangpatterns.org is intended
to address.

To reiterate what I said above, one shouldn't blindly implement a solution
without considering when it is appropriate and when it isn't appropriate.
This is what I think you meant when you stated above "DON'T THINK IN TERMS
OF FUTURES AND THEN ENCODE THAT IN ERLANG".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150402/e5b91141/attachment.htm>