Erlang newbie questions

classic Classic list List threaded Threaded
45 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Erlang newbie questions

Gerry Weaver
Hello All,

I am new to Erlang and I'm trying to make the case to continue learning this language. I have read all of the books available and seen several presentations on the language. I am interested in Erlang primarily for the distributed and fault tolerant features it offers. However, I have some reservations about how useful this really is. For example, if you have a network server and the listener process fails, how do you recover? It seems that the fault tolerance is only applicable in the VM context. This is, in my mind equivalent to any other application process. If I have a network server written in C, I can have a watchdog process to kill and/or restart it in the event of failure. The C based approach actually seems more robust. In this scenario, how would one restart the Erlang VM? It has been my experience that network servers most often fail due to OS or hardware limits rather than
bugs in the code (at least for thoroughly tested production ready code). When you factor in the amount of baggage that comes with Erlang, or any other VM based language, it's difficult to justify. Now there is also the rapid development aspect, but I'm finding that at least for now, the time savings is being eaten up by looking for documentation. I understand that this situation will improve over time, but the various posts I've seen from folks with more experience seem to indicate that this will take quite a while. I like the language (except the , ; . thing). You can do some pretty cool things with it, but when I got over that initial gee whiz, I had some trouble seeing a real world production use case. I'm not trying to be critical, I just figure I must have missed something along the way. Any perspectives or advice on this would be greatly appreciated.


Thanks,
-G








Reply | Threaded
Open this post in threaded view
|

Erlang newbie questions

Jesper Louis Andersen
On Mon, Oct 17, 2011 at 23:14, Gerry Weaver <gerryw> wrote:

[...]

> For example, if you have a network server and the listener process fails, how do you recover? It seems that the fault tolerance is only applicable in the VM context. This is, in my mind equivalent to any other application process. If I have a network server written in C, I can have a watchdog process to kill and/or restart it in the event of failure. The C based approach actually seems more robust.

There is a distinct, subtle difference here. C programs tend to be an
all or nothing approach. If there is a mistake in the C server, then
it doesn't matter where that error happen. It can be in the parsing of
a configuration file when you send it a SIGHUP or something such. This
will kill the C server, all its internal state, all undergoing
transactions, all connections currently on the server and more. That
is, either the C program runs and you are happy, or it doesn't run and
you have trouble.

Erlang has, due to process isolation, the ability to subdivide the
server into smaller compartments. An error in one of these will in
general not take down the whole server. Like you say, it is rarely the
listen loop itself which has the error. It is often something else.
Here, Erlang has a built-in mechanism for ditching a wrong or faulty
TCP socket without affecting the other connections. So you can say
that in Erlang systems, it is not an all-or-nothing approach but more
fine grained. The point is that the isolation lets you segment your
program such that errors can not propagate uncontrolled from any
system to any system.

The other subtle difference is that in C, you trade execution speed
for safety. C programs are not safe. They segfault rather than raise
error. Now, if you have the time and effort to build your program
well, it can become robust and stable. But the point is that you will
be able to get to that same level of robustness in Erlang for a
fraction of the effort. And in addition, Erlang programs tend to run
really fast when concurrency and distribution is involved - you need
to beat the Erlang VM, a system with well over 15 years of
optimization.

Finally, there is the point that Erlang is a way better language than
C. C is an excellent language if you need an imperative simple
language. But if you need abstraction, it is notoriously bad. Erlang,
with a proper lambda calculus base, fares much better there.


--
J.


Reply | Threaded
Open this post in threaded view
|

Erlang newbie questions

Kaiduan Xie
In reply to this post by Gerry Weaver
For the network server, if the listener process fails, it gets
restarted by the supervisor, listens on the port again, and only THAT
process is restarted. The other part of the server is not restarted.
In C, you will kill the WHOLE server. Also most of the time, the
listener process does little except blocking and accepting connection,
then spawning another process to do the real work, the chance it gets
restarted is remote.

The learning curve is a little bit long, but Erlang/OTP really shines
for network server. I have written a network server in Erlang, it has
1/4 LOC compared with the C version with the same feature set.

On 10/17/11, Gerry Weaver <gerryw> wrote:

> Hello All,
>
> I am new to Erlang and I'm trying to make the case to continue learning this
> language. I have read all of the books available and seen several
> presentations on the language. I am interested in Erlang primarily for the
> distributed and fault tolerant features it offers. However, I have some
> reservations about how useful this really is. For example, if you have a
> network server and the listener process fails, how do you recover? It seems
> that the fault tolerance is only applicable in the VM context. This is, in
> my mind equivalent to any other application process. If I have a network
> server written in C, I can have a watchdog process to kill and/or restart it
> in the event of failure. The C based approach actually seems more robust. In
> this scenario, how would one restart the Erlang VM? It has been my
> experience that network servers most often fail due to OS or hardware limits
> rather than
> bugs in the code (at least for thoroughly tested production ready code).
> When you factor in the amount of baggage that comes with Erlang, or any
> other VM based language, it's difficult to justify. Now there is also the
> rapid development aspect, but I'm finding that at least for now, the time
> savings is being eaten up by looking for documentation. I understand that
> this situation will improve over time, but the various posts I've seen from
> folks with more experience seem to indicate that this will take quite a
> while. I like the language (except the , ; . thing). You can do some pretty
> cool things with it, but when I got over that initial gee whiz, I had some
> trouble seeing a real world production use case. I'm not trying to be
> critical, I just figure I must have missed something along the way. Any
> perspectives or advice on this would be greatly appreciated.
>
>
> Thanks,
> -G
>
>
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions
> http://erlang.org/mailman/listinfo/erlang-questions
>

--
Sent from my mobile device


Reply | Threaded
Open this post in threaded view
|

Erlang newbie questions

Garrett Smith
In reply to this post by Gerry Weaver
Hi Gerry,

On Mon, Oct 17, 2011 at 4:14 PM, Gerry Weaver <gerryw> wrote:
> I am new to Erlang and I'm trying to make the case to continue learning this language. I have read all of the books available and seen several presentations on the language. I am interested in Erlang primarily for the distributed and fault tolerant features it offers. However, I have some reservations about how useful this really is. For example, if you have a network server and the listener process fails, how do you recover? It seems that the fault tolerance is only applicable in the VM context. This is, in my mind equivalent to any other application process. If I have a network server written in C, I can have a watchdog process to kill and/or restart it in the event of failure. The C based approach actually seems more robust. In this scenario, how would one restart the Erlang VM? It has been my experience that network servers most often fail due to OS or hardware limits rather than
> bugs in the code (at least for thoroughly tested production ready code). When you factor in the amount of baggage that comes with Erlang, or any other VM based language, it's difficult to justify. Now there is also the rapid development aspect, but I'm finding that at least for now, the time savings is being eaten up by looking for documentation. I understand that this situation will improve over time, but the various posts I've seen from folks with more experience seem to indicate that this will take quite a while. I like the language (except the , ; . thing). You can do some pretty cool things with it, but when I got over that initial gee whiz, I had some trouble seeing a real world production use case. I'm not trying to be critical, I just figure I must have missed something along the way. Any perspectives or advice on this would be greatly appreciated.

You typically don't want to use Erlang's supervisory patterns across a
network. As you've observed, those are suited for a single VM.

Fail fast + watch dog patterns are indeed something you can implement
in any language. In Erlang, however, you have a finer level of
granularity of isolation. In a C program, your level of isolation is
the OS process. If that application encounters a fault, you need to
bring the entire OS process down and restart it. In Erlang, your
program can consist of hundreds of Erlang processes (or more) each
completely isolated from one another and free to crash / restart.
Because your level of isolation is more granular, a fault will have
relatively less impact on your system.

To answer your question, your don't restart the Erlang VM. Think of
the Erlang VM as an operating system for code and Erlang processes
like OS processes. It's the same basic architecture, but mapped to
application space.

Erlang's pattern matching semantics will let you write clear "happy
path" code without extra defensive or fail-fast code. In C you need to
constantly check results -- tedious and error prone. In Erlang, you
typically get the assertion for free in patterns like:

  {ok, F} = file:open(...)

