Artigo de Sam Whited, publicado originalmente pelo The Go Blog. A tradução foi feita pela Redação iMasters com autorização. 

Introdução

No dia anterior à GopherCon, um grupo de membros da equipe Go e colaboradores se reuniram em Denver para discutir e planejar o futuro do projeto Go. Este foi o primeiro evento desse tipo, um marco importante para o projeto Go. O evento incluiu uma sessão matinal girando em torno de discussões focadas sobre um tema e uma sessão vespertina composta por mesas redondas em pequenos grupos de discussão.

 

Compilador e tempo de execução

O compilador e a sessão de tempo de execução começaram com uma discussão sobre a refaturação gc e ferramentas relacionadas em pacotes importáveis. Isso reduziria a sobrecarga nas ferramentas principais e nos IDEs que poderiam incorporar o próprio compilador para fazer uma verificação rápida de sintaxe. O código também pode ser compilado inteiramente na memória, o que é útil em ambientes que não fornecem um sistema de arquivos ou para executar testes continuamente enquanto você desenvolve para obter um relatório ao vivo de quebras. Mais discussões sobre se deve ou não prosseguir esta linha de trabalho provavelmente serão abordada nas listas de discussão no futuro.

Houve também uma grande discussão em torno da ponte entre o código de assembly otimizado e Go. A maioria do código criptográfico em Go é escrito em assembly por motivos de desempenho; isso dificulta a depuração, a manutenção e a leitura. Além disso, uma vez que você se aventurou na montagem da escrita, muitas vezes você não pode chamar de volta para Go, limitando a reutilização do código. Uma reescrita em Go facilitaria a manutenção. Adicionando um processador intrínseco e melhorando o suporte para matemática de 128 bits melhoraria o desempenho de criptografia de Go. Foi proposto que o novo pacote de math/bits vindo em 1.9 poderia ser expandido para este propósito.

Não sendo tão familiar com o desenvolvimento do compilador e tempo de execução, isso para mim foi uma das sessões mais interessantes do dia. Aprendi muito sobre o estado atual do mundo, os problemas e para onde as pessoas querem ir daqui.

 

Gerenciamento de dependência

Após uma atualização rápida da equipe de dep no status do projeto, a sessão de gerenciamento de dependência gravitou sobre como o mundo Go funcionará uma vez que o dep (ou algo parecido com dep) se torna o principal meio de gerenciamento de pacotes. Trabalhar para tornar Go mais fácil de se iniciar com e tornar a dep mais fácil de usar já está sendo feito. No Go 1.8, foi introduzido um valor padrão para o GOPATH, o que significa que os usuários só precisarão adicionar o diretório bin do Go para o seu $PATH antes que eles possam começar com dep.

Outra melhoria de usabilidade futura que dep deve permitir, é permitir que o Go funcione a partir de qualquer diretório (não apenas um espaço de trabalho no GOPATH), para que as pessoas possam usar as estruturas de diretório e os fluxos de trabalho que eles costumam usar com outras linguagens. Também pode ser possível tornar a “instalação” mais fácil no futuro, orientando os usuários através do processo de adicionar o diretório bin ao seu caminho, ou mesmo automatizando o processo. Existem muitas boas opções para facilitar o uso das ferramentas Go e a discussão provavelmente continuará nas listas de discussão.

 

A biblioteca padrão

As discussões que tivemos em torno do futuro da linguagem Go são principalmente abordadas na publicação do blog de Russ Cox: Em direção ao Go 2, então vamos passar para a sessão da biblioteca padrão.

Como colaborador da biblioteca padrão e subrepos, esta sessão foi particularmente interessante para mim. O que se passa na biblioteca padrão e subrepos, e quanto ela pode mudar, é um tópico que não está bem definido. Pode ser difícil para a equipe do Go manter uma grande quantidade de pacotes quando eles podem ou não ter alguém com experiência específica no assunto. Para fazer correções críticas para os pacotes na biblioteca padrão, é preciso aguardar 6 meses para uma nova versão do Go ser lançada (ou uma versão do ponto deve ser lançada no caso de problemas de segurança, o que drena os recursos da equipe). Um melhor gerenciamento de dependências pode facilitar a migração de alguns pacotes fora da biblioteca padrão e em seus próprios projetos com seus próprios horários de lançamento.

