メモリ安全性はプラットフォームに大いに役立つでしょうか？
パフォーマンスも向上する可能性があります。
また、Rust を使用すれば、終わりのないバグを減らすことができると思います。
Discourse は、Rust で書き直されることなく、最新のプラットフォームとして存続できるでしょうか？
Rust 開発の容易さと効率性を考えると、人材は問題にならないはずです。
ご意見をお聞かせください。
それを移植してくれるのですか？
「いいね！」 8
ジェフは、なぜRubyなのかについてのブログ記事を書きました。
おそらくRust（はい）よりも前に書かれたものですが、きっと何らかの正当化を提供するでしょう。
「いいね！」 8
はい、しかしマイクロソフトもRustの方向へ進んでいます。
ジェフはもうRustが優れていることを知っているはずです。
血と汗と涙を流せば12〜16日で完了できます。彼はまだ引退するには若すぎます。
「いいね！」 3
RubyまたはPostgreSQLの新しいバージョンへのアップグレードには、少なくとも12〜16日かかると確信しています。Rubyのコードは約60K行です。
Railsの代わりになるものは何でしょうか？
「いいね！」 9
Microsoft は非常に潤沢な資金とリソースを持っています。
コアとすべてのプラグインを書き直す必要があります。
これは、ロードマップを一時停止する必要があることも意味します。
それは可能でしょうか？はい。しかし、テストとデバッグも必要です。
Discourse の現在の顧客は、サイトが壊れる可能性が高いです。
私の意見では、チームがこれに取り組む場合。ベータテスターとともに、長期間にわたってフォークとして取り組む必要があります。たとえば、Discourse2 Meta のプラグインをフォークします。
したがって、現時点では、現在の Ruby を維持し、ポートするリソースを分割することは現実的ではないでしょう。
「いいね！」 7
すみません、これはタイプミスですか？月という意味ですか？
Discourseと同程度の規模と範囲のプロジェクトで、そのような移植が短期間で達成された例を1つ挙げてもらえますか？
「いいね！」 15
David Megginson が概説したプロセスは、非常に馴染み深いものに聞こえるのではないでしょうか。
- エリート（グル）開発者は、現在のプログラミング言語を使用している多くの凡人がいることに気づき、平凡な同僚から自分をより際立たせる何かを探し始めます。
- エリート開発者は、現在の不満のショッピングリストを作成し、それらが少ないと思われる、ほとんど知られていない新しい言語を探します。
- エリート開発者は、新しい言語の開発を推進し、コードを提供したり、ライブラリを作成したりして、新しい言語を普及させ始めます。準エリート（シニア）開発者は、エリート開発者に続いて新しい言語に移行し、書籍やトレーニングの市場を創出し、言語の開発とテストを加速させます。
- 準エリート開発者は、多大な影響力を持っています（エリート開発者は、プロダクション開発チームではなく、研究プロジェクトに孤立して取り組む傾向があります）。彼らは、職場で新しい言語を推進し始めます。
- 大多数の通常の開発者は、新しい言語を学ぶために書籍を購入したり、コースを受講したりする必要があることに気づきます。
- エリート開発者は、現在のプログラミング言語を使用している多くの凡人がいることに気づき、平凡な同僚から自分をより際立たせる何かを探し始めます。
使用しているテクノロジーが、実際に機能し、あなたとユーザーの両方がそれに満足している限り、どのようなテクノロジーを使用しているかは誰が気にするでしょうか？
それが新しいものの美しさです。常に新しいものが登場します。新しい、輝くものを追い求めることが、偶然あなたの目標にならないようにしてください。カササギ開発者にならないようにしましょう。輝く新しいものを追求する際には選択眼を持ち、そうすることで、より良い開発者になれるかもしれません。
「いいね！」 5
すごい。ユーモアで言っていただければ幸いです。
「いいね！」 9
ここでも聞くことができます。彼らは知っているかもしれません 
「いいね！」 12
いいえ、なぜそうおっしゃるのですか？
「いいね！」 2
Rust愛好家がDiscourseを使用しているからでしょうか？それとも、移植に2営業日しかかからないなら、単なるスポーツや楽しみのためにすでにそれを終えているのではないでしょうか？
「いいね！」 3
このスレッドにとても驚いたので、今日は毎日の薬は必要ありません 
「いいね！」 12
Discourse はメモリ安全です。Ruby はメモリ安全な言語であり、ガベージコレクションされる言語はすべてそうです。この点に関して Rust との主な違いは、安全チェックがいつ実行されるかということです。Rust はコンパイル時にチェックを行いますが、Ruby は実行時にチェックを行います。
Rust は、主に C++ のガベージコレクションの欠如によって引き起こされる、ごく一部のエラークラスに対処します。ポインタで理論的に可能なパフォーマンス上の利点を維持しながら、それを行う方法を見つけたことは確かにクールですが、ユーザーが見るような種類のバグを防止するものでは決してありません。たとえば、結果としてオフバイワンエラーが発生するような状況で、<= を意図していたのに < を使用した場合、Rust は私を救ってくれません。アクションが完了した後に成功メッセージを生成し忘れた場合、Rust は私を救ってくれません。
実際にバグを防ぐのは、Discourse がすでに展開しているようなテスト駆動開発です。マスターから直接デプロイして安定性を期待できるプロジェクトは非常に少ないですが、Discourse はそのうちの 1 つです。
「最新プラットフォーム」は、バックエンドとフロントエンドに JavaScript を使用して、あちこちで次々と登場しています。Ruby は Rust よりも人気が 2 つ下です（Kotlin がその間にあります）ので、現時点では珍しい言語ではありません。確かに、あと 10 年すれば状況は異なるかもしれませんが、Rust への書き換えでさえ 10 年後には技術的負債になるでしょう。
その発言がいかにナイーブであるかを伝えるのは難しいので、みんなその考えに笑っているのです。私は開発者が 3 年間コードをリファクタリングしているのを見てきましたが、彼らは wxWidgets/ShuttleGUI から Qt/QML への移行に取り掛かろうとしているところです。これは、文脈からすると、C++ から C++ への移行ですが、UI ツールキットが異なります。コードの動作が同一であることを保証しながらコードを変換するのは、単に難しいことです。12〜16 日というのは、誰かが着手する前に計画だけで必要となる時間でしょう。
「いいね！」 15
私は最も生産的な開発者ではないかもしれませんが、PollプラグインをGlimmer Componentsに移行するのに3週間かかりました😅（言語変更すらしていません！）
「いいね！」 6
Rust や Ruby については分かりませんが、過去 1 年間で CDCK のチームが Ember 5 と Glimmer コンポーネントへのフロントエンドの書き直しで素晴らしい仕事をしたと感じています。これは、標準化されたコンポーネントとスタイルによるフロントエンドの再構築と実際に行われました。この背後にある調整された努力と目的に感銘を受けています 
ですから、Discourse をモダンで使いやすいものに保つために、何を近代化するかという点で、彼らは素晴らしい決定をしたと思います！
「いいね！」 21
Manuel、スタイル（CSS）に関して、どこかに文書化されていますか？ 主な変更点は何だとお考えですか？ DiscourseのCSSコードの構造は、以前よりも作業しにくいと感じますか？
スタイルに関しては、主な変更点は以下の通りです。
これにより、Discourse のカスタマイズがはるかに簡単かつ正確になると私は考えています。しかし、それはあなたの作業知識にもよるでしょう。CSS にあまり慣れていない人が調整を行いたいだけであれば、学習曲線はさらに急になる可能性があります。
ドキュメントについては、Styleguide を確認できます。利用可能なカスタムプロパティをスキャンする最も簡単な方法は、ブラウザの開発者ツールを使用することだと思います。Documentation も再作業中です。現在、Documentation には、developer-guides、Themes & Components、Interface の 2 つのセクションがあります。しかし、カスタムスタイルを宣言したいだけであったり、コンポーネントを作成したりする間には、大きな範囲があります。これらのいくつかは、開発者トピック間に埋もれすぎている可能性がありますか？ 
「いいね！」 9
もし別の言語に移植するのであれば、Go の方が良い選択肢になると思います。Web 管理者が評価するであろう利点の 1 つは、静的バイナリを出荷するため、再ビルドが不要なことです。これにより、コンテナもほとんど不要になります。実際、Discourse で非常に必要とされていると思われる機能は、Web サーバーとは異なるマシンでアプリを ビルド できることです。現在、最小限の最も安い VPS では、ビルドに 10 分近くかかります。ローカルのワークステーションでビルドしてから、最終的なバイナリを Web サーバーに転送して実行できれば、おそらく時間のほんの一部で済むでしょう。Go のような言語では、クロスコンパイルが容易であるため、M1 Mac でビルドしてから x86 Web サーバーにデプロイしたり (あるいは単にビルド、転送、ARM にデプロイしたり) できます。
ビルド中に最も時間がかかっているのはフロントエンドのコンパイルであると現在疑っています。そのため、ビルド時間に関して「Goか否か」は無意味です。
RustもGoもフロントエンドを置き換えることはないでしょう…
（追伸：私もGoは大好きです…）
「いいね！」 3