次世代言語27 Nim Zig Pony Carbon Gleam

2023/02/17(金) 08:18:49.77

FirefoxもWebAssemblyのガベージコレクション機能を実装中であることが明らかに
https://www.publickey1.jp/blog/23/firefoxwebassembly.html

2023/03/18(土) 09:36:05.92

GPT-4で作られた新言語が出てきたな
これからは生成AIが言語を生成する時代かも
https://lukebechtel.com/blog/gpt4-generating-code

2023/03/25(土) 22:53:18.43

所詮トランスパイルするだけの言語は終わる
TSやKotlinなど

2023/03/26(日) 09:50:29.12

C++は元々トランスパイルするだけの言語だったけど未だに終わってないぞ

2023/03/27(月) 14:32:28.74

>>120
直接コンパイルしているから終わらなかった
クラスを追加しただけのように見えてバイナリの速度も若干違うし
今や別物という扱いかと

2023/03/27(月) 21:45:38.89

Types as Commentsが通ったらTypeScriptは安泰

2023/04/08(土) 09:14:03.61

SafariもWebAssemblyのガベージコレクション機能の実装に着手。Technology Preview 167で明らかに
https://www.publickey1.jp/blog/23/safariwebassemblytechnology_preview_167.html

2023/04/13(木) 09:31:47.71

王者Pythonのトップ陥落もあり得るか？　C++とJavaが猛追　2023年4月言語人気ランキング
https://atmarkit.itmedia.co.jp/ait/articles/2304/13/news044.html

TIOBE SoftwareのCEOを務めるポール・ジャンセン氏は、2023年4月に「Zig」が46位となり、初めてトップ50入りしたことについて、次のようにコメントしている。
「昨今では、膨大な量のデータを高速で処理する必要が生じていることから、高性能なプログラミング言語が人気を呼んでいる。CとC++はトップ10の上位を維持し続け、『Rust』もトップ20に定着しつつある。こうした中で、CとC++のもう1つの注目すべきライバルであるZigも、トップ50に入ってきた」

「Zigは非常に実用的な言語であり、C／C++プログラムとスムーズにやりとりする。そのため、C／C++からZigへの移行は簡単だ。Zigは、CとC++の優れた機能(オプション型で強化された明示的なメモリ管理など)を全て備え、あまり優れていない機能(前処理など)は放棄している。トップ50入りは成功を保証しないが、少なくとも注目に値する第一歩だ」(ジャンセン氏)

2023/05/06(土) 21:37:15.59

待望の新言語

Mojo &# 128293;: Programming language for all of AI
https://www.modular.com/mojo

2023/05/07(日) 10:45:52.48

最終的にPython互換を目指すということだからPyInstallerの軽量な代替になってくれないか期待したいところだけど
まだclassもサポートされてないのね。

2023/05/07(日) 10:46:24.88

Nimじゃ駄目なんですか？

2023/05/07(日) 17:32:47.00

>>128
いい言語だと思うが、
開発者少ないのに複数言語へのトランスレートは厳しいよ。
Cのみに絞るか、せめてCとJavaScriptくらいに絞るべきだと思う。

2023/05/08(月) 00:18:12.54

Mojoの発音はそのまま喪女でいいんか？

2023/05/09(火) 15:00:49.20

AIソフト開発向け言語Mojo発表
―Pythonの使いやすさとC言語のパフォーマンスの組み合わせ
https://gihyo.jp/article/2023/05/mojo

すべてを1つの言語で記述
Mojoは使いやすいPythonの部分と、C、C++、およびCUDAを必要とするようなシステムプログラミング機能が組み合わされている。自動チューニングとメタプログラミング機能を備えた次世代コンパイラテクノロジーによって、プログラムに型を追加することでパフォーマンスが大幅に向上し、Rustのようなメモリ安全性をもたせることができる。

Pythonをはるかに超えるパフォーマンス
MojoはすべてのAIハードウェアへのアクセスを可能にするMLIR(Multi-Level Intermediate Representation)を使用している。これにより、Mojoはスレッディング、およびTensorCoreやAMX拡張機能といった低レベルのハードウェア機能を使ってアクセラレーターを利用できる。同社によると、Mojoがハードウェア機能を最大限に活用し､マンデルブロのような数値アルゴリズムを実行する場合、Pythonよりも35,000倍高速に動作するという。

Pythonエコシステムを利用可能
Mojoは単にPythonライクな言語というだけではなく、Numpy、Pandas、Matplotlibなどのメジャーなライブラリをはじめ既存のカスタムPythonコードを含むPythonエコシステムへのアクセスも提供される。

2023/05/10(水) 00:22:05.48

Mojoは早くOSSにしろよ

2023/05/15(月) 06:04:50.19

オフサイドルールは書かされてる感が強くて嫌いなんだけど、世間的には好意的なのか

2023/05/15(月) 19:15:35.36

>>133
オフサイドルールに限らず文脈依存文法は自動化が難しくなるのでセンス悪いと思うけど、ブロックは視覚的に認識しやすいから人気あるんだよなぁ。
YAMLみたいに併用できるならまだマシだけど。

2023/05/15(月) 22:35:11.34

オフサイドルールって文脈依存文法か？

2023/05/19(金) 12:22:48.77

>>135
前後のインデントによってブロックが決まるから文脈依存じゃね？

2023/05/19(金) 18:44:24.43

YAML拡張してifとかの制御構造入れるやつもいるからな。

2023/05/19(金) 22:29:50.83

>>136
後ろのインデントには依存しないんじゃね

2023/05/20(土) 12:03:13.56

オフサイドルールでブロック表すのも、ブレースでブロック表すのも、構文解析的にはは同じことでしょ

2023/05/20(土) 16:28:20.57

インデントの深さに依存するから、フレーズみたいに「現在のブロックを閉じる」だけの操作では済まない。
オフサイドルールのプッシュダウンオートマトン実装例あったっけ？

2023/05/20(土) 16:36:35.19

構文解析的にはほぼ同じ

間違ってても検出できない(ケースが多い)
オートフォーマットができない
のがデメリット

2023/05/20(土) 16:40:15.10

>>141
PDAの実装は？

2023/05/20(土) 16:43:18.84

前処理でブレース挿入して処理するから実際のパーサ部分は似たようなものって言いたいんだろうか

2023/05/20(土) 16:48:04.32

>>143
そりゃ乱暴すぎる。

2023/05/20(土) 18:06:52.09

>>142
GHCとか

Pythonとかはlexerの段階でDEDENTトークンを生成してるから>>143の言う通り

2023/05/21(日) 01:17:46.07

https://docs.python.org/3/reference/lexical_analysis.html#indentation
Pythonの場合はここに書かれてるようにlexerの時点でスタックを使って処理できるという仕様だけど
他の言語のオフサイドルールはもっと複雑になるの？

2023/05/21(日) 15:37:31.99

>>146
lexerの能力は高いだろ。
PDAは(Lexerとかと比べると)大したことできないよ。

2023/06/12(月) 15:08:29.37

Zigの単行tryとcatchは馴染みないから怪訝してたけど使ってみるとtry-catchブロックよりフローが明確になって良いね
これって他言語にもある言語仕様なのかな

2023/06/12(月) 18:10:45.80

>>148
つアダムタッチ

2023/06/13(火) 16:03:31.28

NimってPythonのライブラリにアクセスしてfor文回すともはやNimに求めてた性能ははpythonよりになってしまうのでは？型推論できないからねぇ。

2023/06/13(火) 18:32:28.49

>>150
型推論は無関係な気がする
単にPythonライブラリの性能に律速されるだけ

2023/06/14(水) 07:40:07.84

pythonのダメ記法を捨てられるだけでもメリットデカイね。

2023/06/14(水) 11:21:50.21

for を python で描くと遅い
for は Nim で描いて
中身だけ python ならまだマシ
もちろんネイティブの速度ではないがそんなの Nim だからじゃなくて
C++ でも Rust でも python 呼べば同じ結果になるぞ

2023/06/14(水) 14:43:32.26

>>153
for文をNimで書いて、中身をpythonにして実行速度を計測してみたらpythonオンリーとあまり変わらなくてがっかりしたという経験がある。ただ、自分のコーディングが悪かった可能性もあるけど。

2023/06/14(水) 16:19:12.32

>>154
中身の計算コストがforループ自体のコストと比べて大きければNimでもpythonでも変わらないんじゃない?

2023/07/04(火) 03:53:42.95

病∞！！！！
症∞！！！！！
漠∞！！！！！！
西∞！！！！！！！
卵∞！！！！！！！！
多∞！！！！！！！！！

2023/07/04(火) 09:47:08.65

待望の新言語

Apache Sparkのための新しいプログラミング言語としての「英語」
https://www.databricks.com/jp/blog/introducing-english-new-programming-language-apache-spark
Data & AIのサミットで発表された新機能：DatabricksのEnglish SDK for Apache Sparkを試してみた
https://qiita.com/maroon-db/items/89f7a1aae11a112f9700

2023/07/20(木) 05:33:25.43

Zig 0.11.0のマイルストーンが7月17日から8月3日に延期されてしまった
やはり未解決のissue多すぎて再延長もあり得るかこれは

2023/07/25(火) 11:52:50.13

>>158
1.0も遠のいた？

2023/07/26(水) 00:31:41.04

>>159
1.0も遠のいた…

今回のリリースは目玉のasync関連も見送りっぽいし内容的には実質0.10.6くらいなイメージ
残ってた300前後のissueは未解決のまま公式Newsのとおり0.11.1から1.0.0の各マイルストーンへ再分配中
（大半を単に先延ばしするだけなのでそのまま1.0もズレる）

そんな中で脱LLVM構想も再浮上してるし1.0到達は当初の3年後どころか5年以内目処も危うい

2023/07/27(木) 10:40:07.68

>>160
おぅ、、、orz

2023/08/01(火) 22:10:07.65

しばらくスレに来なかったらスレタイの言語知らんのばっかになっててわろた

2023/08/01(火) 22:28:49.01

Nim 2.0が出たっぽい
しかしぜんぜん話題になってないな…

2023/08/01(火) 22:52:38.66

そもそも、nimを宣伝しているようなblog記事以外で見かけたことがないしな。

2023/08/02(水) 01:14:41.81

Nimを使っている組織一覧:
https://github.com/nim-lang/Nim/wiki/Organizations-using-Nim

2023/08/02(水) 06:48:11.72

>>165
RustよりもNimは実用的っぽいな

2023/08/02(水) 09:34:06.72

nim良いよね

2023/08/02(水) 21:45:09.21

本当、nimの話題って「nimは良い」しかないよな。

2023/08/02(水) 22:26:10.11

nim以外ほとんど何か創ってないからな

2023/08/03(木) 11:22:28.95

Nim 2.0がリリースされました。
https://nim-lang.org/blog/2023/08/01/nim-v20-released.html

2023/08/25(金) 08:02:23.50

JavaScriptランタイム「Bun」がバージョン1.0に到達へ、9月7日にローンチイベント開催
https://www.publickey1.jp/blog/23/javascriptbun1097.html

主な開発言語としてZigを採用し、メモリ管理などを含む低レイヤでの実装を実現することで、Node.jsやDenoよりも高速な動作を実現していると説明しています。

2023/08/25(金) 11:01:59.13

>>171
v1.0の目玉だったWindowsネイティブサポートは結局実現できないままでリリース押し切ることにしたのか

2023/08/25(金) 12:13:30.13

Rust製のDeno遅すぎｗ
https://dev.to/codesphere/bun-the-new-javascript-runtime-competing-with-deno-and-node-115d

2023/09/02(土) 16:19:08.80

それベンチによってはNodeが勝ってたりDenoが勝ってたりするから当てにならん

2023/09/02(土) 16:39:16.86

>>171
元言語のzigはいつ1.0になるんですかねぇ

