3 ms·

I think a few code example would have been nice. The thing I like about concurrency in Elixir is that it's there if you need it but it's mostly not mandatory i

I think a few code example would have been nice. The thing I like about concurrency in Elixir is that it's there if you need it but it's mostly not mandatory in your code, compared to Javascript where its kind of imposed on you even when it's an hindrance. I remember one trick I used to do with LiveView on click events etc was to put all async (or "asyncable") code in a spawn function, which would speed up the return.

freedomben 3y ago
Yes exactly! This is super important for people new to elixir. The vast majority of the time, you don't even need to know that there is even any concurrency. You can write entire sophisticated Phoenix apps and never need it. But when you do eventually need it, it's there and it's wonderful, once you grok the pattern.
- bongobingo1 3y ago
  Yes, I know this is mostly a +1 comment, but this is a huge differentiator from other systems I have worked in where "oh I need concurrency..." becomes a question of what libs, styles, where are the gremlins in the library, where are the state gremlins in our code, etc etc. Vs with Elixir you just sort of go "actually I need two of these. actually I need 200 of these. actually..." and it "just works". Not that there isn't any stuff to learn there, you have to understand how actors pass messages, how you can unintentionally bottle neck via call (caller waits for a reply) vs cast (caller keeps going), etc but its very surprise-free because, surprise surprise, Erlang has been built from the ground up for concurrency and generally worked out how it should work 30 years ago instead of bolting some keywords in.
- spinningslate 3y ago
  Agree. That's a big advantage of thread-based concurrency [0] vs async/await. The decision of whether to do things sequentially or concurrently sits with the caller, not the callee. Which means it's there where you need it and out of the way when you don't. With async/await, the decision is made by a function implementer somewhere down the stack, quite probably in 3rd party code. As the caller you get no choice because coloured functions [1]. You have to deal with concurrency whether your app needs it or not. -- [0] By thread I mean the general concept, not specifically OS threads. In this case it includes the fine-grained processes offered by the BEAM VM that underpins Elixir and Erlang. [1] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
  - zelphirkalt 3y ago
    Is thread-based the right terminology for Erlang's lightweight processes? I guess the pattern is comparable.
  - toast0 3y ago
    Thread-based concurrency is a big part of it, but another nice thing is that mostly synchronous APIs in Erlang are built upon an asynchronous send, followed by an immediate wait. If/when you decide that you don't want the synchronous API, you can usually relatively easily separate the two parts, and process them differently, without having to spawn more threads to do each thing synchronously and then join the threads the way you want. Building on asynchronous sends also makes it conceptually the same to make a local request vs a request on a remote node, although with some additional failure conditions that don't usually make sense to worry about on a single node system.
pawelduda 3y ago
I remember building a Liveview dashboard that eventually had A LOT of things in a table being updated in real time, that the browser tab actually used like 15% of CPU. I implemented batching of websocket updates and added sleep() in interim genserver loop in like 1h... Problem solved, I could just change the sleep value depending on how fast I wanted the updates to happen

freedomben 3y ago

Yes exactly! This is super important for people new to elixir. The vast majority of the time, you don't even need to know that there is even any concurrency. You can write entire sophisticated Phoenix apps and never need it. But when you do eventually need it, it's there and it's wonderful, once you grok the pattern.

bongobingo1 3y ago
Yes, I know this is mostly a +1 comment, but this is a huge differentiator from other systems I have worked in where "oh I need concurrency..." becomes a question of what libs, styles, where are the gremlins in the library, where are the state gremlins in our code, etc etc. Vs with Elixir you just sort of go "actually I need two of these. actually I need 200 of these. actually..." and it "just works". Not that there isn't any stuff to learn there, you have to understand how actors pass messages, how you can unintentionally bottle neck via call (caller waits for a reply) vs cast (caller keeps going), etc but its very surprise-free because, surprise surprise, Erlang has been built from the ground up for concurrency and generally worked out how it should work 30 years ago instead of bolting some keywords in.
spinningslate 3y ago
Agree. That's a big advantage of thread-based concurrency [0] vs async/await. The decision of whether to do things sequentially or concurrently sits with the caller, not the callee. Which means it's there where you need it and out of the way when you don't. With async/await, the decision is made by a function implementer somewhere down the stack, quite probably in 3rd party code. As the caller you get no choice because coloured functions [1]. You have to deal with concurrency whether your app needs it or not. -- [0] By thread I mean the general concept, not specifically OS threads. In this case it includes the fine-grained processes offered by the BEAM VM that underpins Elixir and Erlang. [1] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
- zelphirkalt 3y ago
  Is thread-based the right terminology for Erlang's lightweight processes? I guess the pattern is comparable.
- toast0 3y ago
  Thread-based concurrency is a big part of it, but another nice thing is that mostly synchronous APIs in Erlang are built upon an asynchronous send, followed by an immediate wait. If/when you decide that you don't want the synchronous API, you can usually relatively easily separate the two parts, and process them differently, without having to spawn more threads to do each thing synchronously and then join the threads the way you want. Building on asynchronous sends also makes it conceptually the same to make a local request vs a request on a remote node, although with some additional failure conditions that don't usually make sense to worry about on a single node system.

pawelduda 3y ago

I remember building a Liveview dashboard that eventually had A LOT of things in a table being updated in real time, that the browser tab actually used like 15% of CPU. I implemented batching of websocket updates and added sleep() in interim genserver loop in like 1h... Problem solved, I could just change the sleep value depending on how fast I wanted the updates to happen