<div dir="ltr">A few more comments<div><br></div><div>All code might crash so you have to decide what to do.</div><div><br></div><div>I think of code as belonging to different categories:</div><div><br></div><div>a) Code that if is incorrect will totally screw up your system</div><div>b) Code that if it incorrect will screw up part but not all of your system</div><div>c) Code that if you restart it might work</div><div>d) Code that is in production so it should not crash</div><div>e) Code that is being developed so you expect the odd crash</div><div>    ...</div><div><br></div><div>It's part of the design to figure out which code should be in which category.</div><div><br></div><div>A few years ago, when I was helping build some pretty complex systems</div><div>we did this. What concerned me was the category a) code - this</div><div>is what I called the "error kernel" - a goal was to make this as small</div><div>as possible. This part was written by our most experienced programmers</div><div>and heavily checked.</div><div><br></div><div>Other code in the system had far less stringent requirements on quality.</div><div>For example, Internationalization. Error messages were in English, and we made</div><div>modules  to turn them into different languages.</div><div><br></div><div>This code was not failure-critical - the default strategy if the code failed</div><div>was "revert to English" - so this code was done by our "beginners"</div><div><br></div><div>Part of system design is isolating the error-kernel making it as small as possible</div><div>and getting it implemented by the best programmers.</div><div><br></div><div>All this supervision tree stuff is fine - but you do have to trust</div><div>that the code that implements supervision trees and gen_servers and so on is correct.</div><div><br></div><div>/Joe</div><div><br></div><div><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 28, 2017 at 12:48 PM, Roman Galeev <span dir="ltr"><<a href="mailto:jamhedd@gmail.com" target="_blank">jamhedd@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><div>> We could imagine an intermediate category of calls that are a sort of "pure RPC"</div><div><br></div></span><div>Yeah, I've been thinking of something like that. Anyway, this 'pure RPC' notion could give enough clues to a developer, and to code analyzing tools.</div><img src="https://mltrk.io/pixel/Hm3WyNkdgrFfOYVSU4Dz?rid=Hm3WyNkdgrFfOYVSU4Dz" width="1" height="1" border="0"></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Thu, Sep 28, 2017 at 12:39 PM, zxq9 <span dir="ltr"><<a href="mailto:zxq9@zxq9.com" target="_blank">zxq9@zxq9.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 2017年09月28日 木曜日 12:32:32 you wrote:<br>
> Interesting. Not so strictly speaking, some of the gen_server calls that do<br>
> not change its state may be seen as 'pure' albeit relying on messaging, and<br>
> a tool could probably figure out such calls automatically. And this<br>
> definitely could help to figure out what' going on in a project.<br>
<br>
</span>Perhaps -- but you probably do NOT want a naked call there, because there<br>
is no guarantee the process you called actually exists. Or is on the same<br>
node. Or is calling some external resource not even related to Erlang to<br>
figure out its response.<br>
<br>
We could imagine an intermediate category of calls that are a sort of<br>
"pure RPC", but the utility of this distinction may be pretty limited --<br>
we can't (and shouldn't) know what is going on inside another process.<br>
<br>
Anyway, it is worth exploring the idea, maybe. At the moment I'm looking<br>
at a very limited goal: getting pure declarations to be a real thing. If<br>
I had more time I would formally propose it and work on implementation --<br>
but I have my hands full and a HUGE backlog of other, slightly higher<br>
priority things I think will improve Erlang tooling at a more immediate<br>
level of impact.<br>
<div class="m_-7518314419650650502HOEnZb"><div class="m_-7518314419650650502h5"><br>
-Craig<br>
______________________________<wbr>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/list<wbr>info/erlang-questions</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="">-- <br><div class="m_-7518314419650650502gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">With best regards,<div>     Roman Galeev,</div><div>     <a href="tel:+420%20702%20817%20968" value="+420702817968" target="_blank">+420 702 817 968</a></div></div></div>
</span></div>
<br>______________________________<wbr>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div></div>