[erlang-questions] suggestion: NIF_D

[Paul Davis]

On Tue, Apr 20, 2010 at 3:41 AM, Ulf Wiger
<ulf.wiger@REDACTED> wrote:
> Last week I was at the ACCU 2010 conference in Oxford, and
> had a short discussion with Walter Bright, the inventor of D.
> The discussion briefly touched the ErlOCaml project, and the
> idea that one would like to have the option to drop into a
> "safe" low-level language from Erlang. Walter (perhaps un-
> surprisingly) suggested that D might be a suitable candidate.
>
> I hadn't looked closer at D - only noted that it tended to
> do very well in the shootout (no more, it seems, as I couldn't
> find it there at all now). However, it does look very nice and
> accessible to C programmers:
>
> http://www.digitalmars.com/d/2.0/ctod.html
>
> Safety would come partly from the fact that it's a garbage-
> collected language, and partly because it fixes many of the
> idiosynchracies of C and C++.
>
> Another nice aspect of D is that it is designed to be
> relatively easy to analyse lexically, and compiles very
> quickly. This seems to open up for some fairly funky inlining
> or JIT code generation, but perhaps we're getting ahead of
> ourselves here...
>
> However, I realise that I spend far too little time coding
> C et al to be the one to try this integration, or indeed
> even to judge whether it would be worthwhile to do so.
>
> Any other takers? Opinions?
>
> BR,
> Ulf W
> --
> 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
>
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>

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