永遠の王などいない…ジグがCに代わる、それは当然の結論だ！

新しい言語の出現は本当に既存の言語を脅かす可能性があるのでしょうか? おそらく、本当に永遠の王は存在しないのでしょう。最近の Mojo と同様に、LLVM の父 Chris Lattner は、Python を脅かすことはないが、C++ などの言語を脅かすだろうと述べました。

新しい言語が際限なく出現すると、古い言語の中年の危機がさらに顕著になります。しかし、C++やCと同様に、彼らは釣魚台にしっかりと座っており、「常に悪口を言われているが、決して負けたことはない」ようだ。

しかし、Zig や Go のような、このプログラミングの祖先を置き換えようとする新たな挑戦者が常に存在します。そして、多くの新しい言語ユーザーは、「C は本当に進化する必要があるかもしれない!」と信じるでしょう。

この記事では、現時点で C の代替手段の中で Zig が最適である理由と、Zig 自体が C を置き換える実現可能な計画を持っている理由を具体的に説明します。

1. C はとても素晴らしいのに、なぜこんなにも多くの代替手段があるのでしょうか?

2. なぜ Zig は C++ ではなく C のみを置き換えることができるのか

3. Zig が C の最良の代替手段である理由は何ですか?

4. Zig言語とツールチェーンの優れた機能

5. 長期計画を伴う代替案

6. 結論

7. 拡張と拡張

1. C はとても素晴らしいのに、なぜこんなにも多くの代替手段があるのでしょうか?

C の資本が他のものより優れているのは事実ですが、結局のところ、このプログラミングの祖先がこれほど横暴なのは、現代のあらゆるソフトウェアシステムコンポーネントの作成者だからです。開発者は、Web サーバー、データベース、オペレーティングシステム、フレームワーク、プログラミング言語、クラウドコンポーネント、および多くのソフトウェアコンポーネントを C で作成します。多くのプログラミング言語は C を「置き換える」ことができると言っていますが、コンピューティングの歴史全体が C で作られてきたため、これは考えられません。

しかし、古い言語は常に「現代の発展」のペースに追いつくことができません。C++ 言語は、オブジェクト指向の概念、生産的な言語機能を実装し、標準ライブラリ API の C 言語のパフォーマンス優先設計を維持することにより、現代の開発者向けに C 言語構文を改善します。すべての C 開発者が直面する問題を解決できる C の代替案もいくつかあります。Zig、D、Go、および Odin は、C の代替として人気があります。

Zig は、組み込みのパッケージマネージャー、ビルドシステム、C に似ているがより優れた言語構文、フル機能の標準ライブラリ、成長するコミュニティなど、有望な将来性を示しています。Uber のような大企業も、クロスコンパイルに Zig ツールチェーンを使用し始めています。また、一部のソフトウェア会社は Zig ベースのコードリポジトリを使用してビジネスを開始しました。この話を使って、Zig がどのようにして C 言語に最適な選択肢になったのかを説明します。

2. なぜ Zig は C++ ではなく C のみを置き換えることができるのか

システムプログラミングは一般に、コンピューターハードウェアまたはオペレーティングシステム層に近いものを開発することを指します。システムプログラミングでは通常、他のソフトウェアシステムを実行できるソフトウェアモジュールを実装します。オペレーティングシステム、アプリケーションフレームワーク、組み込みシステムの作成は、システムプログラミングの良い例です。システムプログラマは、主に次の 2 つの言語タイプを選択できます。

C とその代替言語:従来の C、Go、Zig、Nim などの小型で高性能な言語を使用します。
C++ とその代替言語:従来の C++、Rust、Carbon、Cppfront など、やや複雑で高性能な言語を使用します。

ジグ語は第一言語に属します。これは、専用のランタイム (ガベージコレクターが組み込まれていない) を持たない、C に似た小型の高性能言語です。Zig は C 開発者が直面する問題を解決することで「より良い C」言語になろうとするのに対し、Rust は「より良い C++」言語になろうとしています。

3. Zig が C の最良の代替手段である理由は何ですか?

現在、C 言語には標準仕様といくつかの実装があります。たとえば、GNU/Linux システムでは GNU C コンパイラ、macOS では Apple Clang、Windows では MSVC を使用できます。C には、libc、Microsoft C ランタイムライブラリ、BSD libc、musl、Bionic などの複数の標準ライブラリ実装もあります。

ソフトウェアシステムを効率的に構築するには、コンパイラの実装と基本的な標準ライブラリだけでは不十分です。C プログラマは、ビルドシステム、パッケージマネージャ、テストランナーなどを使用する必要があります。これらのツールでは、既存のサードパーティツールを使用するか、独自のツール (BuildZri ビルドシステムなど) を作成する必要があります。

Zig は、組み込みのビルドシステム、パッケージマネージャー、およびテストランナーを提供します。Zig は、C 開発者がよく直面する問題に対するソリューションを提供することで C と競合しています。たとえば、Zig の公式コンパイラはクロスコンパイルをサポートしており、組み込みのテストランナーはソースコード自体の中に配置されたテストケースを実行できます。Zig の言語設計は、C に似たハードウェアに優しい設計を維持することで、より効率的な開発者に優しい機能を提供する傾向があります。Zig はハードウェアに優しいですが、最小限で安全、構文的には Rust に似ており、モダンです。したがって、開発者は C よりも効率的に使用できます。

Zig の未来的でハードウェアに優しい言語の概念を理解するには、以下の簡単な Zig コードスニペットを見てください。

const std = @import("std");

pub fn main() void {
    var nums = [_]u8{1, 2, 4, 5, 120};
    var x: usize = 3;
    var nums_seg = nums[1..x];

    std.debug.print("{any}\n", .{nums_seg});        // { 2, 4 }
    std.debug.print("{}\n", .{@TypeOf(nums_seg)});  // []u8 (slice)
}

Zig は、C のようにインポートを処理するためにプリプロセッサやマクロシステムを使用しません。組み込みの @import 関数を備えた、nodejs のようなモジュールインポート構文を使用します。ここでは、u8 プリミティブ型を使用して、符号なしバイトサイズの整数の配列を作成しました。次に、Zig スライスの概念を使用して配列からスライスを作成します。ご覧のとおり、Zig は C と同様のハードウェアに適したアトミック型システムを提供しますが、C の wait のような char、short、long ではなく、より標準化されたわかりやすい名前付けによって改良されています。

C では通常、プログラマ自身がプログラムを保護する必要がありますが、Zig は厳密なメモリ安全機能を実装しています。上記のバイト配列に 256 を追加してみてください。この実験を C で実行すると、プログラムは不正な値を暗黙的に保存します。Zig では、255 が符号なしバイト型で表現できる最大値であるため、コンパイルエラーが発生します。

Zig コンパイラによって表示される整数オーバーフローチェック、作成者のスクリーンショット

Zig の組み込みテストランナーと単体テスト API を使用すると、ソースファイルにテストを作成できます。

const std = @import("std");

fn add(a: i8, b: i8) i8 {
    return a + b;
}

test "add returns the summation" {
    try std.testing.expectEqual(add(10, 5), 15);
}

他の一般的な言語で C 相互運用が Zig ほど効率的であるのを見たことがありません。ほとんどの言語は C 相互運用に FFI (Foreign Function Interface) を使用しますが、Zig を使用すると、Zig スコープ内で C 関数を定義する必要さえなく C を呼び出すことができます。C ヘッダーファイルをインポートすると、構造体型が自動的に作成されます。

const std = @import("std");
const c = @cImport({
    @cInclude("stdio.h");
});

pub fn main() void {
    var a: u8 = 10;
    var char_count = c.printf("a = %d\n", a); // a = 10

    std.debug.print("{}\n", .{@TypeOf(char_count)}); // c_int
    std.debug.print("{}\n", .{char_count}); // 7
}

上記のコードスニペットに示されているように、Zig を使用すると、ネイティブ Zig 関数であるかのように C 関数を呼び出すことができますが、カスタムプレフィックス (多くの場合 C) が付いています。

Zig は組み込みの文字列型を提供しませんが、C のような低レベルの char 配列ベースの文字列処理概念と便利なショートカットを使用して文字列を操作できます。

std.debug.print("{s}\n", .{"Zig" ++ "Lang"});   // ZigLang (concatenation)
std.debug.print("{s}\n", .{"Zig" ** 5});   // ZigZigZigZigZig (repetition)
std.debug.print("{}\n", .{@TypeOf("string")});   // *const [6:0]u8 (a pointer to an unsigned byte array)

Zig 言語はハードウェア層に近い言語ですが、さまざまなショートカットや最新の言語概念 (スライス、組み込み関数、ループの短縮表現など) を実装して、システムプログラミングに効率的な言語を提供します。そのフル機能のモジュール式標準ライブラリは、Zig がシステムプログラミングを超えるのに役立ちました。汎用プログラミング言語に求められる制御構造、データ構造、基本的なアルゴリズムが提供され、システムプログラミングにも最適です。

クロスコンパイルやビルドシステム API などの Zig ツールチェーンの機能により、プログラマーは最新のシステムプログラミングで C ではなく Zig を選択するようになります。既存の C コードベースの場合、Zig ツールチェーンは代替 C/C++ コンパイラーと C 相互運用機能を提供するため、プログラマーはレガシー C コードベースを最新の Zig に段階的に移行できます。

4. Zig言語とツールチェーンの優れた機能

Zig 言語/ツールチェーンのいくつかの顕著な事実について議論し、それがどのように「より良い C」言語を目指すのかを見ていきます。Zig の多くの機能が、システムプログラミングに C の代替として Zig を選択するきっかけとなりました。

以下の強調表示された機能の概要をご覧ください。