2023/09/02(土) 18:20:03.74

>>174
どのベンチ？ｗ

**デフォルトの名無しさん** (ｽﾌｯ Sd1f-ETx6) · 2023/09/07(木) 10:00:28.15

雨の日にうっかりベンチに座るとパンツがビショビショ濡れ濡れ

2023/09/12(火) 20:59:08.32

>>131　続報

Pythonの高速なスーパーセットをうたう新言語「Mojo」、コンパイラなど公開、ローカル環境で利用可能に
https://www.publickey1.jp/blog/23/pythonmojo.html

2023/09/21(木) 00:39:19.15

Zigに頑張ってほしい

2023/09/22(金) 01:57:24.98

Zigはかなり期待してるので頑張って欲しいな
長いこと指摘されてるissueのclose速度が1日平均5件なのに増加速度は1日平均10件で
ずっと次のリリースにたどり着けないよ問題を結局どう解決する方針にしたんだろう

2023/09/22(金) 12:28:56.47

>>180
こんなんでBunはよく1.0にしたな。

2023/10/04(水) 15:32:29.96

https://harelang.org/
（海外の）FOSS、ミニマリスト、アンチRust界隈で流行ってる言語 Hare
C言語プログラマのために作られたとのこと
メモリ管理は自前だがいろいろ安全対策がされてるっぽい
Windows, Macは対応しないと宣言

2023/10/04(水) 16:37:22.64

Cの代替言語オーディン
https://odin-lang.org/

2023/10/04(水) 16:42:29.89

Cの代替言語オーディン
データ指向、カスタムアロケータ
https://odin-lang.org/

GitHubリポジトリ
https://github.com/odin-lang/Odin

2023/10/05(木) 17:09:32.57

Are

2023/10/30(月) 01:15:43.08

ちょっとOdin触ってみた。
Zigより気に入った。
最適化がまだC/C++より弱いからエッジケースではC/C++,Rustにはパフォーマンスかなわないようがた、ぶっちゃけRustよりOdinのほうが書きやすい。

2023/11/02(木) 09:20:24.55

WebAssemblyのガベージコレクションが正式機能に、最新版のChrome 119で。Firefoxも今月リリースのFirefox 120で正式機能になる見通し
https://www.publickey1.jp/blog/23/webassemblychrome_119firefoxfirefox_120.html

2023/11/21(火) 03:00:21.16

zigのcompiletはCのatoi、atofみたいなのを1関数にまとめれるということ？

2023/11/21(火) 03:09:25.53

wasmはどうせgcを採用するんだろうなと思ってたがやっぱりか
jdkと変わらん

2023/11/21(火) 03:12:08.32

wasmは初期の頃jdkと何が違うの？と言われてた
jdkはバグが多いからとか説明してたが、実際そうでもない
なぜかその界隈の人達が漠然とjavaを嫌ってるだけだな

**188** (ﾜｯﾁｮｲ 22f1-rrr/) · 2023/11/21(火) 04:46:48.83

compiletじゃなくてcomptimeだった

2023/11/21(火) 05:27:43.98

zigのジェネリック、やりたいことは分かるんだけど構文がよく分からん
https://ziglang.org/documentation/master/#Generic-Data-Structures
fn List(comptime T: type) type {
return struct {
items: []T,
len: usize,
};
}

// The generic List data structure can be instantiated by passing in a type:
var buffer: [10]i32 = undefined;
var list = List(i32){
.items = &buffer,
.len = 0,
};
List()の返値はList型じゃなくてi32型なの？
でもi32の変数があったときにいつもその構造体への初期化処理みたいなのかけるわけじゃないでしょ。
でもfn Listの宣言によれば返値の型はtype=i32なんでしょ？謎すぎ

2023/11/21(火) 05:34:22.13

List()の型は匿名のstructだな
でもじゃあこれはなに？っていう
fn List(comptime T: type) type
引数に入力されたtypeの型が返値の型じゃないの？

2023/11/21(火) 10:29:25.70

>>193
>>192の例で説明すると、引数として渡されたtypeはitemsフィールドの要素の型。
戻り値のtypeは匿名structの型。

引数の方のtypeは、匿名struct内の関数の引数や戻り値、その関数の戻り値を組み立てるための型引数などにも使える(文字で書くとややこしい)。

戻り値の方のtypeは、builtin.Typeでサポートされてるものが返せる。

あと引数に渡されるtypeは、戻り値を組み立てる型の中で、例えば「T.foo()」と書くことでT型はfoo関数の存在を制約として与えることもできる(foo関数を持たない型が渡されたらコンパイルエラー)。

2023/11/21(火) 11:43:47.98

ありがとう分かった。
typeはzig標準型全体を指すものということか。
任意の標準型を受け取って、任意の標準型を返す総称型関数ということね。

ダックタイピングも分かった。
宣言じゃなくコードの内容から推論してコンパイルエラー出してくということね。

2023/11/21(火) 14:41:07.08

チュートリアル読んでるけどzig良い。
Cの代替としては最有力かな？
世の中はメモリ安全のためにRust推奨なんだろうけど。
本当はそっちに進んじゃいけない、と思ってる。

2023/11/21(火) 21:16:37.31

Zigのマイルストーン見ると先送りしてきたv0.11.1のバグ180件以上残ったままv0.12.0側のissueばっかり片付けてるな
これはついにマイナーバージョンアップ近づいて来たのかな

2023/11/22(水) 01:53:36.06

linux kernelがrustのサポートを確定したという記事を読んだ。
だったらrustなのかなあ。googleもandroidをrustで書くらしい。
rustなのか。

2023/11/22(水) 03:30:03.94

俺はzigやってこう・・・。

2023/11/22(水) 07:56:27.67

いや、やっぱりrustかなあ。
将来のベアメタルプログラマーは抽象的な言語概念から逃げられないね。
そうなると、初学者はむしろマネージド言語から入るのかな。

2023/11/22(水) 12:13:14.04

