<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif">On Mon, Nov 4, 2019 at 1:10 PM Marthin Laubscher <<a href="mailto:marthin@lobeshare.co.za">marthin@lobeshare.co.za</a>> wrote:</span><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-57278560599484759WordSection1"><p class="MsoNormal"><span style="font-size:11pt">Hi everyone,<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">Please pardon my long absences from this awesome (mature) community and my limited knowledge which is likely outdated as well. I’ve known since 1996 when I was first told (in confidence by an Ericsson Radio Systems liaison) about Erlang that it would have to play a role when I eventually get to implementing the system I’ve been working on designing since 1991. That big day is drawing near, so now I’d like to reaffirm my high level understanding of what the language is suited for.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt"><u></u></span></p></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">If you have been working on this design since 1991, I would recommend you start some experiments into parts of the design. You can often simulate a large amount of devices, and you can also simulate the server side. If there are multiple servers involved, solving the problem in the small scale is often useful: you get to learn about some of the small-scale problems of the design right away. As you scale such a system up, you will run into trouble that has to be solved. But often such solutions stem from the smaller scale ideas you tackled first.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">At scale, I claim any system breaks down. The real work starts when you reach that level. Almost any web server technology has a breaking point, and you will hit it sooner or later. Erlang has a breaking point and you will hit it sooner or later. It also depends on the nature of the problem you are trying to solve. If you are looking at number crunching, I'd definitely design a hybrid where that is outsourced to some other language suited for fast execution. On the other hand, if you are looking at a problem where you have massive concurrency, you might get away with Erlang or Go. If you add the requirement of robustness on top, at a fine granular level, then I know no other thing than the Erlang stack which can do it. Other languages achieve robustness by containerization of computation and then restarting faulty containers. Yet, the disadvantage of such a method are that errors in such systems can "bleed" to sibling requests. This might not be suitable, depending on the problem at hand.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">But you really need to start experiments. It is almost impossible to design a software system without the duality of design and implementation helping each other along. That is, design leads to partial implementation. Partial implementation leads to insights. And insights leads to a better design. Over time, it is often the case the design shrinks to a fundamental core. You want that as small as possible as it makes it understandable.</div><br></div></div></div>