次世代言語27 Nim Zig Pony Carbon Gleam (308ﾚｽ)
上下前次1-新
1(1): (ﾜｯﾁｮｲ c35f-St8y) 2022/08/05(金)09:40 ID:/hLfNpmA0(1)調 AAS
!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
スレタイ（順番はRedMonk準拠）以外の言語もok
前スレ
次世代言語26 TypeScript Swift Go Kotlin Nim
2chｽﾚ:tech VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured
2: (ﾃﾃﾝﾃﾝﾃﾝ MMee-Jv5Y) 2022/08/05(金)12:18 ID:X0qTPiXKM(1)調 AAS
乙
3: (ﾜｯﾁｮｲ ba7c-t4GX) 2022/08/05(金)20:57 ID:IaHwMjJC0(1)調 AAS
本スレ
4: (ﾜｯﾁｮｲ 9a4b-Xfpw) 2022/08/05(金)23:22 ID:mIb2aBTZ0(1)調 AAS
ただし Rust言語ネタは禁止します
5: (ｱｳｱｳｳｰ Sa55-9Xv3) 2022/08/06(土)15:25 ID:eSBCWCwIa(1)調 AAS
>>1
O2
6(1): (ﾜｯﾁｮｲ 895f-UFof) 2022/08/07(日)04:00 ID:40aW3DD80(1)調 AAS
久々にHaxeのプロジェクトページを訪ねてみたらサポートターゲットにHashLinkなるVMが追加されていた
Nekoの後継？
7: (ﾜｯﾁｮｲ 1907-Z5J/) 2022/08/07(日)13:37 ID:Dd35QVWO0(1)調 AAS
過疎やん
8: (ｽｯｯﾌﾟ Sd33-agxP) 2022/08/07(日)15:10 ID:G9vPq40Zd(1)調 AAS
>>6
haxeまだあったのか。
昔ちょろっと見てけっこう良さそうな印象持ったけど流行らなかったな。
nimもトランスレーター系だし、同じ将来にはならないで欲しい。
結局はバックにGAFAMがつくかどうかによるのかねぇ。
それでいうとpythonは運・タイミングが良かったのか。
9(1): (ｻｻｸｯﾃﾛ Sp5d-RXyn) 2022/08/07(日)15:41 ID:SSq6cfdBp(1)調 AAS
nimとかD言語みたいなちょっと良くした程度の言語だと流行らないんだろうなあ
RubyでいうRailsみたいな超人気フレームワークが登場すると話が変わってくるんだろうけも
10(1): (ﾜｯﾁｮｲ 1b8c-lJ3c) 2022/08/08(月)01:27 ID:mO/LiGB20(1)調 AAS
>>9
NimはもっとシームレスにPythonソースを使えればいいんだけど。
nimpyとかnimporterとかって公式になったっけ？
11(1): (ﾜｯﾁｮｲ 132c-D0FT) 2022/08/08(月)15:07 ID:XhYLtnJ40(1)調 AAS
>>10
nimpyやnimporterが公式になるってどういうこと?
標準ライブラリになることを期待してるのかもしれないが、標準ライブラリになったとしても使いやすくなるとは限らないよ。
C/C++のライブラリだったらc2nimやfutharkというツールがC/C++のコードを読んで自動的にバインディングを生成してくれるらしい。
futharkはlibclangを使ってコードをパースするらしい。
12: (ﾜｯﾁｮｲ 13a5-s6Hz) 2022/08/11(木)04:05 ID:Bpvt7Gu80(1)調 AAS
CarbonってC++のABI問題の拗れが引き金となって生まれたものなんだろうけど
わざわざ文法から作り直すことないのにな
実用的なレベルになるまで相当かかりそう
13: (ｽｯｯﾌﾟ Sd33-JIap) 2022/08/11(木)08:03 ID:6LydNS9Hd(1)調 AAS
GoogleでC++の糞の山のメンテばっかりさせられて嫌気が差したんだろ
所詮数あるホビー言語の一つに過ぎないんだから好きにさせてやれよ
14(1): (ﾃﾃﾝﾃﾝﾃﾝ MM8b-lJ3c) 2022/08/12(金)13:09 ID:0xlDyyucM(1)調 AAS
>>11
公式になって手順・ドキュメントが整備されるというということだな。
そうすればもっとpythonコードが流用しやすくなるので、性能で困っているpythonユーザーが手を出しやすくなるかと。
15(1): (ﾜｯﾁｮｲ 937c-agxP) 2022/08/12(金)15:40 ID:bDQmrk+50(1)調 AAS
nimのアンダースコアを無視する仕様は好きじゃない。
16: (ﾜｯﾁｮｲ 132c-D0FT) 2022/08/12(金)18:28 ID:D0nb2yzy0(1)調 AAS
>>14
公式になったからといってドキュメントが整備されるとも限らないし
公式にならなくてもやる気があればドキュメントを整備するＰＲを送ればいいのでは。
>>15
アンダースコアを無視するおかげで、ライブラリがfoo_barみたいな名前を使っていてもライブラリを使う側のコードがfooBarという名前で呼び出せるので命名規則に一貫性をもたらすことができる。
しかしCのライブラリがfoo_barとfooBarという異なる二つの関数を持っているとNimから使うときに違う名前を使って参照するようにbindingを書かなくてはいけなくなってしまう。
そいいうケースはあまりないけどね。
17(3): (ﾜｯﾁｮｲ 468c-Waa7) 2022/08/13(土)22:42 ID:6wAoLN5t0(1)調 AAS
Rustを見てて疑問に思うところがあるんだけど、
「コールスタック専用変数」「ヒープ用変数」といった
使い分けをする言語はあるのかしらん？
現状の言語で近いのは
C：変数はコールスタック専用。ヒープのインスタンスはポインタで管理
Rust：変数はコールスタック専用。ヒープ用変数はBox、Vec、Rcとかで模倣
ぐらいか。
コールスタックにあるインスタンスはスコープに連動するRAIIとかの便利な特性があるから、
他の言語でもコールスタック専用変数があってもいいと思うんだけど。
例えばJavaにコールスタック用変数があればfinalizeメソッドももっと使いやすくなりそう。
コールスタック用変数専用クラスとかあってもいいし。
18(1): (ｽｯｯﾌﾟ Sd62-Rl2g) 2022/08/13(土)23:29 ID:601ao6Evd(1)調 AAS
スタックとヒープの使い分けができるという意味ならGoとかC#とか
19: (ﾜｯﾁｮｲ 422c-GRcq) 2022/08/14(日)01:50 ID:H+Dty+yM0(1/6)調 AAS
>>17
Nimでもスタックとヒープを使いわけられるよ。
refのついた型とクロージャの環境とstring, seqの中身はヒープに確保される。
それ以外のローカル変数はスタックに確保。
C言語のグローバル変数とstatic変数はstatic storageというスタックとは別の所に置かれるよ。
だいたいのシステムプログラミング言語ならヒープとスタックを使い分けられるんじゃないの？
20(1): (ﾜｯﾁｮｲ 422c-GRcq) 2022/08/14(日)01:50 ID:H+Dty+yM0(2/6)調 AAS
>>17
Nimでもスタックとヒープを使いわけられるよ。
refのついた型とクロージャの環境とstring, seqの中身はヒープに確保される。
それ以外のローカル変数はスタックに確保。
C言語のグローバル変数とstatic変数はstatic storageというスタックとは別の所に置かれるよ。
だいたいのシステムプログラミング言語ならヒープとスタックを使い分けられるんじゃないの？
21(1): (ﾜｯﾁｮｲ 468c-8lLW) 2022/08/14(日)01:53 ID:XCwSZ99k0(1/2)調 AAS
>>18
変数のエスケープ解析して自動でヒープとスタックを使い分けるんじゃなくて、その変数をスコープからエスケープするような使い方をしたときにコンパイルエラーにするようなのを想定しています。
スタックフレーム制約付き変数ですな。
22(1): (ﾜｯﾁｮｲ 468c-8lLW) 2022/08/14(日)02:03 ID:XCwSZ99k0(2/2)調 AAS
>>20
確か、Nimもスタックフレームにインスタンスを置くことを強制できなかったかと思うけど、どうだったっけ？
23: (ﾜｯﾁｮｲ 422c-GRcq) 2022/08/14(日)02:10 ID:H+Dty+yM0(3/6)調 AAS
>>17
Nimでもスタックとヒープを使いわけられるよ。
refのついた型とクロージャの環境とstring, seqの中身はヒープに確保される。
それ以外のローカル変数はスタックに確保。
C言語のグローバル変数とstatic変数はstatic storageというスタックとは別の所に置かれるよ。
だいたいのシステムプログラミング言語ならヒープとスタックを使い分けられるんじゃないの？
24: (ﾜｯﾁｮｲ 422c-GRcq) 2022/08/14(日)02:20 ID:H+Dty+yM0(4/6)調 AAS
間違えて連続投稿してすいませんでした。
>>22
type
SomeObj = object
x: int
proc foo =
var x = SomeObj(x: 10) #スタックに確保
var y = new(SomeObj) #ヒープに確保
foo()
25(1): (ｽﾌﾟｯｯ Sd62-IWzR) 2022/08/14(日)09:07 ID:5kZWLu5Dd(1)調 AAS
ここの系列で出たことあるのか知らないし、ちょっと毛色違うんだけど設定ファイル言語でDhallってあるんだね
方向性は凄く好みなんだけど最新バージョンの規格をそのまま食えるのが現状Haskell（とPureScript?）だけらしくて君らそういうところやぞ……ってなってる
yamlやjsonに変換してから食わせることはできるらしいけどやっぱそのまま食えるのと手間と複雑さは無駄に嵩張るし、この手のDSLはどれだけ広い環境で使えるかが重要よねって
26: (ｽｯｯﾌﾟ Sd62-Rl2g) 2022/08/14(日)09:18 ID:E6D9Byfed(1)調 AAS
>>21
C#はスタック変数のエスケープは不可で、その参照を返すようなことはできない
クロージャでキャプチャされたり非同期メソッドの場合にヒープに昇格する例外はあるが、文脈から明らかであり、いわゆるエスケープ解析とは異なるものだ
更に、構造体を ref struct として定義することで上記のような昇格も不可となり、完全にスタック専用になる
27: (ﾜｯﾁｮｲ 4201-8lLW) 2022/08/14(日)10:18 ID:osAuRY7C0(1/2)調 AAS
>>25
ちょっとぐぐってみたけど俺はできると思ってる子がなんかこれあったら便利やんって言うのを色々詰め込んだイメージ
本当にでかい設定ファイルなら嬉しいのかも知れないけど大多数の設定ファイルにはオーバースペック過ぎて流行らないと思う
28: (ﾜｯﾁｮｲ adda-TI6p) 2022/08/14(日)10:55 ID:lDco67Nc0(1/2)調 AAS
オーバースペックさで言うとyamlも相当だしそれだけでは判断できないのでは
29(2): (ﾜｯﾁｮｲ 79f0-mhOm) 2022/08/14(日)19:14 ID:1Y4ysm770(1)調 AAS
スタックとかヒープとか基本的に実装依存じゃないの
言語レベルで規格として策定されてるのある？
30(1): (ﾜｯﾁｮｲ 027c-5Ix7) 2022/08/14(日)19:23 ID:TMCPzdUa0(1)調 AAS
CやC++はmallocやらnewなどでメモリ確保しない限りは全てスタックではないの？
今時のコンパイラはどうやってるのか知らんけど昔は少なくともそうだった
31: (ﾜｯﾁｮｲ 422c-GRcq) 2022/08/14(日)19:43 ID:H+Dty+yM0(5/6)調 AAS
可変長配列とか文字列型などの必要なメモリ量が実行時に決まるものや
関数やブロックのスコープと変数の寿命が対応しないもの(GCで管理されるオブジェクト)などはヒープ使うしかないでしょ。
けどローカル変数などをヒープに置くと効率悪いし。
32: (ﾜｯﾁｮｲ 4201-8lLW) 2022/08/14(日)19:55 ID:osAuRY7C0(2/2)調 AAS
>>29
ハードウェアスタックがないマシン（汎用機とか）もあるから実装依存なのは確かだけどそういうマシンでもソフトウェアでスタック作ってるので実装としてはたいして変わらん
33: (ﾜｯﾁｮｲ 422c-GRcq) 2022/08/14(日)19:58 ID:H+Dty+yM0(6/6)調 AAS
>>30
関数の外にある変数やstatic変数はstatic storageというプロセスが生まれてから死ぬまで存在し続ける領域に置かれるよ。
詳しくはdata segmentとかbssとかで検索してね。
static変数は値を保持し続けないといけないからスタックに置けないし、
関数の外にある変数は複数の関数から共有されるのでコンパイル時かリンク時にアドレスが決まってないといけないと思うのでおそらくスタックに置けない。
34(2): (ｱｳｱｳｳｰ Saa5-xzlL) 2022/08/14(日)20:34 ID:d/RE/iMKa(1)調 AAS
C++の定石としてオブジェクトはスタックに置くのが基本だよ
デストラクタを動かしたいからね
ヒープにデータを割り当てたい時は構造体やクラスでラップするのが基本
35: (ﾜｯﾁｮｲ adda-TI6p) 2022/08/14(日)20:39 ID:lDco67Nc0(2/2)調 AAS
>>29
最適化の余地残すために規格では振る舞いしか記述しないのが基本だと思う
レジスタだけ使うとかあるしね
36: (ｽﾌﾟｯｯ Sd62-IWzR) 2022/08/14(日)20:50 ID:/dHI52Jsd(1)調 AAS
可変長配列に限って言えばCは一応VLAがある
11からオプションだけど
37(1): (ﾌﾞｰｲﾓ MMb6-Rl2g) 2022/08/15(月)08:38 ID:qDRL1WTlM(1)調 AAS
>>34
スマポ使えばいいだけだからそれはない
38: (ｱｳｱｳｳｰ Saa5-xzlL) 2022/08/15(月)13:39 ID:SFJl5V0da(1)調 AAS
>>37
スマポがまさに>>34のパターン使ってるんだけど
39: (ﾜｯﾁｮｲ 027c-5Ix7) 2022/08/15(月)15:41 ID:qHbAfBQi0(1)調 AAS
スマートポインタｗって正直使う必要殆ど無いのに
全てのインスタンス生成で使うバカがいるよねｗ
40: (ﾜｯﾁｮｲ 4201-8lLW) 2022/08/15(月)16:32 ID:zxOEKBbO0(1)調 AAS
今時生ポインタでイキルバカが出てくるとはw
41: (ﾜｯﾁｮｲ e9e6-xzlL) 2022/08/16(火)18:56 ID:1oXHhIiq0(1)調 AAS
スタックに確保されるのがポインタなのかクラスや構造体の実態なのかをちゃんと理解してない人が多すぎるね
コンパイラとかコンピュータアーキテクチャの勉強すべき
そこを避けてたら絶対に使いこなせない
42(1): (ﾜｯﾁｮｲ 027c-5Ix7) 2022/08/16(火)19:04 ID:JSsOGCvC0(1)調 AAS
そもそもスタックやらヒープやらちゃんと意味が分かっている奴って
アセンブラレベルで組んだことがあるとかじゃないと
知らなくても仕方ない気がするなぁ
43: (ﾜｯﾁｮｲ 460f-U+eq) 2022/08/16(火)19:50 ID:RYKZv1s10(1)調 AAS
使いこなす必要は無くて、理解が足りなくてもやりたい事が出来れば、それで良いと思うよ。
44: (ｱｳｱｳｳｰ Saa5-xzlL) 2022/08/17(水)15:25 ID:DfCxGnRFa(1)調 AAS
理解してなくてやりたいことができるってそれはたまたま動いてるか
その機能が必要ないことをやってるだけ
壁が来た時ぶち当たって手遅れになる
最近スクリプト言語系のエンジニアがRustとかのモダン言語で苦しんでるのを見ると
何が理解できてないのか？を理解することってのはすごく大事
45: (ﾜｯﾁｮｲ 3104-GRcq) 2022/08/17(水)16:47 ID:hcUDPGl30(1)調 AAS
Compiler explorerとかでコードがどんな風に最適化されてアセンブリ言語になるか読んでみるといいかもね。
スタックに割り当てられたローカル変数はレジスタに割り当てられる場合はあるけどグローバル変数やヒープにある変数はかならずメモリ上におかれるから毎回メモリからレジスタにロードして値を計算してからメモリにストアされる。
46: (ﾜｯﾁｮｲ ed7c-n+Ky) 2022/08/17(水)17:41 ID:J/baCQNr0(1)調 AAS
最適化でキャッシュの考慮や制御までするんだから
volatileないと実際どうなるかはわからんとちゃうかな
47(1): (ﾜｯﾁｮｲ 9901-5Ix7) 2022/08/17(水)17:53 ID:cnWCAZlk0(1)調 AAS
Rustやるなら当然アセンブラが理解できないとってことだね
メモリ安心安全のためには必要なコストだよね
48: (ﾜｯﾁｮｲ 9901-U+eq) 2022/08/17(水)20:56 ID:9RiCNb2+0(1)調 AAS
プログラム書くのが本業の人なら、どうやってプログラムが動くのか知らなきゃっていうのは分かるけれど、プログラムば手段であって、コピペでも何でも良いから欲しい結果が得られるなら良いって人もいるから。
それで、Rustがそんな人に合わせる必要はないし、そんなのはPython辺りに任せて、Rustはプロフェッショナルの道具でいいんじゃないの？
上下前次1-新書関写板覧索設栞歴
あと 260 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.023s