次世代言語27 Nim Zig Pony Carbon Gleam (308ﾚｽ)
上下前次1-新
251: (ﾜｯﾁｮｲ 5903-T9th) 2024/03/29(金)21:11 ID:F+7of5fq0(1) AAS
Erlangランタイムの静的型付け関数型言語Gleamがバージョン1.0に到達
外部ﾘﾝｸ:www.infoq.com
252: (ﾜｯﾁｮｲ adda-VtrB) 2024/03/29(金)23:02 ID:JKQcuRe50(1) AAS
スレチかもしれないけど、この言語そのものというよりは、作者の目指す未来の言語像が可能性を感じる。
Viscuit
外部ﾘﾝｸ:www.viscuit.com
言語そのもののイメージとしてはProlog版Scratchから、さらに子供に分かりにくい機能を外したもの。
感銘を受けた記事を２，３貼っておきます。
理想的なプログラミング言語
外部ﾘﾝｸ:devroom.viscuit.com
言語の進化とプログラミング教育
外部ﾘﾝｸ:devroom.viscuit.com
プログラミングの大衆化
外部ﾘﾝｸ:devroom.viscuit.com
253: (ﾜｯﾁｮｲ 9edd-rfcW) 2024/03/30(土)02:29 ID:n/Lqlt000(1) AAS
Bun v1.1がついにWindowsネイティブ対応化を引っさげて4月1日リリース予定
日程がエイプリルフールでややザワついてるが敢えてこの日を選んでるっぽい？
Bunを作るZigもv0.12.0が4月2日リリース予定になってるが
こっちは既に数回無告知延期して公式すら話題にしなくなってるのでまたダメかもしれん
254: (ﾜｯﾁｮｲ c24b-7+Gk) 2024/04/10(水)00:48 ID:PZl/2Qvj0(1) AAS
どんぐりテスト
255: (ﾜｯﾁｮｲ 6760-+hba) 2024/04/28(日)22:41 ID:UPZ0W4Nj0(1) AAS
hoshu
256: (ﾜｯﾁｮｲ a7f9-y8PE) 2024/04/29(月)13:16 ID:bo2jVeD+0(1) AAS
で？結局どれがいいんだい
257: (ﾜｯﾁｮｲ 2701-Ufki) 2024/04/29(月)16:50 ID:12eKztj20(1) AAS
Rustが死んだからZigかCarbonかな
258: (ﾜｯﾁｮｲ c767-NzXl) 2024/04/29(月)22:47 ID:6wHhtPFS0(1) AAS
死んでるの？
俺の中では同系統のコンセプトに対抗できてる言語が一切見られないので Rust 一強な勢いなんだが。
259: (ﾜｯﾁｮｲ 2501-b/g4) 2024/06/08(土)08:52 ID:SAkY8LF70(1) AAS
Zigのリリースサイクル早いね、もう0.13.0がリリースされた
260: (ﾜｯﾁｮｲ a575-eRYk) 2024/07/08(月)21:11 ID:EaEf11Cm0(1) AAS
待望の新言語
生成AIに疑似コードで指示すると自然言語よりも効率的にプログラムが生成できるというアイデアから生まれた、生成AI用の疑似言語「SudoLang」
外部ﾘﾝｸ[html]:www.publickey1.jp
261: (ﾜｯﾁｮｲ 1b16-tQMZ) 2024/07/09(火)01:43 ID:SMbKjjog0(1) AAS
本末転倒だろ
262(2): (ｵｲｺﾗﾐﾈｵ MM1b-qpqo) 2024/09/01(日)15:29 ID:f0nFMo6oM(1) AAS
RustがCより速くなるベンチマークは見たことがないです
NimのORCは明示的にオブジェクトプールを使ったプログラミングが必要ですが
ベンチマークがCより２倍以上速くなって、特にハードなリアルタイムシステム向け
のチューニングもできるようになっているようです
外部ﾘﾝｸ:zenn.dev
NimがCより２倍以上速くなって、しかもORCでメモリ安全も担保されているなら
Rustを使う意味がなくなると思うのですが、このベンチマークは本当なのでしょうか？
263: (ﾜｯﾁｮｲ eaad-voeu) 2024/09/08(日)01:45 ID:Hh5CAE6t0(1) AAS
>>262
nimは一旦ｃに変換してコンパイルするので、ｃより早くなる事はないです。
ベンチマークで早くなっているのは、メモリプールを使っているからです。
(個別にヒープメモリを確保するのではなく、大きなブロックで一度に確保して
自分で割り当てを管理しているから）
私もｃでメモリプールを実装した事がありますが、ヒープのメモリ確保のコスト
は以外と大きくて、一括で確保するのはパフォーマンスの面で効果が大きいです。
またこのメモリプールの部分は自前でメモリ管理しているため、ＯＲＣとは関係が
ないです。（参照リンク元の記事の意図は、ＯＲＣと手動管理が混在できる事を
利点としているかと思います）
Ｒｕｓｔは詳しくないのですが、おそらくこのレベルの実装は可能だと思うので、
同じように実装すれば同程度の速度向上になるかと思います。
（ただし一括メモリ確保->個別データに強制castが必要で安全性は落ちる）
参照リンク元の記事は、メモリプールのような低水準のコードでもＮｉｍは高い
可読性で書く事ができると言いたいのでは。（手動確保したメモリをdestroy定義
で自動解放できる所とか）
264: (ﾜｯﾁｮｲ f9df-BHET) 2024/09/08(日)07:43 ID:vegiTRtO0(1) AAS
>>262
>ベンチマークがCより２倍以上速くなって
という記述は見当たらないけど
> NimがCより２倍以上速くなって、しかもORCでメモリ安全も担保されているなら
> Rustを使う意味がなくなると思うのですが、このベンチマークは本当なのでしょうか？
「メモリプールが速い」は本当だろう
「Cより速い」は、そもそもそんなことを書いてないのでダウト
Rustは分からんけどGCが無いぶんNimよりは有利なのでは
265: (ｱｳｱｳｴｰ Sadf-D2eP) 2024/10/02(水)13:03 ID:XbzwGALZa(1) AAS
RustがNimより速い訳がない
266(1): (ﾜｯﾁｮｲ ffad-4whB) 2024/10/03(木)12:29 ID:gQlcDFcc0(1) AAS
nim 2.2.0 リリース
久しぶりに速度をはかるとかなり高速化されているようだ。
単純なフィボナッチ計算４５桁で実測
-d:releaseコンパイルで約26%, -d:dangerで約33%高速化している。
(実際の高速化はこの一つ前のバージョン2.0.10でされている）
267: (ﾜｯﾁｮｲ 6f9f-xlWa) 2024/10/03(木)13:32 ID:/N1KY/IS0(1) AAS
実用コードでそこまでの差はないだろうけど
チェックの省略やTCOが上手になったのかな
Cコードで差分とってみてほしい
268: (ﾜｯﾁｮｲ ffad-4whB) 2024/10/05(土)02:05 ID:dycfQkyl0(1) AAS
266です。
nimから出力されたCコードの差分を取った所、違っていた箇所は以下の２点でした。
?メイン処理に入る前のnim側の初期化処理（関数名が変わっている）
?フィボナッチ関数内のresult変数の０初期化
※gccのコンパイルオプションも全く同じ
特に高速化に繋がる変更はなく、なぜ早くなるのか不明でしたが、色々と試して
上記?が原因と分かりました。
nimのresult変数の初期化が入る事で、ｇｃｃ側のコンパイル最適化で高速化
しているようです。
試しにnim2.0.8でresult変数を０初期化した所、nim2.2.0と同じ処理速度
が出る事が確認できました。
(フィボ関数内の先頭でresult変数を０初期化し、以降の算出値をresult変数に
格納するように変更した）
269: (ﾜｯﾁｮｲ 231f-olmx) 2024/10/05(土)14:35 ID:tOSXTi2h0(1) AAS
>>266
Nimの場合はバックエンドに使うCコンパイラの最適化能力も実行速度に影響します。Nimのバージョン間の実行速度を比較するときにCコンパイラのバージョンを同じにしていますか?
面倒でなければCコンパイラの出力するアセンブリコードを読むと何故result変数を0初期化することが処理速度に影響するかわかると思います。
--passC:"-S"というコンパイラオプションをNimに渡すとnimcacheディレクトリにアセンブリコードが出力されます。
270: (ﾜｯﾁｮｲ caad-6k2q) 2024/10/06(日)13:25 ID:yuNPVtUj0(1) AAS
>Nimの場合はバックエンドに使うCコンパイラの最適化能力も実行速度に影響します。Nimのバージョン間の実行速度を比較するときにCコンパイラのバージョンを同じにしていますか?
当然同じ環境です。choosenimでバージョン切り替えて確認してます。
私の疑問点は解消しましたし、gcc側の最適化内容まで追うつもりはないので、私の方の検証はこれで終了とします。
271: (ﾜｯﾁｮｲ 3901-c8YC) 2024/10/26(土)14:10 ID:lE9emaTH0(1) AAS
Zig言語で開発したターミナルエミュレータだってさ
ミッチェル・ハシモト氏の個人開発によるターミナルエミュレータ「Ghostty 1.0」、12月に正式リリース予定。オープンソースとして公開へ
2024年10月25日
外部ﾘﾝｸ[html]:www.publickey1.jp
272: (ｽﾌﾟｰﾌﾟ Sdbf-hCSs) 2024/11/29(金)13:35 ID:cbzvCkJwd(1) AAS
Crystalとかわりと新しめな言語っぽいけど次世代言語としてはあんま価値はない感じ？
273: (ﾜｯﾁｮｲ 9f1c-ksDR) 2024/11/29(金)14:06 ID:kgssLEYJ0(1) AAS
対立煽りに荒らし尽くされて過疎ってるだけだから気にせんと何でも書いてってや
274: (ﾜｯﾁｮｲ 7702-cdGy) 2024/11/29(金)18:48 ID:KH+D4ATv0(1) AAS
やはり、実際に採用されたプロダクトが出てくる頻度で見ると、Zigが頭一つ抜けてるな
275: (ﾜｯﾁｮｲ 6208-Dngz) 2024/12/03(火)00:07 ID:SdCS4Rrb0(1) AAS
zigをCコンパイラもどきとして扱うのはよく見るけどzig言語の採用例ってあんまり多くなくない
276(1): (ﾜｯﾁｮｲ 96b3-jW52) 2024/12/03(火)06:50 ID:hGt3IOpB0(1/3) AAS
時雨堂もZig撤退しちゃったしなぁ
277(1): (ﾜｯﾁｮｲ 4502-WFUB) 2024/12/03(火)07:04 ID:JOdYPQk60(1/2) AAS
>>276
マジかよ
それはショックだな
278(1): (ﾜｯﾁｮｲ 967c-jW52) 2024/12/03(火)07:13 ID:hGt3IOpB0(2/3) AAS
>>277
非同期の仕様が全然決まらないかららしい
本家はLLVMに変わるコンパイラバックエンドに注力してるみたいだけど
そんなことより言語仕様とか標準ライブラリやったほうがいい気はする…
279: (ﾜｯﾁｮｲ 4502-WFUB) 2024/12/03(火)07:40 ID:JOdYPQk60(2/2) AAS
>>278
本家は今のCの適用範囲をそのままZigで置換することを目指していて
範囲外にある非同期に関心薄いのはしょうがないのでは
280: (ﾜｯﾁｮｲ 2af5-jW52) 2024/12/03(火)08:12 ID:13VhrJJT0(1) AAS
Cの適用範囲ってのが残ってるのかちょっと疑問はある
Rust for Linuxの騒動でも感じたけどCにこだわりのある人はC以外に移行しないと思う
移行してもいいって人はすでにRustなりに行ってる可能性高いし
組み込み系は残ってるけど認定コンパイラ必須だからハードル高いし
そもそもユーザ増えないと認定にお金出してくれる会社も現れないんだよな
上下前次1-新書関写板覧索設栞歴
あと 28 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.007s