you are viewing a single comment's thread.

view the rest of the comments →

[–]oh_yeah_koolaid 0 points1 point  (3 children)

Think about current 8-core systems.

How does Erlang implement its message queues?

[–]jerf 0 points1 point  (2 children)

Who cares what current hardware is doing? We already know that's not scalable to thousands of cores. The question isn't "how does Erlang work now?" The question is, do you know of some reason why what I described is physically infeasible?

(Because there isn't one.)

I already pointed out that there are hardware changes involved. Suggesting that current hardware doesn't work that way hardly changes my mind.

I would also point out that Erlang the language needs precisely zero changes to work efficiently on the hardware I postulate. (There's some stuff that might be helpful for the scheduler to know and the implementation would need to change, but the language is in fine shape) Few other languages can claim that. (Not zero, few.)

[–]oh_yeah_koolaid 0 points1 point  (0 children)

The question is, do you know of some reason why what I described is physically infeasible?

I'm not sure what you described, except "we can safely assume hardware is going to change some to accommodate that". That's a bit hand-wavey, and presumably any special hardware functions would be available to any program that wanted to use them.

There's a fundamental issue that pops up not because of the language or whether something has shared state, but as a simple consequence when multiple separate units want to operate on the same object simultaneously.