Australとは

基本情報

項目	内容
名称	Austral
分類	線形型とcapability securityを重視するシステムプログラミング言語
主な用途	型システム・資源管理・安全な低レイヤー設計の研究、小規模な試作
資源管理	ガベージコレクションを前提とせず、線形型で値と資源の消費を管理
処理系	コンパイラがCコードを生成し、Cコンパイラを利用
開発状態	発展途上。標準ライブラリ、分離コンパイル、パッケージ管理を採用前に確認
公式サイト	austral-lang.org
ソースコード	austral/austral
確認日	2026-07-14

Australは、線形型とcapability-based securityを中核に据えたシステムプログラミング言語です。

公式サイトでは、メモリ安全性とcapability-secureなコードを提供しながら、1人でも全体を理解できるほど単純な言語を目指し、可読性、保守性、モジュール性を重視すると説明されています。

Australは、CやC++のようにガベージコレクションを使わず低レベルな資源を扱う一方で、メモリやファイルハンドルなどの資源を型システムによって安全に管理しようとします。

主な特徴は次のとおりです。

線形型
capability-based security
ガベージコレクションなし
デストラクタなし
例外なし
暗黙のコピーなし
暗黙の型変換なし
グローバル状態なし
未初期化変数なし
安全な算術
代数的データ型
網羅性検査
型クラス
モジュールシステム

Rustと同じく「ガベージコレクションなしでメモリ安全性を高めるシステム言語」という比較軸があります。

ただし、AustralはRustの小型版ではありません。

Rustが所有権、借用、ライフタイム、RAII、Drop、trait、unsafeを組み合わせるのに対し、Australはより厳格な線形型、明示的な資源消費、capability、例外やデストラクタを持たない設計によって安全性を実現しようとします。

結論：型システムと安全なシステム言語を研究・試用する人に向く

Australが向いているのは、線形型、所有権、capability-based security、ガベージコレクションを使わない安全な資源管理を学びたい人です。

小規模なツール、サンプル、コンパイラ研究、言語比較、セキュリティ設計の実験にも適しています。

一方、成熟したエコシステム、豊富なライブラリ、安定したパッケージ管理、広いプラットフォーム対応、商用サポートを必要とする本番システムでは、Rust、Ada/SPARK、C++、Zigなどと慎重に比較する必要があります。

公式リポジトリでは、コンパイラが仕様上の機能を実装していると説明されていますが、標準ライブラリは基本的なデータ構造やcapability-based filesystem accessを拡充中であり、分離コンパイルをサポートしないこと、ビルドツールとパッケージマネージャーがロードマップ上の課題であることも記載されています。

したがって、現時点では「言語機能が存在すること」と「一般的な本番開発基盤として成熟していること」を分けて評価する必要があります。

Australが向く人

線形型を実際のコードで学びたい人
所有権・資源管理の言語設計を研究する人
capability-based securityを調査する人
Rustとは異なる安全性設計を比較したい人
小規模なシステムツールを試作する人
コンパイラや型システムを学ぶ人
暗黙処理を極力排除した言語を試したい人

Australを避ける条件

大規模な本番サービスへ直ちに採用したい
成熟したWeb、GUI、DB、非同期I/Oエコシステムが必要
crates.ioのような大規模パッケージレジストリを前提とする
IDE、デバッガ、プロファイラ、静的解析の充実を最優先する
多数の開発者を短期間で採用・教育する必要がある
対応OS、ABI、FFI、クロスコンパイル要件を検証していない
言語の安全性だけでアプリケーション全体が安全になると考えている

30秒要約

Australは線形型を使う新興システムプログラミング言語
メモリ安全性とcapability-based securityを設計目標にする
ガベージコレクション、デストラクタ、例外、暗黙コピーを持たない
線形値は原則として正確に1回使用・消費する
メモリだけでなく、ファイルやDBハンドルなどの資源も線形に扱える
安全な算術として、オーバーフロー時に停止する演算と剰余演算を区別する
Rustとは所有権の目的が似るが、借用・RAII・Drop・unsafeの設計が異なる
コンパイラはOCamlで実装され、既定ではCコードを生成してCコンパイラを呼ぶ
公式リポジトリの最新リリース表示は2023年6月27日の0.2.0
masterの活動、標準ライブラリ、ロードマップはリリース番号と別に確認する
本番採用前に、分離コンパイル、パッケージ管理、標準ライブラリ、FFI、ツールを実機検証する

