この記事は以前に公開された記事への返答として書かれたものです 対蹠地の記事.

過去 XNUMX 年以上にわたり、私は Go を使用して、開発された課金システムを備えた特殊な RADIUS サーバーを実装してきました。 その過程で、私は言語自体の複雑さを学んでいきます。 プログラム自体は非常に単純であり、この記事の目的ではありませんが、Go 自体を使用した経験は、Go を擁護するためにいくつかの言葉を加える価値があります。 Go は、本格的でスケーラブルなコードの主流の言語になりつつあります。 この言語は Google によって作成され、積極的に使用されています。 結論から言えば、私は正直に言って、Go 言語の設計は知性のないプログラマーにとって悪いものだと考えています。

弱いプログラマー向けに設計されていますか?

弱者は問題について話す。 アイデアや夢について力強く語ります...

Go は学習が非常に簡単で、事実上まったくトレーニングを行わなくてもコードを読むことができるほど簡単です。 この言語の機能は、多くのグローバル企業で、中核ではない専門家 (マネージャー、顧客など) と一緒にコードを読むときに使用されています。 これは、デザイン駆動開発などの方法論に非常に便利です。
初心者プログラマーでも、XNUMX ～ XNUMX 週間後にはかなりまともなコードを作成できるようになります。 私が勉強した本は「Go Programming」（マーク・サマーフィールド著）です。 この本はとても良くて、言語の多くのニュアンスに触れています。 Java や PHP などの必要以上に複雑な言語を使用した後では、魔法がないのが新鮮です。 しかし、遅かれ早かれ、多くの限られたプログラマーは、新しい分野で古い手法を使用するという考えを持ちます。 これは本当に必要ですか?

ロブ・パイク (この言語の主なイデオロギー者) は、理解しやすく効果的に使用できる産業言語として Go 言語を作成しました。 この言語は大規模なチームで最大限の生産性を発揮できるように設計されており、それについては疑いの余地がありません。 多くの初心者プログラマは、欠けている機能がたくさんあると不満を抱いています。 この単純さへの欲求は、言語の設計者による意識的な決定であり、なぜそれが必要なのかを完全に理解するには、開発者の動機と、開発者が Go で何を達成しようとしていたのかを理解する必要があります。

では、なぜこれほどシンプルになったのでしょうか? ロブ・パイクの言葉をいくつか引用します。

ここで重要な点は、当社のプログラマーは研究者ではないということです。 彼らは通常、非常に若く、おそらく Java、C/C++、または Python を勉強した後、私たちのところに来ます。 彼らは優れた言語を理解することはできませんが、同時に私たちは彼らに良いソフトウェアを作ってもらいたいと考えています。 だからこそ、言語は理解しやすく、学びやすいものでなければなりません。

彼はよく知られているはずで、大まかに言えば C に似ています。 Google で働くプログラマーはキャリアを早くからスタートしており、手続き型言語、特に C ファミリに精通していることがほとんどです。 新しいプログラミング言語で迅速な生産性が求められるということは、言語が過激になりすぎてはいけないことを意味します。

賢明な言葉ですね。

シンプルさのアーティファクト

シンプルであることは美しさの必須条件です。 レフ・トルストイ。

シンプルさを保つことは、あらゆるデザインにおいて最も重要な目標の XNUMX つです。 ご存知のとおり、完璧なプロジェクトとは、追加するものが何もないプロジェクトではなく、削除するものが何もないプロジェクトです。 多くの人は、複雑な問題を解決するには (あるいは表現するには)、複雑なツールが必要であると信じています。 しかし、そうではありません。 PERL 言語を例に考えてみましょう。 言語イデオロギー学者は、プログラマーは XNUMX つの問題を解決するために少なくとも XNUMX つの異なる方法を持っている必要があると信じていました。 Go 言語のイデオロギー者たちは、目標を達成するには XNUMX つの方法だけで十分であると判断し、別の道を選択しました。 このアプローチには重要な基礎があります。それは、学びやすく忘れにくい唯一の方法です。

多くの移民は、この言語にはエレガントな抽象概念が含まれていないと不満を抱いています。 はい、これは真実ですが、これはこの言語の主な利点の XNUMX つです。 この言語には最小限の魔法が含まれているため、プログラムを読むために深い知識は必要ありません。 コードの冗長さに関しては、これはまったく問題ではありません。 よく書かれた Golang プログラムは、構造がほとんど、またはまったくなく、垂直方向に読み込まれます。 さらに、プログラムを読み取る速度は、プログラムを書き込む速度よりも少なくとも XNUMX 桁高速です。 すべてのコードの書式設定が統一されている (組み込みの gofmt コマンドを使用して実行される) と考えれば、余分な数行を読み取ってもまったく問題ありません。

