X



Rust part23

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
垢版 |
2024/02/23(金) 17:37:52.13ID:CheDQupm
公式
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 part22
https://mevius.5ch.net/test/read.cgi/tech/1705760500/

ワッチョイスレ
プログラミング言語 Rust 4【ワッチョイ】
https://mevius.2ch.net/test/read.cgi/tech/1514107621/
0527デフォルトの名無しさん
垢版 |
2024/04/02(火) 23:57:17.27ID:ULMcj34Q
外部のお墨付きを欲しがる時点でオワっとるんよ
言語として
ここでそういう話題使って必死で盛り上げようとして
消えそうな火に風送ってるつもりかしらんけど
0528デフォルトの名無しさん
垢版 |
2024/04/03(水) 00:07:33.86ID:xB8sPKZQ
IT大手ライバル同士が
GAFAMからHUAWEIまで一致団結して
Rust Foundationを設立した時点で未来は確定していた
そしてRustに対抗できるライバル言語の芽が今も存在しない
0530デフォルトの名無しさん
垢版 |
2024/04/03(水) 07:36:47.52ID:ClJR5oeK
Rustの代替になる思想の言語が全くそれ以降全く見ないからな。
今のところGCレスでメモリ安全に向き合った唯一の言語でねえの?

後発の言語は Rust みたいに複雑なコンパイル時の検証を最初から書こうなんてそうそう思えないんじゃないかな。
0531デフォルトの名無しさん
垢版 |
2024/04/03(水) 08:17:45.92ID:OgaFV8I4
>>527
欲しがってるかね?
むしろ外部が乗っかろうとしてる感じ。
0532デフォルトの名無しさん
垢版 |
2024/04/03(水) 08:58:53.93ID:7dkIXzmY
>>530
メモリ安全に向き合う、程度ならそれこそc++11が先駆けだろ。
過去互換性のせいで徹底できないけど。

それよりもRustはスタックフレーム指向であることに価値がある。
スタック is god, 再帰 is god.
0533デフォルトの名無しさん
垢版 |
2024/04/03(水) 11:38:42.38ID:TbyA9/um
>>515
まあ標準ライブラリがかなりミニマムだなぁって感じるときはある
乱数くらい用意しておいてよ…
0534デフォルトの名無しさん
垢版 |
2024/04/03(水) 11:38:56.67ID:zWYr6uc2
>>530
ある言語Aがあってその弱点が強烈で直したいけどすでに普及しきっている
で別の言語Bが作られる

その言語Bが普及しきっていなければ容易に弱点を変更できるので別のC言語は必要とされない
0535デフォルトの名無しさん
垢版 |
2024/04/03(水) 13:08:37.11ID:VOIzFFgw
>>534
>その言語Bが普及しきっていなければ容易に弱点を変更できる
これが真とは限らない
容易に変更できる場合もあればそうでない場合もある
0536デフォルトの名無しさん
垢版 |
2024/04/03(水) 13:33:20.93ID:7LWlVk3J
Rustで過去に結構破壊的変更がされてたらしいけどそれは普及してなかったからじゃないのか

wikipedia
> 2015年に1.0版がリリースされるまでにいくつもの破壊的な仕様変更があったが、1.0版以降は基本的には後方互換を保って6週間間隔で定期的にリリースされている。
0537デフォルトの名無しさん
垢版 |
2024/04/03(水) 21:45:24.20ID:ClJR5oeK
GCやJITは銀の弾丸と思われていろんな後発言語に取り込まれたけど、所有権は最初から組み込むには高度すぎるがエコシステム成熟前に組み込まないといけないという制約が大きいんだろうな。
0539デフォルトの名無しさん
垢版 |
2024/04/04(木) 03:50:23.61ID:6dtGhNgR
>>537
所有権は最終的にはプログラム間の境界の問題になるから、c++のスマートポインタのようにアダプタで管理範囲を調整することで改善可能。
適切なアダプタを用意しても境界のプロトコルをどうやって徹底するかという問題は残るから、Rustみたいに言語レベルで強制できると頑強になる。

ただ、Rustみたいにガチガチにすると設計の柔軟性を失うから、実装も早すぎる最適化になりがち。Rustの絶壁の学習曲線と相まって、開発初期のRust導入はプロジェクトを破綻させる要因となりうる。Rustが適しているのは、ある程度枯れた設計の実装を置き換えるようなプロジェクトかと。
0540デフォルトの名無しさん
垢版 |
2024/04/04(木) 04:13:47.93ID:KZy/sIny
Rustはむしろリファクタリングにも向いていてなかなか良い言語だぜ
とりあえず動くように雑に書いて動かしてみて
次に機能追加充実させる上で整理しながらモジュール化や共通事項のtrait化など

