La sécurité de la mémoire bénéficierait-elle grandement à la plateforme ?
Les performances pourraient également connaître une amélioration.
Je pense aussi que les bugs sans fin de Discourse pourraient être réduits avec Rust.
Discourse, en tant que plateforme moderne, survivra-t-il sans être réécrit en Rust ?
Avec la facilité et l’efficacité du travail de développement en Rust, le personnel ne devrait pas poser de problème.
Des réflexions ?
Proposes-tu de le porter toi-même ? 
Jeff a écrit un article de blog expliquant pourquoi Ruby :
Probablement écrit avant Rust (oui), mais fournira sûrement une justification.
Bien sûr, mais Microsoft suit également la voie de Rust.
Jeff sait sûrement maintenant que Rust est supérieur.
Cela pourrait être fait en 12 à 16 jours avec du sang, de la sueur et des larmes. Il est un peu jeune pour prendre sa retraite.
Je suis à peu près sûr qu’il faut au moins 12 à 16 jours pour passer à une nouvelle version de Ruby ou de postgres. Il y a environ 60 000 lignes de Ruby.
Qu’est-ce qui remplacerait Rails ?
Microsoft a des poches et des ressources très profondes.
L’une nécessiterait de réécrire le cœur et aussi tous les plugins.
Cela signifierait également que la feuille de route devrait être mise en attente.
Pourrait-il être fait, bien sûr. Mais il faut aussi tester et déboguer.
Les clients actuels de Discourse verraient probablement leurs sites se casser.
À mon avis, si l’équipe devait travailler sur cela. Il faudrait travailler dessus comme un fork avec des bêta-testeurs sur une longue période. Forker des plugins pour, disons, Discourse2 Meta.
Il n’est donc pas vraiment raisonnable pour le moment de diviser les ressources pour maintenir le ruby actuel et le portage.
Désolé, est-ce une faute de frappe, vouliez-vous dire des mois ?
Pouvez-vous citer un seul projet de taille et de portée similaires à Discourse où un tel portage a été réalisé dans un délai aussi court ?
Je parie que le processus que David Megginson décrit ici vous semble familier :
Les développeurs d’élite (gourous) remarquent que trop de gens ordinaires utilisent leur langage de programmation actuel et commencent à chercher quelque chose qui les distinguera mieux de leurs collègues médiocres.
Les développeurs d’élite prennent leur liste de courses des désagréments actuels et cherchent un nouveau langage peu connu qui en a apparemment moins.
Les développeurs d’élite commencent à piloter le développement du nouveau langage, contribuant du code, écrivant des bibliothèques, etc., puis font la promotion du nouveau langage. Les développeurs de niveau intermédiaire (seniors) suivent les développeurs d’élite vers le nouveau langage, créant un marché pour les livres, la formation, etc., et accélérant également le développement et les tests du langage.
Les développeurs de niveau intermédiaire, qui ont une énorme influence (les développeurs d’élite ont tendance à travailler isolément sur des projets de recherche plutôt que sur des équipes de développement de production), commencent à promouvoir le nouveau langage sur le lieu de travail.
La grande masse des développeurs réguliers réalisent qu’ils doivent commencer à acheter des livres et à suivre des cours pour apprendre un nouveau langage.
Les développeurs d’élite remarquent que trop de gens ordinaires utilisent leur langage de programmation actuel et commencent à chercher quelque chose qui les distinguera mieux de leurs collègues médiocres.
Peu importe la technologie que vous utilisez, tant qu’elle fonctionne, et que vous et vos utilisateurs en êtes satisfaits ?
C’est la beauté des nouveautés : il y en a toujours une nouvelle qui arrive. Ne laissez pas la poursuite des choses nouvelles et brillantes devenir accidentellement votre objectif. Évitez de devenir un développeur pie. Soyez sélectif dans votre quête du brillant et du nouveau, et vous pourriez vous retrouver un meilleur développeur pour cela.
Wow. J’espère que vous plaisantiez.
On pourrait toujours demander ici, ils pourraient savoir 
Non, pourquoi dites-vous cela ?
Peut-être parce que les passionnés de Rust utilisent Discourse ? Ou peut-être que si le portage ne prenait que deux jours ouvrables, ils l’auraient déjà fait, juste pour le sport et le plaisir ?
Je suis tellement stupéfait par ce fil que je n’aurai pas besoin de mes médicaments quotidiens aujourd’hui 
Discourse est sécurisé en mémoire. Ruby est un langage sécurisé en mémoire ; tous les langages à garbage collector le sont. La principale différence avec Rust à cet égard est le moment où les vérifications de sécurité sont effectuées ; Rust les effectue au moment de la compilation, Ruby les effectue au moment de l’exécution.
Rust ne s’attaque qu’à quelques classes d’erreurs, principalement celles causées par l’absence de garbage collection en C++. Il est certainement cool qu’ils aient trouvé un moyen de le faire tout en conservant les avantages de performance théoriquement possibles avec les pointeurs, mais cela n’empêche en aucun cas le type de bugs que vous verriez en tant qu’utilisateur. Par exemple, si j’utilise < alors que je voulais <=, et que j’obtiens une erreur d’un cran à la suite, Rust ne me sauvera pas. Si j’oublie de faire apparaître un message de succès après qu’une action soit terminée, Rust ne me sauvera pas.
Ce qui empêche réellement les bugs, c’est le type de développement piloté par les tests que Discourse déploie déjà. Il y a très peu de projets que vous pouvez déployer directement depuis master et vous attendre à ce qu’ils soient stables, mais Discourse en est un.
Les « plateformes modernes » apparaissent à gauche, à droite et au centre en utilisant JavaScript pour le backend et le frontend. Ruby est 2 places derrière Rust en popularité (Kotlin est entre les deux), donc ce n’est guère un langage rare pour le moment. Bien sûr, dans 10 ans, les choses pourraient être différentes, mais même une réécriture en Rust serait une dette technique dans 10 ans.
Il est difficile de transmettre à quel point cette déclaration est naïve, c’est pourquoi tout le monde rit de cette idée. J’ai vu mes développeurs refactoriser du code pendant 3 ans maintenant, et ils sont juste prêts à commencer à migrer de wxWidgets/ShuttleGUI vers Qt/QML - ce qui, pour contexte, est une migration de C++ vers C++, juste un toolkit d’interface utilisateur différent. Il est juste difficile de transformer du code tout en s’assurant que le comportement reste identique. 12-16 jours, c’est le temps dont vous auriez probablement besoin juste pour la planification avant que quiconque ne commence.
Je ne suis peut-être pas le développeur le plus productif, mais il m’a fallu 3 semaines juste pour migrer le plugin Poll vers les composants Glimmer (ce qui n’est même pas un changement de langue !).
Je ne sais rien de Rust ou de Ruby, mais j’ai l’impression qu’au cours de la dernière année, l’équipe de CDCK a fait un travail incroyable avec la réécriture du frontend en Ember 5 et les composants Glimmer. Cela s’est accompagné d’une reconstruction du frontend avec des composants et des styles standardisés. Je suis impressionné par l’effort coordonné et le but qui ont été mis derrière cela 
Donc, pour moi, ils ont pris une excellente décision quant à ce qu’il fallait moderniser, car cela a fait une énorme différence pour garder Discourse moderne et agréable à utiliser !
Manuel, en ce qui concerne les styles (CSS), est-ce documenté quelque part ? Quelles sont, selon vous, les principaux changements ? Pensez-vous que la structure du code CSS de Discourse est moins facile à utiliser maintenant ?
En ce qui concerne les styles, les principaux changements que je vois sont que
Pour moi, cela rend la personnalisation de Discourse beaucoup plus facile et précise. Mais je suppose que cela dépend de vos connaissances pratiques. J’imagine qu’il y a une courbe d’apprentissage plus raide maintenant pour les personnes qui veulent juste faire quelques ajustements et qui ne connaissent pas bien le CSS.
Concernant la documentation, vous pouvez consulter le Styleguide et je suppose que le moyen le plus simple de scanner les propriétés personnalisées disponibles est d’utiliser les outils de développement de votre navigateur. Documentation est également en cours de remaniement. Actuellement, il y a deux sections dans Documentation : developer-guides, Thèmes & Composants et Interface. Mais il y a une énorme différence entre vouloir simplement déclarer quelques styles personnalisés et créer un composant. Une partie de cela est probablement enfouie trop profondément entre les sujets de développement ? 
Si vous comptez le porter dans une autre langue, je m’attends à ce que Go soit une meilleure option. L’un des avantages que les administrateurs Web pourraient apprécier est l’absence de recompilations, car il distribue des binaires statiques. Cela rend également les conteneurs largement inutiles. En fait, une fonctionnalité qui semble cruellement nécessaire avec Discourse est la possibilité de construire l’application sur une machine différente de votre serveur Web. Actuellement, avec le VPS minimal et le moins cher, la construction prend près de 10 minutes. Cela prendrait probablement une fraction du temps si je pouvais construire localement sur mon poste de travail, puis expédier les binaires finaux vers le serveur Web pour les exécuter. Gardez à l’esprit que des langages comme Go vous permettent de compiler de manière triviale, de sorte que vous pourriez construire sur votre Mac M1, puis déployer sur un serveur Web x86 (ou même simplement construire, expédier et déployer ARM).
Je soupçonne que le temps le plus long actuellement pendant la compilation est la compilation du front-end, donc « Go ou pas » est sans objet en ce qui concerne le temps de compilation.
Ni Rust ni Go ne remplaceraient le front-end…
(PS J’adore Go aussi…)