Relato da Tonari sobre a implementação de videoconferência em “tempo real”
→ A latência do Zoom e do WebRTC fica entre 315 e 500 ms
Em vez de mexer em 750 mil linhas da stack do WebRTC para alcançar um nível de tempo real de 130 ms de latência, decidiram projetar toda a stack do zero e reimplementá-la de acordo com o hardware desejado
→ Rust foi escolhido por segurança, desempenho e manutenção
Principais crates usados
→ Melhores que a biblioteca padrão: crossbeam, parking_lot, bytes, socket2
→ Para deixar logs e CLI mais bonitos: fern, structopt
→ Ferramentas auxiliares do cargo: cargo-release, cargo-udeps, cargo tree, cargo-geiger, cargo-flamegraph
Pontos difíceis do Rust
-
O tempo de compilação é longo
-
A cobertura de bibliotecas é insuficiente
-
Exige escrever código correto e claro desde o início
-
O sistema de inferência de tipos é tão poderoso que às vezes parece que você está usando uma linguagem de tipagem dinâmica
-
A linguagem continua evoluindo
Resultados de escolher Rust
-
Não houve experiência de downtime relacionado a software
-
Foi fácil escrever código com bom desempenho graças ao uso eficiente de recursos
-
O uso de CPU e memória é previsível e consistente
-
Garante latência e taxa de quadros consistentes
-
A experiência de manutenção da base de código também foi excelente
-
No fim, criaram um produto confiável e sustentável, com desempenho rápido em taxa de quadros, latência e eficiência de recursos
→ Teria sido difícil sem Rust
Ainda não há comentários.