Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

[インデックス 15976] ファイルの概要

このコミットは、Go言語の公式FAQドキュメントである doc/go_faq.html を更新するものです。このファイルは、Go言語に関するよくある質問とその回答をまとめたもので、ユーザーがGo言語の設計思想、機能、使い方について理解を深めるための重要なリソースです。

コミット

このコミットは、Go言語のFAQドキュメントに新しい情報、特にGo 1.1リリースに関連する詳細と、関連するブログ記事やプロジェクトへのリンクを追加することを目的としています。これにより、FAQの正確性と網羅性を向上させ、読者に追加情報源へのアクセスを提供します。

GitHub上でのコミットページへのリンク

https://github.com/golang/go/commit/48ecfc979ffb209c2705f594c4edc6c8c8829486

元コミット内容

faq: update with some links and 1.1-specific details

R=golang-dev, remyoudompheng, iant
CC=golang-dev
https://golang.org/cl/8038048

変更の背景

このコミットが行われた2013年3月は、Go 1.1のリリースが間近に迫っていた時期です。Go 1.1は、Go言語にとって重要なマイルストーンとなるリリースであり、パフォーマンスの向上、ツールの改善、標準ライブラリの拡張など、多くの変更が含まれていました。

このコミットの背景には、以下の点が挙げられます。

  1. Go 1.1への対応: Go 1.1で導入される、または明確化される新しい情報や推奨事項をFAQに反映させる必要がありました。特に、intのサイズに関する記述の変更や、GOMAXPROCSに関する説明の更新は、Go 1.1でのランタイムの改善や並行処理モデルの進化と関連しています。
  2. 情報源の充実: Go言語のコミュニティが成長し、関連するブログ記事やプロジェクトが増えてきたため、FAQからそれらの有用な情報源へリンクを張ることで、ユーザーがより深くGoを理解できるようにすることが目的でした。例えば、「Go at Google」の記事やVitessプロジェクトへのリンク追加がこれに該当します。
  3. 既存情報の明確化と修正: FAQ内の既存の記述について、より正確で分かりやすい表現に修正する必要がありました。特に、参照型（スライス、マップ）に関する説明は、Go言語の設計思想における重要なポイントであり、その理解を深めるための修正が行われています。

前提知識の解説

このコミットの変更内容を理解するためには、以下のGo言語に関する前提知識が必要です。

  • Go FAQ (Frequently Asked Questions): Go言語の公式ドキュメントの一部で、Go言語の設計思想、機能、一般的な疑問に対する回答がまとめられています。
  • Go 1.1: 2013年5月にリリースされたGo言語のメジャーバージョンアップ。パフォーマンスの向上、ランタイムの改善、標準ライブラリの拡張など、多くの重要な変更が含まれていました。特に、ガベージコレクションの改善や、GOMAXPROCSのデフォルト値の変更（Go 1.5で変更されるが、この時期から議論が活発化）など、ランタイムの並行処理に関する議論が盛んでした。
  • CSP (Communicating Sequential Processes): 並行処理の理論モデルの一つで、チャネルを介したプロセス間の通信を基本とします。Go言語の並行処理モデル（ゴルーチンとチャネル）は、このCSPに強く影響を受けています。OccamやErlangもCSPから派生した言語として知られています。Goのチャネルは「ファーストクラスオブジェクト」として扱われ、言語の強力な機能となっています。
  • ゴルーチン (Goroutines): Go言語における軽量な並行実行単位。OSのスレッドよりもはるかに軽量で、数千、数万のゴルーチンを同時に実行することが可能です。
  • チャネル (Channels): ゴルーチン間でデータを安全に送受信するための通信メカニズム。CSPモデルにおける通信の主要な手段です。
  • 参照型 (Reference Types): Go言語におけるスライス、マップ、チャネルなどは、内部的にポインタのような振る舞いをします。これらは「参照型」と呼ばれ、変数をコピーしても元のデータ構造を共有します。このコミットでは、Go言語の初期段階でポインタと値の厳密な分離が使いにくかったため、参照型を導入することで生産性と快適性が向上したという歴史的経緯が説明されています。
  • intのサイズ: Go言語のint型は、プラットフォームに依存する整数型です。32ビットシステムでは32ビット、64ビットシステムでは64ビットになることが一般的ですが、Goの初期の実装では64ビットシステムでも32ビットintが使われることがありました。このコミットでは、その記述がより正確な表現に修正されています。
  • GOMAXPROCS: Goランタイムが同時に実行できるOSスレッドの最大数を制御する環境変数。Go 1.5以前はデフォルトで1でしたが、Go 1.5以降はCPUコア数に設定されるようになりました。このコミットの時点では、アプリケーションごとに設定する必要があることが強調されています。
  • 「並行性 (Concurrency) は並列性 (Parallelism) ではない」: Go言語の設計思想における重要な概念。並行性とは、複数のタスクが同時に進行しているように見えること（例：シングルコアCPUでタスクを切り替えながら実行）。並列性とは、複数のタスクが実際に同時に実行されていること（例：マルチコアCPUで複数のタスクを同時に実行）。Goは並行処理を容易にしますが、それが常に並列実行を意味するわけではないという点を強調しています。
  • Goコンパイラのブートストラップ: コンパイラ自身をそのコンパイラがコンパイルできる言語で記述すること。Goの初期コンパイラgcはC言語で書かれていましたが、将来的にはGo自身で書かれる可能性が議論されていました。gccgoはGCCをバックエンドとするGoコンパイラです。

