X

次世代言語27 Nim Zig Pony Carbon Gleam

2022/08/05(金) 09:40:50.22ID:/hLfNpmA0
!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/05(金) 12:18:02.18ID:X0qTPiXKM
乙
3デフォルトの名無しさん (ﾜｯﾁｮｲ ba7c-t4GX)
垢版 |
2022/08/05(金) 20:57:32.27ID:IaHwMjJC0
本スレ
2022/08/05(金) 23:22:06.64ID:mIb2aBTZ0
ただし Rust言語ネタは禁止します
5デフォルトの名無しさん (ｱｳｱｳｳｰ Sa55-9Xv3)
垢版 |
2022/08/06(土) 15:25:50.11ID:eSBCWCwIa
>>1
O2
2022/08/07(日) 04:00:41.01ID:40aW3DD80
久々にHaxeのプロジェクトページを訪ねてみたらサポートターゲットにHashLinkなるVMが追加されていた
Nekoの後継？
2022/08/07(日) 13:37:10.92ID:Dd35QVWO0
過疎やん
8デフォルトの名無しさん (ｽｯｯﾌﾟ Sd33-agxP)
垢版 |
2022/08/07(日) 15:10:39.88ID:G9vPq40Zd
>>6
haxeまだあったのか。
昔ちょろっと見てけっこう良さそうな印象持ったけど流行らなかったな。
nimもトランスレーター系だし、同じ将来にはならないで欲しい。
結局はバックにGAFAMがつくかどうかによるのかねぇ。
それでいうとpythonは運・タイミングが良かったのか。
2022/08/07(日) 15:41:37.32ID:SSq6cfdBp
nimとかD言語みたいなちょっと良くした程度の言語だと流行らないんだろうなあ
RubyでいうRailsみたいな超人気フレームワークが登場すると話が変わってくるんだろうけも
2022/08/08(月) 01:27:47.98ID:mO/LiGB20
>>9
NimはもっとシームレスにPythonソースを使えればいいんだけど。
nimpyとかnimporterとかって公式になったっけ？
2022/08/08(月) 15:07:53.58ID:XhYLtnJ40
>>10
nimpyやnimporterが公式になるってどういうこと?
標準ライブラリになることを期待してるのかもしれないが、標準ライブラリになったとしても使いやすくなるとは限らないよ。
C/C++のライブラリだったらc2nimやfutharkというツールがC/C++のコードを読んで自動的にバインディングを生成してくれるらしい。
futharkはlibclangを使ってコードをパースするらしい。
2022/08/11(木) 04:05:29.11ID:Bpvt7Gu80
CarbonってC++のABI問題の拗れが引き金となって生まれたものなんだろうけど
わざわざ文法から作り直すことないのにな
実用的なレベルになるまで相当かかりそう
2022/08/11(木) 08:03:21.25ID:6LydNS9Hd
GoogleでC++の糞の山のメンテばっかりさせられて嫌気が差したんだろ
所詮数あるホビー言語の一つに過ぎないんだから好きにさせてやれよ
2022/08/12(金) 13:09:15.20ID:0xlDyyucM
>>11
公式になって手順・ドキュメントが整備されるというということだな。
そうすればもっとpythonコードが流用しやすくなるので、性能で困っているpythonユーザーが手を出しやすくなるかと。
15デフォルトの名無しさん (ﾜｯﾁｮｲ 937c-agxP)
垢版 |
2022/08/12(金) 15:40:56.79ID:bDQmrk+50
nimのアンダースコアを無視する仕様は好きじゃない。
2022/08/12(金) 18:28:24.07ID:D0nb2yzy0
>>14
公式になったからといってドキュメントが整備されるとも限らないし
公式にならなくてもやる気があればドキュメントを整備するＰＲを送ればいいのでは。

>>15
アンダースコアを無視するおかげで、ライブラリがfoo_barみたいな名前を使っていてもライブラリを使う側のコードがfooBarという名前で呼び出せるので命名規則に一貫性をもたらすことができる。
しかしCのライブラリがfoo_barとfooBarという異なる二つの関数を持っているとNimから使うときに違う名前を使って参照するようにbindingを書かなくてはいけなくなってしまう。
そいいうケースはあまりないけどね。
17デフォルトの名無しさん (ﾜｯﾁｮｲ 468c-Waa7)
垢版 |
2022/08/13(土) 22:42:00.05ID:6wAoLN5t0
Rustを見てて疑問に思うところがあるんだけど、
「コールスタック専用変数」「ヒープ用変数」といった
使い分けをする言語はあるのかしらん？
現状の言語で近いのは
C：変数はコールスタック専用。ヒープのインスタンスはポインタで管理
Rust：変数はコールスタック専用。ヒープ用変数はBox、Vec、Rcとかで模倣
ぐらいか。
コールスタックにあるインスタンスはスコープに連動するRAIIとかの便利な特性があるから、
他の言語でもコールスタック専用変数があってもいいと思うんだけど。
例えばJavaにコールスタック用変数があればfinalizeメソッドももっと使いやすくなりそう。
コールスタック用変数専用クラスとかあってもいいし。
2022/08/13(土) 23:29:46.92ID:601ao6Evd
スタックとヒープの使い分けができるという意味ならGoとかC#とか
2022/08/14(日) 01:50:30.53ID:H+Dty+yM0
>>17
Nimでもスタックとヒープを使いわけられるよ。
refのついた型とクロージャの環境とstring, seqの中身はヒープに確保される。
それ以外のローカル変数はスタックに確保。
C言語のグローバル変数とstatic変数はstatic storageというスタックとは別の所に置かれるよ。

だいたいのシステムプログラミング言語ならヒープとスタックを使い分けられるんじゃないの？
2022/08/14(日) 01:50:48.23ID:H+Dty+yM0
>>17
Nimでもスタックとヒープを使いわけられるよ。
refのついた型とクロージャの環境とstring, seqの中身はヒープに確保される。
それ以外のローカル変数はスタックに確保。
C言語のグローバル変数とstatic変数はstatic storageというスタックとは別の所に置かれるよ。

だいたいのシステムプログラミング言語ならヒープとスタックを使い分けられるんじゃないの？
2022/08/14(日) 01:53:56.93ID:XCwSZ99k0
>>18
変数のエスケープ解析して自動でヒープとスタックを使い分けるんじゃなくて、その変数をスコープからエスケープするような使い方をしたときにコンパイルエラーにするようなのを想定しています。
スタックフレーム制約付き変数ですな。
2022/08/14(日) 02:03:29.71ID:XCwSZ99k0
>>20
確か、Nimもスタックフレームにインスタンスを置くことを強制できなかったかと思うけど、どうだったっけ？
2022/08/14(日) 02:10:20.77ID:H+Dty+yM0
>>17
Nimでもスタックとヒープを使いわけられるよ。
refのついた型とクロージャの環境とstring, seqの中身はヒープに確保される。
それ以外のローカル変数はスタックに確保。
C言語のグローバル変数とstatic変数はstatic storageというスタックとは別の所に置かれるよ。

だいたいのシステムプログラミング言語ならヒープとスタックを使い分けられるんじゃないの？
2022/08/14(日) 02:20:35.55ID:H+Dty+yM0
間違えて連続投稿してすいませんでした。
>>22
type
　SomeObj = object
　　x: int

proc foo =
　var x = SomeObj(x: 10) #スタックに確保
　var y = new(SomeObj) #ヒープに確保

foo()
2022/08/14(日) 09:07:22.22ID:5kZWLu5Dd
ここの系列で出たことあるのか知らないし、ちょっと毛色違うんだけど設定ファイル言語でDhallってあるんだね
方向性は凄く好みなんだけど最新バージョンの規格をそのまま食えるのが現状Haskell（とPureScript?）だけらしくて君らそういうところやぞ……ってなってる

yamlやjsonに変換してから食わせることはできるらしいけどやっぱそのまま食えるのと手間と複雑さは無駄に嵩張るし、この手のDSLはどれだけ広い環境で使えるかが重要よねって
2022/08/14(日) 09:18:07.39ID:E6D9Byfed
>>21
C#はスタック変数のエスケープは不可で、その参照を返すようなことはできない
クロージャでキャプチャされたり非同期メソッドの場合にヒープに昇格する例外はあるが、文脈から明らかであり、いわゆるエスケープ解析とは異なるものだ
更に、構造体を ref struct として定義することで上記のような昇格も不可となり、完全にスタック専用になる
2022/08/14(日) 10:18:19.35ID:osAuRY7C0
>>25
ちょっとぐぐってみたけど俺はできると思ってる子がなんかこれあったら便利やんって言うのを色々詰め込んだイメージ
本当にでかい設定ファイルなら嬉しいのかも知れないけど大多数の設定ファイルにはオーバースペック過ぎて流行らないと思う
2022/08/14(日) 10:55:58.43ID:lDco67Nc0
オーバースペックさで言うとyamlも相当だしそれだけでは判断できないのでは
2022/08/14(日) 19:14:39.32ID:1Y4ysm770
スタックとかヒープとか基本的に実装依存じゃないの
言語レベルで規格として策定されてるのある？
2022/08/14(日) 19:23:27.68ID:TMCPzdUa0
CやC++はmallocやらnewなどでメモリ確保しない限りは全てスタックではないの？
今時のコンパイラはどうやってるのか知らんけど昔は少なくともそうだった
2022/08/14(日) 19:43:04.36ID:H+Dty+yM0
可変長配列とか文字列型などの必要なメモリ量が実行時に決まるものや
関数やブロックのスコープと変数の寿命が対応しないもの(GCで管理されるオブジェクト)などはヒープ使うしかないでしょ。
けどローカル変数などをヒープに置くと効率悪いし。
2022/08/14(日) 19:55:23.52ID:osAuRY7C0
>>29
ハードウェアスタックがないマシン（汎用機とか）もあるから実装依存なのは確かだけどそういうマシンでもソフトウェアでスタック作ってるので実装としてはたいして変わらん
2022/08/14(日) 19:58:39.91ID:H+Dty+yM0
>>30
関数の外にある変数やstatic変数はstatic storageというプロセスが生まれてから死ぬまで存在し続ける領域に置かれるよ。
詳しくはdata segmentとかbssとかで検索してね。
static変数は値を保持し続けないといけないからスタックに置けないし、
関数の外にある変数は複数の関数から共有されるのでコンパイル時かリンク時にアドレスが決まってないといけないと思うのでおそらくスタックに置けない。
2022/08/14(日) 20:34:35.63ID:d/RE/iMKa
C++の定石としてオブジェクトはスタックに置くのが基本だよ
デストラクタを動かしたいからね
ヒープにデータを割り当てたい時は構造体やクラスでラップするのが基本
2022/08/14(日) 20:39:54.05ID:lDco67Nc0
>>29
最適化の余地残すために規格では振る舞いしか記述しないのが基本だと思う
レジスタだけ使うとかあるしね
2022/08/14(日) 20:50:39.49ID:/dHI52Jsd
可変長配列に限って言えばCは一応VLAがある
11からオプションだけど
2022/08/15(月) 08:38:26.95ID:qDRL1WTlM
>>34
スマポ使えばいいだけだからそれはない
2022/08/15(月) 13:39:10.26ID:SFJl5V0da
>>37
スマポがまさに>>34のパターン使ってるんだけど
2022/08/15(月) 15:41:07.32ID:qHbAfBQi0
スマートポインタｗって正直使う必要殆ど無いのに
全てのインスタンス生成で使うバカがいるよねｗ
2022/08/15(月) 16:32:14.78ID:zxOEKBbO0
今時生ポインタでイキルバカが出てくるとはw
2022/08/16(火) 18:56:36.29ID:1oXHhIiq0
スタックに確保されるのがポインタなのかクラスや構造体の実態なのかをちゃんと理解してない人が多すぎるね
コンパイラとかコンピュータアーキテクチャの勉強すべき
そこを避けてたら絶対に使いこなせない
2022/08/16(火) 19:04:37.29ID:JSsOGCvC0
そもそもスタックやらヒープやらちゃんと意味が分かっている奴って
アセンブラレベルで組んだことがあるとかじゃないと
知らなくても仕方ない気がするなぁ
2022/08/16(火) 19:50:02.47ID:RYKZv1s10
使いこなす必要は無くて、理解が足りなくてもやりたい事が出来れば、それで良いと思うよ。
2022/08/17(水) 15:25:42.74ID:DfCxGnRFa
理解してなくてやりたいことができるってそれはたまたま動いてるか
その機能が必要ないことをやってるだけ
壁が来た時ぶち当たって手遅れになる
最近スクリプト言語系のエンジニアがRustとかのモダン言語で苦しんでるのを見ると
何が理解できてないのか？を理解することってのはすごく大事
2022/08/17(水) 16:47:04.91ID:hcUDPGl30
Compiler explorerとかでコードがどんな風に最適化されてアセンブリ言語になるか読んでみるといいかもね。
スタックに割り当てられたローカル変数はレジスタに割り当てられる場合はあるけどグローバル変数やヒープにある変数はかならずメモリ上におかれるから毎回メモリからレジスタにロードして値を計算してからメモリにストアされる。
2022/08/17(水) 17:41:05.70ID:J/baCQNr0
最適化でキャッシュの考慮や制御までするんだから
volatileないと実際どうなるかはわからんとちゃうかな
2022/08/17(水) 17:53:10.26ID:cnWCAZlk0
Rustやるなら当然アセンブラが理解できないとってことだね
メモリ安心安全のためには必要なコストだよね
2022/08/17(水) 20:56:42.47ID:9RiCNb2+0
プログラム書くのが本業の人なら、どうやってプログラムが動くのか知らなきゃっていうのは分かるけれど、プログラムば手段であって、コピペでも何でも良いから欲しい結果が得られるなら良いって人もいるから。

それで、Rustがそんな人に合わせる必要はないし、そんなのはPython辺りに任せて、Rustはプロフェッショナルの道具でいいんじゃないの？
2022/08/17(水) 21:08:17.88ID:3noakHYk0
それでいいよ
あっちのスレの空気持ち込まないでくれ
2022/08/17(水) 22:39:10.52ID:SgLVBpM30
>>47
アセンブリ知ってて損することはないけど、必須な知識ではないよ
スタックやヒープの区別について分かっていればよくて、理解のための手段のひとつとしてアセンブリが提案されているだけ
他の手段で理解できるならそれで良い
Cを使いこなすのにアセンブリの知識が必須ではないのと同じ
2022/08/17(水) 23:44:30.76ID:C+o8slGL0
書いたコードがどんな機械語になってるか、確認してない層が一定数存在するって事？
周りに居たら嫌だなぁ
2022/08/18(木) 00:15:49.61ID:uPozsGij0
どんなバイナリになるかイメージはするけど確認なんてしないだろ
最適化ビルドするとまるで想像通りじゃなくてびびったりはする
53デフォルトの名無しさん (ﾜｯﾁｮｲ 827c-Z8r5)
垢版 |
2022/08/18(木) 00:23:55.46ID:K1uqUAUE0
>>52
だよね。
2022/08/18(木) 01:11:39.51ID:yLDzsouG0
>>42
俺特殊なハードウェア用のコンパイラとか作ってたんだけど
コンパイラ作ってようやくCがちゃんと理解できたよ
マジでコンパイラ作らないとわらないと思う
55デフォルトの名無しさん (ｱｳｱｳｳｰ Saa5-oUG4)
垢版 |
2022/08/18(木) 11:25:09.48ID:p/limWqpa
https://www.kinokuniya.co.jp/f/dsg-01-9784797337952
ISBN 4797337958
2022/08/18(木) 12:21:45.00ID:yLDzsouG0
>>55
これはまあまあおすすめ
ただ32bitCPU時代に書かれた本なのでそこが微妙なのと
理論的なものがほとんどなく構文解析もJavaCC使ってるし
コード生成も毎回演算結果をスタックにpushするようなことをやってた気がする
allocaも自前で実装するし
ただCのような言語をアセンブリ言語へコンパイルするための勉強としては悪くない
57デフォルトの名無しさん (ｱｳｱｳｳｰ Saa5-oUG4)
垢版 |
2022/08/18(木) 14:58:14.10ID:qt1eMpHHa
著者はruby厨
racc使う予定だったらしい
2022/08/18(木) 21:22:03.04ID:1X5HVpNn0
intel ISAのドキュメントがオレオレ用語多くて意味わからん
59デフォルトの名無しさん (ﾄﾞｺｸﾞﾛ MM4f-06yp)
垢版 |
2022/09/05(月) 00:54:15.45ID:cFc+MJ1wM
あげ
60デフォルトの名無しさん (ﾜｯﾁｮｲ 5f7c-eJ3+)
垢版 |
2022/09/05(月) 01:08:51.55ID:9iTWKe040
nimも早くnull安全にしてくれないかね。
61デフォルトの名無しさん (ﾜｯﾁｮｲ 0701-Jj1I)
垢版 |
2022/09/05(月) 01:34:04.91ID:ARttffD10
ドラゴンブックを見て一つ一つ実装していくのが良いですよ。
誤植が猛烈に多いのも練習問題のような気がしてきますよ。
2022/09/05(月) 08:15:38.43ID:HWNfM8e/M
>>60
このあたりは偏執狂のRustの方が上手だな。
いっそのこと参照型のゼロ値は禁止すればいいのに。
2022/09/05(月) 22:33:29.07ID:1hFtemgL0
>>60

std/options で

ひとまずOK じゃないか ?
2022/09/06(火) 04:20:51.68ID:6xx96XME0
Not nil annotationはversion2.xで使えるようになるらしいよ。
https://github.com/nim-lang/RFCs/issues/437
2022/09/06(火) 08:29:06.48ID:AHhd6ypaM
>>64
not nil がデフォルトになるとあるね。
2022/09/06(火) 13:26:12.50ID:3wQQbwTr0
>>64

2.0がいつ出るかなんて全く不明
1.8.0の次は1.10.0
次は1.12.0となって。。。
恐らく5年以上先 ?
2022/09/08(木) 12:38:55.89ID:H4D+Re2GM
スタックフレームて大抵の実行環境で使用されているのに、スタックフレームに特化した言語て無いよね。
なんでなんだろう？
2022/09/08(木) 17:28:20.37ID:cKTVDYCV0
世の中のほとんどのプログラムにはヒープメモリが必要だからでしょ。
実行時じゃないとサイズがわからないことがあるし、スタック上に動的にメモリ領域を確保できるようにするとかなり大きめにスタックを確保しなくてはならくなるだろうし。
2022/09/08(木) 18:05:59.15ID:U6/gufpm0
スタックフレームに特化した言語ってどういうものを想定してるの？
Forthみたいなスタック指向の言語とは違うよね
2022/09/08(木) 18:22:30.25ID:ydRaiFc90
実CPUのスタック操作なんて仕様にいれたら足枷だしね
関数のABIとは別に仮想的なローカルスタックを扱えるかんじ？
2022/09/08(木) 18:50:48.63ID:11l7kxGRM
>>69
COBOL++でしょ
2022/09/08(木) 19:36:15.16ID:gDKj2SJwM
>>69
スタックフレームならではの特性をコードに明記できる、といったイメージ。
例えばスタックにあるインスタンスしか受け付けない(参照)引数とかあれば、shared ptrとかunique ptrの参照渡しも安全に使える。
Rustがそこそこいい感じなんだけど、なんか中途半端。
2022/09/08(木) 21:06:39.94ID:g68A8C0LM
>>72
Rustなら実用上はCopyで十分
2022/09/08(木) 22:22:15.01ID:D8Erj63H0
>>73
rustの話は向こうのスレでお願い
2022/09/09(金) 07:32:44.98ID:v1OYGNdb0
>>73
そういうのが中途半端だと言っている。日本語も読めないのかよ。
76デフォルトの名無しさん (ﾜｯﾁｮｲ a95f-Yvh5)
垢版 |
2022/09/16(金) 11:26:01.87ID:eTFy07in0
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.79ID:CoCetj5m0
Jaktは知らないな
どんな処理系かな
2022/09/16(金) 11:58:16.96ID:CoCetj5m0
パッと見の構文はRustソックリ
borrow checkerはなく、代わりにARCを使って実行時にメモリ管理しようとしてるっぽい

なんでRustやZig使わないんだろうと気になったけど、自作したSerenityOSのためのエコシステムはできるだけすべて自作したい、くらいの動機みたい
参考: https://awesomekling.github.io/Memory-safety-for-SerenityOS/
まあZig未満のドマイナー言語にとどまりそう
2022/09/16(金) 12:01:00.82ID:CoCetj5m0
書き忘れた
jaktはC++へのトランスパイラ、ってのも特徴

SerenityOSはC++で作ってたから、C++トランスパイラにすれば移行しやすかったってことだろう
80デフォルトの名無しさん (ｱｳｱｳｳｰ Sa5b-8eP5)
垢版 |
2022/09/18(日) 13:44:05.76ID:KpBP36NGa
トンズラパイラに観えた
2022/09/28(水) 19:48:23.69ID:Tun9Z/EC0
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.55ID:alq59Sy20
検証 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.26ID:alq59Sy20
感想:
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.48ID:hHOnLIUR0
並べるときは速度の早い順で書いて下さい
2022/10/31(月) 12:29:04.61ID:RFzpfvk70
「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.85ID:4lYEr6WH0
Rust「…」
2022/11/13(日) 10:14:16.92ID:lA0JSaU/0
検証①②
https://i.imgur.com/EjOYpAq.png
2022/11/13(日) 17:19:42.67ID:vYboHCwy0
>>87
時間比較する時は
時間で昇順ソートした表を掲載して下さい
89デフォルトの名無しさん (ｱｳｱｳｳｰ Saa9-FFna)
垢版 |
2022/11/14(月) 11:28:56.72ID:EWF0SvAna
>Nimが想像より遥かに速くて「Cと同程度」以上の結果

Nimが速いのはトランスパイラだからな
2022/11/19(土) 20:53:35.05ID:7QNjN12J0
Nimの実行速度はGCCと同等と思って良い
2022/11/28(月) 15:07:09.33ID:6X8/W5dUa
他人が比較したやつを載せるんじゃなくてお前が比較したやつ載せろよ
2022/11/28(月) 17:49:52.29ID:SIJnWXGqH
なら >>91 が 比較しろ
2022/11/28(月) 18:00:59.49ID:6X8/W5dUa
何でやねん
2022/11/28(月) 18:40:44.25ID:LDNjf6uN0
今更だけど、スレタイが前スレとは違う言語だらけで
マイナーなのをウォッチする別スレかと思ってたわ
2022/11/29(火) 00:59:42.07ID:QobrmxBH0
TypeScript、Go、Swift、Kotlinって次世代でも何でもなく普及しきってる現役言語で、それぞれ言語別のスレが伸びてるし、
ここはこのスレタイで良いと思うわ
96デフォルトの名無しさん (ﾜｯﾁｮｲ b74e-WfGi)
垢版 |
2022/11/29(火) 12:05:03.27ID:zwTDTYOm0
Gleamだけ知らんのだがどんな言語？
97デフォルトの名無しさん (ﾜｯﾁｮｲ 97f0-hCdI)
垢版 |
2022/11/29(火) 15:23:09.06ID:Vcr0dhdC0
https://gleam.run/
Rust製のErlang、JavaScriptトランスパイラ、という事で語れる人集合！
>>91が比較したら見直すぞ！
2022/12/12(月) 11:40:34.09ID:X5LmWbdvp
新言語Verse
https://simon.peytonjones.org/assets/pdfs/haskell-exchange-22.pdf
関数型でUnreal Engineに組み込むらしい
2022/12/18(日) 01:37:12.14ID:xkWav1uF0
Nested Choice面白いな
2022/12/18(日) 11:18:36.47ID:9uYd/N4Nr
おお、まだJuliaの名前が見られるとは
2022/12/24(土) 17:31:02.76ID:sDckaCi+0
Zigは一般運用していいレベルだと触って感じた
2022/12/25(日) 14:55:22.12ID:KZAI5vpb0
一般運用が何をさしてるか不明だけど
仕事で広範囲に使うのは厳しいんじゃ ?
1.0に達して無くて仕様も変更され続けてるし
2023/01/03(火) 23:06:21.96ID:EF4+Zmp+d
いつの間にかスレタイNim以外聞いた事ない言語名になってた
2023/01/05(木) 00:37:52.42ID:Xf8DhQg+0
Cyber言語
https://cyberscript.dev/index.html

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

Luaよりも人気でるかも
組み込み用途なので汎用的には流行らないと思うけど
105デフォルトの名無しさん (ﾜｯﾁｮｲ 5a7c-WW1s)
垢版 |
2023/01/05(木) 01:10:08.86ID:Ymjh5Awz0
>>104
lua嫌いだから頑張ってほしいな。
2023/01/10(火) 00:06:39.20ID:lqMsrQlz0
TEST
2023/01/21(土) 14:23:16.05ID:tJUqTfCaa
Googleって何個流行らん言語開発する気なんやろな
コトリンも結局流行らんかったし
goも流行ってるかと言われると微妙やし
カーボンなんて絶対はやらんわ
2023/01/21(土) 15:29:58.89ID:6AMuhJZU0
Google Chrome、プログラミング言語「Rust」の採用を発表
https://news.mynavi.jp/techplus/article/20230113-2561774/
2023/01/21(土) 18:31:14.57ID:DGuAb7AB0
>>107
kotlinはGoogleちゃうぞ。JetBrains。
2023/01/21(土) 19:13:09.85ID:mrhEz1eCa
>>109
そうやったんか
泥の印象しかないから思いこんでたわ
2023/01/26(木) 11:26:58.76ID:AA1/dHsVd
>>104
CyberってZigで書かれてるんだな。
あと非JITのインタープリターなのに高速なのは普通にすごい、これは応援するわ。
2023/02/01(水) 15:25:14.11ID:HrKHxNtD0
Zig言語が v1.0 でリリースされるのは
3年後らしい
うまくいっての話だから普通ならさらに2，3年は遅れるかも
2023/02/06(月) 08:25:04.30ID:2pHg0M5D0
WebAssemblyにガベージコレクション機能が登場、Chrome 111で試験的実装に。Dartなど高級言語のWebAssembly対応へ前進
https://www.publickey1.jp/blog/23/webassemblychrome_111dartwebassembly.html
2023/02/06(月) 09:11:15.73ID:JuD75zQDM
おお
2023/02/06(月) 09:44:38.64ID:fVls87ar0
すべてのGC言語に対応するGC実装を決められない
から困難と言ってたと思うがまとまるんだろうか
2023/02/06(月) 11:44:22.80ID:t4UlNWb00
https://github.com/WebAssembly/gc/blob/master/proposals/gc/Overview.md
この辺みても到底詳細仕様が決まるようには見えないし
先陣を切って自分の都合の良いように決めるために、Googleがゴリ押し始めたんだろうね
まあQUICはうまくいった感あるし、Chromeの影響力を考えると一気に進みそうだね
2023/02/06(月) 12:44:04.53ID:s421rGzSM
ここからが勝負なのよね
ライセンス上の制約が少ない言語なら何でもいいから早く覇権決めて欲しい
2023/02/17(金) 08:18:49.77ID:qlaClCnE0
FirefoxもWebAssemblyのガベージコレクション機能を実装中であることが明らかに
https://www.publickey1.jp/blog/23/firefoxwebassembly.html
2023/03/18(土) 09:36:05.92ID:GmA34DaYa
GPT-4で作られた新言語が出てきたな
これからは生成AIが言語を生成する時代かも
https://lukebechtel.com/blog/gpt4-generating-code
2023/03/25(土) 22:53:18.43ID:BSe5gihC0
所詮トランスパイルするだけの言語は終わる
TSやKotlinなど
2023/03/26(日) 09:50:29.12ID:t5F8xIRn0
C++は元々トランスパイルするだけの言語だったけど未だに終わってないぞ
2023/03/27(月) 14:32:28.74ID:CEoRbIwo0
>>120
直接コンパイルしているから終わらなかった
クラスを追加しただけのように見えてバイナリの速度も若干違うし
今や別物という扱いかと
2023/03/27(月) 21:45:38.89ID:ZY+RQ7940
Types as Commentsが通ったらTypeScriptは安泰
2023/04/08(土) 09:14:03.61ID:WXwwqEgX0
SafariもWebAssemblyのガベージコレクション機能の実装に着手。Technology Preview 167で明らかに
https://www.publickey1.jp/blog/23/safariwebassemblytechnology_preview_167.html
2023/04/13(木) 09:31:47.71ID:VEQIQK6j0
王者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.59ID:Ljj/ks5m0
待望の新言語

Mojo &# 128293;: Programming language for all of AI
https://www.modular.com/mojo
2023/05/07(日) 10:45:52.48ID:2alg5WM70
最終的にPython互換を目指すということだからPyInstallerの軽量な代替になってくれないか期待したいところだけど
まだclassもサポートされてないのね。
2023/05/07(日) 10:46:24.88ID:IEgposGn0
Nimじゃ駄目なんですか？
129デフォルトの名無しさん (ﾜｯﾁｮｲ cbda-0v65)
垢版 |
2023/05/07(日) 17:32:47.00ID:souVRU9G0
>>128
いい言語だと思うが、
開発者少ないのに複数言語へのトランスレートは厳しいよ。
Cのみに絞るか、せめてCとJavaScriptくらいに絞るべきだと思う。
2023/05/08(月) 00:18:12.54ID:7UdtJzN/0
Mojoの発音はそのまま喪女でいいんか？
2023/05/09(火) 15:00:49.20ID:cZVxEdl70
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.48ID:M80iwSIA0
Mojoは早くOSSにしろよ
2023/05/15(月) 06:04:50.19ID:EP98fI5GM
オフサイドルールは書かされてる感が強くて嫌いなんだけど、世間的には好意的なのか
2023/05/15(月) 19:15:35.36ID:fkhy8mxoM
>>133
オフサイドルールに限らず文脈依存文法は自動化が難しくなるのでセンス悪いと思うけど、ブロックは視覚的に認識しやすいから人気あるんだよなぁ。
YAMLみたいに併用できるならまだマシだけど。
2023/05/15(月) 22:35:11.34ID:aSVKjNnD0
オフサイドルールって文脈依存文法か？
2023/05/19(金) 12:22:48.77ID:fk0Gpq/FM
>>135
前後のインデントによってブロックが決まるから文脈依存じゃね？
137デフォルトの名無しさん (ﾜｯﾁｮｲ ff7c-OaH6)
垢版 |
2023/05/19(金) 18:44:24.43ID:fagGQhCY0
YAML拡張してifとかの制御構造入れるやつもいるからな。
2023/05/19(金) 22:29:50.83ID:O8g/UjD80
>>136
後ろのインデントには依存しないんじゃね
2023/05/20(土) 12:03:13.56ID:Ok/r6Mln0
オフサイドルールでブロック表すのも、ブレースでブロック表すのも、構文解析的にはは同じことでしょ
2023/05/20(土) 16:28:20.57ID:/tIrPGWZM
インデントの深さに依存するから、フレーズみたいに「現在のブロックを閉じる」だけの操作では済まない。
オフサイドルールのプッシュダウンオートマトン実装例あったっけ？
141デフォルトの名無しさん (ﾌﾞｰｲﾓ MM86-F7IQ)
垢版 |
2023/05/20(土) 16:36:35.19ID:A/kRENRgM
構文解析的にはほぼ同じ

間違ってても検出できない(ケースが多い)
オートフォーマットができない
のがデメリット
2023/05/20(土) 16:40:15.10ID:/tIrPGWZM
>>141
PDAの実装は？
2023/05/20(土) 16:43:18.84ID:PfZyfbnf0
前処理でブレース挿入して処理するから実際のパーサ部分は似たようなものって言いたいんだろうか
2023/05/20(土) 16:48:04.32ID:/tIrPGWZM
>>143
そりゃ乱暴すぎる。
145デフォルトの名無しさん (ﾌﾞｰｲﾓ MM27-F7IQ)
垢版 |
2023/05/20(土) 18:06:52.09ID:EUGtogADM
>>142
GHCとか

Pythonとかはlexerの段階でDEDENTトークンを生成してるから>>143の言う通り
2023/05/21(日) 01:17:46.07ID:CmXU6CGz0
https://docs.python.org/3/reference/lexical_analysis.html#indentation
Pythonの場合はここに書かれてるようにlexerの時点でスタックを使って処理できるという仕様だけど
他の言語のオフサイドルールはもっと複雑になるの？
2023/05/21(日) 15:37:31.99ID:7unpu3NzM
>>146
lexerの能力は高いだろ。
PDAは(Lexerとかと比べると)大したことできないよ。
2023/06/12(月) 15:08:29.37ID:kB7As+JK0
Zigの単行tryとcatchは馴染みないから怪訝してたけど使ってみるとtry-catchブロックよりフローが明確になって良いね
これって他言語にもある言語仕様なのかな
149デフォルトの名無しさん (ｽﾌﾟｯｯ Sd73-fEz/)
垢版 |
2023/06/12(月) 18:10:45.80ID:7lxvOpjdd
>>148
つ アダムタッチ
150デフォルトの名無しさん (ｽｯｯﾌﾟ Sd33-kZ0E)
垢版 |
2023/06/13(火) 16:03:31.28ID:xDyMFOGFd
NimってPythonのライブラリにアクセスしてfor文回すともはやNimに求めてた性能ははpythonよりになってしまうのでは？型推論できないからねぇ。
2023/06/13(火) 18:32:28.49ID:yeDPLuAI0
>>150
型推論は無関係な気がする
単にPythonライブラリの性能に律速されるだけ
2023/06/14(水) 07:40:07.84ID:8mvudo25M
pythonのダメ記法を捨てられるだけでもメリットデカイね。
2023/06/14(水) 11:21:50.21ID:iWYHYN4ra
for を python で描くと遅い
for は Nim で描いて
中身だけ python ならまだマシ
もちろんネイティブの速度ではないがそんなの Nim だからじゃなくて
C++ でも Rust でも python 呼べば同じ結果になるぞ
154デフォルトの名無しさん (ﾜｯﾁｮｲ 315f-kZ0E)
垢版 |
2023/06/14(水) 14:43:32.26ID:NMm4TZav0
>>153
for文をNimで書いて、中身をpythonにして実行速度を計測してみたらpythonオンリーとあまり変わらなくてがっかりしたという経験がある。ただ、自分のコーディングが悪かった可能性もあるけど。
2023/06/14(水) 16:19:12.32ID:rOshoQaM0
>>154
中身の計算コストがforループ自体のコストと比べて大きければNimでもpythonでも変わらないんじゃない?
156デフォルトの名無しさん (ﾜｯﾁｮｲ 4f5f-JtsX)
垢版 |
2023/07/04(火) 03:53:42.95ID:ZyJ9aZuM0
病∞！！！！
症∞！！！！！
漠∞！！！！！！
西∞！！！！！！！
卵∞！！！！！！！！
多∞！！！！！！！！！
2023/07/04(火) 09:47:08.65ID:c7VqsKCG0
待望の新言語

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.43ID:LIvlv7Wc0
Zig 0.11.0のマイルストーンが7月17日から8月3日に延期されてしまった
やはり未解決のissue多すぎて再延長もあり得るかこれは
159デフォルトの名無しさん (ｽﾌﾟｯｯ Sd7f-NY88)
垢版 |
2023/07/25(火) 11:52:50.13ID:yYWffJVbd
>>158
1.0も遠のいた？
2023/07/26(水) 00:31:41.04ID:gfwPzIhn0
>>159
1.0も遠のいた…

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