Because process supervision comes with Erlang, you don't need
defensive code (e.g. gratuitous exception handlers or case statements)
-- if something unexpected happens, your code blows up, but gets
restarted in a known/clean state.

This results in much, much less code *and* improved fault tolerance!

Since you're new to Erlang, you're going to be more productive in any
other language at the moment. That will certainly change. In my
experience, Erlang is an extremely productive language -- I'll argue
more so than Python or Ruby. Sounds strange, but I've found that to be
the case.

Good luck!

Garrett


Reply | Threaded
Open this post in threaded view
|

Erlang newbie questions

Jachym Holecek-2
In reply to this post by Gerry Weaver
# Gerry Weaver 2011-10-17:
> I am new to Erlang and I'm trying to make the case to continue learning
> this language. I have read all of the books available and seen several
> presentations on the language. I am interested in Erlang primarily for
> the distributed and fault tolerant features it offers.

And you won't be let down on that -- but it takes a while to appreciate
the higher-level engineering aspects of OTP, so don't give up too early.
Given your good theoretical preparations, I'd suggest the next good step
would be to write a non-trivial toy project in Erlang -- after all, it's
a hard fact of nature that actually doing it is the only way to ever
learn anything.

> However, I have
> some reservations about how useful this really is. For example, if you
> have a network server and the listener process fails, how do you recover?

The bright idea is that Erlang/OTP provides you with very natural tools
to address these situations (impenetrable process isolation being the
basis, but you have timeouts for free, links, monitors, etc), but the
exact strategy is inherently application-specific. Popular choice for
dealing with failed communication link would be to schedule reconnect
attempt and revert to hot-spare meanwhile. I suppose MIT X11's mantra,
"mechanism, not policy", applies nicely here (regarding base Erlang/OTP).

> It seems that the fault tolerance is only applicable in the VM context.

Fair observation, it's actually quite reasonable to think of one BEAM
process as an operating system instance of its own -- it happens to run
on top of some UN*X hypervisor typically, and you'd usually arrange for
the BEAM to be restarted on critical failure (much like you'd configure
your OS to automatically restart on kernel panic). Does this make sense?

> This is, in my mind equivalent to any other application process. If I
> have a network server written in C, I can have a watchdog process to kill
> and/or restart it in the event of failure. The C based approach actually
> seems more robust. In this scenario, how would one restart the Erlang VM?

A number of choices -- I know Solaris SMF works, I imagine DJB's supervise
would work too (as exotic as djbware is...). One thing to emphasize here
is that crashing BEAM means one of two things: 1) you didn't provision for
the right kind of flow-control (or rate throttling or ...) mechanisms to
ensure your node fits applicable resource limits -- for this you can only
blame yourself, or 2) you somehow managed to provoke a drastic error in
BEAM (very very very rare, but not unheard of). Either case is really
akin to an OS crash -- a catastrophic, worst-case scenario. Of course,
other nodes talking to the failed one can deal with it gracefully.

> It has been my experience that network servers most often fail due to OS
> or hardware limits rather than bugs in the code

See above, hitting OS/HW limits is just engineer's failure to exert due
diligence to fit within those limits. Hardware failure or operator error
however I couldn't argue with. Also, see below on completely different
scales of software integration you'll meet in Erlang -- that increases
the likelihood of programming error wanting to spoil the party.

> (at least for thoroughly tested production ready code).

[Must suppress the urge to make cynical comments.]

> When you factor in the amount of baggage
> that comes with Erlang, or any other VM based language, it's difficult
> to justify.

I can understand this prejudice, other way to see this is that, much like
an OS, the BEAM is part of your TCB. Any error therein is fatal and you
can't do much about it. One of the services it provides you however is
blank cheque on safety one Erlang process has regardless, for one, of
what other Erlang processes do, but for other regardless of what the
code running in that process does (is allowed to do). The guarantess
given to a UN*X process by OS kernel seem rather lame in comparison.
In my mind, this is definitely worth it.

> Now there is also the rapid development aspect, but I'm
> finding that at least for now, the time savings is being eaten up by
> looking for documentation. I understand that this situation will improve
> over time, but the various posts I've seen from folks with more experience
> seem to indicate that this will take quite a while. I like the language
> (except the , ; . thing).

Yep, there's some learning curve to deal with, but the closer it starts
resembling a constant function, the more unbelievable will your productivity
be -- rolling production-ready solutions once every three weeks is not
complete science-fiction :-). One thing I wanted to mention, and this
is rather random place to do so, is that besides the other advantages
of Erlang/OTP you've already mentioned (or the books you've read surely
did) there's also one people don't talk about very often: high-level
compositionality of sorts -- not at the level of functions or modules,
but whole applications (or application stacks). You have an existing
solution and suddenly are tasked with adding Diameter interface for
charging, a web-based GUI for Operations and SNMP monitoring interface
all at once? Big deal, just add a few protocol stacks to your boot
file, write a few glue-modules exporting existing information to them,
and you're good to go.

> You can do some pretty cool things with it,
> but when I got over that initial gee whiz, I had some trouble seeing a
> real world production use case.

I'd choose Erlang/OTP for anything that requires complex control logic
or gluing together of many networked systems. I'm a bit too tired to
give specific examples at the moment, can fill in tomorrow and others
will surely be eager to provide their own if you're interested.

> I'm not trying to be critical, I just
> figure I must have missed something along the way. Any perspectives or
> advice on this would be greatly appreciated.

That's fine, coming from embedded systems background (the land of C and
asm) I can understand your skepticism... (I know I wouldn't have believed
nice words until I 1) was open-minded enough to listen 2) went on writing
Erlang code for a while).

Hope this slightly wine-infused mail was helpful, or at least completely
harmless. :-)

BR,
        -- Jachym


Reply | Threaded
Open this post in threaded view
|

Erlang newbie questions

Gerry Weaver
Hi,

Wow! I really appreciate your feedback. I find your responses very logical and helpful ;-)?


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?


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?


I don't mean to sound negative here. I'm just poking around a bit. I find Erlang quite compelling overall. I'm digging into the OTP at this point and there are some really interesting capabilities there.?


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.




Thanks,
-G









-----Original Message-----

