Rust part16

**デフォルトの名無しさん** · 2022/06/27(月) 08:17:03.45

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

Web上の実行環境
https://play.rust-lang.org

日本語の情報
https://rust-jp.rs/

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

前スレ
Rust part15
https://mevius.5ch.net/test/read.cgi/tech/1652347700/

**デフォルトの名無しさん** · 2022/07/04(月) 12:06:52.57

>>146
何の本質？？

**デフォルトの名無しさん** · 2022/07/04(月) 12:45:51.46

>>142
メンタルモデルなんて言葉ねーよ、ハゲ

**デフォルトの名無しさん** · 2022/07/04(月) 12:48:07.99

Rustの登場でC／C++が要らなくなったのは当然

>>147
まずはRustの初歩を学習必須
Rustではlet mut a = 99; とmutを指定すればその変数が書き替え可能
呼び出し先で書き替えたいならば
まずRustの関数を呼び出す時は＆mut a と可変参照を渡せば呼び出し先で書き替え可能
Cの関数を呼び出す時はそれを *mut とポインタにして渡せば呼び出し先で書き替え可能

**デフォルトの名無しさん** · 2022/07/04(月) 12:51:14.14

>>146
全てunsafeにでもしない限り、効率を落とさずには代替になれない例が有ると言っている。
ポインタ値をアプリ全体でLinkedListのノードを識別するための id 値として
利用している場合だ。
index 番号では効率が劇的に下がるケースが多い。

**デフォルトの名無しさん** · 2022/07/04(月) 13:07:11.60

>>151
その件に限らず全てのケースで以下が成立する
基本事項: RustではCと同じ速度＆同じ安全度で常に全ての実装が可能
追加事項: RustではCと同じ速度＆完全に安全なインタフェースで多くの実装が可能
したがってCが不要となったとの話はもちろん正しい

**デフォルトの名無しさん** · 2022/07/04(月) 13:15:16.22

&a as *const _ as *mut _

**デフォルトの名無しさん** · 2022/07/04(月) 13:24:41.08

>>152
あなたの理解は浅い。

**デフォルトの名無しさん** · 2022/07/04(月) 13:39:33.82

>>153
それはmut宣言していない変数を(先のC関数もしくはRust unsafeで)書き換えてしまうことになるためあまりよろしくない
書き替えるならばmut変数のmut参照を直接*mutにした方が良いのでは
let mut a: 型名＝初期値;
c_func( & mut a as *mut _ )

>>154
それは>>152で正しい

**デフォルトの名無しさん** · 2022/07/04(月) 13:43:31.17

すべての言語にunsafeがあればいいよね

**デフォルトの名無しさん** · 2022/07/04(月) 14:00:59.16

>>151
ベンチマークください

**デフォルトの名無しさん** · 2022/07/04(月) 14:07:26.39

>>147
FFI呼び出しに要求されるsafetyを満たしてないと言う意味ではアウトだけどそれがどうかした？

**デフォルトの名無しさん** · 2022/07/04(月) 14:13:33.00

まーた複オジ vs 100点オジの低レベルな言い争いになってるから
隔離スレ復活させたほうがいいな

**デフォルトの名無しさん** · 2022/07/04(月) 15:40:19.20

>>155
頭の悪い人は黙ってろ。

**デフォルトの名無しさん** · 2022/07/04(月) 16:04:58.57

>>160
>>155に間違いは無いようだし
君はさっきから的外れなことばかり書いてるような

**デフォルトの名無しさん** · 2022/07/04(月) 17:29:54.81

>>151
それがどうしたというんだ？
何を言いたいのかわからん。

**デフォルトの名無しさん** · 2022/07/04(月) 18:02:37.22

>>162
馬鹿には何を言っても理解できない。

**デフォルトの名無しさん** · 2022/07/04(月) 18:07:12.10

> 全てunsafeにでもしない限り

誰も問題にしてないところを勝手に取り上げるのはストローマン論法っていうんだぜ！

**デフォルトの名無しさん** · 2022/07/04(月) 18:46:54.41

>>151
なにを問題にしてるのかよくわからんが必要なら全てunsafeにすればいいやん
それでもCとかと同じでそれ以外のケースではRustの方がより安全なんだし

**デフォルトの名無しさん** · 2022/07/04(月) 19:49:32.85

リーナスがこのスレを見ていたらLinuxに採用されることはなかっただろうね

