次世代言語27 Nim Zig Pony Carbon Gleam

1 ：デフォルトの名無しさん ：2022/08/05(金) 09:40:50.22 ID:/hLfNpmA0.net

!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

2 ：デフォルトの名無しさん ：2022/08/05(金) 12:18:02.18 ID:X0qTPiXKM.net

乙

3 ：デフォルトの名無しさん (ﾜｯﾁｮｲ ba7c-t4GX)：2022/08/05(金) 20:57:32 ID:IaHwMjJC0.net

本スレ

4 ：デフォルトの名無しさん ：2022/08/05(金) 23:22:06.64 ID:mIb2aBTZ0.net

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

5 ：デフォルトの名無しさん ：2022/08/06(土) 15:25:50.11 ID:eSBCWCwIa.net

>>1
O2

6 ：デフォルトの名無しさん ：2022/08/07(日) 04:00:41.01 ID:40aW3DD80.net

久々にHaxeのプロジェクトページを訪ねてみたらサポートターゲットにHashLinkなるVMが追加されていた
Nekoの後継？

7 ：デフォルトの名無しさん ：2022/08/07(日) 13:37:10.92 ID:Dd35QVWO0.net

過疎やん

8 ：デフォルトの名無しさん ：2022/08/07(日) 15:10:39.88 ID:G9vPq40Zd.net

>>6
haxeまだあったのか。
昔ちょろっと見てけっこう良さそうな印象持ったけど流行らなかったな。
nimもトランスレーター系だし、同じ将来にはならないで欲しい。
結局はバックにGAFAMがつくかどうかによるのかねぇ。
それでいうとpythonは運・タイミングが良かったのか。

9 ：デフォルトの名無しさん ：2022/08/07(日) 15:41:37.32 ID:SSq6cfdBp.net

nimとかD言語みたいなちょっと良くした程度の言語だと流行らないんだろうなあ
RubyでいうRailsみたいな超人気フレームワークが登場すると話が変わってくるんだろうけも

10 ：デフォルトの名無しさん ：2022/08/08(月) 01:27:47.98 ID:mO/LiGB20.net

>>9
NimはもっとシームレスにPythonソースを使えればいいんだけど。
nimpyとかnimporterとかって公式になったっけ？

11 ：デフォルトの名無しさん ：2022/08/08(月) 15:07:53.58 ID:XhYLtnJ40.net

>>10
nimpyやnimporterが公式になるってどういうこと?
標準ライブラリになることを期待してるのかもしれないが、標準ライブラリになったとしても使いやすくなるとは限らないよ。
C/C++のライブラリだったらc2nimやfutharkというツールがC/C++のコードを読んで自動的にバインディングを生成してくれるらしい。
futharkはlibclangを使ってコードをパースするらしい。

12 ：デフォルトの名無しさん ：2022/08/11(木) 04:05:29.11 ID:Bpvt7Gu80.net

CarbonってC++のABI問題の拗れが引き金となって生まれたものなんだろうけど
わざわざ文法から作り直すことないのにな
実用的なレベルになるまで相当かかりそう

13 ：デフォルトの名無しさん ：2022/08/11(木) 08:03:21.25 ID:6LydNS9Hd.net

GoogleでC++の糞の山のメンテばっかりさせられて嫌気が差したんだろ
所詮数あるホビー言語の一つに過ぎないんだから好きにさせてやれよ

14 ：デフォルトの名無しさん ：2022/08/12(金) 13:09:15.20 ID:0xlDyyucM.net

>>11
公式になって手順・ドキュメントが整備されるというということだな。
そうすればもっとpythonコードが流用しやすくなるので、性能で困っているpythonユーザーが手を出しやすくなるかと。

15 ：デフォルトの名無しさん ：2022/08/12(金) 15:40:56.79 ID:bDQmrk+50.net

nimのアンダースコアを無視する仕様は好きじゃない。

16 ：デフォルトの名無しさん ：2022/08/12(金) 18:28:24.07 ID:D0nb2yzy0.net

>>14
公式になったからといってドキュメントが整備されるとも限らないし
公式にならなくてもやる気があればドキュメントを整備するＰＲを送ればいいのでは。

>>15
アンダースコアを無視するおかげで、ライブラリがfoo_barみたいな名前を使っていてもライブラリを使う側のコードがfooBarという名前で呼び出せるので命名規則に一貫性をもたらすことができる。
しかしCのライブラリがfoo_barとfooBarという異なる二つの関数を持っているとNimから使うときに違う名前を使って参照するようにbindingを書かなくてはいけなくなってしまう。
そいいうケースはあまりないけどね。

17 ：デフォルトの名無しさん ：2022/08/13(土) 22:42:00.05 ID:6wAoLN5t0.net

Rustを見てて疑問に思うところがあるんだけど、
「コールスタック専用変数」「ヒープ用変数」といった
使い分けをする言語はあるのかしらん？
現状の言語で近いのは
C：変数はコールスタック専用。ヒープのインスタンスはポインタで管理
Rust：変数はコールスタック専用。ヒープ用変数はBox、Vec、Rcとかで模倣
ぐらいか。
コールスタックにあるインスタンスはスコープに連動するRAIIとかの便利な特性があるから、
他の言語でもコールスタック専用変数があってもいいと思うんだけど。
例えばJavaにコールスタック用変数があればfinalizeメソッドももっと使いやすくなりそう。
コールスタック用変数専用クラスとかあってもいいし。

18 ：デフォルトの名無しさん ：2022/08/13(土) 23:29:46.92 ID:601ao6Evd.net

スタックとヒープの使い分けができるという意味ならGoとかC#とか

19 ：デフォルトの名無しさん ：2022/08/14(日) 01:50:30.53 ID:H+Dty+yM0.net

>>17
Nimでもスタックとヒープを使いわけられるよ。
refのついた型とクロージャの環境とstring, seqの中身はヒープに確保される。
それ以外のローカル変数はスタックに確保。
C言語のグローバル変数とstatic変数はstatic storageというスタックとは別の所に置かれるよ。

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

20 ：デフォルトの名無しさん ：2022/08/14(日) 01:50:48.23 ID:H+Dty+yM0.net

>>17
Nimでもスタックとヒープを使いわけられるよ。
refのついた型とクロージャの環境とstring, seqの中身はヒープに確保される。
それ以外のローカル変数はスタックに確保。
C言語のグローバル変数とstatic変数はstatic storageというスタックとは別の所に置かれるよ。

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

21 ：デフォルトの名無しさん ：2022/08/14(日) 01:53:56.93 ID:XCwSZ99k0.net

>>18
変数のエスケープ解析して自動でヒープとスタックを使い分けるんじゃなくて、その変数をスコープからエスケープするような使い方をしたときにコンパイルエラーにするようなのを想定しています。
スタックフレーム制約付き変数ですな。

22 ：デフォルトの名無しさん ：2022/08/14(日) 02:03:29.71 ID:XCwSZ99k0.net

>>20
確か、Nimもスタックフレームにインスタンスを置くことを強制できなかったかと思うけど、どうだったっけ？

23 ：デフォルトの名無しさん ：2022/08/14(日) 02:10:20.77 ID:H+Dty+yM0.net

>>17
Nimでもスタックとヒープを使いわけられるよ。
refのついた型とクロージャの環境とstring, seqの中身はヒープに確保される。
それ以外のローカル変数はスタックに確保。
C言語のグローバル変数とstatic変数はstatic storageというスタックとは別の所に置かれるよ。

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

24 ：デフォルトの名無しさん ：2022/08/14(日) 02:20:35.55 ID:H+Dty+yM0.net

間違えて連続投稿してすいませんでした。
>>22
type
　SomeObj = object
　　x: int

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

foo()

25 ：デフォルトの名無しさん ：2022/08/14(日) 09:07:22.22 ID:5kZWLu5Dd.net

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

yamlやjsonに変換してから食わせることはできるらしいけどやっぱそのまま食えるのと手間と複雑さは無駄に嵩張るし、この手のDSLはどれだけ広い環境で使えるかが重要よねって

26 ：デフォルトの名無しさん ：2022/08/14(日) 09:18:07.39 ID:E6D9Byfed.net

>>21
C#はスタック変数のエスケープは不可で、その参照を返すようなことはできない
クロージャでキャプチャされたり非同期メソッドの場合にヒープに昇格する例外はあるが、文脈から明らかであり、いわゆるエスケープ解析とは異なるものだ
更に、構造体を ref struct として定義することで上記のような昇格も不可となり、完全にスタック専用になる

27 ：デフォルトの名無しさん ：2022/08/14(日) 10:18:19.35 ID:osAuRY7C0.net

>>25
ちょっとぐぐってみたけど俺はできると思ってる子がなんかこれあったら便利やんって言うのを色々詰め込んだイメージ
本当にでかい設定ファイルなら嬉しいのかも知れないけど大多数の設定ファイルにはオーバースペック過ぎて流行らないと思う

28 ：デフォルトの名無しさん ：2022/08/14(日) 10:55:58.43 ID:lDco67Nc0.net

オーバースペックさで言うとyamlも相当だしそれだけでは判断できないのでは

29 ：デフォルトの名無しさん ：2022/08/14(日) 19:14:39.32 ID:1Y4ysm770.net

スタックとかヒープとか基本的に実装依存じゃないの
言語レベルで規格として策定されてるのある？

30 ：デフォルトの名無しさん ：2022/08/14(日) 19:23:27.68 ID:TMCPzdUa0.net

CやC++はmallocやらnewなどでメモリ確保しない限りは全てスタックではないの？
今時のコンパイラはどうやってるのか知らんけど昔は少なくともそうだった

31 ：デフォルトの名無しさん ：2022/08/14(日) 19:43:04.36 ID:H+Dty+yM0.net

可変長配列とか文字列型などの必要なメモリ量が実行時に決まるものや
関数やブロックのスコープと変数の寿命が対応しないもの(GCで管理されるオブジェクト)などはヒープ使うしかないでしょ。
けどローカル変数などをヒープに置くと効率悪いし。

32 ：デフォルトの名無しさん ：2022/08/14(日) 19:55:23.52 ID:osAuRY7C0.net

>>29
ハードウェアスタックがないマシン（汎用機とか）もあるから実装依存なのは確かだけどそういうマシンでもソフトウェアでスタック作ってるので実装としてはたいして変わらん

33 ：デフォルトの名無しさん ：2022/08/14(日) 19:58:39.91 ID:H+Dty+yM0.net

>>30
関数の外にある変数やstatic変数はstatic storageというプロセスが生まれてから死ぬまで存在し続ける領域に置かれるよ。
詳しくはdata segmentとかbssとかで検索してね。
static変数は値を保持し続けないといけないからスタックに置けないし、
関数の外にある変数は複数の関数から共有されるのでコンパイル時かリンク時にアドレスが決まってないといけないと思うのでおそらくスタックに置けない。

