Rust part8

**デフォルトの名無しさん** · 2020/01/24(金) 11:47:52.41

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 Part7
http://mevius.5ch.net/test/read.cgi/tech/1563114707/

**デフォルトの名無しさん** · 2020/05/30(土) 07:24:57.35

待望の新言語

ZetZ、形式的検証機能を備えたCのダイアレクト
https://www.infoq.com/jp/news/2020/05/zz-formal-verified-c-dialect/

**デフォルトの名無しさん** · 2020/05/30(土) 11:52:22.59

# と #! はどういう使い分けがあるの？

**デフォルトの名無しさん** · 2020/05/30(土) 13:01:17.39

>>594
#は直後の構文要素に対するアノテーションで
#!はそれを含むスコープ全体へのアノテーション。

**デフォルトの名無しさん** · 2020/05/30(土) 15:53:27.03

>>595
Thx

**デフォルトの名無しさん** · 2020/06/01(月) 10:13:32.80

loopとスレッドスリープでやるのもいいけど、いい感じにデーモン立てて一定時間経ったら関数実行してくれるような仕組みのクレートってない？

**デフォルトの名無しさん** · 2020/06/01(月) 10:31:33.62

借用や所有の概念って、Rustがはじめてなのかと思ったら、D言語に既にあったんだね。

**デフォルトの名無しさん** · 2020/06/01(月) 10:51:02.85

>>598
あー。D言語の方がRustを参考に取り入れたらしい。

**デフォルトの名無しさん** · 2020/06/01(月) 11:12:31.20

Rustのヒープは必ず参照カウンタが入ってしまうので、C/C++言語に比べれば遅くなるね。

**デフォルトの名無しさん** · 2020/06/01(月) 11:19:51.79

>>600
Rc以外は参照カウンタ入らないよ。
解放タイミングはコンパイル時に決定するんだからカウンタいらない。

**デフォルトの名無しさん** · 2020/06/01(月) 11:31:20.41

>>601
Box<T>も参照カウンタ入ってないの？

**デフォルトの名無しさん** · 2020/06/01(月) 11:32:01.43

>>601
それより、参照カウンタが入っているかどうかはどこを読めば分かるの？

**デフォルトの名無しさん** · 2020/06/01(月) 11:35:58.71

C++ vs Rust
unique_ptr<T> ---> Box<T>
shared_ptr<T> ---> Rc<T>
weak_ptr<T> ---> Weak<T>
ということなの？
どこに書いてある？？

**デフォルトの名無しさん** · 2020/06/01(月) 11:37:31.71

>>603
RcやArcのドキュメントにはreference counting pointerと書いてある。
Boxとか入ってないやつにわざわざ入ってないとは書いてないけど。

**デフォルトの名無しさん** · 2020/06/01(月) 11:40:30.85

let a = 7;
let a_box: Box<i32>
a_box = Box::new(a+2);　//(3)
という例があったけど、どうして、(3)がエラーにならないの？
mut 属性にしておかなければ、let文でしか代入できないんじゃなかった？

**デフォルトの名無しさん** · 2020/06/01(月) 11:43:34.61

>>604
https://doc.rust-jp.rs/book/second-edition/ch15-00-smart-pointers.html

>>606
a_boxは2行目では値が入ってないので、3行目が最初の代入だから変更ではなくmutはいらない。

**デフォルトの名無しさん** · 2020/06/01(月) 11:44:44.94

>>605
C++とは名前が変わっているだけで、>>604という理解でいいわけだね？

**デフォルトの名無しさん** · 2020/06/01(月) 11:49:39.54

>>607
>a_boxは2行目では値が入ってないので、3行目が最初の代入だから変更ではなくmutはいらない。
なるほど、最初かどうかをコンパイラが追跡していたんだね。
知らなかった。
immutableな変数は、必ず let 文でしか代入できないとばかり思っていた。
最初に読んだ documentでは、例としてそう書いてあったから。

**デフォルトの名無しさん** · 2020/06/01(月) 11:51:23.94

>>608
厳密に同じかはわからないけど、対応としては合ってるかと。

**デフォルトの名無しさん** · 2020/06/01(月) 12:19:02.82

「変数のアドレスを他の変数に代入することを借用(borrowing)という」
という理解で有ってる？

**デフォルトの名無しさん** · 2020/06/01(月) 12:37:12.92