あまり表現力が無い

芸術は自由が制約されることを許しません。 正確さは彼の責任ではありません。

単純さを求めるため、Go には他の言語に慣れている人にとって自然なものとして認識されるような構成要素が欠けています。 最初は多少不便に感じるかもしれませんが、プログラムがずっと読みやすく、明確になっていることに気づきます。

たとえば、標準入力またはコマンド ライン引数からファイルを読み取るコンソール ユーティリティは次のようになります。

package main

import (
    "bufio"
    "flag"
    "fmt"
    "log"
    "os"
)

func main() {

    flag.Parse()

    scanner := newScanner(flag.Args())

    var text string
    for scanner.Scan() {
        text += scanner.Text()
    }

    if err := scanner.Err(); err != nil {
        log.Fatal(err)
    }

    fmt.Println(text)
}

func newScanner(flags []string) *bufio.Scanner {
    if len(flags) == 0 {
        return bufio.NewScanner(os.Stdin)
    }

    file, err := os.Open(flags[0])

    if err != nil {
        log.Fatal(err)
    }

    return bufio.NewScanner(file)
}

D での同じ問題に対する解決策は、多少短く見えますが、読みやすいとは言えません。

import std.stdio, std.array, std.conv;

void main(string[] args)
{
    try
    {
        auto source = args.length > 1 ? File(args[1], "r") : stdin;
        auto text   = source.byLine.join.to!(string);

        writeln(text);
    }
    catch (Exception ex)
    {
        writeln(ex.msg);
    }
}

コピー地獄

人間は自分の中に地獄を抱えています。 マルティン・ルター。

初心者はジェネリックが不足しているという点で Go について常に不満を抱いています。 この問題を解決するために、ほとんどの場合、コードを直接コピーします。 たとえば、整数のリストを合計する関数ですが、そのような専門家志望者は、この機能はデータ型ごとに単純にコピーアンドペーストする以外の方法では実装できないと考えています。

package main

import "fmt"

func int64Sum(list []int64) (uint64) {
    var result int64 = 0
    for x := 0; x < len(list); x++ {
        result += list[x]
    }
    return uint64(result)
}

func int32Sum(list []int32) (uint64) {
    var result int32 = 0
    for x := 0; x < len(list); x++ {
        result += list[x]
    }
    return uint64(result)
}

func main() {

    list32 := []int32{1, 2, 3, 4, 5}
    list64 := []int64{1, 2, 3, 4, 5}

    fmt.Println(int32Sum(list32))
    fmt.Println(int64Sum(list64))
}

この言語には、そのような構造を実装するための十分な手段が備わっています。 たとえば、一般的なプログラミングでも問題ありません。

package main

import "fmt"

func Eval32(list []int32, fn func(a, b int32)int32) int32 {
    var res int32
    for _, val := range list {
        res = fn(res, val)
    }
    return res
}

func int32Add(a, b int32) int32 {
    return a + b
}

func int32Sub(a, b int32) int32 {
    return a + b
}

func Eval64(list []int64, fn func(a, b int64)int64) int64 {
    var res int64
    for _, val := range list {
        res = fn(res, val)
    }
    return res
}

func int64Add(a, b int64) int64 {
    return a + b
}

func int64Sub(a, b int64) int64 {
    return a - b
}

func main() {

    list32 := []int32{1, 2, 3, 4, 5}
    list64 := []int64{1, 2, 3, 4, 5}

    fmt.Println(Eval32(list32, int32Add))
    fmt.Println(Eval64(list64, int64Add))
    fmt.Println(Eval64(list64, int64Sub))
}

また、コードは前のケースよりも若干長くなりましたが、一般化されました。 したがって、すべての算術演算を実装することは難しくありません。

D のプログラムはかなり短く見えると多くの人が言うでしょうが、それは正しいでしょう。

import std.stdio;
import std.algorithm;

void main(string[] args)
{
    [1, 2, 3, 4, 5].reduce!((a, b) => a + b).writeln;
}

ただし、D の実装ではエラー処理の問題が完全に無視されているため、これは短いだけであり、より正確であるわけではありません。

現実の世界では、ロジックが複雑になるにつれて、そのギャップは急速に狭まります。 標準言語の演算子を使用して実行できないアクションを実行する必要がある場合、その差はさらに急速に縮まります。

私の意見では、保守性、拡張性、読みやすさの点では Go 言語が勝っていますが、冗長性では劣っています。