Austral、線形型、所有権、capabilityの違い

用語	意味
Austral	線形型とcapability-based securityを重視するシステム言語
線形型	値を原則として正確に1回使用することを型システムで管理する型
Affine型	値を最大1回使用する型。使わず破棄できる
所有権	資源を管理・解放する責任を特定の値へ対応付ける考え方
Borrowing	所有権を移さず一時的な参照を許可する仕組み
Capability	特定の操作や資源へアクセスする権限を表す値
メモリ安全性	use-after-free、double free、dangling pointerなどを防ぐ性質
Safe arithmetic	オーバーフローなどの算術動作を明確に定義する設計
ADT	代数的データ型。複数のconstructorを持つ型
Typeclass	型が提供すべき操作を定義する仕組み
Module interface	外部へ公開する型や関数の宣言
Module body	実装を記述する部分

Australでは、メモリ安全性とcapability-based securityがつながっています。

ファイルシステムや外部資源へアクセスするには、その権限を表すcapabilityを関数へ明示的に渡します。グローバルな権限へ暗黙にアクセスする設計を避けることで、関数や依存コードが何を操作できるかを制限しやすくします。

線形型とは何か

線形型では、線形な値を複製したり、黙って捨てたりできません。

概念的には次の規則です。

線形値は正確に1回使う

例えば、ヒープ上のメモリ領域を表す線形値があるとします。

その値を2回解放できるなら、double freeが発生します。

値を解放せず忘れられるなら、メモリリークが発生します。

線形型によって、資源を表す値が必ず1つの経路を通り、最終的に明示的に消費されることをコンパイル時に確認します。

通常の値

整数やBooleanなど、コピーしても意味が変わらない値は非線形に扱えます。

xを複数回読む
xをコピーする
xを使わず終了する

線形な値

メモリ、ファイル、ソケット、DB connection、暗号鍵など、複製や放置が危険な資源は線形に扱う候補です。

resourceを別変数へ移動する
resourceを操作する関数へ渡す
最後にclose/free相当の関数で消費する

線形型とAffine型の違い

Rustの所有権は、しばしばAffine型に近いものとして説明されます。

Rustの値は所有者を1つ持ち、コピーできない型はmoveされますが、値を明示的に使わないままスコープを抜けることもできます。その際、Drop実装があればデストラクタが自動実行されます。

Australはデストラクタを持たず、線形資源の破棄を暗黙化しない設計です。

観点	線形型	Affine型
使用回数	正確に1回	最大1回
未使用	原則エラー	許容可能
コピー	明示的に許可された型のみ	型により禁止
資源解放	明示的消費と相性がよい	スコープ終了時の自動破棄と相性がよい
Austral	中心的設計	一部概念との比較対象
Rust	厳密な線形型ではなく所有権・Affine的管理	中心的設計

ただし、実際の両言語の型システムは単純な一語では説明しきれません。正確な規則は各公式仕様を確認します。

メモリ安全性をどう実現するか

Australは、次の組み合わせでメモリ安全性を目指します。

線形型
暗黙コピーなし
未初期化変数なし
明示的な資源消費
参照の制限
安全な配列・ポインタ操作
capabilityによる低レベル操作の制御
例外なし
デストラクタなし
明確な制御フロー

防ごうとする問題

double free
use-after-free
dangling reference
未初期化メモリの読み取り
資源の二重取得
資源リーク
暗黙コピーによる所有権の混乱
権限を持たないコードからの低レベル操作

公式リポジトリは、線形型によってメモリだけでなく、ファイルやデータベースハンドルなどの資源も安全に扱えると説明しています。

capability-based securityとは

