Solving the right problem

Jesper Louis Andersen jesper.louis.andersen@REDACTED
Thu Nov 7 15:46:05 CET 2019

On Mon, Nov 4, 2019 at 1:10 PM Marthin Laubscher <marthin@REDACTED>

> Hi everyone,
> 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.
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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 64024 bytes
Desc: not available
URL: <>

More information about the erlang-questions mailing list