Um exemplo de uma outra linguagem que é considerada assíncrona e que faz algo que não pode ser reproduzido em JavaScript com suas bibliotecas padrão.
Goroutines, são assincronas de verdade já que são concorrentes, são single-threads e não podem ser reproduzidos em JavaScript com suas bibliotecas padrão apenas emuladas o que torna o desempenho incrívelmente lento
Eu programo em Go, e as goroutines não são executadas em uma única thread. Aqui está a documentação oficial do Go: https://go.dev/doc/effective_go. O segundo parágrafo da seção sobre goroutines:
Goroutines are multiplexed onto multiple OS threads so if one should block, such as while waiting for I/O, others continue to run. Their design hides many of the complexities of thread creation and management.
Esse trecho explica que as goroutines são distribuídas em múltiplas threads do sistema operacional.
Também programo em Go e a real é que depende, Go é inteligente, ele divide as gorrotinas se necessário apenas, você pode ter 100 gorrotinas se nessas 100 nenhuma bloquear a thread principal, go não cria novas thread, inclusive você pode testar com watch ps -o thcount <pid> dependendo de como o código é estruturado esse número não aumenta
Mano, tu tá insistindo em atribuir concorrência à assincronia. Isso está errado.
Você pode até achar que seja melhor que a função assíncrona funcione em paralelo, ou concorrentemente. Mas isso é só a sua opinião. Isso não faz parte do conceito de assíncronia e jamais fará. São conceitos e utilidades diferentes.
Pegue qualquer linguagem que você considere "realmente assíncrona" e coloque para rodar em um processador com um único núcleo de processamento (ou limite o acesso do programa a apenas um núcleo). Você já não consegue mais que o programa seja "realmente concorrente", porque o processador vai executar uma instrução por vez, uma atrás da outra, mesmo que a linguagem simule uma concorrência. Mas ainda assim você pode ter a assincronia, independentemente de quantos núcleos o programa tenha acesso. Porque a assincronia só depende da instrução ser executada (ou resolver) fora da ordem que foi deflagrada.
Segundo a sua definição, um programa "realmente assíncrono" deixaria de sê-lo se ficar limitado a um único núcleo de processamento, mas isso não é verdade, pelo contrário, a única coisa que acontece é que o programa deixa de ser "realmente concorrente".
Veja bem esse exemplo:
let someCounter = 0;
const asyncFunction = async () => await new Promise(resolve => setTimeout( ()=>resolve(someCounter++), 500) );
const theValues =
{
// Recebe 1
async: asyncFunction().then( value => theValues.async = value ),
// Recebe 0
sync: someCounter++,
// Mostra 2
get counter () { return someCounter },
}
setTimeout( () => console.log(theValues), 500 );
A propriedade async é claramente definida antes da propriedade sync, porém esta última recebe 0 do contador enquanto a primeira recebe 1 do contador.
Por que isso acontece? Porque a propriedade async resolve seu valor somente 500ms depois da propriedade sync.
Por mais que o JavaScript tenha uma pilha de execução que ocorre em ordem, isso não impede a assincronia. Faz parte do design da linguagem para manter a ordem. Se você tem dois timers de 1ms definidos imediatamente um após o outro, porque diabos seria interessante que o timer definido por último execute antes do que foi definido primeiro? Na minha opinião, o JavaScript faz muito bem em manter as coisas em ordem.