次世代言語28 TypeScript Swift Go Kotlin Rust Nim

**デフォルトの名無しさん** · 2022/08/29(月) 11:22:16.48

スレタイ以外の言語もok

前スレ
次世代言語27 TypeScript Swift Go Kotlin Rust Nim
https://mevius.5ch.net/test/read.cgi/tech/1659655598/

**デフォルトの名無しさん** · 2022/09/15(木) 15:09:17.30

率直に言うと、Nimには開発者、コミュニティの言語オタク感が、、(いい意味で)

**デフォルトの名無しさん** · 2022/09/15(木) 15:26:45.00

>>763
ソースコードのマネージャーw
妄想が過ぎるやろww
お前やっぱり複オジと同じ種類の人間やな

**デフォルトの名無しさん** · 2022/09/15(木) 15:28:52.49

>>782
エンジニアの単なる個人的な好みだよ
スタートアップの開発はだいたいエンジニア1人～せいぜい2,3人で始まり、作り方について外から誰も口出さないから、何でも好きなものを採用できる
とはいえあまり変なものは後からリプレースされることも多いが、あえて関数型使いたがるような奴は比較的優秀だから結果的に生き残りやすいんだろうね

**デフォルトの名無しさん** · 2022/09/15(木) 17:40:49.72

>>776
どの言語もそうだけど慣れの問題だけだよ
慣れるまでは躓きやすいけど
慣れてしまえばそこに何か支障があるわけではなく快適

もちろん手続き型言語しか使ったことがなかった人が関数型言語を始めれば　最初だけカルチャーショック的なものもあるかもしれない

Rustは従来の手続き型言語のバリエーションの範囲内であり難しい点はなにもない
最近は増えてる関数型プログラミングを積極的にサポートしているだけの普通の手続き型言語である

**デフォルトの名無しさん** · 2022/09/15(木) 18:14:28.13

ブレーキ云々は関数型ではなく静的型に責任がある
と理解するまでに10年単位の時間を消費してるのが現実

**デフォルトの名無しさん** · 2022/09/15(木) 18:19:41.49

lispはプロトタイプから本番に移行するに向いている的な事をどこかで見かけたんだけど、何か理由あるのかな？

本番であれば、今時は静的型付けの方が実行前にミスを減らせて良さそうって思うんだけど。

**デフォルトの名無しさん** · 2022/09/15(木) 18:30:04.54

lispで思い出される文章はこれ
http://practical-scheme.net/trans/beating-the-averages-j.html

**デフォルトの名無しさん** · 2022/09/15(木) 18:42:43.79

Concurrencyについては詳しくないんだけど
goはやっぱりつよいの？
erlangよりつよいの？

**デフォルトの名無しさん** · 2022/09/15(木) 18:55:22.88

>>786
マニュアル教習車の運転を「慣れの問題」と言っているようなもんだな。
最初はエンストしまくっていても、慣れればいつかは運転できるようになるわな。それがいつだか知らんけど。

**デフォルトの名無しさん** · 2022/09/15(木) 19:08:20.73

>>777
そういえば前スレでrustは原付（php）に速度で負けてたよね

**デフォルトの名無しさん** · 2022/09/15(木) 19:48:17.43

統一教会「Rustをお持ちしました」

**デフォルトの名無しさん** · 2022/09/15(木) 20:20:12.75

嫌いなものにはとりあえず統一教会と絡ませておけば批判したことにできる頭の具合が羨ましい

**デフォルトの名無しさん** · 2022/09/15(木) 21:03:43.45

統一教会「晋三を捧げよ」

**デフォルトの名無しさん** · 2022/09/15(木) 21:29:46.27

>>794
いやあ、それほどでも（照

**デフォルトの名無しさん** · 2022/09/15(木) 21:32:22.04

世界統一平和自民党から怒られるぞw

**デフォルトの名無しさん** · 2022/09/15(木) 21:55:28.22