そんな中で脱LLVM構想も再浮上してるし1.0到達は当初の3年後どころか5年以内目処も危うい
161デフォルトの名無しさん (ﾜｯﾁｮｲ df7c-NY88)
垢版 |
2023/07/27(木) 10:40:07.68ID:2IasxSCw0
>>160
おぅ、、、orz
2023/08/01(火) 22:10:07.65ID:FfTXTju00
しばらくスレに来なかったらスレタイの言語知らんのばっかになっててわろた
2023/08/01(火) 22:28:49.01ID:ZDoiR0FV0
Nim 2.0が出たっぽい
しかしぜんぜん話題になってないな…
2023/08/01(火) 22:52:38.66ID:IyAK+cNZ0
そもそも、nimを宣伝しているようなblog記事以外で見かけたことがないしな。
2023/08/02(水) 01:14:41.81ID:4aCNkU8+0
Nimを使っている組織一覧:
https://github.com/nim-lang/Nim/wiki/Organizations-using-Nim
2023/08/02(水) 06:48:11.72ID:eH9ezqro0
>>165
RustよりもNimは実用的っぽいな
167デフォルトの名無しさん (ｱｳｱｳｳｰ Sa1f-IPSQ)
垢版 |
2023/08/02(水) 09:34:06.72ID:4pI1Wfnva
nim良いよね
2023/08/02(水) 21:45:09.21ID:9rX+LYDX0
本当、nimの話題って「nimは良い」しかないよな。
2023/08/02(水) 22:26:10.11ID:eH9ezqro0
nim以外ほとんど何か創ってないからな
170デフォルトの名無しさん (ﾜｯﾁｮｲ 6a4b-WXhB)
垢版 |
2023/08/03(木) 11:22:28.95ID:MLrVFD850
Nim 2.0がリリースされました。
https://nim-lang.org/blog/2023/08/01/nim-v20-released.html
2023/08/25(金) 08:02:23.50ID:fA2wbq8J0
JavaScriptランタイム「Bun」がバージョン1.0に到達へ、9月7日にローンチイベント開催
https://www.publickey1.jp/blog/23/javascriptbun1097.html

主な開発言語としてZigを採用し、メモリ管理などを含む低レイヤでの実装を実現することで、Node.jsやDenoよりも高速な動作を実現していると説明しています。
2023/08/25(金) 11:01:59.13ID:ssb8Cd/m0
>>171
v1.0の目玉だったWindowsネイティブサポートは結局実現できないままでリリース押し切ることにしたのか
173デフォルトの名無しさん (ﾜｯﾁｮｲ 7101-YAjS)
垢版 |
2023/08/25(金) 12:13:30.13ID:8Q06WpC+0
Rust製のDeno遅すぎｗ
https://dev.to/codesphere/bun-the-new-javascript-runtime-competing-with-deno-and-node-115d
174デフォルトの名無しさん (ﾜｯﾁｮｲ b302-5XGt)
垢版 |
2023/09/02(土) 16:19:08.80ID:yAII5uv80
それベンチによってはNodeが勝ってたりDenoが勝ってたりするから当てにならん
175デフォルトの名無しさん (ﾜｯﾁｮｲ ff7c-AIuG)
垢版 |
2023/09/02(土) 16:39:16.86ID:aKZIxXWD0
>>171
元言語のzigはいつ1.0になるんですかねぇ
2023/09/02(土) 18:20:03.74ID:8yObFq2T0
>>174
どのベンチ？ｗ
177デフォルトの名無しさん (ｽﾌｯ Sd1f-ETx6)
垢版 |
2023/09/07(木) 10:00:28.15ID:K6fFrmXfd
雨の日にうっかりベンチに座るとパンツがビショビショ濡れ濡れ
2023/09/12(火) 20:59:08.32ID:/qNKcCZu0
>>131　続報

Pythonの高速なスーパーセットをうたう新言語「Mojo」、コンパイラなど公開、ローカル環境で利用可能に
https://www.publickey1.jp/blog/23/pythonmojo.html
179デフォルトの名無しさん (ﾜｯﾁｮｲ 3f7c-/qTM)
垢版 |
2023/09/21(木) 00:39:19.15ID:hd16Ksmk0
Zigに頑張ってほしい
2023/09/22(金) 01:57:24.98ID:e0xvgrYz0
Zigはかなり期待してるので頑張って欲しいな
長いこと指摘されてるissueのclose速度が1日平均5件なのに増加速度は1日平均10件で
ずっと次のリリースにたどり着けないよ問題を結局どう解決する方針にしたんだろう
181デフォルトの名無しさん (ｽｯｯﾌﾟ Sd5f-/qTM)
垢版 |
2023/09/22(金) 12:28:56.47ID:FCvezg2jd
>>180
こんなんでBunはよく1.0にしたな。
2023/10/04(水) 15:32:29.96ID:N8iC4Qef0
https://harelang.org/
（海外の）FOSS、ミニマリスト、アンチRust界隈で流行ってる言語 Hare
C言語プログラマのために作られたとのこと
メモリ管理は自前だがいろいろ安全対策がされてるっぽい
Windows, Macは対応しないと宣言
183デフォルトの名無しさん (ﾜｯﾁｮｲ a37c-X5bY)
垢版 |
2023/10/04(水) 16:37:22.64ID:2V79m8iF0
Cの代替言語オーディン
https://odin-lang.org/
184デフォルトの名無しさん (ﾜｯﾁｮｲ a37c-X5bY)
垢版 |
2023/10/04(水) 16:42:29.89ID:2V79m8iF0
Cの代替言語オーディン
データ指向、カスタムアロケータ
https://odin-lang.org/

GitHubリポジトリ
https://github.com/odin-lang/Odin
185デフォルトの名無しさん (ｱｳｱｳｳｰ Sa89-5C2y)
垢版 |
2023/10/05(木) 17:09:32.57ID:WXXGTjkDa
Are
186デフォルトの名無しさん (ﾜｯﾁｮｲ 937c-cQ99)
垢版 |
2023/10/30(月) 01:15:43.08ID:SHIqNVOV0
ちょっとOdin触ってみた。
Zigより気に入った。
最適化がまだC/C++より弱いからエッジケースではC/C++,Rustにはパフォーマンスかなわないようがた、ぶっちゃけRustよりOdinのほうが書きやすい。
2023/11/02(木) 09:20:24.55ID:+8WanLaR0
WebAssemblyのガベージコレクションが正式機能に、最新版のChrome 119で。Firefoxも今月リリースのFirefox 120で正式機能になる見通し
https://www.publickey1.jp/blog/23/webassemblychrome_119firefoxfirefox_120.html
188デフォルトの名無しさん (ﾜｯﾁｮｲ 22f1-rrr/)
垢版 |
2023/11/21(火) 03:00:21.16ID:60zWiP9n0
zigのcompiletはCのatoi、atofみたいなのを1関数にまとめれるということ？
189デフォルトの名無しさん (ﾜｯﾁｮｲ 22f1-rrr/)
垢版 |
2023/11/21(火) 03:09:25.53ID:60zWiP9n0
wasmはどうせgcを採用するんだろうなと思ってたがやっぱりか
jdkと変わらん
190デフォルトの名無しさん (ﾜｯﾁｮｲ 22f1-rrr/)
垢版 |
2023/11/21(火) 03:12:08.32ID:60zWiP9n0
wasmは初期の頃jdkと何が違うの？と言われてた
jdkはバグが多いからとか説明してたが、実際そうでもない
なぜかその界隈の人達が漠然とjavaを嫌ってるだけだな
191188 (ﾜｯﾁｮｲ 22f1-rrr/)
垢版 |
2023/11/21(火) 04:46:48.83ID:60zWiP9n0
compiletじゃなくてcomptimeだった
192デフォルトの名無しさん (ﾜｯﾁｮｲ 22f1-rrr/)
垢版 |
2023/11/21(火) 05:27:43.98ID:60zWiP9n0
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なんでしょ？謎すぎ
193デフォルトの名無しさん (ﾜｯﾁｮｲ 22f1-rrr/)
垢版 |
2023/11/21(火) 05:34:22.13ID:60zWiP9n0
List()の型は匿名のstructだな
でもじゃあこれはなに？っていう
fn List(comptime T: type) type
引数に入力されたtypeの型が返値の型じゃないの？
2023/11/21(火) 10:29:25.70ID:Z3uiTyFT0
>>193
>>192の例で説明すると、引数として渡されたtypeはitemsフィールドの要素の型。
戻り値のtypeは匿名structの型。

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

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

