Rust part10

**デフォルトの名無しさん** · 2021/04/02(金) 21:38:04.11

Mozilla発のRust言語のスレ

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

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

日本語の情報
https://rust-jp.rs/

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

**デフォルトの名無しさん** · 2021/04/11(日) 10:47:22.32

んでバージョン指定変えてみたら

get_rangeの引数が最小、最大+1の２つから最小..最大+1の範囲リテラルに変わったのね

カンマを..に一ヵ所変えるだけだったから修正自体は対したことなかったけどオーバロードがあればもっと緩やかな改変が出来るのだろうか？
ゼロコスト抽象化の方針上仕方ないのだろうか？

**デフォルトの名無しさん** · 2021/04/11(日) 11:24:02.64

>>77
そんなしょうもない変更の為に互換性破壊したのか

**デフォルトの名無しさん** · 2021/04/11(日) 11:29:55.74

>>78
..= が使えるようになったとあるのでインターフェースの改善ではあるのでは
あと破壊的変更はこれだけではない
https://rust-random.github.io/book/update-0.8.html

**デフォルトの名無しさん** · 2021/04/11(日) 12:27:09.74

マイナーバージョンが上がるのでも結構変わると言うことか

**デフォルトの名無しさん** · 2021/04/11(日) 13:05:02.83

バージョン0のうちはね

**デフォルトの名無しさん** · 2021/04/11(日) 13:15:29.70

誰かも言ってたけどこう言うのは標準ライブラリで整備してほしい所だあな

**デフォルトの名無しさん** · 2021/04/11(日) 13:43:12.49

乱数は用途によってアルゴリズム使い分けにゃならんからなぁ
Cのrandはまぁ使えないとしてC++のrandomまで行くと重い

**デフォルトの名無しさん** · 2021/04/11(日) 14:40:26.89

randの設計が安定しない現状でstdに入れるにしても
かなり限定されたサブセットしか入れられないのでは

**デフォルトの名無しさん** · 2021/04/11(日) 17:41:37.63

それで十分だろ。
メルセンヌツイスターとか必要な場合は各々入れたら良い。
手軽な乱数を必要とする場面は割とある。

**デフォルトの名無しさん** · 2021/04/11(日) 21:41:09.50

メルセンヌ・ツイスタ、MT19937 を使っているのは、Ruby ぐらい

他の言語は、低品質

**デフォルトの名無しさん** · 2021/04/11(日) 22:30:00.44

一瞬信じかけたけど、pythonもboostもmtだったわ

**デフォルトの名無しさん** · 2021/04/11(日) 22:41:39.90

何でそんなとこで嘘つくん？

**デフォルトの名無しさん** · 2021/04/11(日) 23:24:19.82

>>85
直近でThreadRngやRngも破壊的変更されてて
乱数生成器の種類を充実させるとかそういうレベルにすら達してないのよ

**デフォルトの名無しさん** · 2021/04/12(月) 16:58:50.31

一部のプログラミング言語では、デフォルトの疑似乱数生成器としてメルセンヌ・ツイスタが
標準ライブラリに取り入れられている。そのような言語の例として、 Python,[2][3] Ruby,[4]
R,[5] PHP,[6] MATLAB, C++[7]（C++11から）がある。

**デフォルトの名無しさん** · 2021/04/12(月) 19:41:31.46

よそはよそ！うちはうち！

**デフォルトの名無しさん** · 2021/04/12(月) 21:18:15.82

線形合同が、あまりに低品質

**デフォルトの名無しさん** · 2021/04/12(月) 21:49:55.90

オライリー調査で明らかに--Go、Rust、Ruby、Dartに関心高まる - ZDNet Japan

https://japan.zdnet.com/article/35169143/

**デフォルトの名無しさん** · 2021/04/12(月) 22:02:51.56

fn main() {
let n = 100;

println!("{}", type_of(n));
}

これを実行すると
E0425: cannot find function `type_of` in this scope not found in this scope
になるのですがtype_ofは使えないのでしょうか？

rustc -V
1.51.0です

**デフォルトの名無しさん** · 2021/04/12(月) 22:08:31.70

すいません
とほほのRust入門見て解決しました
type_ofを関数として定義しないとダメなんですね

https://docs.rs/typed/1.0.0/typed/fn.type_of.html
にページがあったので組み込み関数があるものだと思いこんでたら
そういうものは存在しなくて,type_ofの関数を定義しないとダメだったようです

kindleで入門書を購入したのですがそこが省略されておりはまりました
失礼しました

**デフォルトの名無しさん** · 2021/04/12(月) 22:40:04.94

乱数ってxorshiftとかxoroshiroもあるわけで
まぁアルゴリズム固定は難しいでしょう

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

no_std環境も考えるともし一つ選ぶならMTよりxorshiftかなぁ。Rustの方針に合わないから入ることはないだろうけど。

**デフォルトの名無しさん** · 2021/04/13(火) 00:51:04.66

APIをどうするかどこまでリッチにするかとかも難しいんだろ

**デフォルトの名無しさん** · 2021/04/13(火) 01:57:46.80

xoroshiro1024がないんだよね。

>>95
```shell
rustup doc --std
```

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

パニックお断り―Linus，"Rust for Linux"の盛り上がりに釘を刺す
https://gihyo.jp/admin/clip/01/linux_dt/202104/15

**デフォルトの名無しさん** · 2021/04/15(木) 21:13:33.74

JavaScript／TypeScriptランタイム環境「Deno 1.9」がリリース、パフォーマンス向上に寄与する機能追加など
https://codezine.jp/article/detail/13970

**デフォルトの名無しさん** · 2021/04/16(金) 04:30:01.56

>>100
メモリの確保に失敗したくらいでpanicはしないが
alloc::alloc::Allocatorの一部メソッドはpanicするから
no_core上にpanicしないアロケータ実装すればよさそう。

コンパイル遅いのはキャッシュするしかない。

**デフォルトの名無しさん** · 2021/04/16(金) 09:28:25.44

結局kernelやるならunsafeつけまくりにしかならんだろ。
そうするとなぜrustで？という事になる。

**デフォルトの名無しさん** · 2021/04/16(金) 09:50:50.04

>>102
その「panicしないアロケータ」を使った Vec やらなんやら全部実装しなおさないといけなくならない？

**デフォルトの名無しさん** · 2021/04/16(金) 18:31:00.46

>>104
といっても変えるのはnewとかくらいで大半の実装はそのままもってくればいいんじゃない？
まあパッチ投げてる人もそこは作業量多いとは言ってるけど。

**デフォルトの名無しさん** · 2021/04/16(金) 18:54:38.72

>>104
Vec等のコンテナにはtry_reserveとかのメモリ割り当て失敗でエラーにする関数用意されているから
メモリ割り当ての失敗だけが問題ならliballocの使い方を変えるだけでよいのでは
他にpanic要因あるならだめだけど
ちなみにnewはメモリ割り当てしないから変更不要

**デフォルトの名無しさん** · 2021/04/16(金) 21:12:31.63

ある種の「コンテキストに対するunsafe」をつけて回らなきゃ無理。
でもってそれはmoonshotだって言ってるわな。
https://lkml.org/lkml/2021/4/14/1140

**デフォルトの名無しさん** · 2021/04/16(金) 21:47:54.90

特定の関数が割り込みのコンテキストから呼び出されたときにコンパイルエラーにすることは
今の言語機能では不可能という話か

**デフォルトの名無しさん** · 2021/04/16(金) 23:21:39.03

>>107
role orientedな言語でコンパイラが特別扱いする
コンテキストを指定できれば実現できる、
ここまで考えてだからmoonshotなのかと。

**デフォルトの名無しさん** · 2021/04/16(金) 23:46:26.48

Cでも出来てないことを要求してどうすんの

**デフォルトの名無しさん** · 2021/04/17(土) 00:54:40.80

知らんがな。どうしてもrustでkernel作りたいってやつに言えや。

