次世代言語27 Nim Zig Pony Carbon Gleam

2022/08/05(金) 09:40:50.22

!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

2022/08/16(火) 19:04:37.29

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

2022/08/16(火) 19:50:02.47

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

2022/08/17(水) 15:25:42.74

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

2022/08/17(水) 16:47:04.91

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

2022/08/17(水) 17:41:05.70

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

2022/08/17(水) 17:53:10.26

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

2022/08/17(水) 20:56:42.47

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

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

2022/08/17(水) 21:08:17.88

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

2022/08/17(水) 22:39:10.52

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

2022/08/17(水) 23:44:30.76

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

2022/08/18(木) 00:15:49.61

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

2022/08/18(木) 00:23:55.46

>>52
だよね。

2022/08/18(木) 01:11:39.51

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

2022/08/18(木) 11:25:09.48

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

2022/08/18(木) 12:21:45.00

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

2022/08/18(木) 14:58:14.10

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

2022/08/18(木) 21:22:03.04

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

2022/09/05(月) 00:54:15.45

あげ

2022/09/05(月) 01:08:51.55

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

2022/09/05(月) 01:34:04.91

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

2022/09/05(月) 08:15:38.43

>>60
このあたりは偏執狂のRustの方が上手だな。
いっそのこと参照型のゼロ値は禁止すればいいのに。

2022/09/05(月) 22:33:29.07

>>60

std/options で

ひとまずOK じゃないか ?

2022/09/06(火) 04:20:51.68

Not nil annotationはversion2.xで使えるようになるらしいよ。
https://github.com/nim-lang/RFCs/issues/437

2022/09/06(火) 08:29:06.48

>>64
not nil がデフォルトになるとあるね。

2022/09/06(火) 13:26:12.50

>>64

2.0がいつ出るかなんて全く不明
1.8.0の次は1.10.0
次は1.12.0となって。。。
恐らく5年以上先 ?

2022/09/08(木) 12:38:55.89

スタックフレームて大抵の実行環境で使用されているのに、スタックフレームに特化した言語て無いよね。
なんでなんだろう？

2022/09/08(木) 17:28:20.37

世の中のほとんどのプログラムにはヒープメモリが必要だからでしょ。
実行時じゃないとサイズがわからないことがあるし、スタック上に動的にメモリ領域を確保できるようにするとかなり大きめにスタックを確保しなくてはならくなるだろうし。

2022/09/08(木) 18:05:59.15

スタックフレームに特化した言語ってどういうものを想定してるの？
Forthみたいなスタック指向の言語とは違うよね

2022/09/08(木) 18:22:30.25

実CPUのスタック操作なんて仕様にいれたら足枷だしね
関数のABIとは別に仮想的なローカルスタックを扱えるかんじ？

2022/09/08(木) 18:50:48.63

>>69
COBOL++でしょ

2022/09/08(木) 19:36:15.16

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

2022/09/08(木) 21:06:39.94

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

2022/09/08(木) 22:22:15.01

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

2022/09/09(金) 07:32:44.98

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

2022/09/16(金) 11:26:01.87

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

2022/09/16(金) 11:34:21.79

Jaktは知らないな
どんな処理系かな

2022/09/16(金) 11:58:16.96

パッと見の構文はRustソックリ
borrow checkerはなく、代わりにARCを使って実行時にメモリ管理しようとしてるっぽい

なんでRustやZig使わないんだろうと気になったけど、自作したSerenityOSのためのエコシステムはできるだけすべて自作したい、くらいの動機みたい
参考: https://awesomekling.github.io/Memory-safety-for-SerenityOS/
まあZig未満のドマイナー言語にとどまりそう

2022/09/16(金) 12:01:00.82

書き忘れた
jaktはC++へのトランスパイラ、ってのも特徴

SerenityOSはC++で作ってたから、C++トランスパイラにすれば移行しやすかったってことだろう

2022/09/18(日) 13:44:05.76

トンズラパイラに観えた

2022/09/28(水) 19:48:23.69

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と同程度」以上の結果が出た。

2022/10/09(日) 07:33:11.55

検証 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

2022/10/09(日) 07:34:33.26

感想:
Juliaは確かに速いが、他との比較は最適化オプションしだい。

動的配列/リストのベンチになるかと思ったが、やってみたらgccが振るわない。
原因はmodulo計算の最適化の違い？ https://godbolt.org/z/T7bKK14fr

ZigはLLVMのmodulo最適化をトリガー出来なかったか。

OdinはLLVM AOTコンパイラとしての性能を引き出せている(今回は)
まだ言語機能の特徴をつかんでいないが、映画、ゲームグラフィックス分野で使う様な
ライブラリが最初から入っているのが売り？

Nimは殴り書きとか、書き捨てとか、簡潔に書けて、gcc/clangの速い方を選べて、
fastmodの様なC++「header only」のライブラリを手軽に利用できるのが良い。

Cythonも慣れたらNimと同じように出来るのだろうか。

2022/10/09(日) 11:10:02.48

並べるときは速度の早い順で書いて下さい

2022/10/31(月) 12:29:04.61

「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

2022/10/31(月) 13:03:53.85

Rust「…」

2022/11/13(日) 10:14:16.92

検証①②
https://i.imgur.com/EjOYpAq.png

2022/11/13(日) 17:19:42.67

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

2022/11/14(月) 11:28:56.72

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

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

2022/11/19(土) 20:53:35.05

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

2022/11/28(月) 15:07:09.33

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

**デフォルトの名無しさん** (JP 0Hcf-RPwI) · 2022/11/28(月) 17:49:52.29

なら >>91 が比較しろ

2022/11/28(月) 18:00:59.49

何でやねん

2022/11/28(月) 18:40:44.25

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

2022/11/29(火) 00:59:42.07

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

2022/11/29(火) 12:05:03.27

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

2022/11/29(火) 15:23:09.06

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

2022/12/12(月) 11:40:34.09

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

2022/12/18(日) 01:37:12.14

Nested Choice面白いな

2022/12/18(日) 11:18:36.47

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

2022/12/24(土) 17:31:02.76

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

2022/12/25(日) 14:55:22.12

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

2023/01/03(火) 23:06:21.96

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

2023/01/05(木) 00:37:52.42

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

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

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

2023/01/05(木) 01:10:08.86

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

2023/01/10(火) 00:06:39.20

TEST

2023/01/21(土) 14:23:16.05

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

2023/01/21(土) 15:29:58.89

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

2023/01/21(土) 18:31:14.57

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

2023/01/21(土) 19:13:09.85

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

2023/01/26(木) 11:26:58.76

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

2023/02/01(水) 15:25:14.11

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

2023/02/06(月) 08:25:04.30

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

2023/02/06(月) 09:11:15.73

おお

2023/02/06(月) 09:44:38.64

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

2023/02/06(月) 11:44:22.80

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

2023/02/06(月) 12:44:04.53

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

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の実装は？