Entendo o .NET, mas acho que Rust está mais na mesma posição que Go. De qualquer forma, imagino que os projetos e bibliotecas de JS relacionados a Go que já existiam também tenham influenciado a decisão.
É realmente uma ideia bem original, mas, como disseram em outros comentários, também fico curioso para saber como eles pretendem resolver o problema caso o tráfego dispare.
> Se o código do TypeScript deixar de ser escrito em TypeScript, a equipe deixará de usar o TypeScript diretamente, o que pode afetar a experiência de desenvolvimento no longo prazo.
Dizem que é preciso comer a própria comida, ou seja, usar diretamente aquilo que você mesmo criou. Mas, no caso de uma linguagem, isso realmente faz pensar um pouco.
No entanto, para adotar tecnologias mais recentes (?), o JUnit4 frequentemente acaba atrapalhando, então pessoalmente tenho um pequeno desejo de que houvesse uma migração para o JUnit5. https://docs.gradle.com/develocity/test-distribution/
Usando o junit-vintage-engine, é possível executar testes em JUnit4 no JUnit5 sem grandes alterações, mas o overhead é considerável. (fica cerca de 20% mais lento)
Como alguém que, de alguma forma, acabou se estabelecendo como engenheiro de build de apps Android, deixo minha opinião...
> Build: gradle
Mesmo sendo muito grande ou complexo, é preciso usar gradle... (olhando para o horizonte)
Como os projetos abaixo estão em andamento para melhorar o desempenho de build do gradle em projetos muito grandes ou complexos, se você já usa gradle em um projeto grande, é bom se preparar para a migração com antecedência.
Pessoalmente, não vejo motivo para expor as camadas de arquitetura no sistema de build.
No caso do app que eu mantenho, fazemos com que feature-api / feature-impl fiquem expostos no sistema de build como módulos.
feature-app :
modelo de dados, ou interfaces integradas com outros módulos
feature-impl:
implementação real da feature
Com essa estrutura, alterações no código de feature-impl não afetam outros módulos que referenciam feature-api (isolamento de dependências), o que ajuda bastante no incremental build e no aumento da taxa de acerto do build cache.
> Teste unitário - junit 4
Acho que a decisão do Google teve um papel importante nisso.
Parece que esses serviços que limitam frequência ou tempo estão voltando a ficar na moda, mas acho que pode acabar sendo só um brilho passageiro e desaparecer, como aquele app que fez sucesso um tempo atrás — não lembro exatamente o nome — em que as pessoas meio que falavam como se fosse uma transmissão.
Carga de CPU de 100% em um computador não é normal, mas
quando a carga de trabalho humana chega a 100%, a conclusão é que é preciso se esforçar ainda mais...
Hum... como observação paralela, nos últimos anos tem sido observado um fenômeno curioso: a maioria das startups vai de Flutter, enquanto grandes empresas como META e OpenAI vão de nativo..
Que boa notícia! Curiosamente, a linguagem TypeScript da MS parece fazer muitas escolhas realmente inesperadas, ao contrário do que se imaginava. Do ponto de vista da MS, sendo praticamente o seu primeiro projeto open source, também pareceu uma decisão muito sensata tentar complementar o JS, ao contrário do Dart do Google, que buscava substituí-lo; e nesta nova linguagem para port nativo, embora devesse ter várias linguagens próprias à disposição, também surpreende o fato de terem escolhido o Go, do Google.
Visitar o McDonald's parece ser fácil. Parece que vai ser uma experiência divertida.
Entendo o .NET, mas acho que Rust está mais na mesma posição que Go. De qualquer forma, imagino que os projetos e bibliotecas de JS relacionados a Go que já existiam também tenham influenciado a decisão.
É realmente uma ideia bem original, mas, como disseram em outros comentários, também fico curioso para saber como eles pretendem resolver o problema caso o tráfego dispare.
Parece que você está falando de um runtime como o Node, mas o que está sendo mencionado aqui é o compilador da própria linguagem TS.
> Se o código do TypeScript deixar de ser escrito em TypeScript, a equipe deixará de usar o TypeScript diretamente, o que pode afetar a experiência de desenvolvimento no longo prazo.
Dizem que é preciso comer a própria comida, ou seja, usar diretamente aquilo que você mesmo criou. Mas, no caso de uma linguagem, isso realmente faz pensar um pouco.
No entanto, para adotar tecnologias mais recentes (?), o JUnit4 frequentemente acaba atrapalhando, então pessoalmente tenho um pequeno desejo de que houvesse uma migração para o JUnit5.
https://docs.gradle.com/develocity/test-distribution/
Usando o
junit-vintage-engine, é possível executar testes em JUnit4 no JUnit5 sem grandes alterações, mas o overhead é considerável. (fica cerca de 20% mais lento)Como alguém que, de alguma forma, acabou se estabelecendo como engenheiro de build de apps Android, deixo minha opinião...
> Build: gradle
Mesmo sendo muito grande ou complexo, é preciso usar gradle... (olhando para o horizonte)
Como os projetos abaixo estão em andamento para melhorar o desempenho de build do gradle em projetos muito grandes ou complexos, se você já usa gradle em um projeto grande, é bom se preparar para a migração com antecedência.
> Estrutura de módulos: separação por feature
Pessoalmente, não vejo motivo para expor as camadas de arquitetura no sistema de build.
No caso do app que eu mantenho, fazemos com que feature-api / feature-impl fiquem expostos no sistema de build como módulos.
Com essa estrutura, alterações no código de feature-impl não afetam outros módulos que referenciam feature-api (isolamento de dependências), o que ajuda bastante no incremental build e no aumento da taxa de acerto do build cache.
> Teste unitário - junit 4
Acho que a decisão do Google teve um papel importante nisso.
No entanto, o plugin de screenshot testing lançado recentemente é baseado em JUnit5.
Parece com o Clubhouse, né? Foi exatamente isso que me veio à cabeça também.
Parece que esses serviços que limitam frequência ou tempo estão voltando a ficar na moda, mas acho que pode acabar sendo só um brilho passageiro e desaparecer, como aquele app que fez sucesso um tempo atrás — não lembro exatamente o nome — em que as pessoas meio que falavam como se fosse uma transmissão.
Que honra para a família Huh, haha.
Parece que o tráfego vai se concentrar enormemente só nesse horário, então vai ser necessário um processamento eficiente.
Fico preocupado que, mais tarde, a manutenção do codebase TypeScript existente acabe sendo negligenciada.
O desenvolvimento da linguagem C# não parou, mas dá muito a sensação de que os frameworks que usam C# estão sendo deixados de lado.
Estou testando e passa uma sensação de pacote completo.
Textos parecidos vivem se repetindo, mas a ganância humana não tem fim e os mesmos erros continuam sendo repetidos
Carga de CPU de 100% em um computador não é normal, mas
quando a carga de trabalho humana chega a 100%, a conclusão é que é preciso se esforçar ainda mais...
Hum... como observação paralela, nos últimos anos tem sido observado um fenômeno curioso: a maioria das startups vai de Flutter, enquanto grandes empresas como META e OpenAI vão de nativo..
Pois é, mas também dá pra entender como os desenvolvedores de .NET se sentem...
Que boa notícia! Curiosamente, a linguagem TypeScript da MS parece fazer muitas escolhas realmente inesperadas, ao contrário do que se imaginava. Do ponto de vista da MS, sendo praticamente o seu primeiro projeto open source, também pareceu uma decisão muito sensata tentar complementar o JS, ao contrário do Dart do Google, que buscava substituí-lo; e nesta nova linguagem para port nativo, embora devesse ter várias linguagens próprias à disposição, também surpreende o fato de terem escolhido o Go, do Google.
Os desenvolvedores de .NET e Rust ficaram bem irritados.
Brother, atualização forçada de firmware para impedir o uso de cartuchos de tinta de impressora de terceiros