> From: "Jachym Holecek" <freza>
> To: "Gerry Weaver" <gerryw>
> Cc: erlang-questions
> Date: 10/17/11 17:41
> Subject: Re: [erlang-questions] Erlang newbie questions
>
> # Gerry Weaver 2011-10-17:
> > I am new to Erlang and I'm trying to make the case to continue learning
> > this language. I have read all of the books available and seen several
> > presentations on the language. I am interested in Erlang primarily for
> > the distributed and fault tolerant features it offers.
>
> And you won't be let down on that -- but it takes a while to appreciate
> the higher-level engineering aspects of OTP, so don't give up too early.
> Given your good theoretical preparations, I'd suggest the next good step
> would be to write a non-trivial toy project in Erlang -- after all, it's
> a hard fact of nature that actually doing it is the only way to ever
> learn anything.
>
> > However, I have
> > some reservations about how useful this really is. For example, if you
> > have a network server and the listener process fails, how do you recover?
>
> The bright idea is that Erlang/OTP provides you with very natural tools
> to address these situations (impenetrable process isolation being the
> basis, but you have timeouts for free, links, monitors, etc), but the
> exact strategy is inherently application-specific. Popular choice for
> dealing with failed communication link would be to schedule reconnect
> attempt and revert to hot-spare meanwhile. I suppose MIT X11's mantra,
> "mechanism, not policy", applies nicely here (regarding base Erlang/OTP).
>
> > It seems that the fault tolerance is only applicable in the VM context.
>
> Fair observation, it's actually quite reasonable to think of one BEAM
> process as an operating system instance of its own -- it happens to run
> on top of some UN*X hypervisor typically, and you'd usually arrange for
> the BEAM to be restarted on critical failure (much like you'd configure
> your OS to automatically restart on kernel panic). Does this make sense?
>
> > This is, in my mind equivalent to any other application process. If I
> > have a network server written in C, I can have a watchdog process to kill
> > and/or restart it in the event of failure. The C based approach actually
> > seems more robust. In this scenario, how would one restart the Erlang VM?
>
> A number of choices -- I know Solaris SMF works, I imagine DJB's supervise
> would work too (as exotic as djbware is...). One thing to emphasize here
> is that crashing BEAM means one of two things: 1) you didn't provision for
> the right kind of flow-control (or rate throttling or ...) mechanisms to
> ensure your node fits applicable resource limits -- for this you can only
> blame yourself, or 2) you somehow managed to provoke a drastic error in
> BEAM (very very very rare, but not unheard of). Either case is really
> akin to an OS crash -- a catastrophic, worst-case scenario. Of course,
> other nodes talking to the failed one can deal with it gracefully.
>
> > It has been my experience that network servers most often fail due to OS
> > or hardware limits rather than bugs in the code
>
> See above, hitting OS/HW limits is just engineer's failure to exert due
> diligence to fit within those limits. Hardware failure or operator error
> however I couldn't argue with. Also, see below on completely different
> scales of software integration you'll meet in Erlang -- that increases
> the likelihood of programming error wanting to spoil the party.
>
> > (at least for thoroughly tested production ready code).
>
> [Must suppress the urge to make cynical comments.]
>
> > When you factor in the amount of baggage
> > that comes with Erlang, or any other VM based language, it's difficult
> > to justify.
>
> I can understand this prejudice, other way to see this is that, much like
> an OS, the BEAM is part of your TCB. Any error therein is fatal and you
> can't do much about it. One of the services it provides you however is
> blank cheque on safety one Erlang process has regardless, for one, of
> what other Erlang processes do, but for other regardless of what the
> code running in that process does (is allowed to do). The guarantess
> given to a UN*X process by OS kernel seem rather lame in comparison.
> In my mind, this is definitely worth it.
>
> > Now there is also the rapid development aspect, but I'm
> > finding that at least for now, the time savings is being eaten up by
> > looking for documentation. I understand that this situation will improve
> > over time, but the various posts I've seen from folks with more experience
> > seem to indicate that this will take quite a while. I like the language
> > (except the , ; . thing).
>
> Yep, there's some learning curve to deal with, but the closer it starts
> resembling a constant function, the more unbelievable will your productivity
> be -- rolling production-ready solutions once every three weeks is not
> complete science-fiction :-). One thing I wanted to mention, and this
> is rather random place to do so, is that besides the other advantages
> of Erlang/OTP you've already mentioned (or the books you've read surely
> did) there's also one people don't talk about very often: high-level
> compositionality of sorts -- not at the level of functions or modules,
> but whole applications (or application stacks). You have an existing
> solution and suddenly are tasked with adding Diameter interface for
> charging, a web-based GUI for Operations and SNMP monitoring interface
> all at once? Big deal, just add a few protocol stacks to your boot
> file, write a few glue-modules exporting existing information to them,
> and you're good to go.
>
> > You can do some pretty cool things with it,
> > but when I got over that initial gee whiz, I had some trouble seeing a
> > real world production use case.
>
> I'd choose Erlang/OTP for anything that requires complex control logic
> or gluing together of many networked systems. I'm a bit too tired to
> give specific examples at the moment, can fill in tomorrow and others
> will surely be eager to provide their own if you're interested.
>
> > I'm not trying to be critical, I just
> > figure I must have missed something along the way. Any perspectives or
> > advice on this would be greatly appreciated.
>
> That's fine, coming from embedded systems background (the land of C and
> asm) I can understand your skepticism... (I know I wouldn't have believed
> nice words until I 1) was open-minded enough to listen 2) went on writing
> Erlang code for a while).
>
> Hope this slightly wine-infused mail was helpful, or at least completely
> harmless. :-)
>
> BR,
> ?????-- Jachym
>
>
>
>





Reply | Threaded
Open this post in threaded view
|

Erlang newbie questions

Fred Hebert
Going to reply inline:

On Mon, Oct 17, 2011 at 8:17 PM, Gerry Weaver <gerryw> wrote:

>
>  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?


You've got 3 levels:

1. Rolling out basic Erlang. This is often done by people who do not want or
know how to deal with the OTP framework, up to supervisors and applications.
You'll see basic scripts calling main, scaffoldings of escripts and whatnot.
This isn't something I'd recommend (not that Escript is the problem, but OTP
is a nice way to work with code with the rest of Erlang programmers).

2. OTP Applications are being used. People up to there use OTP applications,
can see dependencies and whatnot, and will manually start everything using
calls to 'application:start(AppName)' in sequence. Again, escripts might be
used here as a way to bootstrap the application. This model is somewhat
sane, everyone can understand it, but might have problems when it comes to
upgrading running code.

3. OTP Releases. They're a bit annoying to figure out. You've got two ways
to package releases: reltools and systools. People will pick one depending
on whatever they find most convenient. In any case, most people will tend to
use tools like rebar to handle them (especially since rebar also handles
downloading dependencies and whatnot). Despite the complexity, releases will
have nice aspects, like automatically handling application dependencies,
starting things for you, safely doing application and release upgrades
(relups). If you're doing it by hand (or using cross-compatible tools),
release building should be cross-compatible with other platforms.

This doesn't mention how to do things like setting up distributed
applications (more work with OTP apps/releases, central connection nodes,
etc.), how people push code on servers (some people use Erlang to send code
to other nodes with the code server and rpc, rsync it, use pulls with source
control, Chef, linux packages, etc.) and a few other things.

Self-advertisement:
OTP Releases: http://learnyousomeerlang.com/release-is-the-word
Relups: http://learnyousomeerlang.com/relups



> 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?
>

Prolog would be the easy answer.

I would however want to correct you. The full stop is a terminator of
Erlang *forms* and others (;,) are *separators for expressions and forms.* I
won't get into too many details. I've decided to write a blog post on this a
year ago because this is such a common complaint:
http://ferd.ca/on-erlang-s-syntax.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111017/cd18ddd8/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Erlang newbie questions

Ulf Wiger (AL/EAB)
In reply to this post by Gerry Weaver

On 17 Oct 2011, at 23:14, Gerry Weaver wrote:

> It has been my experience that network servers most often fail due to OS or hardware limits rather than
> bugs in the code (at least for thoroughly tested production ready code). When you factor in the amount of baggage that comes with Erlang, or any other VM based language, it's difficult to justify.

Gerry,

You have been given other helpful answers from the good people of this list. I thought I'd add something from my own experience writing commercial code in Erlang.

The thing I've noticed about Erlang-based systems is that they tend to mature very well.

I attribute this to a number of things:

== Functional programming style ==

The parts of your code that rely on pure functions (no side-effects) have the nice property that once you have weeded out the bugs, the code *stays correct*, until requirements change. I've seen this in industrial erlang-based systems: they have been robust from the start, but the quality just keeps going up.

== Error handling + programming for the correct case ==

The combo of pattern-matching, purely functional style, and process supervision, further support the notion of writing functions that are correct by design. They do what they are supposed to for expected input, and simply crash for unexpected/invalid input. This style of programming actually works very well as a *default* in Erlang. For extra robustness, one usually needs to trap and handle errors especially in a few places, but that kind of hardening is fairly straightforward, and can be done as incremental improvements.

== Ability to limit the state-event space ==

It's been mentioned that Erlang shines especially for control and coordination scenarios. An important reason is that Erlang allows you to minimise the interference between different components and events. In many design approaches, it is very hard to introduce new protocols or events, as the effects cut across the code in a very bad way. For many systems, this has the effect that they don't mature well. Changes in traffic conditions, hardware and network topologies, and requirements all have a tendency to trigger a new flurry of bugs, due to things happening in a different order than before, or events combining in unexpected ways. I have compared this to the evils of GOTO programming [1].

Given the old rule of thumb that 80% of the lifecycle cost of a system lies in evolution and maintenance, this makes of a pretty formidable advantage.

In one system I worked with, our first release was 4x better than the company norm on faults/KLOC. After a few releases - with significant feature growth - we were 12x better. Code that was corrected for bugs tended to stay correct, and bug fixes normally didn't introduce any new bugs.

