D and Goは、おそらく今日のPythonやRubyと同じくらい人気があります。それらはそれぞれニッチを埋め、DはC ++の本格的な代替品であると想定されていましたが、C++を押しのけるのに十分な質量を獲得することはおそらくないでしょう。言うまでもなく、どちらも十分に安定しておらず、成熟しておらず、当時のハードウェアとオペレーティングシステムでこれらの言語を10〜20年以内にサポートできるかどうかは不明です。C / C ++はほとんどコンパイルされた言語であり、オペレーティングシステムやネイティブコードアプリケーションの大部分で使用されていることを考えると、近い将来になくなる可能性はほとんどありません。
C and C++ are a pretty much unbeatable combo when it comes to native/unmanaged/"lowlevel" languages.
Not because they're the best languages, far from it, but because they're there, they do the job, and they're good enough. There's little doubt that D, for example, is better than C++ in most respects. But it fails in the most important one: Compatibility with all the existing C++ code. Without that requirement, most of that code would be written in a managed language today anyway. The only reason so many codebases use C++ today is because they used it last year, and it'd be too much of a pain to switch to something else. But if and when they switch, they typically don't switch to D. They switch to C# or Java or Python.
The problem for D and other "upcoming" languages competing for the same niches, is that while they're better, they're not groundbreaking enough to motivate people to actually switch to them.
So C and C++ are here to stay. C is unlikely to evolve much further. It is as it is, and one of the niches it has to fill is "simplicity, even for compiler writers". No other language is likely to beat it in that niche, even if they never revise the standard again.
C++ is evolving much more dramatically, with C++0x getting nearer, and they've already got a huge list of features they want to do afterwards. C++ isn't a dead end in any way.
Both languages are here to stay. Perhaps in 50 years other languages will have replaced them, but it won't happen this decade.
私は現在Dを定期的に使用しています。最先端すぎるので、プロダクション コードを書いている人にはまだお勧めしません。私のコードのほとんどはバイオインフォマティクスの研究プロトタイプであるため、私はそれを回避します。しかし、言語は安定し始めています。Andrei Alexandrescu は、来年 3 月に「The D Programming Language」というタイトルの本をリリースします。現在、本に間に合うように言語のバージョン 2 の仕様を安定させるための圧力がかかっています。
D は C の正式なスーパーセットではありませんが、プリプロセッサがないことを除けば、慣用的なスーパーセットと呼んでいます。つまり、適切な C で記述されたコード (プリプロセッサを無視) は、再設計せずに簡単に D に変換できます。これは、ポインタやインライン ASM などの C の概念が存在し、D でも C と同じように機能するためです。D は直接もサポートしています。 C コードへのリンクおよび D 標準ライブラリには、C 標準ライブラリ全体が含まれます。
また、D はまだ最先端の言語であるためライブラリが不足していますが、そのメタプログラミング機能により、D はライブラリ作成者の夢です。それがうまくいけば、おそらくかなり印象的なライブラリがいくつかあるでしょう。これのプレビューについては、D2 標準ライブラリ (Phobos) の std.range または std.algorithm を参照してください。別の例として、OpenMP のような並列処理モデル (並列 foreach、並列マップ、並列リデュース、フューチャー) を D の純粋なライブラリとして実装しましたが、特別なコンパイラ サポートはありません。( http://cis.jhu.edu/~dsimcha/parallelFuture.htmlを参照)
あなたが主に長期的に興味を持っていることを考えると、D が安定するまで 6 か月かかると思います (Andrei の本と言語を安定させるための現在のプッシュを考えると、バージョン 2 はそれまでに安定しているはずです)。それ。
編集:コア言語仕様は比較的安定しており、ツールチェーンとライブラリの開発に焦点が移ったため、非常にリスクを嫌う環境でない限り、小規模な実稼働プロジェクトには D をお勧めします。ただし、優れたツールチェーンとライブラリのサポートが絶対に必要な大規模なプロジェクトは、まだ待つ必要があります。
リーン生産方式を信じるなら、「できるだけ遅く決定する」ように努力する必要があります。その瞬間は最後の責任ある瞬間でなければなりません。つまり、決定を下さなかった瞬間が重要な代替案を排除する瞬間です。
この原則はあなたの状況に適用できると思います。今すぐ言語にコミットするのではなく（10年後には存在するかどうかさえわからない）、オプションを開いたままにしておく必要があります。たぶん、コードの一部をリファクタリングして、もう少し一般的であるか、より多くの抽象化に基づいて構築されているため、実際に移行が必要な場合は、プロセスが簡単になります。
C++-比較的若く、更新されています...多数のコンパイラベンダーがあり、常に改善されています。
C-アセンブラと高級言語の間のギャップを埋めるのに長い間生きていたでしょう。また、非常にシンプルで実装が簡単な言語であるため、組み込みまたは非常に新しいアーキテクチャなど、さまざまな「奇妙な」アーキテクチャの最初の言語のままになります。
D有望ですが、それでも非常に新しく不安定な仕様とライブラリです。
Go数週間前に生まれました...大きな重要なプロジェクトにはバージョン0のものを使用しないでください。また、それは大幅に制限されていC++ますD。
C と C++ に固執します。私はそれがCOBOLのやり方で進んでいるとは思わない.それは何と同じように動くし、CやC++でコーディングする人を見つけるのに問題はないだろう.
2019 年の更新: C++ は今後 10 年間存続します... (そうでない場合は、この回答を修正します。関連性がなくなったときに....)
今日、企業が COBOL を使用する理由は、企業がすでに何百万もの COBOL コードを記述しているためです。それを投げることができれば - 彼らはすぐにそれをするだろう - 一方、企業はニーズの一部として C/C++ を使用し、この言語を使用する新しいプロジェクトは、Java を使用できない/使用したくない/c# 他のフレームワーク ベースの言語 - したがって、COBOL はここでは類推しません。
dsimchaが言ったように、Dウェイは現在危険です。それでも、この言語には大きな可能性があります。それは低レベルであり、私は（C ++の代わりに）Dを使用することで劇的に優れた生産性を体験しました。おそらく、人々が動的言語で感じること。
Goはブログで販売されているので、私には冗談のようです。インターフェイスメソッドのディスパッチは簡単ではなく、実際には通常の単一継承メソッドのディスパッチよりも遅くなります。
巨大なコードベースがある場合は、もちろん決定がより困難です。既存のプロジェクトではなく、新しいプロジェクトに切り替えることをお勧めします。
私は言語に集中するのではなく、それを取り巻くライブラリに集中します。C++ とブースト ライブラリの組み合わせは、優れた選択肢です。C++ で開発する人は、コンピューティングをよりよく理解している傾向があります。私自身、Java から始めたので、多くの基本的なことを隠すことができて生活が楽になりました。これは良いことですが、プログラミングを本当に理解し始めたのは、C/ C++ (ポインターなど)。
私は C++ が難しい (メモリ管理など) 可能性があることを認識しているので、パフォーマンスが重要ではなく、読みやすさ (== 保守性) のスコアが高い「アドオン」言語を使用するのは良いことだと思います。これには Python をお勧めします。
C ++ソフトウェアを実行しているマシンは無数にありますが、一度にシャットダウンすることはありません。C ++がCOBOLの邪魔になるとしたら、アプリケーションの移行には巨大な市場が存在するでしょう。C ++アプリケーションを当時の人気言語（Z ++ ???）に翻訳するために開発された専用ツールがあります。
ですから、その橋にたどり着いたら、その橋を渡ることが最善のアドバイスだと思います。
C ++ /マルチコア開発への関心を高めたい場合は、インテル®Cilk++ソフトウェア開発キットをチェックしてください。CまたはC++がすぐになくなることもありません。
C* を Cobol と比較すると、間違った結論につながる可能性があります。C は当時としては完璧であり、導入の大きな飛躍であり、今日でも仕事をこなしています。
私は、最も慈善的な日に Cobol を「ナイス トライ」で要約します。
C と C++ は、実装言語としての要件に適合するため、長く存続します。これは本当に変わることはありません。
また、C/C++ の主なマイナスの問題はメモリの安全性の欠如であることを考慮してください。これは、コードが成熟するにつれて問題が少なくなる傾向があります。これは、古いコードを置き換える重大な理由がないことを意味します。
私は、ソフトウェア システムが C から外に向かって成長することを期待しています。今日の階層を見てください。
古い層がなくなるとは思わないし、C と C++ で書かれた従来の上位層は、無期限にそのようにサポートされ、最終的には Ruby、Python、C# で書かれた代替のために段階的に廃止されると思います。または今後の展開。
Goが受け入れられるかどうかはわかりません。Google のそばにいるだけではおそらく十分ではありません。
え？まあ、それについていくつかの良いことが言われていますが、それも離陸することはありません. 話すユーザーベースはありません。D はTIOBE インデックスで人気が 20 位で、急落しています。
言語の人気は、その言語が会社の業務にどれだけ適しているかとはほとんど関係がないと言うかもしれません。しかし、それはプログラミングに適した人をいかに簡単に見つけられるかに大きく関係しています。
Javaがトップであり、今後 20 年以内に Java が遠く離れていたら驚くでしょう。システム プログラミング言語とは見なされていませんが、Java ではできなかった C++ で実行できるタスクがほとんどないほど十分に機能します。確かに最近では、ガベージ コレクターが (完璧に、そして多くの場合より効果的に) 行った仕事を人間のプログラマーに任せようとする人は誰もいません。私は、プログラミングの効率という点で、Java が C++ から大幅に進歩したと考えていました。
私はRubyにとても感銘を受けました。それは洗練された表現力豊かな言語です。あまり多くのコードを使用せずに多くのことを達成できますが、そのコードは依然としてほとんど判読可能です。Ruby の主な原則の 1 つは、一貫性を保ち、開発者を驚かせないことです。これは非常に良いアイデアであり、IMO であり、生産性を向上させます。Rails が大流行していたとき (まだ進行中かもしれません)、Ruby のリファレンス実装が非常に遅いため、私は Ruby に大きく距離を置いていました。しかし、Sun のJRuby 関係者は、JVM 上で非常に高速であるため、検討する価値があることは間違いありません。Ruby は、実際には FP 言語とは見なされていませんが、クロージャーといくつかの関数型プログラミング機能を提供します (これが重要な理由については以下を参照してください)。TIOBE 指数: 10 と上昇中。
将来的に考慮すべきことは、CPU メーカーが物理学によって課されるパフォーマンスの限界に直面しているという事実です。過去のように、毎年クリスマスに利用できる 30% 高速な CPU はなくなりました。したがって、パフォーマンスを向上させるには、より多くのコアが必要です。ソフトウェア開発には、マルチコアの同時プログラミングをサポートするために得られるすべての支援が必要です。C++ では、ほとんどの場合、これに取り残されてしまいます。Java のソリューションは、現代の基準からすれば恐ろしいものです。
このことを考慮して、関数型プログラミング (同時実行に伴う面倒な作業の多くを排除する) や、より優れた同時実行サポートを備えた言語に向かう特定の傾向があります。Erlangは、これと、実行中のプログラムでコードを交換する機能のために特別に作成されました (Ericsson は信じられないほどのアップタイムを望んでいました)。Scalaは Java に似ていますが、関数型プログラミングと並行性をより強力にサポートしています。Clojure、同上ですが、これは Lisp であり、トップ 50 にも入っていません (まだ!!)。
Scala は学者によって開発されたものであり、それを示しています。プログラミング言語のスイス アーミー ナイフになろうとしています。中程度の頭脳を持つプログラマーの多くは、Scala を理解するのに苦労すると思います。Ruby は FP ではなく、同時実行性についてはそれほど重要ではありませんが、実用的で、楽しく、簡単に作業を完了できます。また、JVM で実行すると、Java ライブラリですぐに利用できる大量のコードがあり、Rubyとインターフェースできます。そう：
私の賭けはRubyにあり、外部のチャンスはScalaにあります。しかし、代替手段はたくさんあります！
Java。最近のほとんどの低レベルのものでは、Javaで問題ありません。Javaと同じくらい安全で簡単に開発できるものがあるのに、なぜDやGoなどのC / C++の部分的なソリューションを採用するのでしょうか。リアルタイムソリューションを探しているなら、DとGoは間違いなくそうではありません。言うまでもなく、Javaよりもサポートが少ないでしょう。
Javaはシステムプログラミング言語になりました。「次世代」のポインタなど、安全でない構造を使用して何かを検討する方法がわかりません。これらの安全でない構造がこれまでに存在した唯一の理由は、チューリング完全言語を構築するための実用的なアプローチであったためです。個別のオブジェクトでメモリを表現する必要はありませんでした。なぜなら、それらは機能するものを構築したかっただけだからです。Javaには、ハードウェアとソフトのリアルタイムアプリケーション、さまざまなハードウェアバイトコードプロセッサ、およびJavaを実行する20億を超えるモバイルデバイスがすでに存在します。せいぜい、あなたがしなければならないのは、デバイスとの相互運用性のためのいくつかの構造を追加することだけです。これはそれほど多くのコードではありません。C / C ++でも、これらの構造を追加する必要があります...
何をプログラミングしていますか？1KBのRAMを搭載した8ビットマイクロコントローラー？その場合、そのプラットフォームにアセンブラ以外のものを使用するのは無意味です...