場合によっては、汎用化されたプログラミングは、否定できない利点をもたらします。 これは、sort パッケージで明確に示されています。 したがって、リストを並べ替えるには、sort.Interface インターフェイスを実装するだけで済みます。

import "sort"

type Names []string

func (ns Names) Len() int {
    return len(ns)
}

func (ns Names) Less(i, j int) bool {
    return ns[i] < ns[j]
}

func (ns Names) Swap(i, j int) {
    ns[i], ns[j] = ns[j], ns[i]
}

func main() {
    names := Names{"London", "Berlin", "Rim"}
    sort.Sort(names)
}

オープンソース プロジェクトを取得して grep “interface{}” -R コマンドを実行すると、わかりにくいインターフェイスがどのくらい頻繁に使用されているかがわかります。 心の狭い同志は、これはすべて後発医薬品の欠如によるものだとすぐに言うでしょう。 ただし、常にそうとは限りません。 DELPHI を例に挙げてみましょう。 これらの同じジェネリックが存在するにもかかわらず、任意のデータ型を使用した操作のための特別な VARIANT 型が含まれています。 Go 言語でも同じことができます。

大砲からスズメまで

そしてその拘束衣は狂気の大きさに見合ったものでなければならない。 スタニスラフ・レック

多くの極端なファンは、Go にはジェネリックスを作成する別のメカニズムであるリフレクションがあると主張するかもしれません。 そして彼らは正しいでしょう...しかしそれはまれなケースです。

ロブ・パイクは私たちに次のように警告しています。

これは強力なツールであるため、使用には注意が必要です。 厳密に必要な場合を除き、これは避けるべきです。

ウィキペディアには次のように書かれています。

リフレクションとは、プログラムが実行中に自身の構造と動作を監視および変更できるプロセスを指します。 リフレクションの基礎となるプログラミング パラダイムは、リフレクティブ プログラミングと呼ばれます。 これはメタプログラミングの一種です。

ただし、ご存知のとおり、すべての料金を支払わなければなりません。 この場合は次のようになります。

• プログラムを書くのが難しい
• プログラムの実行速度

したがって、反射は大口径兵器と同様に注意して使用する必要があります。 リフレクションを軽率に使用すると、プログラムが読めなくなり、エラーが絶えず発生し、速度が低下します。 俗物プログラマーにとって、より現実的で控えめな同僚の前で自分のコードを披露できることはまさにそれです。

習近平からの文化的な荷物？ いいえ、さまざまな言語からです。

財産とともに借金も相続人に残ります。

この言語は完全に C の伝統に基づいていると多くの人が信じているという事実にもかかわらず、そうではありません。 この言語には、最高のプログラミング言語の多くの側面が組み込まれています。

構文

まず、文法構造の構文は C 言語の構文に基づいています。 ただし、DELPHI 言語も大きな影響を与えました。 したがって、プログラムの可読性を大幅に低下させる冗長な括弧が完全に削除されていることがわかります。 この言語には、DELPHI 言語に固有の「:=」演算子も含まれています。 パッケージの概念は、ADA などの言語から借用されています。 未使用エンティティの宣言は PROLOG 言語から借用されています。

セマンティクス

パッケージは DELPHI 言語のセマンティクスに基づいていました。 各パッケージにはデータとコードがカプセル化されており、プライベート エンティティとパブリック エンティティが含まれています。 これにより、パッケージ インターフェイスを最小限に抑えることができます。

委任メソッドによる実装操作は DELPHI 言語から借用されました。

編集

Go は C プログラムのコンパイル中に開発されたという冗談があるのも当然です。 この言語の強みの XNUMX つは、超高速なコンパイルです。 このアイデアは DELPHI 言語から借用されました。 各 Go パッケージは DELPHI モジュールに対応します。 これらのパッケージは、本当に必要な場合にのみ再コンパイルされます。 したがって、次回の編集後は、プログラム全体をコンパイルする必要はなく、変更されたパッケージと、これらの変更されたパッケージに依存するパッケージのみを再コンパイルします (その場合でも、パッケージ インターフェイスが変更された場合に限ります)。

高レベルの構成要素

この言語には、C などの低レベル言語とはまったく関係のないさまざまな高レベルの構成要素が含まれています。

• 文字列
• ハッシュテーブル
• スライス
• ダックタイピングは RUBY などの言語から借用しています (残念なことに、多くの人はその可能性を理解していないか、最大限に活用していません)。

メモリ管理