34 ：デフォルトの名無しさん ：2022/08/14(日) 20:34:35.63 ID:d/RE/iMKa.net

C++の定石としてオブジェクトはスタックに置くのが基本だよ
デストラクタを動かしたいからね
ヒープにデータを割り当てたい時は構造体やクラスでラップするのが基本

35 ：デフォルトの名無しさん ：2022/08/14(日) 20:39:54.05 ID:lDco67Nc0.net

>>29
最適化の余地残すために規格では振る舞いしか記述しないのが基本だと思う
レジスタだけ使うとかあるしね

36 ：デフォルトの名無しさん (ｽﾌﾟｯｯ Sd62-IWzR)：[ここ壊れてます] .net

可変長配列に限って言えばCは一応VLAがある
11からオプションだけど

37 ：デフォルトの名無しさん ：2022/08/15(月) 08:38:26.95 ID:qDRL1WTlM.net

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

38 ：デフォルトの名無しさん ：2022/08/15(月) 13:39:10.26 ID:SFJl5V0da.net

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

39 ：デフォルトの名無しさん ：2022/08/15(月) 15:41:07.32 ID:qHbAfBQi0.net

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

40 ：デフォルトの名無しさん ：2022/08/15(月) 16:32:14.78 ID:zxOEKBbO0.net

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

41 ：デフォルトの名無しさん ：2022/08/16(火) 18:56:36.29 ID:1oXHhIiq0.net

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

42 ：デフォルトの名無しさん ：2022/08/16(火) 19:04:37.29 ID:JSsOGCvC0.net

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

43 ：デフォルトの名無しさん ：2022/08/16(火) 19:50:02.47 ID:RYKZv1s10.net

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

44 ：デフォルトの名無しさん ：2022/08/17(水) 15:25:42.74 ID:DfCxGnRFa.net

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

45 ：デフォルトの名無しさん ：2022/08/17(水) 16:47:04.91 ID:hcUDPGl30.net

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

46 ：デフォルトの名無しさん ：2022/08/17(水) 17:41:05.70 ID:J/baCQNr0.net

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

47 ：デフォルトの名無しさん ：2022/08/17(水) 17:53:10.26 ID:cnWCAZlk0.net

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

48 ：デフォルトの名無しさん ：2022/08/17(水) 20:56:42.47 ID:9RiCNb2+0.net

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

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

49 ：デフォルトの名無しさん (ﾜｯﾁｮｲ dd5f-FS65)：[ここ壊れてます] .net

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

50 ：デフォルトの名無しさん ：2022/08/17(水) 22:39:10.52 ID:SgLVBpM30.net

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

51 ：デフォルトの名無しさん ：2022/08/17(水) 23:44:30.76 ID:C+o8slGL0.net

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

52 ：デフォルトの名無しさん ：2022/08/18(木) 00:15:49.61 ID:uPozsGij0.net

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

53 ：デフォルトの名無しさん ：2022/08/18(木) 00:23:55.46 ID:K1uqUAUE0.net

>>52
だよね。

54 ：デフォルトの名無しさん ：2022/08/18(木) 01:11:39.51 ID:yLDzsouG0.net

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

55 ：デフォルトの名無しさん ：2022/08/18(木) 11:25:09.48 ID:p/limWqpa.net

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

56 ：デフォルトの名無しさん ：2022/08/18(木) 12:21:45.00 ID:yLDzsouG0.net

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

57 ：デフォルトの名無しさん ：2022/08/18(木) 14:58:14.10 ID:qt1eMpHHa.net

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

58 ：デフォルトの名無しさん (ﾜｯﾁｮｲ e936-4eON)：[ここ壊れてます] .net

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

59 ：デフォルトの名無しさん ：2022/09/05(月) 00:54:15.45 ID:cFc+MJ1wM.net

あげ

60 ：デフォルトの名無しさん ：2022/09/05(月) 01:08:51.55 ID:9iTWKe040.net

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

61 ：デフォルトの名無しさん ：2022/09/05(月) 01:34:04.91 ID:ARttffD10.net

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

62 ：デフォルトの名無しさん ：2022/09/05(月) 08:15:38.43 ID:HWNfM8e/M.net

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

63 ：デフォルトの名無しさん ：2022/09/05(月) 22:33:29.07 ID:1hFtemgL0.net

>>60

std/options で

ひとまずOK じゃないか ?

64 ：デフォルトの名無しさん ：2022/09/06(火) 04:20:51.68 ID:6xx96XME0.net

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

65 ：デフォルトの名無しさん (ﾃﾃﾝﾃﾝﾃﾝ MMff-jyuF)：[ここ壊れてます] .net

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

66 ：デフォルトの名無しさん ：2022/09/06(火) 13:26:12.50 ID:3wQQbwTr0.net

>>64

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

67 ：デフォルトの名無しさん ：2022/09/08(木) 12:38:55.89 ID:H4D+Re2GM.net

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

68 ：デフォルトの名無しさん ：2022/09/08(木) 17:28:20.37 ID:cKTVDYCV0.net

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

69 ：デフォルトの名無しさん ：2022/09/08(木) 18:05:59.15 ID:U6/gufpm0.net

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

70 ：デフォルトの名無しさん ：2022/09/08(木) 18:22:30.25 ID:ydRaiFc90.net

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

71 ：デフォルトの名無しさん ：2022/09/08(木) 18:50:48.63 ID:11l7kxGRM.net

>>69
COBOL++でしょ

72 ：デフォルトの名無しさん ：2022/09/08(木) 19:36:15.16 ID:gDKj2SJwM.net

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

73 ：デフォルトの名無しさん ：2022/09/08(木) 21:06:39.94 ID:g68A8C0LM.net

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

74 ：デフォルトの名無しさん ：2022/09/08(木) 22:22:15.01 ID:D8Erj63H0.net

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

75 ：デフォルトの名無しさん ：2022/09/09(金) 07:32:44.98 ID:v1OYGNdb0.net

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

76 ：デフォルトの名無しさん (ﾜｯﾁｮｲ a95f-Yvh5)：[ここ壊れてます] .net

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

77 ：デフォルトの名無しさん (ﾜｯﾁｮｲ a563-jxjI)：[ここ壊れてます] .net

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

78 ：デフォルトの名無しさん (ﾜｯﾁｮｲ a563-FZWc)：[ここ壊れてます] .net

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

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

79 ：デフォルトの名無しさん (ﾜｯﾁｮｲ a563-FZWc)：[ここ壊れてます] .net

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

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

80 ：デフォルトの名無しさん ：2022/09/18(日) 13:44:05.76 ID:KpBP36NGa.net

トンズラパイラに観えた

81 ：デフォルトの名無しさん ：2022/09/28(水) 19:48:23.69 ID:Tun9Z/EC0.net

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

82 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 6bf0-rqSc)：[ここ壊れてます] .net

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

83 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 6bf0-rqSc)：[ここ壊れてます] .net

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

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

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

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

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

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

84 ：デフォルトの名無しさん ：2022/10/09(日) 11:10:02.48 ID:hHOnLIUR0.net

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

85 ：デフォルトの名無しさん ：2022/10/31(月) 12:29:04.61 ID:RFzpfvk70.net

「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

86 ：デフォルトの名無しさん ：2022/10/31(月) 13:03:53.85 ID:4lYEr6WH0.net

Rust「…」

87 ：デフォルトの名無しさん ：2022/11/13(日) 10:14:16.92 ID:lA0JSaU/0.net

検証�@�A
https://i.imgur.com/EjOYpAq.png

88 ：デフォルトの名無しさん ：2022/11/13(日) 17:19:42.67 ID:vYboHCwy0.net

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

89 ：デフォルトの名無しさん ：2022/11/14(月) 11:28:56.72 ID:EWF0SvAna.net

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

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

90 ：デフォルトの名無しさん ：2022/11/19(土) 20:53:35.05 ID:7QNjN12J0.net

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

91 ：デフォルトの名無しさん ：2022/11/28(月) 15:07:09.33 ID:6X8/W5dUa.net

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

92 ：デフォルトの名無しさん ：2022/11/28(月) 17:49:52.29 ID:SIJnWXGqH.net

なら >>91 が 比較しろ

93 ：デフォルトの名無しさん ：2022/11/28(月) 18:00:59.49 ID:6X8/W5dUa.net

何でやねん

94 ：デフォルトの名無しさん (ﾜｯﾁｮｲ ffcf-ykd8)：2022/11/28(月) 18:40:44.25 ID:LDNjf6uN0.net

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

95 ：デフォルトの名無しさん (ﾜｯﾁｮｲ b7a4-O5Hl)：2022/11/29(火) 00:59:42.07 ID:QobrmxBH0.net

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

96 ：デフォルトの名無しさん ：2022/11/29(火) 12:05:03.27 ID:zwTDTYOm0.net

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

97 ：デフォルトの名無しさん ：2022/11/29(火) 15:23:09.06 ID:Vcr0dhdC0.net

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

98 ：デフォルトの名無しさん ：2022/12/12(月) 11:40:34.09 ID:X5LmWbdvp.net

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

99 ：デフォルトの名無しさん ：2022/12/18(日) 01:37:12.14 ID:xkWav1uF0.net

Nested Choice面白いな

100 ：デフォルトの名無しさん ：2022/12/18(日) 11:18:36.47 ID:9uYd/N4Nr.net

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

101 ：デフォルトの名無しさん ：2022/12/24(土) 17:31:02.76 ID:sDckaCi+0.net

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

102 ：デフォルトの名無しさん ：2022/12/25(日) 14:55:22.12 ID:KZAI5vpb0.net

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

103 ：デフォルトの名無しさん ：2023/01/03(火) 23:06:21.96 ID:EF4+Zmp+d.net

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

104 ：デフォルトの名無しさん ：2023/01/05(木) 00:37:52.42 ID:Xf8DhQg+0.net

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

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

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

105 ：デフォルトの名無しさん ：2023/01/05(木) 01:10:08.86 ID:Ymjh5Awz0.net

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

106 ：デフォルトの名無しさん ：2023/01/10(火) 00:06:39.20 ID:lqMsrQlz0.net

TEST

107 ：デフォルトの名無しさん ：2023/01/21(土) 14:23:16.05 ID:tJUqTfCaa.net

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

108 ：デフォルトの名無しさん ：2023/01/21(土) 15:29:58.89 ID:6AMuhJZU0.net

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

109 ：デフォルトの名無しさん ：2023/01/21(土) 18:31:14.57 ID:DGuAb7AB0.net

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