Cの後継としてZigは結構ありだと思うけど、
Cが残ってる分野ってISO標準とか組み込みベンダーサポートとかが必須な分野が多くて
Zigがそこまでたどり着くには10年とかかかりそうだよな…

2023/11/22(水) 12:17:19.10

Odinはいかが？

2023/11/23(木) 09:55:21.62

>>196
わかります

2023/11/23(木) 09:55:57.11

>>201
10年待てない人はNimで

2023/11/23(木) 10:39:32.37

nimは概要を読む限り全然いいと思えない。
C++をさらに悪化させたような言語じゃないの？

2023/11/23(木) 10:41:14.18

nim使うならC++で良いはずだよ。既に多用されてて信頼性あるし。

2023/11/23(木) 10:53:59.84

odinのアイデアはほぼzigと同じじゃないか？
zigの方が先に出てきて、その直後にodinが出てきたようだ
メモリ安全と言われているようだが全くそうではないというレビューも見かけた。
後出し追いかけ言語で政治力とエンジニアリングのパワーで優っているのがodinということじゃないか？
Cの代替がzigのようなものであるべきという着眼点を最初にもたらしたのはzigじゃないだろうか
他にそういう方向性の言語がzigより先にあったのだろうか

2023/11/23(木) 11:21:12.37

zigのwikipedia読んでたらCからの変更点という観点でzigが説明されてる。
Cを出発点としていくつかの改善点を加えた言語というのが重要なんだ。
その中でもメモリ安全とcomptimeによる類似関数をひとまとめにするというアイデアが重要と思う。

2023/11/23(木) 12:21:13.00

fn () err!val
みたいな共用体を返す構文はCのerrnoとかC#のoutとかの代用になるのかな
共用体はenumと連携させてswitchで使えるようだから中身に応じて処理を分けれる
実際使ってみないと分からんが、まあ学習は順調に進むし良い印象がある

2023/11/23(木) 12:50:09.22

>>205
>>206
Nimのどこがダメなんでしょうか?
少なくともC++よりシンプルな言語だし読みやすく書きやすい言語だと思うのですが。

2023/11/23(木) 13:59:38.28

NimはまぁPythonっぽい構文が好きな人にはいいかもねって感じなだけで
わざわざ他言語から乗り換えるような特徴がないんだよね

2023/11/23(木) 14:59:02.66

NimはJavaとかC#みたいなクロスプラットフォーム性があるわけではないし
Cが使われているような領域で使えるものでもない
だからそういった領域では論外

C++と競合するが、置き換えれるほどの何かがない
恐らくC++から置き換えるならRustになる

という認識。Nimの言語仕様がJavaやCと比較して優れてる！とか言ってみても仕方ない。
競争相手になり得ない。
C++かRustと比較して総合的に優れてると言えたら重要なものになるだろうけど。

2023/11/23(木) 15:03:11.78

nimはgcありとなしモードあるけどライブラリちゃんと動くの？
gcありじゃないとほとんどのライブラリが動かないということになるなら、
C++にもRustにも到底比較対象にならない
どの領域に入るつもりなんだという印象

2023/11/23(木) 15:16:17.32

要するに、総合的に優れてるように思えても「あらゆる領域でちょっと負ける言語」は使われない。
戦略は？ということ。

C#やjavaと比較→ネイティブコード作れる！エレガントな文法！→java使ってる人達には全くどうでもいいです
Cと比較→たくさんの抽象的な言語概念！大規模開発に強い！→C使ってる人達には全くどうでもいいです
C++やRustと比較→GCがあって簡単にコーディングできるぞ！→彼らにはGCは不要あるいは邪魔です

2023/11/23(木) 15:46:50.74

NimのライバルはZigじゃなくてV言語だと思う
ベターCっぽいけどCの置き換えできないしC++にも届かないって立ち位置の点でね
(文法もC系ではなくPython系って側面も込み)

2023/11/23(木) 18:39:43.19

>>207
＞odinのアイデアはほぼzigと同じじゃないか？

違うな。
zigはcをそのまま取り込む感じだが、odinはあくまでもodin。
cとの連携もzigみたいにそのままでは無い。

＞メモリ安全と言われているようだが全くそうではないというレビューも見かけた。

odinはメモリ安全なんかじゃ全くないぞ。別なもの見てないか？

＞後出し追いかけ言語で政治力とエンジニアリングのパワーで優っているのがodinということじゃないか？

政治力っていったいなんのことよ。
イチャモン着けたいだけか？

＞Cの代替がzigのようなものであるべきと

「zigのようなものであるべき」って言ったらzigしかないじゃん。
言ってることがメチャクチャ。

2023/11/23(木) 18:51:14.02

>>212
＞NimはJavaとかC#みたいなクロスプラットフォーム性があるわけではないし

JavaとかC#はマルチプラットフォームという。
マルチプラットフォームとクロスプラットフォームの違いは自分で調べてね。

＞C++と競合するが、置き換えれるほどの何かがない

GCあるから置き換えは無理だね。
使わないようにも出きるし、その方向に向かってるけど既にあるライブラリがGC前提だったりするし。

nimはトランスレーター系で、出力がcだったりjavascriptへだったりして、そこでリソース消費しちゃってる感あるのがな。
かつてhaxeという言語があったが結局流行らなかった。

2023/11/23(木) 18:53:19.90

>>208
zigはメモリ安全なんかじゃねーぞ

2023/11/23(木) 18:54:51.91

odinについて知りたかったらhacker newsを見てくれ。

2023/11/23(木) 19:18:19.30

>>209
Error Union はペイロードを持てないので、erronoと同じと見て差し支えない。
ニュアンスとしてはgo言語のエラーと値を返すスタイルが近いかな。
go言語と違って、エラーがなければ値が保証される(毎度のエラーチェック不要)のと、エラーハンドリング不要ならtryで呼び出し元に押しつけられる楽さはある。

C#のTry～メソッドのout引数を戻り値で扱えるが、zigはポインタ渡しもできるのでさらに強力。