Capabilityは、何かを実行できる権限を表す値です。

例えば、ファイルシステムへアクセスする関数がある場合、グローバルなファイルAPIを誰でも呼べる設計ではなく、ファイル操作権限を表すcapabilityを受け取る関数として設計します。

概念例:

readConfig(path)

よりも、次の形です。

readConfig(fileCapability, path)

関数がcapabilityを受け取らなければ、ファイルへアクセスできません。

利点

関数の権限を引数から確認できる
依存ライブラリへ必要最小限の権限だけ渡せる
グローバル状態を減らせる
テスト用capabilityへの差し替えを設計しやすい
supply-chain attackの影響範囲を制限できる可能性がある

限界

Capabilityを導入するだけで安全になるわけではありません。

強すぎるcapabilityを渡す
capabilityを不必要に長く保持する
FFI先が権限境界を無視する
path traversalを許す
権限確認後に対象が変化する
秘密情報をログへ出す

といった問題は別途対策が必要です。

Australのanti-features

Austral公式は、あえて採用しない機能をanti-featuresとして列挙しています。

採用しない機能	狙い
Garbage collection	実行時停止やGC依存を避ける
Destructors	隠れた制御フローと暗黙解放を避ける
Exceptions	予期しない非局所的制御フローを避ける
Implicit function calls	見えない処理を避ける
Implicit type conversions	意図しない型変換を避ける
Implicit copies	資源の複製を避ける
Global state	隠れた依存・権限を避ける
Subtyping	型関係を単純化する
Macros	構文変形と複雑性を抑える
Reflection	実行時の暗黙性を抑える
Annotations	メタプログラミング依存を抑える
Type inference	型情報の流れを一方向に保つ
Uninitialized variables	未定義値の利用を防ぐ
Operator precedence	式の解釈を明示させる
Variable shadowing	同名変数による混乱を避ける

この設計は可読性と予測可能性を高める一方、他言語では簡潔に書ける処理が冗長になる可能性があります。

基本コード

公式リポジトリのFibonacci例に沿った基本構造です。

module body Fib is
    function fib(n: Nat64): Nat64 is
        if n < 2 then
            return n;
        else
            return fib(n - 1) + fib(n - 2);
        end if;
    end;

    function main(): ExitCode is
        print("fib(10) = ");
        printLn(fib(10));
        return ExitSuccess();
    end;
end module body.

コンパイルします。

austral compile fib.aum \
  --entrypoint=Fib:main \
  --output=fib

実行します。

./fib

期待される出力:

fib(10) = 55

この例では.aumがmodule bodyファイルです。

大きなプログラムでは、公開interfaceを.aui、実装を.aumへ分けます。

実行例1：module interfaceとmodule bodyを分ける

Counter.aui:

module interface Counter is
    function increment(value: Nat64): Nat64;
end module interface.

Counter.aum:

module body Counter is
    function increment(value: Nat64): Nat64 is
        return value + 1;
    end;
end module body.

Main.aum:

module body Main is
    import Counter: increment;

    function main(): ExitCode is
        let value: Nat64 := increment(41);
        printLn(value);
        return ExitSuccess();
    end;
end module body.

概念的なコンパイル:

austral compile \
  Counter.aui,Counter.aum \
  Main.aum \
  --entrypoint=Main:main \
  --output=program

正確なimport構文、数値出力関数、module一覧の渡し方は、対象コミットのチュートリアルとexample programsで確認してください。

公式リポジトリでは、複数moduleをカンマ区切りでコンパイラへ渡す例が示されています。

実行例2：Cコードを生成して確認する

Australコンパイラは、既定ではCコードを生成し、Cコンパイラを呼び出して実行ファイルを作ります。

Cコードだけを出力する例:

austral compile \
  --target-type=c \
  fib.aum \
  --entrypoint=Fib:main \
  --output=fib.c

生成物を確認します。

sed -n '1,200p' fib.c

公式READMEは、生成Cを次のようなオプションでコンパイルする例を示しています。

gcc -fwrapv fib.c -lm -o fib

