Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unpacking Elixir: Concurrency

underjord.io

Post reply on HN
Print view View original

21–30 of 138 posts

Re: Unpacking Elixir: Concurrency

#21

Post by thibaut_barrere »

out_of_protocol wrote: post #6

Unlike javascript, elixir makes you write synchronous code, e.g. def process_items(items) do items |> Task.async_stream(&Processor.process/1, max_concurrency: 2, timeout: 7000, on_timeout: :kill_task) |> Enum.to_list() end Semantics of regular and concurrent code is the same

Very convenient to parallelise HTTP queries (and without the need to go “evented”).

One recent example where I assert that API responses match our OpenAPI specifications here, for the curious:

https://github.com/etalab/transport-site/pull/3351/files#dif...

Re: Unpacking Elixir: Concurrency

#22

Post by cpursley »

cutler wrote: post #12

The deal-breaker for me with Elixir has always been the lack of real Elixir vectors rather than the crappy Erlang array library. Yes, I know you can use a Map with numeric keys but that's not the same.

Vs which other languages - do you have examples of better patterns?

Re: Unpacking Elixir: Concurrency

#23

Post by peoplefromibiza »

brabel wrote: post #14
cutler wrote: post #12

The deal-breaker for me with Elixir has always been the lack of real Elixir vectors rather than the crappy Erlang array library. Yes, I know you can use a Map with numeric keys but that's not the same.

What would be the difference between a "real vector" and a Map with numeric keys?

Maps are hashtables, Vectors are a contiguous area of memory where each element can be access by index referring to a specific address in that memory.

Vectors are usually also homogeneous about the data they hold, because each element should occupy the same fixed amount of memory, such as i*item_size gievs you back the offset of the element i in memory.

Anyway, in Elixir you can use the Erlang's :array module

Re: Unpacking Elixir: Concurrency

#24

Post by peoplefromibiza »

cpursley wrote: post #22
cutler wrote: post #12

The deal-breaker for me with Elixir has always been the lack of real Elixir vectors rather than the crappy Erlang array library. Yes, I know you can use a Map with numeric keys but that's not the same.

Vs which other languages - do you have examples of better patterns?

all the C family

all the JVM languages

all the .Net languages

Rust

Ruby

Python

etc.

Re: Unpacking Elixir: Concurrency

#25

Post by [deleted] »

jug wrote: post #16

> If I do want to do concurrent work there is the usual async/await mechanisms, implemented in the Task module. Not as weird as in JS. They just return a Task reference which is a helpful abstraction on top of the Process ID or PID. Then you can await on it to get a result or await on multiple to get multiple results. There is also a wicked function called Task.async_stream which will take an enumerable (list, map, s…

[deleted]

Re: Unpacking Elixir: Concurrency

#27

Post by cpursley »

peoplefromibiza wrote: post #24
cpursley wrote: post #22

Earlier quoted context omitted.

Vs which other languages - do you have examples of better patterns?

all the C family all the JVM languages all the .Net languages Rust Ruby Python etc.

Thanks. What's the Ruby example? It's the one I'm most familiar in.

Re: Unpacking Elixir: Concurrency

#28

Post by h0l0cube »

jug wrote: post #16

> If I do want to do concurrent work there is the usual async/await mechanisms, implemented in the Task module. Not as weird as in JS. They just return a Task reference which is a helpful abstraction on top of the Process ID or PID. Then you can await on it to get a result or await on multiple to get multiple results. There is also a wicked function called Task.async_stream which will take an enumerable (list, map, s…

One of those major differences would be that each ‘process’ is incredibly lightweight, and a memory model that allows you to spawn millions of them without having to think about memory allocation or cpu contention

Re: Unpacking Elixir: Concurrency

#29

Post by bongobingo1 »

freedomben wrote: post #13
conradfr wrote: post #3

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…

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.

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.

Post reply on HN