2023/11/23(木) 19:25:49.77

>>218
deferの使用を癖づけしておけば、おおむね安全だから・・・。

動的確保したu8のスライスを別の変数にも持たせ、
元の変数の破棄によるダングリングポインタで自分の足を撃ち抜くくらいかな？
よく事故るところは。

2023/11/23(木) 19:28:51.80

>>217
haxeは構文マクロ書きやすくて好きなだけに悲しい

2023/11/23(木) 21:24:37.29

>>222
haxe知ってる人がいて嬉しい。
マイナーで終わったのが残念。

2023/11/23(木) 22:52:57.39

>>212
おまえなんも判ってないな

>Cが使われているような領域で使えるものでもない

使えるだろ

>C++と競合するが、置き換えれるほどの何かがない

NimはC++とは競合しないC++と共存する

>恐らくC++から置き換えるならRustになる

RustにCの置き換えはあっても
RustがC++を置き換えることは無いわ

2023/11/23(木) 22:57:33.95

>>215
>文法もC系ではなくPython系って側面も込み

事実誤認だ
よくそんな平気で嘘が吐けるな

2023/11/23(木) 22:58:53.23

>>214
君は表面的なところしか観れないhusianasann

2023/11/23(木) 23:16:34.09

Nim言語はC言語やJavascript言語を出力するのでそれらの言語が動くプラットフォームならほぼ動く。
Raspberry Pi zeroやTermux上でもNimコンパイラが動くし
Goodboy GalaxyっていうNim言語で書かれたGame boy advanceで動くゲームもあるしRaspberry Pi Picoで動くプログラムも作れる。

GC付き言語だとすべてのオブジェクトがヒープに作成されると勘違いする人がいるけどNimでもC++のようにオブジェクトをヒープに確保するかスタックに確保するか選ぶことができる。
NimではGCの代わりにARCっていうメモリ管理方法を選択できてこれはC++のshared_ptrやRustのRcと同じ参照カウンタ方式でヒープを管理する。
なのでARCが使えるかどうかは循環参照があるかないかで決まる。
Nim2.0からはORC(循環参照があっても解放できるようにARCに機能を追加したもの)がデフォルトになっている。

Nimのマクロは式や文のASTを受け取ってそのASTを読んだりASTを生成して返すのでいろんなことができる。
例えばNimの標準機能にあるstrformatモジュールを使えばfmt"x*y={x*y}"のように文字列の中の{}で囲まれた部分に直接式を書くことができる。
fmtマクロはコンパイル時に文字列リテラルを読んで"x*y="という文字列にx*yの結果を文字列化したものを付け足すコードを生成する。
C++やRustで言語に備わった機能だけでfmtマクロのようなものを作ることは無理じゃない?

2023/11/24(金) 00:02:43.09

俺も>>211と同じような印象を持ってるけど、一方でこうやって熱心に布教してくるユーザーが目につくんだよね。
温度差が面白い。
pythonスレで宣伝するのはさすがにスレチだからやめてほしいが。

2023/11/24(金) 00:24:17.65

>>218
rustほどではないけどcと比較すればかなりメモリ安全な言語

2023/11/24(金) 00:45:17.10

>>227
nimのマクロはASTいじれるから強いよな。
俺もnim好きだし。
一方で >>217 で書いたようにまだライブラリに旧いGC使ってるの混じってるのと、CだけじゃなくJavaScriptへのトランスレートとかして開発リソースを消費してるのが懸念。

あとRustのマクロならたぶん近いことできるんじゃないかね？
あれは hygienicマクロうたってるし。ただ複雑過ぎるとも思う。

2023/11/24(金) 00:56:07.29

C++もGCありの開発可能だからnimはC++と近いのでは？
主にC++が使われてるのはミドルウェア、webブラウザ、ゲームとかだけど
いずれもGCが動かない環境ではない

2023/11/24(金) 01:04:25.73

nimがcと競合すると考えるなら、
nimがカーネルやデバドラで使われると思うのか

2023/11/24(金) 08:28:38.02

>>228
熱心に布教するユーザが目に付くというのがまさにとりたてて特徴がないということの証明になっているかもね
他言語だと多少気にいらなくても〇〇のために使っている、となるがNimはその思想に完全にマッチした人しか残っていないという

2023/11/24(金) 13:19:56.18

Nimユーザーから見るとRustなどの他の言語はいちいち;とか{}を入力したりそれらの文字で少し見づらくなるがそれを大きく上回るメリットがあるとは思えない。
RustやC++やZigで書いたコードがNimより速くなるわけではない。
NimはGC使ってるから遅いみたいに言う人はいるがヒープメモリを使わないようにするとかヒープメモリをループの外側でのみ確保するようにすればメモリ管理のコストがボトルネックにならない。
どうしてもヒープ確保が必要になる場合でもARCかORCを使えばshared_ptrやRcと同じように参照数が0になったら即解放するようになる。
Rustはメモリ安全だというが普通にNimのコードを書いていてメモリ関係のバグで困ったことは無い。
Win32 APIとかLinuxのシステムコールを呼ぶときはポインタを使うからメモリ安全性に気を付けないといけなくなるがRustでもそういう関数を呼ぶときにはunsafeコードを書かないといけないらしいし。
C/C++はライブラリが豊富にあるがNimからその殆どが使える。
NimはCかC++を出力するからCのマクロとかC++のテンプレートクラス/関数まで呼べる。
C++言語はC++14,17,2xと言語仕様がどんどん複雑になっているから完全に対応は難しいかもしれんが。

2023/11/27(月) 09:37:28.94

>>234
Rustのいいところはコンパイルが通らないから誰が書いてもある程度同じようなコードが出来上がることだと思う
とても極端な話すればレビューもいらない
めちゃくちゃチーム開発に向いてる
Nimは既存の資産を活かせるかつ自由度が高いから小、中規模向けなのかな

2023/11/27(月) 12:16:24.67

>>235
> 誰が書いてもある程度同じようなコードが出来上がる