A colleague of mine, Mats Cronqvist, once wrote in a workshop paper [2], after having analysed some 150 trouble reports from function- and system testing:

"Most of the errors were not coding errors, but simply a working implementation of the wrong thing." (page 2)

Another way of putting it would be that there are comparatively few "accidental errors" in Erlang-based systems - that is, errors that are a consequence of the implementation technique rather than a misunderstanding of the requirements.

BR,
Ulf W

[1] http://www.infoq.com/presentations/Death-by-Accidental-Complexity
[2] "Troubleshooting a Large Erlang System", Mats Cronqvist, 2004 ACM/SIGPLAN Erlang Workshop
  http://dl.acm.org/citation.cfm?id=1022474
  http://www.erlang.se/workshop/2004/cronqvist.pdf

Ulf Wiger, CTO, Erlang Solutions, Ltd.
http://erlang-solutions.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111018/d3252972/attachment.html>

CGS
Reply | Threaded
Open this post in threaded view
|

Erlang newbie questions

CGS
In reply to this post by Gerry Weaver
Hi,

Interesting discussion here and I would like few points (as C is also my
favorite programming language).

The main point for entering the discussion is the fact that many who
replied here were saying that if something crashes in your application
doesn't kill your application like in C. I beg to differ on this point.
If your Erlang application is single threaded, then your application (I
do not speak here about OTP application) will crash if an error occurs
there. If you construct your C application like an OTP application, then
that means your C applications is multithreaded, so, if one thread dies,
it doesn't crash your main application (as well as in OTP application,
if one gen_server crashes the whole application doesn't crash).

Now, Gerry, think Erlang as being multithread application in C where you
don't need to care too much about how to construct the thread. That
means, the construction of each thread is much simpler and you already
have the monitor (watchdog, if you prefer) part implemented, so, you can
focus on what you want to develop and less on the tools you need.

There are few more aspects here you may want to consider before choosing
in which language you want to write your code.

Firstly, the network applications. In C, due to the lack of standards,
you have to know the compiler in which you want to program a port
listener (as example). In Erlang, you get the standard which is missing
in C. Therefore, the productivity is higher in case of Erlang in this case.

Staying in the field of networking, some may argue that Erlang is not
the only one to be productive here. And that is correct if you consider
JAVA (as one of the main languages capable of creating cross-platform
network applications). Still, I would prefer Erlang for its VM and basic
concepts, and, as C programmer, I think you would understand me why I
prefer each thread to have its own memory (just for example).

Secondly, as desktop application, generally, Erlang is far worse choice
than C. Still, if you don't care too much of the speed of your
application, Erlang offers some nice tools for increasing your
productivity as programmer. Also, due to its capability of interacting
with external functions written in C, you can create your own fast
libraries which you can connect them to Erlang (here you will spend a
little bit of time to understand the concept behind).

Thirdly, concerning the application design. If in C you need to design
your application from A to Z, in Erlang you have tools which limit your
design, but it can increase your overall productivity. Actually, I
consider OTP design as being one of the most useful for general purpose.

I will stop here with the list. You will discover many other advantages
using Erlang during making your own experience with Erlang. I am no
expert in Erlang and many things I am still discovering while
programming in this language. And, for you to see that I bumped into the
same problems, I had also some headaches with the line separators (many
times I got compiling errors due to them). But, in the end, those
separators turned out to be more useful than pain in the... Just for
example, a loop in C when you don't want to use the for statement is
written like this (take it as principle and not as something to be
compiled):

myfunc(myvars)
{
  exit_condition;
the_loop_body;
myfunc(modified_vars);
}

while in Erlang, it is looks like that:

myfunc(myvars) ->
the_loop_body,
myfunct(modified_vars);

myfunc(stop_vars) ->
end_of_loop.

As you can see it's not so different, but you have to implement
explicitly the end of the loop. Quite a pain you may say. Actually,
using this method, think of having two functions with the same name, but
with the language choosing which one to be used depending on what
arguments you pass to it. Doesn't it sound a bit familiar? Yes. And more
than that, you know the advantage of this in practical applications. So,
"two rabbits with a single gun shot" (as there is a saying in my country).

OK! One can speak whole day long about the advantages and disadvantages
of Erlang, but the most important is for you to make your own
experience. So far, my experience with Erlang was positive and I found
myself liking Erlang quite some. I wish your experience with Erlang to
be as good as mine. Just don't forget each language has its own beauty,
but you need to know from which angle you should look at it.

Cheers,
CGS




On 10/18/2011 02:17 AM, Gerry Weaver wrote:

> Hi,
>
> Wow! I really appreciate your feedback. I find your responses very logical and helpful ;-)
>
>
> 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?
>
>
> 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?
>
>
> I don't mean to sound negative here. I'm just poking around a bit. I find Erlang quite compelling overall. I'm digging into the OTP at this point and there are some really interesting capabilities there.
>
>
> 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.
>
>
>
>
> Thanks,
> -G
>
>
>
>
>
>
>
>
>
> -----Original Message-----
>> From: "Jachym Holecek"<freza>
>> To: "Gerry Weaver"<gerryw>
>> Cc: erlang-questions
>> Date: 10/17/11 17:41
>> Subject: Re: [erlang-questions] Erlang newbie questions
>>
>> # Gerry Weaver 2011-10-17:
>>> I am new to Erlang and I'm trying to make the case to continue learning
>>> this language. I have read all of the books available and seen several
>>> presentations on the language. I am interested in Erlang primarily for
>>> the distributed and fault tolerant features it offers.
>> And you won't be let down on that -- but it takes a while to appreciate
>> the higher-level engineering aspects of OTP, so don't give up too early.
>> Given your good theoretical preparations, I'd suggest the next good step
>> would be to write a non-trivial toy project in Erlang -- after all, it's
>> a hard fact of nature that actually doing it is the only way to ever
>> learn anything.
>>
>>> However, I have
>>> some reservations about how useful this really is. For example, if you
>>> have a network server and the listener process fails, how do you recover?
>> The bright idea is that Erlang/OTP provides you with very natural tools
>> to address these situations (impenetrable process isolation being the
>> basis, but you have timeouts for free, links, monitors, etc), but the
>> exact strategy is inherently application-specific. Popular choice for
>> dealing with failed communication link would be to schedule reconnect
>> attempt and revert to hot-spare meanwhile. I suppose MIT X11's mantra,
>> "mechanism, not policy", applies nicely here (regarding base Erlang/OTP).
>>
>>> It seems that the fault tolerance is only applicable in the VM context.
>> Fair observation, it's actually quite reasonable to think of one BEAM
>> process as an operating system instance of its own -- it happens to run
>> on top of some UN*X hypervisor typically, and you'd usually arrange for
>> the BEAM to be restarted on critical failure (much like you'd configure
>> your OS to automatically restart on kernel panic). Does this make sense?
>>
>>> This is, in my mind equivalent to any other application process. If I
>>> have a network server written in C, I can have a watchdog process to kill
>>> and/or restart it in the event of failure. The C based approach actually
>>> seems more robust. In this scenario, how would one restart the Erlang VM?
>> A number of choices -- I know Solaris SMF works, I imagine DJB's supervise
>> would work too (as exotic as djbware is...). One thing to emphasize here
>> is that crashing BEAM means one of two things: 1) you didn't provision for
>> the right kind of flow-control (or rate throttling or ...) mechanisms to
>> ensure your node fits applicable resource limits -- for this you can only
>> blame yourself, or 2) you somehow managed to provoke a drastic error in
>> BEAM (very very very rare, but not unheard of). Either case is really
>> akin to an OS crash -- a catastrophic, worst-case scenario. Of course,
>> other nodes talking to the failed one can deal with it gracefully.
>>
>>> It has been my experience that network servers most often fail due to OS
>>> or hardware limits rather than bugs in the code
>> See above, hitting OS/HW limits is just engineer's failure to exert due
>> diligence to fit within those limits. Hardware failure or operator error
>> however I couldn't argue with. Also, see below on completely different
>> scales of software integration you'll meet in Erlang -- that increases
>> the likelihood of programming error wanting to spoil the party.
>>
>>> (at least for thoroughly tested production ready code).
>> [Must suppress the urge to make cynical comments.]
>>
>>> When you factor in the amount of baggage
>>> that comes with Erlang, or any other VM based language, it's difficult
>>> to justify.
>> I can understand this prejudice, other way to see this is that, much like
>> an OS, the BEAM is part of your TCB. Any error therein is fatal and you
>> can't do much about it. One of the services it provides you however is
>> blank cheque on safety one Erlang process has regardless, for one, of
>> what other Erlang processes do, but for other regardless of what the
>> code running in that process does (is allowed to do). The guarantess
>> given to a UN*X process by OS kernel seem rather lame in comparison.
>> In my mind, this is definitely worth it.
>>
>>> Now there is also the rapid development aspect, but I'm
>>> finding that at least for now, the time savings is being eaten up by
>>> looking for documentation. I understand that this situation will improve
>>> over time, but the various posts I've seen from folks with more experience
>>> seem to indicate that this will take quite a while. I like the language
>>> (except the , ; . thing).
>> Yep, there's some learning curve to deal with, but the closer it starts
>> resembling a constant function, the more unbelievable will your productivity
>> be -- rolling production-ready solutions once every three weeks is not
>> complete science-fiction :-). One thing I wanted to mention, and this
>> is rather random place to do so, is that besides the other advantages
>> of Erlang/OTP you've already mentioned (or the books you've read surely
>> did) there's also one people don't talk about very often: high-level
>> compositionality of sorts -- not at the level of functions or modules,
>> but whole applications (or application stacks). You have an existing
>> solution and suddenly are tasked with adding Diameter interface for
>> charging, a web-based GUI for Operations and SNMP monitoring interface
>> all at once? Big deal, just add a few protocol stacks to your boot
>> file, write a few glue-modules exporting existing information to them,
>> and you're good to go.
>>
>>> You can do some pretty cool things with it,
>>> but when I got over that initial gee whiz, I had some trouble seeing a
>>> real world production use case.
>> I'd choose Erlang/OTP for anything that requires complex control logic
>> or gluing together of many networked systems. I'm a bit too tired to
>> give specific examples at the moment, can fill in tomorrow and others
>> will surely be eager to provide their own if you're interested.
>>
>>> I'm not trying to be critical, I just
>>> figure I must have missed something along the way. Any perspectives or
>>> advice on this would be greatly appreciated.
>> That's fine, coming from embedded systems background (the land of C and
>> asm) I can understand your skepticism... (I know I wouldn't have believed
>> nice words until I 1) was open-minded enough to listen 2) went on writing
>> Erlang code for a while).
>>
>> Hope this slightly wine-infused mail was helpful, or at least completely
>> harmless. :-)
>>
>> BR,
>>       -- Jachym
>>
>>
>>
>>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions
> http://erlang.org/mailman/listinfo/erlang-questions



Reply | Threaded
Open this post in threaded view
|

Erlang newbie questions

Tim Watson
In reply to this post by Gerry Weaver
>
> 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.html>

Reply | Threaded
Open this post in threaded view
|

Erlang newbie questions

Michał Ptaszek
In reply to this post by CGS
On Tue, Oct 18, 2011 at 10:32 AM, CGS <cgsmcmlxxv> wrote:

> Hi,
>
> Interesting discussion here and I would like few points (as C is also my
> favorite programming language).
>
> The main point for entering the discussion is the fact that many who replied
> here were saying that if something crashes in your application doesn't kill
> your application like in C. I beg to differ on this point. If your Erlang
> application is single threaded, then your application (I do not speak here
> about OTP application) will crash if an error occurs there. If you construct
> your C application like an OTP application, then that means your C
> applications is multithreaded, so, if one thread dies, it doesn't crash your
> main application (as well as in OTP application, if one gen_server crashes
> the whole application doesn't crash).

Right but in order to "construct your C application like an OTP
application" means
you will have to re-invent 50% (at a conservative estimate) of the
Erlang run-time.

The deep problem is not making your C application mutithreaded - it's making
it fault-resilient. Mutithreaded C implies some kind of data exchange between
different C threads - now there are many ways to do this - the
cleanest alternative
is by copying message passing. The dirtiest - is by shared memory and mutexes.

Shared memory and mutexes is not where you want to go (willingly).

The deep problem has a deeper problem hiding inside it - memory
fragmentation and reallocation
of pointers. This implies some kind of GC or some kind of static
analysis that is beyond the brain of man
or beast to comprehend.

So what do you do? - you decide to not share memory and let each
process have it's own stack and heap
and you copy everything. Now you've invented 15% of Erlang and are
approximately where we were in 1986.

The tricky bits are deep under the surface - addressing memory
fragmentation and failure. Now simple
things don't need all this stuff - so if you want to write an embedded
washing machine controller write it in C.
But if you want to write a few millions of lines of complex code don't
write it in C. Write the 5% of messy stuff that needs to be fast in C
and write the other 95% in Erlang.

(( This is exactly what Dennis Richie (RIP) said about C and assembler
only with the 5% in assembler))

The productivity gain comes from the fact that it is possible to write
95% of a system in {Erlang, C}
and 5% in {C, Assembler}

Just as in the early days of C some systems should be written entirely
in Assembler, today some systems should be written entirely in C.

What Erlang does is move the goal-posts.

If you're only writing small systems - you won't notice this and C is
fine. But if you want to write systems that run
forever and have a large number of lines of code use Erlang. Try to
write it all in Erlang, if this fails write selected parts in C.

This is actually what you would do in C. Write it all in C and then if
this fails write selected parts in assembler.

All we've done is move the goal posts.

Cheers

/Joe

>
> Now, Gerry, think Erlang as being multithread application in C where you
> don't need to care too much about how to construct the thread. That means,
> the construction of each thread is much simpler and you already have the
> monitor (watchdog, if you prefer) part implemented, so, you can focus on
> what you want to develop and less on the tools you need.
>
> There are few more aspects here you may want to consider before choosing in
> which language you want to write your code.
>
> Firstly, the network applications. In C, due to the lack of standards, you
> have to know the compiler in which you want to program a port listener (as
> example). In Erlang, you get the standard which is missing in C. Therefore,
> the productivity is higher in case of Erlang in this case.
>
> Staying in the field of networking, some may argue that Erlang is not the
> only one to be productive here. And that is correct if you consider JAVA (as
> one of the main languages capable of creating cross-platform network
> applications). Still, I would prefer Erlang for its VM and basic concepts,
> and, as C programmer, I think you would understand me why I prefer each
> thread to have its own memory (just for example).
>
> Secondly, as desktop application, generally, Erlang is far worse choice than
> C. Still, if you don't care too much of the speed of your application,
> Erlang offers some nice tools for increasing your productivity as
> programmer. Also, due to its capability of interacting with external
> functions written in C, you can create your own fast libraries which you can
> connect them to Erlang (here you will spend a little bit of time to
> understand the concept behind).
>
> Thirdly, concerning the application design. If in C you need to design your
> application from A to Z, in Erlang you have tools which limit your design,
> but it can increase your overall productivity. Actually, I consider OTP
> design as being one of the most useful for general purpose.
>
> I will stop here with the list. You will discover many other advantages
> using Erlang during making your own experience with Erlang. I am no expert
> in Erlang and many things I am still discovering while programming in this
> language. And, for you to see that I bumped into the same problems, I had
> also some headaches with the line separators (many times I got compiling
> errors due to them). But, in the end, those separators turned out to be more
> useful than pain in the... Just for example, a loop in C when you don't want
> to use the for statement is written like this (take it as principle and not
> as something to be compiled):
>
> myfunc(myvars)
> {
> ?exit_condition;
> the_loop_body;
> myfunc(modified_vars);
> }
>
> while in Erlang, it is looks like that:
>
> myfunc(myvars) ->
> the_loop_body,
> myfunct(modified_vars);
>
> myfunc(stop_vars) ->
> end_of_loop.
>
> As you can see it's not so different, but you have to implement explicitly
> the end of the loop. Quite a pain you may say. Actually, using this method,
> think of having two functions with the same name, but with the language
> choosing which one to be used depending on what arguments you pass to it.
> Doesn't it sound a bit familiar? Yes. And more than that, you know the
> advantage of this in practical applications. So, "two rabbits with a single
> gun shot" (as there is a saying in my country).
>
> OK! One can speak whole day long about the advantages and disadvantages of
> Erlang, but the most important is for you to make your own experience. So
> far, my experience with Erlang was positive and I found myself liking Erlang
> quite some. I wish your experience with Erlang to be as good as mine. Just
> don't forget each language has its own beauty, but you need to know from
> which angle you should look at it.
>
> Cheers,
> CGS
>
>
>
>
> On 10/18/2011 02:17 AM, Gerry Weaver wrote:
>>
>> Hi,
>>
>> Wow! I really appreciate your feedback. I find your responses very logical
>> and helpful ;-)
>>
>> 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?
>>
>>
>> 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?
>>
>>
>> I don't mean to sound negative here. I'm just poking around a bit. I find
>> Erlang quite compelling overall. I'm digging into the OTP at this point and
>> there are some really interesting capabilities there.
>>
>> 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.
>>
>>
>>
>>
>> Thanks,
>> -G
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>>>
>>> From: "Jachym Holecek"<freza>
>>> To: "Gerry Weaver"<gerryw>
>>> Cc: erlang-questions
>>> Date: 10/17/11 17:41
>>> Subject: Re: [erlang-questions] Erlang newbie questions
>>>
>>> # Gerry Weaver 2011-10-17:
>>>>
>>>> I am new to Erlang and I'm trying to make the case to continue learning
>>>> this language. I have read all of the books available and seen several
>>>> presentations on the language. I am interested in Erlang primarily for
>>>> the distributed and fault tolerant features it offers.
>>>
>>> And you won't be let down on that -- but it takes a while to appreciate
>>> the higher-level engineering aspects of OTP, so don't give up too early.
>>> Given your good theoretical preparations, I'd suggest the next good step
>>> would be to write a non-trivial toy project in Erlang -- after all, it's
>>> a hard fact of nature that actually doing it is the only way to ever
>>> learn anything.
>>>
>>>> However, I have
>>>> some reservations about how useful this really is. For example, if you
>>>> have a network server and the listener process fails, how do you
>>>> recover?
>>>
>>> The bright idea is that Erlang/OTP provides you with very natural tools
>>> to address these situations (impenetrable process isolation being the
>>> basis, but you have timeouts for free, links, monitors, etc), but the
>>> exact strategy is inherently application-specific. Popular choice for
>>> dealing with failed communication link would be to schedule reconnect
>>> attempt and revert to hot-spare meanwhile. I suppose MIT X11's mantra,
>>> "mechanism, not policy", applies nicely here (regarding base Erlang/OTP).
>>>
>>>> It seems that the fault tolerance is only applicable in the VM context.
>>>
>>> Fair observation, it's actually quite reasonable to think of one BEAM
>>> process as an operating system instance of its own -- it happens to run
>>> on top of some UN*X hypervisor typically, and you'd usually arrange for
>>> the BEAM to be restarted on critical failure (much like you'd configure
>>> your OS to automatically restart on kernel panic). Does this make sense?
>>>
>>>> This is, in my mind equivalent to any other application process. If I
>>>> have a network server written in C, I can have a watchdog process to
>>>> kill
>>>> and/or restart it in the event of failure. The C based approach actually
>>>> seems more robust. In this scenario, how would one restart the Erlang
>>>> VM?
>>>
>>> A number of choices -- I know Solaris SMF works, I imagine DJB's
>>> supervise
>>> would work too (as exotic as djbware is...). One thing to emphasize here
>>> is that crashing BEAM means one of two things: 1) you didn't provision
>>> for
>>> the right kind of flow-control (or rate throttling or ...) mechanisms to
>>> ensure your node fits applicable resource limits -- for this you can only
>>> blame yourself, or 2) you somehow managed to provoke a drastic error in
>>> BEAM (very very very rare, but not unheard of). Either case is really
>>> akin to an OS crash -- a catastrophic, worst-case scenario. Of course,
>>> other nodes talking to the failed one can deal with it gracefully.
>>>
>>>> It has been my experience that network servers most often fail due to OS
>>>> or hardware limits rather than bugs in the code
>>>
>>> See above, hitting OS/HW limits is just engineer's failure to exert due
>>> diligence to fit within those limits. Hardware failure or operator error
>>> however I couldn't argue with. Also, see below on completely different
>>> scales of software integration you'll meet in Erlang -- that increases
>>> the likelihood of programming error wanting to spoil the party.
>>>
>>>> (at least for thoroughly tested production ready code).
>>>
>>> [Must suppress the urge to make cynical comments.]
>>>
>>>> When you factor in the amount of baggage
>>>> that comes with Erlang, or any other VM based language, it's difficult
>>>> to justify.
>>>
>>> I can understand this prejudice, other way to see this is that, much like
>>> an OS, the BEAM is part of your TCB. Any error therein is fatal and you
>>> can't do much about it. One of the services it provides you however is
>>> blank cheque on safety one Erlang process has regardless, for one, of
>>> what other Erlang processes do, but for other regardless of what the
>>> code running in that process does (is allowed to do). The guarantess
>>> given to a UN*X process by OS kernel seem rather lame in comparison.
>>> In my mind, this is definitely worth it.
>>>
>>>> Now there is also the rapid development aspect, but I'm
>>>> finding that at least for now, the time savings is being eaten up by
>>>> looking for documentation. I understand that this situation will improve
>>>> over time, but the various posts I've seen from folks with more
>>>> experience
>>>> seem to indicate that this will take quite a while. I like the language
>>>> (except the , ; . thing).
>>>
>>> Yep, there's some learning curve to deal with, but the closer it starts
>>> resembling a constant function, the more unbelievable will your
>>> productivity
>>> be -- rolling production-ready solutions once every three weeks is not
>>> complete science-fiction :-). One thing I wanted to mention, and this
>>> is rather random place to do so, is that besides the other advantages
>>> of Erlang/OTP you've already mentioned (or the books you've read surely
>>> did) there's also one people don't talk about very often: high-level
>>> compositionality of sorts -- not at the level of functions or modules,
>>> but whole applications (or application stacks). You have an existing
>>> solution and suddenly are tasked with adding Diameter interface for
>>> charging, a web-based GUI for Operations and SNMP monitoring interface
>>> all at once? Big deal, just add a few protocol stacks to your boot
>>> file, write a few glue-modules exporting existing information to them,
>>> and you're good to go.
>>>
>>>> You can do some pretty cool things with it,
>>>> but when I got over that initial gee whiz, I had some trouble seeing a
>>>> real world production use case.
>>>
>>> I'd choose Erlang/OTP for anything that requires complex control logic
>>> or gluing together of many networked systems. I'm a bit too tired to
>>> give specific examples at the moment, can fill in tomorrow and others
>>> will surely be eager to provide their own if you're interested.
>>>
>>>> I'm not trying to be critical, I just
>>>> figure I must have missed something along the way. Any perspectives or
>>>> advice on this would be greatly appreciated.
>>>
>>> That's fine, coming from embedded systems background (the land of C and
>>> asm) I can understand your skepticism... (I know I wouldn't have believed
>>> nice words until I 1) was open-minded enough to listen 2) went on writing
>>> Erlang code for a while).
>>>
>>> Hope this slightly wine-infused mail was helpful, or at least completely
>>> harmless. :-)
>>>
>>> BR,
>>> ? ? ?-- Jachym
>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions
>> http://erlang.org/mailman/listinfo/erlang-questions
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions
> http://erlang.org/mailman/listinfo/erlang-questions
>