**デフォルトの名無しさん** · 2022/07/04(月) 19:55:55.02

みたらそっ閉じするだろw

**デフォルトの名無しさん** · 2022/07/04(月) 19:58:11.73

>>143
センチメンタルな用語ですね！

**デフォルトの名無しさん** · 2022/07/04(月) 20:06:09.66

メンタルモデルってプログラマー界隈ではよく知られた言葉だと思ってたんだけど通じない人もいるのね

**デフォルトの名無しさん** · 2022/07/04(月) 20:26:03.13

プログラマー界隈で言ってる奴を見たことないしそもそも違い云々の時にそんなもん出されても困惑するだけ

**デフォルトの名無しさん** · 2022/07/04(月) 20:26:54.96

>>169
普通は通じるからご心配なく

**デフォルトの名無しさん** · 2022/07/04(月) 21:09:07.84

>>169
自分の周りでも普通に通じるけど、よく考えるとどこで知った用語か謎かも…
なんか有名なプログラミング系の本とかに書いてあったっけ？

**デフォルトの名無しさん** · 2022/07/04(月) 21:22:26.69

適当な造語をさも常識のように語るのはやめようね
そもそもそんな言葉使わなければいい話

**デフォルトの名無しさん** · 2022/07/04(月) 21:31:48.17

>>172
プログラミングのコンテキストでよく使われるようになったのはUI/UXデザイン分野でよく使われてたからじゃないかな
ドン・ノーマンの「誰のためのデザイン？」とかかなり昔の本から使われてるよ

**デフォルトの名無しさん** · 2022/07/04(月) 21:34:43.82

そもそも拾う必要すら無かったレスを拾ったばっかりによく分からん論争に
なんかすんませんな

**デフォルトの名無しさん** · 2022/07/04(月) 21:35:54.46

>>172
元々は認知心理学の用語でユーザーインターフェイスとか分野から広まって広く知られるようになったんじゃないかと思う
初出は1943年とのこと
https://ja.m.wikipedia.org/wiki/%E3%83%A1%E3%83%B3%E3%82%BF%E3%83%AB%E3%83%A2%E3%83%87%E3%83%AB

**デフォルトの名無しさん** · 2022/07/04(月) 21:44:59.75

複オジ大先生がそんな言葉ないとおっしゃってるんだぞ！
スーパー自宅開発者の複オジ大先生が間違ってるとでも言うのか！！

**デフォルトの名無しさん** · 2022/07/04(月) 21:56:46.09

もはやここが隔離スレ状態

**デフォルトの名無しさん** · 2022/07/05(火) 02:12:03.31

>>165
「全てunsafe」だぞ。
アプリ全体をunsafeということだ。
なら、C/C++で十分。

**デフォルトの名無しさん** · 2022/07/05(火) 04:52:44.77

だから
> ポインタ値をアプリ全体でLinkedListのノードを識別するための id 値として利用している場合だ。
の場合だけだろ
お前はそんな特殊なアプリしか作らないのかよw
そもそもノードの識別を全体にばらまいてるとか設計がタコなんじゃね？

**デフォルトの名無しさん** · 2022/07/05(火) 05:08:33.40

>>180
RubyやJava、オブジェクトの「識別番号」が取得できることがあるが、
それはポインタ値だ。通し番号ではない。
つまり、C言語では伝統的に、リンクトリストのノードを識別するために
ポインタ値が使われている。そしてそれこそがリンクリストの本来の使い方。
だれかが間違えて、通し番号で識別する習慣が生まれてしまったが、それは
集団幻覚みたいなもので、誤った使い方だ。

**デフォルトの名無しさん** · 2022/07/05(火) 05:22:06.16

で、何が言いたいんだ？
Linked Listをアプリ全体にばらまいてるアホ設計を正当化しようとしてるのか？w

**デフォルトの名無しさん** · 2022/07/05(火) 06:08:27.82

>>177
気に入らないやつを片っ端から複おじ認定するのは荒らしなんだろうか

**デフォルトの名無しさん** · 2022/07/05(火) 06:20:58.64

>>183
その子はキチガイ
>>159でも気に入らない二人だけが書き込みしてるように見えてる

**デフォルトの名無しさん** · 2022/07/05(火) 07:54:16.72

>>181
GC言語では、ポインタと言ってもコストの高いポインタとなっていて、コストの高いガベージコレクションで回収する。
それに加えて、データ競合を防ぐには更に何らかの競合回避コストも加わってくる。