これは幻想がひどい気がする。コンパイル通らない時にどう解決するか結構個性が出ると思う。
無限に unsafe 指摘されて切れたwebフレームワークのメンテナ居なかったか？

2023/11/29(水) 06:07:56.97

>>236
>無限に unsafe 指摘されて切れた
このひとのことかな
https://wolfbash.hateblo.jp/entry/2017/07/30/193412

2023/11/29(水) 12:33:39.58

>>237
そこまでレベル低い人の話はしていない。

掘り直したら actix-web だった。
以下のページが日本語で問題まとまってる。
ttps://scrapbox.io/nekketsuuu/actix-web%E4%BA%8B%E4%BB%B6

2023/12/06(水) 14:35:16.69

Rust2006年、Nim2008年(or 2005年生誕説)、Go2009年にそれぞれオープン化して同期の中でNimの言語コンセプトだけ主要な席を取れなかったのはおかしい。
Nim好きユーザーとしてはここからの巻き返しを超絶妄想してる。
現世代言語の仕様に引けを取ってないし8月に本体2.0.0に上がったし周辺パッケージも育って熱心な布教者まで揃ってるのにそもそもの認知度が低すぎるままなのは不思議でならない。
いまNimで書いてる人たちは何用途で使ってる?まずは特定用途で知名度を上げることに突破口があると思うんだよね結局は。

2023/12/06(水) 15:24:48.70

>>239
個人で始めたか、法人所属の人が始めたか。
pythonはメジャーになるまで30年以上かかってる。
法人の後ろ楯あると早いね。
何かキラーアプリがでることを期待してる。俺はそんなスキル無い。

2023/12/06(水) 15:53:12.48

>>239
同期だからこそ、潜在ユーザをみんなGoとRustに取られた感はある
企業がついてない分エコシステムとかはどうしても負けるし

あとはC系の人にPython風構文はあまり歓迎されないというのはあるかも
MojoみたくPythonユーザを直接取りに行ったほうが良かったかもね

2023/12/06(水) 16:40:19.51

>>240
30年以上は言い過ぎ？30年近く。

2023/12/06(水) 18:39:52.78

pythonは2000年代初頭にはperlよりメジャーになってただろ。

2023/12/08(金) 03:22:50.77

やっぱりrustなんだろうね
OSも徐々にRustになってくっぽい
主要OSが完全に移行するには100年かかるだろうけど

2023/12/08(金) 05:55:14.09

LinuxカーネルのコードがRustに置き換わるとコンパイル時間が大幅に増加しないか心配。
Cだけのカーネルでもビルドに一時間くらいかかるのに

2023/12/08(金) 09:48:35.93

コンパイルよりCargoのdb更新に時間掛かってるんだよないっつも

2023/12/08(金) 23:03:52.41

>>246
それいくつか前のバージョンで改善されたやつじゃなくて？

2023/12/13(水) 08:12:56.25

待望の新言語

WebAssemblyへのコンパイルだけに特化した新言語「Onyx」登場、Wasmerが発表
https://www.publickey1.jp/blog/23/webassemblyonyxwasmer.html

2024/02/06(火) 21:17:51.46

待望の新言語

Introducing Pkl, a programming language for configuration
https://pkl-lang.org/blog/introducing-pkl.html
Appleがシステム構成のためのプログラミング言語「Pkl」をオープンソースでリリース
https://gigazine.net/news/20240205-apple-pkl/

2024/02/08(木) 14:58:56.60

>>249
DBスキーマみたいなストアドプロシージャ内蔵の静的型付けYAML作ってるってのはこれだったのか
トランスパイラ方式にしたんだな

2024/03/29(金) 21:11:42.51

Erlangランタイムの静的型付け関数型言語Gleamがバージョン1.0に到達
https://www.infoq.com/jp/news/2024/03/gleam-erlang-virtual-machine-1-0/

2024/03/29(金) 23:02:59.73

スレチかもしれないけど、この言語そのものというよりは、作者の目指す未来の言語像が可能性を感じる。

Viscuit
https://www.viscuit.com/
言語そのもののイメージとしてはProlog版Scratchから、さらに子供に分かりにくい機能を外したもの。

感銘を受けた記事を２，３貼っておきます。

理想的なプログラミング言語
https://devroom.viscuit.com/2018/10/06/post-1615/

言語の進化とプログラミング教育
https://devroom.viscuit.com/2017/02/07/%e8%a8%80%e8%aa%9e%e3%81%ae%e9%80%b2%e5%8c%96%e3%81%a8%e3%83%97%e3%83%ad%e3%82%b0%e3%83%a9%e3%83%9f%e3%83%b3%e3%82%b0%e6%95%99%e8%82%b2/

プログラミングの大衆化
https://devroom.viscuit.com/2018/02/27/post-1472/

2024/03/30(土) 02:29:10.46

Bun v1.1がついにWindowsネイティブ対応化を引っさげて4月1日リリース予定
日程がエイプリルフールでややザワついてるが敢えてこの日を選んでるっぽい？

Bunを作るZigもv0.12.0が4月2日リリース予定になってるが
こっちは既に数回無告知延期して公式すら話題にしなくなってるのでまたダメかもしれん

2024/04/10(水) 00:48:05.23

どんぐりテスト

2024/04/28(日) 22:41:22.44

hoshu

2024/04/29(月) 13:16:16.09

で？結局どれがいいんだい

2024/04/29(月) 16:50:51.13

Rustが死んだからZigかCarbonかな

2024/04/29(月) 22:47:28.69

死んでるの？
俺の中では同系統のコンセプトに対抗できてる言語が一切見られないので Rust 一強な勢いなんだが。

2024/06/08(土) 08:52:15.87

Zigのリリースサイクル早いね、もう0.13.0がリリースされた

2024/07/08(月) 21:11:19.11

待望の新言語

生成AIに疑似コードで指示すると自然言語よりも効率的にプログラムが生成できるというアイデアから生まれた、生成AI用の疑似言語「SudoLang」
https://www.publickey1.jp/blog/24/aiaisudolang.html

