Should we just let it crash?
59 views
Skip to first unread message
gmhwxi
Apr 28, 2015, 5:05:00 PM4/28/15
to ats-lan...@googlegroups.com
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 :)
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.
Raoul Duke
Apr 28, 2015, 5:12:59 PM4/28/15
to ats-lang-users
I think an aspect of LiC that is useful food for thought is separation
of concerns.
of concerns.
Brandon Barker
Apr 28, 2015, 5:16:20 PM4/28/15
to ats-lang-users
On Tue, Apr 28, 2015 at 5:05 PM, gmhwxi <gmh...@gmail.com> wrote:
>
> 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 :)
>
> 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
>
> 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 :)
>
> 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.
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:
> • 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!
>
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
Raoul Duke
Apr 28, 2015, 5:30:49 PM4/28/15
to ats-lang-users
>> • 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:
>> 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.
https://duckduckgo.com/?q=waterken+clusterken
gmhwxi
Apr 28, 2015, 7:09:29 PM4/28/15
to ats-lan...@googlegroups.com
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.
Raoul Duke
Apr 28, 2015, 7:12:38 PM4/28/15
to ats-lang-users
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.
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.
gmhwxi
Apr 28, 2015, 9:07:07 PM4/28/15
to ats-lan...@googlegroups.com
I may have misunderstood. I always welcome the chance to learn a few
things :)
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.
things :)
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.
Brandon Barker
Apr 28, 2015, 9:12:32 PM4/28/15
to ats-lang-users
Comic relief: https://youtu.be/nn2FB1P_Mn8
--
Brandon Barker
brandon...@gmail.com
> --
> 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.
> 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
--
Brandon Barker
brandon...@gmail.com
Yannick Duchêne
May 6, 2015, 1:44:31 PM5/6/15
to ats-lan...@googlegroups.com
Is this the transcription of a real talk?
Hongwei Xi
May 6, 2015, 1:46:29 PM5/6/15
to ats-lan...@googlegroups.com
No, it is not. I quoted from his well-known book on Erlang.
--
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.
Reply all
Reply to author
Forward
0 new messages