110 ：デフォルトの名無しさん ：2023/01/21(土) 19:13:09.85 ID:mrhEz1eCa.net

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

111 ：デフォルトの名無しさん ：2023/01/26(木) 11:26:58.76 ID:AA1/dHsVd.net

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

112 ：デフォルトの名無しさん ：2023/02/01(水) 15:25:14.11 ID:HrKHxNtD0.net

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

113 ：デフォルトの名無しさん ：2023/02/06(月) 08:25:04.30 ID:2pHg0M5D0.net

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

114 ：デフォルトの名無しさん ：2023/02/06(月) 09:11:15.73 ID:JuD75zQDM.net

おお

115 ：デフォルトの名無しさん ：2023/02/06(月) 09:44:38.64 ID:fVls87ar0.net

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

116 ：デフォルトの名無しさん ：2023/02/06(月) 11:44:22.80 ID:t4UlNWb00.net

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

117 ：デフォルトの名無しさん ：2023/02/06(月) 12:44:04.53 ID:s421rGzSM.net

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

118 ：デフォルトの名無しさん ：2023/02/17(金) 08:18:49.77 ID:qlaClCnE0.net

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

119 ：デフォルトの名無しさん ：2023/03/18(土) 09:36:05.92 ID:GmA34DaYa.net

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

120 ：デフォルトの名無しさん ：2023/03/25(土) 22:53:18.43 ID:BSe5gihC0.net

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

121 ：デフォルトの名無しさん ：2023/03/26(日) 09:50:29.12 ID:t5F8xIRn0.net

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

122 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 027c-3uzD)：2023/03/27(月) 14:32:28.74 ID:CEoRbIwo0.net

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

123 ：デフォルトの名無しさん ：2023/03/27(月) 21:45:38.89 ID:ZY+RQ7940.net

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

124 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 495f-EkyU)：2023/04/08(土) 09:14:03.61 ID:WXwwqEgX0.net

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

125 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 495f-2jjA)：2023/04/13(木) 09:31:47.71 ID:VEQIQK6j0.net

王者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入りは成功を保証しないが、少なくとも注目に値する第一歩だ」(ジャンセン氏)

126 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 975f-ixN4)：2023/05/06(土) 21:37:15.59 ID:Ljj/ks5m0.net

待望の新言語

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

127 ：デフォルトの名無しさん (ﾜｯﾁｮｲ b7cf-O5MS)：2023/05/07(日) 10:45:52.48 ID:2alg5WM70.net

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

128 ：デフォルトの名無しさん (ﾜｯﾁｮｲ a701-KeI6)：2023/05/07(日) 10:46:24.88 ID:IEgposGn0.net

Nimじゃ駄目なんですか？

129 ：デフォルトの名無しさん (ﾜｯﾁｮｲ cbda-0v65)：2023/05/07(日) 17:32:47.00 ID:souVRU9G0.net

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

130 ：デフォルトの名無しさん (ﾜｯﾁｮｲ df01-O5MS)：2023/05/08(月) 00:18:12.54 ID:7UdtJzN/0.net

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

131 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 975f-hGOv)：2023/05/09(火) 15:00:49.20 ID:cZVxEdl70.net

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

132 ：デフォルトの名無しさん ：2023/05/10(水) 00:22:05.48 ID:M80iwSIA0.net

Mojoは早くOSSにしろよ

133 ：デフォルトの名無しさん (ﾌﾞｰｲﾓ MM7f-BLPe)：2023/05/15(月) 06:04:50.19 ID:EP98fI5GM.net

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

134 ：デフォルトの名無しさん (ﾃﾃﾝﾃﾝﾃﾝ MM7f-+ffB)：2023/05/15(月) 19:15:35.36 ID:fkhy8mxoM.net

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

135 ：デフォルトの名無しさん ：2023/05/15(月) 22:35:11.34 ID:aSVKjNnD0.net

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

136 ：デフォルトの名無しさん ：2023/05/19(金) 12:22:48.77 ID:fk0Gpq/FM.net

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

137 ：デフォルトの名無しさん ：2023/05/19(金) 18:44:24.43 ID:fagGQhCY0.net

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

138 ：デフォルトの名無しさん ：2023/05/19(金) 22:29:50.83 ID:O8g/UjD80.net

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

139 ：デフォルトの名無しさん ：2023/05/20(土) 12:03:13.56 ID:Ok/r6Mln0.net

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

140 ：デフォルトの名無しさん ：2023/05/20(土) 16:28:20.57 ID:/tIrPGWZM.net

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

141 ：デフォルトの名無しさん ：2023/05/20(土) 16:36:35.19 ID:A/kRENRgM.net

構文解析的にはほぼ同じ

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

142 ：デフォルトの名無しさん ：2023/05/20(土) 16:40:15.10 ID:/tIrPGWZM.net

>>141
PDAの実装は？

143 ：デフォルトの名無しさん ：2023/05/20(土) 16:43:18.84 ID:PfZyfbnf0.net

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

144 ：デフォルトの名無しさん ：2023/05/20(土) 16:48:04.32 ID:/tIrPGWZM.net

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

145 ：デフォルトの名無しさん ：2023/05/20(土) 18:06:52.09 ID:EUGtogADM.net

>>142
GHCとか

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

146 ：デフォルトの名無しさん ：2023/05/21(日) 01:17:46.07 ID:CmXU6CGz0.net

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

147 ：デフォルトの名無しさん ：2023/05/21(日) 15:37:31.99 ID:7unpu3NzM.net

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

