Würde Speichersicherheit der Plattform erheblich zugutekommen?
Auch die Leistung könnte sich verbessern.
Ich denke auch, dass die endlosen Diskursfehler mit Rust reduziert werden könnten.
Wird Discourse als moderne Plattform überleben, ohne in Rust neu geschrieben zu werden?
Bei der Einfachheit und Effizienz der Rust-Entwicklung sollte der Arbeitsaufwand kein Problem darstellen.
Gedanken?
Melden Sie sich freiwillig, um es zu portieren? 
Jeff hat einen Blogartikel darüber geschrieben, warum Ruby:
Wahrscheinlich vor Rust (ja) geschrieben, wird aber sicherlich einige Begründungen liefern.
Sicher, aber Microsoft geht auch in Richtung Rust.
Jeff weiß sicher inzwischen, dass Rust überlegen ist.
Es könnte mit etwas Blut, Schweiß und Tränen in 12-16 Tagen erledigt werden. Er ist noch etwas jung, um in Rente zu gehen.
Ich bin ziemlich sicher, dass es mindestens 12-16 Tage dauert, um auf eine neue Version von Ruby oder Postgres zu aktualisieren. Es gibt ungefähr 60.000 Zeilen Ruby.
Was würde Rails ersetzen?
Microsoft hat sehr tiefe Taschen und Ressourcen.
Man müsste den Kern und auch alle Plugins neu schreiben.
Das würde auch bedeuten, dass die Roadmap auf Eis gelegt werden müsste.
Könnte es gemacht werden, sicher. Aber man muss auch testen und debuggen.
Aktuelle Kunden von Discourse würden wahrscheinlich ihre Seiten kaputt machen.
Meiner Meinung nach, wenn das Team daran arbeiten würde. Es müsste als Fork mit Beta-Testern über einen langen Zeitraum bearbeitet werden. Plugins forken für z.B. Discourse2 Meta.
Es ist also derzeit wahrscheinlich nicht vernünftig, die Ressourcen aufzuteilen, um das aktuelle Ruby zu pflegen und zu portieren.
Entschuldigung, ist das ein Tippfehler, meintest du Monate?
Kannst du auf ein einziges Projekt ähnlicher Größe und Tragweite wie Discourse verweisen, bei dem eine solche Portierung in einem so kurzen Zeitraum erreicht wurde?
Ich wette, dass der von David Megginson beschriebene Prozess (http://www.megginson.com/blogs/quoderat/2006/03/06/programming-languages-of-distinction/?ref=blog.codinghorror.com) sehr vertraut klingt:
- Elite-Entwickler (Gurus) stellen fest, dass zu viele einfache Leute ihre aktuelle Programmiersprache verwenden, und suchen nach etwas, das sie besser von ihren mittelmäßigen Kollegen unterscheidet.
- Elite-Entwickler nehmen ihre Einkaufsliste aktueller Ärgernisse und suchen nach einer neuen, wenig bekannten Sprache, die anscheinend weniger davon hat.
- Elite-Entwickler beginnen, die Entwicklung der neuen Sprache voranzutreiben, tragen Code bei, schreiben Bibliotheken usw. und bewerben dann die neue Sprache. Sub-Elite-Entwickler (Senior-Entwickler) folgen den Elite-Entwicklern zur neuen Sprache, schaffen einen Markt für Bücher, Schulungen usw. und beschleunigen auch die Entwicklung und das Testen der Sprache.
- Sub-Elite-Entwickler, die enormen Einfluss haben (Elite-Entwickler neigen dazu, isoliert an Forschungsprojekten statt in Produktionsteams zu arbeiten), beginnen, die neue Sprache am Arbeitsplatz zu fördern.
- Die riesige Masse regulärer Entwickler stellt fest, dass sie Bücher kaufen und Kurse besuchen müssen, um eine neue Sprache zu lernen.
- Elite-Entwickler stellen fest, dass zu viele einfache Leute ihre aktuelle Programmiersprache verwenden, und suchen nach etwas, das sie besser von ihren mittelmäßigen Kollegen unterscheidet.
Wen kümmert es, welche Technologie Sie verwenden, solange sie funktioniert und Sie und Ihre Benutzer damit zufrieden sind?
Das ist das Schöne an neuen Dingen: Es kommt immer etwas Neues. Lassen Sie nicht zu, dass die Jagd nach neuen, glänzenden Dingen versehentlich zu Ihrem Ziel wird. Vermeiden Sie es, ein Elster-Entwickler zu werden. Seien Sie wählerisch bei der Jagd nach dem Glänzenden und Neuen, und Sie werden feststellen, dass Sie dadurch ein besserer Entwickler sind.
Wow. Ich hoffe, Sie haben nur einen Scherz gemacht.
Könnte immer hier fragen, sie wissen es vielleicht 
Nein, warum sagen Sie das?
Vielleicht, weil Rust-Enthusiasten Discourse verwenden? Oder vielleicht, wenn die Portierung nur zwei Arbeitstage dauern würde, hätten sie es bereits getan, nur zum Sport und zum Spaß?
Ich bin von diesem Thread so verblüfft, dass ich meine tägliche Medizin heute nicht brauche 
Discourse ist speichersicher. Ruby ist eine speichersichere Sprache; alle Garbage-Collected-Sprachen sind das. Der Hauptunterschied zu Rust in dieser Hinsicht liegt darin, wann die Sicherheitsprüfungen durchgeführt werden; Rust führt sie zur Kompilierzeit durch, Ruby zur Laufzeit.
Rust befasst sich nur mit wenigen Fehlerklassen, hauptsächlich denen, die durch das Fehlen einer Garbage Collection in C++ verursacht werden. Es ist sicherlich cool, dass sie einen Weg gefunden haben, dies zu tun und gleichzeitig die theoretisch mit Zeigern möglichen Leistungsvorteile zu erhalten, aber es verhindert keineswegs die Art von Fehlern, die man als Benutzer sehen würde. Wenn ich zum Beispiel < verwende, wenn ich <= meinte, und dadurch ein Off-by-one-Fehler entsteht, wird Rust mich nicht retten. Wenn ich vergesse, nach Abschluss einer Aktion eine Erfolgsmeldung auszugeben, wird Rust mich nicht retten.
Was Fehler tatsächlich verhindert, ist die Art von Test-Driven Development, die Discourse bereits einsetzt. Es gibt nur sehr wenige Projekte, die man direkt von Master bereitstellen und erwarten kann, dass sie stabil sind, aber Discourse ist eines davon.
„Moderne Plattformen“ sprießen links, rechts und in der Mitte mit JavaScript für Backend und Frontend aus dem Boden. Ruby liegt in der Beliebtheit zwei Plätze hinter Rust (Kotlin liegt dazwischen), sodass es derzeit kaum eine seltene Sprache ist. Sicher, in 10 Jahren kann sich die Situation ändern, aber selbst eine Neuentwicklung zu Rust wäre in 10 Jahren technische Schuld.
Es ist schwer zu vermitteln, wie naiv diese Aussage ist, weshalb alle über die Idee lachen. Ich habe gesehen, wie meine Entwickler seit 3 Jahren Code refaktorisieren, und sie sind gerade erst bereit, mit der Portierung von wxWidgets/ShuttleGUI auf Qt/QML zu beginnen – was kontextbezogen eine Migration von C++ zu C++ ist, nur ein anderer UI-Toolkit. Es ist einfach schwierig, Code zu transformieren und gleichzeitig sicherzustellen, dass das Verhalten identisch bleibt. 12-16 Tage ist wahrscheinlich die Zeit, die man nur für die Planung benötigt, bevor überhaupt jemand anfängt.
Ich bin vielleicht nicht der produktivste Entwickler, aber es hat mich 3 Wochen gekostet, das Poll-Plugin zu Glimmer Components zu migrieren (was nicht einmal eine Sprachänderung ist!)
Ich weiß nichts über Rust oder Ruby, aber ich habe das Gefühl, dass das Team von CDCK im letzten Jahr eine erstaunliche Arbeit bei der Neufassung des Frontends mit Ember 5 und Glimmer-Komponenten geleistet hat. Es ging tatsächlich mit einem Wiederaufbau des Frontends mit standardisierten Komponenten und Stilen einher. Ich bin beeindruckt von der koordinierten Anstrengung und dem Zweck, der dahintersteckte 
Für mich haben sie eine großartige Entscheidung getroffen, was modernisiert werden sollte, denn das hat einen großen Unterschied gemacht, um Discourse modern und benutzerfreundlich zu halten!
Manuel, in Bezug auf Styles (CSS), ist dies irgendwo dokumentiert? Was sind Ihrer Meinung nach die wichtigsten Änderungen? Finden Sie, dass die Struktur des Discourse-CSS-Codes jetzt einfacher zu handhaben ist?
Was die Stile angeht, sehe ich folgende Hauptänderungen:
Meiner Meinung nach macht dies die Anpassung von Discourse so viel einfacher und genauer. Aber ich schätze, es hängt von Ihrem Arbeitswissen ab. Ich könnte mir vorstellen, dass es jetzt eine steilere Lernkurve für Leute gibt, die nur einige Anpassungen vornehmen möchten und mit CSS nicht so vertraut sind.
Zur Dokumentation können Sie sich den Styleguide ansehen, und ich schätze, der einfachste Weg, um zu scannen, welche benutzerdefinierten Eigenschaften verfügbar sind, ist die Verwendung der Entwicklertools Ihres Browsers. Documentation wird ebenfalls überarbeitet. Derzeit gibt es zwei Abschnitte in Documentation > Developer Guides, Themes & Components und Interface. Aber es gibt eine große Bandbreite zwischen dem Wunsch, einige benutzerdefinierte Stile zu deklarieren, und dem Erstellen einer Komponente. Einige davon sind wahrscheinlich zu tief zwischen den Entwicklerthemen vergraben? 
Wenn Sie es in eine andere Sprache portieren, erwarte ich, dass Go eine bessere Option sein könnte. Einer der Vorteile, den Web-Admins wahrscheinlich schätzen werden, ist das Fehlen von Neuerstellungen, da es statische Binärdateien liefert. Das macht auch Container größtenteils überflüssig. Tatsächlich scheint eine Funktion, die für Discourse dringend benötigt wird, die Möglichkeit zu sein, die App auf einer anderen Maschine als Ihrem Webserver zu builden. Derzeit dauert es mit dem minimalen, billigsten VPS fast 10 Minuten zum Builden. Dies wäre wahrscheinlich ein Bruchteil der Zeit, wenn ich lokal auf meiner Workstation bauen und dann die endgültigen Binärdateien zum Ausführen auf den Webserver verschieben könnte. Beachten Sie, dass Sprachen wie Go es Ihnen ermöglichen, trivial zu kreuzkompilieren, sodass Sie auf Ihrem M1 Mac bauen und dann auf einem x86-Webserver bereitstellen könnten (oder sogar nur ARM bauen, verschieben und bereitstellen).
Ich vermute, dass derzeit die meiste Zeit beim Erstellen die Kompilierung des Frontends beansprucht, daher ist „Go oder nicht“ in Bezug auf die Build-Zeit irrelevant.
Weder Rust noch Go würden das Frontend ersetzen …
(PS Ich liebe Go auch … )