Executando verificação de segurança...
-2

Como o próprio ChatGPT resumiu aqui

ChatGPT não é uma boa fonte porque ele se baseia em mistura de textos, por exemplo:

Em JavaScript, "assíncrono" refere-se a operações que são executadas de forma não bloqueante, permitindo que o código continue a ser executado enquanto se espera que uma operação termine.

Javascript realmente bloqueia a execução, é preciso descer o nível pra entender:

console.log("Inicio");
setInterval(() => {
  console.log("Meio");
}, 500);
console.log("Fim");

O que a linguagem está fazendo?

imprime: Inicio
coloca: console.log("Meio"); na fila de espera para cada 500ms
imprime: Fim

Note que "coloca:" é uma ação rápida, ela bloqueia a execução mas por um tempo muito pequeno (de 1 a 4ms a depender da implementação) Quando chega em imprime Fim ele faz uma busca na fila de espera, qual a próxima coisa a ser executada? Vai ter algo mais ou menos assim:

console.log("Meio");
setInterval(() => {
  console.log("Meio");
}, 500);

Então ele vai interpretar assim:

imprime: Meio
coloca: console.log("Meio"); na fila de espera para cada 500ms

Basicamente o que acontece é que javascript coloca um loop no final da pilha que executa uma função e registra a execução de novo repetindo o processo, toda vez que console.log é executado ele bloqueia, imprime e passa e toda vez que setInterval é chamado ele bloqueia, registra e passa

O que causa esse efeito é que além de ser single-threaded javascript geralmente é single-state também, state são ponteiros que recebem as pilhas de execução, não tem a ver com paralelismo multiplos states podem ou não estar em threads diferentes

Enfim, javascript parece assíncrono porque faz muito bem feito esse gerenciamento mas não é assíncrono, toda chamada "assíncrona", o que ele faz é uma técnica em sua VM chamada Out-of-Order Execution mais especificamente a forma callback queue

O erro é pensar que setInterval não é executado o que não é executado é o seu callback

Carregando publicação patrocinada...
1

Bem, eu só usei o ChatGPT pra resumir. Mas já que sua fonte é mais confiável, explique melhor então o seu conceito de assíncrono.

Pra mim é bem simples, como uma linguagem interpretada, o interpretador vai executar linha a linha.
No entanto, existe uma engine que tá controlando a execução da thread principal (no caso de ser single-thread) e essa engine que controla o Loop de Execução.

Se uma linha de código (linha 1) eu digo que quero uma Promise e a minha engine entende isso e já pula pra linha seguinte sem bloquear a execução do código seguinte (linha 2 em diante) jogando a execução do código (callback) da minha Promise para o Loop controlar a fila, eu estou satisfeito, pois isso é ser assíncrono, no conceito da linguagem em si.

Realmente não estou entendendo o seu ponto, seu conceito de assíncrono, no caso.

1

pois isso é ser assíncrono, no conceito da linguagem em si.

Só não é assincrono no sentido real da palavra, não tem um componente essencial para assincronismo: concorrência

1

@cleitonpqz
Você está certo. O analfabetismo funcional pregou uma peça em muita gente nesse artigo.

Até o PHP tem mecanismos assíncronos nativamente, como as interfaces SplObserver e SplObservable, que aguardam o evento de notificação pra executar alguma coisa...

0
0

Meu amigo, sua defesa é inválida.

"Out-of-Order Execution" é o mesmo que "assíncrono", porque "assíncrono" significa "ocorrer fora de sincronia" ou em outras palavras "ocorrer fora da ordem temporal". Portanto, "out-of-order" === "asynchronous".

Veja bem:

assíncrono
(as·sín·cro·no)

adjetivo

  1. Que não se realiza ao mesmo tempo que outro (ex.: eventos assíncronos). ≠ SIMULTÂNEO

  2. Que não ocorre em tempo real (ex.: aulas assíncronas).

https://dicionario.priberam.org/ass%C3%ADncrono

Ou seja, no seu exemplo, setInterval é síncrono, mas a callback que ele define não é, porque não executa em tempo real (ela aguarda 500ms).

1

no seu exemplo, setInterval é síncrono, mas a callback que ele define não é, porque não executa em tempo real (ela aguarda 500ms). Porque não executa em tempo real (ela aguarda 500ms).

Ela não "aguarda 500ms", ela marca a execução para os próximos 500ms, tem exemplos demais sobre isso no post acima mas aqui vai mais 1:

const inicio = Date.now();
setInterval(()=>{
  console.log("Temporizador 1 "+(Date.now() - inicio));
},500);

setInterval(()=>{
  console.log("Temporizador 2 "+(Date.now() - inicio));
},500);

Como os resultados mostram, javascript apenas "agenda" para daqui 500ms, em assincronismo real os 500ms seriam literais, quanto mais tempo o temporizador tiver e mais coisas estiverem acontecendo mais tempo diverge, o mesmo não acontece em go que é assincrona, com apenas 2 temporizadores já vira bagunça imagina com uns 100