Solving the right problem

[I Gusti Ngurah Oka Prinarjaya]

And, if your team feels so desperate to code in Erlang, because of its
weird syntax,
you can use Elixir to utilise ALL of Erlang's power in a more friendly and
easy-to-understand syntax


Pada tanggal Sel, 5 Nov 2019 pukul 11.59 I Gusti Ngurah Oka Prinarjaya <
okaprinarjaya@REDACTED> menulis:

> I recommended you to use Erlang.
>
> Erlang can save you from nowadays complex microservice architecture. If
> you not use Erlang, it will become so so so fckn complex architecture, too
> many external tools to wired and manage.
> Erlang is all in one toolbox.
> You need Redis? Erlang have ETS and or Mnesia,
> You need Consul (services discovery) in order all of your micro-services
> able to communicate to each other? Oh come on.. Erlang is distributed by
> default. you can use rpc:call() or spawn() process in other server, or
> send message RemoteNodePid ! {Your, Message}
>
> ALL tools nowadays are mimicking Erlang's features
>
>
>
> Pada tanggal Sen, 4 Nov 2019 pukul 19.10 Marthin Laubscher <
> marthin@REDACTED> menulis:
>
>> 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.
>>
>>
>>
>> I reckon the problem I’m looking to address is intrinsically concurrent
>> and if I can design the solution just right I just might be able to avoid
>> introducing sequential code and choke points to create an dynamic
>> (learning, responsive to conditions) distributed server capable of using
>> all or most of its resources for any mixture of trivial, simple, complex
>> and massive service requests whether it’s coming from a few clients or
>> billions of them. Essentially as illustrated in the diagram below:
>>
>>
>>
>>
>>
>> I’d like to ask your advice and check some assumptions if I may impose.
>>
>>
>>
>>    1. Is my conviction that Erlang (and OTP) is ideally if not best
>>    suited to addressing this type of problem objectively justified or likely
>>    based on loyalty and familiarity?
>>    2. Is my aspiration to scale the same code from one server to
>>    potentially hundreds of thousands of cores spread across the globe
>>    hopelessly romantic or somewhere within the realm of possibility?
>>    3. Assuming the network remains HTTP/HTTPS based, would Erlang’s
>>    inets module allow the code accepting new requests to interact with and
>>    control load balancing hardware to ensure each such request is served on
>>    the best available server, or will I need custom load balancers of my own
>>    for that?
>>    4. Still assuming HTTP/HTTPS will inets allow me to break up request
>>    processing across multiple processes and threads based on incremental
>>    scanning of the requests themselves?
>>    5. Are there lessons from previous (or current) successes and/or
>>    failures to achieve similar results to learn from available in the public
>>    domain like maybe from ejabberd or Yaws?  (I’m not attempting to reinvent
>>    any wheels or address a general purpose need like Yaws et al. Internet and
>>    web protocols may be involved but I have a singular focus on delivering
>>    user-specific perspectives of a single large dataset to a custom client
>>    app.)
>>
>>
>>
>> Given my two additional objectives of eventually:-
>>
>>    1. ending up with a boringly simple system which elegantly
>>    encapsulates all these complex requirements, and
>>    2. open-sourcing the entire system once it’s beyond reach of those
>>    with nefarious intentions,
>>
>> would anybody like to get involved in helping design and implement this
>> project or even take the lead on it?
>>
>>
>>
>> Thank you in advance for your kind consideration.
>>
>>
>>
>> Warm regards,
>>
>>
>>
>> Marthin Laubscher
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20191105/21ff88f2/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 64024 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20191105/21ff88f2/attachment.png>