148 ：デフォルトの名無しさん ：2023/06/12(月) 15:08:29.37 ID:kB7As+JK0.net

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

149 ：デフォルトの名無しさん ：2023/06/12(月) 18:10:45.80 ID:7lxvOpjdd.net

>>148
つ アダムタッチ

150 ：デフォルトの名無しさん ：2023/06/13(火) 16:03:31.28 ID:xDyMFOGFd.net

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

151 ：デフォルトの名無しさん ：2023/06/13(火) 18:32:28.49 ID:yeDPLuAI0.net

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

152 ：デフォルトの名無しさん (ﾃﾃﾝﾃﾝﾃﾝ MMeb-jufV)：2023/06/14(水) 07:40:07.84 ID:8mvudo25M.net

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

153 ：デフォルトの名無しさん (ｱｳｱｳｳｰ Sadd-g1CP)：2023/06/14(水) 11:21:50.21 ID:iWYHYN4ra.net

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

154 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 315f-kZ0E)：2023/06/14(水) 14:43:32.26 ID:NMm4TZav0.net

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

155 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 3961-dT3e)：2023/06/14(水) 16:19:12.32 ID:rOshoQaM0.net

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

156 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 4f5f-JtsX)：2023/07/04(火) 03:53:42.95 ID:ZyJ9aZuM0.net

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

157 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 4f5f-JtsX)：2023/07/04(火) 09:47:08.65 ID:c7VqsKCG0.net

待望の新言語

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

158 ：デフォルトの名無しさん (ﾜｯﾁｮｲ e202-5LlG)：2023/07/20(木) 05:33:25.43 ID:LIvlv7Wc0.net

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

159 ：デフォルトの名無しさん (ｽﾌﾟｯｯ Sd7f-NY88)：2023/07/25(火) 11:52:50.13 ID:yYWffJVbd.net

>>158
1.0も遠のいた？

160 ：デフォルトの名無しさん (ﾜｯﾁｮｲ df02-rRCM)：2023/07/26(水) 00:31:41.04 ID:gfwPzIhn0.net

>>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.68 ID:2IasxSCw0.net

>>160
おぅ、、、orz

162 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 2603-6THS)：2023/08/01(火) 22:10:07.65 ID:FfTXTju00.net

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

163 ：デフォルトの名無しさん (ﾜｯﾁｮｲ d3e6-6THS)：2023/08/01(火) 22:28:49.01 ID:ZDoiR0FV0.net

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

164 ：デフォルトの名無しさん (ﾜｯﾁｮｲ becf-TJCF)：2023/08/01(火) 22:52:38.66 ID:IyAK+cNZ0.net

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

165 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 0b61-TR8s)：2023/08/02(水) 01:14:41.81 ID:4aCNkU8+0.net

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

166 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 2301-0TAO)：2023/08/02(水) 06:48:11.72 ID:eH9ezqro0.net

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

167 ：デフォルトの名無しさん (ｱｳｱｳｳｰ Sa1f-IPSQ)：2023/08/02(水) 09:34:06.72 ID:4pI1Wfnva.net

nim良いよね

168 ：デフォルトの名無しさん (ﾜｯﾁｮｲ becf-TJCF)：2023/08/02(水) 21:45:09.21 ID:9rX+LYDX0.net

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

169 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 2301-0TAO)：2023/08/02(水) 22:26:10.11 ID:eH9ezqro0.net

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

170 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 6a4b-WXhB)：2023/08/03(木) 11:22:28.95 ID:MLrVFD850.net

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

171 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 115f-Ck4D)：2023/08/25(金) 08:02:23.50 ID:fA2wbq8J0.net

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

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

172 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 9302-q59E)：2023/08/25(金) 11:01:59.13 ID:ssb8Cd/m0.net

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

173 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 7101-YAjS)：2023/08/25(金) 12:13:30.13 ID:8Q06WpC+0.net

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.80 ID:yAII5uv80.net

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

175 ：デフォルトの名無しさん (ﾜｯﾁｮｲ ff7c-AIuG)：2023/09/02(土) 16:39:16.86 ID:aKZIxXWD0.net

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

176 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 4301-yzHn)：2023/09/02(土) 18:20:03.74 ID:8yObFq2T0.net

>>174
どのベンチ？ｗ

177 ：デフォルトの名無しさん (ｽﾌｯ Sd1f-ETx6)：2023/09/07(木) 10:00:28.15 ID:K6fFrmXfd.net

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

178 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 3b5f-rlb/)：2023/09/12(火) 20:59:08.32 ID:/qNKcCZu0.net

>>131　続報

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

179 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 3f7c-/qTM)：2023/09/21(木) 00:39:19.15 ID:hd16Ksmk0.net

Zigに頑張ってほしい

180 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 7f29-sMWx)：2023/09/22(金) 01:57:24.98 ID:e0xvgrYz0.net

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

181 ：デフォルトの名無しさん (ｽｯｯﾌﾟ Sd5f-/qTM)：2023/09/22(金) 12:28:56.47 ID:FCvezg2jd.net

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

182 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 8501-8Mb1)：2023/10/04(水) 15:32:29.96 ID:N8iC4Qef0.net

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

183 ：デフォルトの名無しさん (ﾜｯﾁｮｲ a37c-X5bY)：2023/10/04(水) 16:37:22.64 ID:2V79m8iF0.net

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

