Arquivo Discussoes de Programacao e Tecnologia Java core has stagnated, Java EE is dead, and Spring is over, but the JVM marches on. C’mon Oracle, where are the big ideas?
Oracle’s last two crap quarterly earnings can most definitely be described as the chickens coming home to roost. The core of the problem is that Oracle lacks anyone who can have a big idea, and a sales machine won’t produce the results that investors are accustomed to unless they have something to sell.
Quem concorda?
Putz, só percebeu isso agora? rs
Desde o início da história Oracle-Java as pessoas já previam que isso ia acontecer.
Putz, só percebeu isso agora? rsDesde o início da história Oracle-Java as pessoas já previam que isso ia acontecer.
Não, faz tempo que venho advogando que o Java estagnou como linguagem. Qualquer um que dê um pulo na concorrência e veja o C++ ou o C#, já chegou a mesma conclusão.
Mas o fato é que boa parte da inércia do Java é por conta de APIs de terceiros, que não são tão estagnadas como o núcleo principal.
Desculpa, a pergunta foi pro autor do texto.
O “problema” (ser uma máquina de vendas, e não de idéias) existe desde a início da empresa, ou seja, está no seu DNA, o que será que fez o autor acordar em 2014 e resolver escrever um blog sobre isso não tenho a mínima idéia. rs
Sobre a concorrência, o maior risco para a linguagem Java é a chegada de um novo paradigma, e não C++ ou C#, porque essas linguagens são baseadas no mesmo paradigma que demonstra estar ultrapassado.
Na verdade, não é nem a chegada porque o paradigma funcional já chegou faz tempo, rs mais a consolidação mesmo que oferece risco…
Para mim, isso é simplesmente um indicativo da maturidade da linguagem, onde forças opostas atuam de um lado para manter o legado e outra no sentido da evolução, quase se anulando e diminuindo a velocidade das inovações.
O que vai fazer o Java evoluir ou o surgimento de uma nova plataforma (e linguagem) será o crescimento das necessidades não atendidas ou mal-atendidas. O que pode já estar acontecendo em alguma universidade ou startup por aí.
No momento, eu espero mais uma Google sair investindo numa nova (por meio de incorporação) plataforma do que a Oracle revolucionando o Java.
Se o autor estiver certo quanto as novas necessidade serem paradigmas orientadas a dados (cloud, NoSQL e big data) então podemos esperar um futuro menos promissor para linguagens orientadas a objetos (Java, C#, C++) .
O que vai fazer o Java evoluir ou o surgimento de uma nova plataforma (e linguagem) será o crescimento das necessidades não atendidas ou mal-atendidas. O que pode já estar acontecendo em alguma universidade ou startup por aí.
Se o autor estiver certo quanto as novas necessidade serem paradigmas orientadas a dados (cloud, NoSQL e big data) então podemos esperar um futuro menos promissor para linguagens orientadas a objetos (Java, C#, C++) .
O que vai fazer o Java evoluir ou o surgimento de uma nova plataforma (e linguagem) será o crescimento das necessidades não atendidas ou mal-atendidas. O que pode já estar acontecendo em alguma universidade ou startup por aí.
Se o autor estiver certo quanto as novas necessidade serem paradigmas orientadas a dados (cloud, NoSQL e big data) então podemos esperar um futuro menos promissor para linguagens orientadas a objetos (Java, C#, C++) .
.NET/C# pelo menos sempre acompanhou bem as novas tendências, foi assim com o advento do Ruby on Rails e agora com algumas influências do NodeJs na próxima versão do ASP.NET MVC (codinome vNext). Fora isso, o fato dessa próxima versão do ASP.NET MVC da Microsoft poder rodar em web server Linux, ganhando mais um espaço muito importante.
Eu achei impressionante o await a async do C#, que agora está sendo copiado pelo JavaScript. O fato deles terem feito um ajuste tão limpo e bem-feito já no paradigma assíncrono mostra que eles estão extremamente antenados com o que está vindo por aí.
Não subestimem o Anders Hejlsberg, criador do C#, ele sempre foi um brilhante idealizador de plataformas, desde a época do Delphi.
.NET/C# pelo menos sempre acompanhou bem as novas tendências, foi assim com o advento do Ruby on Rails e agora com algumas influências do NodeJs na próxima versão do ASP.NET MVC (codinome vNext). Fora isso, o fato dessa próxima versão do ASP.NET MVC da Microsoft poder rodar em web server Linux, ganhando mais um espaço muito importante.
RoR e NodeJs não representam mudança de paradigma e tem uso restrito a nichos específicos, isso as torna mais fáceis de serem assimiladas pelos usuários, como tb serem copiadas pela concorrência.
O que é ótimo para programadores C# que atuam no mesmo nicho que RoR e NodeJs (programação web, basicamente), mas não diz nada sobre a capacidade da linguagem C# de se adequar a um novo paradigma de computação.
Tendências são mudanças que acontecem dentro do mesmo paradigma.
Eu achei impressionante o await a async do C#, que agora está sendo copiado pelo JavaScript. O fato deles terem feito um ajuste tão limpo e bem-feito já no paradigma assíncrono mostra que eles estão extremamente antenados com o que está vindo por aí.Não subestimem o Anders Hejlsberg, criador do C#, ele sempre foi um brilhante idealizador de plataformas, desde a época do Delphi.
Açúcar sintático para o programador não ter que manipular threads manualmente é sempre bem vindo.
Açúcar sintático para o programador não ter que manipular threads manualmente é sempre bem vindo.
Não é exatamente um sintax suggar. Estou incluindo toda a arquitetura em volta disso, que permite:
Não é exatamente um sintax suggar. Estou incluindo toda a arquitetura em volta disso, que permite:
- Escrever código assíncrono como se fosse síncrono;
- Gerar código assíncrono facilmente (com recursos como co-rotinas);
- Ter schedulers prontos para paralelização em múltiplos processadores ou threads. Permitir que o programador faça o próprio scheduler;
- APIs para já contemplando o recurso em todo o SO.
3 não é um recurso da linguagem C#, e nem é bem uma novidade, a Apple já oferece isso desde o mac 10.6 e ios 4.
É um avanço, não tenha dúvida dúvida, principalmente se você é programador front end.
O backend é que caminha para algo muito diferente (cloud, NoSQL e big data são tendências de backend) e linguagens orientadas a dados (funcionais) estão muito mais preparadas para esse tipo de situação do que as orientadas a objetos.
Não é exatamente um sintax suggar. Estou incluindo toda a arquitetura em volta disso, que permite:
- Escrever código assíncrono como se fosse síncrono;
- Gerar código assíncrono facilmente (com recursos como co-rotinas);
- Ter schedulers prontos para paralelização em múltiplos processadores ou threads. Permitir que o programador faça o próprio scheduler;
- APIs para já contemplando o recurso em todo o SO.
3 não é um recurso da linguagem C#, e nem é bem uma novidade, a Apple já oferece isso desde o mac 10.6 e ios 4.
É um avanço, não tenha dúvida dúvida, principalmente se você é programador front end.
O backend é que caminha para algo muito diferente (cloud, NoSQL e big data são tendências de backend) e linguagens orientadas a dados (funcionais) estão muito mais preparadas para esse tipo de situação do que as orientadas a objetos.
Acho que você não está entendendo o que estou dizendo. Não falei que nenhuma dessas coisas era novidade isoladamente (no caso da MS, algo raramente é). Estou falando da arquitetura como um todo, da plataforma. Do fato de tudo estar lá, com uma sintaxe limpa, elegante e integrada na plataforma.
Programe um pouco para Windows 8, ou usando os recursos de async e await de fato, veja como funciona o paralelismo no Azure, e depois conversamos.
Não é exatamente um sintax suggar. Estou incluindo toda a arquitetura em volta disso, que permite:
- Escrever código assíncrono como se fosse síncrono;
- Gerar código assíncrono facilmente (com recursos como co-rotinas);
- Ter schedulers prontos para paralelização em múltiplos processadores ou threads. Permitir que o programador faça o próprio scheduler;
- APIs para já contemplando o recurso em todo o SO.
3 não é um recurso da linguagem C#, e nem é bem uma novidade, a Apple já oferece isso desde o mac 10.6 e ios 4.
É um avanço, não tenha dúvida dúvida, principalmente se você é programador front end.
O backend é que caminha para algo muito diferente (cloud, NoSQL e big data são tendências de backend) e linguagens orientadas a dados (funcionais) estão muito mais preparadas para esse tipo de situação do que as orientadas a objetos.
Acho que você não está entendendo o que estou dizendo. Não falei que nenhuma dessas coisas era novidade isoladamente (no caso da MS, algo raramente é). Estou falando da arquitetura como um todo, da plataforma. Do fato de tudo estar lá, com uma sintaxe limpa, elegante e integrada na plataforma.
Programe um pouco para Windows 8, ou usando os recursos de async e await de fato, veja como funciona o paralelismo no Azure, e depois conversamos.
Muito bom poder usar todos os cores da máquina porque a interface continua responsiva. Como falei, programadores macos e ios sabem o que é isso faz tempo.
Quanto a paralelismo no azure, de fato nem lembro quando foi a última vez que precisei criar uma thread no backend, rs na sua opinião, porque acha que async e await é importante no backend?
Para não ter threads bloqueantes ocupando o servidor web. Senão dependendo do uso simultâneo e limite do servidor web a aplicação pode parar de responder.
Quando vejo falar de MS lembro da MFC, Silverlight, COM/DCOM, Activex e tantas tecnologias que foram o bam bam bam e a MS matou. Difícil ver um concorrente pro Java tão cedo. O Andrew C. Oliver sempre criticou o Java e sempre odiou a Oracle, mesmo na época da Sun e se não viu o que vai vir com os servlets 4.0 e nem as novidades do Java EE 7 (e o que está pra vir no 8) então é difícil discutir.
MFC não posso falar pois não conheço. Mas Silverlight, COM/DCOM, Activex não fazem sentido para os novos tempos, para que dar continuidade? Vai querer fazer novos projetos desktop em Swing? Faz sentido usar Flash ainda? Tem coragem de usar JavaFx para web (que já foi a proposta de Silverlight para Java)? Quem aposta em tecnologias “diferentes” acaba tendo esses riscos, por isso é bom nunca inventar muito.
Para não ter threads bloqueantes ocupando o servidor web. Senão dependendo do uso simultâneo e limite do servidor web a aplicação pode parar de responder.
Na maioria da vezes (98%?), o gargalo de uma aplicação web é o banco, e não no modelo de threads usado pelo servidor.
Então repito a pergunta: tirando aficcionados node.js, quem mais liga para threads não-bloqueantes no backend?
Na maioria da vezes (98%?), o gargalo de uma aplicação web é o banco, e não no modelo de threads usado pelo servidor.Então repito a pergunta: tirando aficcionados node.js, quem mais liga para threads não-bloqueantes no backend?
[2]
Para não ter threads bloqueantes ocupando o servidor web. Senão dependendo do uso simultâneo e limite do servidor web a aplicação pode parar de responder.Na maioria da vezes (98%?), o gargalo de uma aplicação web é o banco, e não no modelo de threads usado pelo servidor.
Então repito a pergunta: tirando aficcionados node.js, quem mais liga para threads não-bloqueantes no backend?
Você mesmo meio que encaminhou a resposta, como exemplo o banco de dados. Supondo então ter um processo pesado e que ao mesmo tempo o resultado de um usuário nao dependa do outro, esse pode ser um caso para não deixar este processo na thread do request, se houver possibilidade de atingir limite de requests ocupados simultâneos no web server. Os recursos estão ai para serem usados de acordo com o cenário, se o problema não existe não usa.
Mas a solução para o cenário que você descreve não é usar operações assíncronas para processamento pesado. Até porque não importa se você usa a thread do request, ou uma thread criada no request handler da sua aplicação, em ambos os casos estará usando recursos computacionais do servidor pra fazer o processamento, e deixando de usar os mesmos recursos para tratar requisições do cliente.
A solução para esse caso é migrar o processamento pesado para outra máquina.
Você mesmo meio que encaminhou a resposta, como exemplo o banco de dados. Supondo então ter um processo pesado e que ao mesmo tempo o resultado de um usuário nao dependa do outro, esse pode ser um caso para não deixar este processo na thread do request, se houver possibilidade de atingir limite de requests ocupados simultâneos no web server. Os recursos estão ai para serem usados de acordo com o cenário, se o problema não existe não usa.Mas a solução para o cenário que você descreve não é usar operações assíncronas para processamento pesado. Até porque não importa se você usa a thread do request, ou uma thread criada no request handler da sua aplicação, em ambos os casos estará usando recursos computacionais do servidor pra fazer o processamento, e deixando de usar os mesmos recursos para tratar requisições do cliente.
A solução para esse caso é migrar o processamento pesado para outra máquina.
Não me refiro a desempenho ou onde o processo pesado vai rodar, mas sobre o limite de requests ocupadas no servidor web, onde seja la onde for rodar o processo pesado, a thread do request não vai ficar travada.
Se o cliente precisa saber o resultado da operação, ele vai ter que esperar na thread ou vai ter que fazer outra requisição para obter a resposta. Isso aumenta, não diminui o número de requests ao servidor.
De qualquer maneira, a decisão de travar é do programador da aplicação e depende do custo da operação a ser realizada (que é conhecido pelo programador no momento da codificação). Ao meu ver, não faz muito sentido o desenvolvedor basear essa decisão no número de requests que o servidor web em produção vai estar configurado para suportar, porque geralmente ele não tem essa informação enquanto esta desenvolvendo a aplicação.
A questão está na otimização do uso dos recursos. Tornar o ambiente síncrono consome muitos recursos: é necessário garantir trocas de mensagens de acks, é necessário tratar contextos de threads, etc.
Programar de maneira assíncrona libera o processador para tratar de outras atividades a um custo bem menor.
Além disso, quando a aplicação como um todo está escrita considerando assincronia, fica bem mais fácil paralelizar tarefas.
A questão está na otimização do uso dos recursos. Tornar o ambiente síncrono consome muitos recursos: é necessário garantir trocas de mensagens de acks, é necessário tratar contextos de threads, etc.Programar de maneira assíncrona libera o processador para tratar de outras atividades a um custo bem menor.
Além disso, quando a aplicação como um todo está escrita considerando assincronia, fica bem mais fácil paralelizar tarefas.
Quando um método é chamado em qualquer linguagem você esta fazendo uma chamada síncrona. Então por padrão, o ambiente é síncrono.
Pra realizar chamadas de maneira assíncrona, deve existir alguma vantagem. No caso de aplicações frontend essa vantagem está em não bloquear a thread responsável por atualizar a interface do usuário, garantindo assim uma interface sempre responsiva.
Qual a vantagem de async em aplicações de backend?
Esse site deveria ter vergonha de deixar um cidadão desses escrever tanta bobagem.
De qualquer forma, tem coisas inovadoras acontecendo com Java o tempo todo, Grails e Groovy por exemplo
Mesmo em aplicações frontend, async só é usado quando o desenvolvedor da aplicação identifica uma operação que pode bloquear a interface do usuário. Portanto não é correta a afirmação que a aplicação é toda escrita considerando assíncrona.
Quando um método é chamado sim, mas considere o exemplo que foi dado, do banco de dados. Para que você tenha a ilusão de sincronismo num “executeQuery” há um controle do lado cliente, para fazer a thread que deu o select dormir, esperar mensagem de confirmação, gerenciar timeouts, etc. E há um controle do lado do banco, para enviar essas mensagens.
Isso torna mais complexa a implementação do banco e dos drivers. Boa parte disso isso pode ser evitada se os dois lados estiverem preparados para chamadas assíncronas.
Esse tipo de arquitetura facilita drasticamente a comunicação entre diferentes threads, ou entre aplicações em diferentes máquinas.
Não. Usa-se async também quando você quer disparar diversas operações assíncronas e aguardar por seu resultado em ordem. Um exemplo disso é o que é feito nessa aplicação para explicar os Promises: http://www.html5rocks.com/en/tutorials/es6/promises/?redirect_from_locale=pt
O Java tem APIs para esse tipo de tratamento. Chamam Future e Callable.
Quando um método é chamado sim, mas considere o exemplo que foi dado, do banco de dados. Para que você tenha a ilusão de sincronismo num “executeQuery” há um controle do lado cliente, para fazer a thread que deu o select dormir, esperar mensagem de confirmação, gerenciar timeouts, etc. E há um controle do lado do banco, para enviar essas mensagens.Isso torna mais complexa a implementação do banco e dos drivers. Boa parte disso isso pode ser evitada se os dois lados estiverem preparados para chamadas assíncronas.
Esse tipo de arquitetura facilita drasticamente a comunicação entre diferentes threads, ou entre aplicações em diferentes máquinas.
Se facilita a implementação do banco e dos drivers não sei, mas de que maneira facilitaria a comunicação?
Se o cliente precisa dos dados ele só precisa esperar pela resposta do banco, o que tem de complicado nisso?
Qual seria a alternativa mais simples neste caso?
Se facilita a implementação do banco e dos drivers não sei, mas de que maneira facilitaria a comunicação?
Se o cliente precisa dos dados ele só precisa esperar pela resposta do banco, o que tem de complicado nisso?
Qual seria a alternativa mais simples neste caso?
É um pouco compicado explicar aqui como isso funciona por baixo dos panos. É, inclusive, o tema de dois meses da minha aula de redes.
A complexidade está no fato de que as duas máquinas não estão, efetivamente, operando ao mesmo tempo. Então, há a necessidade de avisar que o comando foi recebido (ACK), que a outra máquina ainda está viva e processando (KEEP_ALIVE), e que o processamento acabou. Tudo isso para criar a ilusão de sincronia.
A razão por trás da sincronia é que, depois de pronta, fica muito mais fácil programar. É conceitualmente simples fazer um simples "executeQuery"e entender isso como uma chamada de função. Porém, essa ilusão de simplicidade vem com um custo.
Eu nunca vi nenhum trabalho sério que quantifica se esse custo é tão alto ao ponto disso, por si só, justificar toda a mudança de paradigma que o node propõe.
A razão pelo qual gosto do async é justamente o fato de tornar fácil criar threads assíncronas para calculos ou processamento batch e depois sincroniza-las em algum ponto. Do lado do servidor, a vantagem está justamente no fato de você poder disparar vários pequenos processamentos desses, e depois poder espera-los em ordem, ou coloca-los em condição de corrida. Quando há também formas de você declarar quais processamentos estão em contextos distintos (como se faz no C#) e quais dados são trocados em sua fronteira, fica muito fácil criar um escalonador que possa decidir sozinho se um determinado trecho de código pode ser disparado na mesma thread, numa thread separada, ou numa máquina remota, ou mesmo com redundância em várias máquinas (como o Azure faz). Assim é possível ter backends muito poderosos sem você ter um esforço muito grande de gerenciar threads e paralelismo na mão.
Não. Usa-se async também quando você quer disparar diversas operações assíncronas e aguardar por seu resultado em ordem. Um exemplo disso é o que é feito nessa aplicação para explicar os Promises: http://www.html5rocks.com/en/tutorials/es6/promises/?redirect_from_locale=pt
O Java tem APIs para esse tipo de tratamento. Chamam Future e Callable.
JavaScript é diferente porque qualquer coisa pode bloquear a interface, já que só existe uma thread e ela é usada pra tudo.
Estava me referindo a linguagens de verdade.
JavaScript é diferente porque qualquer coisa pode bloquear a interface, já que só existe uma thread e ela é usada pra tudo.Estava me referindo a linguagens de verdade.
Por favor, leia o material que passei e entenda o que estou falando. No caso, o trecho em questão está sincronizando threads que são automaticamente disparadas pelo browser para download de arquivos, e cujo resultado tem que ser exibido em ordem.
Uma situação facilmente necessária e que pode ser reproduzida no backend, em linguagens de verdade, para threads que o próprio programador queira criar para processamentos diversos.
Enfim uma resposta.
Agora entendi porque isso é uma vantagem. Porque você usa uma linguagem que só tem uma thread no servidor. Portanto, no modelo javascript de programação esse tipo de coisa é incentivado.
Mas linguagens que não compartilham das mesmas limitações que javascript, não vejo vantagem disparar processos dessa maneira.
Eram dois assuntos diferentes. O primeiro, a resposta da pergunta de “porque projetar tudo para ser assíncrono permite que o servidor seja mais leve e tenha mais performance”. A segunda é “para o programador de backend, qual é a vantagem de ter mecanismos assíncronos?”.
Isso é válido para qualquer linguagem. Você irá disparar processos dessa maneira em qualquer linguagem. Java, C# ou JavaScript. E vai querer espera-los. Não é à toa que já existem APIs para isso no Java - como boa parte do pacote java.util.synchronized.
Isso é válido para qualquer linguagem. Você irá disparar processos dessa maneira em qualquer linguagem. Java, C# ou JavaScript. E vai querer espera-los. Não é à toa que já existem APIs para isso no Java - como boa parte do pacote java.util.synchronized.
Não acha que existe uma diferença entre ter uma API que o desenvolvedor pode optar usar, e o que acontece com javascript onde você é praticamente obrigado a seguir esse modelo de programação se quiser ter a oportunidade de fazer alguma coisa com a linguagem?
Não me refiro a desempenho ou onde o processo pesado vai rodar, mas sobre o limite de requests ocupadas no servidor web, onde seja la onde for rodar o processo pesado, a thread do request não vai ficar travada.Se o cliente precisa saber o resultado da operação, ele vai ter que esperar na thread ou vai ter que fazer outra requisição para obter a resposta. Isso aumenta, não diminui o número de requests ao servidor.
De qualquer maneira, a decisão de travar é do programador da aplicação e depende do custo da operação a ser realizada (que é conhecido pelo programador no momento da codificação). Ao meu ver, não faz muito sentido o desenvolvedor basear essa decisão no número de requests que o servidor web em produção vai estar configurado para suportar, porque geralmente ele não tem essa informação enquanto esta desenvolvendo a aplicação.
Claro que sim, mas não vejo onde isso seja relevante para a discussão.
Estava só falando que possuir o mesmo mecanismo para se usar quando for conveniente, com uma sintaxe simples e ergonômica, com outros recursos que dão suporte fácil a isso (como co-rotinas) e se aproveitando ao máximo do potencial benéfico do assincronismo é positivo no .Net. O Java ainda está anos luz atrás disso. E o JavaScript, que é altamente dependente disso, está propondo só na versão 7 chegar ao que o .Net já tem hoje. Por isso falei para não menosprezarem a capacidade de integração do criador do .Net.
Em momento nenhum falei que impor esse modelo para absolutamente tudo, como faz o JavaScript, seria positivo. Até porque, o modelo single-threaded do JavaScript não permite que nós criemos nossos próprias rotinas que rodarão assincronamente. Só permite que esperemos por o que o browser já implemente por padrão.
Não me refiro a desempenho ou onde o processo pesado vai rodar, mas sobre o limite de requests ocupadas no servidor web, onde seja la onde for rodar o processo pesado, a thread do request não vai ficar travada.Se o cliente precisa saber o resultado da operação, ele vai ter que esperar na thread ou vai ter que fazer outra requisição para obter a resposta. Isso aumenta, não diminui o número de requests ao servidor.
De qualquer maneira, a decisão de travar é do programador da aplicação e depende do custo da operação a ser realizada (que é conhecido pelo programador no momento da codificação). Ao meu ver, não faz muito sentido o desenvolvedor basear essa decisão no número de requests que o servidor web em produção vai estar configurado para suportar, porque geralmente ele não tem essa informação enquanto esta desenvolvendo a aplicação.
Tambem nao me refiro ao cliente, ele vai esperar sim, mas a thread do request gerenciada pelo webserver nao vai estar travada pela efetiva execucao do processo pesado. Existem sim casos de limitação, normalmente o erro retornado quando estoura no IIS é “Server too busy”, clássico ocorrer em hospedagens compartilhadas. No Java estou por fora, não tenho certeza mas parece que no Tomcat por exemplo tem algo relacionado a “maxThreads”.
concordo se usar hospedagens compartilhadas vai ocorrer vários casos de limitação.
Claro que sim, mas não vejo onde isso seja relevante para a discussão.Estava só falando que possuir o mesmo mecanismo para se usar quando for conveniente, com uma sintaxe simples e ergonômica, com outros recursos que dão suporte fácil a isso (como co-rotinas) e se aproveitando ao máximo do potencial benéfico do assincronismo é positivo no .Net. O Java ainda está anos luz atrás disso. E o JavaScript, que é altamente dependente disso, está propondo só na versão 7 chegar ao que o .Net já tem hoje. Por isso falei para não menosprezarem a capacidade de integração do criador do .Net.
Em momento nenhum falei que impor esse modelo para absolutamente tudo, como faz o JavaScript, seria positivo. Até porque, o modelo single-threaded do JavaScript não permite que nós criemos nossos próprias rotinas que rodarão assincronamente. Só permite que esperemos por o que o browser já implemente por padrão.
JS chegar ao que .net tem hoje? rs
Porque acha que isso seria possível ou desejável?
Isso é válido para qualquer linguagem. Você irá disparar processos dessa maneira em qualquer linguagem. Java, C# ou JavaScript. E vai querer espera-los. Não é à toa que já existem APIs para isso no Java - como boa parte do pacote java.util.synchronized.
Aqui você deve estar se referindo ao pacote java.util.concurrent.
Abraço
Não. Usa-se async também quando você quer disparar diversas operações assíncronas e aguardar por seu resultado em ordem. Um exemplo disso é o que é feito nessa aplicação para explicar os Promises: http://www.html5rocks.com/en/tutorials/es6/promises/?redirect_from_locale=pt
O Java tem APIs para esse tipo de tratamento. Chamam Future e Callable.
Isso mesmo, JEE 6.
Usamos por aqui, é bem interessante, mas é usado em situações mais específicas, como as citadas pelos colegas e você.
JS chegar ao que .net tem hoje? rsPorque acha que isso seria possível ou desejável?
Estou me referindo a essa proposta aqui:
Estamos falando da parte de assincronia, não do .Net framework inteiro.
Mesmo não querendo levar a discussão para Java X .Net eu tenho que confessar, eu relutei muito (muito mesmo) em trabalhar com .Net, eu já estava trabalhando com java e finalmente tinha me familiarizado com o Java SE (core) e estava começando a mandar bem no Spring, Hibernate etc etc… Surgiu um projeto pra ganhar o dobro em .Net, pensei pensei… e decidi arriscar, não me arrependo nem um pouco, a Micro$osft mudou demais nesses últimos anos, aquela microsoft que todos os javeiros me alertaram quando eu estava no começo da minha carreira não é tão sombria assim, os caras andam escutando bastante a comunidade, saem muitas releases novas o tempo todo de todas as tecnologias que eles mantem.
Eu comecei a trabalhar com .Net no asp.net mvc 4, já estamos no 5.2 em 1 ano e pouco que eu estou trabalhando com asp.net, existem muitos projetos open-source. Mas voltando ao tópico, concordo um pouco com o post do cara, mas desejo vida longa ao java, se uma ou outra linguagem dominar o mercado em absoluto perdemos a “competitividade” e estaremos fadados a evoluções lentas em questão de novidades, quem sabe não foi isso que aconteceu com o java nos últimos anos…
Estou me referindo a essa proposta aqui:
Estamos falando da parte de assincronia, não do .Net framework inteiro.
Não vejo que relação isso pode ter com aplicações desktops escritas em .net.
A programação assíncrona permite trabalhar com alguns modelos de arquiteturas muito interessantes. Um caso por exemplo é o modelo CQRS de acesso a dados. Ele consiste basicamente em dividir as tarefas de manipulação de modelos de dados em dois conjuntos: Command (atualização / inserção de dados) e Query (leitura de dados). As operações de inserção e atualização na maioria das vezes podem ser feitas assincronamente. Eu não preciso, por exemplo, esperar que uma operação de inserção na base seja concluida para eu continuar o fluxo da minha aplicação. E isso é só um exemplo.
A programação assíncrona no lado backand permite evitar operações bloqueantes desnecessárias. Tudo o que eu não precisar esperar o resultado para continuar o processo da aplicação eu posso mandar fazer assíncronamente.
A programação assíncrona permite trabalhar com alguns modelos de arquiteturas muito interessantes. Um caso por exemplo é o modelo CQRS de acesso a dados. Ele consiste basicamente em dividir as tarefas de manipulação de modelos de dados em dois conjuntos: Command (atualização / inserção de dados) e Query (leitura de dados). As operações de inserção e atualização na maioria das vezes podem ser feitas assincronamente. Eu não preciso, por exemplo, esperar que uma operação de inserção na base seja concluida para eu continuar o fluxo da minha aplicação. E isso é só um exemplo. A programação assíncrona no lado backand permite evitar operações bloqueantes desnecessárias. Tudo o que eu não precisar esperar o resultado para continuar o processo da aplicação eu posso mandar fazer assíncronamente.
Sim, teoricamente você poderia enviar um comando como uma operação assíncrona, bem lembrado!
Mas quando o desenvolvedor precisar obter o resultado de uma operação pra prosseguir com o fluxo da aplicação, ainda pode ocorrer o bloqueio.
future = conn.transactAsync(tx);
... // fluxo normal da aplicação
txResult = future.get(); // vai bloquear se tx ainda não estiver concluída (ou abortada)
Novamente, a solução neste caso é desenvolvedor que sabe o que esta fazendo, e não funcionalidade X ou Y.
No caso do CQRS (que é um paradigma orientado a dados, e incompatível com objetos) sei que é indicado para cenários com muitas operações de leitura. Não acho que seja uma boa idéia para cenários com muitas operações de escrita, assíncronas ou não, devido as operações serem processadas serialmente no command model.
Eu vejo muito esse argumento usado em listas de discussão C++, para tentar dizer que o garbage collector é inútil… Para mim, esse argumento não faz qualquer sentido. Nós criamos recursos justamente para que os desenvolvedores não precisem se preocupar os mínimos detalhes do que estão fazendo, para evitar que desenvolvedores menos experientes, menos cuidadosos, ou mesmo acidentalmente, cometam erros que a máquina pode evitar.
Mas quando o desenvolvedor precisar obter o resultado de uma operação pra prosseguir com o fluxo da aplicação, ainda pode ocorrer o bloqueio.future = conn.transactAsync(tx); ... // fluxo normal da aplicação txResult = future.get(); // vai bloquear se tx ainda não estiver concluída (ou abortada)
Essa seria uma forma errada de trabalhar no paradigma assíncrono. O correto seria você responder a um callback, e deixar o processador fazendo outras coisas que não precisam ser bloqueadas enquanto isso:
//Em C# isso faz com que a thread pare, dando lugar a outras coisas
txResult = await conn.transactAsync(tx);
Em JavaScript, com Promises, um código similar seria:
conn.transactAsync(tx).then(function(result) {
txResult = result;
});
Mas quando o desenvolvedor precisar obter o resultado de uma operação pra prosseguir com o fluxo da aplicação, ainda pode ocorrer o bloqueio.
future = conn.transactAsync(tx); ... // fluxo normal da aplicação txResult = future.get(); // vai bloquear se tx ainda não estiver concluída (ou abortada)Novamente, a solução neste caso é desenvolvedor que sabe o que esta fazendo, e não funcionalidade X ou Y.
No caso do CQRS (que é um paradigma orientado a dados, e incompatível com objetos) sei que é indicado para cenários com muitas operações de leitura. Não acho que seja uma boa idéia para cenários com muitas operações de escrita, assíncronas ou não, devido as operações serem processadas serialmente no command model.
Mas ai é que tá, você deve usar da assincronia justamente quando você não precisa do resultado da execução. Para operações de alteração / inserção de dados em um banco, por exemplo, esse é o caso adequado em muitas vezes. E incrivelmente isso se adequa até mesmo para operações de leita. Isso mesmo, podemos fazer leitura de dados de forma assíncrona. Onde trabalho estamos desenvolvendo o BackEnd de um sistema usando o paradigma de atores (com o framework akka). Estamos criando uma API de persistência completamente assíncrona. A grande vantagem é que isso vai nos ajudar muito na hora de escalar a nossa aplicação, que tem como grande gargalo hoje o banco de dados. E antes que pergunte, obivamente estamos tendo cuidado para não ter provlemas de inconsistência que podem vir com a assincronia se trabalhada da forma errada.
public async Task<string> ActionRequisicaoExemplo()
{
var t1 = Task.Run(() => ProcessoDemorado1());
var t2 = Task.Run(() => ProcessoDemorado2());
await Task.WhenAll(t1, t2);
return "finalizado";
}
public static void ProcessoDemorado1()
{
Thread.Sleep(10000);
}
public static void ProcessoDemorado2()
{
Thread.Sleep(10000);
}
Mas quando o desenvolvedor precisar obter o resultado de uma operação pra prosseguir com o fluxo da aplicação, ainda pode ocorrer o bloqueio.
future = conn.transactAsync(tx); ... // fluxo normal da aplicação txResult = future.get(); // vai bloquear se tx ainda não estiver concluída (ou abortada)Novamente, a solução neste caso é desenvolvedor que sabe o que esta fazendo, e não funcionalidade X ou Y.
No caso do CQRS (que é um paradigma orientado a dados, e incompatível com objetos) sei que é indicado para cenários com muitas operações de leitura. Não acho que seja uma boa idéia para cenários com muitas operações de escrita, assíncronas ou não, devido as operações serem processadas serialmente no command model.
Mas ai é que tá, você deve usar da assincronia justamente quando você não precisa do resultado da execução. Para operações de alteração / inserção de dados em um banco, por exemplo, esse é o caso adequado em muitas vezes. E incrivelmente isso se adequa até mesmo para operações de leita. Isso mesmo, podemos fazer leitura de dados de forma assíncrona. Onde trabalho estamos desenvolvendo o BackEnd de um sistema usando o paradigma de atores (com o framework akka). Estamos criando uma API de persistência completamente assíncrona. A grande vantagem é que isso vai nos ajudar muito na hora de escalar a nossa aplicação, que tem como grande gargalo hoje o banco de dados. E antes que pergunte, obivamente estamos tendo cuidado para não ter provlemas de inconsistência que podem vir com a assincronia se trabalhada da forma errada.
Toda operação envolvendo atores é assíncrona, não importa se leitura ou escrita. É uma característica própria das linguagens que seguem o modelo distribuído de troca de mensagens. Programas C#, Java, C++ seguem um modelo diferente, que eu chamaria de local orientado a objetos.
Não sou muito familiar com o modelo distribuído, mas sei que ele faz sucesso em sistemas... distribuídos.. onde os requisitos são bem diferentes dos requisitos esperados para uma aplicação de banco de dados.
Eu vejo muito esse argumento usado em listas de discussão C++, para tentar dizer que o garbage collector é inútil… Para mim, esse argumento não faz qualquer sentido. Nós criamos recursos justamente para que os desenvolvedores não precisem se preocupar os mínimos detalhes do que estão fazendo, para evitar que desenvolvedores menos experientes, menos cuidadosos, ou mesmo acidentalmente, cometam erros que a máquina pode evitar.
Em nenhum momento eu disse que operações assíncronas são inúteis.
Apenas disse que se o banco é o gargalo do sistema, tornar as operações com o banco assíncronas não vai fazer o banco ser capaz de processar as requisições mais rápido. Considerando que a maioria dos servidores é capaz de lidar com mais requisições do que o banco, existe a possibilidade de você o sobrecarregar ainda mais o banco dessa maneira.
Sobre garbage collector, meu pensamento é na mesma linha. GC só evita que o desenvolvedor tenha que desalojar o objeto no fim da sua vida. Mas você ainda precisa saber o que esta fazendo e como isso afeta o ciclo de vida dos seus objetos. O preço disso é um processo a mais rodando o gc versus não ter o processo e você desalojar manualmente. Se é útil ou não vai depender de cada caso. Não existe unidade de utilidade universal que funciona pra todo mundo.
Mas quando o desenvolvedor precisar obter o resultado de uma operação pra prosseguir com o fluxo da aplicação, ainda pode ocorrer o bloqueio.future = conn.transactAsync(tx); ... // fluxo normal da aplicação txResult = future.get(); // vai bloquear se tx ainda não estiver concluída (ou abortada)Essa seria uma forma errada de trabalhar no paradigma assíncrono. O correto seria você responder a um callback, e deixar o processador fazendo outras coisas que não precisam ser bloqueadas enquanto isso:
//Em C# isso faz com que a thread pare, dando lugar a outras coisas txResult = await conn.transactAsync(tx);Em JavaScript, com Promises, um código similar seria:
conn.transactAsync(tx).then(function(result) { txResult = result; });
a maneira "correta" vai depender do idioma usado pela linguagem. Em todos os casos o resultado é o mesmo.
Nem falei que você disse. Só estava explicando porque não considero “o programador deve saber o que está fazendo” como um argumento numa discussão sobre funcionalidades de uma linguagem. Um programador que sabe muito jamais precisará de funcionalidade nenhuma que facilite a vide dele “a priori”.
Só para ilustrar em código funcional o que já conversamos sobre programação assíncrona em C# no backend:Como principalmente ViniGodoy falou em um dos posts, o exemplo mostra a execução de dois processos em paralelo. Neste caso, ao invés de durar 20 segundos a execução total, vai durar só 10 a execução dos dois. Existem outras variantes de acordo com a necessidade, mas já dá pra ter noção do quanto está simples programação assíncrona em C#.public async Task<string> ActionRequisicaoExemplo() { var t1 = Task.Run(() => ProcessoDemorado1()); var t2 = Task.Run(() => ProcessoDemorado2()); await Task.WhenAll(t1, t2); return "finalizado"; } public static void ProcessoDemorado1() { Thread.Sleep(10000); } public static void ProcessoDemorado2() { Thread.Sleep(10000); }
Seu código é funcional no desktop onde um processo demorado pode bloquear a thread do usuário por 10 segundos.
Esse problema não existe na web onde requisições levam ms para processar.. não 10 segundos.. bom, a não ser que tenha algo errado com o design da sua aplicação web. :O
Só para ilustrar em código funcional o que já conversamos sobre programação assíncrona em C# no backend:Como principalmente ViniGodoy falou em um dos posts, o exemplo mostra a execução de dois processos em paralelo. Neste caso, ao invés de durar 20 segundos a execução total, vai durar só 10 a execução dos dois. Existem outras variantes de acordo com a necessidade, mas já dá pra ter noção do quanto está simples programação assíncrona em C#.public async Task<string> ActionRequisicaoExemplo() { var t1 = Task.Run(() => ProcessoDemorado1()); var t2 = Task.Run(() => ProcessoDemorado2()); await Task.WhenAll(t1, t2); return "finalizado"; } public static void ProcessoDemorado1() { Thread.Sleep(10000); } public static void ProcessoDemorado2() { Thread.Sleep(10000); }Seu código é funcional no desktop onde um processo demorado pode bloquear a thread do usuário por 10 segundos.
Esse problema não existe na web onde requisições levam ms para processar.. não 10 segundos.. bom, a não ser que tenha algo errado com o design da sua aplicação web. :O
Trabalho com ASP.NET MVC e tenho situações onde o cliente precisa exportar para Excel relatórios complexos com fonte de dados variadas. Difícil alguém não passar por uma situação de relatório analítico que não demore segundos.
Pode ter situações úteis em aplicações de banco de dados. O SGDB é perfeitamente capaz de lidar com diversos acessos ao mesmo tempo, da mesma forma que vários usuários simultâneos. Então pode ser válido se o cenário for favorável e tiver a necessidade.Trabalho com ASP.NET MVC e tenho situações onde o cliente precisa exportar para Excel relatórios complexos com fonte de dados variadas. Difícil alguém não passar por uma situação de relatório analítico que não demore segundos.
Apenas estou dizendo que seu cenário não é valido na web. um cliente nunca iria esperar 10 segundos numa requisição pra receber do servidor uma string escrito “finalizado”. Isso não tem lógica nenhuma. lol
Do ponto de vista da otimização dos recursos do servidor web, é mais indicado retornar a requisição com um “processo iniciado” ao invés de “finalizado” e fazer o cliente fazer outra requisição pra saber se o processo foi finalizado.
Pode ter situações úteis em aplicações de banco de dados. O SGDB é perfeitamente capaz de lidar com diversos acessos ao mesmo tempo, da mesma forma que vários usuários simultâneos. Então pode ser válido se o cenário for favorável e tiver a necessidade.Trabalho com ASP.NET MVC e tenho situações onde o cliente precisa exportar para Excel relatórios complexos com fonte de dados variadas. Difícil alguém não passar por uma situação de relatório analítico que não demore segundos.
Apenas estou dizendo que seu cenário não é valido na web. um cliente nunca iria esperar 10 segundos numa requisição pra receber do servidor uma string escrito “finalizado”. Isso não tem lógica nenhuma. lol
Do ponto de vista da otimização dos recursos do servidor web, é mais indicado retornar a requisição com um “processo iniciado” ao invés de “finalizado” e fazer o cliente fazer outra requisição pra saber se o processo foi finalizado.Depende do caso que deseja atender. Não quer dizer que isso seja mais indicado que outra solução que é feita para atender outro caso. Em muitos casos o cliente faz a ação só para esperar o retorno da mesma, como você mesmo já citou em outros posts e a discussão continuou nisso. Se lá no servidor for uma situação que possa haver divisão de tarefas para processar um mesmo resultado, isso vai ajudar no tempo total da execução.
Não analise as coisas ao pé da letra. Funcional para a pessoa poder copiar e colar na Controller, podendo praticar imediatamente. O código está claro que é só para ilustrar na prática execuções em paralelo, o que você pode fazer na vida real vai ser qualquer coisa que tiver necessidade. Para fins de exemplo, uma string é a maneira mais fácil para ter algum retorno no browser. Não é esse o foco da discussão, mais uma vez você desvia o foco sem necessidade, assim como já fez nas discussões com VinyGodoy. Obviamente o retorno pode ser qualquer coisa, como um json, como um arquivo Excel a qual falei a pouco. Mesmo assim não necessariamente o retorno tem que ser algo pesado ou “palpável” se o que é feito no servidor for algo pesado, tudo depende do caso.
Então tudo depende do caso e não podemos analisar cada caso? hm… ?
O fato é que uma requisição web nunca leva 10 segundos se você tem alguma idéia do que esta fazendo. 
Depende do caso que deseja atender. Não quer dizer que isso seja mais indicado que outra solução que é feita para atender outro caso. Em muitos casos o cliente faz a ação só para esperar o retorno da mesma, como você mesmo já citou em outros posts e a discussão continuou nisso. Se lá no servidor for uma situação que possa haver divisão de tarefas para processar um mesmo resultado, isso vai ajudar no tempo total da execução.
Nuss… ta cada vez pior.
Por favor, refira ao primeiro post do matheuslmota para entender porque métodos que causam efeitos colaterais, como inserir no banco ou executar processos, não devem retornar valor.
Não analise as coisas ao pé da letra. Funcional para a pessoa poder copiar e colar na Controller, podendo praticar imediatamente. O código está claro que é só para ilustrar na prática execuções em paralelo, o que você pode fazer na vida real vai ser qualquer coisa que tiver necessidade. Para fins de exemplo, uma string é a maneira mais fácil para ter algum retorno no browser. Não é esse o foco da discussão, mais uma vez você desvia o foco sem necessidade, assim como já fez nas discussões com VinyGodoy. Obviamente o retorno pode ser qualquer coisa, como um json, como um arquivo Excel a qual falei a pouco. Mesmo assim não necessariamente o retorno tem que ser algo pesado ou “palpável” se o que é feito no servidor for algo pesado, tudo depende do caso.Então tudo depende do caso e não podemos analisar cada caso? hm… ?
O fato é que uma requisição web nunca leva 10 segundos se você tem alguma idéia do que esta fazendo. :D
De novo querer levar o exemplo de Sleep como caso real? Os 10 segundos foram para dar tempo a pessoa notar o que acontece executando o código. Se na vida real vai ser 1, 2, 5, ou até mesmo 10 segundos, isso vai ser problema de cada situação. Parece que você fala de aplicação web como se fosse só aplicações públicas na Internet, ou nunca passou por casos envolvendo grande volume de dados ou diversas fontes de dados externas a qual você não é responsável, como por exemplo web services.
Depende do caso que deseja atender. Não quer dizer que isso seja mais indicado que outra solução que é feita para atender outro caso. Em muitos casos o cliente faz a ação só para esperar o retorno da mesma, como você mesmo já citou em outros posts e a discussão continuou nisso. Se lá no servidor for uma situação que possa haver divisão de tarefas para processar um mesmo resultado, isso vai ajudar no tempo total da execução.
Nuss… ta cada vez pior.
Por favor, refira ao primeiro post do matheuslmota para entender porque métodos que causam efeitos colaterais, como inserir no banco ou executar processos, não devem retornar valor.
Se você não passa por situações do tipo, não se preocupe com isso, mas também não ignore que exista a possibilidade.
De novo querer levar o exemplo de Sleep como caso real? Os 10 segundos foram para dar tempo a pessoa notar o que acontece executando o código. Se na vida real vai ser 1, 2, 5, ou até mesmo 10 segundos, isso vai ser problema de cada situação. Parece que você fala de aplicação web como se fosse só aplicações públicas na Internet, ou nunca passou por casos envolvendo grande volume de dados ou diversas fontes de dados externas a qual você não é responsável, como por exemplo web services.
O que são aplicações privadas na internet e porque as requisições pra elas levam 1-10 segundos ao invés de 200 ms como uma aplicação web na internet “normal”?
Parece que você queria descrever uma consulta e acabou descrevendo um comando por engano então, porque até onde pude notar ProcessoDemorado1 e ProcessoDemorado2 não realizam consulta nenhuma? :\
nunca dura 10 segundos uma requisição no seu crud de faculdade…
Pq crud “profissional” não tem problema o cliente esperar 10s na mesma requisição?
vc escreveu isso
O fato é que uma requisição web nunca leva 10 segundos se você tem alguma idéia do que esta fazendo.
Você no mínimo é loko…
vc escreveu isso
O fato é que uma requisição web nunca leva 10 segundos se você tem alguma idéia do que esta fazendo.Você no mínimo é loko…
…ou seu crud esta um tanto quanto lento. kkkk
Nunca leva 10 segundos PRA SER PROCESSADA PELO SERVIDOR.
É claro que pode levar mais de 10 segundos se você usar a internet discada da sua faculdade. Mas estamos falando do tempo que o servidor leva pra processar o request. Portanto não inclui o tempo que leva para o request chegar no servidor, nem o tempo que leva pro response chegar ao cliente.
Só pra deixar claro isso pra aqueles que como vc não fizeram o dever de casa.
sim meu crud tem 4 máquinas de 128 gb de memória cada uma, somente pra banco de dados oracle(fora os servidores), alguns bilhões de registros, especialista em tunning em banco de dados, e uma infinidade de coisa pra processar no servidor pra fazer todos os dias e q levam horas e horas pra fazer. Claro que posso criar uma thread e devolver para o cliente um “sucesso” e continuar processando ou fazer por algum job, mais em trocentos casos isso de criar uma thread e devolver um “sucesso” não se aplica, e os processos ficam rodando 15, 30,45,90 minutos. Nem todo sistema é igual, então sossega a piriquita aew
Minha faculdade era federal e tinha a internet mais rápida do país.
sim meu crud tem 4 máquinas de 128 gb de memória cada uma, somente pra banco de dados oracle(fora os servidores), alguns bilhões de registros, especialista em tunning em banco de dados, e uma infinidade de coisa pra processar no servidor pra fazer todos os dias e q levam horas e horas pra fazer. Claro que posso criar uma thread e devolver para o cliente um “sucesso” e continuar processando ou fazer por algum job, mais em trocentos casos isso de criar uma thread e devolver um “sucesso” não se aplica, e os processos ficam rodando 15, 30,45,90 minutos. Nem todo sistema é igual, então sossega a piriquita aew
Minha faculdade era federal e tinha a internet mais rápida do país.
Dizer que não faz sentido usar await no request handler de uma aplicação web é o mesmo que dizer que todo sistema é igual? hehe conte-me mais…
Pra lidar com processos demorados é mais eficiente, do ponto de vista do servidor, responder com “iniciado” (não é “sucesso”, mais um sinal que não esta fazendo seu dever de casa) imediatamente e depois ir buscar o resultado (ao invés de await). Essa é a prática recomendada pelo protocolo pra lidar com processos demorados na web. Porque você não consegue aplicar na sua aplicação é que precisa ser questionado, e não a técnica usada por toda a web “publica”. 