次世代言語27 Nim Zig Pony Carbon Gleam ->画像>1枚

!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512

スレタイ（順番はRedMonk準拠）以外の言語もok

前スレ

次世代言語26 TypeScript Swift Go Kotlin Nim
http://2chb.net/r/tech/1655771266/

---

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

乙

本スレ

ただし Rust言語ネタは禁止します

>>1
O2

久々に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というスタックとは別の所に置かれるよ。

だいたいのシステムプログラミング言語ならヒープとスタックを使い分けられるんじゃないの？

ここの系列で出たことあるのか知らないし、ちょっと毛色違うんだけど設定ファイル言語で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からオプションだけど

>>34
スマポ使えばいいだけだからそれはない

>>37
スマポがまさに>>34のパターン使ってるんだけど

スマートポインタｗって正直使う必要殆ど無いのに
全てのインスタンス生成で使うバカがいるよねｗ

今時生ポインタでイキルバカが出てくるとはw

スタックに確保されるのがポインタなのかクラスや構造体の実態なのかをちゃんと理解してない人が多すぎるね
コンパイラとかコンピュータアーキテクチャの勉強すべき
そこを避けてたら絶対に使いこなせない

そもそもスタックやらヒープやらちゃんと意味が分かっている奴って
アセンブラレベルで組んだことがあるとかじゃないと
知らなくても仕方ない気がするなぁ

使いこなす必要は無くて、理解が足りなくてもやりたい事が出来れば、それで良いと思うよ。

理解してなくてやりたいことができるってそれはたまたま動いてるか
その機能が必要ないことをやってるだけ
壁が来た時ぶち当たって手遅れになる
最近スクリプト言語系のエンジニアがRustとかのモダン言語で苦しんでるのを見ると
何が理解できてないのか？を理解することってのはすごく大事

Compiler explorerとかでコードがどんな風に最適化されてアセンブリ言語になるか読んでみるといいかもね。
スタックに割り当てられたローカル変数はレジスタに割り当てられる場合はあるけどグローバル変数やヒープにある変数はかならずメモリ上におかれるから毎回メモリからレジスタにロードして値を計算してからメモリにストアされる。

最適化でキャッシュの考慮や制御までするんだから
volatileないと実際どうなるかはわからんとちゃうかな

Rustやるなら当然アセンブラが理解できないとってことだね
メモリ安心安全のためには必要なコストだよね

プログラム書くのが本業の人なら、どうやってプログラムが動くのか知らなきゃっていうのは分かるけれど、プログラムば手段であって、コピペでも何でも良いから欲しい結果が得られるなら良いって人もいるから。

それで、Rustがそんな人に合わせる必要はないし、そんなのはPython辺りに任せて、Rustはプロフェッショナルの道具でいいんじゃないの？

それでいいよ
あっちのスレの空気持ち込まないでくれ

>>47
アセンブリ知ってて損することはないけど、必須な知識ではないよ
スタックやヒープの区別について分かっていればよくて、理解のための手段のひとつとしてアセンブリが提案されているだけ
他の手段で理解できるならそれで良い
Cを使いこなすのにアセンブリの知識が必須ではないのと同じ

書いたコードがどんな機械語になってるか、確認してない層が一定数存在するって事？
周りに居たら嫌だなぁ

どんなバイナリになるかイメージはするけど確認なんてしないだろ
最適化ビルドするとまるで想像通りじゃなくてびびったりはする

>>52
だよね。

>>42
俺特殊なハードウェア用のコンパイラとか作ってたんだけど
コンパイラ作ってようやくCがちゃんと理解できたよ
マジでコンパイラ作らないとわらないと思う

https://www.kinokuniya.co.jp/f/dsg-01-9784797337952
ISBN 4797337958

>>55
これはまあまあおすすめ
ただ32bitCPU時代に書かれた本なのでそこが微妙なのと
理論的なものがほとんどなく構文解析もJavaCC使ってるし
コード生成も毎回演算結果をスタックにpushするようなことをやってた気がする
allocaも自前で実装するし
ただCのような言語をアセンブリ言語へコンパイルするための勉強としては悪くない

著者はruby厨
racc使う予定だったらしい

intel ISAのドキュメントがオレオレ用語多くて意味わからん

あげ

nimも早くnull安全にしてくれないかね。

ドラゴンブックを見て一つ一つ実装していくのが良いですよ。
誤植が猛烈に多いのも練習問題のような気がしてきますよ。

>>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
COBOL++でしょ

>>69
スタックフレームならではの特性をコードに明記できる、といったイメージ。
例えばスタックにあるインスタンスしか受け付けない(参照)引数とかあれば、shared ptrとかunique ptrの参照渡しも安全に使える。
Rustがそこそこいい感じなんだけど、なんか中途半端。

>>72
Rustなら実用上はCopyで十分

>>73
rustの話は向こうのスレでお願い

>>73
そういうのが中途半端だと言っている。日本語も読めないのかよ。

800 デフォルトの名無しさん sage 2022/09/15(木) 23:09:10.28 ID:KFRYW2wo
次スレはこれらの言語を入れてください
Zig
https://ziglang.org/ja/
Jakt
https://github.com/SerenityOS/jakt

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

