Redis é bom, mas.

 

É um texto muito perspicaz, continuo lendo e relendo.

 

Parece que as mudanças dos tempos estão rápidas demais mesmo :(

 

Parece que não há muitos modelos abertos de TTS com suporte a coreano. Ouvi dizer que o Kokoro-82M, lançado há algum tempo, suporta coreano, mas também ouvi comentários de que a qualidade não parece ser tão boa. Dando uma pesquisada rápida, vi que dizem que dá para criar e usar algo com GPT-Sovits ou que com algo como Edge-TTS o resultado fica razoavelmente bom.

Ultimamente, enquanto faço vibe coding, acho que se juntar isso com Whisper pode sair algo interessante, mas ainda não tenho nenhuma ideia haha

 
jokerized 2026-01-16 | comentário pai | em: Rust é mais rápido que C? (steveklabnik.com)

Em sistemas embarcados, a gente programa levando em conta até o tamanho da linha de cache do hardware. No fim, a questão é até onde o programador consegue levar a otimização extrema na linguagem e também o desempenho da biblioteca padrão e do compilador; como ambos oferecem suporte a baixo nível, parece que a diferença de overhead entre os dois deve ser mínima. Então não parece ser uma discussão tão significativa... Se for necessária uma otimização extrema, no fim das contas a intervenção humana acaba sendo necessária. Os compiladores não são tão perfeitos quanto se imagina.

 

Tenho dúvidas se o coreano está funcionando bem.

 
aer0700 2026-01-16 | comentário pai | em: Rust é mais rápido que C? (steveklabnik.com)

Em média, não sei qual linguagem seria a mais rápida, mas acho que a dispersão no C++ deve ser a maior.

 

E a primeira foto realmente parece uma cena de filme de gênero pós-apocalíptico.

 

(habilidade de programação = o mínimo para entrar no jogo) T_T

 
galadbran 2026-01-16 | comentário pai | em: Rust é mais rápido que C? (steveklabnik.com)

Você não fez isso de propósito, né? rs

 
secret3056 2026-01-16 | comentário pai | em: Rust é mais rápido que C? (steveklabnik.com)

O Zig também não é ruim... T_T

 

De qualquer forma, o nível certamente é diferente quando alguém com conhecimento de composição e criatividade usa isso, em vez de uma pessoa comum só ficar clicando, né?

 
xguru 2026-01-16 | comentário pai | em: 25 anos da Wikipédia (wikipedia25.org)

O próprio site original é muito bom, mas ainda não há tradução para o coreano.

 

task_plan.md é igual ao método que eu estava usando atualmente. Seria muito conveniente se isso fosse feito automaticamente.

 

O GitHub Actions deveria fazer apenas setup de ambiente (SO, toolchain de build, …) e executar scripts (shell, Python, bat, ps1…). Mesmo que o GitHub caia, se o ambiente estiver pronto, deveria ser possível fazer o build em qualquer lugar. Quando vejo os workflows do GitHub Actions hoje em dia, fico pensando se realmente precisa ir atrás e usar até esse tipo de coisa. Há muito tempo atrás (?) o Ansible foi por esse caminho e acabou fracassando.

 
iolothebard 2026-01-15 | comentário pai | em: Rust é mais rápido que C? (steveklabnik.com)

Acabei escrevendo num estilo de resumo de IA T_T

 
iolothebard 2026-01-15 | comentário pai | em: Rust é mais rápido que C? (steveklabnik.com)

Acho que Rust vai acabar sendo mais um substituto de C++ do que de C. C é praticamente a única (talvez a última) linguagem em que dá para imaginar o código que o compilador vai gerar…

 

Será a era em que Architecture e QA Engineer sobreviverão. Julgar se isso está certo ou não...