[erlang-questions] Erlang and the learning curve

[Steve Vinoski]

On Tue, Jan 4, 2011 at 1:35 PM, Morten Krogh <mk@REDACTED> wrote:
> On 1/4/11 4:37 PM, Steve Vinoski wrote:
>>
>> On Tue, Jan 4, 2011 at 6:31 AM, Morten Krogh<mk@REDACTED>  wrote:
>>>
>>> Why are one fourth, or whatever, of the posts on this list about nif or c
>>> nodes or ports?
>>
>> Even if we assume your percentage is accurate (which I don't), simply
>> assuming these features are used only for performance reasons is a
>> case of premature optimization. ;-)
>>
>> While some uses of these features involve performance concerns, C
>> nodes, ports, drivers, and NIFs all serve as points for integrating
>> Erlang with other environments. NIFs have already proven themselves
>> particularly useful in this regard. Because of the continued growth in
>> the popularity and application of Erlang, the number of developers
>> interested in using these features to integrate with non-Erlang code
>> is also growing.
>>
>> These are areas of Erlang involving languages other than Erlang, such
>> as C, so it could be they're harder to understand than other parts of
>> the language. It also could be that even with the aforementioned
>> growing popularity of the language, the number of Erlang developers
>> who've ever written C nodes and drivers used in production remains
>> relatively small, and so finding good sources of detailed information
>> about how best to write them is challenging.
>>
>> But still, I'd argue there really aren't that many questions posted
>> here about these features.
>>
>> --steve
>
> My percentage is probably wrong. I didn't count. I just wanted to stress
> that I see quite a lot of performance optimization in Erlang.

As do I, but not by jumping out of Erlang. Using Erlang's profilers
and other tools is very straightforward and can significantly help
improve performance.

> Why were NIFs introduced at all? Why new BIFs all the time? All of that
> could be done in Erlang.

Only the OTP team can say for sure why they introduced NIFs, but my
understanding is that it allows for easier integration with and access
to C than drivers. I personally don't find drivers difficult, but I
know they can be overkill for simple integration needs.

Are new BIFs really being introduced "all the time" strictly for
performance reasons? If so can you cite some examples?

> Steve, I have never seen a NIF that was not performance motivated.
> But you have seen many more NIFs than me.
> Do you have any examples?

I have two NIFs in the system I work on, for example, neither of which
is performance-oriented:

* One NIF allows simple access the Linux UUID library so that my
Erlang code can generate UUIDs the same as the C++ components with
which it interoperates over the internal chassis network. This has
nothing to do with performance and everything to do with consistent
UUID generation across all the components in the chassis.

* The other NIF enables control plane calls to some specialized
offload sockets on our video delivery hardware. The system components
providing these sockets are written in C, so the NIF imports their
header files to pick up all their #defines, constants, and function
prototypes, and then presents that functionality in Erlang in a way
that's natural and simple for the Erlang programmer to use. This NIF
has nothing to do with performance and everything to do with code
coherency, integration with the C code, and minimizing duplication
between Erlang and C.

--steve