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

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

スレタイ以外の言語もok

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

**デフォルトの名無しさん** · 2022/09/26(月) 14:41:03.61

暇なんか

**デフォルトの名無しさん** · 2022/09/26(月) 14:46:16.26

暇なんや、ごめん。。。

**デフォルトの名無しさん** · 2022/09/26(月) 14:51:59.22

>>469
根拠を示していないから、ただの誹謗中傷にしかなっていない。
煽るにしても、もうちょっとそれらしい主張にしたら？
例えば「JVM系の言語はだらしなくヒープを使うからネイティブにしても速くならない。そんなのをやるんだったら、安全性と速さを両立したRustを勉強したほうがいい」とか。

**デフォルトの名無しさん** · 2022/09/26(月) 16:55:54.26

ruby は ruby で実装されています
遅くなる罠

**デフォルトの名無しさん** · 2022/09/26(月) 17:38:57.35

>>471
LLVMなんてどこでも使っているのに
LLVMというだけでRust信者と思い込むのは浅はか
なんでもかんでもRustにもって来たがるのはアンチの悪い癖

**デフォルトの名無しさん** · 2022/09/26(月) 17:45:13.50

>>469
JVM言語の唯一のメリットであるポータブルな点は当時と比べて重要度を失っているんじゃないかな
もちろんポータブル自体は有利だけどJVMよりもっと様々な必要や要素を兼ね備えたWASMの出現が大きかったね
後発だから色んな改善がされているのは当たり前だけどWASM＞JVMであることは否定しようがないもんね

**デフォルトの名無しさん** · 2022/09/26(月) 20:34:04.50

https://github.com/benhoyt/countwords

Language x10 x100 x200 x400 Memory Comment
--------------------------------------------------------------
Zig 0.118 1.073 2.113 4.203 3.2MB (std.HashMap + "caller hash" by Context(std.hash.Fnv1a_64.hash))
C(gcc) 0.136 1.146 2.271 4.531 2.0MB (optimized.c, binIO,jemalloc,O4,LTO) NEW
C(clang/LLVM) 0.137 1.147 2.280 4.544 2.0MB (optimized.c, binIO,jemalloc,O3,LTO) NEW
Go 0.177 1.412 2.733 5.446 3.8MB (caller hash)<--from過去スレ
Rust(LLVM) 0.154 1.425 2.838 5.674 2.6MB (optimized-customhashmap,O3,LTO,caller-hash) NEW

以下、caller-hashではない
Zig 0.162 1.493 2.970 5.935 4.6MB (std.StringHashMap)
Rust(LLVM) 0.214 1.725 3.396 6.715 3.5MB (optimized,fxhash,O3,LTO) NEW

zig version 0.10.0-dev.4166+cae76d829
gcc 12.2.0/clang 15.0.0
rustc 1.64.0 (a55dd71d5 2022-09-19)
CPU Zen3@boost max~4.75GHz

Go Ryzen9 5900X windows11 <-- Boost Clock. Up to 4.8GHz.?

Rust(optimized-customhashmap)はC(optimized.c)と「コードを合わせ」てあるはずだが、コンパイルオプション程度の「簡単」な工夫を試した限りではgcc/clangと「ほぼ同じ結果にはならなかった」

「コードを合わせたRust」がCと比べて「2~3割程度遅い」のは「そういう場合もあるよね」で驚きも失望もない

意外なのは過去スレGoがRustと同水準だ(起動時間0.03s程度以外むしろGoの方が速い)という事。(こちらで再現したわけではない)

**デフォルトの名無しさん** · 2022/09/26(月) 21:18:14.74

またキチガイが粘着にデマを蒸し返してるのか
RustがC/C++と同等の速さで動くことは世界中で様々なケースで確認済み
今は次の段階へ進んでいて新たなシステム構築からRustへ置き換わって行ってる

**デフォルトの名無しさん** · 2022/09/26(月) 21:28:58.87

Rustはコードがスパゲッティになっちゃうから
その分遅くなる可能性あるよね
スパゲッティにならなきゃＣと同等だよ

**デフォルトの名無しさん** · 2022/09/26(月) 21:31:40.65

>>479
さすがにそりゃ無理だろ。

**デフォルトの名無しさん** · 2022/09/26(月) 21:46:52.90

