- 組み込みシステム開発では、LuaはMicroPythonより高い安定性と拡張性を提供する
- LuaはCとの統合が容易で、軽量かつ決定論的な構造を持ち、コード保守性と長期的なコスト削減においてより大きな利点がある
- MicroPythonは高速なプロトタイピングには適しているが、大規模プロジェクトやプロダクション環境では限界に突き当たる
- Luaは小さく効率的な実行ファイルとしてビルドでき、不要な機能なしで運用可能で、プロトタイピングから製品化まで高い拡張性と保守性を備える
- Xedge FrameworkはLuaを組み込みシステム向けに最適化し、強力なIoT機能とWeb機能を提供する
組み込みプロフェッショナル環境におけるLua vs. MicroPython
- 産業オートメーション、医療機器、商用IoTなどのプロ向け組み込みプロジェクトでは、高水準でありながら軽量な環境がますます好まれる傾向にある
- MicroPythonは高速なプロトタイピングと現場展開に強みがあるが、主にホビー／教育向けボード中心のエコシステムである
- Pythonの強みであるNumPy、pandasのような大規模ライブラリはMicroPythonにはなく、標準ライブラリも大幅に縮小されている
- C拡張との統合も、MicroPythonは比較的複雑だ
- LuaはCアプリケーションとの統合を根本的な思想として採用している
- 安定したミニマルなC APIとバイトコード仮想マシンを提供
- C/C++の関数やデータ構造をLuaに容易に公開できる
- Lua ANSI Cライブラリは組み込み向けに設計されており、構造が簡潔・軽量・決定論的である
- MicroPythonはPython 3の再実装であり、デスクトップ指向言語としての前提が残っているため、リソース制約のある環境では限界が早く表れる
シームレスなC連携はLuaの中核
- Lua最大の利点はCとのスムーズな統合にある
- APIは安定していて最小限に保たれており、独自のC/C++関数やデータ構造をLuaに簡単に公開できる
- MicroPythonもC拡張をサポートしているが、カスタムファームウェアのビルドが必要で、ワークフローがより複雑になる
- LuaではC連携そのものが設計思想である
- Lua C APIを手動で使うことも、SWIGなどの自動バインディングツールを活用してCの関数／構造体をLuaから呼び出すこともできる
- 性能が重要なロジックはCで、高水準のビジネスロジックはLuaで分離することで、保守性と拡張性を高められる
ミニマルなフットプリントと拡張性
- Luaはコアインタプリタが非常に小さく、不要な機能は簡単に削除できる
- MicroPythonも組み込み向けに最適化されているが、基本イメージが大きく、必須モジュールを有効化すると容量が増える
- どちらも高速なプロトタイピングに適しているが、Luaはプロダクションまで高い拡張性を持つ
- Luaは高水準-低水準の分離構造を設計しやすく、迅速にプロトタイプを開発した後、保守しやすいハイブリッド構成へ発展させやすい
- Luaは最初からCコードと結合してスケールアップが自然で、開発フローが途切れない
- MicroPythonはプロトタイプ後にコアロジックを書き直す必要が出たり、限界に突き当たることがある
エコシステムとライブラリアクセス - Quality Over Quantity
- MicroPythonはWi-Fiボードなどホビー／教育向けハードウェア中心のエコシステムが活発だが、大規模なPythonエコシステムの主要ライブラリが欠けている
- Luaはライブラリの数は少ないが、Cで容易に拡張可能であり、エコシステムの限界にぶつかりにくい
保守性とコスト面での利点
- Luaはコードベースが小さく、テスト・デバッグ・引き継ぎがしやすい
- プロジェクト拡大時にも、LuaスクリプトとCコアの間でレイヤー分離を維持でき、引き継ぎや協業に有利である
- MicroPythonも可読性は高いが、プロジェクトが大きくなるほどシステムコードとスクリプト層が混在しやすい傾向があり、保守コストが上がる可能性がある
結論: Choose What Scales
- 教育やプロトタイピング目的であれば、MicroPythonも優れた選択肢である
- セキュリティ、信頼性、保守性が重要な組み込み製品にはLuaのほうが実用的で、拡張性・柔軟性・安定性を同時に提供する
- Luaは単なるスクリプト言語ではなく、組み込み開発戦略である
組み込み機器でLua Cライブラリを統合する方法
- Lua Cライブラリは軽量・ANSI C互換・標準Cライブラリ以外への依存がほとんどない
- ベアメタル、RTOSベースのシステムに適しており、標準Cのstdin/stdoutなど一部要素は移植時に注意が必要
-
Real Time LogicのXedge Framework
- Xedge Frameworkは組み込み環境に最適化されたLuaランタイムおよびAPIセットを提供
- TLS, MQTT5, WebSocketなどのセキュア通信、RESTful Webサービス、リアルタイムデータ処理、Modbus/OPC UAプロトコルなどIoT/Web機能を内蔵
- Luaの柔軟性と軽量性を保ちながら、実運用に投入可能な完成度の高い組み込みフレームワークを提供する
- Luaを組み込み製品に組み込むなら、Xedgeが最も実用的な選択肢であり、統合を簡素化し、開発速度を高め、差別化されたロジックに集中できるようにする
2件のコメント
そもそも機器を生産するコンポーネントメーカーは、LuaであれPythonであれ、あまりきちんとサポートしていない。せいぜいCくらいか。
Hacker Newsの意見
ゲームエンジンを作って、ゲーム全体をスクリプト言語で書くことにしたとき、JavaScript(QuickJS)、Python(Boost.Python)、Lua(Sol2) の3つで悩んだ
Luaの埋め込みは本当に簡単で、C++ラッパーと一緒に使っても非常に手軽だった
ほどなくして「これならすぐ使えそうだ」と思えるエンジンができあがった
しかもLua VMはとても軽量だ
詳しくは carimboプロジェクト を参照
エンジンやアプリケーションがLuaのスクリプト対応をしているのを見ると、Fennelが使える点が気に入っている
FennelはLuaにトランスパイルされる言語だ
Fennel公式リンク
個人的にはBoost.Pythonはスクリプティング用途としてはいまひとつだと思う
その点が判断に影響した可能性はある
Sol2がLua VMなのか、それとも標準のLua VMの単なるラッパーなのか気になる
「Luaは単なる高水準言語ではなく、組み込み開発戦略だ」という文句には納得しづらい
こういう表現が入った記事は真面目に受け取りにくい
全体として「自分はLuaを長く使ってきたので、もう結論を出せる」という感じの文章だ
MicroPythonについては実際の経験があまりなさそうなのに、いくつか誇張された批判がある
たとえば「MicroPythonプロジェクトはシステムコードとスクリプト層が混在していて保守しにくい」という話には根拠が薄い
言語やプロジェクト管理・構造設計の影響かもしれず、原因は厳密に評価されるべきだと思う
この記事は実際の記事というより、Xedge Luaフレームワークの広告のように感じる
ただの広告だ
全体的に文章がchatgptっぽい
広告記事なら、人が書いたかLLMが書いたかはどうでもよく思える
コメントでも言われていたようにchatgpt感があって、読んでいてあまり楽しくなかった
PLDB Top 1000 のリストでは、LuaはMicroPythonより上位にある
この比較記事 ではGithubユーザーのSkipKaczinksiが、Luaのほうが概ね速いと見ている
Hackadayの記事 でもMichael PoliaがLuaは小さくて速いと述べている
Toit言語 はMicroPythonより30倍速いと主張している
Toitの創業者はV8の初期開発責任者だった
「embedded」と「embeddable」は区別する必要がある
MicroPythonは組み込みプラットフォームで使われるが、Luaのように既存アプリケーションへ統合する「埋め込み可能ランタイム」ではない
MicroPythonの目的は、従来のCランタイムを置き換え、最小限のCラッパーで初期化だけ行い、残りのビジネスロジックをMicroPythonスクリプトで書けるようにすることだ
Luaの
lua_Stateのように複数のインタープリタを同時に使える構造やサンドボックス機能はないつまりMicroPythonは、「ゲームエンジン内でスクリプトとして高速に反復開発する」用途より、「IoTボード上でPythonでセンサーデータを読む」用途に最適化されている
完全にそのままで使えるわけではなく、多少のグルーコードは必要だ
参考として embedポートの例 を見ればよい
Luaは組み込み用途でも素晴らしい言語だと思う
Luaベースの製品も良いと思うが、この記事の「なぜLuaがMicroPythonに勝るのか」という点には説得力が足りない
MicroPythonをCで拡張するのは思ったより簡単で、公式モジュール開発と同じ方法で外部モジュールも作れる
そのため、ファームウェアのカスタムビルド時にも難なく追加できる
また、Python系ライブラリ(numpyなど)が使えないという指摘もあったが、実際にはnumpyやscipyの一部を再実装したulabライブラリも存在する
個人的には聞いた話がマーケティング文句に感じられる
マイクロコントローラで十分なリソースがあるならmicropythonを使う
電力、メモリ、CPU制御が本当に重要なら、結局はC/C++を使う
ネットワーク関連の開発はC/C++だと難しいが、高速かつ安全にできる選択肢が少なかった（最近は内蔵TLS対応もだいぶ良くなっているだろうが）
LuaはCをうまく包んだような印象だ
ライブラリが豊富なら良いが、Luaツールチェーン、マイクロコントローラのツールチェーン、必要なライブラリをすべて自分で移植しなければならない負担が大きい
なので、これがマーケティング記事なら、Xedge 製品を使って外注してくれ、というメッセージなのだろうと思う
2350でも普通に動くとだけ短く触れておく
本当に「真剣に」組み込み開発でmicropythonやluaを使っている人がいるのか気になる
20年近くフリーランスとしてLua中心の組み込み製品を作ってきた
VOIP機器、ホームオートメーション、産業用ルーター、デジタルビデオレコーダーなど、さまざまな分野でLuaを活用している
通常、システムはLinuxカーネル、libc、Luaインタープリタ、そしていくつかの外部ライブラリで構成される
Luaアプリケーションのソースは3万〜10万行程度で、今の基準では「小さい」製品もある（フラッシュ8MB、RAM 64MBなど）
Luaはこうした環境でうまく動く
どれも現役製品で、顧客にとっても収益を生んでいる
LuaとCの連携は非常に簡単で、非同期処理についても、現代の言語がいまだに悩んでいるようなことをLuaは昔から解決してきた
言語はシンプルでありながら強力で、コルーチン、クロージャ、メタテーブルなどにより多様なパラダイムを使える
この規模のプロジェクトなら、今でもLua + C/C++の組み合わせを選ぶだろう
他のエコシステム（Elixir、Rust、Nim）も使ってきたが、Luaほど強力で柔軟な言語は見つからなかった
私たちはMicroPythonでclass B医療機器まで開発している
組み込みの世界は範囲が非常に広い
安全性に厳しい分野では規制上使えないが、試験装置などは規制に関係ないので使いやすいものを使う
IoT分野でも、結局はそれぞれが便利なものを使っていると考えればよい
MicroPythonはキューブサット（小型衛星）などの衛星ミッションでも実際に使われている
関連するカンファレンスやポッドキャストの事例もある
何千もの製品がLuaを内部的に使っているか、少なくとも一部で利用している
最近LuaJITも調べたが、過小評価されていると思う
「本格的な組み込み開発者」はたいていコンパイル言語を使うと思う
趣味ではArduino(Platformio)を使っている
マイクロコントローラではコンパイルしてフラッシュに書き込むのがすぐ終わるので、あえてインタープリタは必要ない
いつかC++を置き換えられる別のコンパイル言語も試してみたい
Raspberry Pi Picoでうまく動くおすすめの言語があれば知りたい
専門家というほどではないが、Rustが最も人気のある代替候補の1つだと感じる
トレンディで、C++の問題もかなり解決しており、ツーリングも悪くない
Zigも面白そうなので試してみたい
Raspberry Piは性能が高いので、システム言語でなくても動かせる
Kotlinも好きで、基本的にはJVMが必要だがネイティブビルドも可能だ
ただしPicoでGPIO制御をするなら、ファイルシステムを直接触る必要があるかもしれない（補足すると、PicoでのKotlinサポートは確かではない）
Nimもかなり良い選択肢に見える
関連資料は picostdlibのNimサポート を参照
Luaは本質的にずっと単純な言語だ
Pythonは「やり方は1つだけ」という信念を掲げているが、実際にはあれこれ詰め込んだ「万能ツール」のように感じる
そのぶん始めやすく、ライブラリも多いので簡単に開発できるが、
リソースが限られた小さな環境にはあまり向いていない
豪華な椅子を無理やり板から作ったイームズチェアに変えるようなものには限界がある
Pythonは簡単で、Luaは単純だ
「簡単さ」の問題は内部の複雑さが隠れていることであり、「単純さ」は利用者により多くの努力を求めることを意味する
Pythonはバージョン互換性が弱く、3.xから3.x+1へ移るときに問題がよく起きる
Luaも完璧ではないが、それでも複数のLuaバージョンをサポートする事例が多く、急激なバージョンアップを強いられにくい利点がある