マジか。

**デフォルトの名無しさん** · 2022/09/15(木) 22:18:19.78

>>788
common lisp とかだとあとから型書いてパフォーマンス上がる処理系とかあった気がするし、プロトタイプから色々柔軟に改修しやすいとかあったのかもね。

**デフォルトの名無しさん** · 2022/09/15(木) 23:09:10.28

次スレはこれらの言語を入れてください
Zig
https://ziglang.org/ja/
Jakt
https://github.com/SerenityOS/jakt

**デフォルトの名無しさん** · 2022/09/15(木) 23:18:38.32

バージョンが 1.0 に達していない言語は混乱するだけだから入れなくていいよ
必要なら専用スレを立てた方がいい

**デフォルトの名無しさん** · 2022/09/16(金) 00:51:51.14

genesisを入れろ

**デフォルトの名無しさん** · 2022/09/16(金) 01:45:52.39

ちゃんと>>1に「スレタイ以外の言語もok」と書かれているように
それ以外の言語の話もこのスレでは歓迎です

スレタイは文字数制限があるため全ての言語を列挙することはできません
もし話題の多い言語が出てくれば話題の少ない言語と交代することになるでしょう
登場して20年以上経つ古い言語はもちろん対象外です

**デフォルトの名無しさん** · 2022/09/16(金) 06:52:08.13

Rustを外せ（コッソリ

**デフォルトの名無しさん** · 2022/09/16(金) 06:56:42.28

ここが隔離スレだろ

**デフォルトの名無しさん** · 2022/09/16(金) 07:49:14.15

Rustの話題はRustスレでいいだろ

**デフォルトの名無しさん** · 2022/09/16(金) 07:52:17.18

>>796
彼女が企画もののAVに出てそう

**デフォルトの名無しさん** · 2022/09/16(金) 08:18:42.51

>>790
goは聞きかじりだけどもシングルスレッドのコードを気楽に拡張して同時実行にできることが売りに見える
erlangは最初から並列であることを求めてるから方向性が違う
どっちも強いは成り立つんじゃないかな

**デフォルトの名無しさん** · 2022/09/16(金) 10:19:44.03

お待たせしました(awesomeレス 1of3 ※)

Clojure StackOverflow >愛され言語ランキング上位　2つあるawesome-clojureがどちらもマメに更新されてる
　　　　CircleCIとかいくつかの実用サービスに使われてるのがすごい　「本物のREPL」(未確認)　LogSeq
　　　　Apple,CircleCI,Cisco,Cognitect,Nubank🏧,Walmart >使ってますが何か？ https://docs.google.com/spreadsheets/d/1jBQD-rzOeGeKgLjsQ21r4YfEHp8XOpB_vl6TGJEBj3g/edit#gid=0
Rust　　試食コーナーで食べてもらって狂喜乱舞
　　　　GAFAM >Rustエコシステムには投資しないトリクルダウン無し寡占する　GAFAM >だが今は試食タイムだ
　　　　GAFAM >「あま～～い」ってさけんで食レポしてる😏みんな食べに来てね😛
　　　　StackOverflow >愛され言語ランキング1位
　　　　JetBrains >Rustで作らしてくれーと言ってるけど許可降りない
　　　　KENTA >提灯コメント出さない
　　　　俺 >数学出来ないのでRustはキツイ規制の鶴亀算が史上最強　鶴亀算でRustフレームワークが充実することなんて無い
　　　　Rust >鶴亀算だけなら俺が安全性や正しさを確実に保証 unsafe☢は関知しないお前の責任だ
　　　　俺 >今はRustだけで良い。レベルアップはお断りだ　数学出来ないけど有能社員を指導したいとは思ってる　すべての理解が概念的概念的に理解すれば簡単だ
　　　　有能社員 >Rustは学習コストが高い割に使えない　C/C++を書けないとRustは書けない、Rustは意味なし
　　　　有能社員 >Rustは言語オタク二極化だと思ってたらHaskell衰退の道を追う　Rustには興味のアンテナ張るだけ先行投資なんてしない
　　　　現実派 >データ競合がコンパイル時点でゼロってことはない。JARO⚠案件だ
　　　　下っ端社員 >RustはGAFAMなんかより自動車ISO認証級(仮)の実績積み上げがないと、言い出すのも怖い😩
　　　　Rustは教官付き教習車だから、コンパイラの言うとおりに運転しないとブレーキ踏まれて前に進めない。
　　　　現実派 >具体的な話マダー？😡 >絶壁の学習曲線はRustの重大な問題 🆕