>>480
Rustで書くと素直な整理されたデータ構造に改善する方へ寄せられていくから
スパゲティにはならずむしろスパゲティ解消のメンテしやすい良いコードになってしまいますね

**デフォルトの名無しさん** · 2022/09/26(月) 21:52:22.11

保守性の悪いスパゲッティなコードを書く人がRustを嫌っているのはそこだな
Rustだといつもの汚い思い通りのコードが書けないからイライラするのだろう

**デフォルトの名無しさん** · 2022/09/26(月) 22:14:45.96

Rustスレで自己満クソコードをいっぱい貼った子がおってなｗ
あれたぶん自分ではきれいな非スパゲッティコードだと思ってるんやろな

**デフォルトの名無しさん** · 2022/09/26(月) 22:20:48.84

>>484
最近Rustスレ見ているけどそんなの見たことないな
別の言語の話なのかな

**デフォルトの名無しさん** · 2022/09/26(月) 22:36:11.87

汚コーダーこと複オジ必死ww

**デフォルトの名無しさん** · 2022/09/26(月) 22:39:34.93

Rustはある種のBDUFを強制するから良い場合もあれば良くない場合もある

**デフォルトの名無しさん** · 2022/09/26(月) 22:52:31.71

具体的にその汚いコードというのを見てみたい
もし本当にあるならば

**デフォルトの名無しさん** · 2022/09/26(月) 23:05:18.27

自分ではキレイと思ってるから自分では自信があったのかなｗ
スレ住民にクソコード貼るなって言われても意固地になってたよｗ
その流れを再放送するなら無意味だよね
聞く耳持たないだけだから

**デフォルトの名無しさん** · 2022/09/26(月) 23:10:51.04

仕様をよっぽど気に入らない限りコードなんて見なければいい
仕様が憎ければコードまで汚く見える

**デフォルトの名無しさん** · 2022/09/26(月) 23:19:28.91

スパゲティコード見せて
Rustで見かけたことないので興味ある

**デフォルトの名無しさん** · 2022/09/26(月) 23:27:53.64

>>489
「ママー、きょうこんなコードかいたんだよ、みてみてー」ってノリだったから汚いかどうかは眼中になかったんだろ

気持ち悪いおっさんが幼稚園児メンタルで汚コードを一日中貼り続けるからマジキモかったけどな

**デフォルトの名無しさん** · 2022/09/26(月) 23:30:20.22

>>491
・>>1から過去スレをたどっていくことができない情弱
・酷評されたコードを汚くないと再反駁するためのネタ振り

どっち？

**デフォルトの名無しさん** · 2022/09/26(月) 23:32:17.55

再放送になるだけだから相手しちゃダメよ

**デフォルトの名無しさん** · 2022/09/26(月) 23:33:27.62

スパゲッティな汚いコードが貼られているスレどこよ？

**デフォルトの名無しさん** · 2022/09/26(月) 23:38:47.29

昔はgotoだらけの制御が絡み合って個々に分解しにくいコードを指してスパゲティと呼んだものだが
今時そんなgotoだらけのコードはないだろうから、どんなコードを指してスパゲティと呼んだのか興味はある。

**デフォルトの名無しさん** · 2022/09/26(月) 23:40:55.28

コードを示せない上にスレも示せないって、スパコードが実在しないんじゃね

**デフォルトの名無しさん** · 2022/09/26(月) 23:42:48.94

きれい
a + (b + c) = (a + b) + c

汚い
(= (+ a (+ b c)) (+ (+ a b) c))

**デフォルトの名無しさん** · 2022/09/26(月) 23:48:39.78

Rustでスパゲッテイなコードは起きないだろうから
>>484がRustを叩きたくて嘘をついていて引くに引けなくなっただけだと思うよ

**デフォルトの名無しさん** · 2022/09/26(月) 23:54:32.25

最初から「Rustスレ」でって書いてあるじゃん
ディープコピーすら知らなかった複オジの黒歴史を見てこいよw

**デフォルトの名無しさん** · 2022/09/26(月) 23:56:01.56

>>500
本人だから相手しちゃダメ
また汚コードペタペタされるぞ

**デフォルトの名無しさん** · 2022/09/27(火) 00:01:35.99

Rustスレもいつも眺めているがスパゲティコードらしきものを見たことないな
そもそもRustでスパゲッティコードというものが想像つかん

**デフォルトの名無しさん** · 2022/09/27(火) 00:16:44.35

急に必死じゃん
ウケる

**デフォルトの名無しさん** · 2022/09/27(火) 00:29:16.23

結局Rustアンチの人による妄想なの？
次世代言語でのスパゲッティ見てみたかった

**デフォルトの名無しさん** · 2022/09/27(火) 06:55:28.90

言語のアンチをしている時点で異常者だから

**デフォルトの名無しさん** · 2022/09/27(火) 07:43:25.27

>>482
「改善する方向に誘導」は嘘。
マズそうなデータ構造で助言してくれるわけじゃない。
実際は「煮詰まってきたときにコンパイルが拒否する」が正解。Rustはにっちもさっちもいかなくなってから「これはダメ」と放り投げる。

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

テスト駆動によれば、テストが通らない状態から始めるように誘導しなければ
改善へ誘導したと言えなくなる

**デフォルトの名無しさん** · 2022/09/27(火) 09:41:06.42

Rustが叩かれてるというよりは単に複オジが叩かれてるだけなんだがｗ
このへんの区別がつかない人と話になる？ｗ

**デフォルトの名無しさん** · 2022/09/27(火) 11:19:43.94

このスレはなぜJuliaの話題が無いのか
単純な計算やループだとRustのようにCと同等のネイティブコードで実行でき簡単に並列化・分散化してスケールする。
行列を標準で扱え、コンパイルも出来てスクリプト言語のように手軽にcliで実行できる。面倒な型は普通に型推論だが
逆行する推論を備え、それによってコンパイル言語でありえない動的さと、Lispのような真のマクロを備える
それともどこかにある最適な実装を、シコシコとオレ様実装してしまう泥臭く真の漢のシステムプログラマーばかりなのか

**デフォルトの名無しさん** · 2022/09/27(火) 11:26:01.22

>>509
汎用言語じゃないから

**デフォルトの名無しさん** · 2022/09/27(火) 11:38:54.13

>>509
その単純な計算やループはたまにしか使わない
JuliaはGC言語なのにヒープメモリをできる限り少なくするプログラミングをプログラマーがしなければいけない
そのへんに気を使わずプログラムを作ると速さに大きな差が出る
つまりメモリ管理は気にせず言語に任せておけばいいという言語じゃない
なのにガベージコレクションが発生する

**デフォルトの名無しさん** · 2022/09/27(火) 12:04:52.19

>>509
今時数値計算をCPUでやるおじさんは老害

**デフォルトの名無しさん** · 2022/09/27(火) 12:51:08.64

Juliaは多重ディスパッチでデータ型とアルゴリズム実装を自由に組み合わせられるみたいなのが売りの一つだと思うけど
ちゃんとテストされてない組み合わせだと簡単に計算結果を間違うという指摘が結構あって
数値計算向けの言語としては致命的なんではないかなぁと思っている

**デフォルトの名無しさん** · 2022/09/27(火) 13:19:39.57

カリー化の要領で単一ディスパッチに帰着するパターンの正式名称が致命的だった

**デフォルトの名無しさん** · 2022/09/27(火) 15:29:16.37

>>511
本当に触ったことありますか？どんな言語だとしても、ループ内でのヒープメモリ割り当てなんて気を付けて書く。
それはRustだって同じ事、GCというかスコープを外れたらOSが回収するが、決してメモリーを気にしないような
プログラミングなんてしない、これはGoでもJavaでも同じ。これを気にしない人はカッコ付けて再帰呼び出しを
してみたりスタックさえ気にしない人が稀にいる
本当に言いたいことを最後に書く日本人の典型だと思うが、そりゃGCはGC系なので発生するでしょうね

>>512
いまどきならCUDA.jlやAMDGPU.jlというものがある。だがRustだとかGoだとかもGPUを普通は使ったりしない。
前者は標準の高階関数で悦に入ってるのがその証拠であり、後者は多数のgoroutineで疑似パラレル処理を
するわけだが稀にGPUを使うとしても特殊例に過ぎない

>>513
そりゃテストされてない組み合わせなんてまともに動くほうが稀だとおもうけど。Rustでいえば少し昔のactixを
async-stdで動かすようなもんだろう、動的呼び出しのコストを気にして、動的性がほとんどないRustやGoと
比べるのが違うんだろうと思うが、letだのvarだの書かないのは、型推測の究極系からいうとありだと思う。
パターンマッチングもあるし、ライバルはRustとかじゃなく、PythonのDeepleaning系やＲなんだろうと思うが

**デフォルトの名無しさん** · 2022/09/27(火) 15:42:59.62

めっちゃw早口で言ってそうw

**デフォルトの名無しさん** · 2022/09/27(火) 16:39:12.74

>>515
> どんな言語だとしても、ループ内でのヒープメモリ割り当てなんて気を付けて書く。

多くのGC言語では、そんなことを気にせずGC任せのプログラマーが多数派だと思います

> GCというかスコープを外れたらOSが回収するが、

ありえません

**デフォルトの名無しさん** · 2022/09/27(火) 18:30:42.66

Rustみたいなバリバリの実用土方向け言語と比べるのは間違い。

**デフォルトの名無しさん** · 2022/09/27(火) 18:38:52.09

>>515
必死で笑った

**デフォルトの名無しさん** · 2022/09/27(火) 18:56:17.56

>>515
本当まで読んだ

**デフォルトの名無しさん** · 2022/09/27(火) 19:10:24.11

>>518
え？ほとんど誰も使ってないんだけど

**デフォルトの名無しさん** · 2022/09/27(火) 19:50:43.74

>>518
Rustは管理部門がコーダーに押し付けたい言語。
社員監視用にマナー講師を雇うようなもんだ。

**デフォルトの名無しさん** · 2022/09/27(火) 20:02:47.05

>>522
このまえはRustを趣味で使われる割合が多いと叩いていたのに叩く方針変更かね
Rustはプログラマーに愛されているプログラミング言語7年連続1位と記事が出ているけどどうするのかね

**デフォルトの名無しさん** · 2022/09/27(火) 20:09:31.55

>>515
各組み合わせごとに厳密にテストしないと組み合わせられないなら
「多重ディスパッチで簡単に組み合わせられます」とか言うなよってこと
そもそも静的型ならコンパイルエラーになるしPythonとかなら巨大なライブラリにみんなで乗っかる方式だから、組み合わせの問題が発生しやすいのはJulia固有の話

**デフォルトの名無しさん** · 2022/09/27(火) 20:13:06.18

>>523
今までも同じ主張しかしとらんよ。
これからは他人のために使うRustユーザーが増えていくから、愛され言語１位を維持するのは無理だろ。
PythonとかJavaの規模のなっても維持できているなら本物だな。

**デフォルトの名無しさん** · 2022/09/27(火) 20:18:14.18

Rustは他の言語よりコーティングしやすいしプログラマーにとっては嬉しい言語っす

**デフォルトの名無しさん** · 2022/09/27(火) 20:49:24.20

1から自分で好きなように書くならRustは気持ち良い言語なのは同意するけどね
Rustは個人の好みや癖が出やすい言語だから、他人のオナニーの後片付けは辛いぞ
Rubyしかり、創意工夫()の余地が大きくて楽しい()言語はレガシー化すると激しくプログラマに嫌われる傾向がある

**デフォルトの名無しさん** · 2022/09/27(火) 21:06:03.50

>>527
プログラミングしたことのない人には
RubyとRustは創意工夫の余地があって辛くて
他の言語には創意工夫の余地がないように見えているのか
そんなデタラメ書き散らす前にプログラミング経験積んで出直してこい

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

Go追加>>478(>>450,461)
Language x10 x100 x200 x400 Memory Comment
--------------------------------------------------------------
Zig 0.118 1.073 2.113 4.203 3.2MB (std.HashMap, caller hash by Context(Fnv1a_64))
C(gcc) 0.136 1.146 2.271 4.531 2.0MB (optimized.c, binIO,jemalloc,O4,LTO)
C(clang/LLVM) 0.137 1.147 2.280 4.544 2.0MB (optimized.c, binIO,jemalloc,O3,LTO)
Go 0.152 1.233 2.428 4.832 3.9MB (caller hash,better loop) New
Go 0.164 1.346 2.654 5.279 3.8MB (caller hash)手元再現 New
Go 0.177 1.412 2.733 5.446 3.8MB (caller hash)<--参考値from過去スレ
Rust(LLVM) 0.154 1.425 2.838 5.674 2.6MB (optimized-customhashmap,O3,LTO,caller-hash)

以下、caller-hashではない
Go 0.085 0.366 0.693 1.319 61.9MB (parallel.go,reserve 65536/2)<--マルチスレッド New
Zig 0.162 1.493 2.970 5.935 4.6MB (std.StringHashMap)
Go 0.182 1.563 3.063 6.097 3.8MB (customhash.go,reserve 65536) New
Rust(LLVM) 0.214 1.725 3.396 6.715 3.5MB (optimized,fxhash,O3,LTO)

zig version 0.10.0-dev.4166+cae76d829
gcc 12.2.0/clang 15.0.0
go version go1.19.1
rustc 1.64.0 (a55dd71d5 2022-09-19)
CPU Zen3@boost max~4.75GHz

https://github.com/benhoyt/countwords

予想以上にGoが速かったが、最近の成果かもしれない。
https://go.dev/blog/go1.19 (2 August 2022)
>Go 1.19 includes a wide variety of performance and implementation improvements

**デフォルトの名無しさん** · 2022/09/27(火) 21:40:42.21

アルゴリズムの比較と言語の比較の区別がつかない人が未だに無意味なことを続けてるな～

**デフォルトの名無しさん** · 2022/09/27(火) 22:51:31.16

>>522
なるほど

**デフォルトの名無しさん** · 2022/09/27(火) 23:06:01.46

社畜タイムだな

**デフォルトの名無しさん** · 2022/09/27(火) 23:25:50.78

>>522
そんなホワイト企業があるなら名前教えてくれよ

**デフォルトの名無しさん** · 2022/09/28(水) 11:39:35.28

くせぇ、くせぇ、泥だらけ漢だらけで土方臭え！forループじゃなくmap使えとか親方ァは細かすぎる・・・
何がワシだって「下積みの頃はC未定義動作で行間を読んだもんだ！」だ！未定義動作書くなよ！？基本だろうが！＃
何が「ここは大手の偉い人が書いたから変えらなかったんだよ！」だ！
Displayトレイトが滅多に表示しない方に使ってて頻繁に表示する方はいちいちdisp_xxxなんて呼ばないといけないんだ！
設計根本から間違ってるだろうが！
「Rustは気持ち良い言語、Rustは気持ちよく書ける」なんて2020年代前半に言われてたらしいが、もう憎しみしかない
お百度参りしても、この恨み晴れるとは思えない
オレこのデスマが終わったら、高給取りのAIのPython業界に転職するんだ・・・

**デフォルトの名無しさん** · 2022/09/28(水) 12:04:48.31

>>534
ことごとく勘違いしてるでしょ？

mapは単なる写像にすぎなくてループと対応するものではなくループの中の写像の文 let y = f(x); に対応するものです

未定義動作はunsafeを使わない限り発生しません

disp_xxxといったものは標準ライブラリにありません

以上から貴方はRustではなく異なる別のものを使っている可能性が高いです

**デフォルトの名無しさん** · 2022/09/28(水) 13:39:09.80

顔真っ赤で一行開け必死で笑ったｗｗｗキモッｗ

**デフォルトの名無しさん** · 2022/09/28(水) 18:08:24.66

rustは、haskellみたいにはならないと思う。
ロマンが足りない。オナニーしても気持ち良くない的な。
その点、juliaの方がロマン感じる。

**デフォルトの名無しさん** · 2022/09/28(水) 18:19:46.86

rustは十分ロマンがあるよ

**デフォルトの名無しさん** · 2022/09/28(水) 19:06:02.54

嫌いなのはわかるけど消去法でもRust一択だよ
まずスクリプト言語は速度と安全性がゴミなので論外
(書き捨てのスクリプトにのみ使うならアリ)

C/C++は論外
世界中のバグはこの言語から生まれている

JavaやC#もぬるぽ排除失敗
副作用まみれを助長する言語仕様
クソ重GCとJVM運用でオワコン

Goも結局ジェネリクス導入の失敗で標準ライブラリがジェネリクスなしの涙目に
安全性とは程遠い
言語仕様も一部よくわからない謎
さらにゴルーチンの書きにくさで並行処理の言語としても微妙

その他のモダン言語は結局本質的解決にはなってないから論外

よってRust一択

**デフォルトの名無しさん** · 2022/09/28(水) 19:10:09.32

>>539
Goはnil安全性すらないから前世紀の言語っぽい

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

Goは色んな機能を削りすぎていて苦痛
ジェネリック導入で明るい未来を期待していたけどあんな使えない仕様になるとは

**デフォルトの名無しさん** · 2022/09/28(水) 19:17:23.82

>>540
あーそれもあるか
err != nilには笑ったわ
なんかエディタのスニペットに登録してるから問題ないらしい

**デフォルトの名無しさん** · 2022/09/28(水) 19:20:37.46

正直NULL安全みたいな機能いるか？
Kotlinとかにもあるけど、結局NULL許容型も書けるし中途半端過ぎる

**デフォルトの名無しさん** · 2022/09/28(水) 19:21:11.66

>>539
Rustは絶壁の学習曲線で多数の初学者が挫折し、エンスー以外使えないエンドコンテンツで終わるだろう。

せめてライブラリとかフレームワークを初心者向けに作り込むことができればまだ可能性はあるが、所有権とライフタイムがラフな使い方を拒否するからそういうことも困難。

まぁ、「３番目に学習する言語」くらいの位置になれれば万々歳だな。

**デフォルトの名無しさん** · 2022/09/28(水) 19:25:13.91

>>543
関数型界隈以外ではその重要性に気がついてなかった
いわゆるシステムプログラミング言語でRustが唯一まともにNULL安全性を持って生まれた言語

**デフォルトの名無しさん** · 2022/09/28(水) 19:30:16.66

>>544
初心者が挫折しがちというのは理解できるのだが
(俺自身C/C++のヘビーユーザーだったが最初はコンパイルを通すのに苦労した)
しかし一旦理解するとコンパイルエラーはほぼ起きないし
Rustの気持ちになって考えることができるようになる
本当にコンパイラの気持ちがわかる

**デフォルトの名無しさん** · 2022/09/28(水) 19:40:17.57

>>543
Javaのヌルポは散々馬鹿にされていたからなぁ。
実際には、正常値としてのNullならnull objectの方が素性が良い。optionalみたいなNullが良いのは、異質なケースとして明示的に処理したい場合のみ。

**デフォルトの名無しさん** · 2022/09/28(水) 19:43:30.85

>>546
その「一旦理解する」というのが絶壁だっつうの。

**デフォルトの名無しさん** · 2022/09/28(水) 19:43:33.10

データ構造含めてスパゲッティでも動いてくれるGC言語と
データ構造が整理されていないとコンパイラが通ってくれないRust
保守性の良いコードを強制してくるRustはウザいよな

**デフォルトの名無しさん** · 2022/09/28(水) 19:51:26.79

>>547
ポインタであろうとデータであろうと
nullやnilなどはその型と全く別の型であるべきであり
型が異なればコンパイルエラーとすることができるため
nullやnilをうっかり使ってしまう悲劇を確実に回避できる
この仕組みを備えることをnull安全性と言う

**デフォルトの名無しさん** · 2022/09/28(水) 20:06:25.79

>>543
kotlinは割りとバランスいいと思う。
Option<T> みたいな冗長な型にならず T? で済ませてるから。
Rust はそこはちょっとダルい。

**デフォルトの名無しさん** · 2022/09/28(水) 20:27:35.31

はぁ？w

**デフォルトの名無しさん** · 2022/09/28(水) 20:37:57.86

>>539
そんな優等生な実用性は求めてないんだよ。

次世代なら、超すごいGCとかなんでも推論してハマればすごいけれど外れるとクソみたいなのをやってくれよ。

**デフォルトの名無しさん** · 2022/09/28(水) 21:50:06.42

>>553
その辺はcopilotなど最新のAIの分野だと思われる
モダン言語としてはまず言語仕様をしっかり安全性の高いものにするのが大事
それに俺はヤンキーを否定してるわけではない
pythonとかライブラリの充実度は世界一だろうし
雑なツールを作るには一番早くできるだろう
TypeScriptもスクリプト言語の型システムとしてはよくできている
しかしその手の言語を最初に使っても結局そのスクリプトを人がどんどん改造してスパゲッティになる様子を見てきた
スクリプト言語である程度実装可能なことがわかったら
すぐにRustに切り替えるべき

**デフォルトの名無しさん** · 2022/09/28(水) 22:09:10.05

>>548
C/C++を理解していないと難しいとは思う
所有権の移動はあらゆる変数参照で起きうるから
ひとまず借用しまくること
Rustの借用はコンパイルが通る限り安全なのだ
所有権を移動しない
これで既存の言語のように書けるのではないかな

**デフォルトの名無しさん** · 2022/09/28(水) 22:56:28.26

>>555
move不要説って、RefCellで複雑なことやろうとするでしょ

Cellでreplaceしまくったほうが簡単だよ

**デフォルトの名無しさん** · 2022/09/28(水) 23:45:50.98

moveでもborrowでも呼び出し階層のどのレイヤーで所有権を持つか常に意識しないといけないから既存の言語と同じ感覚では書けないよ

それが良い面もあれば悪い面もある

**デフォルトの名無しさん** · 2022/09/28(水) 23:54:28.10

>>556
Cellや動かせないOptionの中身に対してはreplaceだな
生成コストかかるものならtakeで一時的に借りるしな
moveはいつでもコスト安い

**デフォルトの名無しさん** · 2022/09/28(水) 23:56:03.77

>>543
いるに決まってんだろ。
お前意味なくいつもnull許容ばかり使ってるのか？ありえねーわ。

**デフォルトの名無しさん** · 2022/09/28(水) 23:58:55.54

>>557
それは>>515も書いているように
どんな言語でもまともなプログラマーならば内心で意識してプログラミングするっしょ
そしてその意識の差で速度が大きく変わって来るから言語に関係なく重要な

**デフォルトの名無しさん** · 2022/09/29(木) 00:25:48.05

moveは速い
cloneも速くするためにはRcに入れて循環参照とかいうリスクを取る

逆に言えば、最適化の意識が低いスタイルを確立すれば循環参照問題が無くなるのでは？

**デフォルトの名無しさん** · 2022/09/29(木) 01:02:09.01

>>561
聞きかじりだけでRustを使ったことがないからそんな間違えをする
Rcのcloneと中身のcloneは全く別物かつ独立
例えば中身がclone実装なく不可でもRcはcloneできる

循環参照は意図的に作らない限りRustでは自然に生じることはない
そして作らないことが正解

**デフォルトの名無しさん** · 2022/09/29(木) 01:13:01.23

>>560
GC言語では全く意識する必要ないよ
性能にも関係ない話

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

>>563
GC言語でも意識しないと性能に直結するぞ
>>515が言うループの内外どちらかで速度差を測ればすぐ分かる

**デフォルトの名無しさん** · 2022/09/29(木) 04:16:41.47

複オジ相手しても時間の無駄だぞ

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

>>562
聞きかじりがどうのと、そんなメンドクサイ言語はダメだわ。
バグのもとだわ。

**デフォルトの名無しさん** · 2022/09/29(木) 08:16:59.79

>>560 >>562
そんな前提が無いと使えないんじゃ、やっぱりRustは絶壁の学習コストだな。

コミニティも初心者に配慮する気配無いし、>>544が正解か。

**デフォルトの名無しさん** · 2022/09/29(木) 08:35:25.13

>>566
>>567
じゃあC++についても知らないのね
C++のshared_ptrもRustのRc/Arcもどちらも機能もその件も同じで
そのスマートポインタのコピー(clone)をしても中身はコピーされないんだよ
中身はそのままで共有する仕組みであって基本知識の入門レベル

GCのある言語でもオブジェクトの参照のコピーとオブジェクト自体のコピーの違いがありますね
それと同じことだからこの2種類のコピーの違いを理解できていないのはマズいですよー

**デフォルトの名無しさん** · 2022/09/29(木) 08:50:17.22

ホントRustをわざと嫌われるように仕向けてるように見えるよなあ

**デフォルトの名無しさん** · 2022/09/29(木) 10:17:24.11

Rustはなぜ開発者に愛されているのか、そして「人を選ぶ」理由とは？実案件でRustを採用するゆめみに聞く
https://codezine.jp/article/detail/16416

**デフォルトの名無しさん** · 2022/09/29(木) 11:33:20.73

まずは既存言語の延長として借用ベースでコードを書いてから
適切にムーブもするというスタイルをお勧めしたいね
本来のRustのスタイルとしてはムーブベースで考えるべきなのだけど
ハードルがかなり高いと思う
(C++のムーブコンストラクタやムーブ代入演算子を使いまくってた俺クラスの人間じゃないと無理)
借用の乱用でライフタイムの指定が嫌になったころにムーブを覚える
これこそアハ体験