[erlang-questions] Erlang newbie questions

[Tim Watson]

>
> Another issue that I've started to think about is deployment. There seem to
> be several competing tools/utilities for this. Is there a preferred or
> recommended solution?
>
>
I think like most platforms (Java, Python, Ruby, etc) this tends to depend
on what people actually prefer to do. At work we have one rule, which is
that deployment has to be fully automated. The data centre guys use puppet
to manage boxes, so we have put together some service definitions that are
always installed on certain "kinds" of machine. In other cases, I've seen
teams deploy using Capistrano and/or Fabric to great effect. The Dukes of
Erl have a solution for putting an Erlang/OTP release into a package
management chain so you can install using apt/yum/etc.

Erlang/OTP provides a very useful concept called a release, which is
essentially a tarball containing everything need to run your
application/stack. This is probably the basic unit of distribution for most
deployments, and can be produced automatically by build tools such as rebar
(shameless plug for my
https://github.com/hyperthunk/rebar_dist_pluginthere). :)


>
> Is the Erlang language itself still evolving? The reason I ask is that the
> fellow that did CouchDB posted a blog entry about the things he encountered
> while developing CouchDB. What was interesting to me is how, even after a
> short time with the language, many of the issues he mentioned immediately
> rang true with me. For example, what is the benefit of the "; , ."
> terminators as opposed to a single terminator approach?
>
>
Whilst the core syntax of the language is unlikely to change in the near
future, many new language features are appearing all the time! The "; , ."
thing got me for a little while, as coming from Python and OCaml I was used
to indentation and block termination keywords (e.g., "end") and of course
the C-like languages that use only ";" everywhere. Nowadays however, not
only am I fully used to the syntax, I actually find it helpful in reading
the code. It really does work as punctuation, and I'm sure there are lots of
ways to improve it but it doesn't need to reduce your productivity as long
as you can get used to it after a while (took me over 6 months writing code
every day to be comfortable without scrutinising too often).

Also beam's abstract code is very trivial to generate, so writing your own
front end to compile down to regular Erlang modules is very plausible. There
is a Lisp Flavoured Erlang project which is super cool and runs on the beam
emulator, and there is a Ruby-like language called Reia (
http://reia-lang.org/). I have no idea whether these projects are fit for
use in a production system, but they certainly demonstrate just what awesome
looking stuff you can build to run on beam. I don't know if these compile
down to erlang modules or have some kind of runtime environment, but either
approach is plausible.

Personally I'd like Erlang to have a syntax like Haskell or OCaml, but I'm
far too busy building functional stuff so I've learned to live with the
existing syntax and now we're old friends.


> I assume a best practice is to minimize the use of modules written in other
> languages. What exactly would the scenario be for a C module that segfaults?
> I assume it would take down the VM.
>
>
Depends on how it's been integrated. There are four ways to integrate C/C++
code today, two of which will not bring down the VM and one of which that
will. They are

1. C Nodes
2. Port Programs
3. Linked-In Drivers
4. Native Implemented Functions

I won't go into all the details here, as the documentation for these is
"quite good" and the good folk on this list are very helpful when you have
specific questions. To boil it down to the essentials, a C node is an
external program that "looks like" a regular Erlang node and communicates
with it's peers using the distribution protocol. If it crashes, it needs to
be restarted but nobody else is hit. A Port Program is also an external
program, which the emulator talks to using pipes/stdio. If it crashes,
nothing else does and it can be restarted.

Linked-in drivers and NIFs are shared libraries, loaded into the beam
process address space and sharing data and flow control with the emulator
itself. If these segfault, they will indeed bring down the whole beam
process.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111018/59fbe06f/attachment.htm>