**はちみつ餃子** ◆8X2XSCHEME · 2021/04/17(土) 02:30:05.79

Linux のカーネルはカーネルとは言ってもかなり巨大なので
現状の Rust でも採用可能な箇所もあるんでないの。
知らんけど。

**デフォルトの名無しさん** · 2021/04/17(土) 08:49:33.19

>>112
だからその考えでドライバーならということで始めたら上記の問題が出てきたってところだよ。
何周遅れてんだよ。

**デフォルトの名無しさん** · 2021/04/17(土) 09:05:35.37

グーグル、Linuxカーネル開発における「Rust」採用の動きをサポートする考え
https://japan.zdnet.com/article/35169455/

利用が進めば問題点も見えてくるし何らかの対策は追加されるだろうな

**デフォルトの名無しさん** · 2021/04/17(土) 09:33:32.53

linusすごいな
Rust関わってる人全員子供扱いかよ

**デフォルトの名無しさん** · 2021/04/17(土) 10:42:23.64

いや、これrustでkernelに関わろうとした人たちが低レイヤーのこと、あまりにわかってなさすぎだろ。。
これ、ほぼ素人の俺でも気づくような内容だぞ

**デフォルトの名無しさん** · 2021/04/17(土) 10:53:16.85

へぇ、すごいんですねぇー^^

**デフォルトの名無しさん** · 2021/04/17(土) 10:55:23.76

冷笑系気取りのバカって本当に救いようがないよな。

**デフォルトの名無しさん** · 2021/04/17(土) 11:09:22.71

C++でもコンテナに値を追加しようとすると、メモリー不足で追加に失敗
する可能性があるが、それをいちいちチェックする人はまず居ないだろうな。
デスクトップマシンでそれに失敗する可能性はとても低いけども。

**デフォルトの名無しさん** · 2021/04/17(土) 11:14:10.31

例えば、
std::vector<int> v; // 空の動的配列を生成
for ( unsigned int i = 0; i < 100000000; i++ ) {
v.push_back(i + 100); // 末尾に i + 100 という値を追加
}
とした場合、環境やマシンの状態によってはメモリー不足で失敗することは
あるだろうが、これをいちいちエラーチェックする人は少ないだろう。

**デフォルトの名無しさん** · 2021/04/17(土) 11:22:45.09

>>116
https://rust-lang.github.io/rfcs/2116-alloc-me-maybe.html

歴史的背景はこことか見ると書いてあるけど、処理系の初期開発で想定されていたほとんどの開発者はallocation errorから回復する必要がないから、あえてそういうAPIデザインにしたと
カーネルはその「ほとんど」から外れる用途だからlinusは当然今のAPIじゃダメだと釘を刺す

だからallocator_apiその他の安定化が急がれる、それだけの話じゃないの？

**デフォルトの名無しさん** · 2021/04/17(土) 11:25:00.56

linusへのレスポンス読んだ？
allocについては問題なのは認識してるけど
開発スピード上げるために今はliballoc使っていて
そのうち独自の物に置き換えると言っている

**デフォルトの名無しさん** · 2021/04/17(土) 11:27:24.53

pure rustでカーネル作ってる人いるんだから
原理的に不可能ってわけでもないだろ

**デフォルトの名無しさん** · 2021/04/17(土) 11:29:13.13

allocまで全部作り切ってからパッチ投げてLinusに却下って言われたら目も当てられんしな。プロトタイプの段階でこまめに出すのはいいと思う。

**デフォルトの名無しさん** · 2021/04/17(土) 11:37:37.77

>>120
伝統的なCでは、
char *ptr;
if ( (ptr = malloc(サイズ)) == NULL ) {　// (1)
　printf( "メモリ確保にしっぱいしたで～\n" );
}
それをC++で書くとすれば、
if ( (ptr = new char [サイズ]) == NULL ) {　// (2)
　printf( "メモリ確保にしっぱいしたで～\n" );
}
となるけれども、
v.push_back(i + 100);　// (3)
でメモリーエラーのエラーチェックしないのに(2)でしても余り意味はないという
考え方もあるわけでなので(2)と書かずにエラーチェック無しで
ptr = new char [サイズ];　// (4)
と書く方針もあっていいと思う。
なお、よっぽど大きなデータを扱わない限り、デスクトップマシンでは
(3)や(4)で失敗する可能性はとても低い。

