Assíncrono existe?

[utterances-bot]

Assíncrono existe?

Ei man, ler isso aí

https://patinho.tech/assincrono-existe

[Paulooo0]

Adorei, ótimo artigo

[thelinuxlich]

ótimo artigo, só perde pro silêncio!

[nicolasmelo1]

Pensa o seguinte, de maneira simplificada é o seguinte:

• Vc tem o AST do código, pensa no AST como um grande objetão JSONzão.
• Esse JSON representam cada pedaço de código. O trampo do interpreter é ler esse JSONzão e ir interpretando.
• Beleza até ai? Não? Beleza.
• Pensa que agora vc pode ter um array de ASTs, vamos pensar nela como "o que interpretar", é uma fila. Vc joga no fim e só tira o primeiro.
• Ou seja, seu interpreter funciona fazendo um array.shift() e pegando o primeiro elemento do array.
• Vc encontra uma função async. O que a linguagem pode fazer é jogar a execução dessa função em uma outra thread, atribui um UUID em um Map onde a key é o uuid, e o valor é o AST do código restante.
• Aquela thread resolveu? Pega o UUID no map, joga o AST que vc salvou no map, no array pra interpretar

"Pera, que?"

É isso, pensa comigo, quando ele encontra uma função async ele breca a interpretação do AST, só continua depois que a thread resolver com o resultado. Lembra que o Array tem outros ASTs para serem executados? Se vc breca a execução do AST, vai pro próximo AST a ser executado do array. E etc etc. Dessa maneira ele consegue "pausar" a execução de uma coisa e executar outra.

Isso é bem high level. Tem todo o lance do Heap e da Memória e tal, mas no geral é isso.

[MarlonJerold]

ótimo artigo, só perde pro silêncio!

Esqueci de deixar claro que o público alvo é para langs com complexidade como Java para implementar algo assíncrono, esqueci que o async da tua lang é feito com dois pulos, para langs como Java, é mais complicado, e demostrei isso claro na forma como abordei o assunto, mas fico feliz de ver você demostrar sua contribuição, e talvez eu fique em silêncio igual você, você que é o Senior aqui, sou apenas um estagiário

[thelinuxlich]

ótimo artigo, só perde pro silêncio!

Esqueci de deixar claro que o público alvo é para langs com complexidade como Java para implementar algo assíncrono, esqueci que o async da tua lang é feito com dois pulos, para langs como Java, é mais complicado, e demostrei isso claro na forma como abordei o assunto, mas fico feliz de ver você demostrar sua contribuição, e talvez eu fique em silêncio igual você, você que é o Senior aqui, sou apenas um estagiário

A complexidade do Java é muleta pro seu argumento. Antes de entrar nessa seara, estude sobre function colors. O Golang implementa colorless functions igual ao Java e depende de um scheduler para gerenciar o processamento assíncrono de acordo com as threads disponíveis, assim como o Java.

Ruby é colorless igual Java mas utiliza green threads, tudo acontece na mesma thread, assim como Javascript.

Depois você pode se aprofundar no que é e quais as diferenças entre Task/Future/Promise.

[MarlonJerold]

ótimo artigo, só perde pro silêncio!

Esqueci de deixar claro que o público alvo é para langs com complexidade como Java para implementar algo assíncrono, esqueci que o async da tua lang é feito com dois pulos, para langs como Java, é mais complicado, e demostrei isso claro na forma como abordei o assunto, mas fico feliz de ver você demostrar sua contribuição, e talvez eu fique em silêncio igual você, você que é o Senior aqui, sou apenas um estagiário

A complexidade do Java é muleta pro seu argumento. Antes de entrar nessa seara, estude sobre function colors. O Golang implementa colorless functions igual ao Java e depende de um scheduler para gerenciar o processamento assíncrono de acordo com as threads disponíveis, assim como o Java.

Ruby é colorless igual Java mas utiliza green threads, tudo acontece na mesma thread, assim como Javascript.

Depois você pode se aprofundar no que é e quais as diferenças entre Task/Future/Promise.

