Nim 2.0 - 命令型プログラミングパラダイムとマクロシステムに焦点を当てたプログラミング言語
(nim-lang.org)- ORCメモリ管理がデフォルトになる
- JavaScriptバックエンドが
int64とuint64にデフォルトで BigInt を使用し、JSバックエンドと連携するコードでこれらの型を使う場合は更新が必要になる可能性がある --experimental:strictEffectsが常に有効化され、コールバック引数にはeffectsOfアノテーションが必要になる- ドキュメントコメントのデフォルトのマークアップ言語が従来の
RstMarkdownモードから Markdown に変わり、{.doctype: Markdown | RST | RstMarkdown.}プラグマとmd2html・rst2htmlコマンドが追加される - 標準ライブラリの
os関連機能の一部がPath抽象化を使う新しいインターフェースとして分離され、std/oserrors,std/envvars,std/paths,std/dirs,std/files,std/symlinks,std/appdirs,std/cmdlineモジュールとして提供される - 複数の標準ライブラリモジュールが Nimble パッケージへ移され、
std/punycode,std/asyncftpclient,std/smtp,std/db_*,std/md5,std/sha1,std/sumsを使用する際はnimbleまたはatlasのインストールが必要になる - 名前なしの
block内で名前なしのbreakを使う方式は非推奨となり、将来のバージョンではエラーになる予定 "strictFuncs"の定義が変わり、refまたはptrのデリファレンスへの代入が禁止される- 変数のタプルアンパックは複数代入へ展開されるシンタックスシュガーとして扱われ、ネストしたタプルアンパックが可能になる
- top-down inference が複数の基本ケースで実装され、例の
seq[(float, byte, cstring)]初期化コードがコンパイル可能になる - オブジェクトフィールドにデフォルト値を指定でき、明示的に初期化しなかったフィールドにはそのデフォルト値が使われる
- 実験的な
strictDefsスイッチが追加され、変数を使用する前に明示的に値が代入されたかを検査し、let変数がちょうど1回だけ代入されたかも検査する - C++ 相互運用に
virtualプラグマと拡張されたconstructorプラグマが追加され、C++ コンストラクタと仮想メソッドに対応するコンストラクタおよび仮想 proc を定義できるようになる - Nimble 0.14 が同梱され lock-file をサポートし、ライブラリの保存場所が
$nimbleDir/pkgsから$nimbleDir/pkgs2に変更される
1件のコメント
Hacker Newsの意見
プロダクションで Nim を満足して使っている。主にデータ分析とレポート生成ツールを作っており、サーバースクリプトから呼び出すCLI実行ファイルとしてコンパイルしている。
Nimは高速で小さな実行ファイルを生成し、異種混在のJSONデータ構造やデータフレームライブラリが優れている。スタックを強く好む設計で、シーケンスやテーブルのような動的データ構造も、スタック上のポインタがヒープデータを指し、寿命はスタックフレームが管理する。
プログラム内に動的参照がほとんどなく、GCを気にしなくてよい。型システムは単純で合理的で、正しいコードへ自然に導いてくれる。デフォルトも参照透過性に近く、明示的に外れない限り、すべてが不変値渡しになる。
ジェネリクスは強力で期待どおりに動作し、統一関数呼び出し構文 は信じられないほど便利だ。特定の型を第1引数に取るプロシージャや関数を作るだけで、メソッドやインターフェースに相当するものを書けるため、そうした抽象化が不要になり、コード構造が単純でフラットになる。
以前Dを見つけたときのことを思い出すほど楽しく、むしろそれ以上だ。ほぼ100%がビジネスロジックで、余計なもののないネイティブコンパイルされる型注釈付きPythonを想像すると、Nimの体験に近い。
今回のリリースを試すのが楽しみだ。25年間プロとしてプログラミングしてきた立場から見ると、Nimはいくつもの世界の長所をうまく集めた言語 だと思う。
Pythonのように使いやすく、強い型付けだが型推論が優れており、デフォルトで高速かつ安全になっている。組み込みから高性能計算までよく合う。
UFCS、ジェネリクス、conceptsのおかげでOOPの利点を得つつ、整理のために脆いデータ関係を延々と積み上げる足場コードを書く必要が少ない。Pythonと違って、曖昧さはコンパイルエラーになる。
同じプログラムが、ほとんどの他の言語よりはるかに小さく、読みやすく、理解しやすいと感じる。裏で起きる魔法も多くないのに、デフォルトが筋の通ったものになっているからだ。
コンパイル時メタプログラミング は別格だ。別の方言や置換の小細工ではなく、言語設計の中核に入っており、使うのも直感的だ。たとえばファイルからカスタムのパースコードを生成しやすく、反復的なボイラープレートをなくせて、コンパイルも速い。
優れた型システムのおかげでPythonよりうまく書きやすい一方、性能はC/C++に匹敵し、小さく独立した実行ファイルとして配布するのも非常に簡単だ。
C、C++、ObjC、JSに対するネイティブABI、優れたFFI、良好なPython相互運用性も備えている。既存のエコシステムを書き直さずに直接使える。
ESP32向けにPython風の擬似コードを書いているのに、ほとんど労力なく非常に効率的で、望めばベアメタル制御もできる、と想像すればよい。同じ効率的な言語でバックエンドとフロントエンドの両方を持つWebアプリを書き、高速な弾幕ゲームを作りながら、明示しない限りスタック割り当てなのでGCを心配しない、という具合だ。
ビジネスの観点でも、Pythonのように素早くプロトタイプを作ったものが、すでにプロダクションに十分な速さと軽さを備えている点には大きな価値がある。会社の秘密兵器になり得る。
下層のランタイムであるC環境を自分で管理しつつ、その上でJSONのようなものが第一級にしっかりサポートされる現代的な高水準言語を使える点が本当に良い。Pythonが好きな立場でも、Nimはより良く、より優れたPythonだ。
特に開発中の JS相互運用性 がどれくらい快適なのか、Nimを単体ライブラリとしてJSにコンパイルするレベルを超えているのか知りたい。NimからブラウザAPIを直接呼び出したり、かなり単純なラッパーで呼び出したりできるのか？
それでも約4年間、大きな性能低下や必要な変更はなかった。
関係者全員とNimコミュニティ全体に祝福を送りたい。この10年間Nimを主言語として使ってきており、Nim 2.0の新機能をとても気に入っている。
いくつかは自分のプロジェクトにとって本当にゲームチェンジャーだ。たとえば オブジェクトのデフォルト値 は、理論上Norm[1]がオブジェクトインスタンスだけでなくオブジェクト型とも動作できるようにしてくれる可能性がある。新しく追加されたオーバーロード可能な列挙型がなければ、Karkas[2]はそもそも不可能だったはずだ。まだ作業中ではある。
[1] https://norm.nim.town
[2] https://karkas.nim.town
Nimはソフトウェアを書くには本当に良い言語だ。素早くデプロイし、楽しく開発しながら、非常に高性能なソフトウェアを作れる。
ただし経験上、まだ尖った部分もある。C/C++コンパイラとオプションを合わせる必要があり、エラーメッセージは非常に貧弱で、一部のライブラリは特定の設定やシステムでしか動かない。それでもコミュニティが小さいことを考えると、大きく責めるのは難しい。VS Code統合 はよく動作し、クラッシュはほとんどなかった。
Manning Publicationsがこれを見ているなら、最新のNimバージョンに対応した本が出るといいし、もっと読みやすいフォントの別の組版も検討してほしい。
Dominik Pichetaの素晴らしい本を買ったが、紙の本は細いフォントのせいで、眼鏡を作っても読むのがとてもつらく、PDFを使わざるを得なかった。ストロークやステムのようなフォントの構成要素が細すぎる。
年を取ったせいで自分の問題かと思い、K&R第2版の原本と比べてみたが、あの本はいまでも完璧に読めた。
RedditがNimをどう使っているかについて記事を書いている: https://www.reddit.com/r/RedditEng/comments/yvbt4h/why_i_enj...
ますます多くの大企業やスタートアップがNimを採用している。Nim 2.0にはとても期待しているし、貢献したすべての人に大いに感謝している。
逸話でもよいので、いくつか社名を挙げられるだろうか？
Nimはしばらくの間いちばん好きな言語で、ついに2.0がリリースされてとても楽しみ。今回の機能のかなり多くは、長く待ち望まれていたものだ。
唯一の欠点は、一番下で触れられているように、一部の同梱モジュールがサードパーティリポジトリへ移されたこと。大きな問題ではないが、SQLiteサポートがライブラリに組み込まれていたのは良かった。いくつかのデータベースをサポートし始めると、さらに多くのデータベース対応を求める圧力を受けることにはなるだろう。ただ、MD5とSHA1のサポートまで外れたのは少し驚きだ。
パスやロギングのサポートは標準にあるとよいが、ものによってはサードパーティであるほうが、よりよく進化できる。
関係者のみなさん、おめでとう。Nimは本当に興味深い言語だと感じる。
仕事で使う理由を探している。自分の仕事はモバイル周辺なので、JSやObjCにコンパイルできる点は魅力的だが、まだあれこれ触っている段階を超えられていない。Rustと比べると、始めるのはずっとシンプルだ。
Nodeアドオンを作る方式で動作する。WebアプリでNimコードを再利用したり、性能が重要なコードに使ったりするのに向いている。
数か月前にNimを見てみたが、機能面ではPythonにあったらいいと思うものが多かった。C/C++との簡単な相互運用、静的型付け、コンパイル、Android/iOS向けにクロスコンパイルして実行できる、といった点だ。
しかし言語が新しいわけではないのに、エコシステムが小さい。Pythonのnumpy、scipy、pandas、opencvのような高品質なライブラリが多くない。大手プレイヤーが採用していない点が惜しく、Unreal Engineが独自の新しいスクリプト言語Verseを作るより、Nimを採用してみていたらよかったのにと思う。
もう一つ惜しいのは、自分でアダプタを作らずにC/C++ライブラリと即座に相互運用できる機能だ。ヘッダーを取り込むだけで終わり、という形ならよいのに。
Rustとも同じように簡単な相互運用があるとよい。採用を増やせるし、Rustではモバイルデバイスでも大きな問題なく動作する高品質なクロスプラットフォームcrateを見つけやすいからだ。
数年以内に、より高速化したPython、GILの削除、nuitka、モバイル向けbriefcaseなどによってPythonが追いつくか、MojoがNimの立ち位置を奪ってしまうのではないかと心配している。
それでもNimには、Pythonとほぼシームレスに相互運用できるnimpyライブラリがある。つまりPyTorch、scipy、opencvをそのまま取り込んでNimから使える。
NimとZigを実際に使った経験があるのか気になる。両者がどのように似ていて、どう違うのか聞きたい。Nim v2基準で、両言語の慣用的なWebサーバーベンチマークも見てみたい
Zigも良く、オプショナル値のサポートとエラー処理のアプローチは気に入っている。しかし、
!?[]u8のようにuint8のマルチポインタに対するオプショナルポインタのエラー合併を表す騒がしい構文には抵抗があった動的割り当てが必要なほとんどのコードでアロケータを用意して渡さなければならないことも、中核ロジックの妨げになる。文字列連結やフォーマットのような小さな作業も一仕事になる
Zigには動的ディスパッチもないため、多相的なコードを書きにくく、何らかの形のダックタイピングで回避しなければならない。結局、Zigは自分には合わないと判断した
[1] https://github.com/khaledh/axiom
[2] https://github.com/khaledh/axiom-zig
例を見ると、ほぼ同じコードを複数の言語で書いているので大枠は分かるが、言語機能の面では表面をなぞっている程度だ。たとえばZigの例はcomptime機能を使っていない
Zig: https://github.com/floooh/sokol-zig/tree/master/src/examples
Nim: https://github.com/floooh/sokol-nim/tree/master/examples
Odin: https://github.com/floooh/sokol-odin/tree/main/examples
Rust: https://github.com/floooh/sokol-rust/tree/main/examples
Zigはより退屈だが、それはすべて良い理由によるものだ。個人的にOSをNimで書くことはないが、Zigは成熟すればその用途に素晴らしいものになると思う。私は組み込みソフトウェアで使い始めた
NimはCLIツール、サーバーアプリケーション、ひょっとするとGUIアプリケーションやゲームにも使うと思う
Zigチームは全体のコンパイラインフラにはるかに多くの労力を注いでいるように見え、経験上、本当に印象的だ。素晴らしい革新がある
ZigはCの後継であり代替という特定のニッチを狙う、はるかに焦点の絞られた言語で、その目標を見事に満たしている
言語の好みは、現在使っている言語が満たしてくれない個人的な必要や欲求によると思う。私はCの後継を目指すやり方が興味深く、Zig側に落ち着いたが、他の人がNimを選ぶ理由も理解できる