Should we just let it crash?

Google Group
1

I am in the middle of studying the possibility of compiling a portion
of ATS into Erlang. If successful, this would allow us to use ATS+Erlang
for constructing distributed programs. Stay tuned :slight_smile:

Erlang is a very interesting language. No doubt about it. However, I really
felt Joe Armstrong went way too much overboard with his let-it-crash
"philosophy".

Why Crash?

Crashing immediately when something goes wrong is often a very good idea;
in fact, it has several advantages.

• We don’t have to write defensive code to guard against errors; we just
crash.

HX: Well, who is going to save the state? After all, the physical world is
stateful. It’s been that way since the big bang.

• We don’t have to think about what to do; we just crash, and somebody
else will fix the error.

HX: Why would we believe this “somebody” has the silver bullet we don’t
have?

• We don’t make matters worse by performing additional computations
after we know that things have gone wrong.

HX: Who says that performing additional computations is always harmful.
Does this mean that one should just kill oneself if one is ever cut by a
knife accidentally?

• We can get very good error diagnostics if we flag the first place where an
error occurs. Often continuing after an error has occurred leads to even
more errors and makes debugging even more difficult.

HX: I don’t know about other people. I debugged a few Erlang programs, and
I could tell that it was not easy for me!

• When writing error recovery code, we don’t need to bother about why
something crashed; we just need to concentrate on cleaning up afterward.

HX: So that we should just wait for the next crash? What about the wasted
time and energy?

It is often claimed that Erlang-based telephone services are so robust;
they are always
up; they are never down. I think that a much better measurement is the
number of calls that have
been dropped. Up/down is too qualitative.

2

I believe you are misunderstanding and/or the way it is presented can
be misleading or misunderstood. Everybody halfway decent who works on
real code who would advertise LiC would also know all about things
like, oh, say: transactions. Again, e.g. see the Ken protocol.

3

LiC oversimplifies and is oversold.

Say someone implements a server using non-tail-recursion. The server
crashes periodically due to stack overflow. According to LiC, all we need
is essentially to have a monitoring process to bring up the server when it
is down.

In any case, I think that the focus should be on understanding, if possible,
why a crash actually happened.On Tuesday, April 28, 2015 at 5:12:59 PM UTC-4, Raoul Duke wrote:

I think an aspect of LiC that is useful food for thought is separation
of concerns.

4

• We don’t have to write defensive code to guard against errors; we just
crash.
HX: Well, who is going to save the state? After all, the physical world is
stateful. It’s been that way since the big bang.
I guess in some situations you could have a callback to a
checkpoint/restart program, assuming you are happying with running in
C/R … this is a possible compromise.

please everybody see the Ken protocol/design:

5

Comic relief: https://youtu.be/nn2FB1P_Mn8On Tue, Apr 28, 2015 at 9:07 PM, gmhwxi gmh...@gmail.com wrote:

I may have misunderstood. I always welcome the chance to learn a few
things :slight_smile:

Let me quote Joe Armstrong:

Let It Crash
This will sound very strange to you if you come from a language like C. In C
we are taught to write defensive code. Programs should check their arguments
and not crash. There is a very good reason for this in C: writing
multiprocess
code is extremely difficult and most applications have only one process, so
if
this process crashes the entire application, you’re in big trouble.
Unfortunately,
this leads to large quantities of error checking code, which is intertwined
with
the non-error-checking code.

Programs should check their arguments and not crash

My understanding is that checking arguments allows you to have an option:
you
can decide to crash immediately or not crash. I certainly use plenty asserts
in my
code.

There are transactions and there are non-transactions. My main concern is
that
LiC leads to non-performant systems: If it does not work, you just need to
restart.
We certainly do plenty of that to our OSes or browsers.

On Tuesday, April 28, 2015 at 7:12:38 PM UTC-4, Raoul Duke wrote:

I believe you are misunderstanding and/or the way it is presented can
be misleading or misunderstood. Everybody halfway decent who works on
real code who would advertise LiC would also know all about things
like, oh, say: transactions. Again, e.g. see the Ken protocol.

–
You received this message because you are subscribed to the Google Groups
“ats-lang-users” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ats-lang-user...@googlegroups.com.
To post to this group, send email to ats-lan...@googlegroups.com.
Visit this group at http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ats-lang-users/b0df50dd-0969-46f3-a380-a90cdaeadd1b%40googlegroups.com.

Brandon Barker
brandon...@gmail.com

6

I may have misunderstood. I always welcome the chance to learn a few
things :slight_smile:

Let me quote Joe Armstrong:

Let It Crash
This will sound very strange to you if you come from a language like C. In C
we are taught to write defensive code. Programs should check their arguments
and not crash. There is a very good reason for this in C: writing
multiprocess
code is extremely difficult and most applications have only one process, so
if
this process crashes the entire application, you’re in big trouble.
Unfortunately,
this leads to large quantities of error checking code, which is intertwined
with
the non-error-checking code.

Programs should check their arguments and not crash

My understanding is that checking arguments allows you to have an option:
you
can decide to crash immediately or not crash. I certainly use plenty
asserts in my
code.

There are transactions and there are non-transactions. My main concern is
that
LiC leads to non-performant systems: If it does not work, you just need to
restart.
We certainly do plenty of that to our OSes or browsers.On Tuesday, April 28, 2015 at 7:12:38 PM UTC-4, Raoul Duke wrote:

I believe you are misunderstanding and/or the way it is presented can
be misleading or misunderstood. Everybody halfway decent who works on
real code who would advertise LiC would also know all about things
like, oh, say: transactions. Again, e.g. see the Ken protocol.

7

I think an aspect of LiC that is useful food for thought is separation
of concerns.

8

I am in the middle of studying the possibility of compiling a portion
of ATS into Erlang. If successful, this would allow us to use ATS+Erlang
for constructing distributed programs. Stay tuned :slight_smile:

Erlang is a very interesting language. No doubt about it. However, I really
felt Joe Armstrong went way too much overboard with his let-it-crash
“philosophy”.

Why Crash?

Crashing immediately when something goes wrong is often a very good idea;
in fact, it has several advantages.

• We don’t have to write defensive code to guard against errors; we just
crash.

HX: Well, who is going to save the state? After all, the physical world is
stateful. It’s been that way since the big bang.
I guess in some situations you could have a callback to a
checkpoint/restart program, assuming you are happying with running in
C/R … this is a possible compromise.

• We don’t have to think about what to do; we just crash, and somebody
else will fix the error.

HX: Why would we believe this “somebody” has the silver bullet we don’t
have?

• We don’t make matters worse by performing additional computations
after we know that things have gone wrong.

HX: Who says that performing additional computations is always harmful.
Does this mean that one should just kill oneself if one is ever cut by a
knife accidentally?

• We can get very good error diagnostics if we flag the first place where an
error occurs. Often continuing after an error has occurred leads to even
more errors and makes debugging even more difficult.

HX: I don’t know about other people. I debugged a few Erlang programs, and
I could tell that it was not easy for me!

A solaris kernel developer agrees with you:
http://www.reddit.com/r/IAmA/comments/31ny87/i_am_the_cto_of_joyent_the_father_of_dtrace_and/cq3dhd4

• When writing error recovery code, we don’t need to bother about why
something crashed; we just need to concentrate on cleaning up afterward.

HX: So that we should just wait for the next crash? What about the wasted
time and energy?

It is often claimed that Erlang-based telephone services are so robust; they
are always
up; they are never down. I think that a much better measurement is the
number of calls that have
been dropped. Up/down is too qualitative.

–
You received this message because you are subscribed to the Google Groups
“ats-lang-users” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ats-lang-user...@googlegroups.com.
To post to this group, send email to ats-lan...@googlegroups.com.
Visit this group at http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ats-lang-users/c7f53a3f-27c3-4571-9b55-1b0bdea9cd36%40googlegroups.com.

Brandon Barker
brandon...@gmail.com

9

Is this the transcription of a real talk?Le mardi 28 avril 2015 23:05:00 UTC+2, gmhwxi a ĂŠcrit :