技術的詳細

このコミットは、doc/go_faq.htmlファイルに対して以下の具体的な変更を加えています。

  1. Go言語の背景と動機に関する記事へのリンク追加:

    • <p>The article <a href="http://talks.golang.org/2012/splash.article">Go at Google</a> discusses the background and motivation behind the design of the Go language, as well as providing more detail about many of the answers presented in this FAQ.</p>
    • Go言語の設計背景と動機について詳しく解説した「Go at Google」という記事へのリンクが追加されました。これは、FAQの回答を補完する形で、より深い理解を促すための情報源となります。

  2. Go言語の利用事例の追加:

    • <p>Other examples include the <a href="https://code.google.com/p/vitess/">Vitess</a> system for large-scale SQL installations and Google's download server, <code>dl.google.com</code>, which delivers Chrome binaries and other large installables such as <code>apt-get</code> packages.</p>
    • Go言語が実際に大規模なシステムで利用されている例として、大規模SQLインストール向けのVitessシステムと、Googleのダウンロードサーバー（dl.google.com）が追加されました。これにより、Go言語の実用性と信頼性が強調されています。

  3. CSPモデルと手続き型言語フレームワークの適合性に関する記述の追加:

    • +Experience with several earlier languages has shown that the CSP model +fits well into a procedural language framework.
    • CSPモデルが手続き型言語フレームワークにうまく適合するという、これまでの言語開発の経験に基づく知見が追加されました。これは、Go言語がCSPモデルを採用した理由の一つを補強するものです。

  4. 参照型に関する説明の修正:

    • -values made the language harder to use. Introducing reference types, -including slices to handle the reference form of arrays, resolved -these issues. Reference types add some regrettable complexity to the -language but they have a large effect on usability: Go became a more -productive, comfortable language when they were introduced.
    • +values made the language harder to use. Changing these +types to act as references to the associated, shared data structures resolved +these issues. This change added some regrettable complexity to the +language but had a large effect on usability: Go became a more +productive, comfortable language when it was introduced.
    • スライスやマップなどの「参照型」の導入に関する説明が修正されました。以前は「参照型を導入した」という表現でしたが、より正確に「これらの型が関連する共有データ構造への参照として機能するように変更した」という表現に変わっています。これにより、Go言語がポインタと値の厳密な分離から、より使いやすい参照セマンティクスへと進化してきた経緯が明確化されています。

  5. メソッドのレシーバに関する説明の修正:

    • -(Slices and maps are reference types, so their story is a little
    • +(Slices and maps act as references, so their story is a little
    • スライスとマップが「参照型である」という表現から、「参照として機能する」という表現に修正されました。これは、上記4の変更と一貫しており、より正確な記述となっています。

  6. intのサイズに関する質問と回答の修正:

    • -Why is <code>int</code> 32 bits on 64 bit machines?</h3>
    • +What is the size of an <code>int</code> on a 64 bit machine?</h3>
    • 質問が「なぜintは64ビットマシンで32ビットなのか？」から「64ビットマシンでのintのサイズは何か？」に変更されました。
    • -At the moment, all implementations use 32-bit ints, an essentially arbitrary decision. -However, we expect that <code>int</code> will be increased to 64 bits on 64-bit -architectures in a future release of Go.
    • 「現在、すべての実装で32ビットintが使われているが、将来のリリースで64ビットアーキテクチャでは64ビットに増える予定」という記述が削除されました。これは、Go 1.1の時点でintのサイズがプラットフォームに依存するという一般的な説明に統一され、将来の変更に関する具体的な予測を避けるためと考えられます。

  7. GOMAXPROCSと「並行性は並列性ではない」に関する記述の追加:

    • +However, be aware that +<a href="http://blog.golang.org/2013/01/concurrency-is-not-parallelism.html">concurrency +is not parallelism</a>.
    • +For more detail on this topic see the talk entitled, +<a href="http://blog.golang.org/2013/01/concurrency-is-not-parallelism.html">Concurrency +is not Parallelism</a>.
    • GOMAXPROCSに関するセクションに、「並行性は並列性ではない」という重要な概念と、それに関する公式ブログ記事へのリンクが追加されました。これは、Goの並行処理モデルを正しく理解するための重要な指針となります。

  8. Goコンパイラの開発状況に関する記述の更新:

    • -parser are already available in the <a href="/pkg/go/"><code>go</code></a> package.)
    • +parser are already available in the <a href="/pkg/go/"><code>go</code></a> package +and a type checker is in the works.)
    • Go言語でコンパイラを実装することの可能性について言及している箇所で、「goパッケージにはすでにネイティブのレキサーとパーサーが利用可能であり、タイプチェッカーも開発中である」という情報が追加されました。これは、Go言語自身でGoコンパイラを記述するプロジェクトが進行中であることを示唆しています。

これらの変更は、Go言語の進化、特にGo 1.1のリリースに伴うランタイムの挙動、並行処理モデルの理解、そして言語の設計思想に関するFAQの情報を最新かつ正確に保つためのものです。

コアとなるコードの変更箇所

--- a/doc/go_faq.html
+++ b/doc/go_faq.html
@@ -157,6 +157,12 @@ and so on.  These cannot be addressed well by libraries or tools; a new
 language was called for.
 </p>
 