184 ：デフォルトの名無しさん (ﾜｯﾁｮｲ a37c-X5bY)：2023/10/04(水) 16:42:29.89 ID:2V79m8iF0.net

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

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

185 ：デフォルトの名無しさん ：2023/10/05(木) 17:09:32.57 ID:WXXGTjkDa.net

Are

186 ：デフォルトの名無しさん ：2023/10/30(月) 01:15:43.08 ID:SHIqNVOV0.net

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

187 ：デフォルトの名無しさん (ﾜｯﾁｮｲ b137-eepm)：2023/11/02(木) 09:20:24.55 ID:+8WanLaR0.net

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

188 ：デフォルトの名無しさん ：2023/11/21(火) 03:00:21.16 ID:60zWiP9n0.net

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

189 ：デフォルトの名無しさん ：2023/11/21(火) 03:09:25.53 ID:60zWiP9n0.net

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

190 ：デフォルトの名無しさん ：2023/11/21(火) 03:12:08.32 ID:60zWiP9n0.net

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

191 ：188 (ﾜｯﾁｮｲ 22f1-rrr/)：2023/11/21(火) 04:46:48.83 ID:60zWiP9n0.net

compiletじゃなくてcomptimeだった

192 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 22f1-rrr/)：2023/11/21(火) 05:27:43.98 ID:60zWiP9n0.net

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 ：デフォルトの名無しさん ：2023/11/21(火) 05:34:22.13 ID:60zWiP9n0.net

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

194 ：デフォルトの名無しさん (ﾜｯﾁｮｲ cd26-1See)：2023/11/21(火) 10:29:25.70 ID:Z3uiTyFT0.net

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

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

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

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

195 ：デフォルトの名無しさん ：2023/11/21(火) 11:43:47.98 ID:60zWiP9n0.net

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

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

196 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 226b-rrr/)：2023/11/21(火) 14:41:07.08 ID:60zWiP9n0.net

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

197 ：デフォルトの名無しさん ：2023/11/21(火) 21:16:37.31 ID:NcXE8D4H0.net

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

198 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 22f8-rrr/)：2023/11/22(水) 01:53:36.06 ID:bjqLP0h40.net

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

199 ：デフォルトの名無しさん ：2023/11/22(水) 03:30:03.94 ID:bjqLP0h40.net

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

200 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 22f8-rrr/)：2023/11/22(水) 07:56:27.67 ID:bjqLP0h40.net

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

201 ：デフォルトの名無しさん (ﾌﾞｰｲﾓ MM66-OZuz)：2023/11/22(水) 12:13:14.04 ID:Xn3ar1UbM.net

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

202 ：デフォルトの名無しさん (ｽﾌﾟｯｯ Sd82-ts/j)：2023/11/22(水) 12:17:19.10 ID:o4kbjPDBd.net

Odinはいかが？

203 ：デフォルトの名無しさん ：2023/11/23(木) 09:55:21.62 ID:mHKDjshta.net

>>196
わかります

204 ：デフォルトの名無しさん ：2023/11/23(木) 09:55:57.11 ID:mHKDjshta.net

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

205 ：デフォルトの名無しさん ：2023/11/23(木) 10:39:32.37 ID:h/UsGTLS0.net

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

206 ：デフォルトの名無しさん ：2023/11/23(木) 10:41:14.18 ID:h/UsGTLS0.net

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

207 ：デフォルトの名無しさん ：2023/11/23(木) 10:53:59.84 ID:h/UsGTLS0.net

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

208 ：デフォルトの名無しさん ：2023/11/23(木) 11:21:12.37 ID:h/UsGTLS0.net

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

209 ：デフォルトの名無しさん ：2023/11/23(木) 12:21:13.00 ID:h/UsGTLS0.net

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

210 ：デフォルトの名無しさん ：2023/11/23(木) 12:50:09.22 ID:45eqFX8V0.net

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

211 ：デフォルトの名無しさん ：2023/11/23(木) 13:59:38.28 ID:/UTIXb+w0.net

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

212 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 225b-rrr/)：2023/11/23(木) 14:59:02.66 ID:h/UsGTLS0.net

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

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

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

213 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 225b-rrr/)：2023/11/23(木) 15:03:11.78 ID:h/UsGTLS0.net

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

214 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 225b-rrr/)：2023/11/23(木) 15:16:17.32 ID:h/UsGTLS0.net

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

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

215 ：デフォルトの名無しさん (ﾜｯﾁｮｲ ae6b-f5/H)：2023/11/23(木) 15:46:50.74 ID:o2OM8ETk0.net

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

216 ：デフォルトの名無しさん ：2023/11/23(木) 18:39:43.19 ID:AGqDCJM/0.net

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

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

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

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


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

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


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

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

217 ：デフォルトの名無しさん ：2023/11/23(木) 18:51:14.02 ID:AGqDCJM/0.net

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

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

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

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

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

218 ：デフォルトの名無しさん ：2023/11/23(木) 18:53:19.90 ID:AGqDCJM/0.net

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

219 ：デフォルトの名無しさん ：2023/11/23(木) 18:54:51.91 ID:AGqDCJM/0.net

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

220 ：デフォルトの名無しさん (ﾜｯﾁｮｲ a111-1See)：2023/11/23(木) 19:18:19.30 ID:HQ3SaqO80.net

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

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

221 ：デフォルトの名無しさん (ﾜｯﾁｮｲ a111-1See)：2023/11/23(木) 19:25:49.77 ID:HQ3SaqO80.net

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

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