注意

生成Cは人が直接保守する正本ではありません。

Australソースを正本にする
生成Cへ直接修正を入れない
-fwrapvが必要な理由を確認する
利用するCコンパイラを固定する
sanitizerで生成物も検査する
ABIとプラットフォーム差を確認する

ことが重要です。

実行例3：型チェックだけ行う

実行ファイルを作らず、型チェックだけ行うtargetが公式READMEに示されています。

austral compile \
  --target-type=tc \
  Counter.aui,Counter.aum \
  Main.aum

CIでは、型チェックと実行テストを分ける構成を検討できます。

lint相当の確認
型チェック
C生成
Cコンパイル
単体テスト
sanitizer
対象OSでの実行

ただし、正式なテストランナーやパッケージ管理の現状は対象コミットで確認します。

線形資源の概念例

Australの線形型を説明する概念例です。

-- 正確なAPI名は対象標準ライブラリで要確認

let handle: File := openFile(root, "data.txt");
let content: String := readAll(handle);
closeFile(handle);

線形なhandleは、コピーしたり、閉じた後に再利用したり、閉じずに関数を抜けたりできないことを型検査で確認する設計です。

次の操作は拒否されるべき対象です。

handleを2つの変数へ複製する
handleを2回closeする
close後にreadする
handleを消費せずreturnする

実際のfilesystem APIは標準ライブラリの開発状況と仕様で変化する可能性があります。記事公開前に公式exampleまたは標準ライブラリソースで確認してください。

安全な算術

Austral公式は、数値型の全演算に明確な意味を与え、オーバーフロー時にtrapする演算とmodular arithmeticを区別すると説明しています。

これは、C系言語で問題になりやすい次の点を明確化する狙いがあります。

符号付き整数オーバーフロー
桁あふれ
wraparoundを期待する処理
境界値での実装依存
最適化による予期しない変形

Trap-on-overflow

範囲外になった場合に停止させる演算です。

金額、件数、配列長など、桁あふれを見逃したくない処理に向きます。

Modular arithmetic

一定ビット幅でwraparoundすることを明示した演算です。

ハッシュ、暗号、ビット演算、PRNGなどで必要になる場合があります。

演算子名と具体構文は、対象Austral仕様のArithmeticセクションで確認してください。

代数的データ型と網羅性検査

AustralはMLやHaskellのような代数的データ型を提供し、case分析の網羅性を検査します。

概念例:

union Result[T: Type, E: Type] is
    case Ok(value: T);
    case Error(error: E);
end;

利用側:

case result of
    when Ok(value) do
        -- 成功処理
    when Error(error) do
        -- エラー処理
end case;

Australは例外を持たないため、失敗を戻り値の型で表現し、呼び出し側が明示的に処理する設計が重要になります。

正確なgeneric、kind、union、case構文は仕様で確認してください。

AustralとRustの比較

観点	Austral	Rust
主目的	単純で安全なシステム言語	高性能で安全な汎用システム言語
資源管理	線形型、明示的消費	所有権、借用、RAII、Drop
型の使用規則	線形値は正確に1回	コピー不可値は最大1回move、スコープ終了でdrop可能
Garbage collection	なし	なし
Destructors	なし	`Drop`あり
Exceptions	なし	なし。panicは存在
Borrowing	制限されたborrowを仕様で提供	共有・可変参照とlifetime
Unsafe	安全境界をcapability等で制御	`unsafe`ブロック・関数・trait
Capability security	言語設計の中心	標準所有権とは別途設計
Type inference	原則採用しない	広く利用
Implicit copies	なし	`Copy`型は暗黙コピー
Global state	採用しない方針	`static`、`const`等あり
Macros	なし	宣言・手続きmacroあり
Subtyping	なし	lifetime subtyping等がある
Arithmetic	trap演算とmodular演算を明示	debug/release差やwrapping APIを理解する必要
Package manager	ロードマップ上で要確認	Cargo
Package registry	要確認	crates.io
Standard library	拡充中	広い
Async	first-class asyncなし	async/awaitあり
Separate compilation	公式READMEで未対応	対応
Ecosystem	小規模・成熟度要確認	大規模
Stable release	0.xで要確認	Stable channelあり

