次世代言語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も相当だしそれだけでは判断できないのでは

2022/08/14(日) 19:14:39.32

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

2022/08/14(日) 19:23:27.68

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

2022/08/14(日) 19:43:04.36

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

2022/08/14(日) 19:55:23.52

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

2022/08/14(日) 19:58:39.91

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

2022/08/14(日) 20:34:35.63

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

2022/08/14(日) 20:39:54.05

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

2022/08/14(日) 20:50:39.49

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

2022/08/15(月) 08:38:26.95

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

2022/08/15(月) 13:39:10.26

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

2022/08/15(月) 15:41:07.32

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

2022/08/15(月) 16:32:14.78

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

2022/08/16(火) 18:56:36.29

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>52
だよね。

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

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

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

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

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

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

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

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

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

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

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

あげ

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

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

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

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

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

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

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

>>60

std/options で

ひとまずOK じゃないか ?

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

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

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

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

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

>>64

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

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

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

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

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

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

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

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

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

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

>>69
COBOL++でしょ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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