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/23(土) 23:03:55.77

>>563
>その型はスライスだから全く別。しかも&もないからそんな型ない
rustのドキュメントも混同しまくってるけど[T]はDSTのarrayで&[T]がDSTのarrayの借用（スライス）だぞ。

>>564
Boxのrustdocに書いてある

**デフォルトの名無しさん** · 2020/05/24(日) 01:52:15.18

>>565
[[[i32; 3]; 3]] は存在できるが [[[I32]]] は存在できない
配列の要素毎にサイズが可変となってしまう

**562** · 2020/05/24(日) 09:30:45.62

>>566
スライスにとって要素の数の情報は動的なもの (実質的に fat pointer) で
配列にとっての要素の数は型の一部ってこと？

**デフォルトの名無しさん** · 2020/05/24(日) 17:28:53.26

>>567
そういうこと
もっと言うと [T] の要素数情報は配列自体ではなく配列への参照 (fat pointer) が保持してるから
[T] が単独で存在することはできなくて、
参照経由の &[T] やスマートポインタ経由の Box<[T]>, Rc<[T]> といった形でしか存在できない

**562** · 2020/05/24(日) 17:59:17.80

>>568
そういうことか。
fat pointer を基礎に据えることを除けば
C/C++ のルールとかなり似てるのでわかりやすいな。
(けどそれ故に C/C++ 的な考え方に引きずられてしまう部分もある……。)

**デフォルトの名無しさん** · 2020/05/24(日) 20:09:44.60

言いたい事は理解できるが
存在できないって言い方は少し引っかかる

**デフォルトの名無しさん** · 2020/05/24(日) 23:17:03.73

6月号で特集が組まれてます
初心者の方は是非

**デフォルトの名無しさん** · 2020/05/24(日) 23:36:35.12

なにこれどうなってるの？traitでFizzBuzz？
https://github.com/doctorn/trait-eval

**デフォルトの名無しさん** · 2020/05/25(月) 09:27:38.21

traitのFizzbuzzに付属してるtrait群がいいね。From実装してなくて爪甘いけど

**デフォルトの名無しさん** · 2020/05/25(月) 22:39:28.81

>>566
>[[[i32; 3]; 3]] は存在できるが
unsizedだからできない。
というか存在はしてる。rustはリージョンでメモリ管理するからコンパイル時に
リージョンのサイズが分かる必要があるからDSTが第一級じゃないだけ。
スライスにすればそのスライスのサイズはusize*2だからzoneを確保できるだろ。
コンパイル時にポインタのサイズが分かれば良いだけだから

assert_eq!(::std::alloc::Layout::new::<*const [u64]>(), ::std::alloc::Layout::new::<&[u64]>());

は通る。the bookとnomiconよめ。

**デフォルトの名無しさん** · 2020/05/26(火) 01:25:10.52

>>540
https://search.yahoo.co.jp/realtime/search?p=Rust

**デフォルトの名無しさん** · 2020/05/26(火) 09:22:21.48

>>574
(要素数と要素サイズがコンパイル時で既知である必要があるarrayの形では)存在できない
と読んでくれ

**デフォルトの名無しさん** · 2020/05/26(火) 12:44:21.66

::stdの指定の仕方ってなんで使うの？stdじゃなくて
自作のmod std作った時にしか被らないぐらいしか利点なさそう。しかもそんな紛らわしい名前で作らないし

**デフォルトの名無しさん** · 2020/05/26(火) 23:26:23.63

他の crate に公開するマクロで使う

**デフォルトの名無しさん** · 2020/05/26(火) 23:27:54.23

std以外のcrateにも使えるから、モジュールとの名前かぶりで使わざるを得ないときもある
testとか

**デフォルトの名無しさん** · 2020/05/27(水) 10:28:00.44

2018の次期バージョンっていくつ？

**デフォルトの名無しさん** · 2020/05/27(水) 11:01:45.48

>>580
Prepare for a possible Rust 2021 Edition
https://github.com/rust-lang/rfcs/blob/master/text/2857-roadmap-2020.md

**デフォルトの名無しさん** · 2020/05/28(木) 08:05:27.45

pub enum KansaiPref {
Osaka,
Hyogo,
Kyoto,
}
こういうenumを文字列から生成する時ってnewよりfrom_strで作った方がいいの？

impl KansaiPref {
fn new(s: &str) -> Self {
use Self::*;
match s {
"大阪" => Osaka,
"兵庫" => Hyogo,
"京都" => Kyoto,
_ => unimplemented!(),
}
}

newかfrom_str

impl FromStr for KansaiPref {
type Err = ...;
fn from_str(s: &str) -> Result<Self, Self::Err> {
use Self::*;
match s {
"大阪" => Osaka,
"兵庫" => Hyogo,
"京都" => Kyoto,
_ => unimplemented!(),
}
}
}

**デフォルトの名無しさん** · 2020/05/28(木) 10:15:20.06

>>582
どっちでもいいと思うけど自分ならfrom_str選ぶ
理由はenumをnewするのにResult(かOption)が返されるシグニチャよりも
input.parse::<KansaiPref>()してResultが返されるほうが意図が伝わりやすいから

**デフォルトの名無しさん** · 2020/05/28(木) 12:26:13.92

>>582
俺は初心者だから意見としてはそれほどあてにならないけど、
from_str を使った方がいいと思う。
new はただの習慣だが FromStr は制約として機能するので、
既存の枠組みの中で便利に機能する可能性がある。

**デフォルトの名無しさん** · 2020/05/28(木) 22:03:56.44

多言語展開を考えるとどれも使いたくねえな…と思ってしまう

**デフォルトの名無しさん** · 2020/05/29(金) 07:36:25.48

FromStr実装するならちゃんと Err 返してくれ

**デフォルトの名無しさん** · 2020/05/29(金) 16:33:26.54

let a : Box<[T; 1000]> = Box::new([Default::default();1000]);

みたいなのってスタックに要素を作ってからヒープにコピーするようになるから効率が悪いし、
Copy を実装してない型だと使えないみたいなんだけど、これって今はどうするのが常套手段なの？

前提条件として変数の型は Box<[T; 1000]> というのは固定ということにして、
unsafe も避けられるものなら避けたい。

**デフォルトの名無しさん** · 2020/05/29(金) 17:24:59.34

>>587
vec![Default::default();1000].into_boxed_slice();

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

>>586
標準でString or &str のパース失敗時に返すErrの型とかあんの？

**デフォルトの名無しさん** · 2020/05/30(土) 00:58:42.40

vec! と同じような使い勝手の box! があってもよさそうな気がするけど、
そういうクレートがあったりする？

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

#![feature(box_syntax)]
let a: Box<[T; 1000]> = box [Default::default(); 1000];

https://github.com/rust-lang/rust/issues/53827

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

>>591
おおっ、これぞ私が必要としていたもの！

**デフォルトの名無しさん** · 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はそんなことはなかったが。