一方で、C/C++ではリンクされたノードリストからノードを外す時に、そのライブラリがノードを解放してしまうと、そこへのポインタを保持していた場合にダングリング発生。
それを回避するためにはshared_ptrなどのコストの高いポインタを使わざるを得ない。
ちなみにC++のshared_ptrはスレッドセーフだからマルチスレッド時でも大丈夫だが、逆に言えばシングルスレッド時には無駄なコストがかかっている。

Rustでは、そこはRcとArcの2種類が提供されており、シングルスレッド時にはコストの低いRc使用、マルチスレッド時にはRcだとコンパイルエラーとなってくれてArc使用と、最小限のコストで済む。
このようにノード解放の観点だけ見ても、考慮すべきことをRustコンパイラは適切に指摘してくれる。

**デフォルトの名無しさん** · 2022/07/05(火) 10:29:00.25

なんでずっとRustスレでRustのセールストークやってるんだ？

**デフォルトの名無しさん** · 2022/07/05(火) 10:43:19.79

RustスレでRustのネガキャンやってるやつよりマシだろ

**デフォルトの名無しさん** · 2022/07/05(火) 11:28:42.85

>>182
C言語が速い秘密はLinkedListとそのノードをアプリ全体でポインタ値で識別している
ことにある。先頭を0として1,2,3と割り振った通し番号を使っていたと
したら、全然速度が出ない。
そしてその証拠が、JavaやRubyなどで「識別番号」が8桁の16進数で表示できる
ことだ。その識別番号とは生ポインタ値のことであり、それがそのオブジェクトを
唯一に特定できる最も効率的な方法である。
他の方法では効率が落ちる。

**デフォルトの名無しさん** · 2022/07/05(火) 11:29:55.08

>>185
あなたは、理解が浅い。
RustのRcやArcには欠陥がある。
そんなもので済むならとっくにCやC++でも採用されている。
C/C++の歴史の長さを舐めてはいけない。

**デフォルトの名無しさん** · 2022/07/05(火) 12:22:07.18

>>188
同じ話を何度も繰り返すなよ、ボケ爺か？
そうであってもそのアプリがCと同じでそれ以外のアプリならRustの方が安全って書いてあるだろ

**デフォルトの名無しさん** · 2022/07/05(火) 12:28:00.80

>>187
他人に説明できるだけの合理的理由が無いことは自覚してるんだな……

**デフォルトの名無しさん** · 2022/07/05(火) 12:32:52.81

えっ、なにか説明が欲しかったのか？
スレ読んでりゃわかると思うがw

**デフォルトの名無しさん** · 2022/07/05(火) 13:04:52.14

>>189
欠陥があると主張するならば、その理由を示さなければならない。
さらにC++でも採用されていることを知らないのは無知ではないか？
C++のshared_ptr ＝ RustのArc ＝ SwiftのARC が同じ機能であり、スレッドセーフなリファレンスカウンタ利用の共有ポインタ方式。
それらのスレッドセーフでないコストの安いバージョンがRustのRcである。
これらは、安全にポインタを共有しつつ即時解放を行なうために、必須の機能である。

**デフォルトの名無しさん** · 2022/07/05(火) 13:13:39.59

>>188
ここでいう効率ってなんの効率？

**デフォルトの名無しさん** · 2022/07/05(火) 13:19:57.09

ラスタシアンは何故算数おじさんに触れずにいられないのか

**デフォルトの名無しさん** · 2022/07/05(火) 16:10:20.98

>>193
いや、RustのRcなどは、C++とshared_ptrと同じじゃない。
全然違うと言っても過言ではない。

**デフォルトの名無しさん** · 2022/07/05(火) 18:30:15.50

>>195
なぜか自分のレスには反応してくれないんだよね

>>196
具体的になにが違うの

**デフォルトの名無しさん** · 2022/07/05(火) 23:09:51.67

>>196
違いがあると主張するならば、この議論で意味のある違いがあることを示さなければならない。
さらに前述の、欠陥があると主張した件についても、その欠陥を示さなければならない。

**デフォルトの名無しさん** · 2022/07/05(火) 23:19:42.19