Rustと同じ点

ガベージコレクションを使わない
コンパイル時に所有権・資源利用を検査する
use-after-freeやdouble freeを防ごうとする
システムプログラミングを対象にする
Cとの相互運用やネイティブコード生成を意識する
型システムで安全性を高める

Rustと異なる点

デストラクタ

Rustでは、所有値がスコープを抜けるとDropが自動実行されます。

Australはデストラクタをanti-featureとして持たず、資源解放を暗黙の制御フローにしない方針です。

借用

Rustはborrow checkerとlifetimeを中心に、多様な参照パターンを許します。

Australは線形性を中心に、より単純で制限された資源の受け渡しを目指します。

エコシステム

RustにはCargo、crates.io、rustup、rustfmt、Clippy、rust-analyzerなどがあります。

Australは公式ロードマップ上でbuild toolingとpackage managerが課題とされ、標準ライブラリも拡充中です。

言語の複雑性

Rustは実用範囲が広い一方、trait、lifetime、macro、async、unsafe、Pinなど、多くの概念があります。

Australは機能を意図的に削り、1人が言語全体を理解できる単純さを目指します。

Austral、Rust、C、Zigの比較

判断軸	Austral	Rust	C	Zig
メモリ安全性	線形型中心	所有権・借用中心	開発者責任	明示的管理と安全機能
GC	なし	なし	なし	なし
成熟度	新興・要検証	高い	非常に高い	発展中
エコシステム	小さい	大きい	非常に大きい	拡大中
標準ライブラリ	拡充中	広い	小さいが安定	広い方向
パッケージ管理	要確認	Cargo	統一標準なし	build systemあり
言語仕様の単純さ	強く重視	機能が多い	言語は比較的小さい	明示性を重視
Capability	中心機能	ライブラリ・設計で実現	標準にはない	標準中心ではない
本番採用実績	公開事例を要確認	多い	非常に多い	増加中
学習目的	型・安全性研究	実務と安全性	低レベル基礎	現代的低レベル開発

導入判断フロー

1. 目的は学習・研究か本番採用か

学習・研究:

Australは有力な対象です。

本番採用:

次へ進みます。

2. Rustでは満たせない要件があるか

例:

デストラクタを避けたい
capabilityを言語中心に扱いたい
言語全体の単純さを重視する
線形型を厳密に利用したい
暗黙処理を極小化したい

明確な理由がなければ、成熟度の高いRustを優先する判断があります。

3. 必要ライブラリがあるか

確認項目:

filesystem
networking
TLS
HTTP
serialization
database
concurrency
cryptography
logging
testing
CLI parsing
OS API
C FFI

不足する場合、自作コストとセキュリティ監査が必要です。

4. 対象プラットフォームでビルドできるか

Linux
macOS
Windows
embedded
cross compilation
ARM
x86-64
musl
static linking

を実機確認します。

5. 保守体制があるか

コンパイラ更新への追従
標準ライブラリ変更
breaking change
build環境
Cコンパイラ
security advisory
fork維持
社内教育

を評価します。

試す前の確認項目

リリース状況

公式GitHubのReleases表示では、2026年7月10日に確認した時点で最新リリースは0.2.0、公開日は2023年6月27日です。

ただし、リリース日だけで継続状況を判断しません。

masterの最新コミット
コミット頻度
open issues
pull requests
roadmap
maintainerの発言
standard libraryの更新
CI状態

を合わせて確認します。

コンパイラ

公式READMEでは、bootstrapping compilerはOCamlで実装され、仕様の全機能を実装すると説明されています。

一方、分離コンパイルをサポートしないことが主な制約として挙げられています。

大規模プロジェクトでは次を測定します。

全体コンパイル時間
incremental buildの有無
module数増加時の挙動
並列ビルド
キャッシュ
CI時間

標準ライブラリ

