次世代言語27 Nim Zig Pony Carbon Gleam
!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
スレタイ（順番はRedMonk準拠）以外の言語もok
前スレ
次世代言語26 TypeScript Swift Go Kotlin Nim
https://mevius.5ch.net/test/read.cgi/tech/1655771266/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured 久々にHaxeのプロジェクトページを訪ねてみたらサポートターゲットにHashLinkなるVMが追加されていた
Nekoの後継？ >>6
haxeまだあったのか。
昔ちょろっと見てけっこう良さそうな印象持ったけど流行らなかったな。
nimもトランスレーター系だし、同じ将来にはならないで欲しい。
結局はバックにGAFAMがつくかどうかによるのかねぇ。
それでいうとpythonは運・タイミングが良かったのか。 nimとかD言語みたいなちょっと良くした程度の言語だと流行らないんだろうなあ
RubyでいうRailsみたいな超人気フレームワークが登場すると話が変わってくるんだろうけも >>9
NimはもっとシームレスにPythonソースを使えればいいんだけど。
nimpyとかnimporterとかって公式になったっけ？ >>10
nimpyやnimporterが公式になるってどういうこと?
標準ライブラリになることを期待してるのかもしれないが、標準ライブラリになったとしても使いやすくなるとは限らないよ。
C/C++のライブラリだったらc2nimやfutharkというツールがC/C++のコードを読んで自動的にバインディングを生成してくれるらしい。
futharkはlibclangを使ってコードをパースするらしい。 CarbonってC++のABI問題の拗れが引き金となって生まれたものなんだろうけど
わざわざ文法から作り直すことないのにな
実用的なレベルになるまで相当かかりそう GoogleでC++の糞の山のメンテばっかりさせられて嫌気が差したんだろ
所詮数あるホビー言語の一つに過ぎないんだから好きにさせてやれよ >>11
公式になって手順・ドキュメントが整備されるというということだな。
そうすればもっとpythonコードが流用しやすくなるので、性能で困っているpythonユーザーが手を出しやすくなるかと。 nimのアンダースコアを無視する仕様は好きじゃない。 >>14
公式になったからといってドキュメントが整備されるとも限らないし
公式にならなくてもやる気があればドキュメントを整備するＰＲを送ればいいのでは。
>>15
アンダースコアを無視するおかげで、ライブラリがfoo_barみたいな名前を使っていてもライブラリを使う側のコードがfooBarという名前で呼び出せるので命名規則に一貫性をもたらすことができる。
しかしCのライブラリがfoo_barとfooBarという異なる二つの関数を持っているとNimから使うときに違う名前を使って参照するようにbindingを書かなくてはいけなくなってしまう。
そいいうケースはあまりないけどね。 Rustを見てて疑問に思うところがあるんだけど、
「コールスタック専用変数」「ヒープ用変数」といった
使い分けをする言語はあるのかしらん？
現状の言語で近いのは
C：変数はコールスタック専用。ヒープのインスタンスはポインタで管理
Rust：変数はコールスタック専用。ヒープ用変数はBox、Vec、Rcとかで模倣
ぐらいか。
コールスタックにあるインスタンスはスコープに連動するRAIIとかの便利な特性があるから、
他の言語でもコールスタック専用変数があってもいいと思うんだけど。
例えばJavaにコールスタック用変数があればfinalizeメソッドももっと使いやすくなりそう。
コールスタック用変数専用クラスとかあってもいいし。 スタックとヒープの使い分けができるという意味ならGoとかC#とか >>17
Nimでもスタックとヒープを使いわけられるよ。
refのついた型とクロージャの環境とstring, seqの中身はヒープに確保される。
それ以外のローカル変数はスタックに確保。
C言語のグローバル変数とstatic変数はstatic storageというスタックとは別の所に置かれるよ。
だいたいのシステムプログラミング言語ならヒープとスタックを使い分けられるんじゃないの？ >>17
Nimでもスタックとヒープを使いわけられるよ。
refのついた型とクロージャの環境とstring, seqの中身はヒープに確保される。
それ以外のローカル変数はスタックに確保。
C言語のグローバル変数とstatic変数はstatic storageというスタックとは別の所に置かれるよ。
だいたいのシステムプログラミング言語ならヒープとスタックを使い分けられるんじゃないの？ >>18
変数のエスケープ解析して自動でヒープとスタックを使い分けるんじゃなくて、その変数をスコープからエスケープするような使い方をしたときにコンパイルエラーにするようなのを想定しています。
スタックフレーム制約付き変数ですな。 >>20
確か、Nimもスタックフレームにインスタンスを置くことを強制できなかったかと思うけど、どうだったっけ？ >>17
Nimでもスタックとヒープを使いわけられるよ。
refのついた型とクロージャの環境とstring, seqの中身はヒープに確保される。
それ以外のローカル変数はスタックに確保。
C言語のグローバル変数とstatic変数はstatic storageというスタックとは別の所に置かれるよ。
だいたいのシステムプログラミング言語ならヒープとスタックを使い分けられるんじゃないの？ 間違えて連続投稿してすいませんでした。
>>22
type
SomeObj = object
x: int
proc foo =
var x = SomeObj(x: 10) #スタックに確保
var y = new(SomeObj) #ヒープに確保
foo() ここの系列で出たことあるのか知らないし、ちょっと毛色違うんだけど設定ファイル言語でDhallってあるんだね
方向性は凄く好みなんだけど最新バージョンの規格をそのまま食えるのが現状Haskell（とPureScript?）だけらしくて君らそういうところやぞ……ってなってる
yamlやjsonに変換してから食わせることはできるらしいけどやっぱそのまま食えるのと手間と複雑さは無駄に嵩張るし、この手のDSLはどれだけ広い環境で使えるかが重要よねって >>21
C#はスタック変数のエスケープは不可で、その参照を返すようなことはできない
クロージャでキャプチャされたり非同期メソッドの場合にヒープに昇格する例外はあるが、文脈から明らかであり、いわゆるエスケープ解析とは異なるものだ
更に、構造体を ref struct として定義することで上記のような昇格も不可となり、完全にスタック専用になる >>25
ちょっとぐぐってみたけど俺はできると思ってる子がなんかこれあったら便利やんって言うのを色々詰め込んだイメージ
本当にでかい設定ファイルなら嬉しいのかも知れないけど大多数の設定ファイルにはオーバースペック過ぎて流行らないと思う オーバースペックさで言うとyamlも相当だしそれだけでは判断できないのでは スタックとかヒープとか基本的に実装依存じゃないの
言語レベルで規格として策定されてるのある？ CやC++はmallocやらnewなどでメモリ確保しない限りは全てスタックではないの？
今時のコンパイラはどうやってるのか知らんけど昔は少なくともそうだった 可変長配列とか文字列型などの必要なメモリ量が実行時に決まるものや
関数やブロックのスコープと変数の寿命が対応しないもの(GCで管理されるオブジェクト)などはヒープ使うしかないでしょ。
けどローカル変数などをヒープに置くと効率悪いし。 >>29
ハードウェアスタックがないマシン（汎用機とか）もあるから実装依存なのは確かだけどそういうマシンでもソフトウェアでスタック作ってるので実装としてはたいして変わらん >>30
関数の外にある変数やstatic変数はstatic storageというプロセスが生まれてから死ぬまで存在し続ける領域に置かれるよ。
詳しくはdata segmentとかbssとかで検索してね。
static変数は値を保持し続けないといけないからスタックに置けないし、
関数の外にある変数は複数の関数から共有されるのでコンパイル時かリンク時にアドレスが決まってないといけないと思うのでおそらくスタックに置けない。 C++の定石としてオブジェクトはスタックに置くのが基本だよ
デストラクタを動かしたいからね
ヒープにデータを割り当てたい時は構造体やクラスでラップするのが基本 >>29
最適化の余地残すために規格では振る舞いしか記述しないのが基本だと思う
レジスタだけ使うとかあるしね 可変長配列に限って言えばCは一応VLAがある
11からオプションだけど >>37
スマポがまさに>>34のパターン使ってるんだけど スマートポインタｗって正直使う必要殆ど無いのに
全てのインスタンス生成で使うバカがいるよねｗ スタックに確保されるのがポインタなのかクラスや構造体の実態なのかをちゃんと理解してない人が多すぎるね
コンパイラとかコンピュータアーキテクチャの勉強すべき
そこを避けてたら絶対に使いこなせない そもそもスタックやらヒープやらちゃんと意味が分かっている奴って
アセンブラレベルで組んだことがあるとかじゃないと
知らなくても仕方ない気がするなぁ 使いこなす必要は無くて、理解が足りなくてもやりたい事が出来れば、それで良いと思うよ。 理解してなくてやりたいことができるってそれはたまたま動いてるか
その機能が必要ないことをやってるだけ
壁が来た時ぶち当たって手遅れになる
最近スクリプト言語系のエンジニアがRustとかのモダン言語で苦しんでるのを見ると
何が理解できてないのか？を理解することってのはすごく大事 Compiler explorerとかでコードがどんな風に最適化されてアセンブリ言語になるか読んでみるといいかもね。
スタックに割り当てられたローカル変数はレジスタに割り当てられる場合はあるけどグローバル変数やヒープにある変数はかならずメモリ上におかれるから毎回メモリからレジスタにロードして値を計算してからメモリにストアされる。 最適化でキャッシュの考慮や制御までするんだから
volatileないと実際どうなるかはわからんとちゃうかな Rustやるなら当然アセンブラが理解できないとってことだね
メモリ安心安全のためには必要なコストだよね プログラム書くのが本業の人なら、どうやってプログラムが動くのか知らなきゃっていうのは分かるけれど、プログラムば手段であって、コピペでも何でも良いから欲しい結果が得られるなら良いって人もいるから。
それで、Rustがそんな人に合わせる必要はないし、そんなのはPython辺りに任せて、Rustはプロフェッショナルの道具でいいんじゃないの？ それでいいよ
あっちのスレの空気持ち込まないでくれ >>47
アセンブリ知ってて損することはないけど、必須な知識ではないよ
スタックやヒープの区別について分かっていればよくて、理解のための手段のひとつとしてアセンブリが提案されているだけ
他の手段で理解できるならそれで良い
Cを使いこなすのにアセンブリの知識が必須ではないのと同じ 書いたコードがどんな機械語になってるか、確認してない層が一定数存在するって事？
周りに居たら嫌だなぁ どんなバイナリになるかイメージはするけど確認なんてしないだろ
最適化ビルドするとまるで想像通りじゃなくてびびったりはする >>42
俺特殊なハードウェア用のコンパイラとか作ってたんだけど
コンパイラ作ってようやくCがちゃんと理解できたよ
マジでコンパイラ作らないとわらないと思う >>55
これはまあまあおすすめ
ただ32bitCPU時代に書かれた本なのでそこが微妙なのと
理論的なものがほとんどなく構文解析もJavaCC使ってるし
コード生成も毎回演算結果をスタックにpushするようなことをやってた気がする
allocaも自前で実装するし
ただCのような言語をアセンブリ言語へコンパイルするための勉強としては悪くない intel ISAのドキュメントがオレオレ用語多くて意味わからん ドラゴンブックを見て一つ一つ実装していくのが良いですよ。
誤植が猛烈に多いのも練習問題のような気がしてきますよ。 >>60
このあたりは偏執狂のRustの方が上手だな。
いっそのこと参照型のゼロ値は禁止すればいいのに。 >>60
std/options で
ひとまずOK じゃないか ? Not nil annotationはversion2.xで使えるようになるらしいよ。
https://github.com/nim-lang/RFCs/issues/437 >>64
not nil がデフォルトになるとあるね。 >>64
2.0がいつ出るかなんて全く不明
1.8.0の次は1.10.0
次は1.12.0となって。。。
恐らく5年以上先 ? スタックフレームて大抵の実行環境で使用されているのに、スタックフレームに特化した言語て無いよね。
なんでなんだろう？ 世の中のほとんどのプログラムにはヒープメモリが必要だからでしょ。
実行時じゃないとサイズがわからないことがあるし、スタック上に動的にメモリ領域を確保できるようにするとかなり大きめにスタックを確保しなくてはならくなるだろうし。 スタックフレームに特化した言語ってどういうものを想定してるの？
Forthみたいなスタック指向の言語とは違うよね 実CPUのスタック操作なんて仕様にいれたら足枷だしね
関数のABIとは別に仮想的なローカルスタックを扱えるかんじ？ >>69
スタックフレームならではの特性をコードに明記できる、といったイメージ。
例えばスタックにあるインスタンスしか受け付けない(参照)引数とかあれば、shared ptrとかunique ptrの参照渡しも安全に使える。
Rustがそこそこいい感じなんだけど、なんか中途半端。 >>73
そういうのが中途半端だと言っている。日本語も読めないのかよ。 800 デフォルトの名無しさん sage 2022/09/15(木) 23:09:10.28 ID:KFRYW2wo
次スレはこれらの言語を入れてください
Zig
https://ziglang.org/ja/
Jakt
https://github.com/SerenityOS/jakt パッと見の構文はRustソックリ
borrow checkerはなく、代わりにARCを使って実行時にメモリ管理しようとしてるっぽい
なんでRustやZig使わないんだろうと気になったけど、自作したSerenityOSのためのエコシステムはできるだけすべて自作したい、くらいの動機みたい
参考: https://awesomekling.github.io/Memory-safety-for-SerenityOS/
まあZig未満のドマイナー言語にとどまりそう 書き忘れた
jaktはC++へのトランスパイラ、ってのも特徴
SerenityOSはC++で作ってたから、C++トランスパイラにすれば移行しやすかったってことだろう Nim追加
Language x10 x100 x200 x400 Memory Comment
--------------------------------------------------------------
Zig 0.118 1.073 2.113 4.203 3.2MB (std.HashMap, caller-hash by Context(Fnv1a_64))
Nim(clang) 0.211 1.171 2.245 4.372 4.2MB (CustomCountTable,LTO,ARC,caller-hash) New
C(gcc) 0.136 1.146 2.271 4.531 2.0MB (optimized.c,binary IO,jemalloc,O4,LTO)
C(clang/LLVM) 0.137 1.147 2.280 4.544 2.0MB (optimized.c,binary IO,jemalloc,O3,LTO)
Go 0.152 1.233 2.428 4.832 3.9MB (caller hash,better loop)
Go 0.164 1.346 2.654 5.279 3.8MB (caller hash)
Rust(LLVM) 0.154 1.425 2.838 5.674 2.6MB (optimized-customhashmap,O3,LTO,caller-hash)
以下、caller-hashではない
Go 0.085 0.366 0.693 1.319 61.9MB (parallel.go,reserve 65536/2)<--マルチスレッド
Nim(clang) 0.218 1.255 2.401 4.691 4.2MB (CustomCountTable,LTO,ARC) New
Zig 0.162 1.493 2.970 5.935 4.6MB (std.StringHashMap)
Go 0.182 1.563 3.063 6.097 3.8MB (customhash.go,reserve 65536)
Rust(LLVM) 0.214 1.725 3.396 6.715 3.5MB (optimized,fxhash,O3,LTO)
Nim(clang) 0.316 2.241 4.371 8.633 4.2MB (optimized.nim,std/CountTable,65536,LTO,ARC,FNV) New
Nim(clang) 0.332 2.387 4.652 9.152 4.2MB (optimized.nim,std/CountTable,65536,LTO,ARC) New
zig 0.10.0-dev/gcc 12.2.0/clang 15.0.0/Nim 1.6.8/go go1.19.1/rust 1.64.0
CPU Zen3@boost~4.75GHz
https://github.com/benhoyt/countwords
https://mevius.5ch.net/test/read.cgi/tech/1663409149/529,450,461,478
今回の検証では、「C」は定点観測用として固定。
Nim/CustomCountTableはinc呼び出しの引数string copyを抑制。
Nimが想像より遥かに速くて「Cと同程度」以上の結果が出た。 検証 https://blog.fascode.net/2021/10/24/try_julia/
Language 10^5 10^6 Comment
----------------------------------
C++(clang) 0.032 1.029 (O3,LTO,vector,fastmod)
Nim(clang) 0.033 1.031 (O3,LTO,Seq,fastmod)
Nim(gcc) 0.041 1.339 (O4,Seq,fastmod)
C++(gcc) 0.042 1.502 (O4,vector,fastmod)
以下、fastmodではない
Odin(LLVM) 0.073 3.784 (o:speed,[dynamic]int)
Nim(clang) 0.074 3.784 (O3,LTO,Seq)
C++(clang) 0.074 3.785 (O3,vector)
Cython(clang) 0.089 3.797 (O3,libcpp.vector)
Nim(gcc) 0.083 4.410 (O4,Seq)
C++(gcc) 0.085 4.412 (O4,vector)
Zig(LLVM) 0.083 4.410 (OReleaseFast,ArrayList)
Julia(LLVM) 0.254 4.583 (JIT,O3,Int[])
Python(Numba) 0.602 5.236 (JIT,list[int])
PyPy 0.162 7.046 (JIT,list[int])
Cython(clang) 0.696 39.603 (O3,list[int])
Python 1.187 75.740 (list[int])
https://odin-lang.org/
https://github.com/lemire/fastmod
zig 0.10.0-dev/gcc 12.2.0/clang 15.0.2/Nim 1.6.8/Odin dev-2022-10-nightly/
julia 1.8.2/Python 3.10.7/PyPy 7.3.9/Cython 0.29.32/numba 0.56.2
CPU Zen3@boost~4.75GHz 感想:
Juliaは確かに速いが、他との比較は最適化オプションしだい。
動的配列/リストのベンチになるかと思ったが、やってみたらgccが振るわない。
原因はmodulo計算の最適化の違い？ https://godbolt.org/z/T7bKK14fr
ZigはLLVMのmodulo最適化をトリガー出来なかったか。
OdinはLLVM AOTコンパイラとしての性能を引き出せている(今回は)
まだ言語機能の特徴をつかんでいないが、映画、ゲームグラフィックス分野で使う様な
ライブラリが最初から入っているのが売り？
Nimは殴り書きとか、書き捨てとか、簡潔に書けて、gcc/clangの速い方を選べて、
fastmodの様なC++「header only」のライブラリを手軽に利用できるのが良い。
Cythonも慣れたらNimと同じように出来るのだろうか。 「Python 3.11」がリリース、4年で5倍の高速化を目指す「Faster Cpython」計画が始動
https://forest.watch.impress.co.jp/docs/news/1451751.html
200万ドル程度と見積もられる資金はMicrosoftが協力
参考
Faster-Cpython Microsoft
Pyjion Microsoft
Cinder Instagram/Facebook/Meta
GraalPy Oracle
Pyston Dropbox->pyston-lite
Ruby3 3倍速->rya >>87
時間比較する時は
時間で昇順ソートした表を掲載して下さい >Nimが想像より遥かに速くて「Cと同程度」以上の結果
Nimが速いのはトランスパイラだからな 他人が比較したやつを載せるんじゃなくてお前が比較したやつ載せろよ 今更だけど、スレタイが前スレとは違う言語だらけで
マイナーなのをウォッチする別スレかと思ってたわ TypeScript、Go、Swift、Kotlinって次世代でも何でもなく普及しきってる現役言語で、それぞれ言語別のスレが伸びてるし、
ここはこのスレタイで良いと思うわ https://gleam.run/
Rust製のErlang、JavaScriptトランスパイラ、という事で語れる人集合！
>>91が比較したら見直すぞ！ 一般運用が何をさしてるか不明だけど
仕事で広範囲に使うのは厳しいんじゃ ?
1.0に達して無くて仕様も変更され続けてるし いつの間にかスレタイNim以外聞いた事ない言語名になってた Cyber言語
https://cyberscript.dev/index.html
Luajitの3倍高速な組み込み用のスクリプト言語
Pythonライクなインデント
Luaよりも人気でるかも
組み込み用途なので汎用的には流行らないと思うけど Googleって何個流行らん言語開発する気なんやろな
コトリンも結局流行らんかったし
goも流行ってるかと言われると微妙やし
カーボンなんて絶対はやらんわ >>107
kotlinはGoogleちゃうぞ。JetBrains。 >>109
そうやったんか
泥の印象しかないから思いこんでたわ >>104
CyberってZigで書かれてるんだな。
あと非JITのインタープリターなのに高速なのは普通にすごい、これは応援するわ。 Zig言語が v1.0 でリリースされるのは
3年後らしい
うまくいっての話だから普通ならさらに2，3年は遅れるかも すべてのGC言語に対応するGC実装を決められない
から困難と言ってたと思うがまとまるんだろうか https://github.com/WebAssembly/gc/blob/master/proposals/gc/Overview.md
この辺みても到底詳細仕様が決まるようには見えないし
先陣を切って自分の都合の良いように決めるために、Googleがゴリ押し始めたんだろうね
まあQUICはうまくいった感あるし、Chromeの影響力を考えると一気に進みそうだね ここからが勝負なのよね
ライセンス上の制約が少ない言語なら何でもいいから早く覇権決めて欲しい 所詮トランスパイルするだけの言語は終わる
TSやKotlinなど C++は元々トランスパイルするだけの言語だったけど未だに終わってないぞ >>120
直接コンパイルしているから終わらなかった
クラスを追加しただけのように見えてバイナリの速度も若干違うし
今や別物という扱いかと Types as Commentsが通ったらTypeScriptは安泰 王者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入りは成功を保証しないが、少なくとも注目に値する第一歩だ」(ジャンセン氏) 待望の新言語
Mojo &# 128293;: Programming language for all of AI
https://www.modular.com/mojo 最終的にPython互換を目指すということだからPyInstallerの軽量な代替になってくれないか期待したいところだけど
まだclassもサポートされてないのね。 >>128
いい言語だと思うが、
開発者少ないのに複数言語へのトランスレートは厳しいよ。
Cのみに絞るか、せめてCとJavaScriptくらいに絞るべきだと思う。 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エコシステムへのアクセスも提供される。 オフサイドルールは書かされてる感が強くて嫌いなんだけど、世間的には好意的なのか >>133
オフサイドルールに限らず文脈依存文法は自動化が難しくなるのでセンス悪いと思うけど、ブロックは視覚的に認識しやすいから人気あるんだよなぁ。
YAMLみたいに併用できるならまだマシだけど。 >>135
前後のインデントによってブロックが決まるから文脈依存じゃね？ YAML拡張してifとかの制御構造入れるやつもいるからな。 >>136
後ろのインデントには依存しないんじゃね オフサイドルールでブロック表すのも、ブレースでブロック表すのも、構文解析的にはは同じことでしょ インデントの深さに依存するから、フレーズみたいに「現在のブロックを閉じる」だけの操作では済まない。
オフサイドルールのプッシュダウンオートマトン実装例あったっけ？ 構文解析的にはほぼ同じ
間違ってても検出できない(ケースが多い)
オートフォーマットができない
のがデメリット 前処理でブレース挿入して処理するから実際のパーサ部分は似たようなものって言いたいんだろうか >>142
GHCとか
Pythonとかはlexerの段階でDEDENTトークンを生成してるから>>143の言う通り https://docs.python.org/3/reference/lexical_analysis.html#indentation
Pythonの場合はここに書かれてるようにlexerの時点でスタックを使って処理できるという仕様だけど
他の言語のオフサイドルールはもっと複雑になるの？ >>146
lexerの能力は高いだろ。
PDAは(Lexerとかと比べると)大したことできないよ。 Zigの単行tryとcatchは馴染みないから怪訝してたけど使ってみるとtry-catchブロックよりフローが明確になって良いね
これって他言語にもある言語仕様なのかな NimってPythonのライブラリにアクセスしてfor文回すともはやNimに求めてた性能ははpythonよりになってしまうのでは？型推論できないからねぇ。 >>150
型推論は無関係な気がする
単にPythonライブラリの性能に律速されるだけ pythonのダメ記法を捨てられるだけでもメリットデカイね。 for を python で描くと遅い
for は Nim で描いて
中身だけ python ならまだマシ
もちろんネイティブの速度ではないがそんなの Nim だからじゃなくて
C++ でも Rust でも python 呼べば同じ結果になるぞ >>153
for文をNimで書いて、中身をpythonにして実行速度を計測してみたらpythonオンリーとあまり変わらなくてがっかりしたという経験がある。ただ、自分のコーディングが悪かった可能性もあるけど。 >>154
中身の計算コストがforループ自体のコストと比べて大きければNimでもpythonでも変わらないんじゃない? 病∞！！！！
症∞！！！！！
漠∞！！！！！！
西∞！！！！！！！
卵∞！！！！！！！！
多∞！！！！！！！！！ Zig 0.11.0のマイルストーンが7月17日から8月3日に延期されてしまった
やはり未解決のissue多すぎて再延長もあり得るかこれは >>159
1.0も遠のいた…
今回のリリースは目玉のasync関連も見送りっぽいし内容的には実質0.10.6くらいなイメージ
残ってた300前後のissueは未解決のまま公式Newsのとおり0.11.1から1.0.0の各マイルストーンへ再分配中
（大半を単に先延ばしするだけなのでそのまま1.0もズレる）
そんな中で脱LLVM構想も再浮上してるし1.0到達は当初の3年後どころか5年以内目処も危うい しばらくスレに来なかったらスレタイの言語知らんのばっかになっててわろた Nim 2.0が出たっぽい
しかしぜんぜん話題になってないな… そもそも、nimを宣伝しているようなblog記事以外で見かけたことがないしな。 本当、nimの話題って「nimは良い」しかないよな。 JavaScriptランタイム「Bun」がバージョン1.0に到達へ、9月7日にローンチイベント開催
https://www.publickey1.jp/blog/23/javascriptbun1097.html
主な開発言語としてZigを採用し、メモリ管理などを含む低レイヤでの実装を実現することで、Node.jsやDenoよりも高速な動作を実現していると説明しています。 >>171
v1.0の目玉だったWindowsネイティブサポートは結局実現できないままでリリース押し切ることにしたのか それベンチによってはNodeが勝ってたりDenoが勝ってたりするから当てにならん >>171
元言語のzigはいつ1.0になるんですかねぇ 雨の日にうっかりベンチに座るとパンツがビショビショ濡れ濡れ >>131 続報
Pythonの高速なスーパーセットをうたう新言語「Mojo」、コンパイラなど公開、ローカル環境で利用可能に
https://www.publickey1.jp/blog/23/pythonmojo.html Zigはかなり期待してるので頑張って欲しいな
長いこと指摘されてるissueのclose速度が1日平均5件なのに増加速度は1日平均10件で
ずっと次のリリースにたどり着けないよ問題を結局どう解決する方針にしたんだろう >>180
こんなんでBunはよく1.0にしたな。 https://harelang.org/
（海外の）FOSS、ミニマリスト、アンチRust界隈で流行ってる言語 Hare
C言語プログラマのために作られたとのこと
メモリ管理は自前だがいろいろ安全対策がされてるっぽい
Windows, Macは対応しないと宣言 ちょっとOdin触ってみた。
Zigより気に入った。
最適化がまだC/C++より弱いからエッジケースではC/C++,Rustにはパフォーマンスかなわないようがた、ぶっちゃけRustよりOdinのほうが書きやすい。 WebAssemblyのガベージコレクションが正式機能に、最新版のChrome 119で。Firefoxも今月リリースのFirefox 120で正式機能になる見通し
https://www.publickey1.jp/blog/23/webassemblychrome_119firefoxfirefox_120.html zigのcompiletはCのatoi、atofみたいなのを1関数にまとめれるということ？ wasmはどうせgcを採用するんだろうなと思ってたがやっぱりか
jdkと変わらん wasmは初期の頃jdkと何が違うの？と言われてた
jdkはバグが多いからとか説明してたが、実際そうでもない
なぜかその界隈の人達が漠然とjavaを嫌ってるだけだな 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なんでしょ？謎すぎ List()の型は匿名のstructだな
でもじゃあこれはなに？っていう
fn List(comptime T: type) type
引数に入力されたtypeの型が返値の型じゃないの？ >>193
>>192の例で説明すると、引数として渡されたtypeはitemsフィールドの要素の型。
戻り値のtypeは匿名structの型。
引数の方のtypeは、匿名struct内の関数の引数や戻り値、その関数の戻り値を組み立てるための型引数などにも使える(文字で書くとややこしい)。
戻り値の方のtypeは、builtin.Typeでサポートされてるものが返せる。
あと引数に渡されるtypeは、戻り値を組み立てる型の中で、例えば「T.foo()」と書くことでT型はfoo関数の存在を制約として与えることもできる(foo関数を持たない型が渡されたらコンパイルエラー)。 ありがとう分かった。
typeはzig標準型全体を指すものということか。
任意の標準型を受け取って、任意の標準型を返す総称型関数ということね。
ダックタイピングも分かった。
宣言じゃなくコードの内容から推論してコンパイルエラー出してくということね。 チュートリアル読んでるけどzig良い。
Cの代替としては最有力かな？
世の中はメモリ安全のためにRust推奨なんだろうけど。
本当はそっちに進んじゃいけない、と思ってる。 Zigのマイルストーン見ると先送りしてきたv0.11.1のバグ180件以上残ったままv0.12.0側のissueばっかり片付けてるな
これはついにマイナーバージョンアップ近づいて来たのかな linux kernelがrustのサポートを確定したという記事を読んだ。
だったらrustなのかなあ。googleもandroidをrustで書くらしい。
rustなのか。 いや、やっぱりrustかなあ。
将来のベアメタルプログラマーは抽象的な言語概念から逃げられないね。
そうなると、初学者はむしろマネージド言語から入るのかな。 Cの後継としてZigは結構ありだと思うけど、
Cが残ってる分野ってISO標準とか組み込みベンダーサポートとかが必須な分野が多くて
Zigがそこまでたどり着くには10年とかかかりそうだよな… nimは概要を読む限り全然いいと思えない。
C++をさらに悪化させたような言語じゃないの？ nim使うならC++で良いはずだよ。既に多用されてて信頼性あるし。 odinのアイデアはほぼzigと同じじゃないか？
zigの方が先に出てきて、その直後にodinが出てきたようだ
メモリ安全と言われているようだが全くそうではないというレビューも見かけた。
後出し追いかけ言語で政治力とエンジニアリングのパワーで優っているのがodinということじゃないか？
Cの代替がzigのようなものであるべきという着眼点を最初にもたらしたのはzigじゃないだろうか
他にそういう方向性の言語がzigより先にあったのだろうか zigのwikipedia読んでたらCからの変更点という観点でzigが説明されてる。
Cを出発点としていくつかの改善点を加えた言語というのが重要なんだ。
その中でもメモリ安全とcomptimeによる類似関数をひとまとめにするというアイデアが重要と思う。 fn () err!val
みたいな共用体を返す構文はCのerrnoとかC#のoutとかの代用になるのかな
共用体はenumと連携させてswitchで使えるようだから中身に応じて処理を分けれる
実際使ってみないと分からんが、まあ学習は順調に進むし良い印象がある >>205
>>206
Nimのどこがダメなんでしょうか?
少なくともC++よりシンプルな言語だし読みやすく書きやすい言語だと思うのですが。 NimはまぁPythonっぽい構文が好きな人にはいいかもねって感じなだけで
わざわざ他言語から乗り換えるような特徴がないんだよね NimはJavaとかC#みたいなクロスプラットフォーム性があるわけではないし
Cが使われているような領域で使えるものでもない
だからそういった領域では論外
C++と競合するが、置き換えれるほどの何かがない
恐らくC++から置き換えるならRustになる
という認識。Nimの言語仕様がJavaやCと比較して優れてる！とか言ってみても仕方ない。
競争相手になり得ない。
C++かRustと比較して総合的に優れてると言えたら重要なものになるだろうけど。 nimはgcありとなしモードあるけどライブラリちゃんと動くの？
gcありじゃないとほとんどのライブラリが動かないということになるなら、
C++にもRustにも到底比較対象にならない
どの領域に入るつもりなんだという印象 要するに、総合的に優れてるように思えても「あらゆる領域でちょっと負ける言語」は使われない。
戦略は？ということ。
C#やjavaと比較→ネイティブコード作れる！エレガントな文法！→java使ってる人達には全くどうでもいいです
Cと比較→たくさんの抽象的な言語概念！大規模開発に強い！→C使ってる人達には全くどうでもいいです
C++やRustと比較→GCがあって簡単にコーディングできるぞ！→彼らにはGCは不要あるいは邪魔です NimのライバルはZigじゃなくてV言語だと思う
ベターCっぽいけどCの置き換えできないしC++にも届かないって立ち位置の点でね
(文法もC系ではなくPython系って側面も込み) >>207
＞odinのアイデアはほぼzigと同じじゃないか？
違うな。
zigはcをそのまま取り込む感じだが、odinはあくまでもodin。
cとの連携もzigみたいにそのままでは無い。
＞メモリ安全と言われているようだが全くそうではないというレビューも見かけた。
odinはメモリ安全なんかじゃ全くないぞ。別なもの見てないか？
＞後出し追いかけ言語で政治力とエンジニアリングのパワーで優っているのがodinということじゃないか？
政治力っていったいなんのことよ。
イチャモン着けたいだけか？
＞Cの代替がzigのようなものであるべきと
「zigのようなものであるべき」って言ったらzigしかないじゃん。
言ってることがメチャクチャ。 >>212
＞NimはJavaとかC#みたいなクロスプラットフォーム性があるわけではないし
JavaとかC#はマルチプラットフォームという。
マルチプラットフォームとクロスプラットフォームの違いは自分で調べてね。
＞C++と競合するが、置き換えれるほどの何かがない
GCあるから置き換えは無理だね。
使わないようにも出きるし、その方向に向かってるけど既にあるライブラリがGC前提だったりするし。
nimはトランスレーター系で、出力がcだったりjavascriptへだったりして、そこでリソース消費しちゃってる感あるのがな。
かつてhaxeという言語があったが結局流行らなかった。 odinについて知りたかったらhacker newsを見てくれ。 >>209
Error Union はペイロードを持てないので、erronoと同じと見て差し支えない。
ニュアンスとしてはgo言語のエラーと値を返すスタイルが近いかな。
go言語と違って、エラーがなければ値が保証される(毎度のエラーチェック不要)のと、エラーハンドリング不要ならtryで呼び出し元に押しつけられる楽さはある。
C#のTry～メソッドのout引数を戻り値で扱えるが、zigはポインタ渡しもできるのでさらに強力。 >>218
deferの使用を癖づけしておけば、おおむね安全だから・・・。
動的確保したu8のスライスを別の変数にも持たせ、
元の変数の破棄によるダングリングポインタで自分の足を撃ち抜くくらいかな？
よく事故るところは。 >>217
haxeは構文マクロ書きやすくて好きなだけに悲しい >>222
haxe知ってる人がいて嬉しい。
マイナーで終わったのが残念。 >>212
おまえなんも判ってないな
>Cが使われているような領域で使えるものでもない
使えるだろ
>C++と競合するが、置き換えれるほどの何かがない
NimはC++とは競合しないC++と共存する
>恐らくC++から置き換えるならRustになる
RustにCの置き換えはあっても
RustがC++を置き換えることは無いわ >>215
>文法もC系ではなくPython系って側面も込み
事実誤認だ
よくそんな平気で嘘が吐けるな >>214
君は表面的なところしか観れないhusianasann 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マクロのようなものを作ることは無理じゃない? 俺も>>211と同じような印象を持ってるけど、一方でこうやって熱心に布教してくるユーザーが目につくんだよね。
温度差が面白い。
pythonスレで宣伝するのはさすがにスレチだからやめてほしいが。 >>218
rustほどではないけどcと比較すればかなりメモリ安全な言語 >>227
nimのマクロはASTいじれるから強いよな。
俺もnim好きだし。
一方で >>217 で書いたようにまだライブラリに旧いGC使ってるの混じってるのと、CだけじゃなくJavaScriptへのトランスレートとかして開発リソースを消費してるのが懸念。
あとRustのマクロならたぶん近いことできるんじゃないかね？
あれは hygienicマクロうたってるし。ただ複雑過ぎるとも思う。 C++もGCありの開発可能だからnimはC++と近いのでは？
主にC++が使われてるのはミドルウェア、webブラウザ、ゲームとかだけど
いずれもGCが動かない環境ではない nimがcと競合すると考えるなら、
nimがカーネルやデバドラで使われると思うのか >>228
熱心に布教するユーザが目に付くというのがまさにとりたてて特徴がないということの証明になっているかもね
他言語だと多少気にいらなくても〇〇のために使っている、となるがNimはその思想に完全にマッチした人しか残っていないという 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と言語仕様がどんどん複雑になっているから完全に対応は難しいかもしれんが。 >>234
Rustのいいところはコンパイルが通らないから誰が書いてもある程度同じようなコードが出来上がることだと思う
とても極端な話すればレビューもいらない
めちゃくちゃチーム開発に向いてる
Nimは既存の資産を活かせるかつ自由度が高いから小、中規模向けなのかな >>235
> 誰が書いてもある程度同じようなコードが出来上がる
これは幻想がひどい気がする。コンパイル通らない時にどう解決するか結構個性が出ると思う。
無限に unsafe 指摘されて切れたwebフレームワークのメンテナ居なかったか？ >>237
そこまでレベル低い人の話はしていない。
掘り直したら actix-web だった。
以下のページが日本語で問題まとまってる。
ttps://scrapbox.io/nekketsuuu/actix-web%E4%BA%8B%E4%BB%B6 Rust2006年、Nim2008年(or 2005年生誕説)、Go2009年にそれぞれオープン化して同期の中でNimの言語コンセプトだけ主要な席を取れなかったのはおかしい。
Nim好きユーザーとしてはここからの巻き返しを超絶妄想してる。
現世代言語の仕様に引けを取ってないし8月に本体2.0.0に上がったし周辺パッケージも育って熱心な布教者まで揃ってるのにそもそもの認知度が低すぎるままなのは不思議でならない。
いまNimで書いてる人たちは何用途で使ってる?まずは特定用途で知名度を上げることに突破口があると思うんだよね結局は。 >>239
個人で始めたか、法人所属の人が始めたか。
pythonはメジャーになるまで30年以上かかってる。
法人の後ろ楯あると早いね。
何かキラーアプリがでることを期待してる。俺はそんなスキル無い。 >>239
同期だからこそ、潜在ユーザをみんなGoとRustに取られた感はある
企業がついてない分エコシステムとかはどうしても負けるし
あとはC系の人にPython風構文はあまり歓迎されないというのはあるかも
MojoみたくPythonユーザを直接取りに行ったほうが良かったかもね pythonは2000年代初頭にはperlよりメジャーになってただろ。 やっぱりrustなんだろうね
OSも徐々にRustになってくっぽい
主要OSが完全に移行するには100年かかるだろうけど LinuxカーネルのコードがRustに置き換わるとコンパイル時間が大幅に増加しないか心配。
Cだけのカーネルでもビルドに一時間くらいかかるのに コンパイルよりCargoのdb更新に時間掛かってるんだよないっつも >>246
それいくつか前のバージョンで改善されたやつじゃなくて？ 待望の新言語
Introducing Pkl, a programming language for configuration
https://pkl-lang.org/blog/introducing-pkl.html
Appleがシステム構成のためのプログラミング言語「Pkl」をオープンソースでリリース
https://gigazine.net/news/20240205-apple-pkl/ >>249
DBスキーマみたいなストアドプロシージャ内蔵の静的型付けYAML作ってるってのはこれだったのか
トランスパイラ方式にしたんだな Bun v1.1がついにWindowsネイティブ対応化を引っさげて4月1日リリース予定
日程がエイプリルフールでややザワついてるが敢えてこの日を選んでるっぽい？
Bunを作るZigもv0.12.0が4月2日リリース予定になってるが
こっちは既に数回無告知延期して公式すら話題にしなくなってるのでまたダメかもしれん 死んでるの？
俺の中では同系統のコンセプトに対抗できてる言語が一切見られないので Rust 一強な勢いなんだが。 
