D言語をプロダクションに使うには、ということを考える

D言語のコードを社のレポジトリにpushした。(まだmasterにmergeされていないので、先走り気味かもしれない)

D言語を使った理由は使いたかったというのもあるが、今回のケースでは

• 使う箇所が部分的(言語はわりとなんでもいいところ)
• 標準でjsonを扱うためのライブラリがついている(まあ今時の言語だとだいたいありそうな,Rustは標準でなかったので外れた)
• バイナリを置けばいいだけのほうが楽そう(共有ライブラリのバージョンや置き場所の問題があるので、distroが同じという前提はあった)
• 静的型チェックがある(これはチームの文化として)
• それなりに安定して使える(NimとかCrystalとかPonyとかはこのへんで省かれる)

このへんを満たしているという点で、D言語を使うことが合理的な判断だったというところがある。この場合golangでよかった気がするけれど。

ユースケースを満たせばいいってものでもなく、D言語がチームで受け入れられるか、という点も大事になる。

チーム内での評価は

• Pros
  • (C++がチームの標準言語なので)似たような構文なので読みやすい
  • 構文はわりとよい(型推論があるとか)
  • unittestを関数の近くに書けるところ
• Cons
  • パターンマッチがない
  • 直和型がない(std.variantは、まあ…)

といった感じ。OCamlとかHaskellが好まれるチーム文化があるけれど、C++も書くチームなので受け入れられやすい。気がする。

D言語投入ありきで考えて、プロダクション投入するには、

1. 小さく独立した部分ではじめる(動く状態を作ることが大事。時間かけるとけっきょくだれかにPythonとかで書かれてしまう)
2. チームの文化に合致するか見定める(けっきょく他の人がレビューしないって言ったら別の言語で書くしかない)

この2点に集約される気がする。