<div dir="ltr">You are most likely thinking about the AXD301, it was born as an ATM switch. It used an combination of C/C++, Java and Erlang<div><br></div><div>At that time (long time ago) The AXD 301 control system, release 3.2, consisted of roughly:</div><div><div>• 1 million lines of Erlang source code</div><div>• 400,000 lines of C/C++ code</div><div>• 13,000 lines of Java code</div><div><br></div><div>(excluding comments and whitespace)</div><div>In addition, some 500,000 lines of C code reside on device processors. In the control system, about 100,000 lines of C code constitutes 3rd party software which is started, configured and supervised by corresponding (tiny) Erlang programs.</div><div>The above numbers do not include the actual Erlang/OTP product, which contains 240,000 lines of Erlang, 460,000 lines of C/C++ and 15,000 lines of Java.</div></div><div><br></div><div>You can find more details including the numbers above here: <a href="http://www.erlang.se/publications/Ulf_Wiger.pdf">http://www.erlang.se/publications/Ulf_Wiger.pdf</a> </div><div><br></div><div>Thomas</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, 12 Jun 2018 at 21:17 Jesper Louis Andersen <<a href="mailto:jesper.louis.andersen@gmail.com">jesper.louis.andersen@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Jun 12, 2018 at 9:00 PM joe mcguckin <<a href="mailto:joe@via.net" target="_blank">joe@via.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If it was a voice switch, surely they must have used C (or similar) to perform the low-level hardware interfacing stuff like voice transcoding, digitization, etc<br>
<br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>Chances are C is too slow for this operation as well. You usually need either FPGAs or ASICs and then a (thin) C driver layer to interface with the Erlang Control Plane. But I have relatively little knowledge of the actual Ericsson projects and their inner workings.</div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
How easy is it for a  task to fire off a new thread on a different server?<br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>Starting a new process on another Erlang node is rather easy. Calling eg, spawn(Node, Fun) will start running Fun on the node Node (which is usually on a different machine).</div><div><br></div><div>However, in most systems which need this, you tend to build higher-level solutions out of the underlying primitives depending on what kind of fault-guarantees you are looking for and what kind of problem you are trying to solve. Because working at the lowest level requires a lot of attention to the small details which you would like to solve once and for all.</div><div><br></div><div>The reason we tend to say process and not thread is because threads usually implies there is a shared data space all threads can access with locks around data so shared. First, this model is going to break down in a distributed setting (Unless you have direct DMA over the network in a HPC-setting). Second, an Erlang process logically do not share data with each other and owns its own data. The current implementation is very explicit about this, giving each process its own heap, stack and garbage collection. But one could imagine sharing the heap among all processes: because the language is functional, there is no way one process can overwrite the data of another.</div><div><br></div><div>The biggest secret is that data is copied between processes, and usually not passed by reference (except a few types of data). Since messages are often small and since this improves data locality (especially when you are distributed), the overhead of doing so tend to be smaller than what people think it is. This also suggests a model where you tend to move the computation to where the data is, rather than moving the data to the computation.</div></div></div>
_______________________________________________<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/listinfo/erlang-questions</a><br>
</blockquote></div>