[erlang-questions] Erlang info

Thomas Elsgaard thomas.elsgaard@REDACTED
Tue Jun 12 21:25:30 CEST 2018

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

At that time (long time ago) The AXD 301 control system, release 3.2,
consisted of roughly:
• 1 million lines of Erlang source code
• 400,000 lines of C/C++ code
• 13,000 lines of Java code

(excluding comments and whitespace)
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.
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.

You can find more details including the numbers above here:


On Tue, 12 Jun 2018 at 21:17 Jesper Louis Andersen <
jesper.louis.andersen@REDACTED> wrote:

> On Tue, Jun 12, 2018 at 9:00 PM joe mcguckin <joe@REDACTED> wrote:
>> 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
> 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.
>> How easy is it for a  task to fire off a new thread on a different server?
> 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).
> 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.
> 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.
> 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.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180612/89eb3ab1/attachment.htm>

More information about the erlang-questions mailing list