ID: o7IiynR8
こいつやべーだろ。なんにも知らないくせにRustのヒープは必ず参照カウンタが入るとか嘘吹かしてんじゃねえか
蓋開けれみりゃ初心者のクレクレゴミだし、どういう自信で最初言ったんだよ

**デフォルトの名無しさん** · 2020/06/01(月) 12:37:39.24

>>611
実態はアドレスだが所有権管理の対象になるのはアドレスではなく参照。

**デフォルトの名無しさん** · 2020/06/01(月) 13:18:58.22

コンパイル時に所有権のチェックをしてるってのがよくわかってなくて変なことを言ってるのかもね。
「所有権の移動」が「実行時にアドレスと一緒に所有権が渡される」みたいな認識だとしたら
参照カウンタによって実装されるという ID:o7IiynR8 みたいな言説になるのはわからんでもない。

が、 Rust は静的解析の賢さでメモリの安全性を高めるのがウリのひとつなんだからそんなわけねーだろというくらいには
想像できて欲しいよ。

**デフォルトの名無しさん** · 2020/06/01(月) 13:24:10.03

C++の概念に言い換えて理解しようというのが
そもそも無理筋な気が

**デフォルトの名無しさん** · 2020/06/01(月) 13:41:16.41

説明書読まずにとりあえず人に聞いて教えて貰おうとするやついるよね

**デフォルトの名無しさん** · 2020/06/01(月) 14:10:26.06

所有権回りは Rust の重要な特徴だから
どんな入門書でも書いてないはずはないんだよな。

**デフォルトの名無しさん** · 2020/06/01(月) 14:47:28.60

Rustの普及を阻む課題　年次調査から明らかに
https://www.atmarkit.co.jp/ait/articles/2006/01/news044.html

Rustの利用をやめた回答者にその理由を尋ねたところ「自社がRustを使っていない」という回答が最も多かった。
他の上位の理由は「習得が大変」「必要としているライブラリがない」「移行すると作業能率が落ちる」「IDE(統合開発環境)でのサポートが不十分」などだ。

Rustを利用したことがない回答者に理由を尋ねたところ、「Rustを学んだことがないから。ただし、学びたい」「自社がRustを使っていないから」という回答が、いずれも約4分の1の割合に達し、この2つで回答の過半数を占めた。

Rustの普及拡大への最大の課題として挙げた上位3つは、「トレーニング／ドキュメントの充実」「ライブラリの充実／改善」「IDEの統合」だ。

**デフォルトの名無しさん** · 2020/06/01(月) 15:24:58.77

https://blog.rust-lang.org/2020/04/17/Rust-survey-2019.html

**デフォルトの名無しさん** · 2020/06/01(月) 15:45:21.43

ちょっと変わった傾向だな:

55% of Rust users develop on Linux
24% develop on Windows
23% develop on macOS

**デフォルトの名無しさん** · 2020/06/01(月) 15:59:56.59

間違った知識を他人に教えるのは説明書読む以前の問題

**デフォルトの名無しさん** · 2020/06/01(月) 16:00:16.74

回答者がターゲットとしているプラットフォームも以下の様に書かれているが、回答者がWebBackendを職業にしている人が多いことに対応している可能性が高い :
Linux: 36.9%、
Windows: 16.3%、
maxOS: 14.7%
WebAssembly: 14.4%
Embedded: 7.6%
iOS: 2.9%
BSD: 2.7%
Android: 2.4%

When it comes to what platforms using are targeting for their applications Linux remains the first choice with 36.9%,with Windows as second at 16.3%.
Following close behind Windows are macOS and Web Assembly at 14% each

**デフォルトの名無しさん** · 2020/06/01(月) 17:53:49.92

Some a = xxx; // 何か初期済みであると仮定
let b1 = Box::new(a);
let b2 = b1;
とした場合、b1が持っていた所有権はb2に移ってしまい、
b1はこれ以後使えなくなるという理解で有ってますか？

**デフォルトの名無しさん** · 2020/06/01(月) 18:03:59.31

初心者なもので、正しく(?)は、
let b1 = Box<Some>::new();
let b2 = b1;
なのかも知れません。

**デフォルトの名無しさん** · 2020/06/01(月) 18:07:45.72

>>623
とりあえずThe Bookの所有権のところを一通り読んでから質問してください
その質問の答えも試し方も全部書いてますので
https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html

