次世代言語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
スタックに確保されるのがポインタなのかクラスや構造体の実態なのかをちゃんと理解してない人が多すぎるね
コンパイラとかコンピュータアーキテクチャの勉強すべき
そこを避けてたら絶対に使いこなせない
新着レスの表示
レスを投稿する

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