Houve também uma discussão sobre coisas que são difíceis de alcançar com as interfaces na biblioteca padrão. Por exemplo, seria bom se o io.Reader aceitasse um contexto para que o bloqueio das operações de leitura pudesse ser cancelado.

Mais relatórios de experiência são necessários antes que possamos determinar o que irá mudar na biblioteca padrão.

 

Ferramentas e editores

Um servidor de linguagem para editores para uso foi um tópico quente na sessão de ferramentas, com uma série de pessoas pedindo para que IDE e desenvolvedores de ferramentas adotem um “Servidor de Linguagem Go” comum para indexar e exibir informações sobre código e pacotes. O Protocolo de Servidor de Linguagem da Microsoft foi sugerido como um bom ponto de partida devido ao seu amplo suporte em editores e IDEs.

Jaana Burcu Dogan também discutiu seu trabalho sobre o rastreamento distribuído e como as informações sobre eventos de tempo de execução poderiam ser mais fáceis de adquirir e de serem anexadas a traços. Foi proposto um padrão de “contador” API para reportar estatísticas, mas relatórios de experiência específicos da comunidade serão necessários antes que essa API possa ser projetada.

 

A experiência do colaborador

A sessão final do dia foi sobre a experiência do colaborador. A primeira discussão foi sobre como o fluxo de trabalho Gerrit atual poderia ser facilitado para os novos colaboradores, que já resultou em melhorias na documentação de vários repositórios e influenciou a oficina dos novos colaboradores poucos dias depois!

Fazer com que seja mais fácil encontrar tarefas para trabalhar, capacitar os usuários para executar garndening taks no rastreador de problemas e facilitar a localização de revisores também foram considerados. Esperamos ver melhorias nessas e em mais áreas do processo de contribuição nas próximas semanas e meses!

 

Sessões de discussão

À tarde, os participantes se dividiram em grupos menores para ter discussões mais aprofundadas sobre alguns dos tópicos da sessão da manhã. Essas discussões tiveram metas mais específicas. Por exemplo, um grupo trabalhou na identificação das partes úteis de um relatório de experiência e em uma lista de literatura existente documentando as experiências do usuário Go, resultando na página wiki de relatório de experiência.

Outro grupo considerou o futuro dos erros em Go. Muitos usuários do Go são inicialmente confundidos ou não entendem o fato de que erro é uma interface, e pode ser difícil anexar mais informações a erros sem mascarar erros de sentinela, como io.EOF. A sessão de discussão abordou maneiras específicas de talvez ser possível corrigir alguns desses problemas nos próximos lançamentos do Go, mas também abordou maneiras de o gerenciamento de erros poder ser melhorado no Go 2.

 

Comunidade

Fora das discussões técnicas, a cúpula também proporcionou uma oportunidade para um grupo de pessoas de todo o mundo, que muitas vezes conversam e trabalham juntas, de se encontrarem pessoalmente, em muitos casos pela primeira vez. Não há substituto para um pequeno tempo de cara a cara para construir um senso de respeito mútuo e camaradagem, o que é crítico quando um grupo diversificado com diferentes perspectivas e ideias precisa se unir para trabalhar em uma única comunidade. Durante os intervalos, os membros do time Go se dispersaram entre os colaboradores para discussões sobre Go e uma pequena socialização geral, que realmente ajudou a colocar rostos nos nomes que revisam nosso código todos os dias.

Como Russ discutiu em Em direção ao Go 2, comunicar-se efetivamente exige conhecer seu público. Ter uma ampla amostra de colaboradores Go juntos em uma sala nos ajudou a entender melhor o público Go e iniciar muitas discussões produtivas sobre o futuro do Go. Avançando, esperamos fazer eventos mais frequentes como esse para facilitar o discurso e o senso de comunidade.

Artigos relacionados

• Workshop de contribuição
• Em direção ao Go 2
• Resultados do Survey Go 2016
• Participe do Questionário de Inquérito ao Usuário e da Empresa de 2016
• Go, Código Aberto, Comunidade
• Quatro anos de Go
• Leve-o para um encontro do Go
• Go vira três
• Conhecendo a comunidade Go
• A Linguagem de Programação Go se transforma em duas
• Spotlight em bibliotecas externas Go
• Bibliotecas de terceiros: goprotobuf e além

 

***

 

Este artigo é do The Go Blog. Ele foi escrito por Sam Whited. A tradução foi feita pela Redação iMasters com autorização. Você pode acessar o original em: https://blog.golang.org/contributors-summit