hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
Rust (プログラミング言語) 設計と特徴
Rust言語が備える型システムは、impl（実装）、trait（トレイト）、struct（構造体）およびenum（列挙型）を基本として構成される。implが他の言語におけるクラスに近い役割を果たし、継承とポリモーフィズムはtraitによって提供される。traitにはメソッドを定義することができ、traitで宣言されたメソッドはimplによってstructへミックスインされる。structにはフィールドが定義可能で、traitとimplはそれ自身にはフィールドは定義できない。enumには複数種類の型のカテゴリ変数が定義可能で、数値型、文字列型、オブジェクト型などの複数の状態を選択的に持ちうる。菱形継承問題を回避するためにtraitのみが継承が可能である。
Rust (プログラミング言語) 設計と特徴
変数の型を決定する型システムは静的型付けかつ強い型付けである。静的型付けと動的型付けの区分においての型付けは、コンパイル時に全ての変数に対して型を決定する静的型付けを基本としているが、トレイトをポインタを介して利用することで、ダックタイピングに似た型付けが可能なトレイトオブジェクトが存在する。ほかに、Anyトレイトにて、実行時リフレクションを用いた動的型付けも可能である。強い型付けと弱い型付けの区分においての型付けは、実行時に変数の型を型変換（アップキャスト、ダウンキャスト、クロスキャスト）およびボクシングをすることを許さない強い型付けのみをサポートしている。C言語、Javaは実行時に型変換をすることを許す弱い型付けをサポートしているが、Rust言語では変換先の型が明示されていない状況での型変換は認められていない。なお、型が確定している変数への代入や、シグネチャによりやはり型が確定している関数への引数渡しおよび返値の受け取り等に際しては、型強制のための関数が定義されていればそれを暗黙のうちに呼び出すことができる。
Rust (プログラミング言語) 設計と特徴
Rustコンパイラは変数への代入時（変数 = 値）、変数の型を値の型に基づき型推論する。変数の宣言には必ずしも型を決定するための初期値を必要としない。変数の宣言時に初期値が与えられた場合は「変数の型」は「初期値の型」であると型推論がなされるが、初期値が与えられなかった場合は以降のブロックコード中のその変数へ値が初めて代入された時に「左辺の変数の型」は「右辺の代入する値の型」であると型推論がなされる。変数への代入が型不一致により失敗した場合にはコンパイル時にエラーを検出する。
Rust (プログラミング言語) 設計と特徴
ポリモーフィズムを実現するため、構造体のフィールドおよび関数の入出力値は特定のトレイトの実装をするジェネリック型を指定することが出来る。そのような定義の中では、ジェネリック型で型が宣言された変数および入出力値はそのトレイトの特性のみ使用できる。これはジェネリック関数が定義されるとすぐに型判定ができることを意味している。これはC++のダック・タイピングで具体的な型がインスタンス化されるまで判定できないテンプレートとは対照的である。しかし、Rustのジェネリクスの実装はC++のテンプレートの典型的な実装と似ており、インスタンス化ごとにコードの個別のコピーが生成される。これは単相化と呼ばれ、JavaやHaskellで通常使用される型消去方式とは対照的である。単相化の利点は特定のユースケースごとに最適化されたコードであり、欠点は結果のバイナリのコンパイル時間およびサイズが増加することである。Rustのトレイトを用いたポリモーフィズムの実現は、実行時のオーバーヘッドがない「ゼロコスト抽象化」と表現されている。
Rust (プログラミング言語) 設計と特徴
システムプログラミング言語には効率良いリソース管理機能が必須である（例: メモリ・ファイル管理）。C言語はプログラマがリソースを直接管理し高い効率を得られる反面、メモリリークのようなバグ混入の危険性を孕んでいる。より高級な言語（例: Java）ではガベージコレクションのような動的リソース管理機構により高い安全性を得られる反面、動的管理のオーバーヘッドが必ず付きまとう。
Rustは所有権を軸としRAII・参照・借用チェッカーなどを言語仕様として組み入れることで、リソース管理検証をコンパイル時・静的におこなう。ゆえに動的管理のオーバーヘッドを避けつつ、安全性が担保されたリソースアクセスが可能になっている（c.f. ゼロコスト抽象化）。
以下はRustのリソース管理を支える個別の概念である。
所有権（英: Ownership）はリソース管理の中心を成す重要な概念である。一つのリソースは一つの所有者（変数やブロック）のみに関連付けされるという制約がRust特有のリソース管理機能として存在する。これは、あるリソースの所有権はある所有者（owner）が持っている、のように表現される。同時に、リソースの所有権を複数の変数が持つことは出来ない。
これはC++のスマートポインタの一種であるunique_ptrの振る舞いに似ている。
Rust (プログラミング言語) 設計と特徴
参照（英: Reference）は「他者所有値の一時的な借り受け」を表現する値である。すなわち参照とは、値の所有権を元の所有者に置いたまま作成される、値へのアクセス扉である。参照を介して参照先の値を読み書きできる一方、参照を解放しても（所有権がないので）参照先の値は存在し続ける。参照は常に有効な参照先を指すと保証されている。参照を得ることを借用（英: borrow）という。
参照はいくつかの問題を解決するためにRustへ導入された。まず値へのアクセスを所有者のみに限定した場合、所有者変数がブロック/関数の内外を引き回されて冗長になる。値の所有権を有さずにアクセスを可能にする、扉・プロキシ・エイリアスのようなオブジェクトがあればこれは解決する。しかし単にアクセスオブジェクトを渡すとその有効範囲が不明なためダングリング参照を起こしうる。これは参照と参照先の生存期間等を比較することで静的に検出できる（借用チェッカー）。これにより参照は常に有効になり、ヌル参照チェックも不要になる。このような背景で導入されたのがRustの参照である。
参照に関する型・演算子・式が存在する。借用を表す式を借用式 &expr（英: borrow expression）という。型・演算子は以下である。
すなわち、演算子 & を用いた式 &expr の評価により型 &T の値が得られる。&mut でも同様である。
Rust (プログラミング言語) 設計と特徴
共有参照型は参照先の読み取りのみが可能で書き換えができないが、値が不変であるため同じ値を指す複数の共有参照が生成できる。参照はCopy トレイトによりムーブでなくコピーで渡される。可変参照型は両方が可能であるが、値が可変であるため同じ値を指す他の参照が生成できない。ゆえに参照は Copy トレイトを持たずコピーでなくムーブで渡される。
既に解放されたリソースを指し続ける参照はバグを引き起こす（例: ダングリングポインタ）。もし静的にこれを検証できれば、オーバーヘッド無しに安全性を担保できる。また検証により不正な参照を避けられるため参照へのヌル代入が不要となり、ヌルポインタチェックを不要にできる。
Rustでは借用チェッカー（英: borrow checker、ボローチェッカー）により所有権の競合および不正利用を静的に検証する。所有権が解放されたリソースを指す参照は無効であり、使用した場合はコンパイルエラーとなる。ボローチェッカーは参照についてもライフタイム（lifetimes）としてリソースの生存期間を検証する。これによりヌルポインタやダングリングポインタ、リソース利用競合を制限したメモリ安全性を実現している。
リソースのメモリ確保は基本的にはスタックメモリを利用しており、ヒープメモリを利用したメモリ確保はBoxやVecなどの特定の型のみで限定的に利用されている。
Rust (プログラミング言語) 設計と特徴
コンパイル時に型のサイズが決定できない可変長配列を表すような型はヒープメモリを利用するBox型を使用してリソースを管理する。Boxリソース自体はスタックメモリで管理されるが、Boxリソースが所有権を持つ実体のリソースはヒープメモリで管理される。標準のヒープメモリ確保にはシステムアロケータを利用するが、対象プラットフォームやビルド時の指定により他のメモリ確保APIを利用することもある。ヒープメモリはスタックメモリに比べて速度性能が落ちるため、必要時にのみ限定的に利用されている。
Rustは実行時に境界チェックをおこなう。これによりバッファオーバーランをはじめとしたメモリアクセスに対する安全性を得ている。この機能はゼロコスト抽象化でなく実行時の命令であるため、安全性と引き換えにいくらかの性能オーバーヘッドが発生している。他のシステムプログラミング言語として代表的なC言語やC++は境界チェックを強制しないため、Rustの特徴の1つとなっている。
ライフタイム（英: Lifetime）はジェネリック型の一種で、リソースやそれらへの参照の生存期間を表す。
Rust (プログラミング言語) 設計と特徴
参照を関数やメソッドとの間で受け渡ししたり、構造体や列挙型など別のデータ型に保存すると、参照の生存期間が参照を定義したスコープだけでは決まらなくなる。この場合、参照や参照先リソースに対してライフタイムの付加が必要となる。ライフタイムは'lifetimeの形式で記述する。ライフタイムを参照型に付加する場合は&の直後、それ以外の型に対してはジェネリック型として付加する。この他、別のジェネリック型に対してライフタイムを付加することもできる。特に、あるライフタイムに対して別のライフタイムを境界条件として与え、どちらか片方がもう片方よりも長く生存することを要求することができる。
ボローチェッカーはライフタイムを持つ変数に対し、その変数が指す参照先やリソースの生存期間がライフタイムにより要求される生存期間を満たしているかどうかをチェックする。チェックに失敗した場合はコンパイルエラーとする。注意すべき点として、ライフタイムを与えることにより参照先やリソースの生存期間を延長することはできない。それらの生存期間はあくまでそれらを定義および使用するスコープによって決まるため、ライフタイムのチェックでエラーが出た場合は参照先の生存期間を修正する必要がある。
Rust (プログラミング言語) 設計と特徴
関数やメソッドの定義にあっては、付加すべきライフタイムに、ある特定のパターンが存在することが知られている。そのようなパターンの通りにライフタイムを指定したい場合は、ライフタイムの手動付加を省略し、コンパイラにライフタイムを自動付加させることができる。この機能はライフタイムエリゾン（英: lifetime elision）と呼ばれる。ライフタイムエリゾンのパターン以外のライフタイムが必要な場合はライフタイムエリゾンは使用できず、ライフタイムを明示的に付加しなければならない。
関数の型を定義する際、その引数や返値が参照を含む場合はしばしばライフタイムが必要となるが、そのライフタイムが指し示す生存期間が関数の型だけでは決められず、その型に含まれる関数やクロージャを実際に定義しないと生存期間も決まらないことがある。このような場合、関数の型にて用いるライフタイムを、関数型としては任意の生存期間を持って構わないと定めることができる。そのようなライフタイムは高階トレイト境界（英: higher-rank trait bound、HRTB）として定義する。HRTBを用いて定義した関数型は単一の型ではなく、ライフタイムが取り得る限りの場合の数だけある型の集まりとなり、理論上「関数の集まり」になることに由来している。
Rust (プログラミング言語) 設計と特徴
Rustの特徴として、変数をメモリ上で自由に移動することができる。 これにより、関数やメソッド呼び出しでの変数受け渡しを値により行うことができる。また、それらの操作や代入等における所有権の移動もこの特徴に依存している。
Box<T>型（Tは型、以下同様）のようなスマートポインタ、およびVec<T>型のように可変長データを指すポインタの場合、ポインタが指しているデータは通常は移動しないが、ポインタそのものは移動する。すなわち、ポインタの値を受け渡しする挙動となる。
変数の移動を防止したい場合は、一般にはPin<P>型（PはトレイトPointer<T>を持つ型、典型的にはスマートポインタ）を使用する。この型はBox<T>型や&mut T型の取得を禁止しており、これによりPin<P>型が指すデータの移動を防ぐ。なお、Pin<P>型からPin<&mut T>型を得ることは可能で、これを用いてデータの移動を防ぎつつ変更することは可能である。また、Pin<P>型そのものを値受け渡しなどにより移動することもできる。
Rustにて変数の移動を防ぐ必要がある状況としては、主に以下がある。
Rustのライブラリはクレート（crate）という呼称で提供される。多くのクレートはcrates.ioで公開されている。同サイトはバージョン毎のソースコードをアーカイブとして提供している。クレートは必ずしもcrates.ioに登録されている必要はなく、Webサーバやファイルシステムを指すURIで指定することもできる。ライブラリはソースコードプロジェクトで配布されることが一般的だが、コンパイルしたバイナリライブラリファイルで出力することも可能である。スタティックライブラリ（拡張子rlib）およびダイナミックライブラリ（拡張子はプラットフォームに依存）をサポートしている。いずれの形式にあっても、コンパイルされたオブジェクトコードが含まれる。スタティックライブラリではこれに加えてコンパイラのバックエンドがサポートする中間表現での出力を含めることも可能であり、Link-Time Optimizationにてこれを利用することができる。
コアライブラリはcoreの名称で提供されている。このライブラリは標準ライブラリに依存しない基幹ライブラリであり、一切の上位ライブラリ、システムライブラリ、libcライブラリにリンクしていない。コアライブラリは最小限であり、ヒープ割り当てを認識せず並行性や入出力も提供していない。それらのことはプラットフォームへの調整が必要であり、このライブラリはプラットフォームに依存しない。
標準ライブラリはstdの名称で提供されている。このライブラリは基礎的な型（Vec<T>やOption<T>）、言語の基本の処理、標準のマクロ、入出力（I/O）、マルチスレッドなどの機能を提供する。標準ライブラリは標準でリンクしてソフトウェアがビルドされるが、より根幹的なソフトウェアやリソースの小さい組み込み環境ではリンクを外してソフトウェアをビルドすることができる。
Rustは基本的で汎用的な機能を含め標準ライブラリではなく外部ライブラリとして提供している。これはいわゆる「バッテリー同梱 (“Battery Included”)」の反対を行くもので、言語と共に更新することで保守的になりがちな標準ライブラリではなく、言語とは独立して更新することで最善を繰り返し探求しうる外部ライブラリとすることで、それらの機能をより良い品質で提供する考えに基づいていたものである。外部ライブラリの利便性と品質の保証のためにcrates.ioとAPIガイドラインを提供している。
言語開発のコミュニティがそれらについて携わっていないわけではなく、基礎的な外部ライブラリはコミュニティ配下で開発が進められている。
Rust (プログラミング言語) 開発ツール
Rustの開発ツールは独立したソフトウェアとして提供されているが、Rustの公式なインストール方法に従えば、以下のツール一式が手に入る。
rustcはRustで記述されたRustソースコードをコンパイルするコンパイラ（処理系）である。コンパイルの成果物として中間コード、および実行ファイル、静的ライブラリ、動的ライブラリを出力する。rustcはクロスコンパイルを可能とし、Windows、Linux、macOS向けの実行ファイル他、AndroidやiOSで動作するライブラリをホストマシンで出力することができる。
対象プラットフォームは完成度に合わせて３つのTier（ティア）に分かれている。Tier 1はバイナリリリースが提供されており、自動ビルドと自動テストが整備され、それらが安定して成功（パス）することが保証されている。
Tier 2はバイナリリリースが提供されており、自動ビルドと自動テストは整備されているがテストが成功することは保証されていない。Tier 3はソースコードとしては対応しているが、自動ビルドと自動テストの動作が保証されておらず、公式リリースは提供されていない。
Windows、Linux、macOS向けのRustコンパイラはティア1でリリースされている。Android、iOS、WebAssembly向けのRustコンパイラはティア2でリリースされている。
Rust (プログラミング言語) 開発ツール
Rust 1.12版より導入されたMIR (Mid-level IR) によって、コンパイルと実行時間の迅速化ならびに型チェックの正確性の実現が図られている。
CargoはRust製ソフトウェアプロジェクトのCUIのビルドツールである。規定のファイル構成（ディレクトリ、設定ファイル、ソースファイル）のプロジェクトディレクトリで利用される。プロジェクトのビルド（コンパイル）、依存ライブラリのダウンロード、テスト、ドキュメント生成などをサポートする。通常はCargoを中心に開発を行えるように設計されているため、rustcコンパイラを直接呼び出すことは稀である。Cargoの依存ライブラリのダウンロード先はcrates.ioである。
サブコマンドは拡張可能で標準のコマンドの他、README.mdファイルの自動生成コマンドなどの拡張コマンドが存在する。この拡張はcargo-xxxと名付けたコマンドを適切にインストールするだけで、cargoにxxxというサブコマンドを追加できる。
rustupはツールチェーンの管理ソフトウェアである。ツールチェーンのダウンロードとインストール、ソフトウェアバージョンの管理、コンパイルターゲットの切り替えの機能を提供する。
Rust (プログラミング言語) 開発ツール
rustupはRustプロジェクトがリリースしているコンパイラ（rustc）、ビルドツール（Cargo）などのツールチェーンをインターネットを経由してホストマシンにダウンロード、インストールおよびマネージメントする機能を提供する。インストール対象のツールチェーンのバージョンは、安定版、ベータ版、ナイトリー版の全てを含んでおり、利用者が必要とするバージョンを指定してダウンロードすることができる。また、ターゲットプラットフォームについても全ての種類を含んでおり、ホストマシンと異なるプラットフォーム（例えば、ホストがmacOSであってもWindowsやAndroid、iOS）のコンパイラをインストールすることができる。この場合、コンパイラはクロスコンパイラとして動作してターゲットプラットフォームに合わせたビルドを実施する。
Rust 1.13版以前はシェルスクリプトで実装されたrustup.shが公開されていた。これと並行してRust言語で実装された同等機能を提供するrustup.rsの開発が進められており、Rust 1.14版でrustup.shは非推奨となり、Rust 1.14版以降はrustup.rsが公式リリースとして提供されている。
Rust (プログラミング言語) 評価
Rustは2016～2025年に渡ってStack Overflow Developer Surveyで「最も愛されているプログラミング言語」で一位を獲得し続け、プログラマの好意的な評価は多い。
一方で、Rustは学習難易度が高い言語とも考えられている。多くのRust初学者のプログラマにおいて、自身が正しいと思って書いたソースコードのコンパイルに対してコンパイラ（ボローチェッカー）がエラーを検出する、「ボローチェッカーとの戦い」（fighting with the borrow checker）が発生しがちである。小さなアプリケーションの実装について同時期に言語開発されているGo言語と比較した場合、Rust言語よりGo言語の方が開発効率が良いという評価がある。学習難易度の高さは開発チームも認識しており、2017年ロードマップでは学習曲線の改善を目的として挙げていた。
この問題を改善するために、2020年現在において、自動化をメインテーマにした開発を続けており、前述にあるcargo、rustup等のツール以外にも、rustfmt、clippy、cargo docなどのツール類をIDE環境のみならずCUI環境でも利用可能な状態へと整備を続けている。また、後方互換性を維持しているため、crates.ioを用いる事でライブラリ類などの生産性の向上にも努めている。
Rust (プログラミング言語) 評価
Rustの実行時速度性能は同じくコンパイラにLLVMを利用している場合のC言語と同等程度であり、一部の処理ではC言語を上回った速度が確認されている。2018年2月時点で、ウェブサーバアプリケーションの汎用処理では速度性能の良いRust製ライブラリは開発が進んでいない。単純なテキスト処理では速度性能は良い。
その後のベンチマークでは、並行処理やグラフィックス処理においても、JavaやGoを上回っており、コンパイラの出力するコードの優秀性が証明されている。ただし、サポートされていないグラフィックスボード（Cのライブラリをインクルードしなければならない）では、C/C++の実効性能には及んでいない。
Rust (プログラミング言語) 歴史
2006年、Mozillaで働いていたグレイドン・ホアレは現代のインターネット環境で高い並行性と高い安全性が求められるシステムプログラミング言語としてC言語やC++に代わりうるプログラミング言語 Rust言語の開発に着手した。MozillaがRustの開発に関わりはじめたのは2009年で、Rustは2010年のモジラ・サミットで公に姿を表した。RustソースコードをコンパイルするRustコンパイラは、初期の頃はOCaml言語で作られたコンパイラ（rustboot）が用いられていたが、2010年にはRust言語自身でRustコンパイラを作るセルフホスティングへ移行したコンパイラ（rustc）の開発が始められ、翌年にはブートストラップ問題を解決した最初の完動品が完成した。この時よりRustコンパイラはコンパイル基盤にLLVMを用いたものとなった。
プレアルファ（0.1版）と呼ばれる最初のバージョンは2012年1月にリリースされた。Mozillaはこれを新しいモノ好みの人やプログラミング言語愛好家のためのアルファ版と位置づけていた。最初の安定版である1.0版がリリースされるまでの0.x版リリースでは、いくつもの大きな破壊的な仕様変更が言語およびライブラリに加えられた。
Rust (プログラミング言語) 歴史
変数名や関数名など識別子は、この言語の開発の初期の頃は、ASCII文字以外の文字を使うことが禁じられていた。言語についてのある質疑応答の中で、現場の非英語圏のプログラマーのほとんどが識別子にはASCII文字を使っていると述べられていた。しかしその制限は反論を引き出すことになった。それにより、2011年2月に言語に変更が行われ、この制限は削除された。
型判定は、0.4版以前の従来の静的型付けに加えて、型状態システムをサポートしていた。型状態システムは、特別なcheck文を使用してプログラム文の前後での型決定をモデル化した。C言語やC++コードでのアサーションの場合と同様に、プログラム実行中ではなくコンパイル時に型不一致を検出する。型状態の概念はRust特有のものではなく、NILで採用されていたものである。実際にはほとんど使用されていなかったため型状態は削除されたが、ブランディングパターンで同じ機能を実現できる。
Rust (プログラミング言語) 歴史
オブジェクト指向のシステムは、0.2版から0.4版にかけて大きく変わっていった。0.2版で初めてクラス（class）が導入され、0.3版でインターフェース（interface）を通したデストラクタとポリモーフィズムが追加され、0.4版で継承を提供する手段としてトレイト（trait）が追加された。インターフェースはトレイトに一部の機能が統合されて、異なる不要な機能として削除された。クラスもまた削除され、構造体とトレイトを使用したミックスインに置き換えられた。
コアのメモリモデルは、0.9版から0.11版の間、2つのビルトインのポインタ型（ヒープメモリ型~とガベージコレクション型@）を機能を単純化するために用意していた。それらは、標準ライブラリのBox型とGc型で置き換えられ、Gc型は最終的には削除された。
2014年1月、Dr. Dobb's Journalの編集長アンドリュー・ビンストックはD言語やGo言語、Nim言語と同様にC++の競争相手になる機会を得たとコメントした。ビンストックによると、Rustは非常にエレガントな言語として広く見られているが、バージョン間で繰り返し大きく変更されたため普及が遅れているという。
Rust (プログラミング言語) 歴史
2015年5月16日、安定版となるRust 1.0がリリースされた。1.0版の後、安定版およびベータ版が6週間おきに定期リリースされている。またナイトリー版が毎日リリースされている。新たな機能はナイトリー版で開発が進められ、ベータ版で動作が検証されている。
2016年8月2日にリリースされたFirefox 48にはRustで書き直されたメディアパーサが組み込まれており、Mozillaが開発しているブラウザのFirefoxにおいてRustで書かれたコードが書き加えられる初例となった。
2016年9月にRustはFedora 24の標準コンポーネントに加えられ、RPMのパッケージ管理システムを用いてのインストール作業が容易化されている。
2018年12月6日にバージョン1.31がリリースされた。今回からエディション制が導入され、最新版は"Rust 2018"、従来版は"Rust 2015"と呼ばれることになる。言語機能への破壊的変更は新しいエディションのみに適用されるが、互換性に影響しない機能追加は引き続き両者に適用される。また、2015年版から2018年版へはcargo fixでトランスコンパイルできる。
2021年5月11日に、3年ぶりの改訂となる2021年版について公式 Blogへ記載が行われた。当該機能は、2021年10月21日にリリースの1.56より適用される。今回の主要な改訂は、例外処理への対応が強化され、prelude文にTryIntoやTryFrom、FromIteratorなどが追加される。詳細については、公式Blogを参照されたいが、後方互換性を維持しているため、2018年版との間では特に問題なくコンパイルできる。
Rust (プログラミング言語) Rustで実装されたソフトウェア
RustコンパイラはRust自身で記述されている。
その他のRustを使って開発されているプロジェクト：
OS
Magic Pocket – Dropboxのペタバイトを管理する機器のファイルシステム
Redox – マイクロカーネルオペレーティングシステム
intermezzOS – システムプログラミングの試験的なオペレーティングシステム
Stratis – Fedora 28で予定されるファイルシステム 
Railcar – Oracleの仮想化マシン
Android - 2021年からRustを採用している。
Linux - バージョン6.1から一部の機能にRustが組み込まれると予定されている。
KataOS - RISC-Vで動作する組み込みシステム向けにGoogleが開発したOS。
Windows - 2019年からWindows 10のコンポーネントの一部をRustに置き換えている。
Rust (プログラミング言語) Rustで実装されたソフトウェア
その他
Exonum – ブロックチェーンのオープンソースフレームワーク
OpenDNS – ソリューションの内の2つのコンポーネント
Piston – ゲームエンジン
rustls – TLSのRust実装
REmacs – EmacsのRust実装 
Pijul – Darcsを参考にしたバージョン管理システム
Xi – Google Open Sourceで開発されているテキストエディタ
ripgrep – grepに相当する高速なテキスト検索ツール
rav1e – Xiph.Org FoundationによるAV1エンコーダの実装
Polkadot – 異なるブロックチェーン間で相互運用性を実現するオープンソースのプロトコル
Deno – JavaScriptとTypeScriptのランタイム環境
Ruffle - 2020年でサポート終了するAdobe Flash Playerの代替として開発中のエミュレーター。
mirakc  - 日本のテレビ(ISDB)録画システムMirakurunクローン
Nucleus - Dropboxの同期エンジン。
Git - 一部Rustライブラリが使用されている。
Rust (プログラミング言語) 学習用参考図書など
英語の読める読者ならば、rustup doc コマンドを用いる事で以下の文献をオフラインで閲覧可能。また、日本の有志によってRust By Exampleなどが翻訳されており（ただし部分訳）、公式サイトなどを参照されたい。
OYQ-5
OYQ-5 TDS（目標指示装置、英語: Target Designation System）は、海上自衛隊のC4Iシステム（戦術情報処理装置）の一つ。また本項目では、OYQ-5より発展したOYQ-6, OYQ-7, OYQ-8に関しても記述する。
OYQ-5は、海上自衛隊のワークホースたる汎用護衛艦（DD）に戦術情報処理装置を搭載したという点で、極めてエポックメイキングな機種であった。以後の戦術情報処理装置の国産化において重要な基盤となり、発展型のOYQ-6、 OYQ-7、OYQ-8も含めると計34隻に搭載された。
なお、本機を含めた海上自衛隊の電子機器の型番はアメリカ軍の軍用電子機器の命名規則におおむね基づいているが、一文字目のみは、米軍式では「S」がつけられるべきところを、「お船」（Ofune）ないし「艦載用」（On Board）を捩った「O」とされている。本機の場合は、水上船舶搭載の情報処理用機器、特殊又は複合目的ということになる。
OYQ-5 来歴
海上自衛隊では、ポスト4次防期（昭和52～54年度）において、護衛艦隊の8艦8機体制化という新編制（いわゆる「新･八八艦隊」）への移行を計画していた。この編制では、ワークホースとして、従来の多目的護衛艦（DDA）と対潜護衛艦（DDK）を統合した新艦種として、汎用護衛艦（52DD; のちのはつゆき型）の導入が必要とされた。
52DDでは、個艦防空火力としてシースパローIBPDMSの導入が計画された。これは、しらね型（50DDH）で導入されたシースパローBPDMS（短SAMシステム1型-1）の改良型であった。同型のシースパローBPDMSは、TDS-2目標指示装置による武器管制を受けていたことから、52DDのシースパローIBPDMSは、これを発展させたTDS-3目標指示装置と組み合わされる計画であった。
OYQ-5 来歴
しかし対艦ミサイル脅威の深刻化を受けて、生存性の確保のためには、たちかぜ型（46DDG）のWESと同様に脅威評価・武器管制（TEWA）機能が必要と考えられるようになった。これに応じて、TDS-3の計画を発展させて開発されたのがOYQ-5である（TDS-3の名称も、通称として生き残ることになった）。ソフトウェアはすべて国産とされており、三菱電機が海自プログラム業務隊との連携下に開発したが、開発にあたっては、アメリカ海軍を参考にした独自のドキュメント体系の策定から着手する必要があった。またDDGのWESやDDHのTDPSのソフトウェアは基本的に米UNIVAC社製品を対外有償軍事援助（FMS）により購入していたため、独自システムの開発経験がなかったことから、コードサイズの見積もりや工程管理などの面でかなり難航したが、1977年5月に運用要求が完成した。なお開発にあたっては、スペリー-UNIVAC社との技術提携が行われており、同社の技術者4名が来日して支援作業にあたった。
OYQ-5 OYQ-5
既存の訓練・教育および機材整備体系との整合性の観点から、ハードウェアはWESやTDPSと同様の米国製が採用されており、下記のような構成となった。
TDSコンソール - OJ-194/UYA-4×4基
追尾員用
対空目標追尾員（Air Detector Tracker: AD/T）
水上目標追尾員（Surface Detector Tracker: SD/T）
管制官用
戦術評定・武器管制官（Evaluator/Ship Weapon Coordinator: EVAL/SWC）
射撃指揮装置/ミサイル・ランチャー管制官（Director Assignment Controller/Weapon Assignment Controller: DAC/WAC）
OYQ-5 OYQ-5
TDSコンソールは、WESやTDPSと同じOJ-194/UYA-4が採用された。当初は3基構成の予定だったが、対潜戦機能（ソナー探知目標表示および哨戒ヘリコプター管制）能力付与のため、上記の通り4基に増備された。電子計算機として採用されたAN/UYK-20は、WESやTDPSで採用されたCP-642B/USQ-20よりも1世代新しい機種であり、OYQ-5ではメモリサイズ64キロワードの機種が採用された。ただしメモリサイズは当時としても小容量であったためにソフトウェアの開発には苦労が伴い、例えばオペレーティングシステム（OS）については、汎用のOSの核の部分のみ小さくまとめた独自のOSを開発して、メモリの有効活用を図った。プログラミング言語としてはCMS-2を使用した。
センサー情報をもとに目標の脅威評価を行ない、シースパローIBPDMSおよび76mm単装速射砲による適切な武器の指向をリコメンドする（すなわちTEWA機能を備えた）システムであり、性能的にはミサイル護衛艦向けのWESにおおむね匹敵するものとされている。ただしOPS-14やOPS-18などのレーダー・システムとの連接は実現せず、レーダー情報の入力は手動で行なう必要があったため、応答時間の短縮上限界があった。
戦術データ・リンクとしては、処理能力やコストの面から、当時北大西洋条約機構（NATO）で標準的に採用されていた双方向式のリンク 11の搭載は断念された。その後、リンク 14を通じて受信した情報を入力する機能が後日装備されたものの、これは本来はラジオテレタイプ（RTTY）を通じたテレタイプ端末での受信用であり、受信・読み取り・作図等の所要の情報処理上のタイムロスがあり、自艦（僚艦）対空レーダ探知目標の後追い情報となるため有効性に乏しく、またテレタイプ英文印刷であるため読み取り員には上級電測員を配員せざるを得ず、実用性には乏しかった。
OYQ-5 OYQ-6/7
OYQ-5は、WESやTDPSと比してコンパクトで、DDに求められる最小限の機能を保有していた。しかし電子計算機の性能上、将来発展余裕に乏しく、プログラムの柔軟性発揮が難しかった。また特にリンク 11の未装備は、艦隊の情報共有に参加できないという点で、戦力の大きな減殺となった。このことから、はつゆき型を発展させたあさぎり型（58DD）では、OYQ-5をもとに下記のように強化したOYQ-6が搭載されることになった。
名称もミサイル護衛艦向けのシステムと同じCDS（英: Combat Direction System、戦闘指揮装置）に変更されたことから、“full destroyer CDS”とも称される。電子計算機としては、あさぎり型で搭載されたOYQ-6〜6Bではメモリサイズを192キロワードに拡張したUYK-20 1基を使用した。またTDSコンソールも5基に増備された。
OYQ-5 OYQ-6/7
その後、同型の最終艦（61DD）において、86式えい航式パッシブソーナーOQR-1の運用に対応するためOYQ-101 対潜情報処理装置（ASWDS）が搭載されたことに伴い、これとの連接に対応したOYQ-7に発展した。これにより、対潜戦におけるパッシブ情報の統合・表示機能が強化されており、この情報処理所要の増大に伴い、電子計算機はデュアルプロセッサ化され、160キロワードのメモリを備えたUYK-20 2基とされている。またTDSコンソールとして、OJ-197が追加された。これはのちに、あさぎり型の他艦にもバックフィットされたほか、「ひえい」（FRAM改修後）にも搭載された。なお、アメリカ海軍協会 (USNI) ではあぶくま型（61DE）にもOYQ-7が搭載されたとみていたが、実際には、同型の戦闘指揮所は戦術情報処理装置をもたない在来型であった。
OYQ-5 OYQ-8
ミサイル艇（PG）向けに開発されたOYQ-8シリーズも、OYQ-5/6/7と同様に小型コンピュータのみが使用されている。ミサイル艇1号型（02PG）で搭載されたOYQ-8では、OYQ-5と同様にUYK-20が1基搭載された。続くはやぶさ型ミサイル艇（11PG）で搭載されたOYQ-8Bおよび改良型のOYQ-8Cでは、新世代のAN/UYK-44に更新された。
なお、特に76mm単装速射砲を備えた11PGのOYQ-8Bにおいては、センサとしてOPS-18-3対水上捜索レーダーやOPS-20航海レーダー、NOLR-9B電波探知装置（ESM）など、また武器システムとして艦対艦ミサイル艦上装置とFCS-2-31Cを備え、またリンク 11への接続能力を備えるなど、対空捜索レーダーや対潜戦用の水測装備・対潜兵器を持たない点を除けば、OYQ-6に類似した機能となっている。
グループGT1
グループGT1（Group GT1, グループジーティーワン）は、かつて存在した自動車レースに使用する競技車両のカテゴリーの1つである。元々はBPR GT選手権時代にGT2クラスとして設立されたカテゴリーだった。1999年で旧GT1が消滅した後、代わりにGT車両のトップカテゴリーとして設定された。国際自動車連盟（FIA）による正式な呼称は「Groupe GT1（仏語：グループ GT1）」であるが、日本国内ではあまり一般的な呼び方ではなく、「GT1クラス」もしく「FIA GT1」などと呼ぶことがほとんどである。
本項では、母体となった旧GT2についても記述する。
グループGT1 概要
市販スポーツカーを改造した車両がホモロゲーション（公認）の対象となる。旧GT1に比べ、改造範囲の規制が厳しいものの比較的大幅な改造が認められている。
600馬力前後のパワー、比較的強力なダウンフォース、カーボンブレーキによる制動力を持つ。1999年 - 2009年の規定ではパワーウェイトレシオだけを見るならBPR時代のGT1マシンに近い。
2010年に新規格のGT1規定を打ち出し、それまでの規格のマシンを駆除する予定だったが、新規格のマシンがフォードGT GT-1、ランボルギーニ・ムルシエラゴR-SV、ニッサンGT-R GT-1の3車種しか作られなかったため、旧規格のマシンにもアップデートキットを組ませることで対処した。現在は下記の理由により消滅したカテゴリーである。
グループGT1 歴史
1994年
1999年
2005年
2006年
2010年
2012年
グループGT1 レギュレーション
エンジン(排気量)
最低重量
駆動系、足回り
燃料タンク最大容量
グループGT1 ホモロゲーション取得車両一覧
レクサスLFAもFIA GT1に参加するためホモロゲーション取得する動きがあったが、結局折り合いが付かず、取りやめとなった
くれなゐ丸
くれなゐ丸（くれないまる、紅丸）は、かつて大阪商船および関西汽船が運航した旅客船。日本における初期のディーゼル船の一隻で、客船部門では音戸丸級貨客船に続いて二番目の船である。後に続く瀬戸内海航路就航の客船のプロトタイプとなった。
くれなゐ丸 概要
1912年（明治45年）に初代「紅丸」（1,399トン）をもって始まった大阪商船の別府航路は、関西から別府温泉に向かう入湯客という新たな観光客を生み出し、乗客は年を追うごとに増加して、瀬戸内海方面における重要航路となっていた。1921年（大正10年）12月に別府航路向けにより大型で、初めから専用船として建造された「紫丸」（1,586トン）に続いて、大阪商船工務部長の和辻春樹の設計により建造されたのが二代目の「紅丸」である。
くれなゐ丸 概要
「紅丸」は大阪鉄工所で建造され、1924年（大正13年）7月16日に進水して9月17日に竣工。これに伴い、初代「紅丸」は「鳴門丸」と改名した。大阪商船が、建造がわずかに先行した音戸丸級貨客船に続いて「紅丸」をディーゼル機関搭載船として建造した真の理由ははっきりしないが、「従来からのレシプロエンジンとの比較のため」とする新聞記事も存在する。運航成績はよく、日本における大型ディーゼル船の建造に大きな影響を与えた。もっとも、当の大阪鉄工所は「紅丸」建造をきっかけにMAN社から技師を招いてディーゼル機関の自主製作に乗り出そうとしたが資金難で取りやめになり、新造船の受注で不利になってしまった。内装は、一等船室が「桃山式」と呼ばれる和風の装飾が施され、二等と三等の船室もスペースや通風、採光の面で配慮されており、「紫丸」と比べてもグレードアップしていた。もっとも、「紫丸」と同様に一等船室のプロムナードデッキを設け、外側から入室できるようになっていたため、プロムナードデッキを歩く乗客から船室がのぞかれるという欠点も有していた。
くれなゐ丸 概要
9月23日から就航を開始し、これによって別府航路は毎日運航されるようになった。以後、1928年（昭和3年）に「紅丸」をさらに改良した「緑丸」（1,725トン）、1929年（昭和4年）に「緑丸」の同型船「菫丸」（1,725トン）が就航して毎日二便の運航に拡大した。その後、1934年（昭和9年）に「に志き丸」（1,848トン）が就航したのをきっかけに、色を船名にしていた「紫丸」から「菫丸」までの就航船も平仮名に改めることとなり、「紅丸」は「くれなゐ丸」に改められた。1939年（昭和14年）からは大阪高松線に移るが、日中戦争の長期化などにより瀬戸内海航路は縮小の方向に向かう。1941年（昭和16年）12月8日の太平洋戦争開戦を経て、1942年（昭和17年）には大阪商船や他の船主の瀬戸内海航路を統合経営する関西汽船が設立され、「くれなゐ丸」も関西汽船に移籍する。
1943年（昭和18年）1月、大阪商船は日本陸軍の命により、フィリピン方面の沿岸航路を運営する「比島運航部」を設立し、4月から業務を開始する。「くれなゐ丸」は比島運航部の管轄下で運航することとなり、音戸丸級貨客船の一隻である「三原丸」（697トン）とともに大阪商船に用船の形で復帰したあと、フィリピンに回航される。日本からの機帆船や現地で接収した汽船などとともにフィリピン沿岸航路に就航し、昭和18年10月からは「三原丸」とともにマニラとセブ間の定期航路に就航した。運航から1年近く経った1944年（昭和19年）9月9日、ペリリューの戦いの支援を行っていたアメリカ第38任務部隊（マーク・ミッチャー中将）の艦載機はフィリピン各地を空襲。「くれなゐ丸」と「三原丸」もこの網にかかり、北緯09度45分 東経125度30分﻿ / ﻿北緯9.750度 東経125.500度﻿ / 9.750; 125.500の地点で沈没した。
トルラク方言
トルラク方言（セルビア語:Торлачки дијалект / Torlački dijalekt セルビア語発音: [tɔ̌rlaːk]、ブルガリア語:Торлашки диалект / Torlashki dialekt）は、セルビア南東部（クニャジェヴァツ - ニシュ - プレシェヴォ）、コソボ（グニラネ - プリズレン）、マケドニア共和国北東部（クラトヴォ - クマノヴォ）、ブルガリア西部（ベログラトチク - ゴデチ - トルン - ブレズニク）といった地方で話される方言であり、セルビア・クロアチア語とブルガリア・マケドニア語の中間に位置する遷移方言である。
言語学者によってはこの言語（方言）を、シュト方言、カイ方言、チャ方言と並ぶセルビア・クロアチア語の4つめの主要方言群とする。一方でこの言語をブルガリア語西部方言の一部とみなす言語学者もいる。トルラク方言には標準形はなく、またトルラク方言に属する諸方言にも多くの多様性がある。
この言語を話すのは、民族的にはセルビア人、ブルガリア人、マケドニア人にまたがっている。また、ルーマニアに住む少数のクロアチア人（クラショヴァ人）や、コソボ南部に住むブルガリア人・マケドニア人と近縁のゴーラ人もトルラク方言の話者である。
トルラク方言 分類
19世紀の間、トルラク方言やマケドニア語はブルガリア語の一部とみなされることも多かった。19世紀から20世紀初頭にかけて、ブルガリア人、セルビア人それぞれの言語学者は、それぞれの軍隊と同様にセルビア語とブルガリア語の境界を策定するために闘争を繰り広げた。
パヴレ・イヴィッチ（Pavle Ivić）やアシム・パツォ（Asim Peco）などのセルビア人の言語学者たちは、トルラク方言をセルビア語のシュト方言の一部とみなし、プリズレン＝ティモク方言と呼んだ。パヴレ・イヴィッチは、ブルガリア語の方言の一部はブルガリア語よりもむしろセルビア語に近いとして、プリズレン＝ティモク方言は完全にセルビア語に属するものと主張し、ブルガリア語遷移方言やショプ人といったものは東部南スラヴ語群（ブルガリア語など）よりも西部南スラヴ諸語（セルビア語など）に近いとした
トルラク方言 分類
他方で、クルステ・ミシルコフやベニョ・ツォネフ（Benyo Tsonev）、ガヴリル・ザネトフ（Gavril Zanetov）といったブルガリアの言語学者らはトルラク方言をブルガリア語の方言に分類している。彼らは、格の消失などの文法的な特徴をもとに、トルラク方言をブルガリア語に属するものとしている。ストイコ・ストイコフ、ランゲル・ボジコフ（Rangel Bozhkov）などは、この言語をブルガリア語のベログラトチク＝トルン方言に分類し、シュト方言の範疇に含めるべきではないとしている。ストイコフはトルラク方言の文法はブルガリア語のものに近く、その起源がブルガリア語にあることを示しているとしている。
クロアチアの言語学者ミラン・レシェタルは、トルラク方言（レシェタルによれば「スヴルリグ方言 (Svrlijg)」はシュト方言とは異なる方言群であるとしている。別のクロアチアの言語学者ダリボル・ブロゾヴィッチもまた、トルラク方言はシュト方言とは異なるとしている。
トルラク方言は、ブルガリア語・マケドニア語とセルビア語が入り交じる地域で見られる。
トルラク方言 特徴
トルラク方言の基礎語彙はほとんどがセルビア語、ブルガリア語およびマケドニア語同様にスラヴ祖語に起源を持つものであるが、シャル山脈のゴーラではアルーマニア語、ギリシャ語、トルコ語、アルバニア語などからの借用語も多く見られる。また、多くの主要言語では使われなくなったり意味が変わってしまった古い語が残されている。なお、トルラク方言に属する諸方言の間でも差異は大きく、例えばルーマニアのクラショヴァ人はゴーラ人の言語を理解できるとは限らない。
スラヴ系の各国で話されるトルラク方言は、特に新しく導入された単語や概念において、それぞれその国の標準形の言語の影響を受けている。この例外はルーマニアであり、オスマン帝国の衰退後に誕生したスラヴ各国の標準語の影響を免れている。この地方に古来より住むスラヴ人はクラショヴァ人（カラショヴァ人）と呼ばれており、彼らはセルビア東部のティモチュカ・クライナから移住した人々と移住先のルーマニアに住むスラヴ人とが混合した民族集団である。
マケドニア語およびブルガリア語は現代のスラヴ諸語において数少ない、ほぼすべての格が失われた言語であり、名詞の多くは主格の形のみのこされている。トルラク方言もこの特徴を持っている。北西においては具格が属格と統合され、さらに処格と属格が統合される。更に南ではあらゆる屈折が消失し、意味的関係は前置詞のみによって決まるようになる。
トルラク方言 特徴
マケドニア語、トルラク方言、ならびにブルガリア語やセルビア語の一部の方言では、他のスラヴ諸語と異なり、[x]、[ɦ]、[h]といった音価は存在しない。この他のスラヴ諸語では、スラヴ祖語の「*g」に由来する[x]や[ɦ]といった音価は広く一般的である。マケドニア語における「h」の大部分は、借用語や、ペフチェヴォ（Пехчево / Pehčevo）などの一部の方言が話される地方の地名にみられるものである。これに対してマケドニア語標準形はプリレプの方言を土台としている。「千」や「強要」はマケドニア語標準形ではそれぞれ「iljada」、「itno」であるのに対してセルビア語標準形では「hiljada」、「hitno」となっている。また、「ホラ」や「美しい」はマケドニア語標準形の「oro」、「ubav」に対してブルガリア語標準形では「horo」、「hubav」となっている。この違いを分け隔てる等語線は、マケドニア共和国南端でプリレプとペフチェヴォの間を通り、中央セルビアのシュマディヤに達する。シュマディヤの土着の民謡では、「私は欲する」を意味する語として「оћу / oću」が使われており、これはセルビア語標準形では「хоћу / hoću」となる。
トルラク方言 特徴
トルラク方言では、古語に見られる音節主音の/l/が残されており、/r/と同様に音節の主音として機能している。/l/は西スラヴ語群の一部では現代でも音節主音として残っている。シュト方言では、音節主音の/l/は/u/や/o/へと変化した。ブルガリア語では、/l/の前に「ъ」の文字で表される母音/ɤ/が挿入されることで、子音クラスタが切り分けられた。トルラク方言に属する全ての方言で/l/が完全に保存されているわけではなく、完全に音節主音となっているものから[ə]、[u]、[ɔ]、[a]といった母音を伴うようになったものまで様々である。音節主音の/l/は多くが軟口蓋化して[ɫ]へと変化している。
すべてのトルラク方言において:
一部のトルラク方言において:
トルラク方言 書物
トルラク方言は歴史上、国の公用語として整備されたことがないため、トルラク方言で書かれた書物は少なく、古代教会スラヴ語を第一に用いる正教会の神品による文献がある程度である。トルラク方言の影響を受けた文体の書物として知られる限り最古のものとしては、テムスカ修道院の手稿がある。これは、1762年にピロト出身のキリル・ジヴコヴィッチによって著されたものであり、自身はこの言語を「簡易なブルガリア語」とみなしていた。
トルラク方言 民族誌
「トルラク」とは南スラブ語で羊の囲いを意味する「tor」に由来し、トルラクはかつて羊飼いを意味するとの説がある。また、トルラク方言の話者、すなわちトルラク人を独自の民族グループとみなす説もある。トルラク人はショプ人の一部とされたり、逆にショプ人がトルラク人の一部とされることもあり、19世紀にはトルラク人とショプ人の明確な区別はなかった。オスマン帝国統治時代、この地方の人々はブルガリア人あるいはセルビア人といった民族意識を持っていなかった。このため、セルビア人やブルガリア人はいずれもトルラク人を自民族の一部であると主張しており、トルラク人の中にもセルビア人に同調する者もブルガリア人に同調する者もある。19世紀の文献で、トルラク人がブルガリア人としての民族意識を持っていると記しているものがある。オスマン帝国の影響力が弱まった結果、19世紀後期から20世紀初頭にかけてバルカン半島では民族主義的感情が高まる。トルラク地域におけるブルガリアとセルビアの国境はベルリン条約、バルカン戦争、第一次世界大戦によって変動し、後にマケドニア共和国の成立によって更に国境が生じた。
トルラク方言 脚注
Friedman, Victor (2006). “Determination and Doubling in Balkan Borderlands”. Harvard Ukrainian Studies 1-4:  105–116. http://mahimahi.uchicago.edu/media/faculty/vfriedm/220Friedman09.pdf.
Friedman, Victor (2008). “Balkan Slavic Dialectology and Balkan Linguistics: Periphery as Center”. American Contributions to the 14th International Congress of Slavists 1:Linguistics:  131–148. http://home.uchicago.edu/~vfriedm/Articles/213Friedman08.pdf.
和田淳子
和田 淳子（わだ じゅんこ、1973年 - ）は、日本の映像作家。青森市出身。
文化服装学院卒。イメージフォーラム付属映像研究所18＆19期生。一定のリズムをもったモノローグと、女性ヌードをモチーフにした身体イメージで注目を集め、90年代半ばのガーリー・ムーブメントの一翼をになう存在となる。
短編映画「桃色ベビーオイル」でぴあフィルムフェスティバルグランプリノミネート、IFF大賞受賞。初の長編映画「ボディドロップアスファルト」が、バンクーバーを始めとする国際映画祭の正式招待作品となり、日本のアヴァンギャルト・ムービーをリードするフィルムメーカーの一人として紹介される。
ほかにファッションブランド"TOCCA"のDM,ポスターの企画など。
現在、手製本による短篇小説写真集を代表に、撮影、おはなし、ブックデザインのすべてを独りで手掛けている。
和田淳子 フィルモグラフィ
(企画)愛知芸術文化センター (制作)愛知県文化情報センター　
(出演)小山田サユリ、尾木真琴、田中要次、岸野雄一、マチュー・マンシュ、あがた森魚、大久保賢一、鈴木慶一、手塚眞、沼田元氣、鈴木卓爾、小代浩人、金井勝 
(監督・脚本・衣装)和田淳子　(エグゼクティブ・プロデューサー)越後谷卓司
(オリジナル映像作品作家選定委員)竹葉丈,とちぎあきら,平野勇治,村山匡一郎 
(制作主任)藤田功一 (撮影・照明)白尾一博,宮下昇 (編集)白尾一博 (録音)小林徹哉 (ＣＧ制作)高島秀夫,花岡岳 
(タイトルデザイン)辻川幸一郎 (ヘアメイク)小野あけみ(スチール)首藤幹夫 
(音楽)コモエスタ八重樫 (衣装協力)VIA BUS STOP
和田淳子 手製本
代表作「Spring and Fall」(和田淳子による撮り下ろしの写真と短篇物語集)
グループGT2
グループGT2（グループジーティーツー）は、自動車レースに使用する競技車両のカテゴリーの1つである。1999年で旧GT1が消滅し、旧GT2車両がGT1に改称しトップカテゴリーに設定された際に下位カテゴリーとして設立された。FIAによる正式な呼称は「Groupe GT2（仏語：グループ GT2）」であるが、日本国内ではあまり一般的な呼び方ではなく、「GT2クラス」もしく「FIA GT2」などと呼ぶことがほとんどである。
グループGT2 概要
市販スポーツカーを改造した車両がホモロゲーション（公認）の対象となる。改造範囲がGT1マシンにくらべて狭く、より市販車に近い。世界のGTレースでワークス・プライベーター問わず運用された。しかし勝てるマシンが限られたことから人気が衰退し、後にフランス西部自動車クラブ（ACO）が耐久レース向けのLM-GTEとして発展させたものを引き継ぐ形となった。
その後、ブランパンGTシリーズ（後のGTワールドチャレンジ）を運営するSROモータースポーツグループが「GT2」の名称を復活させることを発表。2021年よりGTワールドチャレンジ・ヨーロッパの併催イベントとしてGT2ヨーロピアンシリーズが開催されているほか、いくつかの地域でレースが行われている。
グループGT2 レギュレーション
エンジン(排気量)
最低重量
駆動系、足回り
燃料タンク最大容量
大島大火
大島大火（おおしま たいか）は、1965年（昭和40年）1月11日、伊豆大島（東京都大島町）で発生した大規模な火災である。
島西部の集落・元町の中心部が壊滅した。
記事により「伊豆大島大火」と表記される場合もある。