>>197
>具体的になにが違うの
平日の昼ひまでこのスレにくるおじさん・じじいは
C++のshared_ptrと同じじゃないということを知ってさえいれば激十分なんだよ。
だから、具体的になにが違うかは(知らないから)答えられない。
C++とRustの深い知識あるようなすごい奴が平日の昼暇でここで遊んでいる
なんてことはないだろう。

**デフォルトの名無しさん** · 2022/07/06(水) 11:32:12.50

Full Stack Rust App Template using Yew + Actix!
https://youtu.be/oCiGjrpGk4A

**デフォルトの名無しさん** · 2022/07/06(水) 11:45:22.14

UIフレームワークはスレチだよしんどけ

**デフォルトの名無しさん** · 2022/07/06(水) 12:20:02.69

ここRustプログラミングに関することならば何でも歓迎
各々の関心がないことの和集合を取ると全体集合になる
特定の人にとって関心がないからと言って排除してはいけない

**デフォルトの名無しさん** · 2022/07/06(水) 14:24:50.14

違いが大きすぎるとどこが違うとかいうのを説明するのが難しくなる。
織田信長とオムライスの違いを説明できるか？
まあ shared_ptr と Rc の違いはさすがにそこまで大きくはないけども、
前提となる C++ と Rust の違いも小さくはないので比較する意味を感じないな。
shared_ptr は shared_ptr だし Rc は Rc としか言いようがないだろう。

**デフォルトの名無しさん** · 2022/07/06(水) 16:11:44.19

リファレンスカウント方式の複製可能なスマートポインタという点では類似のものと言って良いのでは
元々はc++とrustで実行効率に差があるという話だがその観点でどういう差があるのかね
そもそも実行効率が何のことを言っているのかがよくわからんから議論しても仕方ないか

**デフォルトの名無しさん** · 2022/07/06(水) 18:50:47.56

原理と詳細を区別できない人はちょっと……

**デフォルトの名無しさん** · 2022/07/06(水) 23:39:03.25

>>203
全く別物の比較なら、信長は人間、オムライスは食べ物、というようなザックリした説明で良くなるのでは？

**デフォルトの名無しさん** · 2022/07/06(水) 23:45:15.32

Arcとstd::shared_ptr<>が似てるという人に対して、「いや、std::shared_ptr<>とRcは全然違う」と反論するのがおかしいのでは？

**デフォルトの名無しさん** · 2022/07/07(木) 00:18:57.43

>>206
そうだよ。
それを適用するなら
shared_ptr は C++ のスマートポインタ、 Rc は Rust のスマートポインタということしか言えなくなる。

**デフォルトの名無しさん** · 2022/07/07(木) 00:49:54.35

>>208
俺らのレベルではその程度の知識で十分だろ
で、スマートポインタでもなんか違いあるの？と質問されても具体的に答えられなくても
全く問題ないからな。
一方、すごい人からすれはstd::shared_ptr<>とRcは全然違うとなるんだろうが
(すごい人敵にはそれらは例えばstd::shared_ptrは信長で人間、一方、Rcはオムライスで食べ物ぐらい違う！
でも、俺らは人間だって餌として食べることができるから同じだろ)

**デフォルトの名無しさん** · 2022/07/07(木) 05:04:39.45

>>196
>>193 は
> C++のshared_ptr ＝ RustのArc ＝ SwiftのARC が同じ機能であり、スレッドセーフなリファレンスカウンタ利用の共有ポインタ方式。
って書いてるんだから同じじゃないとか全然違うとかフワフワしたこと言ってないで
・機能
・スレッドセーフ
・リファレンスカウンタを利用
の各項目について違いを書きなよ

**デフォルトの名無しさん** · 2022/07/07(木) 08:43:50.09

共有ポインタって何？

**デフォルトの名無しさん** · 2022/07/07(木) 10:54:08.79

shared pointerじゃね？

**デフォルトの名無しさん** · 2022/07/07(木) 11:14:16.23

結局参照カウント方式なのは一緒なんでしょ

**デフォルトの名無しさん** · 2022/07/07(木) 12:48:02.98

>>212
だとするとshared pointer方式ってどんな方式？？
リファレンスカウンタを利用しないshared pointer方式もあるってことだよね？

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

>>214
shared pointerはc++のが有名すぎるからなんとも言えないなぁ。

参照カウント以外でポインタを共有するのはリンクリスト方式とかあるよ。

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

ARCで管理してる時点でRustはガベコレじゃないからすごい！って理論は破綻してるんじゃありませんかね？

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

>>216
誰がそんなこと言ってんの？

静的に管理できるものは静的に管理するし、実行時にしかわからないものは実行時に管理するってだけのことだ。
参照カウンタの適用範囲を間違えてるプログラマがいるならそれはそいつが無能。

**デフォルトの名無しさん** · 2022/07/07(木) 16:01:25.39

Rust公式の日本語意訳にはしっかりRustはガベコレじゃないから高速って書いてあるね

**デフォルトの名無しさん** · 2022/07/07(木) 16:16:37.05

>>216
Objective-C/SwiftのARCとRustのArcは同じ3文字略語だけど別のものだよ
それを理解した上で言ってるのなら別にいいんだけどさ

**デフォルトの名無しさん** · 2022/07/07(木) 18:43:04.02

>>216
そもそもRust公式が「メモリリークはメモリ安全の範疇」と言っているしな。

**デフォルトの名無しさん** · 2022/07/07(木) 18:52:31.81

>>220
それはRustの定義がおかしい
一般的にはメモリリークがあるとメモリ安全だとは言わない

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

流れぶった切りだけど単純にRustの人たちはGUIどうしてんの？

**デフォルトの名無しさん** · 2022/07/07(木) 19:11:09.29

なんだ、じゃあ、バグはセーフティと定義したら、Rustは安全高めなのか。

**デフォルトの名無しさん** · 2022/07/07(木) 19:29:21.10

rust にクラスはないのですか？

**デフォルトの名無しさん** · 2022/07/07(木) 19:39:16.69

>>221
Rust が言語の仕組みによって防ごうと努力する範囲にメモリリークは含まないという定義だよ。
それを表すのに「Rust の仕様の中では」メモリ安全という用語を使っているのであって、
定義におかしいもクソもない。定義なんだから。

**デフォルトの名無しさん** · 2022/07/07(木) 19:46:35.34

>>224
クラスと名付けられている概念はない。
あなたにとってクラスとは何のこと？何が出来ればクラス？

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

型クラスの事を聞いてるんじゃない？

**デフォルトの名無しさん** · 2022/07/07(木) 19:49:32.87

>>216
ARCで管理しているのはSwift
RustはC++と同じくRAIIなので高速
どうしても共有メモリを使いたい時のみshared_ptrやRc/Arcを用いる

**デフォルトの名無しさん** · 2022/07/07(木) 20:00:40.75

>>225
そのRustの仕様の中でメモリ安全性を達成できていないんだから
Rustの仕様の中でメモリ安全性という用語を使うのは不適切
Rustの謳うメモリ安全性は世間一般のメモリ安全性とは異なる概念なんだからそれを表すには他の用語を使うのが適当かと

**デフォルトの名無しさん** · 2022/07/07(木) 20:06:09.82

>>224
クラスはその根幹の継承がデメリットだらけと結論が出ているためGoやRustなどでは採用されていない
メンバー変数やメンバーメソッド等とは構造体で使えるため困ることはない
Rustでは構造体を含む任意の型に対して横断的に共通適用可能なトレイトがあり非常に強力で利便性がよい

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

>>229
知らんがな。
大抵の専門用語は一般名詞に (その分野における) 明確な定義を与えることで成り立ってるのはごく普通のことだろ。

**デフォルトの名無しさん** · 2022/07/07(木) 20:25:04.56

>>229
世間一般なんてものはなくそれぞれがそれぞれの定義域に依る
そしてそれが明確になっていればよい
例えばRustではメモリ競合は防止可能と明確化しつつ、より一般的な競合状態は対象外と明確化している
原理的に無理なものは無理なのだからそこは明確化してあればそれでよい

**デフォルトの名無しさん** · 2022/07/07(木) 21:01:30.61

>>228
aliasingの話してるところにRAIIが来るのもよくわからないがRAIIだと高速という理屈はさらにわけわかめ

**デフォルトの名無しさん** · 2022/07/07(木) 21:12:46.12

>>222
windows-rsでunsafe祭りになりながら書いたよ。オススメはしないが。

**デフォルトの名無しさん** · 2022/07/07(木) 21:39:23.64

SwiftのARCとRustのArcの区別がつかない人は論外なので発言を控えてほしい
ただでさえしょうもないのにしょうもなさが倍増するからね・・・

SwiftのARCはAutomatic Reference Counting
https://docs.swift.org/swift-book/LanguageGuide/AutomaticReferenceCounting.html

RustのArcはAtomically Reference Counted
https://doc.rust-lang.org/std/sync/struct.Arc.html

**デフォルトの名無しさん** · 2022/07/07(木) 22:03:40.09

>>230
継承をやめて委譲にすれば割とまともになると思います
https://mevius.5ch.net/test/read.cgi/tech/1434079972/51
https://mevius.5ch.net/test/read.cgi/tech/1434079972/84

**デフォルトの名無しさん** · 2022/07/07(木) 22:05:44.36

>>233
C++とRustはヒープ利用に対してRAIIによるデストラクタ呼び出しによりリファレンスカウンタ無しでメモリ解放するので高速
さらに加えてRustでは所有権と借用のルール明確化により解放の安全性も静的に保証している
一方でSwiftはヒープ利用に対して常にリファレンスカウンタを用いるARCによりメモリ解放の管理をするため低速

**デフォルトの名無しさん** · 2022/07/07(木) 22:11:56.95

>>236
その流れで継承不可のクラスベースのオブジェクト指向言語がどういうものになるか思考実験的に考えてみなよ

**デフォルトの名無しさん** · 2022/07/08(金) 03:25:18.13

それよりSQLが超苦手な俺はPRQLにめちゃくちゃ期待しているのだがラスタシアン達はSQLも達者なのかね？

**デフォルトの名無しさん** · 2022/07/08(金) 03:34:35.68

うーん。
このスレ↓では、Rustはメモリーリークしない、Cはリークすると議論してたからなあ。

https://mevius.5ch.net/test/read.cgi/tech/1650185555/

**デフォルトの名無しさん** · 2022/07/08(金) 07:13:21.57

pijul使ってみたけど、改行コードがCRLFだと非対応で
バイナリファイル扱いになるという謎仕様でまいった
差分とか出せなくなる
ファイルタイプ判別を変えるオプションは無い

それは置いといても、表示もドキュメントも超簡素で
もうすぐ1.0.0リリースを迎えるとは思えない状態

ほとんどの入門記事で使われている重要コマンドpijul statusが
最近のバージョンで削除されたのも謎すぎる
だいじょうぶなのかこれ

**デフォルトの名無しさん** · 2022/07/08(金) 07:47:38.58

>>239
今の開発のトレンドが互換性維持で苦労して中途半端なものになるくらいなら好きな仕様にして最後全部トランスパイルすりゃいいじゃん！になってしまったな
世の天才が叡智を絞った結果がRust界隈含めて今まで散々馬鹿にしてたウェブ(JS)の後追いなの草生えるわ
ちなみに英語圏ではSQLはシークェルと発音するから覚えとけ
ラスタシアンの紳士諸君はえすきゅーえるとかクソダサい発音禁止な

**デフォルトの名無しさん** · 2022/07/08(金) 08:02:14.74

PRQL 書き味が CloudWatch logs Insightと似てそうだけどあれもそんなにいいもんじゃないぞ。

**デフォルトの名無しさん** · 2022/07/08(金) 08:04:43.63

>>242
外人の禿げたおっさんはだいたいエスキューエル言うてるやろ

**デフォルトの名無しさん** · 2022/07/08(金) 08:11:32.47

コントロールも無視もできない処理系や既存資産の上でまともな進化や開発体験を維持しようとしたらトランスパイルになるのは必然だったんだろうな。

それが必要になるクソさと、トランスパイルコストの損益分岐点が最初に現れたのがJSってだけだと思うよ。

**デフォルトの名無しさん** · 2022/07/08(金) 08:44:10.67

>>240
メモリリークに関しては

まず、Rustは自動的に即座にメモリ解放されるため他の言語と比べて高速かつ安全
ただし、Rustにおいて循環参照は他の言語と大きく異なり、
・意図的に色々と明確に指示して作成しないと、循環参照は自然に発生しない
・強い参照と弱い参照を使い分けることが出来るため、強い参照のみによる循環参照を避けることが可能
・意図的に強い循環参照を作成した場合は、それはRustにとって自動的なメモリ解放の対象とならない

したがって、Rustにおいて強い循環参照を意図的に作成した場合のみメモリリークが起こりうるが、わざと作成したのだから意図通り、という扱い

**デフォルトの名無しさん** · 2022/07/08(金) 09:06:34.18

ほんと無知って怖いね