222 ：デフォルトの名無しさん (ﾜｯﾁｮｲ a111-1See)：2023/11/23(木) 19:28:51.80 ID:HQ3SaqO80.net

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

223 ：デフォルトの名無しさん ：2023/11/23(木) 21:24:37.29 ID:AGqDCJM/0.net

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

224 ：デフォルトの名無しさん (ｱｳｱｳｳｰ Sa85-UHOz)：2023/11/23(木) 22:52:57.39 ID:38VIgpCLa.net

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

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

使えるだろ

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

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

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

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

225 ：デフォルトの名無しさん (ｱｳｱｳｳｰ Sa85-UHOz)：2023/11/23(木) 22:57:33.95 ID:38VIgpCLa.net

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

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

226 ：デフォルトの名無しさん (ｱｳｱｳｳｰ Sa85-UHOz)：2023/11/23(木) 22:58:53.23 ID:38VIgpCLa.net

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

227 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 6e83-aicd)：2023/11/23(木) 23:16:34.09 ID:45eqFX8V0.net

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マクロのようなものを作ることは無理じゃない?

228 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 6ecf-ekUX)：2023/11/24(金) 00:02:43.09 ID:cA/HuquY0.net

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

229 ：デフォルトの名無しさん ：2023/11/24(金) 00:24:17.65 ID:Wcn967L80.net

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

230 ：デフォルトの名無しさん ：2023/11/24(金) 00:45:17.10 ID:6OrpRj0R0.net

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

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

231 ：デフォルトの名無しさん ：2023/11/24(金) 00:56:07.29 ID:Wcn967L80.net

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

232 ：デフォルトの名無しさん ：2023/11/24(金) 01:04:25.73 ID:Wcn967L80.net

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

233 ：デフォルトの名無しさん (ﾜｯﾁｮｲ e97e-OZuz)：2023/11/24(金) 08:28:38.02 ID:ksIXeJJJ0.net

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

234 ：デフォルトの名無しさん ：2023/11/24(金) 13:19:56.18 ID:+HdIulh/0.net

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と言語仕様がどんどん複雑になっているから完全に対応は難しいかもしれんが。

235 ：デフォルトの名無しさん ：2023/11/27(月) 09:37:28.94 ID:BB7NmH0K0.net

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

236 ：デフォルトの名無しさん ：2023/11/27(月) 12:16:24.67 ID:0LRMXswf0.net

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

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

237 ：デフォルトの名無しさん (ｱｳｱｳｳｰ Sa0b-6V65)：2023/11/29(水) 06:07:56.97 ID:n75oaT1ga.net

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

238 ：デフォルトの名無しさん ：2023/11/29(水) 12:33:39.58 ID:fVcl6vAK0.net

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

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

239 ：デフォルトの名無しさん ：2023/12/06(水) 14:35:16.69 ID:FgD2yr5e0.net

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

240 ：デフォルトの名無しさん ：2023/12/06(水) 15:24:48.70 ID:MT5mgeUa0.net

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

241 ：デフォルトの名無しさん ：2023/12/06(水) 15:53:12.48 ID:KVh/UeYmM.net

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

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

242 ：デフォルトの名無しさん ：2023/12/06(水) 16:40:19.51 ID:MT5mgeUa0.net

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

243 ：デフォルトの名無しさん ：2023/12/06(水) 18:39:52.78 ID:Lg+sIo970.net

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

244 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 8ab6-yDrh)：2023/12/08(金) 03:22:50.77 ID:OHR+wWxR0.net

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

245 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 6683-9d3Q)：2023/12/08(金) 05:55:14.09 ID:xBCOoZoU0.net

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

246 ：デフォルトの名無しさん ：2023/12/08(金) 09:48:35.93 ID:k3Bpg+TDa.net

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

247 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 7501-M0la)：2023/12/08(金) 23:03:52.41 ID:Pln0qn0V0.net

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

248 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 9734-C3j7)：2023/12/13(水) 08:12:56.25 ID:SOLvnyCP0.net

待望の新言語

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

249 ：デフォルトの名無しさん ：2024/02/06(火) 21:17:51.46 ID:vknt9k+q0.net

待望の新言語

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

250 ：デフォルトの名無しさん ：2024/02/08(木) 14:58:56.60 ID:fJ9G9a/R0.net

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

251 ：デフォルトの名無しさん ：2024/03/29(金) 21:11:42.51 ID:F+7of5fq0.net

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

252 ：デフォルトの名無しさん ：2024/03/29(金) 23:02:59.73 ID:JKQcuRe50.net

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

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/

253 ：デフォルトの名無しさん ：2024/03/30(土) 02:29:10.46 ID:n/Lqlt000.net

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

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

254 ：デフォルトの名無しさん ：2024/04/10(水) 00:48:05.23 ID:PZl/2Qvj0.net

どんぐりテスト

255 ：デフォルトの名無しさん ：2024/04/28(日) 22:41:22.44 ID:UPZ0W4Nj0.net

hoshu

256 ：デフォルトの名無しさん (ﾜｯﾁｮｲ a7f9-y8PE)：2024/04/29(月) 13:16:16.09 ID:bo2jVeD+0.net

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

257 ：デフォルトの名無しさん ：2024/04/29(月) 16:50:51.13 ID:12eKztj20.net

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

258 ：デフォルトの名無しさん ：2024/04/29(月) 22:47:28.69 ID:6wHhtPFS0.net

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