READMEでは、基本的なデータ構造とcapability-based filesystem accessを持つ標準ライブラリを設計中と説明しています。

必要APIが安定しているか、ドキュメントとテストを確認します。

ビルド依存

公式READMEでは、Nixを使う方法と、OCaml、Dune、opam、Cコンパイラを使う方法が案内されています。

ビルド再現性のため、次を固定します。

Austral commit
OCaml version
Dune version
opam lock
C compiler
OS image
Nix flake lock

コンパイラをソースからビルドする

公式READMEに沿った概念手順です。

git clone https://github.com/austral/austral.git
cd austral

opam環境を作ります。

opam switch create austral 4.13.0
eval "$(opam env --switch=austral)"
opam install --deps-only -y .

ビルドします。

make

テストします。

./run-tests.sh

標準ライブラリをビルドします。

cd standard
make

注意

これは2026年7月10日に確認したREADMEの手順を基にしています。

公開時には次を再確認してください。

推奨OCamlバージョン
Nix手順
opam package
compiler binaryの場所
standard libraryのbuild順序
対応Cコンパイラ
release artifactの有無

セキュリティ上の注意

Australは安全性を重視していますが、言語機能だけでアプリケーション全体の安全性は保証されません。

FFI

Cコードとの境界では、C側の問題をAustralの型システムだけで防げない可能性があります。

pointer lifetime
buffer length
null pointer
integer width
struct layout
ownership transfer
callback lifetime
thread safety
error code
errno

を明示します。

Capabilityの過剰付与

root capabilityや広いfilesystem capabilityを依存ライブラリへ渡すと、最小権限の効果が薄れます。

capabilityを細分化し、必要な関数へ必要な期間だけ渡します。

生成C

生成されたCコードを通常のCコードとして扱い、次を確認します。

cc \
  -Wall \
  -Wextra \
  -Wconversion \
  -Wshadow \
  -fsanitize=address,undefined \
  -fno-omit-frame-pointer \
  generated.c \
  -lm \
  -o program

生成コードが全警告なしになることを保証する例ではありません。対象コンパイラと生成コードに合わせて調整します。

Supply-chain

Australはcapabilityによって依存コードの権限を制約する思想を持ちます。

それでも次は必要です。

依存ソースのレビュー
commit固定
checksum
build環境の隔離
compiler bootstrapの信頼
OCaml/opam依存の監査
C toolchainの監査
CI secretの分離

Arithmetic

安全な算術を使っても、次は別問題です。

ゼロ除算
単位の混同
桁数不足
浮動小数点誤差
入力値検証
配列サイズ計算
メモリ容量超過

保守上の注意

0.xであること

0.x系では、互換性が安定版言語ほど保証されない可能性があります。

compiler version
specification revision
standard library API
generated C ABI
module syntax
command-line interface

を固定します。

リリースとmasterの差

最新リリースが古くてもmasterで開発が続いている場合があります。

逆に、コミット数が多くても利用者向けの安定リリース、migration guide、security supportが整っているとは限りません。

本番ではtagかcommit SHAを固定し、自社で検証します。

小規模コミュニティ

issue回答、bus factor、レビュー速度、脆弱性対応、ドキュメント更新を確認します。

生成物の管理

生成CをGit管理するか、CIで毎回生成するかを決めます。

一般にはAustralソースとcompiler versionを正本とし、生成Cの再現性を検証します。

失敗しやすい点

Rustと同じ所有権言語だと思う

目的は似ていますが、線形型、借用、デストラクタ、capability、暗黙コピーの設計が異なります。

線形型ならメモリリークが絶対にないと断定する

線形型は資源利用を強く制約しますが、FFI、コンパイラの不具合、OS資源、意図的な長期保持、循環する外部構造などを含め、全システムの安全性を無条件に保証するとは限りません。

capabilityがsandboxだと思う

Capabilityは権限を値として管理する設計です。

OSプロセス分離、container、seccomp、filesystem sandboxと同じものではありません。必要に応じて併用します。

commitが多いだけで成熟していると判断する