I am in the middle of studying the possibility of compiling a portion
of ATS into Erlang. If successful, this would allow us to use ATS+Erlang
for constructing distributed programs. Stay tuned :slight_smile:

Erlang is a very interesting language. No doubt about it. However, I really
felt Joe Armstrong went way too much overboard with his let-it-crash
“philosophy”.

Why Crash?

Crashing immediately when something goes wrong is often a very good idea;
in fact, it has several advantages.

• We don’t have to write defensive code to guard against errors; we just
crash.

HX: Well, who is going to save the state? After all, the physical world is
stateful. It’s been that way since the big bang.

• We don’t have to think about what to do; we just crash, and somebody
else will fix the error.

HX: Why would we believe this “somebody” has the silver bullet we don’t
have?

• We don’t make matters worse by performing additional computations
after we know that things have gone wrong.

HX: Who says that performing additional computations is always harmful.
Does this mean that one should just kill oneself if one is ever cut by a
knife accidentally?

• We can get very good error diagnostics if we flag the first place where
an
error occurs. Often continuing after an error has occurred leads to even
more errors and makes debugging even more difficult.

HX: I don’t know about other people. I debugged a few Erlang programs, and
I could tell that it was not easy for me!

• When writing error recovery code, we don’t need to bother about why
something crashed; we just need to concentrate on cleaning up afterward.

HX: So that we should just wait for the next crash? What about the wasted
time and energy?

It is often claimed that Erlang-based telephone services are so robust;
they are always
up; they are never down. I think that a much better measurement is the
number of calls that have
been dropped. Up/down is too qualitative.

10

No, it is not. I quoted from his well-known book on Erlang.On Wed, May 6, 2015 at 1:44 PM, ‘Yannick Duchêne’ via ats-lang-users < ats-lan...@googlegroups.com> wrote:

Is this the transcription of a real talk?

Le mardi 28 avril 2015 23:05:00 UTC+2, gmhwxi a ĂŠcrit :

I am in the middle of studying the possibility of compiling a portion
of ATS into Erlang. If successful, this would allow us to use ATS+Erlang
for constructing distributed programs. Stay tuned :slight_smile:

Erlang is a very interesting language. No doubt about it. However, I
really
felt Joe Armstrong went way too much overboard with his let-it-crash
“philosophy”.

Why Crash?

Crashing immediately when something goes wrong is often a very good idea;
in fact, it has several advantages.

• We don’t have to write defensive code to guard against errors; we just
crash.

HX: Well, who is going to save the state? After all, the physical world
is
stateful. It’s been that way since the big bang.

• We don’t have to think about what to do; we just crash, and somebody
else will fix the error.

HX: Why would we believe this “somebody” has the silver bullet we don’t
have?

• We don’t make matters worse by performing additional computations
after we know that things have gone wrong.

HX: Who says that performing additional computations is always harmful.
Does this mean that one should just kill oneself if one is ever cut by a
knife accidentally?

• We can get very good error diagnostics if we flag the first place where
an
error occurs. Often continuing after an error has occurred leads to even
more errors and makes debugging even more difficult.

HX: I don’t know about other people. I debugged a few Erlang programs, and
I could tell that it was not easy for me!

• When writing error recovery code, we don’t need to bother about why
something crashed; we just need to concentrate on cleaning up afterward.

HX: So that we should just wait for the next crash? What about the wasted
time and energy?

It is often claimed that Erlang-based telephone services are so robust;
they are always
up; they are never down. I think that a much better measurement is the
number of calls that have
been dropped. Up/down is too qualitative.

–
You received this message because you are subscribed to the Google Groups
“ats-lang-users” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ats-lang-user...@googlegroups.com.
To post to this group, send email to ats-lan...@googlegroups.com.
Visit this group at http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ats-lang-users/618d1801-d653-49b6-a02b-f4f27f8083d5%40googlegroups.com
https://groups.google.com/d/msgid/ats-lang-users/618d1801-d653-49b6-a02b-f4f27f8083d5%40googlegroups.com?utm_medium=email&utm_source=footer
.