Zig は単なる言語ではなく、システムプログラミングプロジェクトの開発、テスト、構築、リリースのためのフル機能を備えたツールチェーンです。
開発者向けの CLI は、すぐに使用できる実行可能ライブラリプロジェクトと共有ライブラリプロジェクトをサポートします。
Zig を使用すると C を呼び出すことができますが、C には依存しません。libc は Zig バイナリのオプションのコンポーネントです。
Zig には自動ガベージコレクターがないため、専用のランタイムがありません。そのため、高速で軽量のバイナリを生成します。
Zig は一般に中級言語ですが、非同期プログラミング構文、ジェネリックス、型強制 (自動および手動の両方) などの最新の汎用機能を提供します。
Zig ツールチェーンはクロスコンパイルを通じて C/C++ をコンパイルできるため、Zig 言語を使用する前に、その C/C++ コンパイラを使用して既存の C コードベースを構築できます。
Python などのクロスプラットフォーム OS レベル API を含む、よく書かれたモジュール式のフル機能の標準ライブラリ。
for-in ループ、複数の switch ケース (switch スコープ)、インライン for、switch ステートメントなど、ハードウェアに優しいシステムプログラミング環境を損なうことなく、生産性を最優先した言語機能を提供します。
これには、一般的な C プログラミングパターンに基づくエラー処理に対する enum ベースのアプローチが付属しており、複雑でエラーが発生しやすい例外の概念はありません。
アロケーターの概念と defer キーワードを通じて手動でメモリ管理を行うことができます。

5. 長期計画を伴う代替案

これまで、言語とツールチェーンの機能によって Zig がどのように優れた C 代替手段となるかについて説明してきました。パフォーマンスはどうですか? C よりも優れていますか?

C、C++、Rust、Zig など、専用のランタイムを持たないすべての言語は、特定の言語で記述されたすべてのソースコードから生のアセンブリを生成するため、システムプログラミング言語のパフォーマンスは、その言語で記述されたアセンブリコードの品質に依存します。バイナリ。システムプログラミング言語のコンパイラーは、LLVM 最適化または独自の成熟した最適化のいずれかを使用するため、どちらの言語が速いかを言うのは困難です。システムプログラミングのパフォーマンスは、多くの場合、プログラマーが作成するアルゴリズムに依存します。

ただし、Zig の公式ドキュメントでは、llvm ベースの最適化と未定義の動作の強化により、Zig は C よりも高速に実行されると主張しています。さらに、Zig は、LLVM を依存関係から削除することで、Zig をさらに改善することも計画しています。Zig Software Foundation (ZSF) はプロジェクトを積極的に維持し、コミュニティからの新しい設計提案を受け入れています。

Zig の有望な将来性により、Zig は C の最良の代替品となり、C プログラマーが既存のコードベースを最新の Zig に移行するようになりました。

6. 結論

このストーリーでは、Zig が小規模で開発者に優しく、ハードウェアに優しく、効率的で高性能かつ安全な言語設計を提供することで、どのように「より優れた」C 言語であるかについて説明します。改善された言語設計とツールチェーンにより、オペレーティングシステム、ライブラリ、クラウドコンピューティングモジュール、フレームワークの構築など、C を使用するユースケースで Zig が適切にパフォーマンスを発揮できるようになります。さらに、その将来の言語機能は、人気のある Go 言語と競合する可能性さえあります。

Zig やその他の将来のシステムプログラミング言語は決して C/C++ に「置き換わる」ことはありませんが、近代化が加速するにつれて、Zig はこれまでに作られた最高の C 代替言語の 1 つになりました。

7. 拡張と拡張

永遠の王は存在せず、問題を最適化する途中でテクノロジーは常に超えられます。これは、従来の開発ではなくローコードの場合に当てはまります。

伝統的な企業でも大規模なデジタル化が始まったこの10年で、社内ツールの開発過程では、大量のページ、シーン、コンポーネントなどが常に繰り返されていることが分かりました。このホイールはエンジニアにとって多くの時間を無駄にしました。

このような問題に対応して、ローコードテクノロジは、特定の繰り返し発生するシナリオとプロセスを個別のコンポーネント、API、データベースインターフェイスに視覚化し、ホイールの繰り返し作成を回避します。プログラマーの生産性が大幅に向上しました。

JNPF 高速開発プラットフォームは典型的なローコード自動化製品であり、業界をリードする SpringBoot マイクロサービスアーキテクチャと SpringCloud モードを採用し、プラットフォームの拡張基盤を改善し、迅速なシステム開発、柔軟な拡張、シームレスな統合、および統合のニーズを満たします。高性能アプリケーションやその他の包括的な機能により、フロントエンドとバックエンドの分離モードを採用することで、フロントエンドとバックエンドの開発者が協力して異なるセクションを担当できるため、手間が省け便利になります。

数千の一般的に使用されるクラスがフロントエンドとバックエンドでカプセル化されており、拡張に便利です。コードジェネレーターが統合されており、フロントエンドとバックエンドでのビジネスコードの生成をサポートし、迅速な開発を実現します。フレームワークには、一般的に使用されるさまざまなデモが統合されています。フォーム、レポート、グラフ、大画面などを簡単かつ直接使用できます。バックエンドフレームワークは Vue2 と Vue3 をサポートしています。

体験のためにURL: www.jnpfsoft.com/?csdnを添付してください。