安定API、標準ライブラリ、パッケージ管理、実運用事例、セキュリティプロセスは別に確認します。

Rustのライブラリをそのまま使えると思う

Rust crateを直接利用できるわけではありません。

C ABIを介する場合、ownershipと安全境界を設計します。

C生成だからCコンパイラなら何でも動くと思う

公式READMEが示す-fwrapvなどの要件、標準、OS、libc、ABIを確認します。

例外がないためエラー処理が不要と思う

失敗は戻り値、ADT、ExitCodeなどで明示的に扱います。

処理漏れを防ぐ設計とテストが必要です。

導入前チェックリスト

[ ] 利用するAustralのtagまたはcommitを固定した
[ ] 公式仕様のrevisionを記録した
[ ] 最新releaseとmasterの差を確認した
[ ] compilerを再現ビルドできた
[ ] run-tests.shが成功した
[ ] standard libraryをビルドできた
[ ] 対象OSとCPUで実行確認した
[ ] C compilerと必要オプションを固定した
[ ] 分離コンパイルの制約を評価した
[ ] build時間を測定した
[ ] 必要な標準ライブラリAPIを確認した
[ ] package managerの現状を確認した
[ ] networking、TLS、DBの実装方針を決めた
[ ] FFI境界を一覧化した
[ ] capabilityの最小権限を設計した
[ ] 線形資源のclose/free経路をテストした
[ ] arithmeticの境界値をテストした
[ ] 生成Cをsanitizerで確認した
[ ] security policyと脆弱性連絡先を確認した
[ ] Rustなどの代替案と比較した
[ ] 撤退・移行方法を決めた

よくある質問

Australはどんな言語ですか

線形型とcapability-based securityを使って、メモリや外部資源を安全に扱うことを目指すシステムプログラミング言語です。

AustralはRustの代替ですか

比較対象にはなりますが、現時点でエコシステムや成熟度が同等とはいえません。

線形型、capability、単純さという設計を試す言語として評価し、本番用途ではRustのツール・ライブラリ・運用実績と比較します。

Australはガベージコレクションを使いますか

使いません。

線形型と明示的な資源管理によって、GCなしの安全性を目指します。

Australにはデストラクタがありますか

公式READMEでは、destructorをanti-featureとして採用しないと説明されています。

資源は線形な値として明示的に消費します。

Australは例外を使いますか

公式READMEでは例外を採用しません。

失敗は戻り値や代数的データ型などで明示的に表現します。

AustralはCへコンパイルされますか

公式コンパイラはCコードを生成し、既定ではCコンパイラを呼び出して実行ファイルを作ります。

--target-type=cでCコードだけを出力できます。

Australは本番で使えますか

技術的にプログラムを作れますが、本番採用の可否は別問題です。

標準ライブラリ、分離コンパイル、build tooling、package manager、FFI、対象OS、保守体制を検証してください。

開発は続いていますか

2026年7月10日の確認では、公式GitHubに多数のコミット、open issue、pull request、roadmapがあります。一方、Releases欄の最新表示は2023年6月27日の0.2.0です。

継続状況は最新commit、maintainer発言、release、CIを公開時点で再確認してください。

まとめ

Australは、線形型とcapability-based securityを中心に設計された新興システムプログラミング言語です。

主な目標は次のとおりです。

GCなしのメモリ安全性
資源の二重解放や使用後参照の防止
ファイルやDBハンドルの安全な管理
最小権限
明示的な制御フロー
安全な算術
単純で理解可能な言語仕様

Rustと目的は重なりますが、設計は異なります。

Austral:
線形型 + capability + 明示的資源消費 + anti-features

Rust:
所有権 + 借用 + lifetime + RAII + Drop + unsafe

Australを試す価値は、成熟したRustの代用品としてではなく、安全なシステム言語の別設計を学べる点にあります。

本番採用では、次を慎重に確認します。

0.xの互換性
最新releaseとmasterの差
標準ライブラリ
分離コンパイル
build tooling
package manager
FFI
platform support
community
security response