Minha pergunta: que tipo de aplicativo requer tantos threads simultâneos de execução?
1) O fato de uma linguagem "escalar" significa que há menos chances de você abandonar essa linguagem quando as coisas ficarem mais complexas no futuro. (Isso é chamado de conceito "Produto Inteiro".) Muitas pessoas estão abandonando o Apache for Nginx por esse mesmo motivo. Se você estiver perto do "limite máximo" imposto pelo overhead de threads, ficará assustado e começará a pensar em maneiras de superar isso. Os sites nunca podem prever quanto tráfego obterão, portanto, gastar um pouco de tempo tornando as coisas escaláveis é razoável.
2) Uma goroutine por solicitação apenas no início. Existem muitas razões para usar goroutines internamente.
- Considere um aplicativo Web com solicitações simultâneas de 100, mas cada solicitação gera centenas de solicitações de back-end. O exemplo óbvio é um agregador de mecanismo de pesquisa. Mas qualquer aplicativo pode criar goroutines para cada "área" na tela e gerá-las independentemente, em vez de sequencialmente. Por exemplo, todas as páginas da Amazon.com são compostas por mais de 150 solicitações de back-end, montadas apenas para você. Você não percebe porque eles são paralelos, não sequenciais, e cada "área" é seu próprio serviço da web.
- Considere qualquer aplicativo em que a confiabilidade e a latência sejam fundamentais. Você provavelmente deseja que cada solicitação recebida ative algumas solicitações de back-end e retorne os dados que retornarem primeiro .
- Considere qualquer "associação ao cliente" realizada no seu aplicativo. Em vez de dizer "para cada elemento, obtenha dados", você pode criar várias goroutines. Se você tiver um monte de DBs escravos para consultar, você irá magicamente N tempo mais rápido. Caso contrário, não será mais lento.
atinge retornos decrescentes quando o número de threads / processos é muito maior que o número de núcleos físicos
O desempenho não é o único motivo para dividir um programa no CSP . Na verdade, ele pode facilitar a compreensão do programa e alguns problemas podem ser resolvidos com muito menos código.
Como nos slides vinculados acima, ter simultaneidade no seu código é uma maneira de organizar o problema. Não ter goroutines é como não ter uma estrutura de dados Map / Dictonary / Hash no seu idioma. Você pode sobreviver sem ele. Mas uma vez que você o possui, você começa a usá-lo em qualquer lugar, e isso realmente simplifica seu programa.
No passado, isso significava "rolar o seu próprio" programação multithread. Mas isso era complexo e perigoso - ainda não existem muitas ferramentas para garantir que você não esteja criando corridas. E como você evita que um futuro mantenedor cometa um erro? Se você observar programas grandes / complexos, verá que eles gastam MUITOS recursos nessa direção.
Como a concorrência não é uma parte de primeira classe da maioria dos idiomas, os programadores de hoje têm um ponto cego para saber por que isso seria útil para eles. Isso só se tornará mais aparente à medida que todo telefone e relógio de pulso se aproxima de 1000 núcleos. Navegue com uma ferramenta incorporada de detector de corrida.