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

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

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

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.