[erlang-questions] Erlang and Akka

[Thomas Lindgren]

"X is a process id for a process that expectsmessages of type Y".

Difficult issue, in my opinion. 

I know of a couple of related ways to do this. First, the concurrent versions of ML, among others, often have "typed channels" for process communication. Personally, I find them awkward to use but they do provide a way to type a form of message passing. 



On Friday, August 29, 2014 12:11 AM, Richard A. O'Keefe <ok@REDACTED> wrote:
 

>
>
>
>On 29/08/2014, at 2:18 AM, Xiao Jia wrote:
>> 
>> So what if we have both Erlang(-style) concurrency and C++ performance (for number crunching, ...) in some new language (yet to be developed)?
>
>C++ performance relies on several things.
>One of them is the type system.
>We know how to get close-to-C performance in a functional
>language; Xavier Leroy did an impressive job with OCaml.
>It depends on a good type system.
>
>The trick is to extend the type system to send and receive.
>This seems like the weakest aspect of Dialyzer: I cannot
>say "X is a process id for a process that expects
>messages of type Y".
>
>Get the type system right and the rest will follow.
>
>Of course, one of Erlang's strengths has always been that you
>don't *have* to use types.
>
>Having said that, I must emphasise once more that
>"I am writing in C++" does NOT imply "my code is efficient".
>I have known *interpreted* Scheme to run faster than
>*compiled* C++.  Memory management is a tricky subject and
>manual (delete) or semi-manual (smart pointers) is NOT always
>faster.
>
>>  Regardless of community size, reusable libraries and other "human-related" issues commonly faced by any new language, can we say such a new language is better than both Erlang and C++ because it (potentially) beats both in performance and concurrency, respectively?
>
>One of the saddest errors in classical philosophy was the use
>of "better" as though it was unequivocal.  Let E be Erlang,
>C be C++, and N be the new language.  It is possible that
>  N >= E (concurrency)
>  N >  E (performance)
>  N <  E (readability)
>  N <  E (human error rate)
>  N >  C (concurrency)
>  N >= C (performance)
>  N <  C (readability -- unlikely but for the sake of argument)
>  N <  C (human error rate -- again unlikely but still)
>We would then have to say that N is better than E and C
>AND ALSO that N is worse than E and C.
>
>
>
>_______________________________________________
>erlang-questions mailing list
>erlang-questions@REDACTED
>http://erlang.org/mailman/listinfo/erlang-questions
>
>
>

Second, Sven-Olof Nyström's old Erlang type analyzer was, at least in theory, capable of inferring types for erlang messages and processes. However, even if we remove a number of language features, an Erlang process can contain many receives connected by arbitrary control flow. Thus, I'd expect that a gen_fsm or suchlike where you essentially implement protocols could potentially yield a very complex type. (Granted, that statement depends on what sort of precision you're looking for in your types. The more I think of the nature of an "erlang process type", the less clear it gets.) 

The model checking guys, McErlang etc, might also have some way of dealing with this, but I haven't investigated that.

Best,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140829/4726fa29/attachment.htm>