Elixir language potential evaluation

The 3 bullet points of your “the problem” sections seems to be well within some of erlang/elixir’s core proposition.
Throw in the excellent Nerves project and I believe you got everything you need to focus your research on.

Thanks for your reply, to be honest i alreeady took a look on the Nerves Project and i got the impression that it is aimed to solve these kind of problems in “smaller” devices so i quickly stopped considering this since in the case of an industrial PC (even with low resources) i was thinking of using Elixir and leveraging the OTP for fault tolerance, i am not sure if i got it wrong here. Good to know that the solutions to the “problem” section seem that could be solved using this ecosystem, although i am trying to see if there are any “good pactices” for projects like these, some system design to help me understand how to properly use the OTP to solve the problems in a correct and future proof way.

For Go there is also this project GitHub - ergo-services/ergo: An actor-based Framework with network transparency for creating event-driven architecture in Golang. Inspired by Erlang. Zero dependencies. · GitHub . That brings OTP features for Go. But you really can’t have process isolation in Go because it uses shared memory model. That makes Erlang/Elixir bit more robust.

Yes i already saw that project some time ago but i was not certain if it is production ready. Also, please forgive my ignorance but from reading the docs of Erlang/Elixir i noticed that most of the strengths reside in the BEAM so the VM is the place that magic happens (connect remotely on a running Instance for debug/inspection or hot code swap) so in theory even if Ergo seems to be production ready, still some of the BEAM features would not be available correct ?

I haven’t used it but my understanding is that it’s production ready. From their GitHub repo https://kaspersky.com , https://www.ringcentral.com and https://lilithgames.com are using it. Sure some BEAM features will be missing. But it seems so compatible with Erlang that you can use some Erlang tools like Observer with it. It will bring things like supervision trees for example that should help with app stability by restarting crashed services. I’ve seen code hotswap talked about quite a bit, but I don’t think almost anyone uses it.

I’m not professional Elixir developer but these things come to mind

Elixir pros

• Immutable
• Process/Memory isolation making it more robust. Process can’t access other processes memory directly.
• Functional language (just functions and data). It being functional might be con as well for hiring people.
• Probably better 99th percentile latency because of memory isolation. If you create a process, do work and exit GC might not even run and memory is released when process exits.
• Better remote inspection and able to run code remotely.
• Single popular web framework called Phoenix. Our company moved from C# to NodeJS/TypeScript, I hate that there are so many different web frameworks with some cons in them all.
• Phoenix LiveView that you can use to create real-time admin interfaces easily.
• Elixir as language has reached point where it’s pretty much ready according to its creator. So it won’t be evolving like C# for example. So you can just focus on building things with it.

Go pros

• Statically typed.
• Better IDE integration because it’s statically typed. My understanding is that JetBrains GoLand IDE is excellent.
• Faster running code.
• Compiles to single binary.
• Quite likely more maintained good quality libraries available.
• Easy to learn. I learned Go fully in one day (before generics) coming from C#.
• Probably easier hiring people

Thanks for the detailed list, yes my findings point to these in one way or another as well and all of these points are excellent. I suppose i can take a second look on the Ergo and see if it could help me in any way.

Golang’s creator’s view that their audience is "not capable of understanding a brilliant language" rubs me the wrong way — YMMV. I’ve also found their writing and messaging to be defensive and irrational. I worked at a household-name software company, and the engineers with experience hated the language.

I found Go very difficult to learn. For example, how to accomplish simple things. How to do application-level multi-threading. How to write safe code, and code defensively. How to write maintainable code. Circa 09/2021, several of these were unsolved problems IMO in Golang.

I started using C# professionally starting from I think version 1.2. Before it had generics. Anyway I knew all about thread safety and other pitfalls that could bite you. So yes even if it was very easy for me to learn, might not be that for others with different background.

I agree with you that in Go you sometimes have to write lot more code to achieve some simple things compared to other languages. It’s partly because Go is very sinple and language wants to have only one way to do a thing. Go not having generics was big part of this problem. But latest Go 1.18 adds generics to the language. It might take a while until libraries catch up. Even core libraries yet don’t seem to have things like generic sort.

I agree. And by making it so simple — in the way Assembly is simple — the designers failed in this goal. There are 100 ways to do any particular thing.

For me it was a programming task along the lines of “Give me a sorted list of the map keys.” Something that’d be one line, 20 characters in Python. In Go, this involved a tedious trip to Stack Overflow and a choice between multiple low-level ways to implement it. Each several lines of un-expressive code.