Goroutines são INÚTEIS para desenvolvimento backend 

Resumo do que aconteceu no vídeo. O cara respondeu sobre peras, quando perguntado sobre maçãs. Realmente, a maioria das web apps em cloud computer estão rodando em máquinas de 1 core com algum gatilho de auto scaling. No entanto, o rapaz que utiliza isso como argumento, não entende que Goroutines são corotines ou green threads e não native threads. É possível ter grande quantidade de Goroutines em um single core, isso sempre vai ser útil para problemas de IO

Gosto desse formato de vídeo. Vejo o conteúdo que o The Primeagen faz no mesmo formato, acho que ele reagiu a esse mesmo post inclusive, e vejo muito espaço pra isso na comunidade BR. Vai fundo mano! PS.: atualmente sou um fã de golang :D

Não é que o código assíncrono em Rust seja muito difícil. É que normalmente código assíncrono é muito difícil por natureza. Acontece o que o Rust oferece certas garantias para que nada quebre ao executar código assíncro. Esse é um preço a se pagar pela segurança, porque o grande objetivo do Rust é justamente a segurança da memória (memory safety). No Go o preço é permitir esse comportamento imprevisível e condições de corrida, logo você tem que colocar locks e mutext. No Erlang/Elixir o preço é copiar toda a memória quando ela é utilizada por outro processo. Cada linguagem e plataforma cobra um preço pela facilidade ou pela segurança. Aí cabe a você decidir o que é melhor para o projeto.

Já havia visto o podcast citado e o cara viajou completamente. É só mais uma das coisas bizarras que a gente encontra no youtube. Ele se referiu a algumas plataformas em que você faz o deploy. Em alguns sistemas sap por exemplo, os processos tem uma única thread. A diferença com go é que você não faz o deploy em uma plataforma virtual, mas faz o deploy de um executável estático para um processador/arquitetura diretamente. São muitos erros naquele podcast.

Conteúdo diferente, de qualidade, bem explicativo e se continuar assim vou me converter ao go kkkk

curti demais esse video, cara. não é o primeiro vídeo seu que eu vejo seu, to achando o conteúdo excelente, +1 inscrito.

As corrotinas do kotlin também são sensacionais, parabéns pelo conteúdo 😮

Muito bom conteúdo amigo! Minha empresa está migrando um sistema para Go e esse é um dos motivos, muito bem explicado!

Talvez ele se expressou meio mal, pq realmente os containers e o modo de deploy hoje me fez mudar a maneira programar algumas coisas em relação a threads e async. Mas tem muito cenário ainda que usar go routines faz todo sentido.

Pedro, boa noite. Ótimo conteúdo como sempre. Estou maratonando seus vídeos e especificamente o de assembly me abriu uma torneira de dúvidas sobre qual linguagem começar a estudar agora. Vim do java, trabalho a pouco mais de 1 ano com python e pretendo estudar uma linguagem de baixo nível tipo rust ou c, no entanto go tem me chamado bastante atenção. Já havia me decidido entre rust porém ao te ver falar da dificuldade em implementar i/o async no rust me deixou meio na dúvida e tendendo ao go novamente 😅. Se puder dar uma dica seria incrível ❤. Tmj e continue com o ótimo trabalho.

Finalmente conteúdo fácil de entender.

Te segui! Gostei muito da sua visão sobre Go

Mano, parabéns pelo conteúdo!

Muito bom! Você vai longe! Conteúdo de muita qualidade!!

Excelente video, Pedro. Blocking I/O é ruim demais :) Non-blocking I/O é vida :) Te permite jogar no lixo a concorrência e rodar tudo no mesmo thread. Fica a dica para um video futuro: non-blocking vs blocking network I/O. A minha dúvida existencial é: pra que virtual threads no Java 21 se temos non-blocking network I/O (Java NIO) há mais de 20 anos?

o codback ta inteiramente na mão dos dev das big... se a sua cloud é um ubuntu metal ou parecido vc ainda tem acesso ao hardware, logo, faz sentido performance de codigo... e ao conhece-lo...certamente java ou python e todas compiladas vão de just in time codigo burro frameworks gordos vendem pás e picaretas, então não é um mau negócio tb.. agora, pega uma vm basica gcp..4 paralelismo..4 cpu (diz que gera 8 threads mas entrega o mesmo resultado . rode um primo 1 bilhão performatico que o resultado sera o mesmo em 4 ou 9 slots hpc) continuando.... 3 cpu calculando 1+2....e a 4o cpu fazendo o role na china..eh paralelismo e concorrência. para o usuário não difere..pois eh não blocante. uma frase em alta ´ no server' ....tipo as big tech querem resolver td e vc foca no devop front...colorir botão... afinal...vc simula 4 cpu , mas, se vc não consegue instalar o ic2 (ou i2c) o drive que mede temperatura do cpu ou thermal zone vc não tem acesso a codigo performatico. vc não controla nada...alguém la na ponta vai decidir se usa ou não seus códigos performáticos....uma vm.. então como o docker sabe o consumo de cpu e memoria..? ja que não informa temperatura do core? (algoritmo deep algoritmo estimativa estatistica)... ai...19 de julho..2022...londres bate 42.9 graus..gcp caiu...defesa, saude, gamer..todo mundo...caiu...culparam a temperatura e o aquecimento global (isso não cai na prova em tic, não entra na camada osi) as big não entrega cpu fisica...apenas virtual...como então programar paralelismo. concorrência...? só se vc for arquiteto dos caras.. gcp london caiu depois que o deepmind (comprado pelo google) deu uma surra no jogadores de tabuleiro...sim...ficou todo mundo embasbacado...ai na sequencia chavecou todos engenheiros da ashrae e subiram os sets point de temperatura de datacenters para economizar 40% de energia... a matematica não fecha..a conta é antiga...performance é inversamente proporcional a temperatura... a briga dos deepmodels por performance e energia e refrigração, consomem mais energia que mineraradores (um banho de 5 minustos por prompt) provou serem demandantes da melhor implementação além de paralelismo massivo, o mesmo que derrubou a leei de moore..e mesmo deepmodels, para reduzir consumo de energia, agora dependem de deepmodels como o zeus....(python, c++) uma chance da programação backend assumir o controle do via front...via deepcod (estatistica e probabilidade) portanto, paralelismo e concorrência foram abstraídos ( ou engolidos) por deepmodel...logo, inexplicavel. zuô tudo.

Topzera Pedro. Excelente explicação.

Você pode sim fazer deploy em multi cores, basta optar por isso. Mas é exatamente o que voce falou, go routines nao é sobre paralelismo, é mais sobre concorrencia. Eu nao diria que uma go routine é como uma green thread pq go routines é bem mais leve e é exatamente por isso que o scheduler é o mais performatico, por que nao tem que lidar com uma serie de coisas que uma thread do kernel ou do usuário precisa se preocupar. É um ambiente fechado. Pra mim essa é maior sacada de Go.

Muito bom vídeo, parabéns!

imagine que voce tenha um sistema com websocket implementando um modelo pub/sub e que de 2 em 2 minutos você precisa fazer o backup das mensagens em memoria para um banco de dados. Em go é muito simples gerar uma goroutine ligada a um channel fazendo isso em background. Em um modelo síncrono eu precisaria de um serviço/instancia extra pra fazer isso funcionar.

Aposto que foi o mesmo cara que deu 32 motivos pra dizer que o typescript é melhor que o golang que falou isso 🤣

Na realidade, solucoes em containers nao fazem deploy em single core apenas. Os cgroups do linux kernel alocam pedaços do processador para o container ou seja, geralmente o processo da aplicação. Acredito que a aplicação sim pode usar mais de um core se necessário.

Para tarefas cpu intensivas que exigem compartilhamento de memória, goroutines são úteis. Exemplo : execução de algoritmos genéticos.

video brabo demais

Eu me pergunto que linguagen e feito docker e kebernets, e se for em GO, e se esse recuurso não seria extremamente importante para o desenvolvimento dessas aplicações, quando algo parece que não faz sentido para aquilo, pode ser que voces esteja so usando aquilo para a coisa errada

Top demais!!

ótimo conteúdo! tenho uma dúvida apenas, estou construindo uma Api, o correto seria implementar as controllers como async? (venho de projetos node e estou aprendendo go, e normalmente a maioria das coisas são em async nos projetos que eu trabalhei)

Muito bom, conteudo muito bom

O senhor acha que vale a pena pra um júnior estudar golang?

muito bom!

Top

top

Muito bom 🎉