+<p>
+The article <a href="http://talks.golang.org/2012/splash.article">Go at Google</a>
+discusses the background and motivation behind the design of the Go language,
+as well as providing more detail about many of the answers presented in this FAQ.
+</p>
+
 <h3 id="ancestors">
 What are Go's ancestors?</h3>
 <p>
@@ -216,6 +222,13 @@ document server running in a production configuration on
 <a href="https://developers.google.com/appengine/">Google App Engine</a>.
 </p>
 
+<p>
+Other examples include the <a href="https://code.google.com/p/vitess/">Vitess</a>
+system for large-scale SQL installations and Google's download server, <code>dl.google.com</code>,
+which delivers Chrome binaries and other large installables such as <code>apt-get</code>
+packages.
+</p>
+
 <h3 id="Do_Go_programs_link_with_Cpp_programs">
 Do Go programs link with C/C++ programs?</h3>
 
@@ -394,6 +407,8 @@ for concurrency comes from Hoare's Communicating Sequential Processes, or CSP.
 Occam and Erlang are two well known languages that stem from CSP.
 Go's concurrency primitives derive from a different part of the family tree
 whose main contribution is the powerful notion of channels as first class objects.
+Experience with several earlier languages has shown that the CSP model
+fits well into a procedural language framework.
 </p>
 
 <h3 id="goroutines">
@@ -874,11 +889,11 @@ There's a lot of history on that topic.  Early on, maps and channels
 were syntactically pointers and it was impossible to declare or use a
 non-pointer instance.  Also, we struggled with how arrays should work.
 Eventually we decided that the strict separation of pointers and
-values made the language harder to use.  Introducing reference types,
-including slices to handle the reference form of arrays, resolved
-these issues.  Reference types add some regrettable complexity to the
-language but they have a large effect on usability: Go became a more
-productive, comfortable language when they were introduced.
+values made the language harder to use.  Changing these
+types to act as references to the associated, shared data structures resolved
+these issues. This change added some regrettable complexity to the
+language but had a large effect on usability: Go became a more
+productive, comfortable language when it was introduced.
 </p>
 
 <h2 id="Writing_Code">Writing Code</h2>