**デフォルトの名無しさん** · 2020/06/01(月) 18:23:13.55

>>625
そこは一時間ほど前に読みましたが、>>623のことは分からないので質問しました。

**デフォルトの名無しさん** · 2020/06/01(月) 18:36:04.96

>>623
お前が正しく理解してるかどうか知らんけど個別の事例として言えば Yes だ。
所有権は移動して、元の変数はもう使えない。

だけどそんなことはやってみたらわかりやすいエラーメッセージが出るじゃないの。

fn main() {
let a = 20;
let b1 = Box::new(a);
let b2 = b1;
println!("{}", b1);
}

みたいなことを書いたら

error[E0382]: use of moved value: `b1`

って出るし、どこでムーブ (所有権の移管) 済みかまでも表示してくれる。
Rust のエラーメッセージはめっちゃ親切なんだから、
「この場合はどうですか」なんて質問する間があったらやってみりゃいいんだよ。

**デフォルトの名無しさん** · 2020/06/01(月) 19:13:13.12

Rustのエラーメッセージがすごく親切なのは分かるんだけど、小手先で直そうとするとどんどん修正範囲が広くなっていって最終的に「設計が悪い」みたいな結論になっちゃう
他言語よりコーディング時に考慮すべき点が多いというか違うというか…慣れればそういうことも無くなるのかね

**デフォルトの名無しさん** · 2020/06/01(月) 22:13:40.55

>>628
色々調べてる途中だけど、どうも、C言語で出来ていたことの何割かは
Rustでは禁止されていて出来ないと思う。
https://stackoverflow.com/questions/40875152/reference-to-element-in-vector
を見てもRustではarrayの1つの要素に対する参照は作れないようだし。
C/C++では当然、そのようなものへの参照やポインタが好きなように作れる。
これが出来ないことである種の組み合わせ爆発が起こりがちになり、
C/C++よりプログラムがしにくくなるだろう。

**デフォルトの名無しさん** · 2020/06/01(月) 22:19:12.08

>>729
例えばの話、C言語だと1つのCPerson型のデータをファイルに出力する関数を
void write(FILE *fp, CPerson const *person);
のように作りさえすれば、
CPerson persons[100];
for (int idx=0; idx<100; idx++ ) {
write(fp, &persons[idx]);
}
でCPersonの配列にも対応できてしまう。
このようなことがRustではできなくなるはず。
無理やり観が有るが、CPersonのメンバ関数としてwrite()関数を作ってしまうことで対応できるかも知れない。

**デフォルトの名無しさん** · 2020/06/01(月) 22:50:56.49

rustはまだ勉強中だけど、630がアホなこと言ってるのは俺でもわかる。

**デフォルトの名無しさん** · 2020/06/01(月) 22:53:23.54

ID:T0vrM+QLやID:bf1cRh+Bと同一人物だね

**デフォルトの名無しさん** · 2020/06/01(月) 22:54:16.92

荒らしの相手するやつも荒らし

**デフォルトの名無しさん** · 2020/06/01(月) 23:37:56.02

もうこのスレで公式すら読んでないような初心者質問するやつ無視でよくね。文章から見て同一人物っぽいし
それとそのテンプレ追加も次立てる人お願い >>999

**デフォルトの名無しさん** · 2020/06/02(火) 10:45:35.24

>>629
https://doc.rust-lang.org/1.9.0/book/structs.html
によれば、構造体メンバのアドレスを参照型変数に代入することができるらしい。

**デフォルトの名無しさん** · 2020/06/02(火) 10:57:29.35

diesel辛いっていう人多いけど、乗り換えるならどんなクレートになんだろうね

**デフォルトの名無しさん** · 2020/06/02(火) 11:19:09.02

>>627 >>634
読んでも書いてない。

**デフォルトの名無しさん** · 2020/06/02(火) 19:18:24.00

結局c++やらんとrustを理解するなんて無理なんだよ

**デフォルトの名無しさん** · 2020/06/02(火) 20:16:57.29

>>638
こないだ C++ スレで >>623 の ID は見たぞ。

**デフォルトの名無しさん** · 2020/06/03(水) 02:21:24.02

https://users.rust-lang.org/t/isnt-rust-too-difficult-to-be-widely-adopted/6173/37
↑のサイトに寄れば、Blandy & Orendorff の Programming Rust の
評判が良いらしい：
I’m also new to Rust and have found the “Programming Rust” book by Blandy & Orendorff to be very helpful.
Especially the chapters on ownership and references.
It is an expensive book though.

また、Box<T>, Rc<T>, RefCell<T>は必要ないという見方があるらしい。
最初から用意されているコンテナを使えば十分という意味のようだ :

I also didn’t need Box, Rc, RefCell, or friends.

**デフォルトの名無しさん** · 2020/06/03(水) 02:34:58.13

>>638
(C++は、C++11から大幅に改定されたので)、海外のサイトに寄れば、
C++11より前のC++からRustを学ぼうとすると大変だが、C++11以後
からだと対応関係が分かり易くて楽なのだそうだ。
unique_ptrとBox<T>が対応しているような話か。
ただ、C++の特徴であるtemplateに相当するものがまだRustにはないことが
残念だと書かれていた。

**デフォルトの名無しさん** · 2020/06/03(水) 02:45:19.00

そのサイトに寄れば、Rustで難しいのは、借用や所有の概念ではなく、
lifetimeなのだそうだ。
個人的にも、構造体のlifetimeについて説明不足を感じた。
構造体の変数のスコープと構造体のメタ部分で記述するライフタイムの
関係性がbookなどでは書かれて無いように思えた。
分からんけど。

**デフォルトの名無しさん** · 2020/06/03(水) 02:59:40.24

2018/04 の時点でも、まだ、lifetimeに関する資料が足りてないと感じている人がいたそうだ。
Can we maybe have a book or booklet exclusively covering lifetimes?
I don’t think the first level of instruction material on lifetimes which is found
in the rust book and others which talks about the syntax and the aliasing rules and elision is enough.
It leads to an incomplete model which only frustrates when you discover its incompleteness.
Rust nominoc does go further. For example it shows with detailed examples how lifetimes start with
a let binding and how they interact with other lifetimes in the same scope.
This is fundamental stuff and absolutely essential to understanding.
But there are still aspects not covered there.
For instance I realized that lifetimes can be shrunk as needed by the compiler only from this
forum (thanks @vitalyd) which invalidated my previous model.
And I’m sure there are other aspects I don’t know about.
I think we just need one place where one can learn everything about lifetimes and be done with it.

**デフォルトの名無しさん** · 2020/06/04(木) 10:31:48.72

>>641
グロ

**デフォルトの名無しさん** · 2020/06/04(木) 12:10:41.88

>>636
sqlxじゃないか

**デフォルトの名無しさん** · 2020/06/04(木) 13:20:58.04

難しいのはネストした場合のオブジェクトに対するイミュータブルかどうかとライフタイムだろう。

**デフォルトの名無しさん** · 2020/06/04(木) 14:06:07.27

ライフタイムはコンパイラが親切丁寧に指摘してくれるから難しくは無いだろ
依存関係とか指摘出来ない系のエラーで詰まる事のが多い

**デフォルトの名無しさん** · 2020/06/04(木) 19:40:21.91

>>647
コンパイラに指摘されれば問題ないかというと総でも無い。
プログラミングはコンパイルする前に予想可能で無いと困る。

**デフォルトの名無しさん** · 2020/06/04(木) 20:10:09.15

競馬かな？

**デフォルトの名無しさん** · 2020/06/04(木) 20:37:04.46

>>648
難しくないってのは「学習は」難しくないって話じゃね？
いずれは自分でわかるようになるというのは当然の前提で、
まあわかるようになっても間違えることはあるのでそれを指摘してくれるのもありがたい。

**デフォルトの名無しさん** · 2020/06/04(木) 22:06:35.88

>>650
ところが、コンパイラを実際に動かさなくても、仕様書や例を見ただけで
理解できる言語も多いんだよ。
たとえば、CやBASIC,JS,Java,C#,Ruby,Python,Perlなどがそれに該当する。
C++は、03まではまあ分かったが、だんだん難しくなっていった。
もはやSTLのソースも仕様書ですらも理解できるのは一部の特殊な人に
限定されてきているかも知れない。STLの
forward()の意味を理解したりどう実装されているかをソースを見て理解できる
る人は本の一握りだろう。
move()とforward()の役割の違いも実装レベルでどれだけの人間が理解できることか。
でもRustも同じように難しくて同じようなことは起こると考えている。

