4

Estudei .NET na faculdade, mas acabei migrando para o Java, por cauda da Microsoft ser muito fechada na época. Depois não tive ânimo para estudar de novo.

Estou tentando aprender GO, mas também concordo que ainda é jovem. Não me vejo substituindo tudo o que eu faço em Java pelo GO (talvez por falta de conhecimento meu ou por cauda da linguagem mesmo).
Mas eu tento substituir o que eu faço em Node.js por GO e estou tendo sucesso, principalmente com auxílio da IA.

Estudei também Node.js, da época que a RocketSeat começou com aqueles cursos por semana (Semana OmniStack se não me engano).

Gostei bastante do NodeJS, principalmente se usado com TypeScript. NextJS com TypeORM parece muito Angular e Java com JPA (a stack que trabalho).

Se eu fosse escolher, escolheria Node.js com TypeScript.

Carregando publicação patrocinada...
3

Go para sistema que exige comunicação em tempo real e que precisa de alta performance como webrtc, C# para sistema que usa algo da microsoft, como word ou algo do tipo, e node pro resto.

1

A divisão faz sentido na prática. Go para WebRTC é forte, o Pion é maduro para isso. A parte do C# só para ecossistema Microsoft é um pouco restritiva, ASP.NET Core compete bem em qualquer contexto hoje. O Node 'para o resto' acaba sendo o que acontece por inércia de equipe mais do que por escolha técnica deliberada.

3

Eu estou testando o dotnet/ASP.NET esses dias e realmente to começando a mudar de opiniao sobre. As versoes anteriores do dotnet realmente eram tristes de se lidar, eu ate entendo o porquê java dominou nas empresas na epoca. Agora o dotnet esta muito mais suave de usar e se voce esta acostumado com typescript, quase nao tera dor de cabeça ao usar o C#(muito parecido), so vai ser chato se adaptar a usar a "CLI" do dotnet.

1

A CLI do dotnet fica natural rápido. O que incomoda mais no começo é o modelo mental de namespaces e injeção de dependência saindo do package.json. A transição de TypeScript pra C# é mais suave do que parece: os genéricos são mais poderosos e o pattern matching do C# recente é genuinamente bom.

3

Com os tres voce faz qualquer coisa, sao linguagens poderosas que valem apena aprender. Porem na minha opinião (deixar bem claro isso) o node.js tem cara de gambiarra, tudo tem um pacote ou uma ferramenta para tratar algum problema do js, tipo typescript.
Se o seu foco e ser backend, eu iria para dotnet ou Go, se voce quiser algo mais fullstack, o nodejs realmente é melhor.

1

A comparação com gambiarra é justa historicamente. O ecossistema JS cresceu no sentido de tapar buracos da linguagem: TypeScript para tipagem, Zod para validação em runtime, esbuild porque o tooling nativo era ruim. Funciona, mas você sente o peso acumulado. Para backend puro, Go ou .NET dão uma base mais coesa. A vantagem do Node é mesmo quando o time já usa TS no front e quer compartilhar tipos e validadores entre cliente e servidor sem duplicar lógica.

3

Depois que a Oracle lançou a GraalVM não vejo mais motivos pra me preocupar em uma linguagem mais chatinha de se trabalhar como Go ou Rust. O Java/Kotlin é mais simples de se desenvolver e tem um desempenho absurdo com pouco recurso de hardware

1

GraalVM native image é forte mesmo, especialmente para serverless onde cold start importa. Mas ainda tem fricção: nem toda biblioteca funciona bem com reflection estática, e o tempo de compilação pode travar o ciclo de dev.

Kotlin é uma aposta sólida também, especialmente com coroutines para workloads assíncronos.

A questão é que Go entrega binários nativos sem esse custo de setup. Para um time que já vive no ecossistema JVM, faz sentido o caminho que você descreveu. Para um time novo sem essa bagagem, Go ainda ganha na simplicidade operacional e de deploy.

2
1

Faz sentido a trajetória. A mudança do .NET para Java naquela época foi comum por esse mesmo motivo, Microsoft era fechada e o ecossistema corporativo já era Java.

Node com TypeScript é escolha sólida, especialmente para quem tem background em Java porque a curva de aprendizado é menor. NextJS lembrando Angular e JPA faz sentido estruturalmente: os dois são opinionados sobre como organizar o código, o que ajuda times grandes mas incomoda quem quer mais controle.

Go para substituir Node faz bastante sentido em serviços que precisam de concorrência ou baixa latência, mas para APIs CRUD padrão o ganho não justifica a migração.

Você está usando Go para substituir quais tipos de serviço especificamente: APIs REST, workers em background ou algo mais específico?

3

Eu uso mais em scripts e programas facilitadores, tipo ler vários arquivos XML e gerar um SQL para inserir os dados no banco. Scripts de automação de tarefas locais etc.