あと引数に渡されるtypeは、戻り値を組み立てる型の中で、例えば「T.foo()」と書くことでT型はfoo関数の存在を制約として与えることもできる(foo関数を持たない型が渡されたらコンパイルエラー)。
195デフォルトの名無しさん (ﾜｯﾁｮｲ 22f1-rrr/)
垢版 |
2023/11/21(火) 11:43:47.98ID:60zWiP9n0
ありがとう分かった。
typeはzig標準型全体を指すものということか。
任意の標準型を受け取って、任意の標準型を返す総称型関数ということね。

ダックタイピングも分かった。
宣言じゃなくコードの内容から推論してコンパイルエラー出してくということね。
196デフォルトの名無しさん (ﾜｯﾁｮｲ 226b-rrr/)
垢版 |
2023/11/21(火) 14:41:07.08ID:60zWiP9n0
チュートリアル読んでるけどzig良い。
Cの代替としては最有力かな？
世の中はメモリ安全のためにRust推奨なんだろうけど。
本当はそっちに進んじゃいけない、と思ってる。
2023/11/21(火) 21:16:37.31ID:NcXE8D4H0
Zigのマイルストーン見ると先送りしてきたv0.11.1のバグ180件以上残ったままv0.12.0側のissueばっかり片付けてるな
これはついにマイナーバージョンアップ近づいて来たのかな
198デフォルトの名無しさん (ﾜｯﾁｮｲ 22f8-rrr/)
垢版 |
2023/11/22(水) 01:53:36.06ID:bjqLP0h40
linux kernelがrustのサポートを確定したという記事を読んだ。
だったらrustなのかなあ。googleもandroidをrustで書くらしい。
rustなのか。
199デフォルトの名無しさん (ﾜｯﾁｮｲ 22f8-rrr/)
垢版 |
2023/11/22(水) 03:30:03.94ID:bjqLP0h40
俺はzigやってこう・・・。
200デフォルトの名無しさん (ﾜｯﾁｮｲ 22f8-rrr/)
垢版 |
2023/11/22(水) 07:56:27.67ID:bjqLP0h40
いや、やっぱりrustかなあ。
将来のベアメタルプログラマーは抽象的な言語概念から逃げられないね。
そうなると、初学者はむしろマネージド言語から入るのかな。
2023/11/22(水) 12:13:14.04ID:Xn3ar1UbM
Cの後継としてZigは結構ありだと思うけど、
Cが残ってる分野ってISO標準とか組み込みベンダーサポートとかが必須な分野が多くて
Zigがそこまでたどり着くには10年とかかかりそうだよな…
202デフォルトの名無しさん (ｽﾌﾟｯｯ Sd82-ts/j)
垢版 |
2023/11/22(水) 12:17:19.10ID:o4kbjPDBd
Odinはいかが？
203デフォルトの名無しさん (ｱｳｱｳｳｰ Sa85-UHOz)
垢版 |
2023/11/23(木) 09:55:21.62ID:mHKDjshta
>>196
わかります
204デフォルトの名無しさん (ｱｳｱｳｳｰ Sa85-UHOz)
垢版 |
2023/11/23(木) 09:55:57.11ID:mHKDjshta
>>201
10年待てない人はNimで
205デフォルトの名無しさん (ﾜｯﾁｮｲ 226d-rrr/)
垢版 |
2023/11/23(木) 10:39:32.37ID:h/UsGTLS0
nimは概要を読む限り全然いいと思えない。
C++をさらに悪化させたような言語じゃないの？
206デフォルトの名無しさん (ﾜｯﾁｮｲ 226d-rrr/)
垢版 |
2023/11/23(木) 10:41:14.18ID:h/UsGTLS0
nim使うならC++で良いはずだよ。既に多用されてて信頼性あるし。
207デフォルトの名無しさん (ﾜｯﾁｮｲ 226d-rrr/)
垢版 |
2023/11/23(木) 10:53:59.84ID:h/UsGTLS0
odinのアイデアはほぼzigと同じじゃないか？
zigの方が先に出てきて、その直後にodinが出てきたようだ
メモリ安全と言われているようだが全くそうではないというレビューも見かけた。
後出し追いかけ言語で政治力とエンジニアリングのパワーで優っているのがodinということじゃないか？
Cの代替がzigのようなものであるべきという着眼点を最初にもたらしたのはzigじゃないだろうか
他にそういう方向性の言語がzigより先にあったのだろうか
208デフォルトの名無しさん (ﾜｯﾁｮｲ 226d-rrr/)
垢版 |
2023/11/23(木) 11:21:12.37ID:h/UsGTLS0
zigのwikipedia読んでたらCからの変更点という観点でzigが説明されてる。
Cを出発点としていくつかの改善点を加えた言語というのが重要なんだ。
その中でもメモリ安全とcomptimeによる類似関数をひとまとめにするというアイデアが重要と思う。
209デフォルトの名無しさん (ﾜｯﾁｮｲ 226d-rrr/)
垢版 |
2023/11/23(木) 12:21:13.00ID:h/UsGTLS0
fn () err!val
みたいな共用体を返す構文はCのerrnoとかC#のoutとかの代用になるのかな
共用体はenumと連携させてswitchで使えるようだから中身に応じて処理を分けれる
実際使ってみないと分からんが、まあ学習は順調に進むし良い印象がある
2023/11/23(木) 12:50:09.22ID:45eqFX8V0
>>205
>>206
Nimのどこがダメなんでしょうか?
少なくともC++よりシンプルな言語だし読みやすく書きやすい言語だと思うのですが。
2023/11/23(木) 13:59:38.28ID:/UTIXb+w0
NimはまぁPythonっぽい構文が好きな人にはいいかもねって感じなだけで
わざわざ他言語から乗り換えるような特徴がないんだよね
212デフォルトの名無しさん (ﾜｯﾁｮｲ 225b-rrr/)
垢版 |
2023/11/23(木) 14:59:02.66ID:h/UsGTLS0
NimはJavaとかC#みたいなクロスプラットフォーム性があるわけではないし
Cが使われているような領域で使えるものでもない
だからそういった領域では論外

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

という認識。Nimの言語仕様がJavaやCと比較して優れてる！とか言ってみても仕方ない。
競争相手になり得ない。
C++かRustと比較して総合的に優れてると言えたら重要なものになるだろうけど。
213デフォルトの名無しさん (ﾜｯﾁｮｲ 225b-rrr/)
垢版 |
2023/11/23(木) 15:03:11.78ID:h/UsGTLS0
nimはgcありとなしモードあるけどライブラリちゃんと動くの？
gcありじゃないとほとんどのライブラリが動かないということになるなら、
C++にもRustにも到底比較対象にならない
どの領域に入るつもりなんだという印象
214デフォルトの名無しさん (ﾜｯﾁｮｲ 225b-rrr/)
垢版 |
2023/11/23(木) 15:16:17.32ID:h/UsGTLS0
要するに、総合的に優れてるように思えても「あらゆる領域でちょっと負ける言語」は使われない。
戦略は？ということ。

C#やjavaと比較→ネイティブコード作れる！エレガントな文法！→java使ってる人達には全くどうでもいいです
Cと比較→たくさんの抽象的な言語概念！大規模開発に強い！→C使ってる人達には全くどうでもいいです
C++やRustと比較→GCがあって簡単にコーディングできるぞ！→彼らにはGCは不要あるいは邪魔です
2023/11/23(木) 15:46:50.74ID:o2OM8ETk0
NimのライバルはZigじゃなくてV言語だと思う
ベターCっぽいけどCの置き換えできないしC++にも届かないって立ち位置の点でね
(文法もC系ではなくPython系って側面も込み)
216デフォルトの名無しさん (ﾜｯﾁｮｲ 427c-ts/j)
垢版 |
2023/11/23(木) 18:39:43.19ID:AGqDCJM/0
>>207
＞odinのアイデアはほぼzigと同じじゃないか？

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

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

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


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

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


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

「zigのようなものであるべき」って言ったらzigしかないじゃん。
言ってることがメチャクチャ。
217デフォルトの名無しさん (ﾜｯﾁｮｲ 427c-ts/j)
垢版 |
2023/11/23(木) 18:51:14.02ID:AGqDCJM/0
>>212
＞NimはJavaとかC#みたいなクロスプラットフォーム性があるわけではないし

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

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

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

nimはトランスレーター系で、出力がcだったりjavascriptへだったりして、そこでリソース消費しちゃってる感あるのがな。
かつてhaxeという言語があったが結局流行らなかった。
218デフォルトの名無しさん (ﾜｯﾁｮｲ 427c-ts/j)
垢版 |
2023/11/23(木) 18:53:19.90ID:AGqDCJM/0
>>208
zigはメモリ安全なんかじゃねーぞ
219デフォルトの名無しさん (ﾜｯﾁｮｲ 427c-ts/j)
垢版 |
2023/11/23(木) 18:54:51.91ID:AGqDCJM/0
odinについて知りたかったらhacker newsを見てくれ。
2023/11/23(木) 19:18:19.30ID:HQ3SaqO80
>>209
Error Union はペイロードを持てないので、erronoと同じと見て差し支えない。
ニュアンスとしてはgo言語のエラーと値を返すスタイルが近いかな。
go言語と違って、エラーがなければ値が保証される(毎度のエラーチェック不要)のと、エラーハンドリング不要ならtryで呼び出し元に押しつけられる楽さはある。

