OpenD, um fork da linguagem D que quer receber contribuições
(dpldocs.info)- Com o acúmulo de reclamações de que as contribuições via a liderança existente do D estavam bloqueadas há muito tempo, alguns contribuidores migraram para OpenD, um fork da linguagem D
- A questão não é tanto se D é closed source, mas que, mesmo após a publicação sob GPL e o lançamento do gdc, o modo de desenvolvimento e a tomada de decisões não eram suficientemente abertos para a comunidade
- O caso de Ares/Tango, que mais tarde levou ao druntime, a queda de atividade no Phobos, PRs abandonados e a falta de execução após “D gripes and wishes” são apresentados como base para o fork
- Após a migração para OpenD, foram interrompidos PRs, relatórios de bugs, suporte a usuários, participação em reuniões da DLF e presença no DConf Online para o D upstream, enquanto o dpldocs.info será mantido enquanto os custos forem cobertos
- Bibliotecas e aplicações D existentes sem contrato de suporte pago não terão garantia de compatibilidade com o D upstream, e o caminho de suporte de longo prazo passa a se deslocar para a participação no OpenD
Por que migrar para o OpenD
- OpenD é um fork da linguagem D, surgido da percepção de que o processo de contribuir para o upstream por meio da liderança existente do D era extremamente frustrante já há muito tempo
- A afirmação repetida de que D é uma linguagem closed source não é precisa
- A parte específica de D no compilador foi publicada sob GPL em 2002
- O gdc, um compilador totalmente sob GPL, foi publicado em 2004
- Ainda assim, houve críticas contínuas de que a metodologia de desenvolvimento de D não era suficientemente aberta e de que havia muito pouca participação significativa da comunidade na tomada de decisões
- Recursos e conceitos centrais de D, assim como uma parte considerável do código D existente, vieram de contribuições e trabalho da comunidade, mas olhar apenas para os casos aceitos pode levar a um viés de sobrevivência
Gargalo antigo de contribuições e o caso Ares/Tango
- Na história de D, houve muitas correções aceitas, mas também muitas que ficaram abandonadas por longos períodos
- O código hoje conhecido como druntime começou em um fork criado porque Walter não aceitava contribuições da comunidade
- Em 2004, desenvolvedores que tentavam colaborar com o upstream fizeram um fork de D para não perder suas contribuições
- Esse fork foi inicialmente chamado de Ares e depois, ao se juntar a outros esforços da comunidade, tornou-se Tango
- Tango se apresentava como “The Developer's Library for D” e funcionava como um espaço em que os desenvolvedores realmente tinham suas contribuições bem-vindas
- O ecossistema Tango tinha muitos elementos que não existiam no ecossistema Phobos
- Depois que o fork foi mantido por quatro anos e ganhou popularidade, o upstream buscou reconciliação, e esse movimento levou ao druntime de hoje
- A avaliação implícita é que, sem o fork Ares/Tango, D não teria conquistado uma posição relevante no mercado, e que esse fork salvou D de uma crise
Participação reduzida após a era de ouro
- O período em que desenvolvedores centrais do Tango voltaram e Andrei Alexandrescu, entre outros, se juntou ao projeto é descrito como uma fase em que o desenvolvimento de D era relativamente aberto, uma era de ouro com mais atividade por volta de 2013
- Também se enfatiza que quase todos os usuários comerciais de D dependiam diretamente de código originado no fork Ares
- Porém, os velhos hábitos não desapareceram, e muitos dos contribuidores da era de ouro não permaneceram na comunidade
- Alguns saíram explicitamente apontando um processo quebrado em que seu trabalho não era valorizado
- Outros reduziram sua atividade por motivos pessoais, e não ficaram contribuidores novos suficientes
- A atividade de desenvolvimento do Phobos caiu fortemente em meados de 2018, com dois pequenos aumentos posteriores
- A adição, por berni44, de formatação de ponto flutuante compatível com CTFE
- O caso em que o módulo sumtype de Paul Backus foi aceito como
std.sumtype
- berni44 disse em 2020 que deixaria a comunidade após esperar quase três meses por review de PR; voltou um ano depois e impulsionou um aumento recente na atividade de desenvolvimento do Phobos, mas saiu novamente poucos meses depois
- No próprio dmd, a quantidade de contribuições pessoais de Walter se manteve em geral estável, mas, com a queda das contribuições de outras pessoas, sua participação passou de cerca de 1/6 na era de ouro para cerca de 1/3 atualmente
Coleta repetida de reclamações e pouca execução
- Por volta do Natal de 2022, Mike Parker pediu às pessoas que enviassem uma lista de “D gripes and wishes”
- Muita gente acreditava que isso não daria em nada, mas houve muitas respostas
- Cerca de seis meses depois, em 18 de maio de 2023, foi publicado um documento público reunindo as respostas
- Depois disso, os únicos resultados confirmados publicamente ficaram na definição dos seguintes objetivos
- estabilização da linguagem, do compilador e da biblioteca padrão
- melhoria do ecossistema, incluindo ferramentas e suporte a bibliotecas de terceiros
- fortalecimento da comunidade, incluindo organização do site, atualização de documentação e tutoriais antigos, e redesign do site
- O pedido era para “não escrever em termos gerais, mas de forma específica”, porém muitas respostas a reclamações concretas permaneceram em bullets de metas amplas
- Como o Vision Document 2016H1 já tinha objetivos parecidos, como ampliar a participação, ferramentas, estabilidade da linguagem e melhorias na especificação, além de adição de bibliotecas, a posição aqui é que mais do que definir metas, é preciso executar
O que muda com a transição para OpenD
- As tentativas de contribuição ao D upstream serão interrompidas, com migração para OpenD, um fork do compilador completo
- A hospedagem de documentação do dpldocs.info está sendo mantida com custos mal cobertos pelo Patreon e continuará funcionando, incluindo suporte a pacotes dub, enquanto esses custos forem mantidos
- Não receberá atualizações do D upstream
- Os recursos existentes provavelmente continuarão funcionando bem
- A parte do blog dedicada a suporte exclusivo ao D upstream será encerrada
- Estatísticas não serão mais incluídas
- O nome mudará para “This Week in ARSD” e talvez depois para “This Week in OpenD”
- PRs e relatórios de bugs para o D upstream serão interrompidos imediatamente
- O que ajudar o autor não será enviado ao upstream, mas integrado ao OpenD
- O suporte a usuários de D também será encerrado
- No passado, eram dedicadas várias horas por semana ao suporte de usuários de D com diferentes níveis de experiência, mas agora não há garantia de resposta para perguntas sobre o D upstream
- Se houver resposta, é bem provável que seja para recomendar que tentem o OpenD
- Não haverá participação em reuniões da DLF, a menos que haja concordância com mudanças de governança como pré-condição
- Convites para livestreams do DConf Online também serão recusados
- Bibliotecas D manterão a promessa de compatibilidade entre versões internas e atualizações de compiladores externos apenas para quem tiver contrato de suporte pago
- Para os demais usuários, a compatibilidade com o D upstream é cancelada imediatamente
- O código é fornecido no estado em que se encontra, sem qualquer garantia explícita ou implícita
- Se aderirem ao fork OpenD, o suporte a essas bibliotecas continuará
- Aplicações D, assim como as bibliotecas, não terão promessa de compatibilidade com o D upstream; como já eram projetadas originalmente para uso próprio, a garantia de compatibilidade é ainda mais flexível
Posição final
- O autor afirma ter dedicado muito tempo a D nos últimos 16 anos e que a maior parte de sua carreira em programação se deve a D e, antes disso, ao Digital Mars C++
- Walter Bright e seus colegas tiveram grande impacto em sua vida, e Walter é avaliado como um excelente contribuidor para projetos de linguagem de programação
- Ainda assim, agora ele deixa o D de Walter Bright e escolhe um caminho separado chamado OpenD
- Para que OpenD tenha sucesso, há muito trabalho pela frente e a chance de fracasso também é muito alta, mas a avaliação é que, a partir de agora, a responsabilidade por esse fracasso caberá apenas ao próprio lado do OpenD
1 comentários
Opiniões do Hacker News
Pelo menos Walter, e talvez outras pessoas da liderança do D, também frequentam este espaço, então é bem provável que vejam estes comentários
Espero que lembrem que eles também são pessoas, que realmente se importam com o D e que, pela minha experiência, são pessoas basicamente decentes tentando fazer o melhor
Não sei por que agora seria diferente, e parece uma repetição de Tango parte 2
A diferença é que agora o navio já zarpou há muito tempo
Se o projeto pode se sair melhor sob outra liderança, essa possibilidade deve ser examinada
Pessoalmente, eu realmente quero que o D volte à vida; ele ainda é minha linguagem favorita
Não se trata de atacar Walter ou qualquer outra pessoa, são apenas pessoas tentando salvar algo de que gostam
Infelizmente, algo assim acabaria acontecendo. Há anos se fala demais em um fork do D
Quando o livro de Andrei Alexandrescu saiu em 2010, quase tudo que era bom no D acabou entrando em C#, Java e C++
A implementação pode não ser tão limpa quanto a do D, mas, se dá para usar de alguma forma dentro de um ecossistema de ferramentas e bibliotecas melhor, essa diferença não importa tanto
Perdeu-se tempo demais perseguindo recursos de ouro que atrairiam pessoas, e nem sequer conseguiram estabilizá-los
Andrei também parece estar mais ocupado hoje em dia com C++ e CUDA do que com D
Com o renascimento das linguagens de programação compiladas nativamente na última década, a concorrência ficou ainda mais forte
Por isso é ainda mais lamentável. A comunidade em si tem muitas pessoas excelentes com quem é bom conversar
Uso Python todos os dias e sinto falta de muitas coisas do D
Sem falar no desempenho
Como alguém de fora que estava dando uma olhada no D, vi algo parecido
Quando Rust ainda era novidade, o conceito de lifetimes foi proposto à comunidade D, mas Walter considerou desnecessário
Alguns anos depois, Walter trouxe sua própria proposta de lifetimes, suficientemente diferente da do Rust, e por isso também menos validada do que a proposta anterior da comunidade
Agora perdi o interesse pelo D, então não sei quão maduro ficou o novo recurso de lifetimes, mas eu ficaria surpreso se fosse tão útil quanto o de Rust
Qualquer recurso envolve trade-offs como interação com outros recursos da linguagem, carga cognitiva, queda na velocidade de compilação, complexidade no desenho da biblioteca padrão e quebra de compatibilidade retroativa
Não acho razoável esperar uma grande reformulação só para dar suporte a um recurso de outra linguagem de que alguém gosta
Meu grupo de pesquisa deixou D alguns anos atrás e foi para Rust por causa da falta de resposta e da direção ruim no desenvolvimento da linguagem
Espero que Adam e os outros tenham sucesso com o OpenD, mas gostaria que aproveitassem a oportunidade para escolher um nome mais único e memorável
Um novo modelo de governança não começa declarando uma lista de novos recursos ou decidindo remover alguns; começa discutindo governança com um quórum das partes interessadas
Isso não é uma mudança de modelo, é apenas uma troca de regime
Pode haver reclamações legítimas, e a forma como D depende de Walter como guardião pode ser rígida demais para algumas pessoas
Mas a maneira como este fork começou não é um bom sinal no longo prazo
Para o fork ter sucesso, ele precisa de amplo apoio e, no fim, trazer para si algo próximo da maioria da comunidade D, não apenas alguns poucos contribuidores prolíficos
Caso contrário, o fork também fracassará, e a atenção ao original ficará ainda mais fragmentada, fazendo com que até a viabilidade restante se perca
Além disso, é preciso ter capacidade e disposição para dar suporte por décadas
Parece que saiu uma atualização: https://dpldocs.info/this-week-in-d/Blog.Posted_2024_01_08.h... e ela também parece ter recebido alguma atenção
Pessoalmente, acho que teria sido mais divertido chamarem de Died
Daria para usar uma frase legal como “It never Died”, também deixaria claro que é um fork e ainda abriria espaço para levar a linguagem em uma nova direção no futuro, se necessário
OpenD dá a impressão de compatibilidade total
Claro que não tenho interesse direto nisso, e espero que dê certo
Há uma grande thread sobre este assunto no fórum do D: https://forum.dlang.org/thread/beykokfitddfdsjyqjjy@forum.dl...
O texto original é principalmente uma reclamação sobre conflitos entre pessoas, enquanto neste link há mais discussão técnica
Pelo que se vê ali, as pessoas que estão fazendo o fork na verdade querem outra linguagem e parecem dispostas a aceitar várias mudanças que quebram compatibilidade para isso
Pessoalmente, fico confuso sobre qual nicho o D está mirando se ele passar a focar totalmente em coletor de lixo
Mesmo antes, não é que houvesse um nicho claro. Essencialmente era “um C++ 10% melhor”, e era difícil de vender por não ter um recurso matador que o diferenciasse de forma clara
A maioria provavelmente vai ficar no C++ por causa do suporte existente, das bases de código e da base industrial, ou usar Rust em novos projetos, ou Zig se quiser simplicidade
Especialmente depois do C++20, já existe algo como um “C++ 10% melhor”
Também não sei se focar no coletor de lixo ajuda muito
Nesse caso, ele passa a competir com C# e Java, duas linguagens que desde o início foram pensadas como sucessoras do C++ com coleta de lixo, seguras e concisas, e não vejo bem como competir com elas neste momento
Em especial, o C# tem recursos de baixo nível e
unsafebastante bons, como ponteiros brutos, controle de tipos por referência/tipos por valor e controle de layout de memória, além de um sistema de tipos e reflexão decentes para uma linguagem mais antiga e orientada a objetos em primeiro lugar, e continua incorporando recursos da família MLSinceramente, a visão do D sempre me pareceu confusa
Li a documentação de recursos específicos da linguagem, como BetterC, modo safe e lifetimes, mas achei a sintaxe difícil de ler e, embora houvesse muitos detalhes, em geral eles não eram bem explicados
Não consegui sentir de fato uma visão ou um propósito de design coerente para a linguagem
O autor até menciona esse problema, mas a visão deles também não parece muito mais clara
É bom que existam alguns objetivos técnicos concretos de médio prazo, mas não fica claro para que esses objetivos existem
Sou programador Rust, então é óbvio o que eu usaria em um novo projeto pessoal, mas, se tivesse que escolher outra coisa, preferiria usar OCaml, C++ ou até C#
Primeiro, D é uma alternativa ao C++, mas não é C++, e muitos desenvolvedores C++ se frustraram com essa diferença
Segundo, D pode fazer muito mais do que ser uma alternativa ao C++
Pode ser usada para scripts, como linguagem de programação de uso geral e, especialmente, para interoperabilidade com C por meio de recursos como ImportC e BetterC
Um dos objetivos do fork é não ficar mais pedindo desculpas pelo coletor de lixo
A biblioteca padrão ainda tem contagem de referências, unique pointer etc.
Se alguém quiser contribuir com funções que evitem o coletor de lixo, acho que elas serão aceitas
Só que, neste fork, provavelmente será difícil ver Adam se esforçando demais para evitar o coletor de lixo ao colocar novas funções na biblioteca padrão
Ele acredita que o medo do coletor de lixo é exagerado
Nos últimos 10 anos, houve muito a aprender em torno da governança de linguagens de programação
Ao observar linguagens emergentes em transformação, elas também passaram por grandes conflitos ou erros relacionados à governança
Hoje, acho que um ponto central a observar em uma linguagem de programação é a governança
É preciso ver como eles dizem que operam, como operam de fato, quais foram os resultados até agora e como parece que será daqui em diante
A evolução de uma linguagem de programação é quase um exercício de gestão de complexidade e, ao mesmo tempo, precisa equilibrar as demandas de várias partes interessadas
Quase todos os conflitos de governança surgiram quando um grupo de partes interessadas contestou requisitos essenciais para outro grupo, e nem sempre é possível satisfazer os dois lados
O
asyncdo Rust é conhecido como um caso desse tipo e ajuda a explicar um design que funciona, mas que, no geral, não é satisfatórioGo é uma rara exceção: a equipe central não tinha motivo para respeitar todos os stakeholders e tinha recursos e vontade suficientes para isso, mas ainda assim surgiram alguns conflitos
O modelo de elaboração de padrões dos anos 1960 a 1980 era muito melhor e também limitava as disputas políticas a um período curto
Não sei bem qual seria o lado negativo de haver várias implementações de compilador
Pessoalmente, acho que esse é o principal motivo pelo qual C se difundiu tanto
Os compiladores podem explorar direções diferentes, e extensões de linguagem cujo valor é comprovado acabam sendo adotadas por outras implementações e, às vezes, entram no padrão sem serem descaracterizadas demais no processo de consenso do comitê
Pelo menos eu achava que havia 2, uma implementação do lado do gcc e outra do dlang