http://2chb.net/r/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

Rust「…」

検証�@�A

>>87
時間比較する時は
時間で昇順ソートした表を掲載して下さい

>Nimが想像より遥かに速くて「Cと同程度」以上の結果

Nimが速いのはトランスパイラだからな

Nimの実行速度はGCCと同等と思って良い

他人が比較したやつを載せるんじゃなくてお前が比較したやつ載せろよ

なら >>91 が 比較しろ

何でやねん

今更だけど、スレタイが前スレとは違う言語だらけで
マイナーなのをウォッチする別スレかと思ってたわ

TypeScript、Go、Swift、Kotlinって次世代でも何でもなく普及しきってる現役言語で、それぞれ言語別のスレが伸びてるし、
ここはこのスレタイで良いと思うわ

Gleamだけ知らんのだがどんな言語？

https://gleam.run/
Rust製のErlang、JavaScriptトランスパイラ、という事で語れる人集合！
>>91が比較したら見直すぞ！

新言語Verse
https://simon.peytonjones.org/assets/pdfs/haskell-exchange-22.pdf
関数型でUnreal Engineに組み込むらしい

Nested Choice面白いな

おお、まだJuliaの名前が見られるとは

Zigは一般運用していいレベルだと触って感じた

一般運用が何をさしてるか不明だけど
仕事で広範囲に使うのは厳しいんじゃ ?
1.0に達して無くて仕様も変更され続けてるし

いつの間にかスレタイNim以外聞いた事ない言語名になってた

Cyber言語
https://cyberscript.dev/index.html

Luajitの3倍高速な組み込み用のスクリプト言語
Pythonライクなインデント

Luaよりも人気でるかも
組み込み用途なので汎用的には流行らないと思うけど

>>104
lua嫌いだから頑張ってほしいな。

TEST

Googleって何個流行らん言語開発する気なんやろな
コトリンも結局流行らんかったし
goも流行ってるかと言われると微妙やし
カーボンなんて絶対はやらんわ

Google Chrome、プログラミング言語「Rust」の採用を発表
https://news.mynavi.jp/techplus/article/20230113-2561774/

>>107
kotlinはGoogleちゃうぞ。JetBrains。

>>109
そうやったんか
泥の印象しかないから思いこんでたわ

>>104
CyberってZigで書かれてるんだな。
あと非JITのインタープリターなのに高速なのは普通にすごい、これは応援するわ。

Zig言語が v1.0 でリリースされるのは
3年後らしい
うまくいっての話だから普通ならさらに2，3年は遅れるかも

WebAssemblyにガベージコレクション機能が登場、Chrome 111で試験的実装に。Dartなど高級言語のWebAssembly対応へ前進
https://www.publickey1.jp/blog/23/webassemblychrome_111dartwebassembly.html

おお

すべてのGC言語に対応するGC実装を決められない
から困難と言ってたと思うがまとまるんだろうか

https://github.com/WebAssembly/gc/blob/master/proposals/gc/Overview.md
この辺みても到底詳細仕様が決まるようには見えないし
先陣を切って自分の都合の良いように決めるために、Googleがゴリ押し始めたんだろうね
まあQUICはうまくいった感あるし、Chromeの影響力を考えると一気に進みそうだね

ここからが勝負なのよね
ライセンス上の制約が少ない言語なら何でもいいから早く覇権決めて欲しい

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

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

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

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

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

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

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

王者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もサポートされてないのね。

Nimじゃ駄目なんですか？

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

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

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エコシステムへのアクセスも提供される。

Mojoは早くOSSにしろよ

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

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

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

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

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

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

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

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

構文解析的にはほぼ同じ

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

>>141
PDAの実装は？

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

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

>>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ブロックよりフローが明確になって良いね
これって他言語にもある言語仕様なのかな

>>148
つ アダムタッチ

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でも変わらないんじゃない?

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

待望の新言語

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

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

>>158
1.0も遠のいた？

>>159
1.0も遠のいた…

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

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

>>160
おぅ、、、orz

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

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

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

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

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

nim良いよね

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

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

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

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

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

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

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

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

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

>>174
どのベンチ？ｗ

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

>>131　続報

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

Zigに頑張ってほしい

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

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

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

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

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

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

Are

ちょっと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を嫌ってるだけだな

compiletじゃなくてcomptimeだった

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なのか。

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

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

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

Odinはいかが？

>>196
わかります

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

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という言語があったが結局流行らなかった。

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

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フレームワークのメンテナ居なかったか？

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

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

掘り直したら actix-web だった。
以下のページが日本語で問題まとまってる。
https://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ユーザを直接取りに行ったほうが良かったかもね

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

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

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

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

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

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

待望の新言語

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

待望の新言語

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作ってるってのはこれだったのか
トランスパイラ方式にしたんだな

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

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

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/

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

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

どんぐりテスト

hoshu

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

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

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

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

待望の新言語

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

本末転倒だろ

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

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

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

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

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

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

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

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

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

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

RustがNimより速い訳がない

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

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

266です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

待望の新言語

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

記述言語OCamlじゃん‥

Haxeを想起させる

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

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

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

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

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

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

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

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

Perlの$%@は良かった

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

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

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

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