C#のTry～メソッドのout引数を戻り値で扱えるが、zigはポインタ渡しもできるのでさらに強力。
2023/11/23(木) 19:25:49.77ID:HQ3SaqO80
>>218
deferの使用を癖づけしておけば、おおむね安全だから・・・。

動的確保したu8のスライスを別の変数にも持たせ、
元の変数の破棄によるダングリングポインタで自分の足を撃ち抜くくらいかな？
よく事故るところは。
2023/11/23(木) 19:28:51.80ID:HQ3SaqO80
>>217
haxeは構文マクロ書きやすくて好きなだけに悲しい
223デフォルトの名無しさん (ﾜｯﾁｮｲ 427c-ts/j)
垢版 |
2023/11/23(木) 21:24:37.29ID:AGqDCJM/0
>>222
haxe知ってる人がいて嬉しい。
マイナーで終わったのが残念。
224デフォルトの名無しさん (ｱｳｱｳｳｰ Sa85-UHOz)
垢版 |
2023/11/23(木) 22:52:57.39ID:38VIgpCLa
>>212
おまえなんも判ってないな

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

使えるだろ

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

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

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

RustにCの置き換えはあっても
RustがC++を置き換えることは無いわ
225デフォルトの名無しさん (ｱｳｱｳｳｰ Sa85-UHOz)
垢版 |
2023/11/23(木) 22:57:33.95ID:38VIgpCLa
>>215
>文法もC系ではなくPython系って側面も込み

事実誤認だ
よくそんな平気で嘘が吐けるな
226デフォルトの名無しさん (ｱｳｱｳｳｰ Sa85-UHOz)
垢版 |
2023/11/23(木) 22:58:53.23ID:38VIgpCLa
>>214
君は表面的なところしか観れないhusianasann
2023/11/23(木) 23:16:34.09ID:45eqFX8V0
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.09ID:cA/HuquY0
俺も>>211と同じような印象を持ってるけど、一方でこうやって熱心に布教してくるユーザーが目につくんだよね。
温度差が面白い。
pythonスレで宣伝するのはさすがにスレチだからやめてほしいが。
229デフォルトの名無しさん (ﾜｯﾁｮｲ 22fa-rrr/)
垢版 |
2023/11/24(金) 00:24:17.65ID:Wcn967L80
>>218
rustほどではないけどcと比較すればかなりメモリ安全な言語
230デフォルトの名無しさん (ﾜｯﾁｮｲ 427c-ts/j)
垢版 |
2023/11/24(金) 00:45:17.10ID:6OrpRj0R0
>>227
nimのマクロはASTいじれるから強いよな。
俺もnim好きだし。
一方で >>217 で書いたようにまだライブラリに旧いGC使ってるの混じってるのと、CだけじゃなくJavaScriptへのトランスレートとかして開発リソースを消費してるのが懸念。

あとRustのマクロならたぶん近いことできるんじゃないかね？
あれは hygienicマクロうたってるし。ただ複雑過ぎるとも思う。
231デフォルトの名無しさん (ﾜｯﾁｮｲ 22fa-rrr/)
垢版 |
2023/11/24(金) 00:56:07.29ID:Wcn967L80
C++もGCありの開発可能だからnimはC++と近いのでは？
主にC++が使われてるのはミドルウェア、webブラウザ、ゲームとかだけど
いずれもGCが動かない環境ではない
232デフォルトの名無しさん (ﾜｯﾁｮｲ 22fa-rrr/)
垢版 |
2023/11/24(金) 01:04:25.73ID:Wcn967L80
nimがcと競合すると考えるなら、
nimがカーネルやデバドラで使われると思うのか
2023/11/24(金) 08:28:38.02ID:ksIXeJJJ0
>>228
熱心に布教するユーザが目に付くというのがまさにとりたてて特徴がないということの証明になっているかもね
他言語だと多少気にいらなくても〇〇のために使っている、となるがNimはその思想に完全にマッチした人しか残っていないという
2023/11/24(金) 13:19:56.18ID:+HdIulh/0
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.94ID:BB7NmH0K0
>>234
Rustのいいところはコンパイルが通らないから誰が書いてもある程度同じようなコードが出来上がることだと思う
とても極端な話すればレビューもいらない
めちゃくちゃチーム開発に向いてる
Nimは既存の資産を活かせるかつ自由度が高いから小、中規模向けなのかな
2023/11/27(月) 12:16:24.67ID:0LRMXswf0
>>235
> 誰が書いてもある程度同じようなコードが出来上がる

これは幻想がひどい気がする。コンパイル通らない時にどう解決するか結構個性が出ると思う。
無限に unsafe 指摘されて切れたwebフレームワークのメンテナ居なかったか？
237デフォルトの名無しさん (ｱｳｱｳｳｰ Sa0b-6V65)
垢版 |
2023/11/29(水) 06:07:56.97ID:n75oaT1ga
>>236
>無限に unsafe 指摘されて切れた
このひとのことかな
https://wolfbash.hateblo.jp/entry/2017/07/30/193412
2023/11/29(水) 12:33:39.58ID:fVcl6vAK0
>>237
そこまでレベル低い人の話はしていない。

掘り直したら actix-web だった。
以下のページが日本語で問題まとまってる。
ttps://scrapbox.io/nekketsuuu/actix-web%E4%BA%8B%E4%BB%B6
2023/12/06(水) 14:35:16.69ID:FgD2yr5e0
Rust2006年、Nim2008年(or 2005年生誕説)、Go2009年にそれぞれオープン化して同期の中でNimの言語コンセプトだけ主要な席を取れなかったのはおかしい。
Nim好きユーザーとしてはここからの巻き返しを超絶妄想してる。
現世代言語の仕様に引けを取ってないし8月に本体2.0.0に上がったし周辺パッケージも育って熱心な布教者まで揃ってるのにそもそもの認知度が低すぎるままなのは不思議でならない。
いまNimで書いてる人たちは何用途で使ってる?まずは特定用途で知名度を上げることに突破口があると思うんだよね結局は。
240デフォルトの名無しさん (ﾜｯﾁｮｲ 2a7c-1JZ4)
垢版 |
2023/12/06(水) 15:24:48.70ID:MT5mgeUa0
>>239
個人で始めたか、法人所属の人が始めたか。
pythonはメジャーになるまで30年以上かかってる。
法人の後ろ楯あると早いね。
何かキラーアプリがでることを期待してる。俺はそんなスキル無い。
2023/12/06(水) 15:53:12.48ID:KVh/UeYmM
>>239
同期だからこそ、潜在ユーザをみんなGoとRustに取られた感はある
企業がついてない分エコシステムとかはどうしても負けるし

あとはC系の人にPython風構文はあまり歓迎されないというのはあるかも
MojoみたくPythonユーザを直接取りに行ったほうが良かったかもね
242デフォルトの名無しさん (ﾜｯﾁｮｲ 2a7c-1JZ4)
垢版 |
2023/12/06(水) 16:40:19.51ID:MT5mgeUa0
>>240
30年以上は言い過ぎ？30年近く。
2023/12/06(水) 18:39:52.78ID:Lg+sIo970
pythonは2000年代初頭にはperlよりメジャーになってただろ。
244デフォルトの名無しさん (ﾜｯﾁｮｲ 8ab6-yDrh)
垢版 |
2023/12/08(金) 03:22:50.77ID:OHR+wWxR0
やっぱりrustなんだろうね
OSも徐々にRustになってくっぽい
主要OSが完全に移行するには100年かかるだろうけど
2023/12/08(金) 05:55:14.09ID:xBCOoZoU0
LinuxカーネルのコードがRustに置き換わるとコンパイル時間が大幅に増加しないか心配。
Cだけのカーネルでもビルドに一時間くらいかかるのに
2023/12/08(金) 09:48:35.93ID:k3Bpg+TDa
コンパイルよりCargoのdb更新に時間掛かってるんだよないっつも
2023/12/08(金) 23:03:52.41ID:Pln0qn0V0
>>246
それいくつか前のバージョンで改善されたやつじゃなくて？
2023/12/13(水) 08:12:56.25ID:SOLvnyCP0
待望の新言語

WebAssemblyへのコンパイルだけに特化した新言語「Onyx」登場、Wasmerが発表
https://www.publickey1.jp/blog/23/webassemblyonyxwasmer.html
2024/02/06(火) 21:17:51.46ID:vknt9k+q0
待望の新言語

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.60ID:fJ9G9a/R0
>>249
DBスキーマみたいなストアドプロシージャ内蔵の静的型付けYAML作ってるってのはこれだったのか
トランスパイラ方式にしたんだな
2024/03/29(金) 21:11:42.51ID:F+7of5fq0
Erlangランタイムの静的型付け関数型言語Gleamがバージョン1.0に到達
https://www.infoq.com/jp/news/2024/03/gleam-erlang-virtual-machine-1-0/
252デフォルトの名無しさん (ﾜｯﾁｮｲ adda-VtrB)
垢版 |
2024/03/29(金) 23:02:59.73ID:JKQcuRe50
スレチかもしれないけど、この言語そのものというよりは、作者の目指す未来の言語像が可能性を感じる。

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.46ID:n/Lqlt000
Bun v1.1がついにWindowsネイティブ対応化を引っさげて4月1日リリース予定
日程がエイプリルフールでややザワついてるが敢えてこの日を選んでるっぽい？

