次世代言語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/05(金) 12:18:02.18

乙

2022/08/05(金) 20:57:32.27

本スレ

2022/08/05(金) 23:22:06.64

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

2022/08/06(土) 15:25:50.11

>>1
O2

2022/08/07(日) 04:00:41.01

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

2022/08/07(日) 13:37:10.92

過疎やん

2022/08/07(日) 15:10:39.88

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

2022/08/07(日) 15:41:37.32

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

2022/08/08(月) 01:27:47.98

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

2022/08/08(月) 15:07:53.58

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

2022/08/11(木) 04:05:29.11

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

2022/08/11(木) 08:03:21.25

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

2022/08/12(金) 13:09:15.20

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

2022/08/12(金) 15:40:56.79

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

2022/08/12(金) 18:28:24.07

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

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

2022/08/13(土) 22:42:00.05

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

2022/08/13(土) 23:29:46.92

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

2022/08/14(日) 01:50:30.53

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

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

2022/08/14(日) 01:50:48.23

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

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

2022/08/14(日) 01:53:56.93

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

2022/08/14(日) 02:03:29.71

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

2022/08/14(日) 02:10:20.77

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

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

2022/08/14(日) 02:20:35.55

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

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

foo()

2022/08/14(日) 09:07:22.22

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

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

2022/08/14(日) 09:18:07.39

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

2022/08/14(日) 10:18:19.35

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

2022/08/14(日) 10:55:58.43

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