Elxir/Erlang

Just to discuss about Elixir, Erlang, OTP and BEAM

I hear so much of the concurrency advantages of Erlang, but read so little of the detail. From what I've actually read, it doesn't seem too novel. Would someone care to enlighten me?

>>60 >From what I've actually read, it doesn't seem too novel. if using message passing of immutable data in place of thread locking doesnt seem novel to you, then you should just keep using thread locking and dont waste time baiting this thread

I'm no expert here, but basically spawning new processes inside BEAM (the erlang virtual machine) has a relative small cost compared to every other language. Making it more rentable in terms of memory and speed. Besides that, the concurrency model based on actors seems to solve data races and other problems that appear when doing concurrency in general. AFAIK there is nothing about concurrent programming that you could do on erlang/elixir that you could not do in any other language... But erlang was designed specifically for that purpose. I've seem some bechmarks for Phoenix against some mainstream stuff like RoR and Node and it crushes both when handling a lot of requests

However I'm not sure how the concurrent aspects of erlang compares to something like rust

>>64 >AFAIK there is nothing about concurrent programming that you could do on erlang/elixir that you could not do in any other language... this is not /g/, if you dont know what youre talking about, then ask questions and stop spouting your ignorance. Erlang/Elixir is used in message passing systems because all data in Erlang/Elixir is immutable, this is crucial to make concurrency work. Stop pretending know something about this when you know nothing.

Yeah of course inmutability solves a lot of problems. I'm not saying that every other language that supports concurrency has this. I'm just saying that you could do concurrency on several other languages with different concurrency models to solve the same problems, maybe not so easily of course

>>63 There's no need to be hostile. I didn't actually know that it was immutable data that was being passed. I ask because I want to learn more, as there's obviously something special about it. Thanks for the answers.

>>64 >Besides that, the concurrency model based on actors seems to solve data races and other problems that appear when doing concurrency in general. Actors (and immutability) make a large class of bugs impossible, but rather than data races you instead have "message races". Also, there is still some mutable state in the Erlang VM, such as the process registry. I have attached an interesting paper about finding race conditions in Erlang based on randomised scheduling.

Do you believe this kind of stuff has some future? I understand that is a nice approach to neural networks in general but Elixir/Erlang is not as fast for numeric computation.

>>151 >Do you believe this kind of stuff has some future? I understand that is a nice approach to neural networks in general but Elixir/Erlang is not as fast for numeric computation. Yes it has a big future, Erlang/Elixir is the best language there is for distributed processing across server nodes. Haskell, Ocaml, Clojure and Erlang/Elixir is used extensively the finance industry for heavy data processing and number crunching. The reason you dont see it or hear about it more is that they hire mathematicians and physicists to do this kind of programming, your average CS bit twiddler would never be able to handle this kind of programming.

>>179 hmm really? because last time I checked mathematicians and physicists were 'bit twiddling' with python. And I'm not saying elixir will not be used in finance environments, but I really doubt it's there yet, considering its been basically 3 years and those departments have their own langs for doing hft. Ocaml, yes though. >>69 Nope, there /is/ nothing you can do in elixir that you can't do in other langs. Akka? I mean, if I never modify a variable and only copy, then i have immutability, even in c. Ofc, Erlang is designed for this pattern specifically.

>>180 why dont you tell use more about your distributed programming in C and Python scientific number crunching since youre obviously some kind of expert

>>180 Physicist here, yeah basically the people that uses python for numerical computing is because there is a lot of modules for it, from simple stuff like numpy and scipy to tensorflow, theano and friends. If someone wrote some Elixir library to do fast numerical computation in C or rust. It would be better suited for this kind of stuff. What do you think?

>>188 >If someone wrote some Elixir library to do fast numerical computation in C or rust. It would be better suited for this kind of stuff. What do you think? I dont think you understand how data mining works. With pure numerical computations you are just doing a massive amount of calculations that is running toward to total and can throw away all the previous calculations. In data mining you are looking for hidden structure within data and so all calculations means something and are relevant to the results you are looking for. So languages with immutable data allow you to organize and reform data without losing the original data in the process. Functional languages are also closely related to symbolic programming and mathematical logic so that its used to prove the existence of data and real world behavior.

>>191 Not every calculation, for example when you are training a neural net, do you really care about how the cost function is computed on each training step? Of course you are interested on the result of such process, but not on every atomic step of it. I'm not thinking on destroying the beautiful workflow on functional programming by adding some C garbage to the code, just to speed up those repetitive numerical computations that you need to do

>Erlang is, in many ways, the culmination of Smalltalk-style object oriented programming adapted and extended to work over networks and distributed systems. I came across this insight today, and now that I think about it's totally true. The fundamental principle in Smalltalk-style OOP is "send a message to an object, the object decides what to do". That's just the actor pattern! The fundamental principle in Erlang is "send a message to a process, which may be on a different machine, the process decides what to do".