Tudo bem, Java é minha muleta pq se você for ver meus repositórios, é a única que no momento da minha carreira estou me aprofundando, utilizei CompletableFuture. E senti sim que é uma complexidade que não sei se vale a pena utilizar no projeto, o debate mostrou que CompletableFuture é utilizado no Java para esses resultados, estou questionando em formas melhores de fazer isso, mas, não sou um bom mensageiro, não sou pago para publicar essas coisas, se for olhar o título do blog é 'Um vislumbre do que passa pela mente de um Pato que escreve códigos'. Então, é isso que está passando no momento. Obrigado pelas dicas. E quanto ao erro que você me mostrou, foi pelo fato de está tendo de ter erro de conexão, não permitiam muitas requisições simuntânes e tive que fazer um delay, me questionando sobre o que de fato eu estava fazendo, o blog não tem interesse nenhum em levar uma verdade, mas sim o que estou passando

[coproduto]

Assíncrono significa que na hora que você escreve o código você não sabe em que ordem as coisas vão acontecer.

Absolutamente nada além disso.

Existem inúmeros motivos pelos quais você pode não ter uma ordenação definida, a ideia de "assíncrono" é justamente você poder ignorar isso do ponto de vista da linguagem, que é só tua interface de controle.

Bloqueante/não-bloqueante, e se uma tarefa sempre completa ou não, são outras questões. Vai te ajudar bastante a pensar nisso você só manter isso em mente: Assíncrono significa "sem ordem definida previamente".

[MarlonJerold]

Assíncrono significa que na hora que você escreve o código você não sabe em que ordem as coisas vão acontecer.

Absolutamente nada além disso.

Existem inúmeros motivos pelos quais você pode não ter uma ordenação definida, a ideia de "assíncrono" é justamente você poder ignorar isso do ponto de vista da linguagem, que é só tua interface de controle.

Bloqueante/não-bloqueante, e se uma tarefa sempre completa ou não, são outras questões. Vai te ajudar bastante a pensar nisso você só manter isso em mente: Assíncrono significa "sem ordem definida previamente".

Daora, ainda não tive a oportunidade de utilizar assíncrono para outras questões, obrigado pela contribuição nesse pequeno blog posts, e irei explorar esses novos horizontes e espero trazer aqui para o blog ^^

[mattpsvreis]

Fala Pato, tranquilo? Vou tentar te ajudar a se elucidar mais sobre o async.

Seu artigo possui alguns equívocos e algumas interpretações incorretas.

1. Confusão entre Assíncrono e Paralelismo: Seu artigo confunde assíncrono com execução paralela, sendo que esses são conceitos diferentes. Assíncrono permite que o programa continue executando outras tarefas enquanto uma operação espera uma resposta. Paralelismo, por outro lado, significa que várias tarefas ocorrem simultaneamente em diferentes threads ou processos. No JavaScript, por exemplo, o assíncrono é baseado em uma única thread (não paralela), onde operações não bloqueantes liberam o fluxo principal até que o resultado esteja pronto.

2. Ordem dos Resultados: Seu artigo menciona que resultados assíncronos podem vir em ordem desordenada, mas parece interpretar isso como uma limitação ou uma falha. Na verdade, a desordem é uma característica esperada e intencional. Se for preciso garantir uma ordem específica, existem métodos para isso, como Promise.all() no caso do JavaScript.

3. Erros de Rede e Falhas de Requisição: Seu artigo parece atribuir as falhas de requisição a problemas do assíncrono em si, quando na verdade, falhas de rede e limitações de tempo são questões externas e podem ocorrer em qualquer modelo de comunicação. Para tratar essas falhas, é prática comum implementar retries e timeouts, além de mecanismos de mensageria que reprocessam tentativas sem impacto na aplicação.

4. Operações Não-Bloqueantes “Misteriosas”: A ideia de que operações não bloqueantes são “misteriosas” mostra um entendimento impreciso sobre como o assíncrono opera. Em operações não bloqueantes, como uma requisição de rede, o código continua executando outras tarefas enquanto espera o retorno. Quando o dado chega, uma função callback ou promessa é executada. Esse modelo é bem conhecido e amplamente documentado, especialmente em linguagens como JavaScript que utiliza um Event Loop para gerenciar a execução.