**デフォルトの名無しさん** · 2020/06/04(木) 22:49:18.31

そのレベルで理解できてない人がC++使うのはどういうメリットがあるのだろうか

**デフォルトの名無しさん** · 2020/06/04(木) 22:52:33.61

実はC++は、forwardやmove, templateなどの詳細を理解できてなくても高級言語的な部分だけを使ってプログラムすることは出来る。
それはRustでも同じ。

**デフォルトの名無しさん** · 2020/06/04(木) 23:01:33.43

C++は仕様が難しいというより
仕様ではないけど当然知ってるべきイディオムが
たくさんあってきつい、という感じがするな。

**デフォルトの名無しさん** · 2020/06/05(金) 01:02:20.04

将棋しか知らない人が囲碁というゲームを見ると
何やってるかわからないしなんだかむずかしそうと言う
しかし実は囲碁はルールそのものはおそろしくシンプルなのだ
ところがルールだけ知っていても、囲碁は打てない
(打てるけど次に何していいかわからなくなる)
なぜなら囲碁はルールとは別に「こういう場面はこういう風に
打ち回す」というイデォムが大量にあってそれを知る必要があるからだ
C++はそれに似ている

**デフォルトの名無しさん** · 2020/06/05(金) 01:41:15.67

そもそもRustの仕様って難しいか？
いろんな言語から取り込んだ概念があって
C一筋とかRuby一筋みたいな人には学ぶべきことが多いとは思うけど、
特に複雑な仕様って思い当たらないんだけどな。
JSの型変換の仕様とかの方がよっぽど複雑だしワケわからんと思う。

**デフォルトの名無しさん** · 2020/06/05(金) 09:30:38.65

>>651
C が仕様や例で理解できるってどんな超人だよ。
コンパイルエラーにも実行時エラーにもならない未定義だの処理系定義だのが山もりだろうが。
初心者の書くコードで完全に仕様に沿ったコードなんて見たことないぞ。

**デフォルトの名無しさん** · 2020/06/05(金) 09:38:30.26

Haskell の入門書を一通りは読んでたから Rust の型システムは似たようなものとして理解できたなぁ。
ライフタイムもプログラムの字面に書きこそしないでも C/C++ では意識せざるを得ないし、
複雑になるとわけわからんってときは C/C++ で書いてもわけわからんようになるやつ。

**デフォルトの名無しさん** · 2020/06/05(金) 12:01:32.43

きっとそういう感じでべた褒めする人が多いから、Rubyみたいに一回大人気言語になった後、急速に衰退する気がする。
Rubyも最初は良いと思われていた。

**デフォルトの名無しさん** · 2020/06/05(金) 12:13:12.11

>>657
Cの仕様はシンプルで、
ポインタと明示的な型宣言と文字列比較をstrcmp()で行うという以外、
基本的な枠組みは既存の言語と変わりはなかったので理解は難しくなかった。

**デフォルトの名無しさん** · 2020/06/05(金) 12:14:22.73

Ruby は今でも十分に使われているよ。 (俺は使ってないけど。)
適切ではないところまで広がった分がそぎ落とされてちょうどいい感じに落ち着いたってだけ。
プログラミング言語の良さはスカラ値で測定できるようなものではなくて、用途による。
利用事例が減ったからといってその勢いで衰退して消えるっていうような話ではない。

Rust はまだ実際のプロダクトでどう使うのが適切なのか見極め切れていないから過剰に広まっている
というのはあると思うが、少なくとも C/C++ で問題だった部分を解決したという側面はある。
そんでそのかわりに出てきた問題ももちろんあるので両方を天秤にかけて判断する材料を集めているとこって感じ。

**デフォルトの名無しさん** · 2020/06/05(金) 12:15:46.52

>>660
うん。 C がシンプルで理解しやすいと思い込みやすい言語なのは俺も知ってる。

**デフォルトの名無しさん** · 2020/06/05(金) 12:32:15.42

Google Trends によれば、検索数の増加曲線はほぼ kotlinと同じ位。
ただし、kotlinは、2017/05に急激に上がってRustと重なりあった曲線になったのに対し、Rustは、2014/01に急激に上がった後、徐々に増えている感じ。
Rustはこの1年くらいでわずかに増加速度がKotlinより上がったが、それでもKotlinの曲線とほぼ重なった状態からは脱してはいない。