**デフォルトの名無しさん** · 2022/09/16(金) 10:22:00.77

お待たせしました(awesomeレス 2of2 ※)

D　　　 C言語と同等に高速で安全も満たす言語　better C/C++の先駆者　breaking changeは日常茶飯事　awesome-d 老舗の割にマメ
OCaml　関数型で速度を最優先するならこれ1択(or F#？)　StackOverflow >愛され言語ではない
F#　　　関数型最速はF#(実例根拠が待たれる)
Go　　　実稼働分野でバリバリ活躍中　GitHub PullReq >TypeScriptとGoが圧倒的
Scala　実稼働分野でバリバリ活躍中　KENTA >日本では衰退しました　ScalaでのNetflix分岐点(未確認)
Nim 　　試食コーナーでスルーされて意気消沈　英語できないので言語マニュアルの日本語訳がスゴい
　　　　Pythonからの乗り換えに最適(未確認 Numpy使ってないPythonコードの高速化例が主？) 🆕
Pony　　開店前　awesome-ponyが2年以上更新されていない
　　　　参照の持ち方だけで6つもある(Reference Capability)　behaviorが終わるごとに該当アクターでGCを回す
　　　　湧く沸くRust >High-Performance Safe Actor Programming https://news.ycombinator.com/item?id=25957307 🆕
Haskell アカデミック勢が根強い　それ以外は衰退しました(未確認)
　　　　Tesla,Microsoft,Meta,GitHub,一流銀行🏧 >使ってますが何か？ https://serokell.io/blog/top-software-written-in-haskell
　　　　Tesla >We use Haskell to auto-generate C code that is compiled into vehicle🚗 firmware.
　　　　下っ端社員 >いい話だ。だが結局☪かよ
Julia　科学技術方面開拓中　StackOverflow >愛され言語ランキング上位
FORTRAN 科学技術方面で強い、しばしば1択
COBOL　金融機関方面では既存システムで根強い　それ以外は衰退しました

**デフォルトの名無しさん** · 2022/09/16(金) 10:24:50.31

Lisp　　JavaScriptと変わらんブランディングした先人たちのマーケティング能力が驚き
　　　　惑星探査機🛰とか特殊な用途、身近なところでルンバ🤖がLisp
　　　　Awesome Lisp Company https://github.com/azzamsa/awesome-lisp-companies
　　　　プロトタイプから本番に移行柔軟に改修しやすい common lisp あとから型書いてパフォーマンスUp 🆕
　　　　思い出 >https://practical-scheme.net/trans/beating-the-averages-j.html >オジさん🧓は言語を変えない 🆕
C　　　 C言語がないぞ C言語がないぞ(大事なことだから2回) 🆕
php　　原付 >静的型はブレーキ🛵 俺にブレーキはない 10年経って分かった <matz😚 🆕
欧米企業「最初のバージョンは常に捨てられる」 🆕
　　　　「アイデアは価値がない、アイデアを誰より早く形にして価値がある」 🆕
Jakt　　https://github.com/SerenityOS/jakt 🆕
　　　　Memory safety, Math safety, performance, transpiles to C++, Inline C++ 🆕
Zig　　 https://ziglang.org/(ja/) en >英語勉強しろ話はそれからだ 🆕
Erlang　方向性が違うどっちも強い >お気楽Goはやっぱりつよいの？ 🆕
　　　　php >原付🛵より遅いぞ https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html 🆕

※ジョーク集です。「未確認」表示の有無に関わらず真偽を保証するものではありません。

**デフォルトの名無しさん** · 2022/09/16(金) 10:25:11.62

病気の人かな
書き込むなよ

**デフォルトの名無しさん** · 2022/09/16(金) 14:24:20.93

>>jakt 追加は
Bounds checking, Sound null safety
try/catchは文
Dict Set TupleがPython並みに簡単この辺はlife-time-analysysに頼らないでARCで実行時管理してるからかな

**デフォルトの名無しさん** · 2022/09/16(金) 15:16:00.68

ARCメインの言語はいずれも遅いから興味ないな
とはいえZigの手動メモリ管理の面倒さと危険さは今の時代ニッチに終わるだろう

**デフォルトの名無しさん** · 2022/09/16(金) 15:25:53.62

あっちのスレでやりなよ
こっちは隔離スレ

**デフォルトの名無しさん** · 2022/09/16(金) 15:55:51.13

ﾜｯﾁｮｲスレのリンク見たら
Written on May 19, 2022 時点で >It’s two weeks old.
っていくらなんでもホヤホヤ過ぎでしょw

**デフォルトの名無しさん** · 2022/09/16(金) 16:35:54.10

https://awesomekling.github.io/Memory-safety-for-SerenityOS/
には
>Q: Why ARC (automatic reference counting) instead of a borrow checker?
>ARC allows the language to feel lightweight without constantly asking the user to make decisions about memory management.

Jakt作者の考えは、Rustの方こそメモリ管理に絶え間ない気配りが必要で、自動のフリして実際にはプログラマーの負担、という事

これも具体的な話がない
>ARCメインの言語は「いずれも」遅い

Rustは都合の良い例だけ持ち出して「境界チェックは消える」とか言いがち

**デフォルトの名無しさん** · 2022/09/16(金) 16:47:16.92

スマポの時点で自動じゃないわなｗ
循環参照はWeak使ってなんとかしてくれっていうね
あとライフタイムにも参照の排他にも
全部頑張って気をつけないといけないのは書き手

メモリはGCに押しつけてしまうのがスッキリなのかもね
そっちはそっちで工夫してねっていう分離ができてる
nimなんかはそこを交換可能にしてて清々しいよね

**デフォルトの名無しさん** · 2022/09/16(金) 17:31:52.57

メモリに気配りしたいからこそrustを使うのであってGCで良ければGC言語使えば良いよ

**デフォルトの名無しさん** · 2022/09/16(金) 17:39:38.21

>>819 == >>814 だろ

形勢が不利になって面倒くさくなった？

じゃなかったら「Zigの手動メモリ管理の面倒さ」-->「Rustは自動メモリ管理で簡単」
みたいな書き方を明示的に否定してくれ

そういうところがRustの胡散臭いところ

**デフォルトの名無しさん** · 2022/09/16(金) 17:50:54.65

プログラマーに負担と責任を押し付けるZigは安全を軽視している

**デフォルトの名無しさん** · 2022/09/16(金) 17:51:15.64

GC言語使いたいなら止めはしないけど
それならスクリプト言語使った方がマシだよ

**デフォルトの名無しさん** · 2022/09/16(金) 17:54:38.33

笑った >>819 == >>814 ==821==822 だろ何回線目？
Zigの話じゃなくて、「Rustは嘘ついてました」って謝罪しろよ

**デフォルトの名無しさん** · 2022/09/16(金) 18:01:54.76

ARC方式のSwiftはクソ遅い

**デフォルトの名無しさん** · 2022/09/16(金) 18:21:34.07

>>818
嫁や彼女が援交やってそうだな。

**デフォルトの名無しさん** · 2022/09/16(金) 18:26:14.43

プロレス終わった？

**デフォルトの名無しさん** · 2022/09/16(金) 18:28:16.66

GCはメモリ確保やコンパクションや解放をまとめてやりやすいからパフォーマンス出しやすい。
そのおかげでストップザワールドやGCスパイクも享受できる。
負荷を予測したい奴には向いてないかもな。
そういう意味ではGC言語はピーキーなんよ。
お前にはまだ早いかもしれん。

**デフォルトの名無しさん** · 2022/09/16(金) 18:32:35.16

>>824
swiftは問答無用でretain,releaseもつくからじゃんよ

**デフォルトの名無しさん** · 2022/09/16(金) 18:38:52.62

GCは～って言って思考停止してるとRustでも使っているepochとか知らなそう

**デフォルトの名無しさん** · 2022/09/16(金) 18:46:51.84

いずれGCがメモリレイアウトを動的に最適化したり必要に応じて確定的なメモリ解放を行うように動的にJITしたりするようになるから、究極的にはGCが勝利するだろうね

**デフォルトの名無しさん** · 2022/09/16(金) 18:48:15.45

Zigの良さがよくわからない
C言語より安全なのはわかるけどでもそれって結局Cでいいじゃんってなるよね
Rustみたいに静的メモリ安全は実現するのは端から諦めてC言語よりちょっと安全な言語を目指しているんだよね
本当にニッチって言葉が似合いすぎている
構文も無駄に複雑だし汚いし将来性ないと思う

**デフォルトの名無しさん** · 2022/09/16(金) 18:49:54.01

>>830
それ結構難しい話に聞こえるけど、具体的な進展があるの？

**デフォルトの名無しさん** · 2022/09/16(金) 18:52:48.51

>>831 ZigはBinary生成が優秀だから、依存dll/soとかクロスコンパイルとか。Rustでも使っているよ

**デフォルトの名無しさん** · 2022/09/16(金) 18:59:55.32

Zigは構文が好きじゃない
わかりにくいよね

**デフォルトの名無しさん** · 2022/09/16(金) 19:00:01.75

>>820
変なこと言ってる人と同一視するのは勘弁してくれ

**デフォルトの名無しさん** · 2022/09/16(金) 19:04:06.25

>>820
そういう決めつけで妄想してると統合失調症になるよ

**デフォルトの名無しさん** · 2022/09/16(金) 19:04:06.82

Zigは作者が会社辞めて専念してるから、華々しくブレイクしなくてもずっと続けてくコミットがすごい
「安全性」は流行っているからリップサービス。マインドは常に実行速度。キレイなBinary。低レイヤー。
構文はちょこちょこ変わるイメージ。ときどき触るだけだけと直ぐに昔のがコンパイル通らなくなる。

**デフォルトの名無しさん** · 2022/09/16(金) 19:13:49.58

Faster than Cが自慢なのはぶっ飛んでるように聞こえるけど、一時期あったVは嘘だったけど、Zigはときどき本当。
LuaJitでもHaskellでもハマる処理では「簡単な記述で」Cより速いときがある。やってみないとわからない。

**デフォルトの名無しさん** · 2022/09/16(金) 19:19:50.21

構文なんて飾りですよ。狭い特定の処理がたまたま「簡単な記述で」書けるかどうかだけ。今はまだ時々実験するくらいで十分。深入りは先の話。

**デフォルトの名無しさん** · 2022/09/16(金) 19:23:23.65

Zigの時代ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!

**デフォルトの名無しさん** · 2022/09/16(金) 19:24:40.95

>>830 これ嘘大袈裟かな？w

**デフォルトの名無しさん** · 2022/09/16(金) 19:25:42.72

まいいや

**デフォルトの名無しさん** · 2022/09/16(金) 19:35:28.83

>>830
それインクリメンタルコピーCGのことでは？

**デフォルトの名無しさん** · 2022/09/16(金) 19:36:49.01

今のところZig使うならCで良いかな
使う気にはなれないな

**デフォルトの名無しさん** · 2022/09/16(金) 19:54:10.89

ム板のゲハスレ

**デフォルトの名無しさん** · 2022/09/16(金) 20:01:08.19

すみませんZigはまだβ、Nimはver1.6という事で....

>>818
>nimなんかはそこを交換可能

NimのGC/ORC/ARCは興味深いですね
https://nim-lang.org/blog/2020/12/08/introducing-orc.html

もっと選べるようだけど、循環参照などデータ構造別に切り替えて混在出来るのかな？
https://nim-lang.github.io/Nim/mm.html

>>843 上記のリストに入ってますか？

**デフォルトの名無しさん** · 2022/09/16(金) 20:08:18.02

>>843 教えてください。検索すると30年位前の論文なんかも出てきて実現しているのかどうか、
それが>>830で言っているGCと一致しているのか、ちょっと理解が追いつきません....

**デフォルトの名無しさん** · 2022/09/16(金) 20:23:30.89

GCの研究が進んでよりよいものができるようになったとき
GC言語はそれをまんまと拝借できるから旨味あるよな

**デフォルトの名無しさん** · 2022/09/16(金) 20:34:49.53

>>848 そうなんです。
ただ >>843の「incremental copy garbage collector」が30年以上まえから未だに研究されているのは検索すればすぐにわかるのですが、
nimで選べるくらいの実用段階なのか、更には>>830で言っているものと一致しているのか、重要ですよね。
30年以上の研究なんて逆に絵に描いた餅に思えたりするので。

**デフォルトの名無しさん** · 2022/09/16(金) 20:51:30.89

GC活用するだけじゃなくて、スタックフレームからエスケープしにくくする仕組みがあると面白いと思うけどね。

Rustほどガチガチだとだるいから、エスケープをコントロールするスマポみたいなクラスを用意するとか。

**デフォルトの名無しさん** · 2022/09/16(金) 21:07:42.67

GC以外だと、JVMや. NetなんかのVMも結構に改善してるんじゃない？

**デフォルトの名無しさん** · 2022/09/16(金) 21:21:31.00

GCもVMもどんどん改善してくれたまへ
JavaでHotSpotだのJITだの言い出したころワクワク感あったな
プログラマはプラットフォームに対してでなくて
これからはGCやVMに対してプログラミングをするだけでよくて
さらにGCやVMは誰かのおかげで勝手に改善されていくらしいという

**デフォルトの名無しさん** · 2022/09/16(金) 21:27:14.70

http://www.kmonos.net/alang/d/garbage.html

ガベージコレクトされたプログラムの方が高速です。これは直感に反するかもしれませんが、その理由は：

明示的なメモリ管理の際によく使われる手法は、参照カウントです。代入があるたびにカウントを増やしたり減らしたリソースを挿入するのは、速度低下の原因になっています。スマートポインタクラスでラップしても、速度的な解決にはなりません。
(またいずれにせよ、循環参照を削除できない参照カウント方式は、一般的な解決策ではありません。)

オブジェクトによって獲得されたリソースの解放には、デストラクタが使用されます。多くのクラスでは、このリソースとは割り当てられたメモリのことです。
GCを使えば、ほとんどのデストラクタが空になり、完全に削除してしまえます。

メモリ管理のためのデストラクタは、オブジェクトがスタックに置かれたときに影響が顕著になります。
例外が発生したときに、全てのスタックフレームでデストラクタが呼び出され、メモリを解放するような仕組みが必要となるのです。もしデストラクタが関係しなければ、例外を処理する特別なスタックフレームを設定する必要がなくなり、コードは高速に実行されます。

メモリ管理に必要なコードは全てを合わせるとちょっとした量になります。大きなプログラムになるほど、キャッシュに入らない部分が増え、ページングが多く発生し、プログラムが遅くなります。

GCは、メモリが残り少なくなってきたときのみ実行されます。メモリに余裕があれば、プログラムは全速力で実行され、メモリ解放に一切時間を取られません。

モダンなGCは、過去の遅いものより遙かに発展しています。世代型のコピーGCには、昔のマーク＆スイープアルゴリズムの非効率さはありません。

モダンなGCはヒープの詰め直しを行います。これによってプログラムが活発に参照するページの数を減らし、キャッシュヒット率を高め、スワップ回数が減ります。

GCを使うプログラムは、メモリリークの積み重ねで次第にパフォーマンスが悪化、という事態に縁がありません。

**デフォルトの名無しさん** · 2022/09/16(金) 21:34:12.96

>>830
どちらもJVMで実現済みのことに思えるが…。

メモリレイアウトの最適化
→ 世代別GC(長寿命なオブジェクトは頻繁にGCしない領域に移動する)

確定的なメモリはJITで開放
→ エスケープ解析(短命でスタックに乗せても構わないオブジェクトはスタックに乗せる)

**デフォルトの名無しさん** · 2022/09/16(金) 21:36:23.95

deno=Rust
bun=zig

https://res.cloudinary.com/practicaldev/image/fetch/s--HAhtlbw8--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/oi6yfxenbfcuhlrkl6j7.png

**デフォルトの名無しさん** · 2022/09/16(金) 21:39:12.85

>>853
近現代の言語だと例外は飛び抜けて重い機能だよな。c++使うときも自分から例外を使うこと無いし。
例外みたいなエラーフローあると便利なことあるんかね？

**デフォルトの名無しさん** · 2022/09/16(金) 21:39:55.16

>>855
それも言語の良し悪しよりもbanがやるべきことをやってないだけだったり、nodeが本質的には不必要なことをやりすぎているだけっぽいと思うんだよな。

**デフォルトの名無しさん** · 2022/09/16(金) 21:44:51.39

>>854 等号の左右、ずいぶん曲解しましたね。

**デフォルトの名無しさん** · 2022/09/16(金) 21:45:22.11

GC言語、メモリを山のように積んでるマシンだと走りきるまでGC走らなかったりするしな。
mallocしてfreeしないアプリみたいなもんで、ケースによってはそりゃ速い。

**デフォルトの名無しさん** · 2022/09/16(金) 21:55:33.67

>>857
そうなんだね

**デフォルトの名無しさん** · 2022/09/16(金) 22:04:21.30

>>857
要約すると、RustはZigに比べて本質的には不必要なことをやりすぎている、という事でOK

**デフォルトの名無しさん** · 2022/09/16(金) 22:10:48.13

Rust「zero overhead abstraction」は嘘でした

**デフォルトの名無しさん** · 2022/09/16(金) 22:15:51.87

>>856
C++使ってないな。C#ユーザー

**デフォルトの名無しさん** · 2022/09/16(金) 22:19:05.45

>>853
この文章10年以上前からあるけど今でも成り立つのだろうか

確かにメモリ解放を遅延させることによって実行命令数がGCの方が少なくなる場合はあると思う
一方でいくつかのmalloc実装がやっているような、直近にfreeされた領域を優先的に再割り当てするようなことは、GCが走らない限り、つまり、メモリを使い切るまではできない
freeされた領域はキャッシュに載っていて高速にアクセスできる可能性が高いので、直近にfreeされた領域を使い回すことはキャッシュヒット率を高める効果がある
GC言語は命令数は少なかったとしても、メモリのアクセスレイテンシの影響をより多く受け、トータルでは遅かったりしないだろうか

この文章の元ネタのベンチマークがあるなら現在のマシンで比較してみたら面白そう

**デフォルトの名無しさん** · 2022/09/16(金) 22:26:31.57

>>861
アプリの実装の善し悪しの話と実装言語の善し悪しを意図的に混同させるのはよくないよ

**デフォルトの名無しさん** · 2022/09/16(金) 22:34:26.05

>>865 Chrome by C++の場合について聞かせて

**デフォルトの名無しさん** · 2022/09/16(金) 22:44:06.52

>>864
それソースある？
必ず再利用するにあたって領域を書き換えてんだから、直前にfreeしたかどうかに関わらず書き換え直後にキャッシュに乗るのは当たり前じゃないの？
チープな環境でスワップインを回避する効果はあるかもしれんが

**デフォルトの名無しさん** · 2022/09/16(金) 22:47:07.20

>>858
曲解してるかなとは我ながら思った。
けど、GCが勝つというほどインパクトある伸び代が挙げられた項目にこれ以上あると感じないんだよね。

**デフォルトの名無しさん** · 2022/09/16(金) 22:47:38.62

>>876 スワップインて。。>>864はまっとうな意見だと思うよ。

**デフォルトの名無しさん** · 2022/09/16(金) 22:54:48.64

>>868
>GCが勝つという
そんな場合もある、程度では。

GraalVMでNativeにした場合で
Native Java(+GC) vs Native other(no GC)は気になる

**デフォルトの名無しさん** · 2022/09/16(金) 23:06:36.63

escapeするかしないか、静的と動的でそんなに違うもんかね。
むしろエラー以外はescapeする・しないは静的で相当範囲カバー出来てそう。データはないけど。

**デフォルトの名無しさん** · 2022/09/16(金) 23:12:50.46

>>864
これはそう。ただ投機的実行(と昨今のその去勢)とかを考えると結構難しいかなとは。

**デフォルトの名無しさん** · 2022/09/16(金) 23:22:07.28

GCを止めたら速いという話は藁人形論法なのでやめませんか？

**デフォルトの名無しさん** · 2022/09/16(金) 23:25:00.60

どこが藁人形なの？

**デフォルトの名無しさん** · 2022/09/16(金) 23:26:02.22

>>872 vulnerability詳しくないけど、mitigationでfree->mallocがどの程度影響するのか気になるな。

**デフォルトの名無しさん** · 2022/09/16(金) 23:34:42.72

>>853
＞GCを使うプログラムは、メモリリークの積み重ねで次第にパフォーマンスが悪化、という事態に縁がありません。

嘘言うな

**デフォルトの名無しさん** · 2022/09/16(金) 23:42:23.80

GCは解放の実タイミングは調整するけど「メモリリーク」とは見なしてないのでは。

むしろ Rust「メモリリークはメモリ安全性保障の範囲外」の方なんとかして

**デフォルトの名無しさん** · 2022/09/16(金) 23:44:19.41

>>867
GCはそもそもfreeから再利用まで間が開くのでその間にキャッシュから外れる可能性が高くなるし、
再利用に当たって領域を書き換えるなら、キャッシュに載ってない場合書き換え処理に時間がかかるのでは
スワップインはよくわからない

**デフォルトの名無しさん** · 2022/09/16(金) 23:45:28.20

>>877
メモリリークを静的に検知するのはプログラムに対する制限が相当大きくなってしまうのでは

**デフォルトの名無しさん** · 2022/09/16(金) 23:53:17.42

>>879 動的にでも検知する仕組み/試みがあったりするのかな。テスト、プロファイル、そりゃあるかな。

**デフォルトの名無しさん** · 2022/09/17(土) 00:04:48.75

>>880
valgrindとかAddressSanitizerとかmallocをhookするやつとかいろいろあるよ

**デフォルトの名無しさん** · 2022/09/17(土) 00:05:17.29

GCはいわばメモリ管理の専門家に幅広い裁量を持たせて仕事させているわけで、
それに比べるとアプリケーションコード内でのメモリ管理はCenter of Excellence的な意味では原理的にどうしても不利よね
メモリ管理の専門家が十分な裁量を持って仕事できるのはせいぜいアロケータの実装くらいで、ほかは高水準のプログラミングモデルやプログラマの能力の制約を強く受けることになる