このようなリファクタリング過程で
他の言語だとメモリ安全性だけでなく書き換え競合やヌル値エラー値取り扱いミスなどエンバグすることも多いが
Rustではコンパイル通せばそれらの心配がなくリファクタリングできる
0541デフォルトの名無しさん
垢版 |
2024/04/04(木) 08:02:04.20ID:KuogGH/c
そもそもGC無しの言語ってニッチじゃない?
当面は、Rustで充足されて安泰な気がする。
0542デフォルトの名無しさん
垢版 |
2024/04/04(木) 08:06:01.77ID:wZ/e8tnl
うむり、実用言語では現時点で安全性とスピードを高い次元で両立できてるのはRustだけかもね。
関数型言語にも良いのあるけど、普及しなさそうだしね…。
(OCamlとか次世代HaskellらしいIdrisとか)

それにCとアセンブラしかない分野(C++不可なくらい低スペックな組み込み)でC++以降のモダンな言語が使えるのは大きい。
0543デフォルトの名無しさん
垢版 |
2024/04/04(木) 08:41:03.15ID:VIrJEXhK
学問的には合理的な型システムとか検証器とかの研究は大きく進んでるけど
メモリの動作モデルをそこそこちゃんと仕様にしてるのは C/C++ しかないんだよね。
LLVM が C/C++ を前提にしてるところもあるし、
Rust もそれに合わせる形になってるところもある。

C/C++ 的な分野をよりよくやる言語と考えると Rust はとても良い。
0544デフォルトの名無しさん
垢版 |
2024/04/04(木) 12:25:37.65ID:Gnl54rZ8
すまんが↓これが動く理由を教えて欲しいんだけどさあ
https://paiza.io/projects/uhC43ajorg-qaLG7mXbw7w
一見すると5行目で所有権が失われて、6行目で使ってるように見えるんだけど・・・・
これって5行目が借用に推定されてるの?
それともリテラルを引数にした場合だと5行目で「1」が他のスタックにコピーされて、所有権が失われる問題なんか起きないのかな?

へるぷみい
0545デフォルトの名無しさん
垢版 |
2024/04/04(木) 12:36:31.67ID:xh1kANkn
マクロだからセーフ
0547デフォルトの名無しさん
垢版 |
2024/04/04(木) 12:49:08.15ID:w8P1RFve
値が複製されて、複製された値の所有権が関数fに渡るだな。

所有権の複製とかいうクソワードは避けてくれ。
0548デフォルトの名無しさん
垢版 |
2024/04/04(木) 14:09:00.66ID:VIrJEXhK
>>544
i32 は Copy トレイトが実装されてる。
普通なら所有権の移動になる文脈で暗黙に clone されると思ったら良い。
0549デフォルトの名無しさん
垢版 |
2024/04/04(木) 14:21:30.05ID:Gnl54rZ8
そう言うことなのか、ありがとう!
理由が分からなかったから不気味だったぜ
0550デフォルトの名無しさん
垢版 |
2024/04/04(木) 15:21:14.87ID:AF0jRQyM
>>547
>値が複製されて、複製された値の所有権が関数fに渡るだな。
複製された値の所有権は最初から関数fのスコープの中で発生するものなので
「関数f」に渡るという表現には少し違和感を感じる
0551デフォルトの名無しさん
垢版 |
2024/04/04(木) 15:34:13.46ID:1vyOHDUL
「違和感を感じる」という表現に違和感を感じる
0553デフォルトの名無しさん
垢版 |
2024/04/04(木) 19:04:00.82ID:mNkWQBjH
感じてるから違和「感」だからね

要は頭痛が痛いと同じ
0554デフォルトの名無しさん
垢版 |
2024/04/04(木) 19:08:09.03ID:v0TcrcAn
違和感がある。これでどうだ
0559デフォルトの名無しさん
垢版 |
2024/04/05(金) 00:09:35.95ID:Lw8p7kTG
>>556
少ないね。
でも、そもそも今までCとアセンブラ以外はほぼ無い状態だったから、出てきただけマシ。

それに、少ないといってもシェアが広いアーキなので滑り出しは順調と言えるのかと。
0561デフォルトの名無しさん
垢版 |
2024/04/05(金) 00:50:16.55ID:Lw8p7kTG
少し前まで次世代言語と言われてた程度には後発。

鯖向け言語で終わると思ってたら、マジでC/アセンブラの牙城を崩し始めるとは思わんかった。
むしろ崩し始めることすら無理だと思ってた。
0562デフォルトの名無しさん
垢版 |
2024/04/05(金) 05:07:52.53ID:CPVE6BHF
>>559
状況も追い風なのかもね。
二の足踏んでたけど、armと生きていく決心をしてrust覚えるか。

先にrust身に付けてから、非対応アーキでC++導入したらメリットあるかな?
0563デフォルトの名無しさん
垢版 |
2024/04/05(金) 08:11:28.72ID:Lw8p7kTG
Rust知ってれば安全性の高いシステム組めますと言うアピールになるし、C++にもその安全性のための知見は役立つ。
複数言語使えますってだけでもアピールになるしね。

Rustは多分仕事自体はまだ多くない。
これからアピールして増やしていく感じなので、両方使えてた方がいい。
0564デフォルトの名無しさん
垢版 |
2024/04/06(土) 22:48:03.64ID:4i1Gvjc8
rustというものがありながらなぜ大部分のコードはC言語なのかを知るために現場に行くのもアリ
0566デフォルトの名無しさん
垢版 |
2024/04/07(日) 01:26:10.29ID:Hmt7T+4v
Rustへの移行は始まったばかりだからまだまだCが残っているのは当たり前
0567デフォルトの名無しさん
垢版 |
2024/04/07(日) 10:55:29.15ID:QD1FKAnH
絶壁の学習曲線。
貧弱なライブラリと人材。
早すぎる最適化。

しばらくは既存コード置き換えが中心だし、今後もプロジェクト初期のプロトタイピングで使われることは無いだろう。
0568デフォルトの名無しさん
垢版 |
2024/04/07(日) 14:17:46.28ID:vzw88H1n
P系言語の糞思考に染まっていない初心者こそ
最初にRustを学ぶべき
0571デフォルトの名無しさん
垢版 |
2024/04/07(日) 18:09:00.76ID:Sj2oLPpI
>>567
移植なんて無駄な作業はどの言語間でも行われることが少なく
通常はシステム更新で全体もしくは一部が作り直される時に別の言語が使われる
Rustでも同様でほとんどがそれら含む新たな案件
0572デフォルトの名無しさん
垢版 |
2024/04/07(日) 18:16:09.73ID:TV6Dkj8m
>>567
早すぎる最適化という意味不明なデタラメ書いているのは君一人だけ
そしてRustを叩きたいためにウソを散りばめる
0573デフォルトの名無しさん
垢版 |
2024/04/08(月) 02:24:45.08ID:BHlkyWwA
>>567
貧弱なライブラリとかエアプかよ
そしてRustを叩きたいためにウソを散りばめる
0575デフォルトの名無しさん
垢版 |
2024/04/08(月) 11:48:22.86ID:hzcejt90
ライブラリはPythonと比べると流石に貧弱
特に数値計算とか物理・機械学習系

簡単な数値計算の時点でnumpy•scipyのようなデファクトがなく、雑魚が乱立している
もっと高度な計算系ではもっと雑魚が乱立しているか、そもそもない
0576デフォルトの名無しさん
垢版 |
2024/04/08(月) 12:32:47.46ID:64QjhTLf
>>575
キチガイアンチ
すべての分野でライブラリが充実している言語は存在しない
ある分野で一番充実している言語を棍棒にしたら他のすべての言語が負けるのは当たり前
そういう無意味なことをして叩いて楽しいか?
0577デフォルトの名無しさん
垢版 |
2024/04/08(月) 13:16:14.61ID:JoalanBl
>>576
貧弱なことを指摘するのは叩きではない
俺はただ、「貧弱なライブラリとかエアプかよ」とか言っているエアプに現実を指摘しただけだ
0578デフォルトの名無しさん
垢版 |
2024/04/08(月) 14:02:16.22ID:7wfBslr8
>>576
そこは「Rustなら〇〇分野のライブラリがどの他言語より充実している」と反論するところだろ。
0579デフォルトの名無しさん
垢版 |
2024/04/08(月) 14:10:54.87ID:7wfBslr8
>>570
絶壁の学習曲線だから無理だろ。

moveを意識しないshared xor mutableの無い、Rc中心のEasyRustとかが無いと、fnひとつ呼び出せないんじゃない?
0581デフォルトの名無しさん
垢版 |
2024/04/08(月) 15:06:06.34ID:rjHvzTUw
ライブラリの多さってイコールでユーザの多さなんだよ
更にいうとその言語開発者の意欲の表れでもある

ライブラリが少ないという事はユーザが少ない
更に少ないユーザの中でも意欲の有る人間は少数って証明なんだよね
0582デフォルトの名無しさん
垢版 |
2024/04/08(月) 15:43:54.88ID:JoalanBl
いやまあ数はあるんよ数は
意欲のある人はいるっぽいんだけど、デファクトとるようなライブラリってやっぱりそれなりの人数でちゃんと資金とって作られてるんだよな
資金取るのは個人の意欲だけじゃなくて、お金のある人を納得させる理屈が必要で、少し前までのRustは少なくとも数値計算の分野でそれが出来る言語ではなかったと思う
0583デフォルトの名無しさん
垢版 |
2024/04/08(月) 16:39:42.51ID:9qnuy4NE
てかrustユーザーってnvidiaのcudaサポートの酷さにガチギレするような奴ばっかでしょ。
そんなんで数値計算ライブラリが入るわけがない。
0584デフォルトの名無しさん
垢版 |
2024/04/08(月) 17:11:27.78ID:7wfBslr8
初心者向けのSimplified Rustと、
c/c++ライブラリバインドを強化したAdaptor Rustあたりは欲しいなぁ。
Safe Rustじゃ難しそうだし。
0585デフォルトの名無しさん
垢版 |
2024/04/08(月) 17:54:43.90ID:JoalanBl
ゼロからプログラム書くならSafe rustが一番簡単だよ
こいつに従っているだけで割と見通しが良くてバグりにくいコードが書ける

まあGoto 多用しているようなFortran おじいちゃんとは相性が悪いかもしれんが
0587デフォルトの名無しさん
垢版 |
2024/04/08(月) 20:39:36.28ID:cqL1RV99
C++を使ったことないけど
Rustで困ったことないな
Rust理解で必要なことはポインタとスタックとヒープとRAIIくらいかな

所有権は単なるヒープ解放責任だから大したことではない
所有権を他へ譲渡しないとRAIIによって自動解放されるというだけの話
非常にシンプル
0589デフォルトの名無しさん
垢版 |
2024/04/09(火) 00:09:53.71ID:pItuq1gX
>>588
それは俺じゃないぞ
0596デフォルトの名無しさん
垢版 |
2024/04/10(水) 01:14:02.81ID:/k7xUJZy
rustだいぶ分かってきたつもりだけど
ライフタイムとジェネリクスとクロージャが一斉に襲いかかってくると無理
好きな言語だけど世の中にはプログラミング言語に強い興味を示す奴が稀なので厳しいなぁと感じる
0599デフォルトの名無しさん
垢版 |
2024/04/10(水) 11:35:35.51ID:AS+TZoYk
>>596
それぞれ理解していれば組み合わさって困ることはないんじゃないかな
Rust特有のライフタイム注釈は構造体なら「参照を持ってるよ」の印で関数なら「この引数の参照は返り値の参照に対応するよ」の印であとは有効期間を満たすだけなど
0600デフォルトの名無しさん
垢版 |
2024/04/10(水) 16:55:22.63ID:yZA7mDLP
Rustってfunctionをfnって略すくらい気が短いのに、なんでメソッド定義時にはわざわざselfみたいなPython臭いの入力しないとだめなんですか?めんどいんですけど
0601デフォルトの名無しさん
垢版 |
2024/04/10(水) 17:30:31.18ID:Fk7YBwaR
メソッドをそうでない普通の関数と区別するためにはなんらかのマークは要るじゃろ。
0602デフォルトの名無しさん
垢版 |
2024/04/10(水) 17:38:51.91ID:t7JkSWKp
self/ mut self/&self/&mut selfの区別もいるしな
self自体これ以上短くしてもよくわからん単語になるしまぁ妥当では
0603デフォルトの名無しさん
垢版 |
2024/04/10(水) 17:52:25.08ID:5Js//1cu
C++ の ref-qualifier とか無理のある文法だもんな。
そこに書くんか!? という変な驚きがある。
引数の一種ということにしたほうがかなり単純でよい。
実際、 C++ でも C++23 から this を明示的な引数に取れる文法が追加された。 (deducing this)
0604デフォルトの名無しさん
垢版 |
2024/04/10(水) 17:58:48.34ID:Q64PiueS
RustでPython実装すりゃ良いんじゃね
0605デフォルトの名無しさん
垢版 |
2024/04/10(水) 18:34:01.75ID:3h5gXXiJ
>>602
普通に全部ダサいんだよなあ
何とかならなかったのかとならなかったのかとならなかったのかと…
0606デフォルトの名無しさん
垢版 |
2024/04/10(水) 19:34:40.80ID:8DE+tVvz
selfより短ければ良いのか、それともC++みたいに省略できてしまってどこで定義されてるのかようわからんくなるのが好きなのか
0607デフォルトの名無しさん
垢版 |
2024/04/10(水) 19:44:04.66ID:y0DX5npz
ぜひとも >>605 の考える最高にイケてる構文を教えてほしい
Rustを今から変えるのは無理でも、後継言語に採用されるかもしれんし
0608デフォルトの名無しさん
垢版 |
2024/04/10(水) 19:47:55.68ID:IjfZ+vUr
>>605
nimの関数呼び出しルール
関数名(第一引数,第二引数...)
第一引数.関数名(第二引数...)
で第一引数がself相当
が一番スマートかと。
0609デフォルトの名無しさん
垢版 |
2024/04/10(水) 20:06:03.20ID:AS+TZoYk
>>605
むしろ>>602はそれらの区別のためにもselfは必須と言ってるようにみえる
さらに構造体などフィールド名と関数内の変数名との区別のためにもselfは欲しい
現状のRustの仕様がベストかな
0610デフォルトの名無しさん
垢版 |
2024/04/10(水) 21:28:15.02ID:8DE+tVvz
selfじゃくてthisならC++マニアも納得
0611デフォルトの名無しさん
垢版 |
2024/04/10(水) 21:34:35.54ID:6SjCdg5T
>>608
nimを知らないけど、Rustのassociated functionもその二種類の呼び出し方法がとれる点は同じだね

Vec::push(&mut vec, 123);
(&mut vec).push(123);
vec.push(123);

この&mutを省略できてRust便利
0613デフォルトの名無しさん
垢版 |
2024/04/10(水) 23:19:28.12ID:AS+TZoYk
deref後のinto_inner適用と区別のため
敢えてself使わないことでメソッド呼び出し形式をできなくして
明示的にRc::into_inner呼び出しさせるパターンだね
0614デフォルトの名無しさん
垢版 |
2024/04/10(水) 23:45:41.84ID:Fk7YBwaR
メソッドを呼び出すことと関数の第一引数に渡すことを同一視する構文は
LISP 用に作られたオブジェクトシステム new flavors でやってた。
0616デフォルトの名無しさん
垢版 |
2024/04/11(木) 02:14:15.06ID:7FNbL3Xb
呼び出し時には与えない引数って紛らわしくね?
0617614
垢版 |
2024/04/11(木) 02:45:03.24ID:C4qhk0zm
>>615
メッセージを送る構文と関数呼出しの構文の両方があって構文糖として扱える仕組みになってたという話。
new flavors の前に flavors というのがあって、それはメッセージを送る構文しかなかったのだけど
new flavors で改良 (かどうかわからんけど) された。
0618デフォルトの名無しさん
垢版 |
2024/04/11(木) 04:57:52.23ID:r6y9Ju0a
>>616
むしろ逆かな
target.method(arg1, arg2, ...)という
targetへのメソッドコールを実現するのを関数で表すと
method(target, arg1, arg2, ...)とする言語が多い

Rustでも同じでこのtargetをselfと書く
targetは送る側から見た視点
selfは受け取った側から見た視点
各実装は受け取った側でなされるためself
0619デフォルトの名無しさん
垢版 |
2024/04/11(木) 08:24:38.80ID:McLA6Ner
UFCSは第一引数を1つ目だからというだけの理由で特別扱いするのが気持ち悪いんだよな
レシーバとして扱われるなら構文上も特別であってほしい
0620デフォルトの名無しさん
垢版 |
2024/04/11(木) 08:39:59.21ID:UjbgXeUt
>>619
何が気持ち悪いのかさっぱりわからない
まず、全ては関数呼び出しになりそれ以外の方法はない、というのはいいよね?
次に、その関数呼び出しでのレシーバの渡し方は最初の引数になる、というのも自然だよね?
ほとんどの言語がこの方式なのに何を気持ち悪がっているのだろう
0621デフォルトの名無しさん
垢版 |
2024/04/11(木) 08:49:57.16ID:azFLg2co
言うほどほとんどの言語がこれか?
pythonは後付けでOOPぶっこんだからただの関数の引数にSelfなんだ
これがPythonいまいちだなって思うところ
c++も似た様な理由でstaticでthis

後発で考慮する余裕あるのにそれを引っ張ってる
0622デフォルトの名無しさん
垢版 |
2024/04/11(木) 09:02:17.34ID:NXydgA7G
>>621
君の感性がおかしいんじゃね?
NimもZigもRustもPythonと同じ標準方式
foo(receiver, arg1, arg2, ..)
または
receiver.foo(arg1, arg2, ..)
■ このスレッドは過去ログ倉庫に格納されています