[erlang-questions] suggestion: NIF_D

[Paul Davis]

On Tue, Apr 20, 2010 at 11:00 AM, Ulf Wiger
<ulf.wiger@REDACTED> wrote:
>
> Hi Paul,
>
> My assumption from what I've read is that the D runtime gives
> minimal overhead, and the integration is a matter of declaring
> the C API as EXTERNAL C (D-friendly declarations).
>
> But this is just from browsing. I am looking for concrete
> feedback if possible.

Ulf,

Sorry, I wrote that a bit too early. Reading it I realize I was being
a bit schizophrenic on how I was considering the use of D in
conjunction with Erlang.

In the case of "lets take a look at writing NIF's with D" I was trying
to say that the scope of a NIF is somewhat limited by the fact that it
must return quickly or risk locking the entire Erlang VM. Due to this,
the LOC in the NIF's I've seen is quite small (1K is a big NIF). With
such a small foot print I wouldn't expect the benefits of using a
language like D to outweigh the costs of depending on its build chain.

In the case of "lets take a look at providing a platform to run
arbitrary D in Erlang" I reckon that could be pretty awesome but I am
unsure whether it would be enough awesome to depend on whatever
build/runtime dependencies it required.

Paul

> BR,
> Ulf W
>
> Paul Davis wrote:
>>
>> Ulf,
>>
>> Two issues come to mind. NIF execution ties up an entire scheduler,
>> which means that embedded language environments are fairly limited in
>> what they can do. The two JavaScript embeddings I know of both focus
>> on use for small quickly executed scripts to serve merely as a
>> convenience and/or sandbox for user code on servers.
>>
>> Secondly, both JavaScript interpreter embeddings use less than 1K
>> lines of code each. One of the reasons I think that NIF's are so cool
>> is that they really don't require a lot of code to plug in different
>> libraries. So unless the D is really well integrated it most likely
>> wouldn't be worth the hurdle as a user of the NIF.
>>
>> Two ways I can think of to make language embeddings more interesting
>> would be to somehow allow NIF's to create a pid that could send and
>> receive messages in a background thread or to have some sort of
>> automagical dispatch to a thread pool.
>>
>> HTH,
>> Paul Davis
>
>
> --
> Ulf Wiger
> CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd
> http://www.erlang-solutions.com
> ---------------------------------------------------
>
> ---------------------------------------------------
>
> WE'VE CHANGED NAMES!
>
> Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG
> SOLUTIONS LTD.
>
> www.erlang-solutions.com
>
>