Rust part9

**デフォルトの名無しさん** · 2020/08/23(日) 01:07:35.52

Mozilla発のRust言語のスレ

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

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

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

**デフォルトの名無しさん** · 2021/01/13(水) 08:49:31.39

自分で使う、as_str
ライブラリとして他で使われる、AsRef

**デフォルトの名無しさん** · 2021/01/13(水) 09:22:05.24

>>580
学習難度はまず低級言語と高級言語両方の利点欠点を理解しないと良さが理解出来ないからねえ…
設計思想からして中上級者向けだから仕方ないかも

**デフォルトの名無しさん** · 2021/01/13(水) 10:55:46.25

単に学習難易度が高いだけでなく、学習が済んだ後もこの言語はめんどくさいが、
C++よりもむしろ。

**デフォルトの名無しさん** · 2021/01/13(水) 12:45:22.11

>>582
AsRefはIntoOwnedと対になっていて str<->String Path<->PathBuf みたいな ref/owned 関係にあるもの同士の変換に使うものだと思う
enum -> &str はそういう関係にはないので微妙に思う

**デフォルトの名無しさん** · 2021/01/13(水) 13:36:01.48

>>586
風俗で事が済んだ後で説教始めるオッサンみたい

**デフォルトの名無しさん** · 2021/01/13(水) 13:53:35.67

C++とRustで難しさめんどくささの方向性違うしな
好みの範疇だと思ってる

**デフォルトの名無しさん** · 2021/01/13(水) 21:18:34.66

Rustのめんどくさいところはダントツでクレート関係だよな
標準で入ってないかつ、細かすぎるからコンパイル糞長いし、APIの仕様が統一されてないからドキュメント見ないと話にならんとこ
しかもクレートによっちゃライフタイム絡ませてきてめちゃくちゃになるし
C++はとにかく言語仕様のいらない豊富さが嫌気さす

**デフォルトの名無しさん** · 2021/01/13(水) 21:41:40.93

D言語かDelphiやれ

**デフォルトの名無しさん** · 2021/01/13(水) 23:05:33.49

もう.net5とC#でいいやん

**デフォルトの名無しさん** · 2021/01/14(木) 01:15:26.66

>>590
traitのおかげで他と比べるとAPIの統一性は達成されてるようにおもう

**デフォルトの名無しさん** · 2021/01/14(木) 01:57:39.37

クレートいいと思うけどな
標準ライブラリに入れると破壊的変更できなくなるけどクレートなら古いバージョン使うことも出来るから
気兼ねなくライブラリを進化させることが出来る

**デフォルトの名無しさん** · 2021/01/14(木) 08:51:13.78

pure-Rustのクレートなら今のところ確実にコンパイルは通るしな。
C++だとGitHubから拾ってきたライブラリが手元でコンパイル通るかどうか半々って感じで厳しい。
マイナーなディストリビューションのせいではあるけど、全部Ubuntuに統一というわけにもいかんしなぁ。

**デフォルトの名無しさん** · 2021/01/15(金) 20:23:33.58

struct A;
struct A();
これとこれが定義できる理由ってなんかある?

struct A {};
だけで済むし、記述バラバラになるから統一したいんだけど

**デフォルトの名無しさん** · 2021/01/16(土) 00:28:37.68

Rustが一番めんどくさいのはメモリ管理だな。
というよりメモリ管理の事ばかり気にしてプログラムしなくてはならない。
plain CやC++ではそこまで気にしなくて良い。

**デフォルトの名無しさん** · 2021/01/16(土) 01:28:58.93

？？？？？？？？？

**デフォルトの名無しさん** · 2021/01/16(土) 11:40:00.74

いつものやつだ気にするな

**デフォルトの名無しさん** · 2021/01/16(土) 14:07:27.84

結局メモリを気にする言語にへんな暗黙性を入れるのは失敗ってことだな。

**デフォルトの名無しさん** · 2021/01/21(木) 02:51:30.26

Rust で書いたツールにドキュメントを付けようとしています。
ライブラリのドキュメントではなくツールとしての使い方の詳細で、
readme に書くには大きすぎるような文章です。

cargo.toml では package.documentation でドキュメントの場所を URL で
示すことは出来るようですが、パッケージ内にドキュメントを一緒に入れておいて
cargo install で適当なところにインストールするようなことは出来ないのでしょうか？

あるいは cargo の直接の管理下には入れられないにしても
なんらかの習慣があったりしますか？

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

ゴミ言語

**デフォルトの名無しさん** · 2021/01/21(木) 14:31:58.28

