プロジェクトの翻訳者および作成者によるProDBGについての少し
ProDBGは、ダニエルコリンによって現在開発されている新しいデバッガーです。 プロジェクトの目標の1つは、多くのアーキテクチャとオペレーティングシステムをサポートすることです。 最初はC / C ++で書かれており、プラグインのサポートが用意されています。 現時点では、開発の初期段階にあり、主にMacOSを対象としています。 次に、投稿者にフロアを渡します。
Twitterで私を読んだ人たちが知っているように、私はC ++はあまり好きではありません。 ヘッダーファイル、不完全なテンプレートなどに通常の問題があります。 そして、大きな問題は代替案を見つけることです。 C＃に切り替えるオプションを検討しましたが、すべてのプラットフォームで適切に機能させることは非常に難しいタスクのようです（たとえば、現時点では、Macでのx86サポートは実質的にありません）。 さらに、この選択が気に入らない人もいます。
私は（Common）Lispが好きです。 私はそのマクロの構造を賞賛します。すべての言語には見られない優雅さを持っています。 しかし、多くの人にとってはどうやら相反するように思われるため、プロジェクトへの投資ははるかに困難になります。 さらに、可能な場合は常にガベージコレクタなしで言語を使用し、Lispを大幅に高速化できますが、それほど単純ではありません。
Rustへの参加
Rustを数年間フォローしましたが、2015年5月にバージョン1.0がリリースされるまでは何も書きませんでした。 Rustを見始めたとき、Rustに役立つものがあるかどうかを理解したかったのです。 紙の上では、すべてが良さそうでした（私にとって最も興味深い点のリストを示します）。
- メモリの安全性を保証。
- データ競合のないストリーム。
- 最小限のランタイム。
- Cへの効果的なバインディング
- ガベージコレクターの欠如。
- モジュール
- LLVMを使用します。
- ネイティブコードにコンパイルされます。
Rustを使用するとどうなるかを確認することにしました。 Rustについてもプレゼンテーションを行いました 。 こちらでご覧いただけます 。
その瞬間、私はサポートされているRustプラットフォームのリストを検討し始めました。 Mac、Windows、Linuxをサポートしています。 通常、少なくとも「新しい」言語では、Windowsサポートはまあまあです。 RustはWindowsでうまく機能し、Rustチームに感謝します。
私のその他の質問：「Rustは大規模プロジェクトに使用されますか？」今後数年間はどこにも使用されない言語に切り替えるのは面倒です。 Rust自体はRustで書かれており、非常に大きいようです。 MozillaのServoも大きなプロジェクトであり、Rustでも書かれています。
Rustはプラグインに適していますか？
私の次の動きは、クリスマス休暇の終わりにプラグインのRustサポートを追加し（現在はC / C ++のみがサポートされています）、プラグインを書くのがどれだけ簡単かを調べることです。 また、関数ポインターを使用した構造に基づいてC APIをRustでラップすると、非常に効果的です。 これは（初期の） 例です。
この例の多くのコードは、Rustをより慣用的にすれば改善できますが、C APIで実際に機能します。
完全な書き換えなしでRustでProDBGを書き換えることは可能ですか？
私は、C ++コードのさまざまな部分を明らかにし、Rustから「prodbg_main」のみを呼び出すことから始めました。 いくつかのリンクエラーを修正した後、動作しました！ これはRustの強みの1つです。コンパイルされた言語であるため、DLLの形で接着剤なしでC / C ++コードとリンクできます。
それから、残りのコードを明らかにし始めました。 動的ライブラリ（プラグイン）をロードし、画面の1つに表示する「プラグインハンドラ」を作成しました。 同時に、プラグインのリロードを追加したため、プラグイン（RustまたはC / C ++で記述できる）をコンパイルするときに、すぐに再起動します。これは素晴らしいことです。
ここで 、メインコードに深く飛び込む前に再生できるテストコードを確認できます（コードが使用できなくなった瞬間、約Transl。） 。
そして今何？
Rustで少し遊んだ後、言語は間違いなく私を魅了しました。 これは素晴らしい機能を提供する素晴らしい言語です（ 私のプレゼンテーションをご覧ください）。 私は特に、人生の時間と借用のシステムに注目したいと思います。 借用/有効期間の良い点は、Rustコンパイラを真に不変の状態で制御できることです。これにより、LLVMフェーズのnoaliasを含めることができるため、RustはCコードよりもパフォーマンスが優れています。
Rustコミュニティに参加し、言語の開発を監督することで、その将来に希望が持てるので、RustでProDBGを書き始めることにしました。 同時に、外部のC ++コード（imgui、Scintilla、bgfxなど）に依存します。 Rustですべてを書き換える理由はありません。 プラグイン用にまだ開いているAPIはCのままです。これにより、他の言語（Lua、Python、JS、.NET）のサポートを追加することは、将来的にはるかに簡単になります。
欠点
C / C ++と同じくらい多くの人々が使用する言語に切り替えると、常に問題が発生します。 遅いコンパイラ（この問題で動作します）、デバッグの難しさ（まだ良いフロントエンドはありませんが、私にとってそれは良い動機だと思います:)、言語を知っている人が少なく、将来誰が起こるかわかりません すべてが述べられたにもかかわらず、私はまだRustが正しい軌道に乗っていると思います、そして、それに切り替えることは正しい決定であるように思えます。
最大の欠点は、最初の移行によりプロジェクトの開発が遅くなることです。 私はこれまでバージョン0.1に到達することを望んでいましたが、現在はリリースが遅れています。
あとがき
これらは物です。 この決定はプロジェクトのすべての参加者に影響するため、簡単ではありませんでした。 APIはCになり、C / C ++で記述されたプラグインとして貢献を受け入れることに注意してください。
それでも、決定は正しかったと思います。 ここ （ 英語 ）では、2015年に言語に何が起こったのか、そして2016年に何が待っているのかを読むことができます。