4 ms·

I'm well aware of the literature. The fact is that still today, we have millions and millions of lines of code that work in parallel and a crushing majority of

I'm well aware of the literature. The fact is that still today, we have millions and millions of lines of code that work in parallel and a crushing majority of it is operating in mutable languages (C++, Java, Javascript, C#, ...). Pushing immutable languages as the silver bullet to solve concurrency problems is trying to solve a problem that nobody has. We've moved on to higher abstraction grounds (fork join, work stealing, coroutines, etc...), Erlang is still stuck in the past.

di4na 10y ago
That still does not works. I have to maintain that code everyday. It does not work.
toast0 10y ago
I think immutability isn't really that important for concurrency in Erlang, since there's conceptually no shared state between Erlang processes -- if you use the mutable process dictionary, no other process could see it anyway[1]. In reality there is ets which is mutable with locks, and refcounted binaries which become immutable once there's more than one reference. That Erlang forces you to build a shared nothing system is the real win for concurrency. Of course, you can do that with other languages too. > We've moved on to higher abstraction grounds (fork join, work stealing, coroutines, etc...), Erlang is still stuck in the past. Erlang can do fork/join, the schedulers can work steal, and erlang processes are approximately equal to coroutines -- I don't understand what you think is stuck in the past (other than the Prolog like syntax, but you get used to that). Immutability is a big win for garbage collection and memory allocation however, since there are no circular references, mark and sweep isn't required and a simple (generational) copying collector can be used instead. [1] actually you can look at other processes' dictionaries if you want, but that requires a lock on the destination process.

di4na 10y ago

That still does not works. I have to maintain that code everyday. It does not work.

toast0 10y ago

I think immutability isn't really that important for concurrency in Erlang, since there's conceptually no shared state between Erlang processes -- if you use the mutable process dictionary, no other process could see it anyway[1]. In reality there is ets which is mutable with locks, and refcounted binaries which become immutable once there's more than one reference. That Erlang forces you to build a shared nothing system is the real win for concurrency. Of course, you can do that with other languages too. > We've moved on to higher abstraction grounds (fork join, work stealing, coroutines, etc...), Erlang is still stuck in the past. Erlang can do fork/join, the schedulers can work steal, and erlang processes are approximately equal to coroutines -- I don't understand what you think is stuck in the past (other than the Prolog like syntax, but you get used to that). Immutability is a big win for garbage collection and memory allocation however, since there are no circular references, mark and sweep isn't required and a simple (generational) copying collector can be used instead. [1] actually you can look at other processes' dictionaries if you want, but that requires a lock on the destination process.