manみたいにドキュメントインストールする方法は知らないな。
ローカルにインストールしなくてもリポジトリのwikiあたりに使い方書いておいてそれ見てねでいいんじゃないかとおもうけど。

**デフォルトの名無しさん** · 2021/01/21(木) 21:40:35.33

ビルドスクリプト使ってenv::var("OUT_DIR”)で取得できるパスにファイル出力してるのが多いみたい

**601** · 2021/01/21(木) 22:18:23.22

なるほど。そういうやり方もあるんですね。
でもドキュメントを各環境で適切な場所に
インストールするのは結局は手作業ということになりそうですね。

そういうことなら無理に自動化するのは諦めて
必要ならこのディレクトリで mdbook コマンドを実行してねみたいな感じにした方がかえって楽かな……

**デフォルトの名無しさん** · 2021/01/21(木) 22:42:45.36

cargo installでrustバイナリ以外をインストールするオフィシャルの方法は長年用意されてないから別の手段で頑張るしかない
https://github.com/rust-lang/cargo/issues/2729

**デフォルトの名無しさん** · 2021/01/24(日) 00:35:05.68

fn num() -> usize {
10.pow(9)
}
この定数はなぜ推論でusizeにならないんですか？

**デフォルトの名無しさん** · 2021/01/24(日) 19:33:54.83

もういい加減にしてクレート

**デフォルトの名無しさん** · 2021/02/03(水) 05:50:55.51

なんでいちいちゴミをワサワサDLしなきゃならねーんだよゴミ言語

**デフォルトの名無しさん** · 2021/02/03(水) 21:58:38.43

どしたのわさわさ

**デフォルトの名無しさん** · 2021/02/03(水) 22:30:52.82

DustじゃなくRustだからゴミじゃなくてサビ言語だよ

**デフォルトの名無しさん** · 2021/02/04(木) 19:02:46.18

&strってなんで&Stringじゃないの？

**デフォルトの名無しさん** · 2021/02/04(木) 20:19:37.24

その2つは別のもの
どっちも存在する

&strはstring sliceのborrow
&StringはStringのborrow

**デフォルトの名無しさん** · 2021/02/04(木) 20:39:25.16

>>613
同一だと思ってたけど違うの？？

&strを要求する関数とかメソッドに&String渡しても動くもんだからてっきり

**デフォルトの名無しさん** · 2021/02/04(木) 20:54:06.40

それはDerefの効能

**デフォルトの名無しさん** · 2021/02/04(木) 21:06:19.09

&strはStringの一部か全部へ参照 rust的にはスライスへの参照
&string[1..3] こういうこと

引数を&StringにするのStringの参照しか渡せないが、&strにすればStringの一部や””で囲った&strも渡せる

**デフォルトの名無しさん** · 2021/02/05(金) 01:36:04.17

>>614
引数として&strをとるメソッドや関数に&Stringは渡せないんじゃなかったっけ
self の場合の話？

**デフォルトの名無しさん** · 2021/02/05(金) 01:46:13.57

>>617
StringはDeref<Target=str>を実装してるから&strをとる関数に&String渡せる
https://doc.rust-lang.org/std/string/struct.String.html#deref

**デフォルトの名無しさん** · 2021/02/05(金) 13:26:40.93

こういう暗黙変換て混乱を生むだけだと思う。

**デフォルトの名無しさん** · 2021/02/05(金) 15:35:15.48

>>618
二つ目の例だけ記憶してて勘違いしてたみたい。ありがとう

>>619
rustは暗黙変換かなり少ないからマシな方だと思う
メソッドのselfの暗黙変換はないとつらいかと

**デフォルトの名無しさん** · 2021/02/06(土) 16:00:13.52

Option::filterのResult版って無いのかな？

**デフォルトの名無しさん** · 2021/02/06(土) 20:10:46.18

>>621
条件に合致しない場合は何を返して欲しいの？

**デフォルトの名無しさん** · 2021/02/06(土) 21:49:40.07

>>621
and_thenでErr返せば？

**デフォルトの名無しさん** · 2021/02/06(土) 21:55:40.99

>>622
引数で渡したエラー値をErrにくるんで返してほしい

**621** · 2021/02/07(日) 10:23:42.94

>>623
うん、それが最適でしたね

もともとTと&T -> boolからOption<T>を構築してたコードがあってSome(t).filter(|t| !t.is_hoge())ってしてたんだけど
それをResultに変えようとしたらif式で数行増えちゃって
ちょうど対応するようなのって無いのかな？って思って質問した次第でした

**デフォルトの名無しさん** · 2021/02/07(日) 11:40:55.51

それはok_orかok_or_elseで変換すればいいだけじゃなくて？

**デフォルトの名無しさん** · 2021/02/08(月) 19:14:38.32

Rustの良さが実感できるのは長大なコードをチーム開発するときなのかな

小さいプロジェクトならRustは
・生ポインタ使わない
・できる限りSTLを使う
・const、moveをデフォルトで使う
ことにしたC++に敵わないような
C++の方が柔軟だしず～っと短く書けるし

**デフォルトの名無しさん** · 2021/02/08(月) 19:48:24.23

あ、標準の機能とかイディオムを巧みに使えばC++並みに短く書けるよ、というのがあったら教えてください

**デフォルトの名無しさん** · 2021/02/08(月) 20:52:33.63

どちらかというとC++の方が長くない？
ヘッダとソースの重複とかイテレータが冗長とかshared_ptrが長いとか。
あと小さいプロジェクトだとビルド環境構築の手間が
相対的に大きくなるからC++はつらいな。

**デフォルトの名無しさん** · 2021/02/08(月) 20:54:12.55

あとなるべくconstにしたいのに多用すると結構長い

**デフォルトの名無しさん** · 2021/02/08(月) 21:36:53.51

RustスレなのでRustの味方をすれば良いと思うが、>>629はあまりにも言いがかりだろう

> ヘッダとソースの重複
重複するコードを書かなければならないことなどない

> イテレータが冗長
今どきautoせずにイテレータを書くことはない

> shared_ptrが長いとか
これは確かに

**デフォルトの名無しさん** · 2021/02/08(月) 22:14:40.49

>>631
テンプレートでなければ関数プロトタイプと実装で同じこと書くと思うんだけど最近は違うんだっけ？
あとイテレータはbegin/endのこと。これも書かなくて良くなったりしてる？

**デフォルトの名無しさん** · 2021/02/08(月) 22:48:07.53

>>632
特殊化が必要なら当然特殊化するし、プロトタイプしか与えられてない関数は当然中身を他の場所で実装しなければならない
が、いずれもヘッダその他で書いてあるのと同じことを繰り返し書くという意味ではない
「引数と返り値をプロトタイプと実装で二度書くじゃないか」と主張してるのか？
だとしたら、「Rustのtraitとimplは同じことの繰り返しだ」と同レベルのデタラメだ

> あとイテレータはbegin/endのこと
範囲for文はあるので、コンテナを走査する時にはbegin()もend()も書く必要はない
が、begin()やend()の指すイテレータが必要なら当然書く必要がある
しかしこれより簡潔な表現方法があるか？

**デフォルトの名無しさん** · 2021/02/08(月) 22:59:07.96

>>633
いや、Rustのtraitとimplも同じことの繰り返しだと思うが。
もちろんそれぞれに意味があるのは分かるが、今話題になってるのは長いかどうかなので、単に長いのでは？ということ。
begin/endは言われてみれば確かにそんなに長くもないな。

**デフォルトの名無しさん** · 2021/02/08(月) 23:04:02.74

そういえばRustだとderiveで導出できるようなのを
手で書かないといけないのも面倒だと思ってたけど
それも最近のC++だと便利になってるのかな?

**デフォルトの名無しさん** · 2021/02/08(月) 23:09:22.70

>>634
～～～～～ッッ！！？！！？？？？
型を示すだけぞ？？？
どういう理屈で「どちらかというとC++の方が長い」？？？
「プロトタイプ」なる仕様が冗長だと思ってるということか？
だとしてもどこがどうRustより長い？
traitとimplが同じことの繰り返しに見えるなら尚更

**デフォルトの名無しさん** · 2021/02/08(月) 23:20:22.89

刃牙みてぇな驚き方

**デフォルトの名無しさん** · 2021/02/09(火) 00:25:25.36

>>636
気持ち悪いなお前……

**デフォルトの名無しさん** · 2021/02/09(火) 00:34:18.83

ゆうてID:tj1CufyMがもの知らん過ぎるよ
刃牙クンが正しい

**デフォルトの名無しさん** · 2021/02/09(火) 00:49:55.66

>>627 がどういうところでrustを冗長に感じたのかが分からないと身のある議論にならないのではないか

**デフォルトの名無しさん** · 2021/02/09(火) 01:06:11.87

let v2 = v.iter().take_while(pred).collect::<Vec<_>>();

auto iter_end = std::find_if_not(v.cbegin(), v.cend(), pred);
auto v2 = std::vector<Hoge>(v.cbegin(), iter_end);

**デフォルトの名無しさん** · 2021/02/09(火) 14:34:18.07

Rust言語を推進する「Rust Foundation」設立。AWS、Google、マイクロソフト、モジラ、ファーウェイらが設立メンバー
https://www.publickey1.jp/blog/21/rustrust_foundationawsgoogle.html

**デフォルトの名無しさん** · 2021/02/09(火) 15:30:38.01

>>642
>ファーウェイ
陰謀論者が発狂しそう

**デフォルトの名無しさん** · 2021/02/09(火) 15:37:53.29

ファーwww
ウェーイｗｗｗ

**デフォルトの名無しさん** · 2021/02/09(火) 15:48:29.20

>>642
GoogleもMSも節操ないな。

**デフォルトの名無しさん** · 2021/02/09(火) 16:43:44.21

非同期って結局のところtokio使えばいいの？

**デフォルトの名無しさん** · 2021/02/09(火) 17:12:10.08

>>646
無難なのは tokio だが、言語としては非同期ランタイムを固定しないという明確な指針がある以上は
使い分けしなさいということになると思う。

**デフォルトの名無しさん** · 2021/02/09(火) 18:32:36.30

traitとimplが同じことの繰り返しは流石にキテレツ過ぎてワロタ
こういう基本的な言語仕様も分かってない人にとってRust使うメリットってあるのかな

「どっちが短く書けるか」については、流石にC++じゃないかな
良くも悪くも自由だし、短さだけを追求したクソコードも作れる

一方でRustも一応エルゴノミクスを掲げてはいるし、冗長さは感じない
C++が短くでき過ぎる、って言い方が正しいとおも

**デフォルトの名無しさん** · 2021/02/09(火) 19:12:15.97

>>642
林檎やfacebookの参入、ゲームやスマホでの導入例が出てくればこれはかなりの地位を占めるな

**デフォルトの名無しさん** · 2021/02/09(火) 20:13:22.59

コードを短くできるなんてどうでもいいことに囚われて半端になってる印象。

**デフォルトの名無しさん** · 2021/02/09(火) 21:03:00.62

>>650
rustが？

**デフォルトの名無しさん** · 2021/02/09(火) 22:20:32.26

どうでもいいことか？

**デフォルトの名無しさん** · 2021/02/09(火) 23:19:34.12

程度問題

**デフォルトの名無しさん** · 2021/02/10(水) 00:30:31.60

具体的なコードの話も出さずに議論されても困る

**デフォルトの名無しさん** · 2021/02/10(水) 02:24:50.74

Firefoxでは160,000行のC ++コードを85,000行のRustコードに置き換えたと言ってる

**デフォルトの名無しさん** · 2021/02/10(水) 06:12:58.16

いやーRust難しくないっすか…
３回くらい入門したけどrustlingsのiterあたりでつらくなってくる
アホは他の優しい最新言語やったほうがいいんですかねぇ

**デフォルトの名無しさん** · 2021/02/10(水) 08:20:43.62

でもRustのコンパイル基盤のLLVMはいつまで経ってもC++製のまんまだよね
書き直さなきゃC++の牙城は壊せんで

**デフォルトの名無しさん** · 2021/02/10(水) 08:39:46.46

それAppleに言えよ…

**デフォルトの名無しさん** · 2021/02/10(水) 09:32:21.19

craneliftがあるじゃん
デバッグビルド向けだけど

**デフォルトの名無しさん** · 2021/02/10(水) 09:36:57.75

コンパイラはrust自身で作られてるからそのうちそうなるんじゃね？

**デフォルトの名無しさん** · 2021/02/10(水) 23:59:35.72

>>658
Appleは重要なパトロンではあるけど関心はApple以外誰も興味無い
キメラ言語のObjective-Cを守る一点だけだろ

**デフォルトの名無しさん** · 2021/02/11(木) 01:31:10.60

>>657
というかC++をちゃんと使いこなしている人は、Rustが便利だとは思えない人が多い
のでRust化する動機が無い。

**デフォルトの名無しさん** · 2021/02/11(木) 02:06:38.13

>>662
>>627てこと？

> 小さいプロジェクトならRustは
> ・生ポインタ使わない
> ・できる限りSTLを使う
> ・const、moveをデフォルトで使う
> ことにしたC++に敵わないような
> C++の方が柔軟だしず～っと短く書けるし

**デフォルトの名無しさん** · 2021/02/11(木) 02:10:08.49

>>663
むしろ、STLがクソすぎるのがC++が嫌われる原因。
C++は、STLを使わずに独自templateライブラリを使うのが便利。

**デフォルトの名無しさん** · 2021/02/11(木) 02:23:45.58

>>664
「使いこなす」がレベチ過ぎてワロシ
コンテナとアルゴに関しては俺もSTL使う方が良いと思ってたわ
vector<bool>とか、難のある仕様があるのは理解してたがそういうのに個別に対処すれば十分だろうと

リーナスとかもSTLが大ッ嫌いだという記事をよく見るが、具体的にどこを毛嫌いしてるのか俺は理解していない

**デフォルトの名無しさん** · 2021/02/11(木) 03:22:28.69

いつもの爺だよ

**デフォルトの名無しさん** · 2021/02/11(木) 10:32:11.70

そりゃOSレベルで見たらメモリの使い方がラップされるようなライブラリは使わんだろ。
馬鹿でもわかる話だと思ってたがそうでもないのか。

**デフォルトの名無しさん** · 2021/02/11(木) 10:55:34.35

むしろ C++ のつらさを知ってないと Rust の良さは (悪さもだが) わからんだろ。

**デフォルトの名無しさん** · 2021/02/11(木) 12:17:58.13

>>667
それ言ったらC++のCじゃない部分は全部ダメじゃね

**デフォルトの名無しさん** · 2021/02/11(木) 12:18:18.96

STLに限らず

**デフォルトの名無しさん** · 2021/02/11(木) 12:38:34.69

>>669
そうだよ
「OSを実装するためには」という条件ではね

**デフォルトの名無しさん** · 2021/02/11(木) 15:13:11.82

>>669
STLはCの良さを台無しにするような傾向がある。
C++の言語仕様自体は適切に使えばそのようなことはない。

**デフォルトの名無しさん** · 2021/02/11(木) 15:46:32.06

>>672
> STLはCの良さを台無しにするような傾向がある。
これは観念的な話？
パフォーマンス的には、もちろん不要なコピー等は避けるという前提のもとで、同じなのかなって思ってたんだけど

> C++の言語仕様自体は適切に使えばそのようなことはない。
適切というのは、C with class として使えば、ということ？

**デフォルトの名無しさん** · 2021/02/11(木) 16:26:39.58

>>672
STL というものは C++ の中にはない。

**デフォルトの名無しさん** · 2021/02/11(木) 16:31:10.44

C++ の標準ライブラリは C 的な良さを殺さないように配慮しまくってるから
抽象化層で抽象化しきれずにイビツになってるんで、
出来が良いとは思わんが C の良さを台無しにしてるとは思わんな。

**デフォルトの名無しさん** · 2021/02/11(木) 16:32:15.96

>>675
そう思ってるならあなたも設計者の頭の出来も馬鹿。

**デフォルトの名無しさん** · 2021/02/11(木) 17:01:42.79

他所でやれ

**デフォルトの名無しさん** · 2021/02/11(木) 17:04:12.74

>>662
MozillaもGoogleもMSもC++を使いこなせないからRustを支援してるって主張か？

**デフォルトの名無しさん** · 2021/02/11(木) 17:27:06.59

>>678
Mozillaなんか独占禁止法違反を誤魔化すためのGoogleの下請けに過ぎないので
レベルの高いプログラマはもはやいないし、MSやGoogleは巨大すぎるので
できそこないのプログラマも多い。

**デフォルトの名無しさん** · 2021/02/11(木) 17:42:02.28

おじいちゃんの想像力が凄すぎる

**デフォルトの名無しさん** · 2021/02/11(木) 19:00:14.15

トランプ好きそう

**デフォルトの名無しさん** · 2021/02/11(木) 19:04:26.47

>>679
なるほど、Mozillaのプログラマは全員レベル低いしGoogleやMSでrustに関わってる人も全員出来損ないという主張なのね

**デフォルトの名無しさん** · 2021/02/11(木) 19:17:51.67

ダニング＝クルーガー効果

ダニング＝クルーガー効果とは、能力の低い人物が自らの容姿や発言・行動などについて、
実際よりも高い評価を行ってしまう優越の錯覚（英語版）を生み出す認知バイアス。
この現象は、人間が自分自身の不適格性を認識すること（メタ認知）ができないことによって生じる。
1999年にこの効果を定義したコーネル大学のデイヴィッド・ダニング（英語版）とジャスティン・クルーガー（英語版）は、
「優越の錯覚を生み出す認知バイアスは、能力の高い人物の場合は外部（＝他人）に対する過小評価に起因している。
一方で、能力の低い人物の場合は内部（＝自身）に対する過大評価に起因している。」と述べている。