TYPESCRIPT É MELHOR QUE GO! 32 motivos do porquê
HTML-код
- Опубликовано: 10 фев 2025
- Recentemente esse post no reddit viralizou: / anyone_who_tried_to_li...
O autor listou 32 motivos pelos quais, segundo ele, typescript é melhor que Go.
Nesse vídeo, eu mostro a minha opnião sobre esses pontos levantados.
Artigo da uber: www.uber.com/e...
--------------------------------------------
Minhas redes sociais:
✅ github.com/phe...
✅ / phenpessoa
✅ x.com/phenpessoa
✅ / phenpessoa
✅ / phenpessoa
✅ / phenpessoa
✅ / phenpessoa
Contato profissional:
phenpessoayt@gmail.com
--------------------------------------------
#golang #typescript #programação
acabei de virar fã do canal!!!
saber os pontos "fracos" da linguagem faz parte tb. Ele aponta o que foi dito dizendo, ok, é válido, sem varrer pra debaixo do tapete...
sensacional!!!
Cara, muito bom
Como sou novo no Go, estava meio travado exatamente nesse ponto do zero default values com JSON, eu estava usando ponteiro para os campos que poderiam ser nulos e essa sacada com um struct Field fica bem melhor.
Também não sabia sobre a questão de alocação de memória Heap e tals, vlw pelp vídeo.
Assisti o vídeo inteiro e nem percebi o tempo passar. Realmente estou gostando muito de Go! Sou dev PHP, gosto muito de Typescript também, mas em questão de tipagem estática prefiro Go com certeza.
Excelente, muito obrigado por ter colocado seu tempo em compartilhar seu conhecimento pra todos nós!
Se não me engano o lance de não saber quando pode retornar erro vai mudar logo. na TypeScript 5.3 Iteration Plan, esta prevista Champion throw Expressions. Acho que vai funcionar como o Java e voce vai consegutir tipar que retorna alguma execeção.
Checked exceptions do Java? Tipo
function foo() throws Error
47:24 O rapaz confundiu legal Programação Funcional com Programação Procedural.
Kakakakaka
estou aprendendo muito com esse vídeo, vc eh muito prático.
Vídeo excelente! Estarei na espera de mais conteudos!
Sei que o vídeo é antigo, mas seria legal um vídeo explicando como as alocações funcionam, com sua didática acredito que muita gente iria entender melhor sobre esses assuntos... heap, stack etc. E como você trabalha com Go, acredito que seja uma boa linguagem de exemplificar também. Outra dúvida, tu vai estar presente na Gophercon desse ano em Floripa?
Video ótimo! Precisamos de mais pessoas e conteúdos assim
Uso JS/TS ha alguns anos e comecei a estudar GO ha poucos meses! Seu video foi excelente, alem do conteúdo o video trouxe um grande aprendizado sobre a linguagem, obrigado por compartilhar esse conhecimento !
Typescript você tem níveis de "strict" que são configuráveis. Então sobrescrever funções, métodos e Objetos é possível, desde que você mantenha os tipos originais. Em suma, você tem mais controle sobre compatibilidade de coisas sobrescritas.
Sempre trabalhei com TS e N sabia q existia níveis de strict, so sabia do "use strict"
Conheci o canal hoje, estou curtindo bastante.
23:16 isso também parece válido, se ele está comparando duas linguagens (oq já é esquisito por si só, pq na vdd uma é superset de uma Lang q veio da web e outra é mais back), é completamente válido falar das praticidades da sintaxe
Essa questão dos erros serem tratados usando try catch é terrível, tanto que eu programo também em typescript e uso a abordagem Either para fugir disso.
Concordo contigo, obrigado pela disposição de tempo pra ajudar quem deseja fazer o que gosta e buscar resultados e não somente ser um funcionário.
Nice video!
Sobre acessar membros de objetos usando variáveis, é algo que só quem usa sente falta. Eu trabalho com TS e JS há anos e, por isso, vejo utilidade e já usei várias vezes. Mas não é o fim do mundo.
Omit e pick, entre outros, são parte do que ele considerou "poderoso sistema de tipagem". Neste sentido, concordo, pq o Typescript tem muitos utilitários para fazer merge, pick e omit de tipos. Facilita demais para não repetir código. Especialmente em interfaces e tipos grandes.
Muito bom o vídeo!
Eu te fato amo a sacada de go com Error handling, gosto demais da possibilidade você dita oque é uma função assíncrona como cliente da função, isso é perfeito por você não amarrar a função(uso C# e tem hora que dá um trabalho!)
Eu não trabalho com Go, mas venho programando em V, se você baixasse e testasse quase não sentiria dificuldade pois é bem parecido com Go, mas tem coisas de V que prefiro.
Enfim, ótimo vídeo!
Sobre 24:19, você dizer que Go tem tudo na biblioteca padrão, é uma expressão muito forte em. Tudo que você citou que o Go tem na biblioteca padrão o Node também tem. Mas se tem uma coisa que você ta certo, é dizer que o amigo ai parece estar querendo programar typescript no Go, o que de fato concordo que nunca vai rolar.
22:08 não entendo qual a pira de querer limitar quantidade de dependências.
Não existe pontos negativos no TS além do package.json ficar grande. E existe inúmeros pontos positivos, além de que em Node não deixa o código pesado, não sei em go, mas o sistema do Node não acontece isso.
Não conheço alguém melhor para debater esse assunto! Adorei
verdade Maria
Se map, filter, reduce forem implementados de forma lazy ele tem boa performance, seria guardar quais operações fazer e só executar ela quando precusar, todas de uma vez quando você percorre uma única vez. Rust implementa de forma lazy e ainda otimiza para converter em loop simples em tempo de compilação
Comecei a estudar Go recentemente e o deus algoritimo me trouxe esse canal. Mt bom ver um seniorzão na linguagem pra ter noção das possibilidades da linguagem. Ótimo trabalho!
9:22 zig lida com isso mto bem, nesse quesito eu discordo bem, não é uma boa desculpa uma Lang não saber lidar com json, visto q ele é um formato mto usado para requisições web.
Pedro você disse que o assincronismo em go não é definido na assinatura da funcão mais sim por quem chama ela, ao contrário do typescript que sempre precisa assinar retornando uma promise, porém, o assincronismo é um sim definido na assinatura da funcao na maioria dos casos, pois geralmente para go routines a funcao precisara receber como parametro o wait group ou channel para poder controlar a concorrencia e comunicacao entre as threads
quando a turma fala de framework chega doi no figado, se os frameworks acabarem morre metade dos devs
Pedro é mestre!
14:30, tá falando de Utility Types como o Omit ou Partial do Typescript. Realmente são uma mão na roda, mas não ter isso no Go é desvantagem? Faz um pouco de falta pra quem usa, mas dá pra contornar isso de outras formas.
16:52 esse tipo de coisa é a mesma coisa q usam pra criticar o uso de TS. Type ghost é o maior problema do superset, mas nos meus códigos mais atuais simplesmente não existe type ghost além das declarações globais..
Acho que no item 5 voce nao entendeu, a reclamação dele foi em relação a ser implicito, em typescript se voce ta implementando uma interface voce deve colocar X implements Y, isso fica explicito , em GO isso nao ficou explicito.
Assim como Java, C# quando voce bate o olho voce ve que aquela classe Implementa uma interface porque vai estar escrito Implements.
51:02 cara isso é um fato kkkk, o TS realmente supera na tipagem
Pedro, no minuto 9:50, quando você fala de não usar os ponteiros, como você recomendaria a abordagem? Eu tenho um pequeno sistema onde nós estamos usando dessa forma por conta do mapeamento do banco de dados, onde o null value é significativo e não encontrei outra forma de fazer, vi a questão do field, mas confesso que não entendi como aplicar no meu caso, se tiver algum vídeo | artigo que detalha mais sobre isso, ficarei agradecido!! ötimo vídeo, parabéns
Usa os tipos sql.nullstring, sql.nullint32 etc... declare o pacote database/sql
16:28 discordo completamente. Como ele iria querer criticar Json que é um tipo de dado? Realmente é meio complicado criticar uma linguagem por seu lsp não ler json, visto que json foi feito inicialmente pro js, mas isso pode sim ser destacado como um grande benefício do ts
Manow você tem algum vídeo explicando o context em Go? Estou iniciando os estudos
Esse ponto do Node Modules é um ponto interessante, simplesmente é um inferno gerenciar tanta dependencia, lembrar quais vc tem que instalar para fazer tal coisa, sem contar no que eu chamo de "modo hype", onde a cada semana existem 15 novas bibliotecas para fazer algo que já fazia antes, sem contar que as proprias bibliotecas se atualizam, estudar e implementar esse tipo de linguagem é completamente volátil, no meu server as coisas podem simplesmente não funcionar o que acabei de fazer, e o que acabei de estudar pode está totalmente obsoleto, pq essas dependências se atualizam como uma célula se divide.
O int começar com zero e triste. Pois podemos ter dados sem resposta. Num formular de idade, posso ter a possibilidade de não ter a resposta ainda, se iniciar com zero, pode pensar que tem meses de vida ou ainda não nasceu. Teria que ter um outro campo para indicar que a idade está definida ou não.
Qual extensão vc está usando pra traduzir a seleção?
47:30 Currying/funções parciais são funções que recebem múltiplos parâmetros usando múltiplas funções, vem do funcional, seria algo como
const sum = (x) => (y) => x + y
const soma = sum(10)(20)
ou
const somar10em = sum(10)
const vinte = somar10em(10)
const cinquenta = somar10em(40)
E é possível em Go, e, na verdade ele ser mais restrito com tipos é até algo bom, a linguagem que meio que já vem com currying por padrão é Haskell, que é fortemente tipada também xD
func sum(x int) func(int) int {
return func(y int) int {
return x + y
}
}
func main() {
fmt.Println(sum(5)(10))
somar10 := sum(10)
cinquenta := somar10(40)
fmt.Println(cinquenta)
}
Olá galera, sou iniciante em programação e gostaria de saber o por que o pedro diz que pode haver algo de errado quando o código precisa iterar sobre uma chave de uma estrutura, alguem pode me explicar ?
Go é muito mais fácil de aprender e muito melhor de executar os projetos!
Sobre frameworks eu acho que o mano estava certo, nao é que nao tenha em outras linguagens é que facilita enquanto o pessoal do go parece que quer constuir tudo do zero. Uma tara por performance que as vezes é um saco
Muito bom vídeo, analisou de forma imparcial até demais, se fosse eu, teria parado no meio do post pelo autor ter ZERO credibilidade e usar argumentos completamente vazios e idiotas. Mas ainda assim, tu analisou imparcialmente e analisou argumento por argumento, considerando quando ele falava algo minimamente válido. Só acho que podia pegar no final do vídeo e procurar algum comentário do pessoal do post, porque tenho certeza que esse cara foi bastante criticado por meter tanto skill issue sem sentido como problema de outra linguagem que só é diferente do amadinho JS dele. (Eu gosto de JS também, mas ver o que esse cara tava falando tava doendo no meu pâncreas)
43:21 Poxa, condição de corrida pode-se ter com qualquer linguagem de programação, mesmo com TS. Até no Erlang/Elixir que tem o melhor modelo de concorrência (na minha opinião) não é difícil ter condições de corrida. Realmente não entendi essa daí.
28:00 ent isso só é ruim. No js, temos webpack e babel pra esse problema, que compila código atual js para código mais antigo 👍
Acho que o grande ponto do criador do post nao é reclamar individualmente de cada feature que ele nao gosta em Go. Está mais para a quantidade de coisa junta que ele nao gosta, que cria uma barreira de uso, no ponto de vista dele.
A pessoa pode pegar um graveto e quebrar com facilidade, mas quando 20 gravetos estao juntos, pra quebrar é muito mais difícil. Entao cada argumento que ele levanta pode parecer fraco. Mas juntando tudo, realmente. A diferença começa a ficar chata pra quem tá acostumada a tanta utilidade e facilidade no TS.
Pelo que vi, ele queria usar typescript no go, cada linguagem tem sua propria forma de se escrever
creio que no comentario 8 sobre picking/omitting do typescript vc pode usar o Pick ou Omit do TS para pegar somente 1 atributo da interface ou omitir um atributo especifico da interface de origem
É isso mesmo! Não conhecia
Go é bem legal,a performance bem massa. Mas eu acho a tipagem do Typescript muito massa principalmente os tipos auxiliares que vc não entendeu como o Pick e Omit que é sensacional. O dia que tiver um compilador Typescript que transforme a linguagem em código de máquina realizando otimizações aí não haverá concorrência hehehe
não querendo corrigir mas ja corrigindo eu vejo muitos desenvolvedores falando sintaxe pronunciando sin-ta-qui-se, mas o certo é sin-ta-si
Depois de ouvir as explicações fiquei com o artigo kkkkkk. Go parece muito confuso mesmo. Eu pessoalmente estava pensando em aprender uma nova linguagem e estava na dúvida entre Go e Rust. O que você recomendaria? Poderia fazer um comparativo entre ambas?
uma verdadeira aula sobre Go
Com 15 anos de back me sinto um junior perto desse cara, to saindo de php e indo pro Go. Esse post é de um programador pleno q ta 20 anos na area.
Quem sabe um dia Go implementa um Result do Either - Error Handling in Functional Programming. Em Rust isso funciona.
Com relação ao que vc fala nos 15min de video o typescript tem alguns utility types como Omit, Pick, Exclude e etc...
Vim pela polemica e ganhei uma aula, me inscrevi!
Quem não tem experiência na área Go não é boa opção comparado nodejs ou php ou c#?
Realmente essa questão de poder pegar so alguns campos usando o OMIT no typescript se mostra muito útil as vezes, mas não é algo que mostra que go é pior ou melhor, toda linguagem tem suas facilidades.
Excelente conteúdo!!! Typescript🎉🎉
typescript eu nunca usei, mas precisando eu usaria tranquilamente lendo a documentação.
O cara do post querer comparar Go com TS é sacanagem. Cada linguagem tem propósitos, causa e consequências complemente diferentes.
Alguns pontos como nill ou zero value são ate validos, mas o resto...
a defesa de go mais saudosista q eu ja vi HAUAHUAUHHAU
27:38 sim, isso é horrível.
É uma crítica totalmente válida
simplesmente algumas coisas são melhores em GO, principalmente a performance. Mas, é irrefutável que outras são muito melhores em TS. Mas, cada um com seu funcionamento e idea de application
11:30 Essa abordagem seria para campos opcionais né? No caso de campos nullable acho que não tem como fugir de usar um pointer.
Edit: brincando aqui vi que a gente poderia substituir o campo Valid por dois (Present e Null) e montar um UnmarshalJSON pra setar os booleans de acordo.
Serve tanto pra campos opcionais como nullables
Mas, se você não quiser usar ponteiros e o campo puder vir nulo do json, vai ter que criar um custom unmarshal e marshal mesmo
Muito boa a ideia de usar dois campos!
Sobre os erros, eu acho que a stacktrace é mais valiosa do que valores. Você sabe exatamente o lugar e a lógica que gerou o erro só de olhar pro stacktrace. Dar manutenção em coisas antigas é muito mais fácil com stacktrace do que com código de erro.
@HugoSantAna7 é uma opinião válida, mas o ponto dele continua errado. Se você quiser colocar stacktraces nos erros em Go, você pode, e não precisa de bibliotecas de terceiros pra isso. Apenas com a linguagem você consegue.
Fala Pedrão! Cara sou do Js e cai de paraquedas nesse vídeo quando fui buscar sobre go. De fato estranhei muito e é muito diferente das concorrentes. Acha que compensa "largar" o JS pelo Go?
Não, use os dois. Aprenda Go, Java (ou dotnet que é bem melhor), Python e continue usando JS. Eu escrevo solucões que usam mais de uma linguagem no mesmo projeto, isso é bem util. Cada linguagem tem seu forte e sua aplicacão. Usar Go + JS é bem interessante, ou JS +GO
Cara que conteúdo massa, eu programo em Go desde 2015 e jamais considerei saber tudo, esse post é pura ignorância e confusão :) esperando mais conteúdo de Go ;)
38:38 meio zoado msm, prefiro os arrays do zig em questão de performance
Gosto muito de Go e lutando muito por uma primeira oportunidade profissional com a linguagem, mas linguagem "well designed" de verdade não é TS (kkkkkkk), é Kotlin
44:29 ué manokkkk,
Algo ruim existe na lang: a
Pedro: na vdd isso é bom
Você não precisa ficar usando todos os loops ao mesmo tempo
Os loops em TS/JS (forEach, map, etc.) só são usados em sequência quando necessários. Você pode fazer um único loop forEach e realizar tudo dentro do forEach sem percorrer o loop novamente. Mas você pode fazer dentro do map tambem, ou do reduce. Enfim. O fato de você ter estas opções sao realmente qualidade de vida. Mas eu concordo com vc que isso pode implicar em perda de performance, só pq é mais "fácil" e o sujeito esquece da performance muitas vezes. De toda forma, pra alguém habilidoso, é melhor ter do que nao ter. Entao nao concordo com seu argumento, neste caso.
Discordo, acredito que não tenha nada a ver com ser habilidoso ou não. Todos esses métodos alocam um novo array em memória, e muitas das vezes o que você faz dentro deles poderia ser feito em um loop simples sem nenhuma alocação.
Fora que, o forEach por si só já pode causar um grande impacto na performance, já que ele tem o overhead de chamar uma função para cada iteração do loop, diferente de um loop normal.
Outro ponto é que GO poderia implementar esses métodos com lazy evaluation, como no Java. Mantendo a performance parecida com um loop normal...
Em node, atualizar uma dependência pode literalmente quebrar o seu projeto inteiro. Isso é muito embaçado...
Que vídeo bom
Esse ponto aos 15 minutos, acho que é válido... Se por algum motivo a struct A mudar sua estrutura, vc só precisaria mudar ela e refletiria em todos que tem A como propriedade, criar um novo X string como vc comentou não parece uma boa ideia se ele significar a mesma coisa que o X da struct A... Imagina só A mudar e vc ter que alterar em todos os lugares os campos que fingem ser o mesmo conceito de X, mas não possuem nenhuma amarração direta?
Faz total sentido!
Nesse caso, em Go, eu criaria uma estrutura comum que teria apenas esses campos compartilhados
E aí eu deixaria essa estrutura “embedada” nas outras… Mas eu realmente não conhecia esses métodos de tipo em typescript como o Pick, por exemplo… Achei bem interessante!
Concordo com você
Terminei agora de ver o vídeo, muito bom! Uma pílula de conhecimento!
Nao acho que o usuário do post do reddit disse que o sistema de Typescript é mais forte que do Go. Acredito que ele disse que é melhor, mais avançado e mais completo. Você pode navegar entre níveis de tipagem dinâmica e estrita, além de ter todas as ferramentas de tipo que faltam em Go. Nessa eu concordo com ele. E acho que no 30 vc considerou este ponto da forma errada.
Golang: 200 Vagas de emprego
JavaScript/Ts: 65.000 Vagas de emprego
pow, ser tratado zero como inválido é f, se for pra ser inválido que se faça uma tratativa pra isso, agora a linguaguem por si so dar erro pq é zero. ate por que os exemplos dados são especifico.. id do banco que é incremental.. pow.. tem varias e varias situações que o valor por ser zero.
Ops. Ia comentar no tabnews. O post saiu de lá?
Só meus 2 centavos sobre currying. Linguagens mais modernas como rock nem estão implementando. Outras linguagens com Rescript e Elm estão tirando ou com propostas para tirar o currying.
Erros como valores foram a melhor invenção da humanidade
Linguagem X é melhor que a Linguagem Y é algo tão "segunda série" na programação. É algo que já deveríamos ter superado. Não existe esse negócio de "linguagem X é melhor que linguagem Y". É mesma coisa que ver um texto "porque um serrote é melhor que um alicate". Não vejo sentido nenhum nesse tipo de comparação.
Seria muito melhor o texto ser "por que eu gosto mais de Typescript do que do Go". Eu nem perderia tempo com um texto desse, pois dá a impressão de ser escrito por alguém leigo em linguagens de programação.
28:40 o cara quer comportamento de linguagem fracamente tipada em linguagem fortemente tipada
24:11 imagina eu não usar uma linguagem pq a comunidade me deixa ofendido 😂
21:12 KKKKKKKKKK aqui vc viajou manin, como assim algo bom na linguagem é um defeito? KKKKKKKKKKK
Tendo em vista que qnd se cria um programa complexo, vc provavelmente vai usar requisições, e que a maioria das requisições vão usar json, é obviamente uma vantagem do TS isso.
Quanto mais vejo isso, mais gosto de Java.
Overload de função eu não concordo com vc. É muito mão na roda. Especialmente pq dar nome semântico pra funções é um saco. Imagina fazer uma função concat() que aceita arrays, strings, numbers, etc, sem overload? Vc criaria um nome pra cada. Isso no nível basico. No nível de negócio, as coisas começam a complicar ainda mais. Especialmente pra dar nomes. Então poder fazer overload é excelente. Nao vejo benefício na simplicidade neste caso.
Typescript nem é linguagem, por que comparar com uma linguagem?
Quem escreveu esse artigo coda fofo demais kkkkkkkk
Typescript nem runtime oficial tem. kkkk
O Deno e Bun estão tentando resolver essa definiciência mas no final eles apenas transpilam para Javascript manda tudo pro JIT do V8/JSC.
Typescript é simplesmente um superset de Javascript, que apesar de popular é uma das linguagens e ecossistemas mais problemáticos que existem.
O nome da linguagem ja diz tudo Script. Typescript/Javascript é bom para fazer script, mas não é bom para construir coisas robustas e performáticas como o Go.
Trabalho com Typescript, e concordo com você. Javascript no geral, é caótico.
Golang >>>>>>> Typescript
como dizer que você é junior sem dizer que você é junior
typescript não deveria nem ser chamado de linguagem é uma bosta o typescript, estão usando pra tudo no front-end o uso de typescript não faz o menor sentido, deixa a preocupação com tipo para o back-end já com suas próprias linguagens, c#, java, go e logico a mais querida Rust, no front as preocupações deveria ser outras com ter uma animação cativante que envolva o usuário, ser detalhista na experiência do usuário, se preocupar em fazer as coisas mais performáticas no front como animações em 60 fps entre muitas outras preocupações, se preocupar com tipo no front não faz menor sentido, sem falar que a semântica na escrita de código typescript.... o typescript é uma maquinação da Microsoft para tentar manipular o front no futuro e tirar o javascript da jogada e a liberdade que a linguagem te dar por não ter um dono TYPESCRIPT É UMA BOSTA.......
piada