[erlang-questions] Erlang and the learning curve

[Morten Krogh]

On 1/4/11 8:59 PM, Steve Vinoski wrote:
> 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.
>
Yes, and that is also my point. Because people have think more about 
performance in Erlang than in C or C++ say, profilers and other tools 
are needed
earlier and should be included in a discussion of the difficulty of 
various languages.  Erlang with profilers and tools is a harder 
"language" than Erlang without.

>> 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.
>
Maybe, but why C to start with. Performance must be a big issue here, 
but anyway.

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

I was thinking about the Binary module for example. Isn't that whole 
module just for performance reasons more or less.
I don't have a list of all new BIFs. It was just my understanding that 
every new release would have some new BIFS, that could be
implemented in pure Erlang. What about min and max? Aren't they BIFs?

Anyway, my point in this thread is just that performance matters, and 
when you compare languages you need to include the whole package including
that you some language needs more work on performance than others. I was 
citing NIFs and BIFs etc to claim that other people than me cares about 
performance
in Erlang.

>> 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.
>
Fine, so performance is not your reason to use more than pure Erlang. I 
will still claim that it is for many others.
But it leads to the same conclusion, namely that functional languages 
are not so much easier.
With such interfaces in your code, you are not supporting the notion of 
functional languages being easy, quite on the contrary.


Morten.