Rustアンチスレ
Hello World以上の事をやるとコンパイルが通らない()Rustのアンチスレです 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
P5EA8 なんで所有権の移動という一度しか起こらない元値を破壊するものが印なしで
参照の借用渡しが&にしたんだろう
ねえ 次世代言語スレのつづきか
安全なだけでめっちゃわかりづらいだろ
ふつうの=でコピーと動きが違いすぎる コピーはコストかかるから暗黙的なコピーは意図せぬ性能劣化を引き起こす可能性がある 暗黙のコピーと暗黙の参照渡しが区別つかないJavaで困らないんだから困らないのかもしれない javaで暗黙にコピーされるのは基本データ型だけでは ていうかJavaやC#は暗黙のdeep copyをしない件について: クソの中のクソ
キング・オブ・クソ
作ったゴミも使うカスも肥溜めで溺死すればいい haskellと同じ道をたどるだけだな。
馬鹿がなぜか選民思想やり出して終了。 >>3
>コンパイルさえ通してしまえばエラーが無いことを保証される。
そんなわけない。 Rustは、コンパイラ時エラーに悩まされる反面、実行時エラーに悩まされるのを減らす
などと言われる。
しかし、コンパイル時エラーが出ると言うことは、裏を返せば、書けないアルゴリズムが存在するということだ。
直感的ではない回りくどい書き方が必要となり記述量が多くなる。
他の言語では好きな書き方が出来て、それはどれも正解だが、Rustでは正解が非常に狭くなる。
正解が狭いことがエラーを減らすなどという人がいるが、実際には、Rustは
書けるアルゴリズムが狭い、と言うことなのである。
これは言語設計の問題である。
なお、ここで言っているアルゴリズムは、全体的なものではなく、細かいミクロ的なものである。
通常の言語では、1つの仕事を細かい変数の使い方まで含めれば数万通り以上に書けるだろう。
そして、そのどれもが正解であり、結果が正しくバグも無いのだから、内のどれかが悪い書き方という
ことは特にない。
ところが、Rustでは、その大部分の書き方が出来ないのである。
駄目だから敢えてできなくしているのではなく、Rustが設計上、書けないアルゴリズムがあるということに他ならない。
つまり、Rustは書けるアルゴリズムが、本来コンピュータが書けるアルゴリズムの内の、非常に狭いサブセットに限られてしまうということである。
これは、Rustの大きな欠陥である。 >>45
「駄目な書き方だからエラーにしている」
と言うのは間違いで、正しくは、
「Rustコンパイラの静的解析能力では、書き方を非常に限定しないと
正しいことを保障できなかったり、自動化できなかったりするため、
しょうがなく狭い書き方しか出来なくしている」
と言うことに他ならない。
人間には脳内の静的解析で明らかに正しいことが分かる書き方でも、
Rustコンパイラではでは同じことができないため、敢えて
変数束縛、借用、単一参照など、コンパイラでも解析できる程度の
範囲に書き方を限定して無理やり人間のプログラミングの可能性を
狭めているに過ぎない。 >>43
Rustは、Haskellから多くを借りてきているらしいから、Haskellと同じ
道をたどると言う予想はあながち間違ってない。 Rustは表面的に使うだけなら、まあ、C++が使えるプログラマなら、大体使えなくは無いだろう。
しかし、自分で独自にリンクリストを作ろうと思うと事態は一変する。
そこまで深く入った人ほど、Rustは難しい言語だと感じるはずで、
RustがC++程度で理解できると思ってる人は、99%、浅い所までしか使ってない
と言えよう。 >>49
RAD言語ならそれで良いが、システム言語では駄目。 Rustは、コンテナは、配列(長さがコンパイル段階で静的に決まる固定長)、
ベクター(動的配列)が主で、LinkedList<T>は、せっかくのリンクトリストの
特徴である末尾以外の「途中」への追加は出来ない。
これではリンクリストの意味が無い。
また、公式ドキュメントに
「ベクターの方がLinkedList<T>より速い」
などと書いてあるが、それはとんでもない間違い。 リンクリストを実装するのはこんなに難しく、
nextメンバの型は、Option<Rc<RefCell<Node<T>>>>
となる :
type Link<T> = Rc<RefCell<Node<T>>>;
#[derive(Debug)]
struct Node<T> {
value: T,
prev: Option<Link<T>>,
next: Option<Link<T>>,
}
impl<T> LinkedList<T> {
pub fn append(&mut self, v: T) {
let node = Node::new(v);
match self.tail.take() {
Some(old_tail) => {
old_tail.borrow_mut().next = Some(Rc::clone(&node));
node.borrow_mut().prev = Some(old_tail);
}
None => {
// first element
debug_assert_eq!(self.len(), 0);
self.head = Some(Rc::clone(&node));
}
}
self.tail = Some(node);
self.length += 1;
}
} 00年代半ばごろのゴミサイトがアクセス数を稼ぐのを思い出した
ゴミ Rustを含めた新手の言語の仕様が固まるまで、20年ぐらい掛かるからなぁ
今20代の連中がRustを使いこなせる様になっても、
システム開発に使える頃には、40過ぎの中年だけど、まだプログラマー続けてるの? レッツ!mut &mut もっと = したい:ダメな日本語; error[E0382]: use of moved value: `vector` 意識高い系が自己満足でめちゃくちゃなコードを他人に押し付ける言語 >>45
何かいいやり方があるはずだ。誰が見ても明らかな、たったひとつのやり方が。
そのやり方は一目見ただけではわかりにくいかもしれない。オランダ人にだけわかりやすいなんてこともあるかもしれない。
The Zen of Pythonの一節だけどRustの設計思想もこういうことなんじゃないか?
何通りもある書き方を統一することによってコードを読む人にも分かりやすくするってことだと思う。
もうそこは好みの問題だから気に入らなければやらないでいいんじゃないか? Rustは組み込みシステムでも非常に多く使われているように何でも書ける
Cと同様に低レベルな部分でも記述可能でさらにインラインアセンブリも可 raw pointer 使えるし C でできることはだいたい出来るのでは
できないのは variable length argument/array くらい? >>63
C/C++/Rust以外の言語ではどうやっても無理 なんかRustアンチは必要以上にunsafeを忌避してる気がする
unsafeは注意が必要な部分を限定するために用意された言語機能なのに
「unsafe使うならC/C++でいいじゃん」
とか考えてそうな雰囲気 unsafeブロック内でもボローチェッカは仕事するって知らん人多そう >>24
C++より便利で安全だから
例えると醤油とソースかな Rustスレでは場違いなので、イテレータというか高階関数の話にもう一度食いつくとする。
Juliaなんかだと並列・分散処理するために@distributed forなんて書くが、Erlangだとループ中に
spawnをして、Goもgoroutineを起動する。map/reduceなんかだと明らかにメニ―コアを使った方が
速いが、標準ではそうなっていなくて、外部ライブラリのrayonなどを使用する。
GoでもRustでもこれをさらに分散処理させるにはgRPCなど規格化されたインターフェースを通すが
やりたい事はJuliaの@distributed forなのに手間を感じさせる。
Rustにライトウェイトスレッドが言語仕様として入るとは思えないが、やはり言語には向き不向きが
存在する。近年のjavascriptを発端とするasync/awaitにも疑問が生じる。あまりにも多くの言語が
同期実行のライブラリと整合性が無さすぎる DSLと同等の使い勝手を汎用的な言語に求めるのはつらいのでは >>69
たしかにJavaScriptのasync/awaitとRustのは最も対照的ですがどちらも良い特徴があると思います
JavaScriptはブラウザも外部のNode.jsもその言語実行環境として非同期ランタイムが組み込まれasync/await導入以前から非同期関数が標準として装備
そのため非同期関数が呼ばれたら次のスケジュールで即座に実行が始まりますね
一方でRustは標準の非同期ランタイムがなく用途に合わせて自由に非同期ランタイムを用意することが出来ます
さらにRustのasync/await自体はゼロコストで設計されており非同期関数が呼ばれても自動的にスケジューリングされない特徴があります
Rustはこれらに関して「何ができない」のではなく「何でもできる」わけなので
あとは記法の簡易性を求めるのならばその呼び出し関数等の設計とマクロでお好みの方面へ寄せることも可能です >>71
これは良い書き方をしているが非同期ランタイムを自由に選べるのではなく、適切に選ばないと
インターフェースをサポートしない場合があるため、互換性が保てないでしょう。Rusterは
ゼロコストという話を良くしますが、Rustの非同期はタスクごとにステートマシンを作るために
確かにNode.jsなどと比べるjavascriptと比べれば、全体で非同期をスケジューリング管理する
ものと比べアロケーションや実行コストなどは小さいですが、それほど喧伝すべきことでもありません。
いずれにせよ多くの非同期はI/Oバウンドでありepollベースなどで管理されます。当然ながら
(Cに代わるようなハードウエア近い)システム言語なので出来ない事があってはイケていません。
私が言っているのは、Rustに限りませんがasync/awaitの記述が普通に考慮されてない設計の悪い
ライブラリが沢山あるという事です。Rustのマクロは最低だと思います、なぜわざわざ学習コストを
引き上げるのか理解できません >>72
あなたの主張は意味がわからない
まず「互換性が保てないでしょう」は何との何の互換性が保てないのか?意味不明
次に「それほど喧伝すべきことでもありません。」は結局のところあなたは反論すら出来ずに同意してしまっている
さらに「Rustに限りませんが(略)設計の悪いライブラリが沢山あるという事です。」はRust言語に対する批判にすらなっていない
それぞれ具体的に問題点を述べましょう 唐突にマクロが登場するのも分かりませんね
async-awaitがマクロだった頃の話をしているのですか? あんたの方が意味不明だけど(笑)
まず文書の書き方にケチを付けてロンパーする癖を直しましょう。
最初から非同期ランタイムの互換性と書いているでしょう。例えばasync-stdと
tokioは互換性がありません。今は互換性がほぼあるようになってきていますが
それでも完全ではありません。
ゼロコストFeatureという話は、VS Javascriptという言語のランタイムではその
通り認めていますが、コンパイル型の言語でコストが高い非同期は稀です。
Rust言語に対する批判しか書かないわけではありません。あなたは攻撃されたと
思い込む癖が強すぎる。「近年のjavascriptを発端とするasync/awaitにも疑問が
生じる。あまりにも多くの言語が同期実行のライブラリと整合性が無さすぎる」
という大本も読めない。まあそういう人間が増えすぎて居る訳で、こんな雑談で
怒り心頭になり、それぞれの具体的な問題点はあなたの性格でしょう。
言語的な反論をせずに文書の読解も出来ず、条件反射で相手を貶す。とてもでは
ないですが近寄りがたいですね
またマクロについても「マクロでお好みの方面へ寄せることも可能です」という
返答に関して感想を述べてるのに過ぎないのに、全く話を辿れていません。 >>75
具体的な問題点を述べましょう
例えばtokioの上に構築されたhttpモジュールであるhyperも互換レイヤーによりasync-std 上でも動作します
RustアンチスレでなぜJavaScriptを問題にしているのかも謎ですが
JavaScriptのasync/await/Promiseもあの環境で非常に優れて設計されています
この件についても具体的な問題点を述べておられないですね >>75
>「近年のjavascriptを発端とするasync/awaitにも疑問が生じる。
>あまりにも多くの言語が同期実行のライブラリと整合性が無さすぎる」
意味がちょっと不明です。
JavaScriptでそれらが用いられうる通信分野では、基本的に同期実行のライブラリは存在しません。
例えばhttpなどで取得してくるfetch()も非同期ですし、もっと低水準のモジュールも非同期です。
同期実行のライブラリと整合性が無さすぎるとは、何を意味しているのでしょうか? Rustって組み込み開発向いて無くね?
どう考えてもLinuxなりBSDなりある程度高度なOSがある事前提だ、OSのメモリーコンパクションが
無いとGCが無い故にメモリーの断片化が起こり、長時間稼働するタイプの小さな組み込みには向かない。
マイクロコントローラのメモリー付きSoCでブーストラップローダーがあるだけの組み込みには使えない
ま、サポートプラットフォームにTier1/Tier2でも、そういうのに使えるとは書いてないけど >>80
その文章だけならCにいれかえてもあってそうなんだが? >>80
つまりC/C++/Rustは組み込みやOSに向いていないとw それはリソースがたっぷりある組み込みのケースで感覚としてはアプリ開発に近い
組み込みはピンキリだからスクリプト言語が動く環境まである
一方でC/C++/Rustじゃないと厳しい環境もある >>75
同期実行ライブラリと整合性が無いというのはウソです
Rustでstd利用の同期とasync-std利用の非同期のプログラムはほとんど同じように書けます
例えば複数のファイルのチェックサム計算を同期と非同期の2通りに書いた以下の記事を参考にすると
https://qiita.com/osanshouo/items/671c45072a79c7b27aba
メイン部分の両者のdiffを取ると以下のような感じです
for entry in entries {
let entry = entry.unwrap();
if entry.file_type().unwrap().is_file() {
+ let handle = async_std::task::spawn(async move {
let filepath = entry.path();
- let mut file = fs::File::open(&filepath).unwrap();
+ let mut file = fs::File::open(&filepath).await.unwrap();
let bytes = {
let mut bytes = Vec::new();
- file.read_to_end(&mut bytes).unwrap();
+ file.read_to_end(&mut bytes).await.unwrap();
bytes
};
let checksum = bytes.iter().fold(0u8, |acc, b| acc.wrapping_add(*b));
println!("{:?}: {}", filepath.file_name().unwrap(), checksum);
+ });
+ handles.push(handle);
}
}
つまり差は2点のみ
非同期実行では不可欠なspawnがが入ることと
非同期を同期風に書けるようにするためのawaitが入ることだけです
おっしゃる『同期実行のライブラリと整合性が無さすぎる』との主張は間違っています コードの規模が大きくなると複雑さが増して相対的に知性下がるからバカが開発することを前提にした方が良い >>87
それは自覚症状が無いだけで自分が馬鹿なだけかも知れんが。 >>88
自分は馬鹿と思ってコード書いた方が良いよ本当に
これはバカにしてるとかじゃなくて心構えとして >>89は賢いお人
本来馬鹿は馬鹿を自覚できないから
平気でウンコを顔面につけたまま歩き回り
いろんなものを糞まみれにしてケロっとしてる >>89
お前と俺を一緒にスンナよ。
人間の頭脳は画一敵意ではなく差が大きい。 少なくともある程度以上の大きさの開発したことある人や
複数案件を同時進行した人なら
いくら完璧にしていても確率的にミスが入り込むとわかるはず
そしてC++とRustとの比較ならどちらが良いかも冷静に判断できる >>85
そんな事を言ってるんじゃないと思いますよ、「複数のファイルのチェックサム計算」なんて単純な事なら
当然ながら同期と非同期でそれほど違いは出ないでしょうし互換性があるように見えるでしょう。なぜなら
チェックサム計算は一瞬で終わり非同期はファイル毎に区切っているから。チェックサム計算は同期コードで
いずれも書かれていて1つも違いがありません。
これをいくつかのファイルは巨大でファイル長が不明(無限では無い)が大きいファイルのチェックサム計算や
より複雑で時間のかかる計算を非同期で行いたいとすればどうしますか?チェックサム計算で、read_to_endは
使えずストリームを非同期に読み続けて計算することになるでしょう。という事はbytes.iter().foldも使えません
「同期実行ライブラリと整合性が無いというのはウソです」このように言い切ること自体に"気持ち悪い信仰"を
持っているのは良く分かりますが、元が「整合性が無さすぎる」と言っているのは、整合性がある1パターンを
示しても意味が全く無いという事です。多くの問題は「ウソです」と言い切れる浅はかさが問題です
http://qiita.comの記事なんて初心者のサンプルに過ぎません >>93
確率的な話をするならコンパイラの塾制度考えた場合の確率を下回るくらいのメリットしかrustにはないよ。 >>95
rustcで検出できるバグを仕込む確率よりもrustcのバグを踏む確率の方が高いということ? rustcで検出できるバグよりcとのバインディングでの勘違いで生じるバグのが多いわな まあ静的チェックに過剰な期待してる奴は大抵クソだよ >>93
そのうち上位層はビジュアルプログラミングに取って代わられて行ったりしてね コンパイルチェックがゼロになるコードを書けるまでウンコ呼ばわりされる >80
>無いとGCが無い故にメモリーの断片化が起こり、長時間稼働するタイプの小さな組み込みには向かない。
ヒープも使わない(ことが多いから)、メモリーの断片化も起きない
当然GCなんかいらない
rustが組み込みに向かないのは同意する 小さなの規模にもよるけど
スタックや初期化時以外で動的なメモリ確保がそもそもできなくない?
Unix風のプロセスモデルでもないとmallocし続けるだけでアウト 組み込みの世界ではヒープじゃなくて、
リンクリストのノードを固定長メモリブロックとして使ったりする
例えばuItronのメモリプールの実装とかそんな感じ
ヒープはリアルタイム性がないから
で、rustはstatic mutが使い辛過ぎて、組み込みでは難しそう アンチスレとはいえ
将来性を考えると、さすがにD言語よりはrustの方が…… Deprecated
Dormant
Dead
縁起悪いよ…(´・ω・`) 言語と関係ないがrusterのこういう陰湿さが嫌、goに頻繁に嫌がらせしてるし、gcが選べるD言語など
まだまだマイナーな言語へ嫌がらせする >>106
将来を考えるなら、文字列でだらだら書くというスタイルが古臭いってなるかもね。
今のプログラミングは、分厚い本を読まされてる、書かされてるみたいなもん。
映像なら3秒でですむことを延々と書き連ねているようなもんだし。 永遠に可能性が無いとは言わないが、テキスト以外の方法は生まれては消えてを繰り返してるのでどうも期待出来無い。
人間がコード書く役割が終わる方が先に来るんじゃないかな。 >>112
AIでも同じようなことが言われていて、
囲碁で人間に勝つには100年かかるなんて言われてたからね。
>人間がコード書く役割が終わる
まさにそれ。
人間は「こうしたい」というのを表現できればそれで良いわけで、それをわざわざ文字列で延々と書き連ねるというのが古臭いことになるんじゃない?ってことね。 現状人間同士である程度厳密に情報を伝えようとすると言葉に頼るわけでコンピューター相手でもそこは変わらない気がする >>114
わざわざ人間が翻訳機になってるっていうのが古臭いって思うんよね。 >>114
文字によるプログラムっていうのが結局いつまで経っても1.5次元みたいなもんで、どことどこが関連しているのかということすらパッと見てわからないしね。
まあ、世の中には何百万行もあるプログラムでも簡単に目を通して全体像を把握できるような天才的な人もいるんだろうけど、私には無理だわ。
トシヨリガーとか、老害だとか言ってる割には旧来の手法に固執するんだな。 >>116
グラフィカルなプログラミング環境とか、設計手法だけどUMLとかあるにも関わらず一般的なプログラミング言語を置き換えるには至ってないよね
旧来の手法を置き換えるには何かしらのブレークスルーが必要なんだと思う
現状プログラミングが主に言葉で書かれているのは、人間がプログラムを考えていることと、人間の考えを厳密にコンピューターに伝える必要があることに由来していると思う
人工知能が発達して人間の曖昧な指示に従ってコンピューターがプログラミングするとか、脳波読みとりなど言語化なしで人間の考えを伝える手段が現れれるなどすれば状況は変わるかも知れない どの程度の複雑さをコンピュータ側に持って行っても、要求なり目的なりを記述する必要は残る。
いわゆる "プログラミング" では無いかもしれないが。
そこの記述はグラフィカルでどうのこうのと言っても汎用性を求めると結局はテキストになるんじゃないかな。
まあ要求記述のテキスト、というとSQLがその一つなんだけどさ。 >>118
で、現実にやってるのは、やれCだなんだと、それぞれの方言に合わせて人間が一生懸命翻訳作業をして文字列で書き起こしている。
客観的に見れば実に珍妙な記号とあるふぁべっの羅列でね。
そして、流行りの方言が出るたびにその方言を覚えては翻訳作業。
でも、結局のところコードが大幅に減るわけでもなく、肥大化するにつれて誰も正しい全体像を把握できなくなるのは同じこと。そして、いつまで経っても無くならない誤訳…バグの山。
やはりこのスタイル自体に無理がきているんだと思うわ。まあ、究極はコンピュータそのものの考え方から変えないとダメかもしれないけどね。 >>119
そのレベルの話だとコーディングと言うよりも設計の問題なのでは 自分がどうしたいってことしか考えないから、言語が要らないなんて言い出す。
受けとる方を考えてみろ。 CとリリースモードのRustは、どちらも実行時間が最小限です。 Cは未定義の動作でそこに到達します。 Rustは、非常に堅牢な言語定義を使用して、コンパイラーが多くの危険なプラクティスを拒否し、多くの望ましい結果を安全で比較的便利にすることを可能にします。
しかし、Rustは、多くの人が望ましくないと考える特定の動作も許可します。許可されるように言語を定義するだけです。たとえば、整数のオーバーフローを考えてみましょう。デバッグモードでは、Rustは整数のオーバーフローでパニックになります。良い。リリースモードでは、2の補数としてラップします。悪い。つまり、それは言語定義に含まれているので、非常に優れていますが、私に関する限り、これは、符号付き整数のオーバーフローを未定義の動作として参照するCおよびC++言語定義とほぼ同じくらい悪いものです。 >>122
Rustはそのために例えば足し算でも
checked_add
overflow_add
wrapping_add
saturating_add
など用途毎に使い分けられるようになっている
あかんところ列挙
・コンパイル型言語らしいけど、C++の方が速い(GCC万歳)
・CPLから派生した言語とかなり系統が違う(習得しづらい)
・関数宣言でわざわざfnをつけないといけない(文脈で理解できないのかコンパイラ)
以下、C++のあかんところ
・最近のは遅い->STL使わんかったらいい、もしくは自作
・バッファオーバーランとか、危ないことが起こる->そんな阿保プログラムを書かなかったらいい >>124
RustとC++はほぼ同等の速度
その上でRustは様々な安全性とC++より便利な機能によりプログラミング生産性も良い >>123
そういうことを言いたいんじゃない。releaseとdebugで動きが異なることを言いたいのだ。例えばGoなどはどちらも動きはわからない。
Rustはどう考えても、プログラムの1つ1つを完全に知りえていなければプログラムを書いてはならず、安全な側へ倒すのではなく、releaseでオーバーフローを省略するのにそれで速いとゴマカしている。計算系のベンチマークテストなどまさにそう
また上のように「用意している」という表現も、限りなく敷居をわざと高くしているだけで、何の利点でもない。 >>123
checked_add (=足し算でoverflowするとOption::Noneを返す) 便利だな
例としてすぐオーバーフローするi8型(符号付き8bit整数)を使って
フィボナッチ数列イテレータを書いてみた
fn fibonacci_i8() -> impl Iterator<Item=i8> {
itertools::unfold((0_i8, 1), |(m, n)|
m.checked_add(*n).map(|f| {
*m = *n;
*n = f;
f
})
)
}
fn main() {
for f in fibonacci_i8() {
print!("{f} ");
}
}
出力結果:
1 2 3 5 8 13 21 34 55 89
確かに上限127を超えて溢れる寸前まで求まっている