@@ -1080,7 +1095,7 @@ There are several considerations.\n First, and most important, does the method need to modify the\n receiver?\n If it does, the receiver <em>must</em> be a pointer.\n-(Slices and maps are reference types, so their story is a little\n+(Slices and maps act as references, so their story is a little\n more subtle, but for instance to change the length of a slice\n in a method the receiver must still be a pointer.)\n In the examples above, if <code>pointerMethod</code> modifies\n@@ -1131,7 +1146,7 @@ of Effective Go</a> for more details.\n </p>\n 
 <h3 id="q_int_sizes">\n-Why is <code>int</code> 32 bits on 64 bit machines?</h3>\n+What is the size of an <code>int</code> on a 64 bit machine?</h3>\n \n <p>\n The sizes of <code>int</code> and <code>uint</code> are implementation-specific\n@@ -1148,12 +1163,6 @@ floating-point numbers.\n The default size of a floating-point constant is <code>float64</code>.\n </p>\n \n-<p>\n-At the moment, all implementations use 32-bit ints, an essentially arbitrary decision.\n-However, we expect that <code>int</code> will be increased to 64 bits on 64-bit\n-architectures in a future release of Go.\n-</p>\n-\n <h3 id="stack_or_heap">\n How do I know whether a variable is allocated on the heap or the stack?</h3>\n \n@@ -1237,6 +1246,9 @@ run-time support to utilize more than one OS thread.\n <p>\n Programs that perform parallel computation should benefit from an increase in\n <code>GOMAXPROCS</code>.\n+However, be aware that\n+<a href="http://blog.golang.org/2013/01/concurrency-is-not-parallelism.html">concurrency\n+is not parallelism</a>.\n </p>\n \n <h3 id="Why_GOMAXPROCS">\n@@ -1270,6 +1282,11 @@ should recognize such cases and optimize its use of OS threads. For now,\n <code>GOMAXPROCS</code> should be set on a per-application basis.\n </p>\n \n+<p>\n+For more detail on this topic see the talk entitled,\n+<a href="http://blog.golang.org/2013/01/concurrency-is-not-parallelism.html">Concurrency\n+is not Parallelism</a>.\n+\n <h2 id="Functions_methods">Functions and Methods</h2>\n \n <h3 id="different_method_sets">\n@@ -1503,9 +1520,11 @@ We considered writing <code>gc</code>, the original Go compiler, in Go itself bu\n elected not to do so because of the difficulties of bootstrapping and\n especially of open source distribution&mdash;you'd need a Go compiler to\n set up a Go environment. <code>Gccgo</code>, which came later, makes it possible to\n-consider writing a compiler in Go, which might well happen. (Go would be a\n+consider writing a compiler in Go, which might well happen.\n+(Go would be a\n fine language in which to implement a compiler; a native lexer and\n-parser are already available in the <a href="/pkg/go/"><code>go</code></a> package.)\n+parser are already available in the <a href="/pkg/go/"><code>go</code></a> package\n+and a type checker is in the works.)\n </p>\n \n <p>\n```

## コアとなるコードの解説

上記の差分は、`doc/go_faq.html` ファイルに対する具体的な変更を示しています。

*   **Go言語の背景と利用事例の追加**:
    *   `+<p>The article <a href="http://talks.golang.org/2012/splash.article">Go at Google</a> ...</p>`
    *   `+<p>Other examples include the <a href="https://code.google.com/p/vitess/">Vitess</a> ...</p>`
    *   Go言語の設計思想を説明するセクションに、GoogleでのGoの利用に関する記事へのリンクが追加されました。また、Goが実際に大規模なシステム（Vitess、Googleのダウンロードサーバー）で使われている具体例が追加され、Goの実用性が強調されています。

*   **CSPモデルと手続き型言語の適合性**:
    *   `+Experience with several earlier languages has shown that the CSP model +fits well into a procedural language framework.`
    *   Goの並行処理の基盤であるCSPモデルが、手続き型言語のフレームワークにうまく適合するという経験則が追記されました。これは、GoがなぜCSPモデルを採用したのかという疑問に対する補足説明となります。

*   **参照型に関する表現の修正**:
    *   `-values made the language harder to use.  Introducing reference types, ...`
    *   `+values made the language harder to use.  Changing these +types to act as references to the associated, shared data structures resolved ...`
    *   Go言語の初期段階でポインタと値の厳密な分離が使いにくかったという歴史的経緯を説明する箇所で、「参照型を導入した」という表現から、「これらの型が関連する共有データ構造への参照として機能するように変更した」という、より正確な表現に修正されました。これにより、Go言語がどのようにして使いやすさを向上させたかが明確になります。
    *   `- (Slices and maps are reference types, so their story is a little`
    *   `+ (Slices and maps act as references, so their story is a little`
    *   同様に、スライスとマップが「参照型である」という表現から、「参照として機能する」という表現に修正され、一貫性が保たれています。

*   **`int`のサイズに関する質問と回答の変更**:
    *   `-Why is <code>int</code> 32 bits on 64 bit machines?</h3>`
    *   `+What is the size of an <code>int</code> on a 64 bit machine?</h3>`
    *   質問が「なぜ32ビットなのか」という具体的な問いから、「サイズは何か」という一般的な問いに変更されました。
    *   `-At the moment, all implementations use 32-bit ints, ...`
    *   将来の`int`のサイズに関する具体的な予測の記述が削除されました。これは、`int`のサイズが実装依存であるという一般的な原則に立ち返り、将来の変更に関する不確実な情報を避けるためです。

*   **`GOMAXPROCS`と「並行性は並列性ではない」の追加**:
    *   `+However, be aware that +<a href="http://blog.golang.org/2013/01/concurrency-is-not-parallelism.html">concurrency +is not parallelism</a>.`
    *   `+For more detail on this topic see the talk entitled, +<a href="http://blog.golang.org/2013/01/concurrency-is-not-parallelism.html">Concurrency +is not Parallelism</a>.`
    *   `GOMAXPROCS`に関する説明に、「並行性は並列性ではない」というGo言語の重要な概念と、それに関する公式ブログ記事へのリンクが追加されました。これは、Goの並行処理モデルを誤解なく理解するための重要な補足です。

*   **Goコンパイラの開発状況の更新**:
    *   `+and a type checker is in the works.)`
    *   Go言語でGoコンパイラを記述する可能性について言及している箇所に、「タイプチェッカーも開発中である」という情報が追加されました。これは、Go言語自身でGoコンパイラをブートストラップするプロジェクトが着実に進んでいることを示しています。

これらの変更は、Go言語のFAQをより正確で、最新の情報に更新し、読者がGo言語の設計思想や利用方法について深く理解できるようにするためのものです。

## 関連リンク

*   Go at Google (記事): [http://talks.golang.org/2012/splash.article](http://talks.golang.org/2012/splash.article)
*   Vitess (GitHub): [https://code.google.com/p/vitess/](https://code.google.com/p/vitess/) (現在はGitHubに移行: [https://github.com/vitessio/vitess](https://github.com/vitessio/vitess))
*   Concurrency is not Parallelism (Goブログ記事): [http://blog.golang.org/2013/01/concurrency-is-not-parallelism.html](http://blog.golang.org/2013/01/concurrency-is-not-parallelism.html)
*   Go言語の`go`パッケージドキュメント: [https://golang.org/pkg/go/](https://golang.org/pkg/go/)

## 参考にした情報源リンク

*   Go 1.1 Release Notes: [https://golang.org/doc/go1.1](https://golang.org/doc/go1.1) (このコミットの時点ではリリース前ですが、関連する情報源として)
*   Go FAQ (現在のバージョン): [https://golang.org/doc/faq](https://golang.org/doc/faq)
*   Go言語の並行処理に関する一般的な情報 (例: Go Concurrency Patterns): [https://golang.org/doc/effective_go.html#concurrency](https://golang.org/doc/effective_go.html#concurrency)
*   Go言語の歴史と設計に関する情報 (例: A Tour of Go, Effective Goなど)
*   CSP (Communicating Sequential Processes) に関する一般的な情報 (例: Wikipediaなど)
*   Go言語における`int`のサイズに関する議論 (Goコミュニティのフォーラムやメーリングリストのアーカイブなど)
*   `GOMAXPROCS`に関するGoブログ記事やドキュメント# [インデックス 15976] ファイルの概要

このコミットは、Go言語の公式FAQドキュメントである `doc/go_faq.html` を更新するものです。このファイルは、Go言語に関するよくある質問とその回答をまとめたもので、ユーザーがGo言語の設計思想、機能、使い方について理解を深めるための重要なリソースです。

## コミット

このコミットは、Go言語のFAQドキュメントに新しい情報、特にGo 1.1リリースに関連する詳細と、関連するブログ記事やプロジェクトへのリンクを追加することを目的としています。これにより、FAQの正確性と網羅性を向上させ、読者に追加情報源へのアクセスを提供します。

## GitHub上でのコミットページへのリンク

[https://github.com/golang/go/commit/48ecfc979ffb209c2705f594c4edc6c8c8829486](https://github.com/golang/go/commit/48ecfc979ffb209c2705f594c4edc6c8c8829486)

## 元コミット内容

faq: update with some links and 1.1-specific details

R=golang-dev, remyoudompheng, iant CC=golang-dev https://golang.org/cl/8038048


## 変更の背景

このコミットが行われた2013年3月は、Go 1.1のリリースが間近に迫っていた時期です。Go 1.1は、Go言語にとって重要なマイルストーンとなるリリースであり、パフォーマンスの向上、ツールの改善、標準ライブラリの拡張など、多くの変更が含まれていました。

このコミットの背景には、以下の点が挙げられます。

1.  **Go 1.1への対応**: Go 1.1で導入される、または明確化される新しい情報や推奨事項をFAQに反映させる必要がありました。特に、`int`のサイズに関する記述の変更や、`GOMAXPROCS`に関する説明の更新は、Go 1.1でのランタイムの改善や並行処理モデルの進化と関連しています。
2.  **情報源の充実**: Go言語のコミュニティが成長し、関連するブログ記事やプロジェクトが増えてきたため、FAQからそれらの有用な情報源へリンクを張ることで、ユーザーがより深くGoを理解できるようにすることが目的でした。例えば、「Go at Google」の記事やVitessプロジェクトへのリンク追加がこれに該当します。
3.  **既存情報の明確化と修正**: FAQ内の既存の記述について、より正確で分かりやすい表現に修正する必要がありました。特に、参照型（スライス、マップ）に関する説明は、Go言語の設計思想における重要なポイントであり、その理解を深めるための修正が行われています。

## 前提知識の解説

このコミットの変更内容を理解するためには、以下のGo言語に関する前提知識が必要です。

*   **Go FAQ (Frequently Asked Questions)**: Go言語の公式ドキュメントの一部で、Go言語の設計思想、機能、一般的な疑問に対する回答がまとめられています。
*   **Go 1.1**: 2013年5月にリリースされたGo言語のメジャーバージョンアップ。パフォーマンスの向上、ランタイムの改善、標準ライブラリの拡張など、多くの重要な変更が含まれていました。特に、ガベージコレクションの改善や、`GOMAXPROCS`のデフォルト値の変更（Go 1.5で変更されるが、この時期から議論が活発化）など、ランタイムの並行処理に関する議論が盛んでした。
*   **CSP (Communicating Sequential Processes)**: 並行処理の理論モデルの一つで、チャネルを介したプロセス間の通信を基本とします。Go言語の並行処理モデル（ゴルーチンとチャネル）は、このCSPに強く影響を受けています。OccamやErlangもCSPから派生した言語として知られています。Goのチャネルは「ファーストクラスオブジェクト」として扱われ、言語の強力な機能となっています。
*   **ゴルーチン (Goroutines)**: Go言語における軽量な並行実行単位。OSのスレッドよりもはるかに軽量で、数千、数万のゴルーチンを同時に実行することが可能です。
*   **チャネル (Channels)**: ゴルーチン間でデータを安全に送受信するための通信メカニズム。CSPモデルにおける通信の主要な手段です。
*   **参照型 (Reference Types)**: Go言語におけるスライス、マップ、チャネルなどは、内部的にポインタのような振る舞いをします。これらは「参照型」と呼ばれ、変数をコピーしても元のデータ構造を共有します。このコミットでは、Go言語の初期段階でポインタと値の厳密な分離が使いにくかったため、参照型を導入することで生産性と快適性が向上したという歴史的経緯が説明されています。
*   **`int`のサイズ**: Go言語の`int`型は、プラットフォームに依存する整数型です。32ビットシステムでは32ビット、64ビットシステムでは64ビットになることが一般的ですが、Goの初期の実装では64ビットシステムでも32ビット`int`が使われることがありました。このコミットでは、その記述がより正確な表現に修正されています。
*   **`GOMAXPROCS`**: Goランタイムが同時に実行できるOSスレッドの最大数を制御する環境変数。Go 1.5以前はデフォルトで1でしたが、Go 1.5以降はCPUコア数に設定されるようになりました。このコミットの時点では、アプリケーションごとに設定する必要があることが強調されています。
*   **「並行性 (Concurrency) は並列性 (Parallelism) ではない」**: Go言語の設計思想における重要な概念。並行性とは、複数のタスクが同時に進行しているように見えること（例：シングルコアCPUでタスクを切り替えながら実行）。並列性とは、複数のタスクが実際に同時に実行されていること（例：マルチコアCPUで複数のタスクを同時に実行）。Goは並行処理を容易にしますが、それが常に並列実行を意味するわけではないという点を強調しています。
*   **Goコンパイラのブートストラップ**: コンパイラ自身をそのコンパイラがコンパイルできる言語で記述すること。Goの初期コンパイラ`gc`はC言語で書かれていましたが、将来的にはGo自身で書かれる可能性が議論されていました。`gccgo`はGCCをバックエンドとするGoコンパイラです。

## 技術的詳細

このコミットは、`doc/go_faq.html`ファイルに対して以下の具体的な変更を加えています。

1.  **Go言語の背景と動機に関する記事へのリンク追加**:
    *   `<p>The article <a href="http://talks.golang.org/2012/splash.article">Go at Google</a> discusses the background and motivation behind the design of the Go language, as well as providing more detail about many of the answers presented in this FAQ.</p>`
    *   Go言語の設計背景と動機について詳しく解説した「Go at Google」という記事へのリンクが追加されました。これは、FAQの回答を補完する形で、より深い理解を促すための情報源となります。

2.  **Go言語の利用事例の追加**:
    *   `<p>Other examples include the <a href="https://code.google.com/p/vitess/">Vitess</a> system for large-scale SQL installations and Google's download server, <code>dl.google.com</code>, which delivers Chrome binaries and other large installables such as <code>apt-get</code> packages.</p>`
    *   Go言語が実際に大規模なシステムで利用されている例として、大規模SQLインストール向けのVitessシステムと、Googleのダウンロードサーバー（dl.google.com）が追加されました。これにより、Go言語の実用性と信頼性が強調されています。

3.  **CSPモデルと手続き型言語フレームワークの適合性に関する記述の追加**:
    *   `+Experience with several earlier languages has shown that the CSP model +fits well into a procedural language framework.`
    *   CSPモデルが手続き型言語フレームワークにうまく適合するという、これまでの言語開発の経験に基づく知見が追加されました。これは、Go言語がCSPモデルを採用した理由の一つを補強するものです。

4.  **参照型に関する説明の修正**:
    *   `-values made the language harder to use.  Introducing reference types, -including slices to handle the reference form of arrays, resolved -these issues.  Reference types add some regrettable complexity to the -language but they have a large effect on usability: Go became a more -productive, comfortable language when they were introduced.`
    *   `+values made the language harder to use.  Changing these +types to act as references to the associated, shared data structures resolved +these issues. This change added some regrettable complexity to the +language but had a large effect on usability: Go became a more +productive, comfortable language when it was introduced.`
    *   スライスやマップなどの「参照型」の導入に関する説明が修正されました。以前は「参照型を導入した」という表現でしたが、より正確に「これらの型が関連する共有データ構造への参照として機能するように変更した」という表現に変わっています。これにより、Go言語がポインタと値の厳密な分離から、より使いやすい参照セマンティクスへと進化してきた経緯が明確化されています。

5.  **メソッドのレシーバに関する説明の修正**:
    *   `-(Slices and maps are reference types, so their story is a little`
    *   `+(Slices and maps act as references, so their story is a little`
    *   スライスとマップが「参照型である」という表現から、「参照として機能する」という表現に修正されました。これは、上記4の変更と一貫しており、より正確な記述となっています。

6.  **`int`のサイズに関する質問と回答の修正**:
    *   `-Why is <code>int</code> 32 bits on 64 bit machines?</h3>`
    *   `+What is the size of an <code>int</code> on a 64 bit machine?</h3>`
    *   質問が「なぜ`int`は64ビットマシンで32ビットなのか？」から「64ビットマシンでの`int`のサイズは何か？」に変更されました。
    *   `-At the moment, all implementations use 32-bit ints, an essentially arbitrary decision. -However, we expect that <code>int</code> will be increased to 64 bits on 64-bit -architectures in a future release of Go.`
    *   「現在、すべての実装で32ビット`int`が使われているが、将来のリリースで64ビットアーキテクチャでは64ビットに増える予定」という記述が削除されました。これは、Go 1.1の時点で`int`のサイズがプラットフォームに依存するという一般的な説明に統一され、将来の変更に関する具体的な予測を避けるためと考えられます。

7.  **`GOMAXPROCS`と「並行性は並列性ではない」に関する記述の追加**:
    *   `+However, be aware that +<a href="http://blog.golang.org/2013/01/concurrency-is-not-parallelism.html">concurrency +is not parallelism</a>.`
    *   `+For more detail on this topic see the talk entitled, +<a href="http://blog.golang.org/2013/01/concurrency-is-not-parallelism.html">Concurrency +is not Parallelism</a>.`
    *   `GOMAXPROCS`に関するセクションに、「並行性は並列性ではない」という重要な概念と、それに関する公式ブログ記事へのリンクが追加されました。これは、Goの並行処理モデルを正しく理解するための重要な指針となります。

8.  **Goコンパイラの開発状況に関する記述の更新**:
    *   `-parser are already available in the <a href="/pkg/go/"><code>go</code></a> package.)`
    *   `+parser are already available in the <a href="/pkg/go/"><code>go</code></a> package +and a type checker is in the works.)`
    *   Go言語でコンパイラを実装することの可能性について言及している箇所で、「`go`パッケージにはすでにネイティブのレキサーとパーサーが利用可能であり、タイプチェッカーも開発中である」という情報が追加されました。これは、Go言語自身でGoコンパイラを記述するプロジェクトが進行中であることを示唆しています。

これらの変更は、Go言語の進化、特にGo 1.1のリリースに伴うランタイムの挙動、並行処理モデルの理解、そして言語の設計思想に関するFAQの情報を最新かつ正確に保つためのものです。

## コアとなるコードの変更箇所

```diff
--- a/doc/go_faq.html
+++ b/doc/go_faq.html
@@ -157,6 +157,12 @@ and so on.  These cannot be addressed well by libraries or tools; a new
 language was called for.
 </p>
 
+<p>
+The article <a href="http://talks.golang.org/2012/splash.article">Go at Google</a>
+discusses the background and motivation behind the design of the Go language,
+as well as providing more detail about many of the answers presented in this FAQ.
+</p>
+
 <h3 id="ancestors">
 What are Go's ancestors?</h3>
 <p>
@@ -216,6 +222,13 @@ document server running in a production configuration on
 <a href="https://developers.google.com/appengine/">Google App Engine</a>.
 </p>
 
+<p>
+Other examples include the <a href="https://code.google.com/p/vitess/">Vitess</a>
+system for large-scale SQL installations and Google's download server, <code>dl.google.com</code>,
+which delivers Chrome binaries and other large installables such as <code>apt-get</code>
+packages.
+</p>
+
 <h3 id="Do_Go_programs_link_with_Cpp_programs">
 Do Go programs link with C/C++ programs?</h3>
 
@@ -394,6 +407,8 @@ for concurrency comes from Hoare's Communicating Sequential Processes, or CSP.
 Occam and Erlang are two well known languages that stem from CSP.
 Go's concurrency primitives derive from a different part of the family tree
 whose main contribution is the powerful notion of channels as first class objects.
+Experience with several earlier languages has shown that the CSP model
+fits well into a procedural language framework.
 </p>
 
 <h3 id="goroutines">
@@ -874,11 +889,11 @@ There's a lot of history on that topic.  Early on, maps and channels
 were syntactically pointers and it was impossible to declare or use a
 non-pointer instance.  Also, we struggled with how arrays should work.
 Eventually we decided that the strict separation of pointers and
-values made the language harder to use.  Introducing reference types,
-including slices to handle the reference form of arrays, resolved
-these issues.  Reference types add some regrettable complexity to the
-language but they have a large effect on usability: Go became a more
-productive, comfortable language when they were introduced.
+values made the language harder to use.  Changing these
+types to act as references to the associated, shared data structures resolved
+these issues. This change added some regrettable complexity to the
+language but had a large effect on usability: Go became a more
+productive, comfortable language when it was introduced.
 </p>
 
 <h2 id="Writing_Code">Writing Code</h2>
@@ -1080,7 +1095,7 @@ There are several considerations.\n First, and most important, does the method need to modify the\n receiver?\n If it does, the receiver <em>must</em> be a pointer.\n-(Slices and maps are reference types, so their story is a little\n+(Slices and maps act as references, so their story is a little\n more subtle, but for instance to change the length of a slice\n in a method the receiver must still be a pointer.)\n In the examples above, if <code>pointerMethod</code> modifies\n@@ -1131,7 +1146,7 @@ of Effective Go</a> for more details.\n </p>\n 
 <h3 id="q_int_sizes">\n-Why is <code>int</code> 32 bits on 64 bit machines?</h3>\n+What is the size of an <code>int</code> on a 64 bit machine?</h3>\n \n <p>\n The sizes of <code>int</code> and <code>uint</code> are implementation-specific\n@@ -1148,12 +1163,6 @@ floating-point numbers.\n The default size of a floating-point constant is <code>float64</code>.\n </p>\n \n-<p>\n-At the moment, all implementations use 32-bit ints, an essentially arbitrary decision.\n-However, we expect that <code>int</code> will be increased to 64 bits on 64-bit\n-architectures in a future release of Go.\n-</p>\n-\n <h3 id="stack_or_heap">\n How do I know whether a variable is allocated on the heap or the stack?</h3>\n \n@@ -1237,6 +1246,9 @@ run-time support to utilize more than one OS thread.\n <p>\n Programs that perform parallel computation should benefit from an increase in\n <code>GOMAXPROCS</code>.\n+However, be aware that\n+<a href="http://blog.golang.org/2013/01/concurrency-is-not-parallelism.html">concurrency\n+is not parallelism</a>.\n </p>\n 
 <h3 id="Why_GOMAXPROCS">\n@@ -1270,6 +1282,11 @@ should recognize such cases and optimize its use of OS threads. For now,\n <code>GOMAXPROCS</code> should be set on a per-application basis.\n </p>\n \n+<p>\n+For more detail on this topic see the talk entitled,\n+<a href="http://blog.golang.org/2013/01/concurrency-is-not-parallelism.html">Concurrency\n+is not Parallelism</a>.\n+\n <h2 id="Functions_methods">Functions and Methods</h2>\n \n <h3 id="different_method_sets">\n@@ -1503,9 +1520,11 @@ We considered writing <code>gc</code>, the original Go compiler, in Go itself bu\n elected not to do so because of the difficulties of bootstrapping and\n especially of open source distribution&mdash;you'd need a Go compiler to\n set up a Go environment. <code>Gccgo</code>, which came later, makes it possible to\n-consider writing a compiler in Go, which might well happen. (Go would be a\n+consider writing a compiler in Go, which might well happen.\n+(Go would be a\n fine language in which to implement a compiler; a native lexer and\n-parser are already available in the <a href="/pkg/go/"><code>go</code></a> package.)\n+parser are already available in the <a href="/pkg/go/"><code>go</code></a> package\n+and a type checker is in the works.)\n </p>\n \n <p>\n```

## コアとなるコードの解説

上記の差分は、`doc/go_faq.html` ファイルに対する具体的な変更を示しています。

*   **Go言語の背景と利用事例の追加**:
    *   `+<p>The article <a href="http://talks.golang.org/2012/splash.article">Go at Google</a> ...</p>`
    *   `+<p>Other examples include the <a href="https://code.google.com/p/vitess/">Vitess</a> ...</p>`
    *   Go言語の設計思想を説明するセクションに、GoogleでのGoの利用に関する記事へのリンクが追加されました。また、Goが実際に大規模なシステム（Vitess、Googleのダウンロードサーバー）で使われている具体例が追加され、Goの実用性が強調されています。

*   **CSPモデルと手続き型言語の適合性**:
    *   `+Experience with several earlier languages has shown that the CSP model +fits well into a procedural language framework.`
    *   Goの並行処理の基盤であるCSPモデルが、手続き型言語のフレームワークにうまく適合するという経験則が追記されました。これは、GoがなぜCSPモデルを採用したのかという疑問に対する補足説明となります。

*   **参照型に関する表現の修正**:
    *   `-values made the language harder to use.  Introducing reference types, ...`
    *   `+values made the language harder to use.  Changing these +types to act as references to the associated, shared data structures resolved ...`
    *   Go言語の初期段階でポインタと値の厳密な分離が使いにくかったという歴史的経緯を説明する箇所で、「参照型を導入した」という表現から、「これらの型が関連する共有データ構造への参照として機能するように変更した」という、より正確な表現に修正されました。これにより、Go言語がどのようにして使いやすさを向上させたかが明確になります。
    *   `- (Slices and maps are reference types, so their story is a little`
    *   `+ (Slices and maps act as references, so their story is a little`
    *   同様に、スライスとマップが「参照型である」という表現から、「参照として機能する」という表現に修正され、一貫性が保たれています。

*   **`int`のサイズに関する質問と回答の変更**:
    *   `-Why is <code>int</code> 32 bits on 64 bit machines?</h3>`
    *   `+What is the size of an <code>int</code> on a 64 bit machine?</h3>`
    *   質問が「なぜ32ビットなのか」という具体的な問いから、「サイズは何か」という一般的な問いに変更されました。
    *   `-At the moment, all implementations use 32-bit ints, ...`
    *   将来の`int`のサイズに関する具体的な予測の記述が削除されました。これは、`int`のサイズが実装依存であるという一般的な原則に立ち返り、将来の変更に関する不確実な情報を避けるためです。

*   **`GOMAXPROCS`と「並行性は並列性ではない」の追加**:
    *   `+However, be aware that +<a href="http://blog.golang.org/2013/01/concurrency-is-not-parallelism.html">concurrency +is not parallelism</a>.`
    *   `+For more detail on this topic see the talk entitled, +<a href="http://blog.golang.org/2013/01/concurrency-is-not-parallelism.html">Concurrency +is not Parallelism</a>.`
    *   `GOMAXPROCS`に関する説明に、「並行性は並列性ではない」というGo言語の重要な概念と、それに関する公式ブログ記事へのリンクが追加されました。これは、Goの並行処理モデルを誤解なく理解するための重要な補足です。

*   **Goコンパイラの開発状況の更新**:
    *   `+and a type checker is in the works.)`
    *   Go言語でGoコンパイラを記述する可能性について言及している箇所に、「タイプチェッカーも開発中である」という情報が追加されました。これは、Go言語自身でGoコンパイラをブートストラップするプロジェクトが着実に進んでいることを示しています。

これらの変更は、Go言語のFAQをより正確で、最新の情報に更新し、読者がGo言語の設計思想や利用方法について深く理解できるようにするためのものです。

## 関連リンク

*   Go at Google (記事): [http://talks.golang.org/2012/splash.article](http://talks.golang.org/2012/splash.article)
*   Vitess (旧Google Code): [https://code.google.com/p/vitess/](https://code.google.com/p/vitess/) (現在はGitHubに移行: [https://github.com/vitessio/vitess](https://github.com/vitessio/vitess))
*   Concurrency is not Parallelism (Goブログ記事): [http://blog.golang.org/2013/01/concurrency-is-not-parallelism.html](http://blog.golang.org/2013/01/concurrency-is-not-parallelism.html)
*   Go言語の`go`パッケージドキュメント: [https://golang.org/pkg/go/](https://golang.org/pkg/go/)

## 参考にした情報源リンク

*   Go 1.1 Release Notes: [https://golang.org/doc/go1.1](https://golang.org/doc/go1.1)
*   Go FAQ (現在のバージョン): [https://golang.org/doc/faq](https://golang.org/doc/faq)
*   Go Concurrency Patterns (Effective Goより): [https://golang.org/doc/effective_go.html#concurrency](https://golang.org/doc/effective_go.html#concurrency)
*   Communicating Sequential Processes (Wikipedia): [https://en.wikipedia.org/wiki/Communicating_sequential_processes](https://en.wikipedia.org/wiki/Communicating_sequential_processes)
*   Go言語における`int`のサイズに関する議論 (Goコミュニティのフォーラムやメーリングリストのアーカイブなど、一般的なGo言語の知識)
*   Goコンパイラのブートストラップに関する情報 (GoブログやGoの設計ドキュメントなど、一般的なGo言語の知識)