Hacker News Reader

Comment by scott_s | Hacker News Reader

You're getting downvoted because your post is "middlebrow dismissal" (https://news.ycombinator.com/item?id=5072224) which is also unnecessarily aggressive. It's quite possible for someone to know exactly what you are talking about, and still downvote it.

Regarding the technical points, having low-level mechanisms for fine-grained synchronization between threads (such as these) does not prevent you from also providing high-level mechanisms for parallelism and concurrency. In fact, it enables others to develop such abstractions in that language in question, without relying on the language itself to provide them.

View on HN

> unnecessarily aggressive

Aggression that's really the result of thread frustration in Java. I hadn't read about middlebrow dismissal before, I can see how my post came off wrong. I'm glad I posted what I said however, because I the responses taught me new things.

I think you can be aggressive (heck look at Linus) but it has to be substantiate by in detail knowledge and arguments. If you are aggressive then make wrong statements (co-routines not sharing memory) then well you'll get downvoted. I guess take that as life advice in general.

> 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.

> 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.

> 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.

> 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.

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.

Reply on news.ycombinator.com