Fri Feb 28 10:30:48 CET 2003
>What I would really like to have is a managed code version of the Beam DLL,
>(either as a real .Net assembly or as a native DLL that can be PInvoked),
> that could be dropped into any .Net project, allowing the application to
>act as a real Erlang node,
>but also with a good user interface.
>I also attempted that - but the horrors of that experiment are better left
>unmentioned - suffice it to say that it's like trying
>to build Erlang natively on Win32 but with 100 times the difficulty :-)
I was thinking about something like this too, only not with .Net, just from
a regular program. I even mentioned it here, and the answer was that this
would impede with the Erlang node's stability (just like a linked-in driver
does, but since the external application is more complex, the chances for it
to crash are bigger).
That's why I rethought the idea and I feel now it is best to use normal
TCP/IP communication. This might have some advantages over implementing an
Erlang node, namely that several channels might be used and thus no
serialization is needed anymore. However it might also be possible to
implement several virtual C (or whatever) nodes in a single process, and
they will have several channels too.
I found in a paper today a quote attributed to Knuth:
"The most important thing in the programming language is the name. A
language will not succeed without a good name. I have recently invented a
very good name and now I am looking for a suitable language."
Is it time to look for a new cool name for Erlang? :-)
Skaffa fler messengerkontakter - Vinn 10.000 i resecheckar!
More information about the erlang-questions