[erlang-questions] The Beauty of Erlang Syntax

[Richard O'Keefe]

On 27 Feb 2009, at 3:50 pm, Steve Davis wrote:
> Took a quick look at that link to "queue magazine", and they seemed to
> be scratching around a bit to find reasons to pad out their list...

My impression too.
>
>
> First was...
>
> " Concurrency more appropriate to synchronized parallel execution"
>
> I guess that sounds good. But I'd need to see an example of what the
> author actually means to understand and make any judgment as to
> whether it's actually true.

It probably means SSE instructions, or the kind of
stuff you'd use CUDA for.
>
>
> "•  Code requiring an aggressive compiler (Erlang entries in language
> benchmark shoot-outs are unimpressive — except for process spawning
> and message passing) "
>
> Does he mean "serial performance" here. If so see below, as this is at
> the heart of most of the list items.
>
> "•  Floating-point-intensive code"
>
> Most code (in any language) isn't particularly "performance sensitive"
> you gotta measure measure measure. Also, I think the author
> specifically means "serial/linear code performance"... ok, but in
> those rare bottlenecks (and they are rare) where beam/hipe are not
> enough, there's always (easy to make) C ports for your escape
> hatches.

It's really true that Erlang likes to put floats in boxes,
and this really is bad for floating-point-intensive code.
Erlang might well be a great language to write a *correct*
Linear Program solver in, but it certainly wouldn't be the
language of choice for writing a *fast* one.  But then, it
would make engineering sense to ship your problem out to an
existing solver and receive the results back anyway; really
good LP solvers are hard enough to write that one would
rather not.
>
>
> "•  Code requiring nonportable instructions "
>
> Why would you want this? *REQUIRING* when does code (rather than
> managers/architects) *require* non-portability.

See above:  I've seen a galaxy simulation done (mostly) on an
nVIDIA graphics processor.  Really impressive.  And if you need
that kind of speed, you're not going to care that it won't port
to my SunBlade 100.  Rather than galaxy simulation, that author
may have had games in mind.

> "•  Projects to implement libraries that must run under
> other execution environments, such as JVM (Java Vir-
> tual Machine) or CLR (Common Language Runtime) "
>
> I've noticed that Java isn't too good on CLR/Mono or on BEAM, and that
> C# isn't so good on the JVM or BEAM.

To be fair to C#, it _was_ designed to support multiple languages
and _was_ revised after feedback from several non-C# groups, and
it _does_ support F#.
>
> All in all, I find this list pretty unconvincing.

I suspect it's there to prevent accusations of bias, to show
that's the author's given _some_ thought to the idea that Erlang
might not be the perfect language.