Bunを作るZigもv0.12.0が4月2日リリース予定になってるが
こっちは既に数回無告知延期して公式すら話題にしなくなってるのでまたダメかもしれん
2024/04/10(水) 00:48:05.23ID:PZl/2Qvj0
どんぐりテスト
2024/04/28(日) 22:41:22.44ID:UPZ0W4Nj0
hoshu
256デフォルトの名無しさん (ﾜｯﾁｮｲ a7f9-y8PE)
垢版 |
2024/04/29(月) 13:16:16.09ID:bo2jVeD+0
で？結局どれがいいんだい
2024/04/29(月) 16:50:51.13ID:12eKztj20
Rustが死んだからZigかCarbonかな
2024/04/29(月) 22:47:28.69ID:6wHhtPFS0
死んでるの？
俺の中では同系統のコンセプトに対抗できてる言語が一切見られないので Rust 一強な勢いなんだが。
2024/06/08(土) 08:52:15.87ID:SAkY8LF70
Zigのリリースサイクル早いね、もう0.13.0がリリースされた
2024/07/08(月) 21:11:19.11ID:EaEf11Cm0
待望の新言語

生成AIに疑似コードで指示すると自然言語よりも効率的にプログラムが生成できるというアイデアから生まれた、生成AI用の疑似言語「SudoLang」
https://www.publickey1.jp/blog/24/aiaisudolang.html
2024/07/09(火) 01:43:38.24ID:SMbKjjog0
本末転倒だろ
2024/09/01(日) 15:29:07.17ID:f0nFMo6oM
RustがCより速くなるベンチマークは見たことがないです

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

NimがCより２倍以上速くなって、しかもORCでメモリ安全も担保されているなら
Rustを使う意味がなくなると思うのですが、このベンチマークは本当なのでしょうか？
263デフォルトの名無しさん (ﾜｯﾁｮｲ eaad-voeu)
垢版 |
2024/09/08(日) 01:45:12.42ID:Hh5CAE6t0
>>262
nimは一旦ｃに変換してコンパイルするので、ｃより早くなる事はないです。

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

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

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

参照リンク元の記事は、メモリプールのような低水準のコードでもＮｉｍは高い
可読性で書く事ができると言いたいのでは。（手動確保したメモリをdestroy定義
で自動解放できる所とか）
264デフォルトの名無しさん (ﾜｯﾁｮｲ f9df-BHET)
垢版 |
2024/09/08(日) 07:43:41.27ID:vegiTRtO0
>>262
>ベンチマークがCより２倍以上速くなって
という記述は見当たらないけど

> NimがCより２倍以上速くなって、しかもORCでメモリ安全も担保されているなら
> Rustを使う意味がなくなると思うのですが、このベンチマークは本当なのでしょうか？
「メモリプールが速い」は本当だろう
「Cより速い」は、そもそもそんなことを書いてないのでダウト
Rustは分からんけどGCが無いぶんNimよりは有利なのでは
2024/10/02(水) 13:03:50.53ID:XbzwGALZa
RustがNimより速い訳がない
266デフォルトの名無しさん (ﾜｯﾁｮｲ ffad-4whB)
垢版 |
2024/10/03(木) 12:29:21.43ID:gQlcDFcc0
nim 2.2.0 リリース
久しぶりに速度をはかるとかなり高速化されているようだ。
単純なフィボナッチ計算４５桁で実測
-d:releaseコンパイルで約26%, -d:dangerで約33%高速化している。
(実際の高速化はこの一つ前のバージョン2.0.10でされている）
2024/10/03(木) 13:32:37.43ID:/N1KY/IS0
実用コードでそこまでの差はないだろうけど
チェックの省略やTCOが上手になったのかな
Cコードで差分とってみてほしい
268デフォルトの名無しさん (ﾜｯﾁｮｲ ffad-4whB)
垢版 |
2024/10/05(土) 02:05:54.37ID:dycfQkyl0
266です。

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

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

nimのresult変数の初期化が入る事で、ｇｃｃ側のコンパイル最適化で高速化
しているようです。
試しにnim2.0.8でresult変数を０初期化した所、nim2.2.0と同じ処理速度
が出る事が確認できました。
(フィボ関数内の先頭でresult変数を０初期化し、以降の算出値をresult変数に
格納するように変更した）
2024/10/05(土) 14:35:02.61ID:tOSXTi2h0
>>266
Nimの場合はバックエンドに使うCコンパイラの最適化能力も実行速度に影響します。Nimのバージョン間の実行速度を比較するときにCコンパイラのバージョンを同じにしていますか?
面倒でなければCコンパイラの出力するアセンブリコードを読むと何故result変数を0初期化することが処理速度に影響するかわかると思います。
--passC:"-S"というコンパイラオプションをNimに渡すとnimcacheディレクトリにアセンブリコードが出力されます。
270デフォルトの名無しさん (ﾜｯﾁｮｲ caad-6k2q)
垢版 |
2024/10/06(日) 13:25:29.22ID:yuNPVtUj0
>Nimの場合はバックエンドに使うCコンパイラの最適化能力も実行速度に影響します。Nimのバージョン間の実行速度を比較するときにCコンパイラのバージョンを同じにしていますか?

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

私の疑問点は解消しましたし、gcc側の最適化内容まで追うつもりはないので、私の方の検証はこれで終了とします。
2024/10/26(土) 14:10:58.86ID:lE9emaTH0
Zig言語で開発したターミナルエミュレータだってさ

ミッチェル・ハシモト氏の個人開発によるターミナルエミュレータ「Ghostty 1.0」、12月に正式リリース予定。オープンソースとして公開へ
2024年10月25日
https://www.publickey1.jp/blog/24/ghostty_1012.html
2024/11/29(金) 13:35:59.12ID:cbzvCkJwd
Crystalとかわりと新しめな言語っぽいけど次世代言語としてはあんま価値はない感じ？
2024/11/29(金) 14:06:07.15ID:kgssLEYJ0
対立煽りに荒らし尽くされて過疎ってるだけだから気にせんと何でも書いてってや
2024/11/29(金) 18:48:03.79ID:KH+D4ATv0
やはり、実際に採用されたプロダクトが出てくる頻度で見ると、Zigが頭一つ抜けてるな
275デフォルトの名無しさん (ﾜｯﾁｮｲ 6208-Dngz)
垢版 |
2024/12/03(火) 00:07:23.29ID:SdCS4Rrb0
zigをCコンパイラもどきとして扱うのはよく見るけどzig言語の採用例ってあんまり多くなくない
2024/12/03(火) 06:50:16.97ID:hGt3IOpB0
時雨堂もZig撤退しちゃったしなぁ
2024/12/03(火) 07:04:26.37ID:JOdYPQk60
>>276
マジかよ
それはショックだな
2024/12/03(火) 07:13:55.18ID:hGt3IOpB0
>>277
非同期の仕様が全然決まらないかららしい
本家はLLVMに変わるコンパイラバックエンドに注力してるみたいだけど
そんなことより言語仕様とか標準ライブラリやったほうがいい気はする…
2024/12/03(火) 07:40:52.23ID:JOdYPQk60
>>278
本家は今のCの適用範囲をそのままZigで置換することを目指していて
範囲外にある非同期に関心薄いのはしょうがないのでは
2024/12/03(火) 08:12:12.79ID:13VhrJJT0
Cの適用範囲ってのが残ってるのかちょっと疑問はある
Rust for Linuxの騒動でも感じたけどCにこだわりのある人はC以外に移行しないと思う
移行してもいいって人はすでにRustなりに行ってる可能性高いし

組み込み系は残ってるけど認定コンパイラ必須だからハードル高いし
そもそもユーザ増えないと認定にお金出してくれる会社も現れないんだよな
281デフォルトの名無しさん (ﾜｯﾁｮｲ a64d-5eKh)
垢版 |
2024/12/03(火) 21:49:17.45ID:FXu9rGH00
zigは結局メモリ安全じゃないからね
ならcでいいってなるね
2024/12/03(火) 23:16:36.04ID:hGt3IOpB0
zigは未使用変数がエラーになるとか今風の言語っぽく厳しい部分もC好きな人には合わなさそう
2024/12/24(火) 09:41:20.41ID:Q1P/mCXL0
待望の新言語

WebAssemblyに特化した言語「MoonBit」のコンパイラがGitHubで公開
https://www.publickey1.jp/blog/24/webassemblymoonbitgithub.html
新着レスの表示
レスを投稿する

5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況