Rust part24

**デフォルトの名無しさん** · 2024/05/27(月) 06:41:26.82

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

公式ドキュメント
https://www.rust-lang.org/learn

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

※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 part23
https://mevius.5ch.net/test/read.cgi/tech/1708677472/

**デフォルトの名無しさん** · 2024/06/25(火) 09:03:31.00

「アセンブラ知らずにCって理解できるものなのか？」
↓
「C++の方が普通。Cは専門家向け」
↓
「いきなりRust」

**デフォルトの名無しさん** · 2024/06/25(火) 09:25:46.54

オレはPHPからRustに移行したよ
actix web使ってる
速さには感激してる

戸惑うのは謎のワーニングが出る時かな
mut付けてないのにmut付けるなってワーニング出たりする
cargo cleanとかすれば消えるんだけど

**デフォルトの名無しさん** · 2024/06/25(火) 09:32:01.85

>>351
Cでmalloc/free手書きしたりSEGV起こすだけで十分理解できると思うけどなぁ
C++じゃないとダメなのってどのへん？

**デフォルトの名無しさん** · 2024/06/25(火) 10:36:22.38

>>348
その3つはどの言語から来ても簡単にすんなり理解できるでしょ

>>353
PHPから来た人はジェネリクスはすんなり理解できるものなの？

**デフォルトの名無しさん** · 2024/06/25(火) 11:03:26.31

>>355
ジェネリクスが特段わかりずらいとは思わなかった
それより型があいまいなPHPから移行すると型定義したくてうずうずする
ちゃんと型定義したかったんだわ

**デフォルトの名無しさん** · 2024/06/25(火) 11:48:25.07

C++ を知っていると Rust がわかりやすいというよりも有難みを感じやすいとは思う。
なんだかんだで Rust は面倒くさいしそれなりに学習曲線の急上昇もあるのは本当だけど、
それでもなお Rust が良いと思えるのは C++ の駄目な部分についての反省が入ってるから。

C++ 的なものが必要な場面で C++ より上手くやるものという感覚で捉えてる。

**デフォルトの名無しさん** · 2024/06/25(火) 12:43:05.46

「Rustを学ぶためにC++を学ぶ必要があるか(学ぶといいか)」も定期的に沸くな

何度も見てて思うのが
「あなたはRustを学ぶ前にC++を学んでいたか」とYes/Noが一致して、平行線にしかならない議論なのでは

**デフォルトの名無しさん** · 2024/06/25(火) 13:05:45.82

フランス語を学ぶときに英語を知ってる必要があるか(學ぶといいか)を考えれば良い
日本語←→フランス語だけ教わりたいのに英語學ぶ必要は無い

**デフォルトの名無しさん** · 2024/06/25(火) 15:05:50.09

Rustを学ぶ前に他言語を学ぶ必要は無い。

しかしプログラム自体の経験が浅いのなら、絶壁の学習曲線に挫折する可能性が高い。そういう初学者はRusuではなく、とりあえずは動くところまで持っていきやすい言語を使って勉強したほうがいい。

**デフォルトの名無しさん** · 2024/06/25(火) 15:23:35.53

C++を経由しないでRustを使えてる人たちがたくさんいることから
C++が不要言語であることは間違いない

**デフォルトの名無しさん** · 2024/06/25(火) 15:29:24.75

>とりあえずは動くところまで持っていきやすい言語

Rustも変な事しなければとりあえずは動く
C/C++みたいに一見動いてるフリしてメモリ壊してたりに気付かない方が有害

**デフォルトの名無しさん** · 2024/06/25(火) 16:22:38.23

それはプログラミングに慣れてるから言えることで、
エラーになってくれることが心底から有難いことだと思えるのは
エラーにならずにぶっ壊れる体験を通してじゃないと無理だよ。

結果的にわかりやすいかどうかの話じゃなくて
学習する当人がちゃんと納得して学習し続けられるかというモチベーションの話としてね。

**デフォルトの名無しさん** · 2024/06/25(火) 16:57:26.38

Cでmalloc/free面倒とか忘れたとか解放したのにポインタ残っていて使っちゃったとか体験しておいたほうがよいかもしれないが
C++は不要

**デフォルトの名無しさん** · 2024/06/25(火) 17:23:57.01

>>363
つまり最初はPerlが良いってことか

**デフォルトの名無しさん** · 2024/06/25(火) 17:55:00.58

初心者レベルだと C/C++ もRust も向いてないって話

**デフォルトの名無しさん** · 2024/06/25(火) 19:32:04.37

そう言えばHaskell難しい言うやつも似たようなこと言ってたな。
そんなに難しいと感じてなかったから不思議だったんだが、
自分でバグ作っておいて言語が難しいとか言うなよ…。

**デフォルトの名無しさん** · 2024/06/25(火) 20:03:41.12

ID:ZtCD4zFU
ID:bjcoCLHQ

**デフォルトの名無しさん** · 2024/06/25(火) 20:13:30.50

関数型言語を使ってるとRustの理解が少し早くなるよ
特にHaskellを知っていればtraitの理解も早いね
しかしRustを学ぶために関数型言語を知っている必要はないんだよな
同様にC++も知っている必要はない

**デフォルトの名無しさん** · 2024/06/25(火) 22:48:01.04

Erlang使ってて良かったと思った

**デフォルトの名無しさん** · 2024/06/25(火) 23:04:44.45

バレおじw

**デフォルトの名無しさん** · 2024/06/25(火) 23:30:51.26

>>347
展開しないほうがよい

展開する時も二重ループは発生するだけでなく単なる計算より重い
さらに本来は回避できる浮動小数点を使わざるを得なくなる
そして>>342のコードをその例のような静的ではなく問題入力値に応じて動的に作り出さなければならない

一方で展開しないならばRustコード数行だけで済み任意の問題に対応できる
割り算部分も0/N=0かN/N=1だけなので整数で済む

**デフォルトの名無しさん** · 2024/06/25(火) 23:49:25.06

>>369
>特にHaskellを知っていればtraitの理解も早いね
これには全く同意できない
type classというかHaskellとはやり方もできることも違いすぎるから
そもそも何の事前知識なくてもtraitは容易に理解できるでしょ

**デフォルトの名無しさん** · 2024/06/26(水) 08:25:01.52

神精霊絶大なエネルギーを使用可能
幽霊人間を疲れさせるや一時操作可能
①エネルギーの貯蔵の仕方は➁そのエネルギーの発生方法は③そのエネルギーを貯蔵する方法は④それだけのエネルギーの物体を科学で観測不能はなぜ

6G通信に使われるテラヘルツ帯の電波、脳細胞の成長を促進
2022/08/16
タンパク質の操作／マイクロ波等の照射が記憶に影響
2008/11/01
男性の精子の減少、携帯電話の使用と関係か最新研究
2023/11/02
統合失調症.発達障害.各身体症状など国力低下
人為的で身体攻撃
威力を測定すれば判明するのにテロリストを野放し

全ての精神病
①　英キングス・カレッジ・ロンドンをはじめとするグループは、人間の脳内で発現している古代ウイルス由来のDNA配列を調べ、それがうつ病・統合失調症・双極性障害といった主要な精神疾患のなりやすさと関係していることを明らかにした。
➁九大、後の出来事が直前の出来事に錯覚を起こさせる脳の仕組みの一端を解明
2024/06/05
④幼児期の脳活動から18歳時点でのIQを予測できるという研究結果
2023/09/09
⑤3歳までに脳は形成される
⑥統合失調症などの患者に幻覚や妄想を引き起こす脳のネットワークがAIを使った研究で明らか

1立方ミリメートルの脳の断片をハーバード大学とGoogleの研究者がナノメートル単位で3Dマッピングすることに成功
2024年05月10日
※MRIで物理的に神経の接続問題観測可能

嘘つきの知的障碍者と精神障碍者や認知症の者発見

◇電磁波攻撃はあるとないどの思考【組織】の者が話しているのかな
マイクロ波聴覚効果やボイス・トォ・スカル発見可能
電磁波している者守りたいもの守りたくないものの判別方法は各対象者の将来で名よある地位やよい未来の映像と悪い未来の映像を見てもらえば副交感神経と交感神経の差と脳波パターンをみたら判明する

**デフォルトの名無しさん** · 2024/06/26(水) 12:30:12.07

>>372
>割り算部分も0/N=0かN/N=1だけなので整数で済む
そうだね
この問題の本質はそこだと思うけどそれ言い出すとif使わない理由が無いな

**デフォルトの名無しさん** · 2024/06/26(水) 12:31:27.14

>>373
事前にやるならNimの方が良いよ

**デフォルトの名無しさん** · 2024/06/26(水) 13:01:41.83

Rustを学ぶ前に他の言語を学ぶ必要はないけど
全くプログラミング言語を知らないならシンプルで学習例も多いC言語一択だね
ポインタとヒープの扱いまで学べたらたらC言語を忘れてRustへ

**デフォルトの名無しさん** · 2024/06/26(水) 14:31:44.00

デストラクタの動きを知らないで本当にrustできんの？って思うけど

**デフォルトの名無しさん** · 2024/06/26(水) 14:43:55.70

スコープを抜けた時にデストラクタが自動的に呼ばれる
それだけ
予備知識を必要としない

**デフォルトの名無しさん** · 2024/06/26(水) 14:54:42.66

Rustのデストラクタの描き方ってなんであんなんなん

**デフォルトの名無しさん** · 2024/06/26(水) 15:00:49.20

C書くしかない時代だったからC勉強できたけど
Rustがある時代に純粋な教養としてC勉強なんて苦行できないだろ
修行僧かよ

**デフォルトの名無しさん** · 2024/06/26(水) 15:13:01.92

最近気付いたんだけどもしかしてRustの所有権って2通りの意味がある？

**デフォルトの名無しさん** · 2024/06/26(水) 17:42:24.19

>>382
そのココロは？

**デフォルトの名無しさん** · 2024/06/26(水) 18:05:02.22

>>378
それってc＋＋学ぶときも一緒じゃない？

**デフォルトの名無しさん** · 2024/06/26(水) 20:50:33.32

>>382
Rustを学ぶ上で所有権は忘れた方がいい
実はRustは非常にシンプルで
値をmoveして用いるか参照して用いるかしかない
(ただしCopy実装型はmoveの代わりにcopy)
値はmoveされないままスコープが尽きると消える
消える直前にデストラクタが呼ばれる
以上たったこれだけだ

**デフォルトの名無しさん** · 2024/06/26(水) 23:00:32.38

>>381
苦行はごちゃごちゃして煩わしい記述を強要されるRustだろ。fnだのmutだの略語が多く
殺伐としているし、記号の使い方なども含めて如何にもギークが作ったというような
美的感覚が欠如した野暮ったいコードを書き連ねるのはおぞましい。

Cと違って新しいSwiftはRustに機能的に近いが、Rustよりずっと洗練されている。

**デフォルトの名無しさん** · 2024/06/26(水) 23:26:44.75

Rust言語を知らないから見た目のキーワード批判しかできないのだ

**デフォルトの名無しさん** · 2024/06/27(木) 04:20:04.01

スタックは早くてヒープは遅い、みたいな話よく聞くんだけど、
具体的に何が早い/遅いの？

**デフォルトの名無しさん** · 2024/06/27(木) 04:33:33.49

>>388
自分でヒープメモリ管理部分を書いてみるとよくわかる
ヒープでメモリ確保したり解放したりするのは色んな処理が入って非常に遅い
スタック上ならそのコストはない
関数に入る＆抜けるときにスタックフレームを指してるレジスタの値を変えるだけ

というのに加えて
CPUの多段メモリキャッシュ機構での速さが桁が変わってくる
スタックフレーム上なら常にアクセスしていてキャッシュに載るから超速い

**デフォルトの名無しさん** · 2024/06/27(木) 07:18:32.22

>>386
mutが煩わしい言うてる時点で関数型プログラミングをまともに出来てないな。
今までの副作用だらけの言語だとマルチスレッドプログラミングが上手く出来ないから関数型プログラミングを取り込んだというのに。

Rustでごちゃごちゃしてると感じるならHaskellにおいで。
forやifと書くことすら煩わしく感じるくらいシンプルだよ。

**デフォルトの名無しさん** · 2024/06/27(木) 08:56:33.16

Swift、よく知らないんだよなあ
Appleの囲い込み言語という時点でもう勉強する気になれない

**デフォルトの名無しさん** · 2024/06/27(木) 09:08:39.14

C++ でも変更なしのときに const を付けるんじゃなくて変更ありのときに指定するほうがよかったという声は結構あるよな。
まあいまさら変更できんが。

**デフォルトの名無しさん** · 2024/06/27(木) 09:50:18.20

>>372
PyO3おすすめ

**デフォルトの名無しさん** · 2024/06/27(木) 10:07:28.99

>美的感覚が欠如した野暮ったいコード

禿しく同意

**デフォルトの名無しさん** · 2024/06/27(木) 10:21:46.91

>>389
キャッシュに乗るという前提なら、
確保・解放が遅いだけでアクセス速度とかは変わらないってことでOK？

キャッシュに乗る確率とかもスタックとヒープでやっぱちがうんかな

**デフォルトの名無しさん** · 2024/06/27(木) 10:30:52.47

キャッシュに載ったらアクセス速度変わるやろ

**デフォルトの名無しさん** · 2024/06/27(木) 10:33:46.61

そりゃ、キャッシュ・イズ・キングと言うぐらいだからな

**デフォルトの名無しさん** · 2024/06/27(木) 11:05:58.76

>>395
キャッシュに乗りやすいというのはアクセスに局所性があるということ。
関数自体が小さくてすぐ終わるなら普通はスタックのほうが以前と近い場所にアクセスすることになる。

**デフォルトの名無しさん** · 2024/06/27(木) 11:20:07.91

よくわかんないんだけどスタック上に確保したメモリの所有権を外に移して関数は終了してスタックが縮んじゃうとかさ
「そんなわけないだろ」って思うんだけど

**デフォルトの名無しさん** · 2024/06/27(木) 11:56:53.85

>>395
スタックフレーム同士も連続しているし
レジスタ退避でアクセスしているし
他のローカル変数もスタック上にありアクセスしているから
スタック上に確保すればキャッシュ上にある

**デフォルトの名無しさん** · 2024/06/27(木) 12:00:05.74

>>399
関数が値を返す場合にサイズが小さければレジスタで返す
サイズが大きい場合は呼び出し元のスタックフレームに領域を確保してそこへ直接書き込んでいる
つまり暗に可変参照を渡す最適化が行われている
それはサイズの大きい値を返す関数呼び出しが多段でも同じなので一番最初の関数のスタックフレームに直接書き込まれる

**デフォルトの名無しさん** · 2024/06/27(木) 12:27:57.71

>>399
>「そんなわけないだろ」
その感覚は正しい
Rustを広めたいために勢い余ってデマを流してる香具師が一定数いる

>>401 が正しい

**デフォルトの名無しさん** · 2024/06/27(木) 12:45:47.11

>>399
>よくわかんないんだけどスタック上に確保したメモリの所有権を外に移して関数は終了してスタックが縮んじゃうとかさ
これ自体なにを言いたいのかよくわからんけど
その前にそんなこと言ってるやつおる？

>>400
>スタック上に確保すればキャッシュ上にある
キャッシュから追い出される状況もあるよね

**デフォルトの名無しさん** · 2024/06/27(木) 12:53:21.92

>>402
いや>>399の話も正しいんだよ
重要なのはRust上の概念とその実現方法(実装)とその最適化の3つは当然異なるということ

所有権を移すとはmoveという概念であって
moveの実装はコピー(してコピー元を使わない)
ただし無駄なコピーは最適化で消える
例えば大きなサイズの構造体を関数が返す場合は呼び出し元の関数のスタックフレーム上に直接書き込まれることで無駄なコピーが発生しない

**デフォルトの名無しさん** · 2024/06/27(木) 13:06:53.73

それをスタックが縮むと表現してるのか
意味は分かった

**デフォルトの名無しさん** · 2024/06/27(木) 13:24:58.99

スタックてのは関数が何段か終了して縮んだあと、また伸び直して前の伸びを上書きしちゃうでしょって話
とにかく「移動」というのが新しくて、代入の移動はわかったけど
関数呼び出しの引数も移動です、返り値も移動ですってのがどういう実装に落とされるのかまだわかってない

**デフォルトの名無しさん** · 2024/06/27(木) 13:49:01.55

低レイヤで起こってることは C と変わらん。
寿命の矛盾がないか静的な検査がクソ強いってだけだ。

**デフォルトの名無しさん** · 2024/06/27(木) 15:56:45.17

スタックを伸ばすだの縮めるだのいうのはメモリのとある番地に実際のメモリを割り当てたり切り離したりすること。
スタックが足りなくなってきたら連続するアドレスのところに実メモリを割り当てるのがスタックを伸ばすってこと。
普通の使い方をしていたらスタック領域を縮めることはあんまりない。
スタックがあるところまで伸びたということはもう一度そこまで伸びる可能性が高いので回収してまた割り当ててをするよりは割り当てっぱなしにしたほうが良いという設計思想になってるので全体のメモリが足りている限りスタックが浅いところまで戻ってきても実メモリを回収しないというのが現代的な OS。
逆に言えば全体のメモリが足りなくなってきたら回収することもあるんだけど。

素人感覚だとメモリをなるべく空くようにするのが「メモリの無駄を防ぐ」という意識の人がいるんだけど、存在するメモリが使われないままになってるほうがもったいないんだ。

それとたとえば Linux だとスタックの大きさは 8MB が上限というのがデフォ。
これは OS 側の設定なのでアプリケーション側では (OS の設定をいじる権限がない限りは) どうにもできない。
8MB ってめちゃくちゃ少ないように感じるかもしれないけどだいたいこんなもんで足りちゃうんだよ。

**デフォルトの名無しさん** · 2024/06/27(木) 16:39:29.50

>>406の書いてる「縮む」はVecで言うところのcapacityじゃなくてlenっぽくない？
ムーブとの関連がよくわからんけど

**デフォルトの名無しさん** · 2024/06/27(木) 17:46:10.67

>>407
ですな

**デフォルトの名無しさん** · 2024/06/27(木) 17:59:42.80

低レイヤのメモリの取り扱いモデルが確立している高級言語が C/C++ くらいしかなくて、 LLVM も汎用的なフレームワークのふりして思ったほど自由ではないので Rust の言語仕様が LLVM の都合に、 C/C++ の都合に引っ張られているところはまあまあある。

**デフォルトの名無しさん** · 2024/06/27(木) 18:20:02.76

つまりC++同様、ポインタの糖衣構文としての参照？

**デフォルトの名無しさん** · 2024/06/27(木) 18:50:13.20

あ、なるほど
&mutみたいに*mutって書けば実体を扱えるわけか

**デフォルトの名無しさん** · 2024/06/27(木) 18:56:27.59

いつものことながら妙なこと書く人はだいたいThe Book(本物)を読んでないよな

**デフォルトの名無しさん** · 2024/06/27(木) 19:07:01.79

そんなの読むような真面目な人間は5chに来ない

**デフォルトの名無しさん** · 2024/06/27(木) 20:08:52.27

>>412
まあ機械語レベルの低レイヤまでいけば参照もポインタも同じっちゃおなじだけど、構文糖だという認識は明確に誤りだ。
参照がポインタの構文糖なんて書いてあるデタラメ本で C++ を学んだのなら C++ の理解も全然できてないと思う。
または書いてないことを脳内で作り出すタイプのやつは誤った方向に邁進してどうにもならなくなったところで質問したりするから言ってることが意味不明になりやすい。
仮に(あくまでも仮にだが！)言ってる理屈自体が正しかったとしてもちゃんとした用語でいってくれないと伝わらないし、ちゃんとした用語は(一次資料に基づいた)ちゃんとした資料で学ばないと身に付かん。

**デフォルトの名無しさん** · 2024/06/27(木) 22:40:30.91

>>406
そのmoveについてもmoveというRust上の概念の理解のみがRustを学習＆利用していく上で必要となるよ
moveによる生成コードがどのようになるかは最適化の方法の変更や進化で変わり得る話だから確定することはできず、学ぶこともできない
こんな場合に現在はたまたまこんな生成コードになっていることだけは実験などでわかるけど今後の保証はない、としか言えない
だからmoveはmoveとして理解することが唯一の正解でしょう

**デフォルトの名無しさん** · 2024/06/27(木) 22:43:00.49

どうせChatGPTの回答を使い回してるだけだろ

**デフォルトの名無しさん** · 2024/06/27(木) 22:45:03.57

>>416
C/C++でポインタのポインタと言わずに
ダブルポインタって言ってる香具師のことか

**デフォルトの名無しさん** · 2024/06/27(木) 23:03:07.98

Rustの各概念を無理矢理なC/C++と結びつけようとしたり生成コードと対応させようとしてる人々がRustを難しいと言ってるようにみえる
そんなことをせずに各概念の理解だけに集中すればRustはシンプルに出来ていてわかりやすい言語だと理解できるよ

**デフォルトの名無しさん** · 2024/06/27(木) 23:34:16.52

C/C++ だと抽象機械という概念を挟む形で仕様化されてる。
言語の挙動を抽象的な (架空の) 機械の動作として記述していて、それを実際の機械とどう対応させるかは知らんけど見かけ上の動作が仕様通りなら良しとする規定。
だから最適化を豪快にやっても結果が同じなら言語仕様に反しない。

で、抽象機械っていうのはある程度は現実のコンピュータを想定はしているけど細かいところは意図的にうやむやにして選択の余地を残してる。
C/C++ には言語仕様としてはスタックもヒープも存在せず書いてあるのは寿命についてのルールだけで、それをどういう形で実現するかは自由……
なんだけど現実にはスタックとヒープを使い分けるとちょうどいいような仕組みになってる。

C/C++ の言語仕様に低レイヤのメモリアクセスのことも確かに書いてあるんだ。
でもそれは抽象的な機械のことであって本物の機械のことじゃない。
でもある程度は対応しているという絶妙なバランスで成り立ってる。

Rust では言語の高レイヤの話と低レイヤの話の間を取り持つ理屈がまだ十分に整理されてないと思う。
言語の性質上、やっぱり低レイヤを全く意識しないで上手く使えるようなものでもないし、低レイヤのことを考えるのもそれなりには必要だと思う。
必要なんだけど意識的にレイヤを分けて考えられないなら混乱するのも確かなので、 (少なくとも最初は) 低レイヤのことは忘れろというのは理に適った助言だと思う。

**デフォルトの名無しさん** · 2024/06/27(木) 23:40:56.83

C/C++の方こそ誤魔化しているぜ
そのため未定義動作だらけだ

Rustはわかりやすく抽象的に明確だ
そして未定義動作もない

**デフォルトの名無しさん** · 2024/06/27(木) 23:46:01.41

未定義動作の話をしてはいないよ。
低レイヤとの間をどう取り持つかの話をしてる。

**デフォルトの名無しさん** · 2024/06/27(木) 23:53:14.85

Rustは低レイヤにも対応している
高い抽象度によるプログラミングもできる
高い抽象度のプログラミングにおいて低レイヤとの対応付けは不要であってやるべきではない

**デフォルトの名無しさん** · 2024/06/27(木) 23:56:31.92

オジーw

**デフォルトの名無しさん** · 2024/06/28(金) 00:09:40.45

>>424
その論を許すなら Rust は OS やデバイスドライバを書くのには使えない言語であってよいという立場になるが、そうじゃないよね？

**デフォルトの名無しさん** · 2024/06/28(金) 00:16:19.92

>>426
なぜなの？
Rustが抽象的にプログラミングできるのも事実であるし
OSやデバイスドライバを記述できるのも事実だよ

**デフォルトの名無しさん** · 2024/06/28(金) 00:20:27.61

>>427
低レイヤを書くための仕様が確立していなくて今はなんとなく書けているという状態を「できる」と称していいならそうだね。

**デフォルトの名無しさん** · 2024/06/28(金) 00:28:00.38

>>428
うーん
Rustに何か欠けているわけではなく
実用的に問題なく機能している状況で
言い掛かりをつけてるだけにみえるけどどうよ

**デフォルトの名無しさん** · 2024/06/28(金) 00:48:52.30

>>429
実用的に問題があって、機能できていない。
Rust の仕様に明るくて低レイヤのメカニズムに明るくても Rust で OS は書けないから。
現状では Rust の実装に明るいという要素が求められていて、ある程度はそういうものかもしれないけど仕様 (というか文書化というべきかな) の明確化が十分とは言えない。

**デフォルトの名無しさん** · 2024/06/28(金) 00:57:19.20

>>430
本気で言ってるのかなあ
デバイスドライバはRust製に置き換えられたよ
OSもRustで新たに作られて機能することも判明してるけど
既存のOSは書き換えコストの問題だから別問題だね

**デフォルトの名無しさん** · 2024/06/28(金) 01:04:07.98

そういえばRedoxの開発は今どうなってるんだろ

**デフォルトの名無しさん** · 2024/06/28(金) 01:21:44.32

>>431
これからやる人に対して説明できる形になってないという話をしてる。
出来てるから出来るんだというのは何の根拠にもならんよ。
出来るようになるための道筋が確立しているかどうかの話なんだ。

**デフォルトの名無しさん** · 2024/06/28(金) 01:57:43.66

流れを切って申し訳ないんだけど
Rustってディープラーニングのプログラムを作るのに実用的な段階に来てる?
まだ一部の物好きが書いてるだけ?

**デフォルトの名無しさん** · 2024/06/28(金) 02:39:42.33

自分

Rustってディープラーニングのプログラムを作るのに実用的な段階に来てる?
まだ一部の物好きが書いてるだけ?

Copilot

Rustでディープラーニングのプログラムを作ることは可能ですが、まだ一部のエンジニアが実験的に取り組んでいる段階と言えます。具体的には、『ゼロから作るDeep Learning』の内容をRustで実装する試みや、Deep LearningのフレームワークDeZeroをRustで実装する試みなどがあります。

これらの試みは、Pythonで書かれたディープラーニングのコードをRustに翻訳し、Rustの学習やディープラーニングの理解を深めるためのものです。しかし、これらの実装はあくまで個々のエンジニアの学習目的で行われており、一般的なディープラーニングの実装にRustが広く使われているわけではありません。

Rustはパフォーマンスが高く、メモリ安全な言語であるため、ディープラーニングの実装にも適していると言えます。しかし、Pythonのように豊富なディープラーニングライブラリが存在しないため、現状ではディープラーニングの実装にはPythonが主に使われています。

Rustでのディープラーニングの実装が一般的になるかどうかは、今後のRustコミュニティの活動やディープラーニングの研究動向によるところが大きいでしょう。

**デフォルトの名無しさん** · 2024/06/28(金) 02:47:01.21

>>435
さっそくの返信ありがとうございます

> 今後のRustコミュニティの活動やディープラーニングの研究動向

がどうなってるかを聞きたかったんですがどんな感じですか?
libtorchバインディングのtorch-rsや
ほぼ純Rust製のcandleが出てきたのはわかったんですが
まだ周辺ライブラリが足りない感じです?

**デフォルトの名無しさん** · 2024/06/28(金) 03:31:36.21

少なくとも俺よりはAIの方が物知りだから自分でAIに聞いた方がいいと思う

警備員[Lv.22] · 2024/06/28(金) 03:44:03.44

論文の検証を論文と異なる言語ではしないでしょぅ
NCNNやDarkNetを超えるエンジンがあるわけではなし

**デフォルトの名無しさん** · 2024/06/28(金) 05:55:26.25

>>417
関数の引数にオブジェクト（Copy型でない型）を渡す際は参照渡しが基本で、
うっかり所有物を引数として渡すと所有権ごと関数の向こうへ移動してしまって二度と戻って来ない
これは逆に、関数が何らかの実体を返り値として返す際には便利

とまあネチネチ考えてればわかってくるもんだよ

**デフォルトの名無しさん** · 2024/06/28(金) 07:54:27.71

>>422
unsafeを無視しちゃいかんよ。

**デフォルトの名無しさん** · 2024/06/28(金) 09:41:44.10

型がガチガチの言語でdeepnetの実装するのは面倒な割に生産性薄いわ

**デフォルトの名無しさん** · 2024/06/28(金) 09:45:48.57

仕組みがまだ確立してなくて試行錯誤があるなら型で制約しまくるのは面倒なだけだけどもうそういう段階じゃないのなら型で固めたほうが (使い方の間違いが検出されやすいので) 生産性高いよ。

**デフォルトの名無しさん** · 2024/06/28(金) 12:27:02.70

>>441
C++/C#/Javaとの比較はともかく、LLとの比較は目指すところが違うでしょ。
Rustは組み込みやOSまでカバーする言語。

医療用機器とか、自動車とか、命に関わるような分野でバグを入れないための言語なんだから。

金融も同じようなものだけど、そっちはOCamlの実績（みずほ）があるのでRustである必要は必ずしもは無い。

**デフォルトの名無しさん** · 2024/06/28(金) 13:07:10.53

LLとかいう死語を使ってるのは複オジだけだぞ

**デフォルトの名無しさん** · 2024/06/28(金) 13:32:56.61

>>441
ささっと数行書くスクリプトでなければ静的型付け言語が生産性高いよ

**デフォルトの名無しさん** · 2024/06/28(金) 17:07:56.21

うい。４０のおっさんよん(^_-)

まあ、プロトタイプは動的型言語で作って、本番のコードは静的型言語で作るなんて常識なんだから、若い人じゃなければ

> 型がガチガチの言語でdeepnetの実装するのは面倒な割に生産性薄いわ

何てこと書かないわな…。

**デフォルトの名無しさん** · 2024/06/28(金) 18:51:50.94

今のご時世にプロトタイプは動的言語とか言ってるのは頭の硬いジジイか、ジジイの本でしか勉強出来ない馬鹿がほとんどなんだよなあ

**デフォルトの名無しさん** · 2024/06/28(金) 19:09:29.56

出来る人ならそれで良いし、それで>>441の言うように生産性が低いと感じないなら全然かまわない。

馬鹿馬鹿言うけど、そういう馬鹿にも作らせないといけないし、それでも作れない救えない奴はリストラするしか道が無い。

**デフォルトの名無しさん** · 2024/06/28(金) 19:58:03.61

動的型でプロトは結局本番で書き直す時間など取れないから机上の空論ってのが最近の認識では
最初から静的型にするか、どうしようもなくなるまで動的型で耐えるかの2択じゃないかな
まぁたいていのスタートアップは耐えられなくなる前に潰れるからそれを見越して動的型というのはありだと思うが

**デフォルトの名無しさん** · 2024/06/28(金) 20:05:28.17

スタートアップ企業であろうと
動的型付け言語を使うのは開発効率が悪い

**デフォルトの名無しさん** · 2024/06/28(金) 20:36:15.04

んー…。
おっさん的には関数単位でテスト出来るかどうかが問題であって、プロトタイプは動的か静的かの問題じゃない気がするな。

最近は静的型言語でもインタラクティブシェル（略語忘れた)のインタプリタで関数単位でプロトタイプ作ってテストして、上手くいけばビルドって流れだし。

そういうのが無い言語は今でもプロトタイプは動的言語で作って…ないわｗ

場合によるな。
すでに作り方を知ってたらいきなり静的型言語で書くし、何か思いついたけど確信が持てない。みたいな時(試行錯誤が予想される)は動的型言語でプロトタイプ書いてるかな。
(静的型言語にインタラクティブシェルが無い時)