Reply | Threaded
Open this post in threaded view
|

Erlang newbie questions

Ulf Wiger (AL/EAB)

On 18 Oct 2011, at 11:47, Joe Armstrong wrote:

> Mutithreaded C implies some kind of data exchange between
> different C threads - now there are many ways to do this - the
> cleanest alternative
> is by copying message passing. The dirtiest - is by shared memory and mutexes.

I beg to differ. The dirtiest way is by shared memory *without* mutexes.  ;-)

BR,
Ulf W

Ulf Wiger, CTO, Erlang Solutions, Ltd.
http://erlang-solutions.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111018/59dc8dce/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Erlang newbie questions

Håkan Huss-2
In reply to this post by Tim Watson
On Tue, Oct 18, 2011 at 11:07, Tim Watson <watson.timothy> wrote:

>>
>> 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.

Well, saying that C-like languages use ";" everywhere is a slight
over-simplification. The C standard lists the following punctuators:

[ ]  ( )  { }  .  ->
++  --  &  *  +  -  ~  !
/  %  <<  >>  <  >  <=  >=  ==  !=  ^  |  &&  ||
?  :  ;  ...
=  *=  /=  %=  +=  -=  <<=  >>=  &=  ^=  |=
,  #  ##
<: :>  <% %>  %:  %:%:

Even if we only look at expression/statement separators, the list
would need to include ";" (which is a terminator in most cases, but a
separator in for loop heads), "," (which is used as a separator, but
can be used as a terminator in initializations of e.g., arrays), "?"
and ":" (which are used as separators in a very specific case), "\n"
(which is significant as a terminator in macro definitions) and of
course {} (which are used for grouping except when they are actually
mandated by syntax whether they group something or not, and which may
or may not negate the need for a terminating ";").

To say that C-like languages have simple punctuation is wrong.
(Believe me, I have taught C to students who have no experience with
C-like languages.) You may be used to that punctuation so it feels
natural to you, but simple it is not.

With regards to Erlang I have taught Erlang to beginners as well, so I
know that it is confusing in Erlang as well. But I do not feel it is
harder to learn in Erlang than in C-like languages.

Regards,
/H?kan


Reply | Threaded
Open this post in threaded view
|

Erlang newbie questions

Michał Ptaszek
In reply to this post by Ulf Wiger (AL/EAB)
On Tue, Oct 18, 2011 at 11:53 AM, Ulf Wiger
<ulf.wiger> wrote:

>
> On 18 Oct 2011, at 11:47, Joe Armstrong wrote:
>
> Mutithreaded C implies some kind of data exchange between
> different C threads - now there are many ways to do this - the
> cleanest alternative
> is by copying message passing. The dirtiest - is by shared memory and
> mutexes.
>
> I beg to differ. The dirtiest way is by shared memory *without* mutexes.

You mean ... I didn't know that was possible - I though emacs detected
this and you were instantly
fired and your house set on fire, and your bones melted down for glue
and so on ...

/J


> ?;-)
> BR,
> Ulf W
> Ulf Wiger,?CTO, Erlang Solutions, Ltd.
> http://erlang-solutions.com
>
>
>


Reply | Threaded
Open this post in threaded view
|

Erlang newbie questions

Ulf Wiger (AL/EAB)

On 18 Oct 2011, at 12:20, Joe Armstrong wrote:

> On Tue, Oct 18, 2011 at 11:53 AM, Ulf Wiger
> <ulf.wiger> wrote:
>>
>> On 18 Oct 2011, at 11:47, Joe Armstrong wrote:
>>
>> Mutithreaded C implies some kind of data exchange between
>> different C threads - now there are many ways to do this - the
>> cleanest alternative
>> is by copying message passing. The dirtiest - is by shared memory and
>> mutexes.
>>
>> I beg to differ. The dirtiest way is by shared memory *without* mutexes.
>
> You mean ... I didn't know that was possible - I though emacs detected
> this and you were instantly
> fired and your house set on fire, and your bones melted down for glue
> and so on ?

Like I said? dirty.

I recall an admonition from a seminar on programming for multicore:

"You cannot use priorities for mutual exclusion!"

Presumably, this technique is commonly used, since it was deemed necessary to point out especially that this is not safe on a multicore machine.

http://www.chibios.org/dokuwiki/doku.php?id=chibios:guides:mutual_exclusion_guide#priority_boost

BR,
Ulf

Ulf Wiger, CTO, Erlang Solutions, Ltd.
http://erlang-solutions.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111018/55cf8473/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Erlang newbie questions

Tim Watson
In reply to this post by Håkan Huss-2
On 18 October 2011 11:07, H?kan Huss <huss01> wrote:

> On Tue, Oct 18, 2011 at 11:07, Tim Watson <watson.timothy>
> wrote:
> >>
> >> 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.
>
> Well, saying that C-like languages use ";" everywhere is a slight
> over-simplification. The C standard lists the following punctuators:
>
> [ ]  ( )  { }  .  ->
> ++  --  &  *  +  -  ~  !
> /  %  <<  >>  <  >  <=  >=  ==  !=  ^  |  &&  ||
> ?  :  ;  ...
> =  *=  /=  %=  +=  -=  <<=  >>=  &=  ^=  |=
> ,  #  ##
> <: :>  <% %>  %:  %:%:
>
> Even if we only look at expression/statement separators, the list
> would need to include ";" (which is a terminator in most cases, but a
> separator in for loop heads), "," (which is used as a separator, but
> can be used as a terminator in initializations of e.g., arrays), "?"
> and ":" (which are used as separators in a very specific case), "\n"
> (which is significant as a terminator in macro definitions) and of
> course {} (which are used for grouping except when they are actually
> mandated by syntax whether they group something or not, and which may
> or may not negate the need for a terminating ";").
>
> To say that C-like languages have simple punctuation is wrong.
> (Believe me, I have taught C to students who have no experience with
> C-like languages.) You may be used to that punctuation so it feels
> natural to you, but simple it is not.
>
> With regards to Erlang I have taught Erlang to beginners as well, so I
> know that it is confusing in Erlang as well. But I do not feel it is
> harder to learn in Erlang than in C-like languages.
>
>
I totally agree, it is not simple in C but as you say, very familiar. I
wasn't trying to say that Erlang syntax is hard, just unfamiliar but once I
learned it I actually now find it totally intuitive.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111018/883fd7c1/attachment.html>

CGS
Reply | Threaded
Open this post in threaded view
|

Erlang newbie questions

CGS
In reply to this post by Ulf Wiger (AL/EAB)
Thanks, Joe and Ulf for those comments. Yes, I was missing that part in
expressing my point. In my post, there were just two simple points I
wanted to pass further:
1. one cannot compare a single thread application written in C with
multithread application in Erlang (if you do want to compare, the
comparison should go from multithread Erlang application to multithread
C application);
2. as Joe simplified and I was also mentioning that, one doesn't need to
reinvent Erlang/OTP when you have it already.

Joe, I met cases when those 5% meant a lot (especially in the long time
consuming physics simulations). In those cases, I would still prefer C
to Erlang. But, as I said, each language has its own beauty and you need
to look at it from the correct angle to make the best use of it. I would
still write a game AI in C and not in Erlang or JavaScript (where there
is an attempt based on jQuery). Maybe it's about me, but I still
consider C as being more suitable for that task. On the other hand, as I
said it before, I wouldn't start writing a network application in C when
Erlang provides such simple ways to do it. But these are just examples
and there is much more in each of them. So, it's a matter of what you
need and where each of the languages shows more beauty in approaching
the problem. I wouldn't just discard C yet, but I wouldn't deny the
productivity of Erlang. It's the same case with all the languages: they
came as a need to cover different sectors (and I can give a lot of
examples, but you already know them).

Cheers,
CGS




On 10/18/2011 12:26 PM, Ulf Wiger wrote:

>
> On 18 Oct 2011, at 12:20, Joe Armstrong wrote:
>
>> On Tue, Oct 18, 2011 at 11:53 AM, Ulf Wiger
>> <ulf.wiger
>> <mailto:ulf.wiger>> wrote:
>>>
>>> On 18 Oct 2011, at 11:47, Joe Armstrong wrote:
>>>
>>> Mutithreaded C implies some kind of data exchange between
>>> different C threads - now there are many ways to do this - the
>>> cleanest alternative
>>> is by copying message passing. The dirtiest - is by shared memory and
>>> mutexes.
>>>
>>> I beg to differ. The dirtiest way is by shared memory *without* mutexes.
>>
>> You mean ... I didn't know that was possible - I though emacs detected
>> this and you were instantly
>> fired and your house set on fire, and your bones melted down for glue
>> and so on ?
>
> Like I said? dirty.
>
> I recall an admonition from a seminar on programming for multicore:
>
> "You cannot use priorities for mutual exclusion!"
>
> Presumably, this technique is commonly used, since it was deemed
> necessary to point out especially that this is not safe on a multicore
> machine.
>
> http://www.chibios.org/dokuwiki/doku.php?id=chibios:guides:mutual_exclusion_guide#priority_boost
>
> BR,
> Ulf
>
> Ulf Wiger, CTO, Erlang Solutions, Ltd.
> http://erlang-solutions.com
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions
> http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111018/60c1811d/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Erlang newbie questions

