(To nitpick: there's a heck of a lot of concurrency, a property of system design, language design, and problem domain, but not much parallelism, a property of the specific VM in use. Smalltalk systems are usually managing interactivity on multiple fronts at the same time.)

Smalltalk "messages" are not asynchronous, but they are also not "good old method calls."

One example of that is that objects handle any message and if it doesn't know how to reply by default (defined in Object class) it raises an error. But this can be redefined (message doesNotUnderstand:) to do anything you want.

Smalltalk supports multicore since the early days, in fact the Blue Book even has some examples for data simulation.

Simulations can be done on one time-sliced processor!

Which main "Smalltalk" are you thinking of when you say "supports multicore since the early days"?

There certainly have been research Smalltalk implementations that do, like:

"Multiprocessor Smalltalk: A Case Study of a Multiprocessor-Based Programming Environment"

https://www.researchgate.net/publication/234768128_Multiproc...

and more complete implementations like Actra and Gemstone/S.

The reference to the Blue Book made it quite obvious.

Thanks for the paper reference.

As for Gemstone I was aware of it. :)

> reference to the Blue Book

So you mean ParcPlace Smalltalk-80 "supports multicore since the early days"?

I think those Smalltalk "processes" are run in the same OS thread and only use one core, so please explain what you mean.

Were you aware of Actra?

After re-reading the Process/ProcessScheduler chapter you are right, it explicitly mentions one VM per CPU.

So from that point I stand corrected, however I would say it was an implementation detail, as the ProcessScheduler could easily have other policies.

> implementation detail

There's an enormous chasm between research experiments:

September 1988 "From Objects to Actors: Study of a Limited Symbiosis in Smalltalk-80"

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41....

:and well-understood techniques supported by all the programming tools.

Thanks for the paper.

> Smalltalk "messages" are good old method calls.

Technically, this is not exactly true. Messages are propagated to superclasses if an objects has no receiver, so they are more messages than method calls.

Also, the design decisions were to make objects an isolated entities which communicate by message passing. They does not have implicit mailboxes like it is in Erlang, and are not strongly-isolated, share-nothing entities (which is what makes the whole system fault-tolerant).

However, objects are definitely has some concurrency, but no async features in modern terms.

> Messages are propagated to superclasses if an objects has no receiver, so they are more messages than method calls.

are they ? this could be implemented with simple vtables and function pointers, without any difference in the case of a function being present or not in the child class case

Oh, my bad. Erlang's processes are actors, not Smalltalk objects, sorry.