メモリ管理については通常、別の記事を書く必要があります。 C++ などの言語では制御が開発者に完全に委ねられていましたが、DELPHI などのその後の言語では参照カウント モデルが使用されました。 このアプローチでは、孤立クラスターが形成されるため、循環参照は許可されませんでしたが、Go にはそのようなクラスターの検出機能が組み込まれています (C# と同様)。 さらに、ガベージ コレクターは現在知られているほとんどの実装よりも効率的であり、すでに多くのリアルタイム タスクに使用できます。 言語自体は、変数を格納する値をスタックに割り当てることができる状況を認識します。 これにより、メモリ マネージャーの負荷が軽減され、プログラムの速度が向上します。

同時実行性と同時実行性

この言語の並列性と競争力は賞賛の余地がありません。 Go に遠く及ばない低レベル言語はありません。 公平を期すために、このモデルは言語の作成者によって発明されたものではなく、単に古き良き ADA 言語から借用されたものであることは注目に値します。 この言語は、すべての CPU を使用して数百万の並列接続を処理できますが、マルチスレッド コードによく見られるデッドロックや競合状態に関する問題は XNUMX 桁ほど複雑ではありません。

追加のメリット

儲かれば誰もが無私になる。

言語はまた、私たちに疑いのない多くの利点をもたらします。

• プロジェクトを構築した後の単一の実行可能ファイルにより、アプリケーションの展開が大幅に簡素化されます。
• 静的型付けと型推論を使用すると、テストを作成しなくても、コード内のエラーの数を大幅に減らすことができます。 私の知っているプログラマーの中には、テストをまったく書かずにテストを行っているが、コードの品質はそれほど低下していません。
• 非常にシンプルなクロスコンパイルと標準ライブラリの優れた移植性により、クロスプラットフォーム アプリケーションの開発が大幅に簡素化されます。
• RE2 の正規表現はスレッドセーフであり、実行時間は予測可能です。
• サードパーティのフレームワークなしでほとんどのプロジェクトを実行できる強力な標準ライブラリ。
• この言語は、問題を解決する方法ではなく、問題に焦点を当てるのに十分強力でありながら、問題を効率的に解決できるほど十分に低レベルです。
• Go エコ システムには、テスト、ドキュメント、パッケージ管理、強力なリンター、コード生成、競合状態検出など、あらゆる場面ですぐに使える開発されたツールがすでに含まれています。
• Go バージョン 1.11 では、一般的な VCS ホスティング上に構築された組み込みのセマンティック依存関係管理が導入されました。 Go エコシステムを構成するすべてのツールは、これらのサービスを使用して、コードを一度にダウンロード、ビルド、インストールします。 それは素晴らしいことです。 バージョン 1.11 の登場により、パッケージのバージョン管理の問題も完全に解決されました。
• この言語の中心的な考え方は魔法を減らすことであるため、この言語は開発者にエラー処理を明示的に行うよう促します。 これは正しいです。そうしないと、エラー処理がまったく忘れられてしまうからです。 もう XNUMX つは、ほとんどの開発者が意図的にエラー処理を無視し、エラーを処理する代わりに単にエラーを上向きに転送することを好むことです。
• Go には純粋な形では仮想性がないため、この言語は古典的な OOP 方法論を実装していません。 ただし、インターフェイスを使用する場合、これは問題になりません。 OOP がないため、初心者にとっての参入障壁が大幅に軽減されます。

コミュニティの利益のためのシンプルさ

複雑にするのは簡単ですが、単純化するのは難しいです。

Go はシンプルになるように設計されており、その目標は達成できています。 これは、チームワークの利点を理解し、エンタープライズ レベルの言語の無限のばらつきにうんざりしている賢いプログラマー向けに書かれています。 比較的小規模な構文構造を保有しているため、時間の経過による変更の影響をほとんど受けることがないため、開発者は言語の革新を際限なく研究するのではなく、開発に多くの時間を割くことができます。

企業はまた、参入障壁が低いため専門家をすぐに見つけることができ、言語の不変性により 10 年後でも同じコードを使用できるなど、多くの利点を受けています。

まとめ

脳の大きさが原因でゾウがノーベル賞受賞者になったことは一度もありません。

チームスピリットよりも個人的なエゴを優先するプログラマーや、学術的な挑戦と終わりのない「自己改善」を愛する理論家にとって、この言語は非常に悪いものです。自分の仕事の結果から美的喜びを感じ、同僚の前で自分がプロフェッショナルであることを示します（ただし、IQではなくこれらの基準で知性を測定する場合）。 人生のあらゆることと同様、それは個人の優先事項の問題です。 すべての価値あるイノベーションと同様、この言語もすでに普遍的な否定から大衆に受け入れられるまで長い道のりを歩んできました。 この言語はそのシンプルさにおいて独創的であり、ご存知のとおり、独創的なものはすべてシンプルです。

出所： habr.com