5. Objetivo do Assíncrono: A principal razão para usar assíncrono não é apenas evitar bloqueios, como seu artigo sugere. Assíncrono também permite melhorar o desempenho e a escalabilidade de aplicações, liberando recursos para outras tarefas enquanto operações de I/O aguardam. Esse é um pilar de sistemas escaláveis e de alta performance.

Espero ter ajudado a entender um pouquinho melhor. :)

[MarlonJerold]

Fala Pato, tranquilo? Vou tentar te ajudar a se elucidar mais sobre o async.

Seu artigo possui alguns equívocos e algumas interpretações incorretas.

1. Confusão entre Assíncrono e Paralelismo: Seu artigo confunde assíncrono com execução paralela, sendo que esses são conceitos diferentes. Assíncrono permite que o programa continue executando outras tarefas enquanto uma operação espera uma resposta. Paralelismo, por outro lado, significa que várias tarefas ocorrem simultaneamente em diferentes threads ou processos. No JavaScript, por exemplo, o assíncrono é baseado em uma única thread (não paralela), onde operações não bloqueantes liberam o fluxo principal até que o resultado esteja pronto.
2. Ordem dos Resultados: Seu artigo menciona que resultados assíncronos podem vir em ordem desordenada, mas parece interpretar isso como uma limitação ou uma falha. Na verdade, a desordem é uma característica esperada e intencional. Se for preciso garantir uma ordem específica, existem métodos para isso, como Promise.all() no caso do JavaScript.
3. Erros de Rede e Falhas de Requisição: Seu artigo parece atribuir as falhas de requisição a problemas do assíncrono em si, quando na verdade, falhas de rede e limitações de tempo são questões externas e podem ocorrer em qualquer modelo de comunicação. Para tratar essas falhas, é prática comum implementar retries e timeouts, além de mecanismos de mensageria que reprocessam tentativas sem impacto na aplicação.
4. Operações Não-Bloqueantes “Misteriosas”: A ideia de que operações não bloqueantes são “misteriosas” mostra um entendimento impreciso sobre como o assíncrono opera. Em operações não bloqueantes, como uma requisição de rede, o código continua executando outras tarefas enquanto espera o retorno. Quando o dado chega, uma função callback ou promessa é executada. Esse modelo é bem conhecido e amplamente documentado, especialmente em linguagens como JavaScript que utiliza um Event Loop para gerenciar a execução.
5. Objetivo do Assíncrono: A principal razão para usar assíncrono não é apenas evitar bloqueios, como seu artigo sugere. Assíncrono também permite melhorar o desempenho e a escalabilidade de aplicações, liberando recursos para outras tarefas enquanto operações de I/O aguardam. Esse é um pilar de sistemas escaláveis e de alta performance.

Espero ter ajudado a entender um pouquinho melhor. :)

Quando eu falo que utilizar assíncrono é para evitar bloqueios, é pq isso é o caminho para que uma aplicação melhore seu desempenho, e a "escalabilidade" de sua aplicação mas vou tentar explicar aqui usando sua linguagem principal, JavaScript

O fato de que, operações aguardem, não significa que a forma não bloqueante de ter assíncrono, não está ali, está, porém está abstrata. Mas de fato é possível termos uma parte do nosso sistema aguardando, para que outra parte seja iniciada. Mas isso só é possível justamente pelo Javascript, oferecer possibilidade de trabalhar de forma não bloqueante com o assíncrono.

Isso não sou eu que digo, é um dos escritores dos livros mais conhecido de programação assíncrona de sua linguagem principal (You Don't Know JS: Async e Performance). Então sim, quando digo que estou utilizando assíncrono pq quero algo não bloqueante, por baixo das letrinhas estou dizendo, quero uma aplicação que tenha desempenho, escalabilidade e todas essas outras palavras bonitinhas, mesmo esperando, ainda assim o foco é não bloqueante, estou aguardando sua contribuição novamente para nos aprofundarmos nisso.