22/09/15 10:59:43.56 OR8C0I/3.net
>>769
これ実質的に自己責任論だから
人間はみんな自己だよねと言っても無駄で、自己はこの世に一人しかいないという考え方なのさ
810:デフォルトの名無しさん
22/09/15 11:07:06.60 P/wAPOM3.net
Rust を使用した Windows での開発の概要
URLﾘﾝｸ(docs.microsoft.com)
811:デフォルトの名無しさん
22/09/15 12:17:06.07 YIKrY0vS.net
なんでRust信者ってID変えんの？
自信ないからかな？
812:デフォルトの名無しさん
22/09/15 12:24:52.85 Yrdeu38e.net
>>765 >>769
『Rustの作法に慣れたコーダーなら』コンパイラにブレーキを踏まれて止まることも少なくて快適だろうけど、慣れていない初級者・初学者のストレスは半端無い。
絶壁の学習曲線はRustの重大な問題で、これを何とかしない限りはHaskellくらいの普及率が関の山かと。
813:デフォルトの名無しさん
22/09/15 12:49:54.52 6n/goZ6T.net
「教官、時速40キロで走っていると原付に追い抜かれて行きます。それに時間に遅れます!」
「奴は自己責任だ。お前は俺だけを見ろ」
「はい! あっ、事故っちゃいました、テヘ」
「ばっかも～ん。しょうがないやつだな」
Rust、愛され言語No.1
814:デフォルトの名無しさん
22/09/15 13:02:27.27 AewR1FC3.net
>>776
初学者が躓きがちなところって例えばどこなんだろう
学習曲線が急という話はあるが実際に初心者が苦しんでる箇所が知りたいなぁ
>>777
これって具体的に何のことを揶揄してるの？
安全性のために効率性が損なわれるという論はあるけどスレで出てきた事例が配列の境界チェックくらいでコンパイラ関係ないという
815:デフォルトの名無しさん
22/09/15 13:21:46.17 N+NQH7M1.net
>>778
実効速度の事は揶揄してなくて、前半は>>681 >アイデアを誰より早く形にして価値がある
のことだと思うけど、
後半は手取り足取りでもChrome>>726でいう25%側で事故る(25%じゃ済まなくなる)、とか？
または愛されRust教官と生徒の...
大した意味はないと思う。
816:デフォルトの名無しさん
22/09/15 14:34:36.53 7O/O6eid.net
まあ実際はrustで開発なんてほとんどしてないからな。
だから自信のない奴が無理矢理褒めてるんだよ。
817:デフォルトの名無しさん
22/09/15 14:42:23.71 AewR1FC3.net
>>780
褒めてる側に怪しい人がいるのはそうだけど貶してる側も具体的な話に乏しくて印象だけで語っている人がいるような
818:デフォルトの名無しさん
22/09/15 14:58:36.52 YdvnBlXp.net
Rustは荒れるので話題転換
Clojure Haskell Lisp辺りの過去に一世風靡？した言語が先端分野で地道
819:に使われ続けてるのは 単純に個別要因(研究者の好みとか)なのだろうか。 Lispくらいの歴史があるのならともかくClojure Haskellである必要性必然性が理解できない。 リストにあるNimも何を目指してるのか、何が得意なのか見えない。 Pythonからの乗り換えに最適、って出てくるのはNumpyも使ってないPythonコードの高速化例が主で、 この程度で「研究者の好み」に響くのか疑問
820:デフォルトの名無しさん
22/09/15 15:09:17.30 YdvnBlXp.net
率直に言うと、Nimには開発者、コミュニティの言語オタク感が、、(いい意味で)
821:デフォルトの名無しさん
22/09/15 15:26:45.00 5tgK0LqN.net
>>763
ソースコードのマネージャーw
妄想が過ぎるやろww
お前やっぱり複オジと同じ種類の人間やな
822:デフォルトの名無しさん
22/09/15 15:28:52.49 YnVRyWH8.net
>>782
エンジニアの単なる個人的な好みだよ
スタートアップの開発はだいたいエンジニア1人～せいぜい2,3人で始まり、作り方について外から誰も口出さないから、何でも好きなものを採用できる
とはいえあまり変なものは後からリプレースされることも多いが、あえて関数型使いたがるような奴は比較的優秀だから結果的に生き残りやすいんだろうね
823:デフォルトの名無しさん
22/09/15 17:40:49.72 DPUhxpSw.net
>>776
どの言語もそうだけど慣れの問題だけだよ
慣れるまでは躓きやすいけど
慣れてしまえばそこに何か支障があるわけではなく快適
もちろん手続き型言語しか使ったことがなかった人が関数型言語を始めれば 最初だけカルチャーショック的なものもあるかもしれない
Rustは従来の手続き型言語のバリエーションの範囲内であり難しい点はなにもない
最近は増えてる関数型プログラミングを積極的にサポートしているだけの普通の手続き型言語である
824:デフォルトの名無しさん
22/09/15 18:14:28.13 OR8C0I/3.net
ブレーキ云々は関数型ではなく静的型に責任がある
と理解するまでに10年単位の時間を消費してるのが現実
825:デフォルトの名無しさん
22/09/15 18:19:41.49 uryhzbE3.net
lispはプロトタイプから本番に移行するに向いている的な事をどこかで見かけたんだけど、何か理由あるのかな？
本番であれば、今時は静的型付けの方が実行前にミスを減らせて良さそうって思うんだけど。
826:デフォルトの名無しさん
22/09/15 18:30:04.54 AewR1FC3.net
lispで思い出される文章はこれ
URLﾘﾝｸ(practical-scheme.net)
827:デフォルトの名無しさん
22/09/15 18:42:43.79 /dOm+x1c.net
Concurrencyについては詳しくないんだけど
goはやっぱりつよいの？
erlangよりつよいの？
828:デフォルトの名無しさん
22/09/15 18:55:22.88 fhKzGp48.net
>>786
マニュアル教習車の運転を「慣れの問題」と言っているようなもんだな。
最初はエンストしまくっていても、慣れればいつかは運転できるようになるわな。それがいつだか知らんけど。
829:デフォルトの名無しさん
22/09/15 19:08:20.73 QksYVlPK.net
>>777
そういえば前スレでrustは原付（php）に速度で負けてたよね
830:デフォルトの名無しさん
22/09/15 19:48:17.43 /Qo8z/Hb.net
統一教会「Rustをお持ちしました」
831:デフォルトの名無しさん
22/09/15 20:20:12.75 +mjTxJT1.net
嫌いなものにはとりあえず統一教会と絡ませておけば批判したことにできる頭の具合が羨ましい
832:デフォルトの名無しさん
22/09/15 21:03:43.45 /Qo8z/Hb.net
統一教会「晋三を捧げよ」
833:デフォルトの名無しさん
22/09/15 21:29:46.27 /Qo8z/Hb.net
>>794
いやあ、それほどでも（照
834:デフォルトの名無しさん
22/09/15 21:32:22.04 z9CUv+9j.net
世界統一平和自民党から怒られるぞw
835:デフォルトの名無しさん
836:
マジか。
837:デフォルトの名無しさん
22/09/15 22:18:19.78 rqzHv7Xe.net
>>788
common lisp とかだとあとから型書いてパフォーマンス上がる処理系とかあった気がするし、プロトタイプから色々柔軟に改修しやすいとかあったのかもね。
838:デフォルトの名無しさん
22/09/15 23:09:10.28 KFRYW2wo.net
次スレはこれらの言語を入れてください
Zig
URLﾘﾝｸ(ziglang.org)
Jakt
URLﾘﾝｸ(github.com)
839:デフォルトの名無しさん
22/09/15 23:18:38.32 M8k2LDUe.net
バージョンが 1.0 に達していない言語は混乱するだけだから入れなくていいよ
必要なら専用スレを立てた方がいい
840:デフォルトの名無しさん
[ここ壊れてます] .net
genesisを入れろ
841:デフォルトの名無しさん
[ここ壊れてます] .net
ちゃんと>>1に「スレタイ以外の言語もok」と書かれているように
それ以外の言語の話もこのスレでは歓迎です
スレタイは文字数制限があるため全ての言語を列挙することはできません
もし話題の多い言語が出てくれば話題の少ない言語と交代することになるでしょう
登場して20年以上経つ古い言語はもちろん対象外です
842:デフォルトの名無しさん
22/09/16 06:52:08.13 fjE4y/uE.net
Rustを外せ（コッソリ
843:デフォルトの名無しさん
22/09/16 06:56:42.28 3KsrPmkI.net
ここが隔離スレだろ
844:デフォルトの名無しさん
22/09/16 07:49:14.15 9X7PH4Bp.net
Rustの話題はRustスレでいいだろ
845:デフォルトの名無しさん
22/09/16 07:52:17.18 ATWJ//93.net
>>796
彼女が企画もののAVに出てそう
846:デフォルトの名無しさん
22/09/16 08:18:42.51 g+vpwU6C.net
>>790
goは聞きかじりだけどもシングルスレッドのコードを気楽に拡張して同時実行にできることが売りに見える
erlangは最初から並列であることを求めてるから方向性が違う
どっちも強いは成り立つんじゃないかな
847:デフォルトの名無しさん
22/09/16 10:19:44.03 0Y0F2QEG.net
お待たせしました(awesomeレス 1of3 ※)
Clojure StackOverflow >愛され言語ランキング上位 2つあるawesome-clojureがどちらもマメに更新されてる
CircleCIとかいくつかの実用サービスに使われてるのがすごい 「本物のREPL」(未確認) LogSeq
Apple,CircleCI,Cisco,Cognitect,Nubank🏧,Walmart >使ってますが何か？ URLﾘﾝｸ(docs.google.com)
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の重大な問題 🆕
848:デフォルトの名無しさん
22/09/16 10:22:00.77 RyrM8365.net
お待たせしました(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 URLﾘﾝｸ(news.ycombinator.com) 🆕
Haskell アカデミック勢が根強い それ以外は衰退しました(未確認)
Tesla,Microsoft,Meta,GitHub,一流銀行🏧 >使ってますが何か？ URLﾘﾝｸ(serokell.io)
Tesla >We use Haskell to auto-generate C code that is compiled into vehicle🚗 firmware.
下っ端社員 >いい話だ。だが結局☪かよ
Julia 科学技術方面開拓中 StackOverflow >愛され言語ランキング上位
FORTRAN 科学技術方面で強い、しばしば1択
COBOL 金融機関方面では既存システムで根強い それ以外は衰退しました
849:デフォルトの名無しさん
22/09/16 10:24:50.31 bc2jlm7t.net
Lisp JavaScriptと変わらん ブランディングした先人たちのマーケティング能力が驚き
惑星探査機🛰とか特殊な用途、身近なところでルンバ🤖がLisp
Awesome Lisp Company URLﾘﾝｸ(github.com)
プロトタイプから本番に移行 柔軟に改修しやすい common lisp あとから型書いてパフォーマンスUp 🆕
思い出 >URLﾘﾝｸ(practical-scheme.net) >オジさん🧓は言語を変えない 🆕
C C言語がないぞ C言語がないぞ(大事なことだから2回) 🆕
php 原付 >静的型はブレーキ🛵 俺にブレーキはない 10年経って分かった <matz😚 🆕
欧米企業「最初のバージョンは常に捨てられる」 🆕
「アイデアは価値がない、アイデアを誰より早く形にして価値がある」 🆕
Jakt URLﾘﾝｸ(github.com) 🆕
Memory safety, Math safety, performance, transpiles to C++, Inline C++ 🆕
Zig URLﾘﾝｸ(ziglang.org)(ja/) en >英語勉強しろ 話はそれからだ 🆕
Erlang 方向性が違う どっちも強い >お気楽Goはやっぱりつよいの？ 🆕
php >原付🛵より遅いぞ URLﾘﾝｸ(benchmarksgame-team.pages.debian.net) 🆕
※ジョーク集です。「未確認」表示の有無に関わらず真偽を保証するものではありません。
850:デフォルトの名無しさん
22/09/16 10:25:11.62 FmJF7Gxj.net
病気の人かな
書き込むなよ
851:デフォルトの名無しさん
22/09/16 14:24:20
852:.93 ID:JbBUDOVI.net
853:デフォルトの名無しさん
22/09/16 15:16:00.68 5FcoWQIv.net
ARCメインの言語はいずれも遅いから興味ないな
とはいえZigの手動メモリ管理の面倒さと危険さは今の時代ニッチに終わるだろう
854:デフォルトの名無しさん
22/09/16 15:25:53.62 EVJZN8ya.net
あっちのスレでやりなよ
こっちは隔離スレ
855:デフォルトの名無しさん
22/09/16 15:55:51.13 lXNxdC5B.net
ﾜｯﾁｮｲスレのリンク見たら
Written on May 19, 2022 時点で >It’s two weeks old.
っていくらなんでもホヤホヤ過ぎでしょw
856:デフォルトの名無しさん
22/09/16 16:35:54.10 5ihvg/eP.net
URLﾘﾝｸ(awesomekling.github.io)
には
>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は都合の良い例だけ持ち出して「境界チェックは消える」とか言いがち
857:デフォルトの名無しさん
22/09/16 16:47:16.92 74dom6Tp.net
スマポの時点で自動じゃないわなｗ
循環参照はWeak使ってなんとかしてくれっていうね
あとライフタイムにも参照の排他にも
全部頑張って気をつけないといけないのは書き手
メモリはGCに押しつけてしまうのがスッキリなのかもね
そっちはそっちで工夫してねっていう分離ができてる
nimなんかはそこを交換可能にしてて清々しいよね
858:デフォルトの名無しさん
22/09/16 17:31:52.57 EVJZN8ya.net
メモリに気配りしたいからこそrustを使うのであってGCで良ければGC言語使えば良いよ
859:デフォルトの名無しさん
22/09/16 17:39:38.21 hXa4CTix.net
>>819 == >>814 だろ
形勢が不利になって面倒くさくなった？
じゃなかったら「Zigの手動メモリ管理の面倒さ」-->「Rustは自動メモリ管理で簡単」
みたいな書き方を明示的に否定してくれ
そういうところがRustの胡散臭いところ
860:デフォルトの名無しさん
22/09/16 17:50:54.65 5FcoWQIv.net
プログラマーに負担と責任を押し付けるZigは安全を軽視している
861:デフォルトの名無しさん
22/09/16 17:51:15.64 rsr6X2sj.net
GC言語使いたいなら止めはしないけど
それならスクリプト言語使った方がマシだよ
862:デフォルトの名無しさん
22/09/16 17:54:38.33 l9zi2+Dh.net
笑った >>819 == >>814 ==821==822 だろ 何回線目？
Zigの話じゃなくて、「Rustは嘘ついてました」って謝罪しろよ
863:デフォルトの名無しさん
22/09/16 18:01:54.76 5FcoWQIv.net
ARC方式のSwiftはクソ遅い
864:デフォルトの名無しさん
[ここ壊れてます] .net
>>818
嫁や彼女が援交やってそうだな。
865:デフォルトの名無しさん
[ここ壊れてます] .net
プロレス終わった？
866:デフォルトの名無しさん
22/09/16 18:28:16.66 fQY5NM7R.net
GCはメモリ確保やコンパクションや解放をまとめてやりやすいからパフォーマンス出しやすい。
そのおかげでストップザワールドやGCスパイクも享受できる。
負荷を予測したい奴には向いてないかもな。
そういう意味ではGC言語はピーキーなん
867:よ。 お前にはまだ早いかもしれん。
868:デフォルトの名無しさん
22/09/16 18:32:35.16 fQY5NM7R.net
>>824
swiftは問答無用でretain,releaseもつくからじゃんよ
869:デフォルトの名無しさん
22/09/16 18:38:52.62 9KGaiKu/.net
GCは～って言って思考停止してるとRustでも使っているepochとか知らなそう
870:デフォルトの名無しさん
22/09/16 18:46:51.84 RqiYn650.net
いずれGCがメモリレイアウトを動的に最適化したり必要に応じて確定的なメモリ解放を行うように動的にJITしたりするようになるから、究極的にはGCが勝利するだろうね
871:デフォルトの名無しさん
22/09/16 18:48:15.45 j69kQS4p.net
Zigの良さがよくわからない
C言語より安全なのはわかるけどでもそれって結局Cでいいじゃんってなるよね
Rustみたいに静的メモリ安全は実現するのは端から諦めてC言語よりちょっと安全な言語を目指しているんだよね
本当にニッチって言葉が似合いすぎている
構文も無駄に複雑だし汚いし将来性ないと思う
872:デフォルトの名無しさん
22/09/16 18:49:54.01 LN15iZX2.net
>>830
それ結構難しい話に聞こえるけど、具体的な進展があるの？
873:デフォルトの名無しさん
22/09/16 18:52:48.51 LN15iZX2.net
>>831 ZigはBinary生成が優秀だから、依存dll/soとかクロスコンパイルとか。Rustでも使っているよ
874:デフォルトの名無しさん
22/09/16 18:59:55.32 xvE1RXjk.net
Zigは構文が好きじゃない
わかりにくいよね
875:デフォルトの名無しさん
22/09/16 19:00:01.75 EVJZN8ya.net
>>820
変なこと言ってる人と同一視するのは勘弁してくれ
876:デフォルトの名無しさん
22/09/16 19:04:06.25 xvE1RXjk.net
>>820
そういう決めつけで妄想してると統合失調症になるよ
877:デフォルトの名無しさん
22/09/16 19:04:06.82 LN15iZX2.net
Zigは作者が会社辞めて専念してるから、華々しくブレイクしなくてもずっと続けてくコミットがすごい
「安全性」は流行っているからリップサービス。マインドは常に実行速度。キレイなBinary。低レイヤー。
構文はちょこちょこ変わるイメージ。ときどき触るだけだけと直ぐに昔のがコンパイル通らなくなる。
878:デフォルトの名無しさん
22/09/16 19:13:49.58 LN15iZX2.net
Faster than Cが自慢なのはぶっ飛んでるように聞こえるけど、一時期あったVは嘘だったけど、Zigはときどき本当。
LuaJitでもHaskellでもハマる処理では「簡単な記述で」Cより速いときがある。やってみないとわからない。
879:デフォルトの名無しさん
22/09/16 19:19:50.21 LN15iZX2.net
構文なんて飾りですよ。狭い特定の処理がたまたま「簡単な記述で」書けるかどうかだけ。今はまだ時々実験するくらいで十分。深入りは先の話。
880:デフォルトの名無しさん
22/09/16 19:23:23.65 HUefBg/J.net
Zigの時代ｷﾀ━━(ﾟ∀ﾟ)━━!!
881:デフォルトの名無しさん
22/09/16 19:24:40.95 LN15iZX2.net
>>830 これ嘘大袈裟かな？w
882:デフォルトの名無しさん
22/09/16 19:25:42.72 LN15iZX2.net
まいいや
883:デフォルトの名無しさん
22/09/16 19:35:28.83 xvE1RXjk.net
>>830
それインクリメンタルコピーCGのことでは？
884:デフォルトの名無しさん
22/09/16 19:36:49.01 xvE1RXjk.net
今のところZig使うならCで良いかな
使う気にはなれないな
885:デフォルトの名無しさん
22/09/16 19:54:10.89 eTFy07in.net
ム板のゲハスレ
886:デフォルトの名無しさん
22/09/16 20:01:08.19 0J+L4jjc.net
すみませんZigはまだβ、Nimはver1.6という事で....
>>818
>nimなんかはそこを交換可能
NimのGC/ORC/ARCは興味深いですね
URLﾘﾝｸ(nim-lang.org)
もっと選べるようだけど、循環参照などデータ構造別に切り替えて混在出来るのかな？
URLﾘﾝｸ(nim-lang.github.io)
>>843 上記のリストに入ってますか？
887:デフォルトの名無しさん
22/09/16 20:08:18.02 0J+L4jjc.net
>>843
888:教えてください。検索すると30年位前の論文なんかも出てきて実現しているのかどうか、 それが>>830で言っているGCと一致しているのか、ちょっと理解が追いつきません....
889:デフォルトの名無しさん
22/09/16 20:23:30.89 74dom6Tp.net
GCの研究が進んでよりよいものができるようになったとき
GC言語はそれをまんまと拝借できるから旨味あるよな
890:デフォルトの名無しさん
22/09/16 20:34:49.53 0J+L4jjc.net
>>848 そうなんです。
ただ >>843の「incremental copy garbage collector」が30年以上まえから未だに研究されているのは検索すればすぐにわかるのですが、
nimで選べるくらいの実用段階なのか、更には>>830で言っている ものと一致しているのか、 重要ですよね。
30年以上の研究なんて逆に絵に描いた餅に思えたりするので。
891:デフォルトの名無しさん
22/09/16 20:51:30.89 paysycNa.net
GC活用するだけじゃなくて、スタックフレームからエスケープしにくくする仕組みがあると面白いと思うけどね。
Rustほどガチガチだとだるいから、エスケープをコントロールするスマポみたいなクラスを用意するとか。
892:デフォルトの名無しさん
22/09/16 21:07:42.67 8k9s5Jiv.net
GC以外だと、JVMや. NetなんかのVMも結構に改善してるんじゃない？
893:デフォルトの名無しさん
22/09/16 21:21:31.00 74dom6Tp.net
GCもVMもどんどん改善してくれたまへ
JavaでHotSpotだのJITだの言い出したころワクワク感あったな
プログラマはプラットフォームに対してでなくて
これからはGCやVMに対してプログラミングをするだけでよくて
さらにGCやVMは誰かのおかげで勝手に改善されていくらしいという
894:デフォルトの名無しさん
22/09/16 21:27:14.70 z5XcLMe6.net
URLﾘﾝｸ(www.kmonos.net)
ガベージコレクトされたプログラムの方が高速です。 これは直感に反するかもしれませんが、その理由は：
明示的なメモリ管理の際によく使われる手法は、参照カウントです。 代入があるたびにカウントを増やしたり減らしたリソースを挿入するのは、 速度低下の原因になっています。スマートポインタクラスでラップしても、 速度的な解決にはなりません。
(またいずれにせよ、 循環参照を削除できない参照カウント方式は、 一般的な解決策ではありません。)
オブジェクトによって獲得されたリソースの解放には、 デストラクタが使用されます。多くのクラスでは、このリソースとは 割り当てられたメモリのことです。
GCを使えば、 ほとんどのデストラクタが空になり、完全に削除してしまえます。
メモリ管理のためのデストラクタは、 オブジェクトがスタックに置かれたときに影響が顕著になります。
例外が発生したときに、全てのスタックフレームでデストラクタが呼び出され、 メモリを解放するような仕組みが必要となるのです。 もしデストラクタが関係しなければ、例外を処理する特別なスタックフレームを 設定する必要がなくなり、コードは高速に実行されます。
メモリ管理に必要なコードは全てを合わせるとちょっとした量になります。 大きなプログラムになるほど、キャッシュに入らない部分が増え、 ページングが多く発生し、 プログラムが遅くなります。
GCは、メモリが残り少なくなってきたときのみ実行されます。 メモリに余裕があれば、プログラムは全速力で実行され、 メモリ解放に一切時間を取られません。
モダンなGCは、過去の遅いものより遙かに発展しています。 世代型のコピーGCには、 昔のマーク＆スイープアルゴリズムの非効率さはありません。
モダンなGCはヒープの詰め直しを行います。 これによってプログラムが活発に参照するページの数を減らし、 キャッシュヒ
895:ット率を高め、 スワップ回数が減ります。 GCを使うプログラムは、メモリリークの積み重ねで次第にパフォーマンスが悪化、 という事態に縁がありません。
896:デフォルトの名無しさん
22/09/16 21:34:12.96 W9x6+yw/.net
>>830
どちらもJVMで実現済みのことに思えるが…。
メモリレイアウトの最適化
→ 世代別GC(長寿命なオブジェクトは頻繁にGCしない領域に移動する)
確定的なメモリはJITで開放
→ エスケープ解析(短命でスタックに乗せても構わないオブジェクトはスタックに乗せる)
897:デフォルトの名無しさん
22/09/16 21:36:23.95 9X7PH4Bp.net
deno=Rust
bun=zig
URLﾘﾝｸ(res.cloudinary.com)
898:デフォルトの名無しさん
22/09/16 21:39:12.85 paysycNa.net
>>853
近現代の言語だと例外は飛び抜けて重い機能だよな。c++使うときも自分から例外を使うこと無いし。
例外みたいなエラーフローあると便利なことあるんかね？
899:デフォルトの名無しさん
22/09/16 21:39:55.16 W9x6+yw/.net
>>855
それも言語の良し悪しよりもbanがやるべきことをやってないだけだったり、nodeが本質的には不必要なことをやりすぎているだけっぽいと思うんだよな。
900:デフォルトの名無しさん
22/09/16 21:44:51.39 PbYmvI2Z.net
>>854 等号の左右、ずいぶん曲解しましたね。
901:デフォルトの名無しさん
22/09/16 21:45:22.11 lW11Z1GI.net
GC言語、メモリを山のように積んでるマシンだと走りきるまでGC走らなかったりするしな。
mallocしてfreeしないアプリみたいなもんで、ケースによってはそりゃ速い。
902:デフォルトの名無しさん
22/09/16 21:55:33.67 9X7PH4Bp.net
>>857
そうなんだね
903:デフォルトの名無しさん
22/09/16 22:04:21.30 N1Gu8JHK.net
>>857
要約すると、RustはZigに比べて本質的には不必要なことをやりすぎている、という事でOK
904:デフォルトの名無しさん
22/09/16 22:10:48.13 oJjxTP0V.net
Rust「zero overhead abstraction」は嘘でした
905:デフォルトの名無しさん
22/09/16 22:15:51.87 8FnpT4Fe.net
>>856
C++使ってないな。C#ユーザー
906:デフォルトの名無しさん
22/09/16 22:19:05.45 EVJZN8ya.net
>>853
この文章10年以上前からあるけど今でも成り立つのだろうか
確かにメモリ解放を遅延させることによって実行命令数がGCの方が少なくなる場合はあると思う
一方でいくつかのmalloc実装がやっているような、直近にfreeされた領域を優先的に再割り当てするようなことは、GCが走らない限り、つまり、メモリを使い切るまではできない
freeされた領域はキャッシュに載っていて高速にアクセスできる可能性が高いので、直近にfreeされた領域を使い回すことはキャッシュヒット率を高める効果がある
GC言語は命令数は少なかったとしても、メモリのアクセスレイテンシの影響をより多く受け、トータルでは遅かったりしないだろうか
この文章の元ネタのベンチマークがあるなら現在のマシンで比較してみたら面白そう
907:デフォルトの名無しさん
22/09/16 22:26:31.57 EVJZN8ya.net
>>861
アプリの実装の善し悪しの話と実装言語の善し悪しを意図的に混同させるのはよくないよ
908:デフォルトの名無しさん
[ここ壊れてます] .net
>>865 Chrome by C++の場合について聞かせて
909:デフォルトの名無しさん
[ここ壊れてます] .net
>>864
それソースある？
必ず再利用するにあたって領域を書き換えてんだから、直前にfreeしたかどうかに関わらず書き換え直後にキャッシュに乗るのは当たり前じゃないの？
チープな環境でス�
910:純bプインを回避する効果はあるかもしれんが
911:デフォルトの名無しさん
22/09/16 22:47:07.20 W9x6+yw/.net
>>858
曲解してるかなとは我ながら思った。
けど、GCが勝つというほどインパクトある伸び代が挙げられた項目にこれ以上あると感じないんだよね。
912:デフォルトの名無しさん
22/09/16 22:47:38.62 aq1cgc5a.net
>>876 スワップインて。。>>864はまっとうな意見だと思うよ。
913:デフォルトの名無しさん
22/09/16 22:54:48.64 aq1cgc5a.net
>>868
>GCが勝つという
そんな場合もある、程度では。
GraalVMでNativeにした場合で
Native Java(+GC) vs Native other(no GC)は気になる
914:デフォルトの名無しさん
22/09/16 23:06:36.63 yQqW5GbJ.net
escapeするかしないか、静的と動的でそんなに違うもんかね。
むしろエラー以外はescapeする・しないは静的で相当範囲カバー出来てそう。データはないけど。
915:デフォルトの名無しさん
22/09/16 23:12:50.46 lW11Z1GI.net
>>864
これはそう。ただ投機的実行(と昨今のその去勢)とかを考えると結構難しいかなとは。
916:デフォルトの名無しさん
22/09/16 23:22:07.28 rsr6X2sj.net
GCを止めたら速いという話は藁人形論法なのでやめませんか？
917:デフォルトの名無しさん
22/09/16 23:25:00.60 lW11Z1GI.net
どこが藁人形なの？
918:デフォルトの名無しさん
22/09/16 23:26:02.22 3cBZTpx6.net
>>872 vulnerability詳しくないけど、mitigationでfree->mallocがどの程度影響するのか気になるな。
919:デフォルトの名無しさん
22/09/16 23:34:42.72 ATWJ//93.net
>>853
＞GCを使うプログラムは、メモリリークの積み重ねで次第にパフォーマンスが悪化、 という事態に縁がありません。
嘘言うな
920:デフォルトの名無しさん
22/09/16 23:42:23.80 n2V9aTfB.net
GCは解放の実タイミングは調整するけど「メモリリーク」とは見なしてないのでは。
むしろ Rust「メモリリークはメモリ安全性保障の範囲外」 の方なんとかして
921:デフォルトの名無しさん
22/09/16 23:44:19.41 EVJZN8ya.net
>>867
GCはそもそもfreeから再利用まで間が開くのでその間にキャッシュから外れる可能性が高くなるし、
再利用に当たって領域を書き換えるなら、キャッシュに載ってない場合書き換え処理に時間がかかるのでは
スワップインはよくわからない
922:デフォルトの名無しさん
22/09/16 23:45:28.20 EVJZN8ya.net
>>877
メモリリークを静的に検知するのはプログラムに対する制限が相当大きくなってしまうのでは
923:デフォルトの名無しさん
22/09/16 23:53:17.42 MTo4LOAu.net
>>879 動的にでも検知する仕組み/試みがあったりするのかな。テスト、プロファイル、そりゃあるかな。
924:デフォルトの名無しさん
22/09/17 00:04:48.75 Qv9rB708.net
>>880
valgrindとかAddressSanitizerとかmallocをhookするやつとかいろいろあるよ
925:デフォルトの名無しさん
22/09/17 00:05:17.29 guSBFHBz.net
GCはいわばメモリ管理の専門家に幅広い裁量を持たせて仕事させているわけで、
それに比べるとアプリケーションコード内でのメモリ管理はCenter of Excellence的な意味では原理的にどうしても不利よね
メモリ管理の専門家が十分な裁量を持って仕事できるのはせいぜいアロケータの実装くらいで、ほかは高水準のプログラミングモデルやプログラマの能力の制約を強く受けることになる
926:デフォルトの名無しさん
22/09/17 00:13:57.81 WaM/gYIx.net
Javaは実行時最適化によりRustの3倍速い。
927:デフォルトの名無しさん
22/09/17 00:21:14.46 Qv9rB708.net
>>883
(場合もある)
928:デフォルトの名無しさん
22/09/17 00:44:08.92 wgXFenVD.net
スパイクの出ないGC出たら即乗り換える予定
929:デフォルトの名無しさん
22/09/17 01:02:29.41 HP4MaZ5C.net
それ以来30年間GC技術が進んだ結果の現状が既出のこれ
>>200
>> URLﾘﾝｸ(pbs.twimg.com)
全く対等に同条件で多くの人々が同じ問題に対して様々な言語で
930:記述した結果の各実行時間 速く実行できた言語はRustとCとC++の3つでいずれもGCなし GCする言語は軒並み遅い 一部をGC対象とならないよう回避の努力をしているGoがGC言語の中で最も速い そうでない普通のGC言語は遅すぎる
931:デフォルトの名無しさん
22/09/17 01:35:11.26 Qv9rB708.net
>>886
これってGC性能が支配的になる問題なの？
932:デフォルトの名無しさん
22/09/17 01:41:35.46 wgXFenVD.net
pythonさん
933:デフォルトの名無しさん
22/09/17 01:47:29.96 5sn184WB.net
>>887
(1) GCが発生している場合
→ GC性能が改善された現在でもGC言語は遅い
(2) GCが発生していない場合
→ GC性能と関係なくGCが起きない段階でもGC言語は遅い
どちらのケースであってもGC言語はダメな存在になってしまいますね
934:デフォルトの名無しさん
[ここ壊れてます] .net
あれ、D言語はかなり早いイメージだったけど、Goに負けることもあるのか
935:デフォルトの名無しさん
[ここ壊れてます] .net
>>884
無いよ（笑
936:デフォルトの名無しさん
[ここ壊れてます] .net
LDCじゃなくてGDC使ってんのかな
937:デフォルトの名無しさん
[ここ壊れてます] .net
Goは速いよ。
アンチGCはGC言語じゃなければ速い、と思い込みすぎでは？
ミッション車みたいなもんで、自分の設計力の無さがパフォーマンス劣化に直結するというか、いわゆるベンチのスペックは素直には出ないよ。
Rustアンチじゃないけど、これはRustの目的でもない(あくまで安全が目的)
GC言語みたいにだれでも80点が取れます、エンストしませんよ、みたいなもんじゃないんよ。
コンパイラが叱ってくれるからハイパフォーマンスとか、書いてて言ってんのかほんとに謎。
938:デフォルトの名無しさん
[ここ壊れてます] .net
ゲハでやれ
939:デフォルトの名無しさん
[ここ壊れてます] .net
>>886
そいつの読み方は「C＋＋とPyPy3圧倒的じゃないか」ですよ。
新参者から熟練者まで数と質すべてが圧倒的。
C++は熟練すると、黒魔術を含め、やりたいことが全てできる言語なので、突き詰めていく性質の企業におすすめ。
逆に、手数で勝負の乱打スタイル企業には、PythonやRoRがお勧め。
940:デフォルトの名無しさん
[ここ壊れてます] .net
>>893
Javaも速いですよ。
Rustの3倍は冗談だけど。
欠点はメモリーを使いすぎること。
一般的なパソコンはメモリーが少し足りない。
だから、Javaは遅いと思われてる。
ミスマッチです。
941:デフォルトの名無しさん
[ここ壊れてます] .net
ハードウェアを売りたい言語だから、ハードウェアに対する要求が少し厳しかったですね。
942:デフォルトの名無しさん
22/09/17 02:25:11.61 YHpfxvp6.net
>>886
やはりGCの言語はいずれも遅いな
GCのせいで遅くなるのではなく
ヒープでメモリ確保するからGCの言語は遅くなる
943:デフォルトの名無しさん
22/09/17 03:31:52.64 5J0Fty65.net
>>896
Java速いよね。あんまり適切なXmx知られてないだけだと思う。
>>898
少なくとも知ってる範囲だとGoもc#も取れるときはスタックを確保するぞ。
944:デフォルトの名無しさん
22/09/17 03:42:09.24 o0T2dyfd.net
>>899
Javaは遅いです
どのベンチマークでもC/C++/Rustの2倍～数倍はJavaが遅いです
>>886の例でもJavaは数倍遅くなっています
945:デフォルトの名無しさん
22/09/17 03:53:04.00 5J0Fty65.net
>>900
abc 182-eはakariって問題なんだけど、読んだ？
Javaで雑に書くとパフォーマンスでない類の問題だよ。
このグラフは言語オタ勢には有名かと思ってたけど、ベンチマークのグラフではなくて、あくまで競技者が書いた言語毎の統計のグラフなので、ポンコツが多ければそれが表現される。
言語人口が多いものの箱ひげが偉いことになってるでしょ。
946:デフォルトの名無しさん
22/09/17 04:54:39.17 1eeK5YMC.net
>>901
なるほど
しかしJavaで書いて最も速くできた人でも遅くて
Rustで書いた平均的な人たちにすら負けているな>>886
どんなに優
947:れた人であってもJavaを使った時点で遅いと確定してしまうのは辛いな
948:デフォルトの名無しさん
22/09/17 07:28:28.63 8assD4qG.net
>>877
これ訳わからんよね。
そこまでして「GC不要でメモリ安全」を売りにしたかったのか、と思うわ。
c++とかだとメモリリークも普通にバグ扱いされるのに、それを「メモリ安全」と言い切るのは詐欺臭い。
949:デフォルトの名無しさん
22/09/17 07:39:14.89 8assD4qG.net
>>902
そもそもRust使える人間は他の言語に詳しい人間しか居ないだろ。
他の言語に詳しく無い人間がRustの絶壁の学習曲線をクリアできるとは思えん。
「Rustしか使えません」なんて人間は存在するのかね？
950:デフォルトの名無しさん
22/09/17 07:46:13.48 TM5e0HO7.net
>>903
それは常識
一般的に循環参照の安全な解放を静的に記述したり静的にチェックすることは不可能
デッドロックも同じで静的に発生をチェックして防止することは不可能
だからコンパイラ(＝静的にチェックする存在)がそれらを防ぐことは対象外となる
951:デフォルトの名無しさん
22/09/17 07:50:22.53 XDvVGFlj.net
>>904
バカは遅い言語や危険な言語を使い続ければよい
時代の要請は高速で安全でプログラミング効率の良い言語でありそれはRust
使えないバカがついていけずに切り捨てられていくことは業界にとっても朗報だ
952:デフォルトの名無しさん
22/09/17 08:47:42.31 +hLuAY/P.net
早い言語は適当に書いても2秒の時間制限に間に合うけど
遅い言語は問題の想定解法じゃないと通らないから結果的に早い言語は上髭多くなるだけ
953:デフォルトの名無しさん
22/09/17 09:18:54.40 vRd8nzJr.net
>>902
execution timeの単位はミリ秒だぞ
ベンチヲタは気にするが1000000回ループして1秒か2秒しか差がつかないのに現実的に問題になることってないぞw
現実のループは多くてもせいぜい1000回程度だろ
954:デフォルトの名無しさん
22/09/17 09:57:15.90 BhE3E6/v.net
>>908
あんたには遅くてダメな言語で十分なのだから他を気にせず不満を持たずそのままでいいじゃないか
あんたには無縁だが世の中には速くて安全で保守性も良い言語が求められているだけの話だ
955:デフォルトの名無しさん
22/09/17 10:21:27.92 ktSmkMDB.net
Rustの他の言語と比べた速度向上って、俺にじゃなく世のほとんどのプロジェクトにとって五十歩百歩の微々たるものなんですわw
956:デフォルトの名無しさん
22/09/17 10:29:26.87 KEhwIc0k.net
前に、rustでtsc実装した人、さらにgoで作り直すって、理由がrustには向いてないからって。翻訳記事だからニュアンス違うのかもしれないけれど。
957:デフォルトの名無しさん
22/09/17 10:29:40.60 8assD4qG.net
>>905
プログラマサイドにそんな「常識」は無い。プログラマ視点なら「メモリリークはバグ。メモリを圧迫してトラブルになる危険がある」の方が常識。Rust関係者はそういうことを説明の奥の方に隠して「メモリ安全」とか誇大広告するから詐欺だと指摘しているわけで。
常識とかけ離れた俺俺定義を使うならちゃんと注意書きしろよ。
「メモリ安全*」
*メモリリークを除きます。
みたいに。
958:デフォルトの名無しさん
22/09/17 10:35:04.81 xfq0iQEs.net
Amazonの>>9の記事にもあるけど
Rustへ書き換えるだけだけでリソースコストや電気代それに伴うCo2排出量などが少なくとも50%は削減できる
さらにセキュリティの要請から安全性も求められている
土方でないまもともなプログラマーならばJavaでもRustでも他の言語でもプログラミングに支障なく書ける
それらの状況から選ぶべき言語がRust一択になっているだけでしょう
959:デフォルトの名無しさん
22/09/17 10:39:04.61 ktSmkMDB.net
960:https://stackoverflow.com/questions/55553048/is-it-possible-to-cause-a-memory-leak-in-rust > Is it possible to cause a memory leak in Rust? > You can also leak memory if you create a cycle of shared references: > You can also use Box::leak to create a static reference, or Box::into_raw in an FFI situation. > You might've forgotten about Box::leak and Box::into_raw which are pretty common in ffi situations for passing around states. https://doc.rust-lang.org/book/ch15-06-reference-cycles.html#reference-cycles-can-leak-memory > Reference Cycles Can Leak Memory
961:デフォルトの名無しさん
22/09/17 10:46:39.42 vRd8nzJr.net
RustでなくVBAを使うことでエネルギー削減になることもあるな
962:デフォルトの名無しさん
22/09/17 10:55:22.36 8assD4qG.net
>>913
Rustを学習した人間の感想の多くが「Rustは難解」と言っているのに、「まともなプログラマなら支障なく書ける」とする根拠は？
根拠が個人の感想なら、「まともなドライバーならマニュアル車を支障なく運転できる」と言うくらい傲慢だと思うがね。
963:デフォルトの名無しさん
22/09/17 10:55:41.70 gI44iNXP.net
>>912
それはちょっと知識不足じゃないかしら
もし循環参照を作っちゃった場合はそれを安全に解放する局所的な方法は理論的に存在しないんですよ
GCでも局所的に解決できる参照カウント方式では循環参照を解放できないため
GCの中でも全体のマークスイープ方式や全体の使用中分コピー方式でようやく解放されます
そららは非常にコストが重いだけでなく発動までに時差もあります
したがってプログラミング言語界ではそんなコストがかかるものに依存するのではなく
最初から循環参照を作らない方向で進んでいます
そのため最近は多くの言語で弱参照がサポートされており循環参照の発生を防ぐことができます
今回の話のJavaでももちろん弱参照が用意されていて最初から循環参照を作らないようにプログラミングします
そのほうが有利だからです
964:デフォルトの名無しさん
22/09/17 11:04:35.77 ktSmkMDB.net
>>917
C#では参照はツリーで管理されるから循環参照も問題なく一瞬で開放される
965:デフォルトの名無しさん
22/09/17 11:12:08.51 /Lpl+zOG.net
>>917
Wikipediaですら「メモリ安全性」の解説でメモリリークをメモリエラーとしているのに、実装側の都合で一般に使われている用語の意味をひん曲げて「常識」とな？
そういうのが詐欺だと指摘しているだけだけどなぁ。
今度からちゃんと
「メモリ安全*」
*メモリリークを除きます。
と注釈付けろよ。
966:デフォルトの名無しさん
[ここ壊れてます] .net
>>918
それはC#でもJavaでもRustでも他の言語でも全て同じ方法です
どの言語も弱参照を併用して参照はツリー状のみにすることで循環参照の発生を防ぎます
もちろんそこには弱参照による弱い循環参照がありますが通常の参照はツリー状なので
おっしゃる通りに一瞬で解放することが可能です
967:デフォルトの名無しさん
[ここ壊れてます] .net
>>919
wikipediaのメモリ安全性のメモリリークで挙げられてる項目は循環参照によるリークは含まれてないっぽいが
URLﾘﾝｸ(ja.m.wikipedia.org)
968:デフォルトの名無しさん
[ここ壊れてます] .net
ところで所有権は複製されるってことでいいの？
969:デフォルトの名無しさん
[ここ壊れてます] .net
>>921
リンク先にある「メモリリーク」の項ぐらい読めよ。
970:デフォルトの名無しさん
[ここ壊れてます] .net
今時循環参照くらいでメモリリークするような言語でよく安全を名乗れたもんだ
退化してるやん
971:デフォルトの名無しさん
22/09/17 11:39:26.07 /MEkW9dR.net
昔は保守的GCというGCに人気があった
本当はゴミなのにゴミで
972:はないと判断することはバグではなく安全、という注釈つきのGCだった この注釈は嘘だったという見方の方が今は優勢
973:デフォルトの名無しさん
22/09/17 11:42:22.70 yVMylSLT.net
予想される次の手：
・循環参照の矮小化
循環参照なんてめったに起こらないし
普通に書いてたら発生しようがない
・問題の転嫁
循環参照なんて書くほうが悪い
循環参照によるメモリリークなんかを問題視するほうが悪い
・飛躍した結論
とにかくRustは素晴らしい
974:デフォルトの名無しさん
22/09/17 11:43:45.86 5J0Fty65.net
>>902
「この設問は」ね。だから競プロは複数言語できると面白い。
975:デフォルトの名無しさん
22/09/17 11:45:32.10 bMZyj00L.net
今は強い循環参照を作ってしまったら負けの世界
Pythonですら強い循環参照を避けるために弱参照が用意されていて回避できる
もちろんC#やJavaにKotlinやSwiftにも弱参照が当然あって回避できる
Rustなどのように強い循環参照が自然には発生しない言語仕様だと更に良い
976:デフォルトの名無しさん
22/09/17 11:46:24.15 w5Ud45eS.net
メモリ安全とは何なのがまとまってるページとかは作れないんだろうか
977:デフォルトの名無しさん
22/09/17 11:48:55.60 5J0Fty65.net
>>925
Bohemとかもそうだっけ？
循環参照に関しては、確かにメモリリークだけど、危険ではないんでは？
Dangling pointerにならんかったら良いんじゃ無いかなあ。
循環参照で放置されているものの解放に時間がかかっても、別に問題ないと思うんだけどな。メモリに極端な制約がある環境下でなければ。
最初から循環参照を作らないというのは一つなんだけど、そういうわけにもいかんのよ。
最近書いたけど、グラフなオブジェクトなんかは循環参照するじゃん。
978:デフォルトの名無しさん
22/09/17 11:49:36.37 5J0Fty65.net
>>929
Rustの話ならこれかな？
URLﾘﾝｸ(doc.rust-jp.rs)
979:デフォルトの名無しさん
22/09/17 11:57:30.35 w5Ud45eS.net
ようやくわかってきたよ
C 言語 に大量にある 未定義な挙動が ないことをsafeって言ってんのか
ならメモリリークっていう現象事態はたしかにsafeだ
980:デフォルトの名無しさん
22/09/17 12:01:39.81 Qv9rB708.net
>>923
単にメモリリークと言ったら含まれるけど、
メモリ安全性に関わるメモリリークの文脈では循環参照は言及されてなさそうなんだよね
メモリ安全性という言葉の定義だけの問題で、実用上問題になるという点ではよろしくないとは思うけど
981:デフォルトの名無しさん
22/09/17 12:02:36.48 rp+oVngt.net
循環参照はコールバック等で普通に発生する
トレーシングGCでは全く何の問題にもならないから弱参照なんか使わんよ
982:デフォルトの名無しさん
22/09/17 12:05:32.37 w5Ud45eS.net
URLﾘﾝｸ(doc.rust-jp.rs)
循環参照は、メモリをリークすることもある
ここか
なるほど
983:デフォルトの名無しさん
22/09/17 12:06:42.34 ktSmkMDB.net
>>928
強い弱いの意味がわかってなくて草
984:デフォルトの名無しさん
22/09/17 12:07:05.26 8assD4qG.net
>>931
今まである「メモリ安全性」の常識を無視して『メモリ安全性』という言葉を使わなきゃいいんだけどねぇ。
「プログラムの安全性にこだわった」くらいの宣伝ならまだわかる。
Rustはわざわざ「メモリ安全性」という言葉を使って宣伝しているんだからダメだろ。
985:デフォルトの名無しさん
22/09/17 12:24:51.56 J+gZaL34.net
確定的なタイミングでトレーシングGCしてくれるようなスマートポインタって実現不可能なの？
986:デフォルトの名無しさん
22/09/17 12:27:39.54 bwIIEGYu.net
勘違いしてる人がいるようなので正しい知識をまとめておきます
C++やRustのような非GC言語やリファレンスカウント方式のGC言語では(強い)循環参照の解放は原理的に不可能です
これらの言語ではデッドロック等と同様に(強い)循環参照は発生させてはいけない禁忌として扱われ発生自体を避けます
対処方法としては弱い参照を用いた弱い循環参照を用いるのが主流ですが
プログラムが自分で管理する範囲内で循環参照を作ってまとめて解放したり範囲内GCなどを用いる方式もあります
マーク＆スイープ方式やコピー方式のGC言語ならば
987:(強い)循環参照も解放することができます ただしそれらの方式は全体空間を全てマークしたり辿ったりコピーしたりとコストが重いことの裏返しでもあります さらにGCが起こるまで無駄にメモリを専有してしまう問題もあります そのためこれらの方式のGC言語でも弱参照が用意されて(強い)循環参照を作らないようにすることが一般化しつつあります
988:デフォルトの名無しさん
22/09/17 12:35:09.02 w5Ud45eS.net
>>939
ちなみに誰が勘違いしてんの？
989:デフォルトの名無しさん
22/09/17 12:37:10.60 8assD4qG.net
>>940
>>939
990:デフォルトの名無しさん
22/09/17 12:39:43.66 vRd8nzJr.net
>>939
ちょっと本垢でQiitaにでも書いてくれマサカリ投げに行くから
991:デフォルトの名無しさん
22/09/17 13:12:35.27 5J0Fty65.net
>>937
Rustのメモリ安全性、というのを先に定義しとるからなぁ。
そこはまぁ定義次第なのはその通りだと思う。
992:デフォルトの名無しさん
22/09/17 13:18:40.25 Ct2ljdlf.net
>>938
無理だよ
だから各言語は現実的な対応をとってる
例えばC++のshared_ptrでも循環参照を起こしたらメモリ解放できない
回避策は強い循環参照を作らないようにweak_ptrを使う
Rustでは意図的に頑張らない限り循環参照が勝手に作られることはないけど
同様に参照をWeakにできるからメモリ解放可能な弱参照を用いた循環参照にして扱う
これはARC方式のSwiftでも同様で循環参照を起こしたらメモリ解放できない
Swiftでもweak宣言で弱参照にできるので解放できない循環参照を避けられる
いずれの言語もほぼ同じ仕組み
993:デフォルトの名無しさん
22/09/17 13:55:15.51 Dua3tl/G.net
>>944 >Rustでは意図的に頑張らない限り循環参照が勝手に作られることはない
よくわからないので聞くけど、
Rustでは意図的に頑張れば、Weakにせずに循環参照データ構造を定義してzeroじゃない実データ構築をするコードがコンパイル通るの？
994:デフォルトの名無しさん
22/09/17 13:59:18.77 8assD4qG.net
>>943
ならトップページに「Rustにおけるメモリ安全性」として「*メモリリークは除く」くらいはやらないと優良誤認だろ。
995:デフォルトの名無しさん
22/09/17 14:14:04.83 Qv9rB708.net
>>945
URLﾘﾝｸ(doc.rust-jp.rs)
996:デフォルトの名無しさん
22/09/17 14:16:59.16 Dua3tl/G.net
>>947 ありがとう
997:デフォルトの名無しさん
22/09/17 14:26:47.74 Dua3tl/G.net
>>945
URLﾘﾝｸ(play.rust-lang.org)
>最後のprintln!のコメントを外してプログラムを実行したら、aがbを指して、bがaを指してと、 スタックがオーバーフローするまでコンパイラはこの循環を出力しようとするでしょう。
確かに
thread 'main' has overflowed its stack
fatal runtime error: stack overflow
timeout: the monitored command dumped core
998:デフォルトの名無しさん
22/09/17 14:30:22.04 Qv9rB708.net
>>937
循環参照によるリークを含むようにメモリ安全性を定義してる文献ってある？
Wikipediaの定義ではメモリリークという分類はあるけど、
"メモリ使用量が追跡されていない又は誤って追跡されている場合"
と説明されていて、前者は当てはまらないし、後者はダングリングポインタなどを意図しているようで、循環参照は含まないように読める
SwiftやChromeやAOSPやDのメモリ安全性に関するドキュメントでもメモリリークについては触れられていないようだった
999:デフォルトの名無しさん
22/09/17 14:33:34.46 Dua3tl/G.net
>>949
[BUILD]にしてみたが「循環しるよ」的なwarningはないのね
1000:デフォルトの名無しさん
22/09/17 14:37:56.61 Dua3tl/G.net
>>951
>>944 >Rustでは意図的に頑張らない限り循環参照が勝手に作られることはない
warningがないし、当該データの使い方次第で実行時エラーにもならないので
意図しなくても、「偶発的に」循環参照が作られることはありそうだ。
1001:デフォルトの名無しさん
22/09/17 14:42:00.12 Dua3tl/G.net
潜伏した循環参照が後々深刻な事態になるかどうかは別の話だが
Rustだからと言って、コンパイル通ったからと言って、油断は禁物で
1002:デフォルトの名無しさん
22/09/17 14:43:28.60 Dua3tl/G.net
「常識」でしょw
1003:デフォルトの名無しさん
22/09/17 14:44:11.19 EEEbWrXO.net
>>937
> 今まである「メモリ安全性」の常識
お前の脳内の話じゃないなら具体的にどういう事なのか示してみそ
1004:デフォルトの名無しさん
22/09/17 15:27:41.65 lGXhfZzC.net
すげーくだらないことで盛り上がってんなw
さすが次世代w言語wwスレwww
1005:デフォルトの名無しさん
22/09/17 15:28:08.55 5J0Fty65.net
メモリリークだけでは安全性には差し障らんでしょ。一般的に。
スタック、ヒープが枯渇することはメモリ安全性に差し障るけど。
リークしてるけど走りきった、とか、GCがまとめて解放した、はセーフだと思うよ。
1006:デフォルトの名無しさん
22/09/17 15:58:19.63 8assD4qG.net
>>950
そんなことよりもまず
「メモリ安全性は(プログラムによる)メモリエラーを許容するのか、しないのか」
はどちらだと思うのか考えてもらいたいね。Rustは「メモリエラーが発生するけどRustはメモリ安全」て言っている。
>>955も同じな。お前もRustみたいに断言するのかね。
まぁ、「c++よりもメモリ安全」というならまだ正確だが、それならそうと正直に言うべきだと思うがね。俺俺メモリ安全をwebページの奥の方に置かないで。
1007:デフォルトの名無しさん
22/09/17 16:03:03.55 37/3YRxM.net
>>957
いやメモリリークはDoS攻撃に対する脆弱性になりうるから安全性に差し障るよ
1008:デフォルトの名無しさん
22/09/17 16:11:02.02 Qv9rB708.net
>>958
「メモリ安全性」という用語の定義の話に変な造語持ち込んで話題そらすのやめてよ
Rustによるメモリ安全性の定義が俺俺というなら、ちゃんとした定義を示して欲しいな
「常識だから分かるでしょ？」というのは自分の思いの表明にしかならないよ
1009:デフォルトの名無しさん
22/09/17 16:15:15.87 EEEbWrXO.net
>>958
だからお前の思う「メモリー安全性」の定義を示せよ
まあ示せないからぐだぐだはぐらかすしか無いんだろうけどw
1010:デフォルトの名無しさん
22/09/17 16:22:09.35 8assD4qG.net
>>957
だとするとRustで常駐系のプログラムの開発をするのは安全では無いですな。
常駐系プログラムがメモリを食い潰すのは良くあるバグだけど、Rustだとそれは「仕様」で「メモリ安全の対象外」なんだから。
まぁ、Rcの循環参照だけの話だから、外部のコードを含めてRc使っていないor循環参照していないことを検証できれば安全なんだろうけど、Rustファンが言うような「Rustを使えば安全」というようなことは無い。
>>960
素直にWikipediaの「RAMアクセス時に発生するバグやセキュリティホールなどから保護されている状態のこと」でいいだろ。
Rust公式はなんて定義しているの？>>931は定義じゃないよな。
1011:デフォルトの名無しさん
22/09/17 17:12:30.63 Y2R7c2nA.net
「定義」や「常識」「一般的に」の話とは別だが、このスレ見てる個人的印象だと、
Rustで宣伝商売したい人たちは、Rustを知らない人(意思決定者)が「メモリ安全性」を「優良誤認」(自己責任)するのを密かに期待してそう
Rustプログラマーはそうじゃないと言い切れるのか
1012:デフォルトの名無しさん
22/09/17 17:14:19.56 d1cxOtJi.net
>>962
あんさんキチガイやな
それはRustの問題じゃない
>>939の説明が一番わかりやすいが言語全般における問題で原理的に解決できない問題やで
1013:デフォルトの名無しさん
22/09/17 17:28:19.48 HhHvs5OG.net
URLﾘﾝｸ(insights.stackoverflow.com)
頑張ってるじゃないか
Rubyよりは使われてるみたいだな
1014:デフォルトの名無しさん
22/09/17 17:33:54.35 F49YQPus.net
>>925
今はしらんがrubyのgcも保守的gcだったよ。
1015:デフォルトの名無しさん
22/09/17 17:35:17.75 F49YQPus.net
>>934
じゃあなんで弱参照が用意されてるんですかねぇ？
1016:デフォルトの名無しさん
22/09/17 17:40:51.90 nFfh6P
1017:UY.net
1018:デフォルトの名無しさん
22/09/17 17:42:57.37 Qv9rB708.net
>>962
メモリ安全性に循環参照によるメモリリークの抑止が含まれないことは認めてくれた感じかな？
Rustを使えば絶対安全とか言ってる人の言うことを信じるのは良くないよ
匿名掲示板の変な人の発言じゃなくてちやんとしたドキュメントを読んだ方が良い
Rustはメモリ安全性について独自の定義はしてなくて、Wikipediaに書かれているような意味でのメモリ安全性を保証するよ
1019:デフォルトの名無しさん
22/09/17 17:46:34.02 37/3YRxM.net
>>967
グローバルなキャッシュを実装するときなど、参照先のGCを妨げることなく長時間参照を持ち続ける必要がある場合に使用する
基本的にトレーシングGCで弱参照が必要になるのは極めてレアケース
1020:デフォルトの名無しさん
22/09/17 17:54:50.07 8assD4qG.net
>>964
新しい藁人形連れてくんなよ。
最初から
Rustの問題は>>903で、本来なら
「メモリ安全*」
*メモリリークを除きます。
とちゃんと注意書きすべき
という主張。原理的に解決できるかどうかとか主張していない。
>>964の言うとおり、原理的に解決できないのに>>963を狙って「メモリ安全」と宣伝しているなら邪悪すぎるな。>>964は「Rust公式は邪悪」と言いたいのかな？
1021:970
22/09/17 17:57:12.28 37/3YRxM.net
なお、トレーシングGCにおいて循環強参照を避けることを目的に弱参照を使用することは全く何の意味もない
トレーシングGCのアルゴリズムを知っていれば循環強参照がGCのパフォーマンスやメモリ効率を悪化させることが無いのは明らかであるし、
弱参照の使用はレアケース故に概してあまり最適化されていないため、パフォーマンスは大抵の処理系においてむしろ悪化する
1022:デフォルトの名無しさん
22/09/17 18:01:07.97 F49YQPus.net
GCあるほうが楽だと思うんだけど、スパイクの無いGCって実現できないの？
1023:デフォルトの名無しさん
22/09/17 18:02:24.90 cg31Hi2x.net
>965
>Rubyよりは使われてるみたいだな
逆逆 Stackoverflowは精度がイマイチ
jetbrains
Ruby URLﾘﾝｸ(i.imgur.com) お一人様 7% ほとんどの人が仕事で使っている
Rust URLﾘﾝｸ(i.imgur.com) お一人様 86% ほとんどの人が個人の趣味
1024:デフォルトの名無しさん
22/09/17 18:03:21.53 8assD4qG.net
>>969
いや？全然。
循環参照によるメモリリークはメモリエラーだろ。メモリ安全「RAMアクセス時に発生するバグやセキュリティホールなどから保護されている状態」じゃない。
それにRustファンの言うことを信じているとか、冗談を言うのはやめてくれよ。気持ち悪いから。
1025:デフォルトの名無しさん
22/09/17 18:04:26.55 RkjWnqae.net
>>972
え？
C#では循環参照を避けるためなどの目的で弱参照を使うけど
これは悪化させているとでも言いたいの？
1026:デフォルトの名無しさん
22/09/17 18:05:04.82 5J0Fty65.net
>>962
「どの言語でも基本的には、OOMキラーに殺される前にGCが走らせたり、手動でメモリーを解放できること」ができないと安全では無いんじゃないかな。なので環境依存よ。
そう、Rustを使えば安全では無い。
1027:デフォルトの名無しさん
22/09/17 18:07:30.72 37/3YRxM.net
>>976
そんな事実はない
嘘だと思うならC#スレで聞いてきなさい
1028:デフォルトの名無しさん
22/09/17 18:17:28.35 DwuaYi+a.net
今回の件でGC言語がなぜ何倍も遅いのかよく分かった
世代別ガベージコレクションをするため頻繁にコピーGCを行なうことが遅くなる敗因の一つ
1029:デフォルトの名無しさん
22/09/17 18:27:42.60 nd18Koff.net
>>973
昔、ハードウェア側でGCするJVM(?)があったような…。
1030:デフォルトの名無しさん
22/09/17 18:30:08.29 NCiJs45P.net
>>973
RustはGC無いけど即座に自動的にメモリ解放されて楽だよ
1031:デフォルトの名無しさん
22/09/17 18:36:24.89 w5Ud45eS.net
参照カウントって GC じゃないの?
1032:デフォルトの名無しさん
22/09/17 18:37:21.32 5PJHomtk.net
四天王で最弱のGC。
1033:デフォルトの名無しさん
22/09/17 18:37:25.76 DA06Eolw.net
>>981 それの何が楽だと言っているの?
1034:デフォルトの名無しさん
22/09/17 18:38:14.76 5PJHomtk.net
俺の考えたGCが最強だけど、サブマリン特許やる予定だから教えない。
1035:デフォルトの名無しさん
22/09/17 18:39:44.29 iNOCwuLa.net
はよ次スレ
1036:デフォルトの名無しさん
22/09/17 18:40:19.19 ykXCo787.net
GC言語を使うと大して楽になるわけではないのに劇的に遅くなるからな
無能にはGC言語が向いている
1037:デフォルトの名無しさん
22/09/17 18:40:33.78 5J0Fty65.net
>>979
世代間GCのアリナシもそうだし、
>>927と同じく、言語と解決したい課題によるよ。
1038:デフォルトの名無しさん
22/09/17 18:42:13.95 5PJHomtk.net
Java製アプリはオメガテーつこてるけど、遅いとか重いとか一切ない。
サクサク快適。
だがしかし、キャレットの位置が異常なのでテキストの選択がやりにくい。
この動作はJava GUIの仕様だが、仕様が間違っていると思う。
Windowsと同じ動作にするべき。
1039:デフォルトの名無しさん
22/09/17 18:47:25.27 lRvi//fY.net
>>980 次スレ気づいてない 誰か代理 俺は無理
1040:デフォルトの名無しさん
22/09/17 18:47:35.21 kG69OWVT.net
>>982
プログラマー指定せずとも自動的に参照カウントが使われる言語(PerlとかPythonとかSwiftなど)の場合はGCで合ってるよ
C++のshared_ptrやRustのRcのように特殊な用途のみにプログラマーが明示的に指定して使うものはGCとは呼ばれず単なるデータ管理構造
1041:デフォルトの名無しさん
22/09/17 18:48:56.73 KEhwIc0k.net
>>981
いつも出てくるこの自動解放されて楽って感覚がわからない。自動解放とか出来て当たり前じゃないの？
GCありと同等のルーズさが許されなら良いけれど、実際はメモリ管理を明確にさせられるよね。
1042:デフォルトの名無しさん
22/09/17 18:51:00.89 fAQVBQ3R.net
>>989
Javaは遅い
少なくともC/C++/Rustなどの2倍～数倍は遅い
Javaは仮想マシンだしGCあるし遅くなるのは仕方ない
1043:デフォルトの名無しさん
22/09/17 18:51:29.16 5PJHomtk.net
お子様 → Python
おんな → Ruby
真の男 → Rust
こう言いたいのでは？
岡くんは。
1044:デフォルトの名無しさん
22/09/17 18:52:46.32 5PJHomtk.net
>>993
ってことは、2~3倍遅くても何も問題ないってことだろ。
1045:デフォルトの名無しさん
22/09/17 18:55:08.60 5PJHomtk.net
パイソンとかジャッカルには厨二を惹きつける響きがある。
女がなぜRubyを使いたがるのかはよく知らん。
岡くんがRust推しなのは本読んでわかった気になったから。
1046:デフォルトの名無しさん
22/09/17 18:55:32.40 lBhMDjlR.net
>>992
C並に高速なプログラミング言語では自動メモリ解放は普通は行われない
これは例えば新世代言語であるZigなどでも同じで手動メモリ解放となる
唯一の例外が常に自動的にメモリ解放されるRust
1047:デフォルトの名無しさん
22/09/17 18:56:42.77 8assD4qG.net
次スレはワッチョイ付けるよね。
1048:デフォルトの名無しさん
22/09/17 18:57:28.27 8assD4qG.net
>>997
循環参照除く
1049:デフォルトの名無しさん
22/09/17 18:58:09.16 8assD4qG.net
1000
1050:1001
Over 1000 Thread.net
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 19日 7時間 35分 53秒
1051:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています