Isso não está explicitamente declarado no texto principal, mas talvez possa significar que, quando o código é escrito por IA, ele acaba se tornando uma dívida porque é menos familiar do que aquele escrito diretamente por uma pessoa?
Ué, eu também era usuário pagante hahaha
Fui olhar o histórico da App Store e parece que ficou gratuito a partir da 1.51.
Para mim, é uma ferramenta indispensável, porque as configurações de monitor do meu MacBook mudam conforme o lugar onde eu uso.
Acho que o GIL aparece de forma meio aleatória aí... mesmo que o GIL seja removido,
se a ideia for usar multithread tanto em casos de I/O bound quanto de CPU bound,
talvez seja melhor adotar outra alternativa em vez de Python...
Também parece que asyncio tem uma rejeição bem forte entre quem se aprofunda bastante em Python.
Acho que já ouvi com certa frequência a opinião de que gevent é que deveria ter virado o padrão.
Usam bastante asyncio... é utilizável... existe a limitação de o cancelamento de tarefas ser edge-triggered (e não level-triggered), mas na prática quase não se escreve código que trate cancelamento de tarefa de forma consciente e elegante; um problema maior é que o event loop mantém referências fracas às tarefas, então elas podem desaparecer por causa do GC... mas isso se resolve com structured concurrency.
Para praticamente qualquer operação principal de I/O, não há dificuldade em encontrar bibliotecas com suporte a asyncio...
E o GIL? Não tem muito a ver com isso... a própria ideia de usar asyncio para paralelizar trabalho CPU-intensive já é meio estranha. Se o GIL melhorar, aí sim isso será útil para multithreading CPU-intensive... async serve para rodar da forma mais eficiente possível os trechos com gargalo de I/O...
Enfim, conclusão: há alguns problemas de design, mas para atingir o objetivo não há grandes dificuldades de uso, e estamos utilizando bem isso em produção.
Claro, uma razão maior pode ser que, por causa do GIL, o benefício que dá para obter desde o início já é menor do que em outros ambientes.
Acho que dizer que, sem o GIL, seria possível gerar sinergia é algo quase enganoso. Se você colocar uma prótese, ainda que ajude um pouco, em um corredor que não tem uma das pernas, isso é "sinergia"?
O problema do Asyncio não é a dificuldade da programação assíncrona em si, mas a baixa qualidade. Um design que joga fora consistência e universalidade nem é algo tão raro em Python, mas coisas como ProactorEventLoop ainda têm bugs que causam interrupções de serviço e foram reportados há 5 anos.
Para quem é obrigado a usar isso, é bem difícil simplesmente dar risada ao ler um texto desses.
É difícil generalizar, mas, de modo geral, muitos POs, PMs e designers pareciam ter a visão de que o avanço da IA abriu mais oportunidades para profissionais de PO e PM.
Por outro lado, muitos desenvolvedores pareciam esperar que, com o avanço da IA, passassem a conseguir desenvolver produtos melhor sozinhos, sem precisar necessariamente de POs, PMs ou designers.
Vamos ter que observar como isso vai se desenrolar daqui para frente rs
Qual é o critério para dizer que algo é ruim ou bom? Até termos como “otário” existem porque têm um contexto apropriado de uso. Não se engane achando que este mundo é um lugar transbordando de amor cor-de-rosa.
Se eu já senti incômodo, foi com o próprio conceito de variáveis/funções do PHP, mas nunca senti absolutamente nenhum incômodo com a sintaxe usando $.
Dizer que não consegue usar por causa do cifrão, ~~que quem usa símbolo de dólar ganha muito dinheiro, que não é dólar americano e sim dólar do Zimbábue, então não ganha tanto assim~~, não eram só piadas?...
Mesmo que você sinta desconforto, não acaba se acostumando rápido depois de usar por um tempo?
Os seres humanos são animais que se adaptam.
Isso não está explicitamente declarado no texto principal, mas talvez possa significar que, quando o código é escrito por IA, ele acaba se tornando uma dívida porque é menos familiar do que aquele escrito diretamente por uma pessoa?
Ué, eu também era usuário pagante hahaha
Fui olhar o histórico da App Store e parece que ficou gratuito a partir da 1.51.
Para mim, é uma ferramenta indispensável, porque as configurações de monitor do meu MacBook mudam conforme o lugar onde eu uso.
Não é como se eu estivesse escrevendo um artigo...
Acho que o GIL aparece de forma meio aleatória aí... mesmo que o GIL seja removido,
se a ideia for usar multithread tanto em casos de I/O bound quanto de CPU bound,
talvez seja melhor adotar outra alternativa em vez de Python...
Também parece que
asynciotem uma rejeição bem forte entre quem se aprofunda bastante em Python.Acho que já ouvi com certa frequência a opinião de que
geventé que deveria ter virado o padrão.Obrigado por apresentar um aplicativo tão bom.
Escrevi adicionalmente.
Usam bastante
asyncio... é utilizável... existe a limitação de o cancelamento de tarefas ser edge-triggered (e não level-triggered), mas na prática quase não se escreve código que trate cancelamento de tarefa de forma consciente e elegante; um problema maior é que o event loop mantém referências fracas às tarefas, então elas podem desaparecer por causa do GC... mas isso se resolve com structured concurrency.Para praticamente qualquer operação principal de I/O, não há dificuldade em encontrar bibliotecas com suporte a
asyncio...E o GIL? Não tem muito a ver com isso... a própria ideia de usar
asynciopara paralelizar trabalho CPU-intensive já é meio estranha. Se o GIL melhorar, aí sim isso será útil para multithreading CPU-intensive... async serve para rodar da forma mais eficiente possível os trechos com gargalo de I/O...Enfim, conclusão: há alguns problemas de design, mas para atingir o objetivo não há grandes dificuldades de uso, e estamos utilizando bem isso em produção.
Mesmo sendo um ataque MITM, como conseguiram quebrar a comunicação HTTPS? Só eu que não sei disso?
Como será que a velocidade se compara com a do Biome?
Vou usar o joblib mesmo.
Claro, uma razão maior pode ser que, por causa do GIL, o benefício que dá para obter desde o início já é menor do que em outros ambientes.
Acho que dizer que, sem o GIL, seria possível gerar sinergia é algo quase enganoso. Se você colocar uma prótese, ainda que ajude um pouco, em um corredor que não tem uma das pernas, isso é "sinergia"?
Entre os lugares onde isso foi descrito, este é o documento mais bem organizado.
O problema do Asyncio não é a dificuldade da programação assíncrona em si, mas a baixa qualidade. Um design que joga fora consistência e universalidade nem é algo tão raro em Python, mas coisas como
ProactorEventLoopainda têm bugs que causam interrupções de serviço e foram reportados há 5 anos.Para quem é obrigado a usar isso, é bem difícil simplesmente dar risada ao ler um texto desses.
É difícil generalizar, mas, de modo geral, muitos POs, PMs e designers pareciam ter a visão de que o avanço da IA abriu mais oportunidades para profissionais de PO e PM.
Por outro lado, muitos desenvolvedores pareciam esperar que, com o avanço da IA, passassem a conseguir desenvolver produtos melhor sozinhos, sem precisar necessariamente de POs, PMs ou designers.
Vamos ter que observar como isso vai se desenrolar daqui para frente rs
Parece que está ficando meio como se o JavaScript estivesse mudando.
Você é livre para não gostar, mas o autor também está vivendo na era da IA. Este texto do autor provavelmente já foi coletado pelos big data da IA.
A baixa confiabilidade do AI Overview já é bem conhecida, mas isso aqui é um pouco grave.
Qual é o critério para dizer que algo é ruim ou bom? Até termos como “otário” existem porque têm um contexto apropriado de uso. Não se engane achando que este mundo é um lugar transbordando de amor cor-de-rosa.
Se eu já senti incômodo, foi com o próprio conceito de variáveis/funções do PHP, mas nunca senti absolutamente nenhum incômodo com a sintaxe usando
$.Dizer que não consegue usar por causa do cifrão, ~~que quem usa símbolo de dólar ganha muito dinheiro, que não é dólar americano e sim dólar do Zimbábue, então não ganha tanto assim~~, não eram só piadas?...