vitor_almeida

vitor_almeida

Hello people.

I have only recently been studying Elixir and I hear about how simple it is to work with concurrency in the language. Does this mean that we don’t have to deal with race conditions, deadlocks and other problems? Doesn’t that make me know less about concurrency ?

Showing Posts 1 to 6

dimitarvp

dimitarvp

Not really IMO. It does give you a parallelism / concurrency model to think in that not many other languages support.

NobbZ

NobbZ

You have the same problems, though they are less common due to message passing and immutability.

mindriot

mindriot

In addition to the other points made, because the model for exchanging concurrent data is always explicit it is often the case that it is easier to see that a particular implementation will lead to race conditions or dead locks.

wanton7

wanton7

Elixir uses Erlang VM called BEAM uses processes (actors) that communicate with other processes by message passing and I’ll be calling them actors in rest of this answer.

You can still get race conditions

  1. actor1 keeps state
  2. actor2 and actor3 send message to actor1 that changes state at “same” time
  3. actor4 ask actor1 for state and that state could be state set by actor2 or actor3

But all in all in Elixir’s actor model it’s much simpler to reason about and you don’t usually have same kind concurrency problems you have in other languages. Because actor is running “single threaded” from programmers point of view and have their own memory that other actors can’t access. They communicate with other actors by sending them messages.

So you are still thinking about it but differently.

ityonemo

ityonemo

Race conditions: no. There is nothing that can guard you against race conditions. I would say that vm startup race conditions bite me in the butt once every few months (but I’m really good at recognizing them now, and they are easy to fix in elixir).

Deadlocks: It’s rather hard to write a deadlock in elixir. At least genserver will keep you from writing a call from a process to itself. You could deadlock by calling a process that calls back, but that’s maybe a sign of poor systems design… So I can totally see a noob, especially from oop-land doing this.

Honestly, if anything you’ll get much better at writing correct concurrency patterns because a lot of the boilerplate will be pushed out of the way freeing you to think about the truly hard things like consistency, resiliency, and fault tolerance. In most other concurrent-capable PLs, I’m so exhausted with boilerplate that I can’t bother to think about those issues.

Recently I started implementing code in multithreaded zig and I realized that having worked in elixir “doing the right thing” just came naturally.

OvermindDL1

OvermindDL1

For general race conditions there is nothing that can catch all cases, however languages like Rust do make things like data race conditions impossible. :slight_smile:

— All posts loaded —

Where Next? Top

Trending in Chat/Questions Top

Other Trending Topics Top

garrison
Hobbes is a low-level distributed database for the Elixir programming language. Hobbes provides a simple, safe, and scalable storage lay...
New
mcass19
ExRatatui lets you cook up rich terminal UIs in Elixir, powered by Rust’s ratatui via Rustler NIFs. Build interactive terminal applicatio...
New
Damirados
Hello everyone. After busy few months I am happy to announce v0.1.0 of Emerge & Solve. They are GUI (Emerge) and State management (S...
New
netoum
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New
wintermeyer
There are three potential reasons for members of this forum to have a look at https://vutuv.de You are tired or annoyed of LinkedIn. Yo...
New
webofbits
Aludel - LLM Evaluation Workbench Aludel is an embeddable Phoenix LiveView dashboard for evaluating and comparing LLM prompts across mult...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews