A segurança de memória beneficiaria muito a plataforma?
O desempenho também poderia ver uma melhoria.
Também acho que os bugs intermináveis do Discourse poderiam ser reduzidos com Rust.
O Discourse, como uma plataforma moderna, sobreviverá sem ser reescrito em Rust?
Com a facilidade e eficiência do trabalho de desenvolvimento em Rust, a mão de obra não deve ser um problema.
Opiniões?
Você está se voluntariando para portar? 
Jeff escreveu um artigo de blog sobre por que Ruby:
Provavelmente escrito antes do Rust (sim), mas certamente fornecerá alguma justificativa.
Claro, mas a Microsoft também está seguindo o caminho do Rust.
Jeff certamente já sabe que o Rust é superior.
Poderia ser feito em 12-16 dias com muito esforço. Ele é um pouco jovem para se aposentar ainda.
Tenho quase certeza de que leva pelo menos 12 a 16 dias para atualizar para uma nova versão do Ruby ou do postgres. Existem cerca de 60 mil linhas de Ruby.
O que substituiria o Rails?
A Microsoft tem bolsos e recursos muito profundos.
Uma que você precisaria reescrever o núcleo e também todos os plugins.
Isso também significaria que o roteiro precisaria ser colocado em espera.
Poderia ser feito, com certeza. Mas você também precisa testar e depurar.
Os clientes atuais do Discourse provavelmente teriam seus sites quebrados.
Na minha opinião, se a equipe fosse trabalhar nisso. Seria necessário trabalhar como um fork com testadores beta por um longo período de tempo. Fazer fork de plugins para, digamos, Discourse2 Meta.
Portanto, não é provável que seja razoável neste momento dividir os recursos para manter o ruby atual e a portabilidade.
Desculpe, isso é um erro de digitação, você quis dizer meses?
Você pode apontar um único projeto de tamanho e escopo semelhantes ao Discourse onde tal portabilidade foi alcançada em um prazo tão curto?
Aposto que o processo que David Megginson descreve soa terrivelmente familiar:
Desenvolvedores de elite (gurus) percebem que muitos “desclassificados” estão usando sua linguagem de programação atual e começam a procurar algo que os distinga melhor de seus colegas medíocres.
Desenvolvedores de elite pegam sua lista de compras de aborrecimentos atuais e procuram uma nova linguagem pouco conhecida que aparentemente tenha menos deles.
Desenvolvedores de elite começam a impulsionar o desenvolvimento da nova linguagem, contribuindo com código, escrevendo bibliotecas, etc., e então evangelizam a nova linguagem. Desenvolvedores sub-elite (seniores) seguem os desenvolvedores de elite para a nova linguagem, criando um mercado para livros, treinamento, etc., e também acelerando o desenvolvimento e teste da linguagem.
Desenvolvedores sub-elite, que têm enorme influência (desenvolvedores de elite tendem a trabalhar isoladamente em projetos de pesquisa em vez de em equipes de desenvolvimento de produção), começam a defender a nova linguagem no local de trabalho.
A enorme massa de desenvolvedores regulares percebe que tem que começar a comprar livros e fazer cursos para aprender uma nova linguagem.
Desenvolvedores de elite percebem que muitos “desclassificados” estão usando sua linguagem de programação atual e começam a procurar algo que os distinga melhor de seus colegas medíocres.
Quem se importa com a tecnologia que você usa, desde que ela funcione, e tanto você quanto seus usuários fiquem felizes com ela?
Essa é a beleza das coisas novas: sempre há uma nova chegando. Não deixe que a busca por coisas novas e brilhantes se torne acidentalmente seu objetivo. Evite se tornar um desenvolvedor-magpie. Seja seletivo em sua busca pelo brilhante e novo, e você pode se tornar um desenvolvedor melhor por isso.
Uau. Espero que você estivesse apenas brincando.
Sempre se pode perguntar aqui, eles podem saber 
Não, por que você diz isso?
Talvez porque os entusiastas de Rust estejam usando o Discourse? Ou talvez se a portabilidade levasse apenas dois dias úteis, eles já a teriam feito, apenas por esporte e diversão?
Fico tão pasmo com este tópico que não precisarei da minha medicação diária hoje 
O Discourse é seguro em termos de memória. Ruby é uma linguagem de programação segura em termos de memória; todas as linguagens com coleta de lixo são. A principal diferença para Rust, nesse aspecto, é quando as verificações de segurança são realizadas; Rust as faz em tempo de compilação, Ruby as faz em tempo de execução.
Rust lida apenas com algumas classes de erros, principalmente aqueles causados pela falta de coleta de lixo do C++. Certamente é legal que eles encontraram uma maneira de fazer isso, mantendo os benefícios de desempenho teoricamente possíveis com ponteiros, mas isso de forma alguma impede o tipo de bugs que você veria como usuário. Por exemplo, se eu usar < quando quis dizer <=, e como resultado tiver um erro de “off-by-one”, Rust não me salvará. Se eu esquecer de gerar uma mensagem de sucesso após a conclusão de uma ação, Rust não me salvará.
O que realmente previne bugs é o tipo de desenvolvimento orientado a testes que o Discourse já implementa. Existem muito poucos projetos que você pode simplesmente implantar diretamente do master e esperar que sejam estáveis, mas o Discourse é um deles.
“Plataformas modernas” estão surgindo por toda parte, usando JavaScript para backend e frontend. Ruby está 2 posições atrás de Rust em popularidade (Kotlin está entre as duas), então não é uma linguagem rara no momento. Claro, em mais 10 anos as coisas podem parecer diferentes, mas mesmo uma reescrita para Rust seria dívida técnica em 10 anos.
É difícil transmitir o quão ingênua é essa declaração, e é por isso que todos estão rindo da ideia. Já vi meus desenvolvedores refatorarem código por 3 anos, e eles estão apenas começando a migrar de wxWidgets/ShuttleGUI para Qt/QML - que, para contextualizar, é uma migração de C++ para C++, apenas um kit de ferramentas de UI diferente. É simplesmente difícil transformar código e, ao mesmo tempo, garantir que o comportamento permaneça idêntico. 12-16 dias é o tempo que você precisaria apenas para o planejamento antes que alguém sequer começasse, provavelmente.
Eu posso não ser o desenvolvedor mais produtivo, mas levei 3 semanas só para migrar o plugin Poll para Glimmer Components (o que nem é uma mudança de linguagem!)
Não sei sobre Rust ou Ruby, mas sinto que, no último ano, a equipe da CDCK fez um trabalho incrível na reescrita do frontend para Ember 5 e componentes Glimmer. Na verdade, isso veio acompanhado de uma reconstrução do frontend com componentes e estilos padronizados. Estou impressionado com o esforço coordenado e o propósito que foram colocados por trás disso 
Portanto, para mim, eles tomaram uma ótima decisão sobre o que modernizar, porque isso fez uma enorme diferença em manter o Discourse moderno e agradável de usar!
Manuel, com relação aos estilos (CSS), isso está documentado em algum lugar? O que você considera como as principais mudanças? Você sente que a estrutura do código CSS do Discourse é menos fácil de trabalhar agora?
Com relação aos estilos, as principais alterações que vejo são que
Para mim, isso torna a personalização do Discourse muito mais fácil e precisa. Mas, suponho que dependa do seu conhecimento de trabalho. Eu poderia imaginar que há uma curva de aprendizado mais acentuada agora para pessoas que apenas querem fazer alguns ajustes e não estão tão familiarizadas com CSS.
Sobre a documentação, você pode conferir o Guia de Estilo e, suponho que a maneira mais fácil de verificar quais propriedades personalizadas estão disponíveis é usando as ferramentas de desenvolvedor do seu navegador. Documentation também está sendo reformulada. Atualmente, existem duas seções em Documentation developer-guides, Temas e Componentes e Interface. Mas há uma enorme variação entre apenas querer declarar alguns estilos personalizados e criar um componente. Parte disso provavelmente está enterrada muito profundamente entre os tópicos de desenvolvedor? 
se você for portá-lo para outra linguagem, espero que Go seja uma opção melhor. Uma das vantagens que espero que os administradores da web apreciem é a falta de reconstruções, já que ele envia binários estáticos. Isso também torna os contêineres em grande parte desnecessários. Na verdade, um recurso que parece ser muito necessário com o Discourse é a capacidade de construir o aplicativo em uma máquina diferente do seu servidor web. Atualmente, com o VPS mínimo e mais barato, leva quase 10 minutos para construir. Isso provavelmente seria uma fração do tempo se eu pudesse construir localmente na minha estação de trabalho e, em seguida, enviar os binários finais para o servidor web para executar. Tenha em mente que linguagens como Go permitem que você compile de forma trivial, então você poderia construir em seu Mac M1 e, em seguida, implantar em um servidor web x86 (ou até mesmo apenas construir, enviar e implantar ARM).
Suspeito que atualmente o maior tempo gasto durante a compilação seja a compilação do front-end, então “ir ou não” é irrelevante em relação ao tempo de compilação.
Nem Rust nem Go substituiriam o front-end…
(PS Eu também amo Go…)