4 ms·

Everything I've ever heard on that front is that Erlang should be considered a control layer which has any CPU-bound tasks run in C. Actors/message passing is a

by hderms 10y ago

Everything I've ever heard on that front is that Erlang should be considered a control layer which has any CPU-bound tasks run in C. Actors/message passing is a good synchronization primitive but there is apparently a whole host of issues with memory leaks regarding it in the "Erlang in Anger" e-book. I personally lost interest in Erlang because of it only supporting actors as a concurrency mechanism. They're good for some things, and probably exceptionally good at what Erlang was designed for (Telecom systems), but I think they're just one tool in the toolbox. If the recommended solution for CPU-bound tasks is to start writing C, I have to wonder if there's a better way.

staticassertion 10y ago
What concurrency patterns have you found yourself unable to express using actors?
qaq 10y ago
Well short answer long term it's the only viable model you are not going to use locking and STW gc on 500+ core system with few TBs of RAM.
- ianopolous 10y ago
  Lock based concurrency is perfectly fine on 800 core systems with a pauseless gc and many TiB heaps. See Azul for an example using the JVM.
toast0 10y ago
Memory leak isn't quite the right word for what I think you're referring to: processes that most forward binaries without generating enough garbage on their own heap did not trigger garbage collection, leading to too much memory being used. This behavior is better in recent releases (otp 19), the space used by binaries is added to the per process accounting so that it can trigger garbage collection. I agree, if you don't fit into the actor pattern, erlang is probably not a great choice, although the bit syntax is pretty nice, too. Sometimes you can leverage erlang for distribution and supervision and drive the c code; but sometimes it's just not a good fit.
pmarreck 10y ago
I second the question of wondering what sort of concurrency is not well-serviced by the actor model? (especially considering you have zero locking to worry about)

by hderms 10y ago

staticassertion 10y ago

What concurrency patterns have you found yourself unable to express using actors?

qaq 10y ago

Well short answer long term it's the only viable model you are not going to use locking and STW gc on 500+ core system with few TBs of RAM.

ianopolous 10y ago
Lock based concurrency is perfectly fine on 800 core systems with a pauseless gc and many TiB heaps. See Azul for an example using the JVM.

toast0 10y ago

Memory leak isn't quite the right word for what I think you're referring to: processes that most forward binaries without generating enough garbage on their own heap did not trigger garbage collection, leading to too much memory being used. This behavior is better in recent releases (otp 19), the space used by binaries is added to the per process accounting so that it can trigger garbage collection. I agree, if you don't fit into the actor pattern, erlang is probably not a great choice, although the bit syntax is pretty nice, too. Sometimes you can leverage erlang for distribution and supervision and drive the c code; but sometimes it's just not a good fit.

pmarreck 10y ago

I second the question of wondering what sort of concurrency is not well-serviced by the actor model? (especially considering you have zero locking to worry about)