2024/07/09(火) 01:43:38.24

本末転倒だろ

2024/09/01(日) 15:29:07.17

RustがCより速くなるベンチマークは見たことがないです

NimのORCは明示的にオブジェクトプールを使ったプログラミングが必要ですが
ベンチマークがCより２倍以上速くなって、特にハードなリアルタイムシステム向け
のチューニングもできるようになっているようです
https://zenn.dev/dumblepy/articles/af2b2b9f8fd890

NimがCより２倍以上速くなって、しかもORCでメモリ安全も担保されているなら
Rustを使う意味がなくなると思うのですが、このベンチマークは本当なのでしょうか？

2024/09/08(日) 01:45:12.42

>>262
nimは一旦ｃに変換してコンパイルするので、ｃより早くなる事はないです。

ベンチマークで早くなっているのは、メモリプールを使っているからです。
(個別にヒープメモリを確保するのではなく、大きなブロックで一度に確保して
自分で割り当てを管理しているから）

私もｃでメモリプールを実装した事がありますが、ヒープのメモリ確保のコスト
は以外と大きくて、一括で確保するのはパフォーマンスの面で効果が大きいです。
またこのメモリプールの部分は自前でメモリ管理しているため、ＯＲＣとは関係が
ないです。（参照リンク元の記事の意図は、ＯＲＣと手動管理が混在できる事を
利点としているかと思います）

Ｒｕｓｔは詳しくないのですが、おそらくこのレベルの実装は可能だと思うので、
同じように実装すれば同程度の速度向上になるかと思います。
（ただし一括メモリ確保->個別データに強制castが必要で安全性は落ちる）

参照リンク元の記事は、メモリプールのような低水準のコードでもＮｉｍは高い
可読性で書く事ができると言いたいのでは。（手動確保したメモリをdestroy定義
で自動解放できる所とか）

2024/09/08(日) 07:43:41.27

>>262
>ベンチマークがCより２倍以上速くなって
という記述は見当たらないけど

> NimがCより２倍以上速くなって、しかもORCでメモリ安全も担保されているなら
> Rustを使う意味がなくなると思うのですが、このベンチマークは本当なのでしょうか？
「メモリプールが速い」は本当だろう
「Cより速い」は、そもそもそんなことを書いてないのでダウト
Rustは分からんけどGCが無いぶんNimよりは有利なのでは

2024/10/02(水) 13:03:50.53

RustがNimより速い訳がない

2024/10/03(木) 12:29:21.43

nim 2.2.0 リリース
久しぶりに速度をはかるとかなり高速化されているようだ。
単純なフィボナッチ計算４５桁で実測
-d:releaseコンパイルで約26%, -d:dangerで約33%高速化している。
(実際の高速化はこの一つ前のバージョン2.0.10でされている）

2024/10/03(木) 13:32:37.43

実用コードでそこまでの差はないだろうけど
チェックの省略やTCOが上手になったのかな
Cコードで差分とってみてほしい

2024/10/05(土) 02:05:54.37

266です。

nimから出力されたCコードの差分を取った所、違っていた箇所は以下の２点でした。
①メイン処理に入る前のnim側の初期化処理（関数名が変わっている）
②フィボナッチ関数内のresult変数の０初期化
※gccのコンパイルオプションも全く同じ

特に高速化に繋がる変更はなく、なぜ早くなるのか不明でしたが、色々と試して
上記②が原因と分かりました。

nimのresult変数の初期化が入る事で、ｇｃｃ側のコンパイル最適化で高速化
しているようです。
試しにnim2.0.8でresult変数を０初期化した所、nim2.2.0と同じ処理速度
が出る事が確認できました。
(フィボ関数内の先頭でresult変数を０初期化し、以降の算出値をresult変数に
格納するように変更した）

2024/10/05(土) 14:35:02.61

>>266
Nimの場合はバックエンドに使うCコンパイラの最適化能力も実行速度に影響します。Nimのバージョン間の実行速度を比較するときにCコンパイラのバージョンを同じにしていますか?
面倒でなければCコンパイラの出力するアセンブリコードを読むと何故result変数を0初期化することが処理速度に影響するかわかると思います。
--passC:"-S"というコンパイラオプションをNimに渡すとnimcacheディレクトリにアセンブリコードが出力されます。

2024/10/06(日) 13:25:29.22

>Nimの場合はバックエンドに使うCコンパイラの最適化能力も実行速度に影響します。Nimのバージョン間の実行速度を比較するときにCコンパイラのバージョンを同じにしていますか?

当然同じ環境です。choosenimでバージョン切り替えて確認してます。

私の疑問点は解消しましたし、gcc側の最適化内容まで追うつもりはないので、私の方の検証はこれで終了とします。

2024/10/26(土) 14:10:58.86

Zig言語で開発したターミナルエミュレータだってさ

ミッチェル・ハシモト氏の個人開発によるターミナルエミュレータ「Ghostty 1.0」、12月に正式リリース予定。オープンソースとして公開へ
2024年10月25日
https://www.publickey1.jp/blog/24/ghostty_1012.html

2024/11/29(金) 13:35:59.12

Crystalとかわりと新しめな言語っぽいけど次世代言語としてはあんま価値はない感じ？

2024/11/29(金) 14:06:07.15

対立煽りに荒らし尽くされて過疎ってるだけだから気にせんと何でも書いてってや

2024/11/29(金) 18:48:03.79

やはり、実際に採用されたプロダクトが出てくる頻度で見ると、Zigが頭一つ抜けてるな

2024/12/03(火) 00:07:23.29

zigをCコンパイラもどきとして扱うのはよく見るけどzig言語の採用例ってあんまり多くなくない

2024/12/03(火) 06:50:16.97

時雨堂もZig撤退しちゃったしなぁ

2024/12/03(火) 07:04:26.37

>>276
マジかよ
それはショックだな

2024/12/03(火) 07:13:55.18

>>277
非同期の仕様が全然決まらないかららしい
本家はLLVMに変わるコンパイラバックエンドに注力してるみたいだけど
そんなことより言語仕様とか標準ライブラリやったほうがいい気はする…

2024/12/03(火) 07:40:52.23

>>278
本家は今のCの適用範囲をそのままZigで置換することを目指していて
範囲外にある非同期に関心薄いのはしょうがないのでは

2024/12/03(火) 08:12:12.79

Cの適用範囲ってのが残ってるのかちょっと疑問はある
Rust for Linuxの騒動でも感じたけどCにこだわりのある人はC以外に移行しないと思う
移行してもいいって人はすでにRustなりに行ってる可能性高いし

組み込み系は残ってるけど認定コンパイラ必須だからハードル高いし
そもそもユーザ増えないと認定にお金出してくれる会社も現れないんだよな

2024/12/03(火) 21:49:17.45

zigは結局メモリ安全じゃないからね
ならcでいいってなるね

2024/12/03(火) 23:16:36.04

zigは未使用変数がエラーになるとか今風の言語っぽく厳しい部分もC好きな人には合わなさそう

2024/12/24(火) 09:41:20.41

待望の新言語

WebAssemblyに特化した言語「MoonBit」のコンパイラがGitHubで公開
https://www.publickey1.jp/blog/24/webassemblymoonbitgithub.html

2024/12/27(金) 17:23:49.87

記述言語OCamlじゃん‥

2024/12/27(金) 17:30:07.17

Haxeを想起させる

2024/12/28(土) 18:36:13.79

今更言語特有の変な記号とか覚えたく、ない

2024/12/28(土) 18:41:10.43

そもそもWebAssemblyをテキスト形式に書きゃいい
わざわざ別言語を挟む必要なし

2024/12/28(土) 20:01:23.85

ocamlが癌だよなあ
llvmにすりゃよかったのに
今時コンパイラをセルフホスト出来てないのは厳しい

2024/12/29(日) 00:15:57.27

テキスト形式ってWATのことかな？
Component Modelの実装もWATで全部記述するってことだろうけど、つよつよな人だー。

2024/12/29(日) 10:54:43.90

>>289
現状Wasmを使いたくなるケースがJS系より高速な数値計算くらいなんだからテキスト形式で十分
ブラウザゲームのような特殊な用途ではない限り、現行では未だ課題の多いWasmが従来のJS系+Htmlを食らうことはない
Wasmでstdの規格が制定されてWasmファイル容量の大幅削減が実現してからが本番

2024/12/29(日) 11:34:20.33

https://x.com/bobzhang1988/status/1866342498421096448
一応llvmで書き直す構想はあるみたいだ

2024/12/29(日) 14:55:32.92

今時のコンパイラならrust+llvmが鉄板なんじゃないの？
ライブラリも豊富になってきたし

2024/12/29(日) 14:58:20.96

>>289
Lispかける人なら余裕だと思うよ
知らんけど

2025/01/03(金) 03:33:14.60

Perlの$%@は良かった

2025/01/05(日) 10:08:03.18

そう思える人はRubyも好きなはず

2025/01/19(日) 19:22:00.79

Zigは0.14.0がリリースできず2月に先延ばしされました
今回issue残件が脅威の1000件超えのままだけど来月までに選別していつも通り大半を持ち越し

目玉の増分ビルドは正式リリースに届かないっぽいかな
他も根本から書き直しってのが多くて新機能は何が正式に入るのか謎だ

2025/01/20(月) 07:55:51.51

>>296
増分ビルドはnightlyでマージ済み

2025/03/06(木) 15:04:34.42

zig-0.14.0出たよ！恒例の延期はあったけどね

増分ビルドはテスト不足でデフォルトだと無効になっちゃってるようだ
> this feature is not ready to be enabled by default,
> it can be opted into via the -fincremental flag passed to zig build.
使ってみたいなら -fincremental オプションで明示的にオプトインしてねってことなので
有効化したらメッチャ高速になった…！ええやん！

2025/03/06(木) 19:12:13.02

Zig 1.0はいつ出るの？

2025/03/06(木) 19:46:33.97

最後の大物、コルーチンをサポートしてzig 1.0かなぁって予想。

2025/03/24(月) 18:22:12.85

>>229
きりのいいとろこで2030年ごろじゃね？

2025/03/24(月) 22:03:16.05

MoonBitでLLVMを再構築するとのこと
> We will rebuild a better LLVM in MoonBit starting this year,
> modern compiler toolchain in a modern language and it will be deveoped in OSS

2025/03/25(火) 13:53:04.66

>>302
は？別にそこはいいじゃん

2025/05/20(火) 08:58:30.48

待望の新言語

魔法陣のようなプログラミング言語「Mystical」
https://gigazine.net/news/20250519-mystical/

2025/05/21(水) 05:37:24.48

元はforthかな

2025/07/13(日) 21:25:38.68

待望の新言語

jank programming language
https://jank-lang.org/

2025/07/14(月) 13:40:56.77

lisp方言が増える感じなのかな？
clojureは、結構javaのクラスライブラリ呼んでなんとかしてる感じしたので、その点どうなるのかね。

2025/07/17(木) 12:44:48.46

Unison 言語から、「次」の言語を考察したい
https://zenn.dev/mizchi/articles/think-next-language-with-unison

2025/11/20(木) 09:14:17.78

SUSE⁠⁠、Zig言語でSSHの再実装にチャレンジ
https://gihyo.jp/article/2025/11/daily-linux-251119

ZigはCに近いパフォーマンスを出しながらも無駄なオーバーヘッドが少なく、ガベージコレクタをもたずにメモリ管理を手動で行うことから、SSHのような長時間稼働するサービスを効率良く動かせると見られている。

2025/11/20(木) 16:30:37.91

>>309
なんでよりによってSSHをメモリ安全でない言語で？

2025/11/20(木) 17:09:22.39

いわゆるハッカソンでしょ