**デフォルトの名無しさん** · 2021/04/17(土) 11:41:51.20

N88-BASICでは、読み込みモードでファイルを開く時、
open "ファイル名" for input as #1
と書いていたが、ファイルが存在しないとここでエラーになって
アプリが終了していたことを思い出した。
Perl、Ruby、Pythonなんかは、全て基本的に同じ方針だと思う。
その流儀とRustでのメモリー不足時のpanicの方針も同じと考えていいだろうな。

**デフォルトの名無しさん** · 2021/04/17(土) 11:48:23.17

>>121
そう、それだけの話。でもそれだけの話がここでは恐ろしく通じない。

**デフォルトの名無しさん** · 2021/04/17(土) 12:20:31.25

>>122
On allocation: this is just our usage of `alloc` in order to speed
development up -- it will be replaced (or customized, we have to
decide how we will approach it) with our own allocation and data
structures.

これのことか？
itってour usage of `alloc`のことじゃねーのと思ったけど、alloc自体のAPIデザインに問題があるみたいな話出てるの？

**デフォルトの名無しさん** · 2021/04/17(土) 13:30:05.64

>>125
> if ( (ptr = new char [サイズ]) == NULL ) {　// (2)
C++ は new も vector::push_back も bad_alloc が飛ぶ。ふつうの new は nullptr 返さない。

**デフォルトの名無しさん** · 2021/04/17(土) 13:35:37.75

てかアロケータの動作がどうのってLinux Kernel関係あるの？
ベアメタル用途全般が該当すると思うけど

**デフォルトの名無しさん** · 2021/04/17(土) 14:08:16.83

>>129
そういえば、言葉は忘れたけど、関数宣言の行に、その関数の中でどういう
例外が起きる可能性があるかについてのthrows を書くかどうか、書くべきか、
省略しても良いか、などの違いが色々あって、どういう言語仕様にすべきかが
結構問題になっていると聞いた。
すべてを書くと多くなりすぎるし、全く書かないのも問題だとか、そんな話。
なんという言葉だったかな。

**デフォルトの名無しさん** · 2021/04/17(土) 14:30:50.99

allocatorがエラーを返さずに例外を上げる挙動にRustの標準ライブラリ的なもの(コレクションとかスマートポインタとか？)が依存していて、
それはLinuxカーネル的には許容できないからそういうコードをそのまま持ち込むなよ？ということでしょ

Linuxカーネル上のC言語はそもそも標準ライブラリとか使わないし
メモリ確保もmallocじゃなくてkmallocというカーネル内独自関数使うし

ここ見ると
https://medium.com/nttlabs/linux-kernel-module-with-rust-d5363c2f9085
array: vec![0;32] で kmalloc が呼ばれるみたいだね
でもこれLinuxのカーネルモジュールのコードとしてはそこでエラーチェックが必要になるのかね？
もしくはkmallocに失敗したらそのモジュール自体が自動でアンロードされるとか
でもアンロードされるときに後処理とかしたいかなとかいろいろ考える必要はありそう

**はちみつ餃子** ◆8X2XSCHEME · 2021/04/17(土) 14:48:08.80

>>131
動的例外仕様 (dynamic exception specification) のことか？
https://timsong-cpp.github.io/cppwp/n3337/except.spec
送出される可能性のある例外を記述する仕組みだったが、役に立ってなかったので C++17 で廃止された。
(例外を送出するかしないかだけを指定する方式が残された。)

C++ の仕様では例外を送出しないという指定を付けたところを例外が通過しようとしたら
std::terminate が呼ばれて異常終了扱いになるという、実質的な assert なんだわ。
静的な検査をカッチリやってくれるわけではないんで、
カーネル記述みたいな文脈では使い物にならんな。

**デフォルトの名無しさん** · 2021/04/17(土) 14:49:51.36

linuxだろうとwindowsだろうと普通のカーネルはそうだろ。
よっぽど特殊用途のOSならどうかは知らんが。

**デフォルトの名無しさん** · 2021/04/17(土) 15:49:17.42

>>133
なんか、Javaにおいて、throwsに創出するすべての例外を書く仕様にしてみたら、
地獄のように沢山書かなくてはならなくなって困り、
関数プロトタイプ宣言の直後の throws()の中に
「書く必要のある例外」と「書かなくても良い例外」
の違いを設けることにした、この板で聞いた。

**デフォルトの名無しさん** · 2021/04/17(土) 15:56:30.53

>>135
「OutOfMemoryError」例外は、throws に明示しなくて良いことになった
とWikipediaで見た記憶が有る。

**はちみつ餃子** ◆8X2XSCHEME · 2021/04/17(土) 16:29:38.34

>>135
検査例外と非検査例外のことだな。

例外の便利なところは大域脱出が出来るところで、例外を捕捉する箇所と発生する箇所の間では例外のことを忘れられる点。
発生しうる例外の伝播を明示しないといけないのだと返却値で返す形にするのと差がない。
例外を使っていると異常系だということが見た目に分かり易いってくらいのもの。

Java が明示しなくてよい例外という分類を設けたのは明示しなくてよいというだけでなく捕捉もしなくてよいということでもあって、
どのように使い分けるのがよいかは諸説あるけども、非検査例外は

・捕捉したところで回復できないもの
・そもそもその例外を発生させないようにすべきもの (実質的には assert)

というのがおおよその共通認識になっている。
メモリ不足は回復不可能なので非検査例外に分類されているが、
「Java のレイヤでは」回復不可能という話であって、
Java では低レイヤを書かないという前提があるからこういう決め打ちが出来る。

低レイヤと高レイヤでは前提が違ってくるから同じようにはいかんのだ。

**デフォルトの名無しさん** · 2021/04/17(土) 16:34:30.24

>>136
https://www.w3resource.com/java-tutorial/types-of-exception.php

1. Checked exceptions
2. Unchecked exceptions
が有り、2. には、
2-1. Errors
2-2. Runtime exceptions
の2種類がある。
1はmethodシグネチャのthrowsの後に明示しなくてはならないが、
2は不要。1はプログラマが処理することが出来る場合が多いが、
2はとても難しいことが多い。
OutOfMemoryErrorは、2-1 に属し、throwsの後に明示する必要がないが
「2」なのでプログラマが対処することが難しい例外に分類される。

**はちみつ餃子** ◆8X2XSCHEME · 2021/04/17(土) 16:46:23.23

低レイヤでも高レイヤでも使うことを考えたらやっぱ例外という仕組みは使いにくいっつーことだな。
カーネルを書くにあたって Rust が (現状では) ベストというわけでもないだろうけど、
比較的可能性がある選択のひとつではあると思う。
どうせ標準ライブラリのフルセットを使えるわけではないのは C でも同じことだし。

**デフォルトの名無しさん** · 2021/04/17(土) 17:10:18.35

Rubyなんかでファイルオープンする時にはエラー発生チェックをしなくてもよくて
エラーが発生するとpanicする。これは簡単なプログラムでは便利。
そしてbegin,rescue,endではさめば、panicせずにエラー処理することも
出来る様になっている。これはtry,catch構文と発想は同じ。
でも、読み書き用の2つのファイルをオープンして読んで加工して書き込む
ような時、catch文でどっちのエラーか区別したりするのは面倒といえば面倒かな。
C風だと、fopen の行で処理できて分かり易かったのに。

**デフォルトの名無しさん** · 2021/04/17(土) 17:12:33.63

>>139
でも、リストに追加したときにメモリ不足になっても、例外機構でしか
エラーを補足出来ないのは面倒だな。

**デフォルトの名無しさん** · 2021/04/18(日) 02:29:17.84

ttps://github.com/rust-lang/rust-bindgen/commit/0e25962c4e69aef647e7275fa7bc7545dbb8cd0b#diff-b1a35a68f14e696205874893c07fd24fdb88882b47c23cc0e0c80a30c7d53759
コロコロ変わってその度に置換するスクリプト書いてるんだけど、
二ヶ月くらい音沙汰ないからそろそろ名前くらい安定してほしい。

**デフォルトの名無しさん** · 2021/04/18(日) 09:49:21.11

rustってそんなにいいか？
任意の場所でfreeできるcとは違って
ブロック抜けるタイミングでしかメモリ開放されないんだろ？
rustっていらなくなってもブロック抜けるまではヒープメモリ保持しないといけないってことなの？

**デフォルトの名無しさん** · 2021/04/18(日) 10:08:02.12

>>143
dropじゃだめなの？

**デフォルトの名無しさん** · 2021/04/18(日) 10:09:10.01

そんなに良くないからキミはもっとcを頑張ったほうがいい
cを頑張ってc++にも手を出して頑張って
気が狂いそうになるのを覚えてからもう一度来たらいい

**デフォルトの名無しさん** · 2021/04/18(日) 10:34:02.72

>>144
lifetime内であれば手動で早期開放できるんですね
お世話になりました

**デフォルトの名無しさん** · 2021/04/18(日) 12:33:31.22

ワロタw

**デフォルトの名無しさん** · 2021/04/18(日) 12:57:11.20

vectorにpushしながらその要素の可変参照を返すようなメソッドってあったりしますか？

**デフォルトの名無しさん** · 2021/04/18(日) 13:12:40.26

お前らの用途だったらgoで十分だろと思うことが多いわ。
ファッションでやるってのも悪くはないが。

**デフォルトの名無しさん** · 2021/04/18(日) 13:30:23.57

rustではunsafeを多用するのは良いことですか？

**デフォルトの名無しさん** · 2021/04/18(日) 13:39:58.68

必要なら使えばいい

**デフォルトの名無しさん** · 2021/04/18(日) 16:52:32.86

>>148
そういうメソッドはなさそう

特に理由がなければ分けて書いた方がいいけど、ブロック式を使って

let y = { v.push(x); v.last_mut().unwrap() }; // 変数に入れる場合
f({ v.push(x); v.last_mut().unwrap() }); // 関数に渡す場合

みたいな詰め方はできるかな
いっぱい使うならローカルなマクロ作ってもいい

macro_rules! push_and_mut_ref {
($v:expr, $x:expr) => {{ $v.push($x); $v.last_mut().unwrap() }};
}

let y = push_and_mut_ref!(v, x);

蛇足だけどyが生きてる間はvに触れないからご注意を

**デフォルトの名無しさん** · 2021/04/18(日) 17:30:23.89

>>152
>蛇足だけどyが生きてる間はvに触れないからご注意を

蛇足ではない気がする
push時にその要素のmut refを必要とするような書き方は避けたほうがいい

**デフォルトの名無しさん** · 2021/04/18(日) 17:38:05.52

entry APIみたいなことしたいのかな

**デフォルトの名無しさん** · 2021/04/19(月) 03:50:11.66

Rustに比べたC++の良さは雑に書けるところだって気付いた
やっぱ雑が許されない巨大プロジェクトはRustで、小規模な自分用ツールの類はC++で書いてくことになりそうだ

**デフォルトの名無しさん** · 2021/04/19(月) 08:44:54.89

>>155
いいところに気付いたな
Rustは一般プログラマーには無用の長物だ

**デフォルトの名無しさん** · 2021/04/19(月) 10:48:10.96

段階的に直していく方法と最初から設計で硬くしておく方法があると思うが
rustが念頭に置いてるのは明らかに後者。これがいいのか悪いのかは議論の余地がある。

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

型が強いからリファクタリングしやすいという意味では段々直していく方法に適しているとも言えると思うが

**デフォルトの名無しさん** · 2021/04/19(月) 11:21:50.23

>>158
型の強さがある意味で強すぎて、メモリ解放のタイミングまでキッチリあってないと無理なんだが。
ちょっとしたリファクタリングするにもかなり大域的変更になる。

**デフォルトの名無しさん** · 2021/04/19(月) 11:34:35.17

>>155
雑に書いた脆弱性のあるバイナリを世に出さなきゃそれでもいいんじゃね

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

>>160
何言ってんだこの馬鹿
Rust謹製なら脆弱性が無いとでも思ってんのか？

**デフォルトの名無しさん** · 2021/04/19(月) 13:06:52.92

つーかRust以前はどうしてたんだよって話ｗ
流行りのもんに飛びついてそれ以外見えなくなってる典型

**デフォルトの名無しさん** · 2021/04/19(月) 13:26:32.62

どうしてたって脆弱性を秘めたまま出回ってただろ

**デフォルトの名無しさん** · 2021/04/19(月) 13:27:33.53

いつものレイヤーとかスコープを
ごちゃまぜにする思考が乱雑な人でしょ

**デフォルトの名無しさん** · 2021/04/19(月) 14:27:55.78

それお前だろ

**デフォルトの名無しさん** · 2021/04/19(月) 16:41:05.18

まあ、C/C++が危なかろうが、自分のやりたい計算をするだけみたいな用途には向いてるよな
どうみても簡単で早いし・・・・

**デフォルトの名無しさん** · 2021/04/19(月) 16:57:54.64

>>155
C/C++は雑に書けるというより、Rustが想定してないでけで
本当は安全なプログラムも思った通りに書くことが出来る。
RustはRustが想定している範囲内でしか書けないので面倒なことになる。

**デフォルトの名無しさん** · 2021/04/19(月) 17:00:14.68

>>167
職人さんはさまざまな危険な道具を、十分安全に使う。
Rustは、「危険だ危険だ」と言って、危ない道具を使わせず
予め「刃(やいば)を抜かれた」道具の使用を強制する。

**デフォルトの名無しさん** · 2021/04/19(月) 17:08:36.65

AIの機械学習は計算が重いのに言語としては遅いところのPythonのAIは遅くはない。
なぜなら計算部分はC/C++で書かれたライブラリを呼び出して使ってるだけだから。
同様にRustがベンチマークで遅くないのは、実はunsafeモードで書かれたライブラリ
を使ってるせいもある。だからそのベンチマークだけでC/C++と同程度の速さ
であることの証明にはならない。

**デフォルトの名無しさん** · 2021/04/19(月) 17:33:10.17

>>169
具体的に何のベンチマークのことを言っているの？

**デフォルトの名無しさん** · 2021/04/19(月) 17:37:07.25

unsafeがライブラリに隠蔽されていてかつ性能が出ることはRustのコンセプトが正しかったことの証明になるのでは？

**デフォルトの名無しさん** · 2021/04/19(月) 17:58:35.97

今月のWEB+DB PRESSに載ってる簡易的なRDBMSをRustで実装する記事結構いいぞ

RDBMSの仕組みを学ぶことが主眼でRustの解説は最低限なんだけど
Rustでよく使うパターンが

**デフォルトの名無しさん** · 2021/04/19(月) 17:59:44.87

「じゃあC++使えばいいよ」で済む質問を何度投下すれば気が済むのか

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

だって入れ食いなんだもん…

**デフォルトの名無しさん** · 2021/04/19(月) 18:15:13.40

>>173
リトマス試験紙なんよ
C++で苦労した奴は文句は言わない。Rustが何をしてくれようとしてるのか分かるから。
C++ニワカは文句を言う。Rustが何をしてくれようとしてるのか分からないから。

**デフォルトの名無しさん** · 2021/04/19(月) 18:56:00.14

>>171
言ってる意味がまるでわからんのだが。

**デフォルトの名無しさん** · 2021/04/19(月) 19:29:57.41

大半の人は、C/C++で苦労も何もしてないだろう
何が危ないのかも理解しないまま、危険なコードや穴の空きやすいコードを書いてるだけだ