Skip to content

Latest commit

 

History

History
71 lines (44 loc) · 4.64 KB

2022-08-29.md

File metadata and controls

71 lines (44 loc) · 4.64 KB

Encontro 001

Encontro 1

http://www.youtube.com/watch?v=W-4N2hySi5E

Assuntos

  • boas vindas
  • setup repositório
  • escolha do formato
  • escolha dos exercícios
  • data do próximo = Sept 12, 2022 (Segunda)

Links


Produtos

Do encontro

Sumários / Testemunhos

Fabricio

Foi o primeiro encontro, gastamos um bom tempo com o setup de um ambiente compartilhado, fomos de VSCode com plugin Live Share e um dev-shell do nix com latest rust instalado (nix flake init --template#rust ou algo parecido com isso foi o que usei).

Escolher algum problema simples para "molhar os dedos" demorou um tempo também, como todos somos muito iniciantes (com a excessao talvez do Luiz), a sintaxe ainda foi uma grande barreira, entao um pré-desafio foi aprender qual a forma idiomática de escrever testes de unidade.

Cargo parece ser, realisticamente falando, a ferramenta principal de criar boilerplates e usar no dia-a-dia de desenvolvimento, cargo run é essencial para algo que é compilado (evita dois comandos, um para gerar o binario e outro para executar o binário). Ter um Cargo.toml, que é o equivalente à manifest files como o package.json do Node por exemplo, e vai ser útil para incluirmos dependencias nos projetos. No encontro, o Cargo foi a resposta sobre a questao de "como escrever testes de unidade", pois o boilerplate criado para "libs", ou módulos, que é o boilerplate resultante de cargo init --lib inclui uns comentários especiais, tipo este: #[cfg(test) antes do "módulo" mod tests { e tipo estes #[test] antes de cada teste.

Como disse antes, somos um grupo que está bem no começo desta jornada mesmo, então ter estes boilerplates e ter uma pessoa com experiencia entre nós foi muito bom, aprendi que o ponto de exclamação no fim de funções como println! e assert_eq! indica que aquilo é uma macro, e foi doido ver que um tipo comum de listas, os "Vectors" sao criados via macro, algo como isso: let my_vector = vec![1, 2, 3, 4, 5]. Nesta linha, aprendi que Array é o tipo nativo e está na memória, e que vectors estao na "heap" e podem ser expandidos, algo assim...

Outra coisa que vimos tb por cima foi a questão de "traits", a funçcão final da nossa sessão inicial, que foi algo simples de ordenar listas, acabou ficando com uma assinatura de funcao que usa "generics" (T) e este T nao se importa se o input é uma Array, um Vector ou outra coisa, desde que este input "implemente" as "traits" Clone e Ord, na metáfora de POO, traits seriam algo parecido com interfaces.

Resumindo, aprendi que:
  • cargo new --lib é usado para módulos e cria um boilerplate com testes (enquanto cargo new cria um boilerplate de um binário executável)
  • variáveis são imutáveis por padrão, declaradas com a sintaxe let nome_da_var: tipo = valor e o tipo não precisa estar lá se puder ser inferido.
    • para uma variável mutavel: let mut nome: tipo = valor
  • Arrays literais podem ser declaradas com colchete direto [1,2,3,4]
  • Vetores podem ser declarados com vec![1,2,3,4] ou [1,2,3,4].to_vec()
  • traits são o "tipo do tipo", ou o "tipo do generic", ou "interfaces" e a syntaxe é ou <T: Clone + Ord> ou where T: Clone + Ord
  • ter um compilador como aliado é bacana, menos runtime errors e menos testes bestas para escrever
  • o retorno de um bloco nao precisa da keyword return, pode ser só a última linha do bloco sem o ponto-e-vírgula, tipo Helm, Rescript ou OCaml
  • o jeito de incluir uma lib é com use e no caso de estar no mesmo arquivo use super::*;
  • marcação do que é um teste e de que um modulo está configurado para testes é feito com uns comentarios especiais, tipo "ifdefs" do C: #[cfg(test)] e #[test] por exemplo.