**デフォルトの名無しさん** · 2020/06/05(金) 12:34:07.49

>>662
匿名性掲示板では何でも言えてしまうが、実績を見れば俺がちゃんとCやC++を使いこなしていることは分かる。
ただし、C++は一度学んでも仕様が大幅に変更されるので、細かいところを理解するのは時間が掛かるようになってきている。
Cはそんなことはなかったが。

**デフォルトの名無しさん** · 2020/06/05(金) 12:58:47.64

もしかして伝説のスーパーハカーさんですか！？

**デフォルトの名無しさん** · 2020/06/05(金) 13:22:50.72

chronoつかってるんだけど、このyearってなんでi32なの？

https://docs.rs/chrono/0.4.11/chrono/offset/trait.TimeZone.html#method.ymd
fn ymd(&self, year: i32, month: u32, day: u32) -> Date<Self>

**デフォルトの名無しさん** · 2020/06/05(金) 13:32:05.31

>>664
仮に C や C++ を使いこなせているとして、
使いこなせている言語よりも使いこなせてない言語の方が難しいに決まってるじゃないの。
あなたはそうなんですねってだけ。

**デフォルトの名無しさん** · 2020/06/05(金) 13:35:12.28

>>666
符号付きなのがなんでってこと？
month や day はマイナスになる意味はないけど、
年はマイナス (紀元前) を扱いたいこともあるんじゃね。
知らんけど。

**デフォルトの名無しさん** · 2020/06/05(金) 13:44:02.67

合ってんじゃね？
知らんけど。

**デフォルトの名無しさん** · 2020/06/05(金) 14:06:52.05

C++の仕様が大幅に変更されたというのは
なんのことだ？

**デフォルトの名無しさん** · 2020/06/05(金) 14:17:19.64

>>670
有る意味では僅かな修正であっても、基礎的な部分における修正は多大な影響を及ぼすことがある。
moveを出来るようにするために追加されたもろもろの事や、=を書かないタイプの{}
による初期化はそれに該当する。
なんでも無いようでいて、可読性を下げたり危険をもたらすことがある。

**デフォルトの名無しさん** · 2020/06/05(金) 14:41:22.49

>>662
Cほどシンプルな言語もないだろ。それと簡単に使いこなせるかは別問題。

**デフォルトの名無しさん** · 2020/06/05(金) 14:48:48.89

>>671
それ仕様の変更なの？

**デフォルトの名無しさん** · 2020/06/05(金) 14:55:26.22

>>666
そこに書いとるやん
This assumes the proleptic Gregorian calendar, with the year 0 being 1 BCE.

つまり-1は2 BC

**デフォルトの名無しさん** · 2020/06/05(金) 15:08:35.22

Cのプリプロセッサやパーサーを書くと全然シンプルじゃないことが分かる

**デフォルトの名無しさん** · 2020/06/05(金) 15:11:02.16

>>675
それは、使う側にはシンプルそうに見えるCも実は細かく見るとシンプルではないということであって、使う側目線で既に複雑なものはそれ以前の問題他。

**デフォルトの名無しさん** · 2020/06/05(金) 15:43:45.14

依存先より寿命が長くなってはいけないなんていうのは C でも当たり前のことだろ。
Rust のライフタイムはライフタイムを簡単に「表現 (したものをチェック)」する言語機能であって、
C でプログラマがやってる (はずの) ライフタイムの管理より複雑ということはない。

Rust なら処理系がチェックしてくれることを
C ではプログラマがやってたんだぞ。
C で出来てたことが Rust ではやれないってのは言語のせいか？

Rust のライフタイムの管理は制約が厳しいとか面倒くさいとかいうなら話はわかるが、
複雑だとか学習難易度が高いというのは納得しかねる。

**デフォルトの名無しさん** · 2020/06/05(金) 15:54:02.73

>>677
>Rust のライフタイムの管理は制約が厳しいとか面倒くさいとかいうなら話はわかるが、
>複雑だとか学習難易度が高いというのは納得しかねる。
一つあるとすれば、難しさは、ちゃんと本も読んでいるか、ネットに書かれている情報だけに頼っているかの違いに起因している可能性。

**デフォルトの名無しさん** · 2020/06/05(金) 21:26:05.32

