5 ms·

> If you are aggressive then make wrong statements (co-routines not sharing memory) then well you'll get downvoted. My point was that a programmer shouldn't ne

> If you are aggressive then make wrong statements (co-routines not sharing memory) then well you'll get downvoted. My point was that a programmer shouldn't need to share memory to write concurrent code. That statement is not wrong.

rdtsc 12y ago
> That statement is not wrong. Yes it is. Unless you use Erlang or OS processes you are sharing memory. Or rather you not sharing it any more or less than all the other technologies you listed. But I agree with your sentiment in general that shared memory and concurrency are not working well. That is why it is worthwhile learning Erlang if you want to be reliable, fault tolerant concurrent systems. Also nothings stops your from using queues and threads so data is local to each thread and gets copied over the queue.
- laureny 12y ago
  > Unless you use Erlang or OS processes you are sharing memory. Actually, even actor-based systems share memory. If two actors A and B send a message to an actor C and expect a response from it, they are sharing memory: what's in C's state. Which can be different depending on whether C received A's message first or not.
  - rdtsc 12y ago
    > If two actors A and B send a message to an actor C and expect a response from it, they are sharing memory: what's in C's state. Ok in that respect there is just one big pile of shared memory in the whole world, isn't it (maybe except for military air-gaped system). It is the equivalent of saying if A makes an HTTP post to server C the it shares memory. Well ok, I am not sure what you mean by "shared memory", usually it means living in the same heap. So can access it via a pointer or reference.
kasey_junk 12y ago
I think what people are taking exception to, is the difference between abstraction users (programmers who are writing concurrent code) who should be able to use high level concurrency idioms to hide their shared state and abstraction creators (programmers who are writing high level concurrency idioms) who need concurrency primitives to make their abstractions efficient. If we didn't have concurrency primitives, the only high level concurrency idioms we would have would be the ones that made it into the JVM, which is a very slow process.

rdtsc 12y ago

> That statement is not wrong. Yes it is. Unless you use Erlang or OS processes you are sharing memory. Or rather you not sharing it any more or less than all the other technologies you listed. But I agree with your sentiment in general that shared memory and concurrency are not working well. That is why it is worthwhile learning Erlang if you want to be reliable, fault tolerant concurrent systems. Also nothings stops your from using queues and threads so data is local to each thread and gets copied over the queue.

laureny 12y ago
> Unless you use Erlang or OS processes you are sharing memory. Actually, even actor-based systems share memory. If two actors A and B send a message to an actor C and expect a response from it, they are sharing memory: what's in C's state. Which can be different depending on whether C received A's message first or not.
- rdtsc 12y ago
  > If two actors A and B send a message to an actor C and expect a response from it, they are sharing memory: what's in C's state. Ok in that respect there is just one big pile of shared memory in the whole world, isn't it (maybe except for military air-gaped system). It is the equivalent of saying if A makes an HTTP post to server C the it shares memory. Well ok, I am not sure what you mean by "shared memory", usually it means living in the same heap. So can access it via a pointer or reference.

kasey_junk 12y ago

I think what people are taking exception to, is the difference between abstraction users (programmers who are writing concurrent code) who should be able to use high level concurrency idioms to hide their shared state and abstraction creators (programmers who are writing high level concurrency idioms) who need concurrency primitives to make their abstractions efficient. If we didn't have concurrency primitives, the only high level concurrency idioms we would have would be the ones that made it into the JVM, which is a very slow process.