Motoko はモダンな汎用プログラミング言語で, 特に インタネット・コンピュータ のキャニスタ・スマート・コントラクトを記述するのに使えます. Internet Computer での利用を直接の目標としていますが, 汎用性のあるデザインになっているので, 将来的には他のターゲットへのコンパイルも十分可能です.
Motoko is a modern, general-purpose programming language you can use specifically to author Internet Computer canister smart contracts. Although aimed squarely at the Internet Computer, its design is general enough to support future compilation to other targets.
Motokoは, JavaScript のようなモダンなプログラミング言語 (Rust, Swift, TypeScript, C#, Java など) でのオブジェクト指向, あるいは関数型のプログラミング・イディオムにある程度馴染んでいるプログラマが取り組みやすいように考えて設計した, モダンな言語です.
Motoko is a modern language designed to be approachable for programmers who have some basic familiarity with modern object-oriented and/or functional programming idioms in either JavaScript, or another modern programming language, such as Rust, Swift, TypeScript, C#, or Java.
Motoko はモダンなプログラミング・イディオムを用意していますが, 中でも分散型アプリケーション (dapp) 向けの特別なプログラミング抽象化を用意しています. Dapp のひとつひとつは, もっぱら 非同期なメッセージ・パッシング によって通信するひとつ, あるいは複数の アクタ から成ります. あるアクタの状態は他のアクタからは完全に切り離されているので, 分散性が成立します. 複数のアクタ間で状態を共有することはできません. Motoko のアクタ・ベースのプログラミング抽象化によって, ひとにも読みやすいメッセージ・パッシングのパタンを記述できるので, それぞれのネットワーク上の相互作用が一定のルールに則り, ありがちな誤りを回避することが可能になります.
Motoko permits modern programming idioms, including special programming abstractions for distributed applications (dapps). Each dapp consists of one or more actors that communicate solely by asynchronous message passing. The state of an actor is isolated from all other actors, supporting distribution. There is no way to share state between several actors. The actor-based programming abstractions of Motoko permit human-readable message-passing patterns, and they enforce that each network interaction obeys certain rules and avoids certain common mistakes.
特に, Motoko には実用的かつ実用的な型システムがあり, 実行前に型を検査できるので, Motoko で書かれたプログラムは 型健全 であると言えます. Motoko の型システムは, Motoko で書かれたプログラムが, あり得るどんな入力に対しても動的な型エラーなしに安全に実行できるかどうかを静的に検査します. これによって, 他の言語 (特に Web 向けプログラミング言語ね) でよくあるプログラミング上の落し穴 (null 参照, 引数や返値の型の不適合, 存在しないフィールドへのアクセス, などなど) の類をすべて排除できます.
Specifically, Motoko programs are type sound since Motoko includes a practical, practical type system that checks each one before it executes. The Motoko type system statically checks that each Motoko program will execute safely, without dynamic type errors, on all possible inputs. Consequently, entire classes of common programming pitfalls that are common in other languages, and web programming languages in particular, are ruled out. This includes null reference errors, mis-matched argument or result types, missing field errors and many others.
Motoko は実行のために WebAssembly (モダンなコンピュータ・ハードウェアとして明確に抽象化された, 可搬性のあるバイナリ形式) にコンパイルされるので, インタネット上の広い範囲で, もちろん [Internet Computer](../../../../concepts/what-is-Internet Computer) 上でも実行できます.
To execute, Motoko statically compiles to WebAssembly, a portable binary format that abstracts cleanly over modern computer hardware, and thus permits its execution broadly on the Internet, and the [Internet Computer](../../../../concepts/what-is-Internet Computer).
Motoko は開発者が [Internet Computer](../../../../concepts/what-is-Internet Computer) 上のキャニスタ・スマート・コントラクトを含む サービス を記述するために アクタ・ベース のプログラミング・モデルを提供します.
Motoko provides an actor-based programming model to developers to express services, including those of canister smart contracts on the [Internet Computer](../../../../concepts/what-is-Internet Computer).
アクタはオブジェクトに似ていますが, その状態が完全に分離されている点と, その世界の中では 非同期 なメッセージングによってすべての相互作用を行う点が特徴です.
An actor is similar to an object, but is special in that its state is completely isolated, and all its interactions with the world are by asynchronous messaging.
アクタ間のすべての通信には, インタネット・コンピュータのメッセージング・プロトコルを用いたネットワーク上の非同期のメッセージ・パッシングが伴います. ひとつのアクタ内ではメッセージは順次処理され, 状態の変更では (await 式によって明示的に中断されない限りは) 競合は起こりません .
All communication with and between actors involves passing messages asynchronously over the network using the Internet Computer’s messaging protocol. An actor’s messages are processed in sequence, so state modifications never admit race conditions (unless explicitly allowed by punctuating await expressions).
インタネット・コンピュータでは, メッセージを送るごとにリスポンスを受け取ることが保証されます. リスポンスは成功 (何らかの値がある) か, エラーか,です. エラーは, 受け取ったキャニスタ・スマート・コントラクトがそのメッセージを明示的に拒絶したこと, あるいは, ゼロ除算のような不正命令でトラップしたこと, メッセージの配送や資源の制約に起因するシステム・エラーが生じたことを示しています.
The Internet Computer ensures that each message that is sent receives a response. The response is either success with some value, or an error. An error can be the explicit rejection of the message by the receiving canister smart contract, a trap due to an illegal instruction such as division by zero, or a system error due to distribution or resource constraints. For example, a system error might be the transient or permanent unavailability of the receiver (either because the receiving actor is oversubscribed or has been deleted).
他のモダンなプログラミング言語と同じように, Motoko でもコンポネント間の 非同期 な通信用のひとにやさしい構文を使えます.
Like other modern programming languages, Motoko permits an ergonomic syntax for asynchronous communication among components.
Motoko の場合は, コミュニケートするコンポネントとはアクタのことです.
In the case of Motoko, each communicating component is an actor.
アクタを 利用した 例題として, 次の三行のプログラム (多分これ自身がアクタ) を見てみましょう:
As an example of using actors, perhaps as an actor ourselves, consider this three-line program:
let result1 = service1.computeAnswer(params);
let result2 = service2.computeAnswer(params);
finalStep(await result1, await result2)
このプログラムの振る舞いをまとめると, 次の 3 ステップになります:
await キーワードを用いて, 結果が戻って来るのを待つ (行 3).finalStep 関数を呼び出す.We can summarize the program’s behavior with three steps:
await on each result value.finalStep function.一般的には, 複数のサービスの実行はひとつずつ順に行われるのではなく, インタリーヴして 行われることになります. その方が全体的な待ち時間を減らせるからです. ただし, このような待ち時間の短縮を言語の特別なサポート無しで実現しようとすると, 明解さと単純さを大きく犠牲にせざるを得ないでしょう.
Generally-speaking, the services interleave their executions rather than wait for one another, since doing so reduces overall latency. However, if we try to reduce latency this way without special language support, such interleaving will quickly sacrifice clarity and simplicity.
このようなプロミング抽象化があれば, インタリーヴした 実行がない場合 (例えば, 上記のような二つの呼び出しではなく, ひとつだけの場合) でさえ, 明解さと単純さがもたらされます. と言うのも, このようなプロミング抽象化によって, プログラムをどのように変換するかの指示をコンパイラに与え, 下層のシステムのメッセージ・パッシングのループを使って実行をインタリーヴするためにプログラムのロジックをいじくる手間からプログラマを解放できるからです.
Even in cases where there are no interleaving executions (for example, if there were only one call above, not two), the programming abstractions still permit clarity and simplicity, for the same reason. Namely, they signal to the compiler where to transform the program, freeing the programmer from contorting the program’s logic in order to interleave its execution with the underlying system’s message-passing loop.