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

111–120 of 138 posts

Re: Unpacking Elixir: Concurrency

#111

Post by lionkor »

tombert wrote: post #90
hinkley wrote: post #59

Earlier quoted context omitted.

Any sufficiently complicated distributed program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Erlang

That has definitely been my experience. There's been a good number of times I end up gluing things together with ZeroMQ and SQS and Redis where I start thinking "you know this would have been easier to get an equivalent (or better) product in Erlang". Sadly, I've only ever had one job at a shady startup that used Erlang; I would love to work for a company that sees its power, but sadly it seems that everyone who has…

But go only has 3 or 4 ways you can shoot yourself in the foot at every turn with concurrency! Better than C++, I guess.

Re: Unpacking Elixir: Concurrency

#112

Post by lionkor »

jerf wrote: post #36
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

Node has kind of wrecked the term "synchronous". It convinced many people that "synchronous" also entails "only thing running on the processor at the time" and "if you're 'synchronously' waiting on a file read the entire process is waiting". So when you say "Elixir/Erlang/any threaded language 'makes' you write synchronous code", to the people who most need to hear this, those steeped in the async way of the world, y…

Thats so sad, because any truly parallel workload runs synchronously, on multiple processors, not asynchronously (i.e. on as little as a single processor)

Re: Unpacking Elixir: Concurrency

#113

Post by sarchertech »

giraffe_lady wrote: post #49
throwawaymaths wrote: post #31

Earlier quoted context omitted.

You really shouldn't be using agent for mutable state. Kind of annoying that the docs push you to that. Agent is most useful when you need to tie the transient lifetime of some state with something else (think: compilers). Otherwise, it's generally better to use a database, (or ets, if you need performance), GenServer/gen_statem if you need reactive events attached to the state. Agent is just a wrapper over GenServer…

I love elixir and am very comfortable with functional programming and generally prefer it. But being told you have to write a state machine instead of just += a var is an excellent experience in believing elixir is harder than python.

In reality if you’re just trying to += a variable, you’d use reduce (if you couldn’t use one of the built in functions).

Re: Unpacking Elixir: Concurrency

#115

Post by throwawaymaths »

davydog187 wrote: post #42
throwawaymaths wrote: post #35

Earlier quoted context omitted.

I'm pretty sure erlangs :array is just a skin over tuple, so it's ~O(1) but not contiguous. might be O(log n) for dynamic arrays. The only truly array datatype in Erlang is :atomics

Erlang tuples are contiguous in memory for primitive values https://blog.edfine.io/blog/2016/06/28/erlang-data-represent...

Array doesn't guarantee to be put into a single tuple. It might be nested.

Re: Unpacking Elixir: Concurrency

#116

Post by cutler »

toast0 wrote: post #99
cutler wrote: post #92

Earlier quoted context omitted.

Same things arrays are used for in all mainstream languages ie. index-based access.

You want tuples. They've got index-based access, and all your useful things in erlang:element/2, setelement/3, append_element/3, delete_element/2, insert_element/3. With a big caveat that modifying tuples isn't great for performance unless the compiler or optimizer determine that mutating the tuple is acceptable rather than providing a mutated copy.

I understood tuples are only optimised for a handful of elements.

Re: Unpacking Elixir: Concurrency

#117

Post by heisenbugs »

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.

You can achieve a similar goal with the Akka framework on the JVM (functionally native with Scala). Uses the actor model and message passing for every concurrency goal achieved by Elixir. AND you can bundle in all your existing jars if the Java world matters to you.

Re: Unpacking Elixir: Concurrency

#118

Post by throwawaymaths »

cutler wrote: post #116
toast0 wrote: post #99

Earlier quoted context omitted.

You want tuples. They've got index-based access, and all your useful things in erlang:element/2, setelement/3, append_element/3, delete_element/2, insert_element/3. With a big caveat that modifying tuples isn't great for performance unless the compiler or optimizer determine that mutating the tuple is acceptable rather than providing a mutated copy.

I understood tuples are only optimised for a handful of elements.

This is correct. If you want a true array experience you have to use atomics or a nif.

Re: Unpacking Elixir: Concurrency

#119

Post by cultofmetatron »

fndex wrote: post #71
cultofmetatron wrote: post #67

Earlier quoted context omitted.

well my startup uses distributed elixir. we use it horde to distribute certain long lived processes accross our cluster. that does not exclusive to kuernetes. we user kubernetes to manage and handle vm crashes (its only happened twice ever) as well as porvide consistent network toplogy between the nodes. that said, having the ability to send messages between machines without having to bring in an external dependency…

Could you explain a bit more how you are using it?

our payment processor requires a persistent connection to their server for each of our clients. we use horde to make sure there's only one process responsible for each paying user accross our cluster.

Re: Unpacking Elixir: Concurrency

#120

Post by sb8244 »

throwawaymaths wrote: post #34
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.

So what do you use real arrays for? For 80% of programming lists are just fine. Are you doing cpu-bound numerical calculations?

The only time I've hit this is when implementing algorithms that assume constant time access and modification (a lot of algorithms assume this, and can't be swapped for index based maps easily)

This occurred somewhat recently when implementing stable topological sort. I ended up swapping List out for a Vector (Aja is library I used). I received a 100x performance improvement from it.

That's really the only time I've truly hit a List performance roadblock in 7+ years of Elixir.

Post reply on HN