これにて、このスレがRust関連の本の作者の巣窟であることが証明されました。

**デフォルトの名無しさん** · 2020/06/05(金) 21:32:24.36

だいぶ前からじつは言語系のスレはほとんどソレなんだな
宣伝してるやつは気付かれれないと思ってるだろうけど

**デフォルトの名無しさん** · 2020/06/05(金) 21:49:15.38

>>618
2018/11/28の時点で、

https://www.infoworld.com/article/3324488/rust-language-is-too-hard-to-learn-and-use-says-user-survey.html
ユーザーの調査によると、Rust言語は習得も使用も難しい
Rustユーザーの調査では、メモリの安全性と正確性のためにこの言語の非常に宣伝されている機能に困難と不満を感じています
Rust言語チームが実施したRustユーザーコミュニティの新しい調査では、言語とその使用への関心が高まっていますが、プロジェクトが利点として宣伝しているいくつかのRust機能に対するユーザーの不満も示されています。
Rustの習得が難しいのはなぜですか？ユーザーは、Rustの最も特徴的な2つの機能（寿命と所有権/借用システム）は、「トリッキー」、「非常に難しい」、または「まだ得られない」ものであると報告しました。
その他の質問は、Rustを続行するための課題を中心に展開されました。Rustの使用をやめた人の約半分は、わずか1か月後にそうしました。Rustを使用していない最も一般的な理由は、「威圧的すぎる、習得が難しい、または複雑すぎる」（25％）、

**デフォルトの名無しさん** · 2020/06/05(金) 22:00:56.76

Rust言語は、学んだり使ったりするのが難しすぎるということが、ユーザーに対する調査で分かった。
--Rustユーザーに対する調査では、安全性と正確性のために言語が非常にうるさく押し付けてくる特長により困難と欲求不満を感じていることが分かった。

Rust language is too hard to learn and use, says user survey
A survey of Rust users finds difficulty and frustration with the language’s highly touted features for memory safety and correctness.

tout = 押し売りする, うるさく勧誘する, 客引きする
(tout for custom うるさく注文を求める.)
・切符をプレミア付きで売る, ダフ屋をやる.
・うるさく勧める.
・ほめちぎる.

**デフォルトの名無しさん** · 2020/06/05(金) 22:04:18.63

誤:安全性と正確性のために言語が非常にうるさく押し付けてくる特長
誤:安全性と正確性のために言語が非常にうるさく押し付けてくる機構(機能)

**デフォルトの名無しさん** · 2020/06/05(金) 23:15:24.59

>>674
へー。西暦にゼロ年っていうのは無いのか。

**デフォルトの名無しさん** · 2020/06/06(土) 04:00:23.67

この言語廃れてきそうな気がした。
だってみんなが触るって未来が想像できないもん

**デフォルトの名無しさん** · 2020/06/06(土) 04:10:18.67

みんなが触る言語なんて世の中に存在するか？

**デフォルトの名無しさん** · 2020/06/06(土) 05:29:47.06

Rustを使ったことはないけどC++は既存の資源で堅実に作るのに対して
Rustは一人のスーパープログラマが複雑高度なライブラリやモジュールを一点突破で書くのに使われそうなイメージ

**デフォルトの名無しさん** · 2020/06/06(土) 09:51:25.89

まあScalaと同じ道を辿るだろうね
あっちはビッグウェア系でそれなりに採用されてたから被害が甚大だったけど、
Rustに関してはそういうビジネス的な得意分野は今のところ無いのが救いか

**デフォルトの名無しさん** · 2020/06/06(土) 15:58:34.19

>>687
ところがスーパープログラマは、C++でもメモリー関連のバグで詰んで挫折したりすることはないんだな、これが。

**デフォルトの名無しさん** · 2020/06/06(土) 17:06:05.01

>>687
Rust の偉大さのひとつには crates.io の存在がある。
資源の利用という意味じゃ Rust はかなり積極的だぞ。

**デフォルトの名無しさん** · 2020/06/06(土) 17:17:15.77

C++は標準のライブラリリポジトリと標準のビルドツールがあればなぁ、と思う。
野良のは乱立してるけど、結局ほしいライブラリはなかったりするし…。

**デフォルトの名無しさん** · 2020/06/06(土) 17:37:45.92

>>688
MicrosoftもAppleも使っていくのに爆死したら
IT業界壊滅じゃね