Garrett Smith
In reply to this post by CGS
Hi CGS,

On Tue, Oct 18, 2011 at 3:32 AM, CGS <cgsmcmlxxv> wrote:
>
> The main point for entering the discussion is the fact that many who replied
> here were saying that if something crashes in your application doesn't kill
> your application like in C. I beg to differ on this point. If your Erlang
> application is single threaded, then your application (I do not speak here
> about OTP application) will crash if an error occurs there.

I'm inclined to argue that a "single threaded" application isn't a
valid Erlang app :)

I'll be slightly pedantic here -- just because I think it's worth mentioning...

* When you run "erl" you start an OTP facility -- it's not an optional
feature; it's fundamental to an Erlang system

* A "single threaded" app would presumably be an app that's run using
"erl" with -s or -eval. That'll work for running an application, but
it's not the right way :)

* The right way to run an Erlang app is to create an OTP application
and include that app in a release, which is specified when you run
"erl" with the -boot option

If you run your Erlang application this way, you get all the benefits
people have been describing.

This is admittedly a bit of a bugaboo for me, but I think the
dichotomy that people draw between "Erlang" and "OTP" is overall not
helpful. The so called OTP patterns that are treated as
optional/advanced are fundamental to the way the Erlang runtime is
designed. So I tend to blur the two together into a single "Erlang" :)

I think with some improvements in tooling and documentation, the
headaches associated with using "OTP" will go away, which will be a
huge boon for developers -- especially those new to Erlang.

Garrett


CGS
Reply | Threaded
Open this post in threaded view
|

Erlang newbie questions

CGS
Hi Garrett,

I think you misunderstood me. I specified that "Erlang application" does
not refer to "OTP application". It's true that I haven't specified what
exactly is "Erlang application" in my context, but at least I mentioned
that it's not about "OTP application".

Nevertheless, your remark is correct that "single threaded" application
can barely be considered as Erlang application, but, can anyone say you
are not able to create a single threaded "Erlang application" by the
mean of pure application and not as OTP designed it?

Just to give an example, I created a simple "application" which is not
OTP and I am calling it from YAWS <erl> tag. The "application" (which
consists in a single module with two functions) accepts entries, formats
the entries and sends messages to a server (where I used the full OTP
design). It is an application by definition (it can be used as
independent entity - how you launch it does not matter here - and it has
a specific task) even if it is few lines only. So, that's what I called
"Erlang application" (disregarding what's behind gen_tcp). It is single
threaded, so, here we are at my definition of "single threaded Erlang
application".

I hope I was clear now and I apologize if I created any confusion. If my
post still generates confusions, please, let me know.

Cheers,
CGS




On 10/18/2011 04:27 PM, Garrett Smith wrote:

> Hi CGS,
>
> On Tue, Oct 18, 2011 at 3:32 AM, CGS<cgsmcmlxxv>  wrote:
>> The main point for entering the discussion is the fact that many who replied
>> here were saying that if something crashes in your application doesn't kill
>> your application like in C. I beg to differ on this point. If your Erlang
>> application is single threaded, then your application (I do not speak here
>> about OTP application) will crash if an error occurs there.
> I'm inclined to argue that a "single threaded" application isn't a
> valid Erlang app :)
>
> I'll be slightly pedantic here -- just because I think it's worth mentioning...
>
> * When you run "erl" you start an OTP facility -- it's not an optional
> feature; it's fundamental to an Erlang system
>
> * A "single threaded" app would presumably be an app that's run using
> "erl" with -s or -eval. That'll work for running an application, but
> it's not the right way :)
>
> * The right way to run an Erlang app is to create an OTP application
> and include that app in a release, which is specified when you run
> "erl" with the -boot option
>
> If you run your Erlang application this way, you get all the benefits
> people have been describing.
>
> This is admittedly a bit of a bugaboo for me, but I think the
> dichotomy that people draw between "Erlang" and "OTP" is overall not
> helpful. The so called OTP patterns that are treated as
> optional/advanced are fundamental to the way the Erlang runtime is
> designed. So I tend to blur the two together into a single "Erlang" :)
>
> I think with some improvements in tooling and documentation, the
> headaches associated with using "OTP" will go away, which will be a
> huge boon for developers -- especially those new to Erlang.
>
> Garrett



CGS
Reply | Threaded
Open this post in threaded view
|

Erlang newbie questions

CGS
Oh, yes, there is another confusion I might have created with my post. I
used "OTP application" to refer to behavior(application). Sorry for not
defining everything.

Cheers,
CGS



On 10/18/2011 05:51 PM, CGS wrote:

> Hi Garrett,
>
> I think you misunderstood me. I specified that "Erlang application"
> does not refer to "OTP application". It's true that I haven't
> specified what exactly is "Erlang application" in my context, but at
> least I mentioned that it's not about "OTP application".
>
> Nevertheless, your remark is correct that "single threaded"
> application can barely be considered as Erlang application, but, can
> anyone say you are not able to create a single threaded "Erlang
> application" by the mean of pure application and not as OTP designed it?
>
> Just to give an example, I created a simple "application" which is not
> OTP and I am calling it from YAWS <erl> tag. The "application" (which
> consists in a single module with two functions) accepts entries,
> formats the entries and sends messages to a server (where I used the
> full OTP design). It is an application by definition (it can be used
> as independent entity - how you launch it does not matter here - and
> it has a specific task) even if it is few lines only. So, that's what
> I called "Erlang application" (disregarding what's behind gen_tcp). It
> is single threaded, so, here we are at my definition of "single
> threaded Erlang application".
>
> I hope I was clear now and I apologize if I created any confusion. If
> my post still generates confusions, please, let me know.
>
> Cheers,
> CGS
>
>
>
>
> On 10/18/2011 04:27 PM, Garrett Smith wrote:
>> Hi CGS,
>>
>> On Tue, Oct 18, 2011 at 3:32 AM, CGS<cgsmcmlxxv>  wrote:
>>> The main point for entering the discussion is the fact that many who
>>> replied
>>> here were saying that if something crashes in your application
>>> doesn't kill
>>> your application like in C. I beg to differ on this point. If your
>>> Erlang
>>> application is single threaded, then your application (I do not
>>> speak here
>>> about OTP application) will crash if an error occurs there.
>> I'm inclined to argue that a "single threaded" application isn't a
>> valid Erlang app :)
>>
>> I'll be slightly pedantic here -- just because I think it's worth
>> mentioning...
>>
>> * When you run "erl" you start an OTP facility -- it's not an optional
>> feature; it's fundamental to an Erlang system
>>
>> * A "single threaded" app would presumably be an app that's run using
>> "erl" with -s or -eval. That'll work for running an application, but
>> it's not the right way :)
>>
>> * The right way to run an Erlang app is to create an OTP application
>> and include that app in a release, which is specified when you run
>> "erl" with the -boot option
>>
>> If you run your Erlang application this way, you get all the benefits
>> people have been describing.
>>
>> This is admittedly a bit of a bugaboo for me, but I think the
>> dichotomy that people draw between "Erlang" and "OTP" is overall not
>> helpful. The so called OTP patterns that are treated as
>> optional/advanced are fundamental to the way the Erlang runtime is
>> designed. So I tend to blur the two together into a single "Erlang" :)
>>
>> I think with some improvements in tooling and documentation, the
>> headaches associated with using "OTP" will go away, which will be a
>> huge boon for developers -- especially those new to Erlang.
>>
>> Garrett
>



123