◎正当な理由による書き込みの削除について:      生島英之とみられる方へ:

Rustアンチスレ ->画像>1枚


動画、画像抽出 || この掲示板へ 類似スレ 掲示板一覧 人気スレ 動画人気順

このスレへの固定リンク: http://5chb.net/r/tech/1509028624/
ヒント:5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。

1デフォルトの名無しさん
2017/10/26(木) 23:37:04.08ID:9syp6YaG
Hello World以上の事をやるとコンパイルが通らない()Rustのアンチスレです
2デフォルトの名無しさん
2017/10/26(木) 23:40:36.83ID:LSWABSRs
Getting startedでもHello World以上のことはやってるんだから
あなたの触ってる言語がRustじゃない可能性のが高そうだね
3デフォルトの名無しさん
2017/10/27(金) 00:11:03.46ID:8v9HsLU9
コンパイルさえ通してしまえばエラーが無いことを保証される。
自動的な並列化によりメニーコア時代に対応。
メモ化サポート、動的計画法が自動的に実装できる、AI時代に必須。
Rust使いというだけで尊敬される、自動的に彼女ゲット。
C/C++の20倍高速。
4デフォルトの名無しさん
2017/10/27(金) 01:38:19.39ID:HS++Psw6
ただし扱えるのはモジラに選ばれた人間のみ
5デフォルトの名無しさん
2017/10/27(金) 01:59:27.69ID:zibA1NJ/
コンパイルすら通せない馬鹿が劣等感を爆発させた結果が>>1
6デフォルトの名無しさん
2017/10/27(金) 02:21:16.33ID:8v9HsLU9
Rustによって未来志向の意識世界に目覚めました。
いま核ミサイルの集中制御システムに携わっています。
Rustが世界を変える、Rustで世界を変える。
アッラーアクバール。
7デフォルトの名無しさん
2017/10/27(金) 09:45:57.32ID:T+eCoUsJ
Cは自分の頭や足を撃ち抜く危ない言語ってよく言うが、つまり銃レベルで強力ってことだよな

Rustはなんだ?ぼうっ切れか?たしかに銃と違って暴発したりはしないな
8デフォルトの名無しさん
2017/10/27(金) 18:02:33.63ID:cUZom3KZ
http://ha10.net/talk/1503389313.html
9デフォルトの名無しさん
2017/10/27(金) 18:02:45.00ID:697iydar
>>5
>>1だけどこのスレ建てたのは離隔目的だぞ
10デフォルトの名無しさん
2017/10/27(金) 19:54:56.14ID:Ql9mpjN/
どんな木っ端言語にもアンチがいるもんだなぁ(しみじみ)
11デフォルトの名無しさん
2017/10/29(日) 18:15:04.59ID:COmwxbJI
アンチを隔離するつもりが信者が捕獲されちゃったとかrustyなコードにありがちな本末転倒っぷり
12デフォルトの名無しさん
2017/10/30(月) 15:46:08.82ID:a0o0t6OO
>>10
本当に木っ端だったらなんも言わねえよ
モジラが言語自体をゴミクズのままにしておきながら
ステマに工数と金をぶっこんで自社ブランドの肥やしにして
それに騙されてゴミクズ掴まされる被害者がでてることに文句つけてるんだよ
13デフォルトの名無しさん
2017/10/30(月) 17:28:53.44ID:ExtYgMew
>>12をそっくりそのままGoを作ったGoogleに送りつけたい
14デフォルトの名無しさん
2017/11/05(日) 09:42:11.34ID:/OpyHVwj
>>12
え、go ぐらいシンプルな文法でも満足に使えんの?
馬鹿なんじゃないの?
15デフォルトの名無しさん
2018/02/10(土) 22:35:12.01ID:gZwa/8Tz
>>12をそっくりそのままSwiftを作ったAppleに送りつけたい
16デフォルトの名無しさん
2018/02/11(日) 09:24:51.51ID:YryqqCkE
>>11
Rustに傷つけられたアンチと戯れるスレだからね、仕方ないね

Swiftは騙されるアポー信者が多くてめっちゃウハウハだったな、Swiftやってますだけでクッソ仕事多かったのwww
Rustは、、、上流工程には知名度がなく、下流工程には難易度が高く、どこ行っても誰も騙せNEEEEEEEE
どこの業界(分野)に行けば騙されてくれる被害者がいますか?マジで教えてください
17デフォルトの名無しさん
2018/02/11(日) 20:02:48.65ID:JG+HYHMD
整数型からC-like enumに変換するのにtransmuteとかしないといけないのがクソ
enumをforループするだけのことが面倒なのもクソ
ボローチェッカーとの戦い(笑)以前に生産性低すぎるわこんなもん
C++を置き換えるとか言ってるやつは頭お花畑やろな
18デフォルトの名無しさん
2018/02/11(日) 20:26:21.53ID:PouFYKRN
>整数型からC-like enumに変換するのにtransmuteとかしないといけないのがクソ
だって実現方法はともかく意味的に整数はenumではないもの

>enumをforループするだけのことが面倒なのもクソ
forループしようと思う時点でそれはenumを使うべき場所でないのでは……
19デフォルトの名無しさん
2018/02/11(日) 21:47:14.09ID:YryqqCkE
unsafeなtransmuteなんて使う地雷に自ら突っ込んで行ったら生産性も落ちる罠

何をしようとしてenumメンバをforで回す機会があるのかサッパリ分からんが
生産性悪い書き方して生産性悪いと言ってるのはよく分かった
ちょっとオモロイから、生産性悪いと思った事例をもっと教えてくれよ
20デフォルトの名無しさん
2018/02/11(日) 23:22:44.25ID:18bG+VQL
アンチアンチ
21デフォルトの名無しさん
2018/02/12(月) 11:06:57.76ID:+5PXSpLD
俺は賢いからunsafeだって使いこなせるぜ、transmute使うぜ
結果、メモリ非安全で生産性悪いRustクソ!!!!

俺はアホだから危ないunsafe使うのやめよ、整数型からenumにするのはfn new使おう
結果、メモリ安全で生産性良いなー

Rustはアホ向けの学習難易度の低い言語だった可能性が微レ存?
22デフォルトの名無しさん
2018/02/12(月) 13:03:15.96ID:JDol8IEk
普通の人間はアホか賢人に分類すると、だいたいアホ側がふさわしいからな。
無理する奴がバグを生む。俺はアホで良い。
23デフォルトの名無しさん
2018/02/12(月) 19:04:43.26ID:1V20MNhs
ちょっと検索すればenumのvariantsをループで回す方法でてくる
enumの定義時にマクロを使って全メンバーを含む配列も同時に定義するなどがある
これだけをやってくれるcrateも作れそうだ
24デフォルトの名無しさん
2018/02/14(水) 22:58:26.65ID:0r3oW/nt
C++が車だとしたらRustはせいぜいゴーカートだなぁ
25デフォルトの名無しさん
2018/02/16(金) 06:49:37.38ID:W1XJdyx1
☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が3分の2を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆
26デフォルトの名無しさん
2018/02/22(木) 15:21:57.27ID:H839Tp+8
C++がカーチスだとしたらRustはフォルゴーレな印象
27デフォルトの名無しさん
2018/02/23(金) 17:07:47.78ID:ZuaVfjvd
つまり、どっかの豚しか乗りこなせないのか…
28デフォルトの名無しさん
2018/05/23(水) 20:21:30.55ID:Au5e7VGg
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』

P5EA8
29デフォルトの名無しさん
2018/07/05(木) 01:24:10.02ID:RfoszcD2
6YB
30デフォルトの名無しさん
2018/07/16(月) 21:36:50.20ID:LulkQD8r
なんで所有権の移動という一度しか起こらない元値を破壊するものが印なしで
参照の借用渡しが&にしたんだろう

ねえ
31デフォルトの名無しさん
2018/07/18(水) 21:34:09.40ID:uzHZzsnA
moveは安全なのに何が問題だと感じるの?
32デフォルトの名無しさん
2018/07/19(木) 20:56:32.22ID:zpCf8yuT
次世代言語スレのつづきか
安全なだけでめっちゃわかりづらいだろ
ふつうの=でコピーと動きが違いすぎる
33デフォルトの名無しさん
2018/07/21(土) 00:47:19.79ID:mSZJjtkc
コピーはコストかかるから暗黙的なコピーは意図せぬ性能劣化を引き起こす可能性がある
34デフォルトの名無しさん
2018/07/21(土) 04:00:07.64ID:PpAF+dgy
暗黙のコピーと暗黙の参照渡しが区別つかないJavaで困らないんだから困らないのかもしれない
35デフォルトの名無しさん
2018/07/21(土) 23:33:24.37ID:SCDZUWz8
javaで暗黙にコピーされるのは基本データ型だけでは
36デフォルトの名無しさん
2018/07/23(月) 21:30:42.22ID:2ez6F7EW
C#でも困んないし
37デフォルトの名無しさん
2019/07/28(日) 18:59:39.61ID:5UHV96py
JavaとC#にはGCがあるからな
38デフォルトの名無しさん
2019/07/28(日) 19:00:55.44ID:5UHV96py
ていうかJavaやC#は暗黙のdeep copyをしない件について:
39デフォルトの名無しさん
2019/07/29(月) 21:44:34.57ID:CSar0obt
Rustアンチスレ 	->画像>1枚
40デフォルトの名無しさん
2019/07/30(火) 00:56:59.74ID:ZDjzCSg/
>>39
グロ
41デフォルトの名無しさん
2019/10/30(水) 14:37:39.93ID:4EQH++wv
クソの中のクソ
キング・オブ・クソ
作ったゴミも使うカスも肥溜めで溺死すればいい
42デフォルトの名無しさん
2020/03/21(土) 17:46:30.14ID:vJ0Lurek
無能がほざいてて気分いいわ
43デフォルトの名無しさん
2020/03/21(土) 17:51:42.22ID:20ZHUxLS
haskellと同じ道をたどるだけだな。
馬鹿がなぜか選民思想やり出して終了。
44デフォルトの名無しさん
2020/03/21(土) 18:38:21.24ID:txJMIm7g
>>3
>コンパイルさえ通してしまえばエラーが無いことを保証される。
そんなわけない。
45デフォルトの名無しさん
2020/03/25(水) 01:29:02.87ID:COJzGufp
Rustは、コンパイラ時エラーに悩まされる反面、実行時エラーに悩まされるのを減らす
などと言われる。
しかし、コンパイル時エラーが出ると言うことは、裏を返せば、書けないアルゴリズムが存在するということだ。
直感的ではない回りくどい書き方が必要となり記述量が多くなる。
他の言語では好きな書き方が出来て、それはどれも正解だが、Rustでは正解が非常に狭くなる。
正解が狭いことがエラーを減らすなどという人がいるが、実際には、Rustは
書けるアルゴリズムが狭い、と言うことなのである。
これは言語設計の問題である。

なお、ここで言っているアルゴリズムは、全体的なものではなく、細かいミクロ的なものである。
通常の言語では、1つの仕事を細かい変数の使い方まで含めれば数万通り以上に書けるだろう。
そして、そのどれもが正解であり、結果が正しくバグも無いのだから、内のどれかが悪い書き方という
ことは特にない。
ところが、Rustでは、その大部分の書き方が出来ないのである。
駄目だから敢えてできなくしているのではなく、Rustが設計上、書けないアルゴリズムがあるということに他ならない。
つまり、Rustは書けるアルゴリズムが、本来コンピュータが書けるアルゴリズムの内の、非常に狭いサブセットに限られてしまうということである。
これは、Rustの大きな欠陥である。
46デフォルトの名無しさん
2020/03/25(水) 01:29:24.10ID:COJzGufp
>>45
「駄目な書き方だからエラーにしている」
と言うのは間違いで、正しくは、
「Rustコンパイラの静的解析能力では、書き方を非常に限定しないと
 正しいことを保障できなかったり、自動化できなかったりするため、
 しょうがなく狭い書き方しか出来なくしている」
と言うことに他ならない。
人間には脳内の静的解析で明らかに正しいことが分かる書き方でも、
Rustコンパイラではでは同じことができないため、敢えて
変数束縛、借用、単一参照など、コンパイラでも解析できる程度の
範囲に書き方を限定して無理やり人間のプログラミングの可能性を
狭めているに過ぎない。
47デフォルトの名無しさん
2020/03/25(水) 01:31:01.16ID:COJzGufp
>>43
Rustは、Haskellから多くを借りてきているらしいから、Haskellと同じ
道をたどると言う予想はあながち間違ってない。
48デフォルトの名無しさん
2020/03/25(水) 01:41:15.64ID:COJzGufp
Rustは表面的に使うだけなら、まあ、C++が使えるプログラマなら、大体使えなくは無いだろう。

しかし、自分で独自にリンクリストを作ろうと思うと事態は一変する。

そこまで深く入った人ほど、Rustは難しい言語だと感じるはずで、
RustがC++程度で理解できると思ってる人は、99%、浅い所までしか使ってない
と言えよう。
49デフォルトの名無しさん
2020/03/25(水) 08:33:39.98ID:atIoOIeM
道具として正しい在り方だな
50デフォルトの名無しさん
2020/03/25(水) 12:40:37.43ID:COJzGufp
>>49
RAD言語ならそれで良いが、システム言語では駄目。
51デフォルトの名無しさん
2020/08/28(金) 02:41:24.81ID:BFWbiW8H
Rustは、コンテナは、配列(長さがコンパイル段階で静的に決まる固定長)、
ベクター(動的配列)が主で、LinkedList<T>は、せっかくのリンクトリストの
特徴である末尾以外の「途中」への追加は出来ない。
これではリンクリストの意味が無い。
また、公式ドキュメントに
「ベクターの方がLinkedList<T>より速い」
などと書いてあるが、それはとんでもない間違い。
52デフォルトの名無しさん
2020/08/28(金) 17:13:22.85ID:BFWbiW8H
リンクリストを実装するのはこんなに難しく、
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;
  }
}
53デフォルトの名無しさん
2021/01/08(金) 10:57:50.09ID:4h6DBvmg
00年代半ばごろのゴミサイトがアクセス数を稼ぐのを思い出した


ゴミ
54デフォルトの名無しさん
2021/05/05(水) 10:12:10.05ID:Icux/Qfe
可読性低いな
55デフォルトの名無しさん
2021/06/18(金) 18:36:38.41ID:GgPo8kME
Rustを含めた新手の言語の仕様が固まるまで、20年ぐらい掛かるからなぁ

今20代の連中がRustを使いこなせる様になっても、

システム開発に使える頃には、40過ぎの中年だけど、まだプログラマー続けてるの?
56デフォルトの名無しさん
2021/06/30(水) 12:11:47.40ID:TGFkopCB
レッツ!mut &mut もっと = したい:ダメな日本語;
57デフォルトの名無しさん
2021/07/07(水) 23:28:03.78ID:3EDdhBYW
error[E0382]: use of moved value: `vector`
58デフォルトの名無しさん
2021/07/16(金) 02:31:03.20ID:UUn46lBk
もうお前のRustコード直すの嫌だわ
59デフォルトの名無しさん
2021/07/21(水) 02:06:52.85ID:DO3wSfvm
意識高い系が自己満足でめちゃくちゃなコードを他人に押し付ける言語
60デフォルトの名無しさん
2021/08/10(火) 09:03:54.83ID:fPg8NGNP
>>45
何かいいやり方があるはずだ。誰が見ても明らかな、たったひとつのやり方が。
そのやり方は一目見ただけではわかりにくいかもしれない。オランダ人にだけわかりやすいなんてこともあるかもしれない。

The Zen of Pythonの一節だけどRustの設計思想もこういうことなんじゃないか?
何通りもある書き方を統一することによってコードを読む人にも分かりやすくするってことだと思う。
もうそこは好みの問題だから気に入らなければやらないでいいんじゃないか?
61デフォルトの名無しさん
2021/08/10(火) 09:10:56.61ID:UUhRSoFC
Rustは組み込みシステムでも非常に多く使われているように何でも書ける
Cと同様に低レベルな部分でも記述可能でさらにインラインアセンブリも可
62デフォルトの名無しさん
2021/08/10(火) 14:11:34.30ID:mSeKT5En
raw pointer 使えるし C でできることはだいたい出来るのでは
できないのは variable length argument/array くらい?
63デフォルトの名無しさん
2021/08/11(水) 07:11:51.41ID:KlEtC9pi
そりゃunsafeすればなんでもかけるわ
64デフォルトの名無しさん
2021/08/11(水) 07:16:15.10ID:N49Uco17
>>63
C/C++/Rust以外の言語ではどうやっても無理
65デフォルトの名無しさん
2021/08/12(木) 10:28:40.81ID:whMOJJYX
なんかRustアンチは必要以上にunsafeを忌避してる気がする

unsafeは注意が必要な部分を限定するために用意された言語機能なのに
「unsafe使うならC/C++でいいじゃん」
とか考えてそうな雰囲気
66デフォルトの名無しさん
2021/08/12(木) 10:57:49.37ID:tXISMw6z
unsafeブロック内でもボローチェッカは仕事するって知らん人多そう
67デフォルトの名無しさん
2021/09/04(土) 03:57:00.95ID:kn1l/Q+t
>>24
いや、自走車椅子だろ
68デフォルトの名無しさん
2021/09/04(土) 04:05:22.28ID:iqtSb51S
>>24
C++より便利で安全だから
例えると醤油とソースかな
69デフォルトの名無しさん
2021/09/06(月) 13:53:51.27ID:kq9rR1L5
Rustスレでは場違いなので、イテレータというか高階関数の話にもう一度食いつくとする。

Juliaなんかだと並列・分散処理するために@distributed forなんて書くが、Erlangだとループ中に
spawnをして、Goもgoroutineを起動する。map/reduceなんかだと明らかにメニ―コアを使った方が
速いが、標準ではそうなっていなくて、外部ライブラリのrayonなどを使用する。
GoでもRustでもこれをさらに分散処理させるにはgRPCなど規格化されたインターフェースを通すが
やりたい事はJuliaの@distributed forなのに手間を感じさせる。
Rustにライトウェイトスレッドが言語仕様として入るとは思えないが、やはり言語には向き不向きが
存在する。近年のjavascriptを発端とするasync/awaitにも疑問が生じる。あまりにも多くの言語が
同期実行のライブラリと整合性が無さすぎる
70デフォルトの名無しさん
2021/09/06(月) 14:51:17.48ID:6RpN+EMp
DSLと同等の使い勝手を汎用的な言語に求めるのはつらいのでは
71デフォルトの名無しさん
2021/09/06(月) 16:49:04.49ID:7r7RF488
>>69
たしかにJavaScriptのasync/awaitとRustのは最も対照的ですがどちらも良い特徴があると思います
JavaScriptはブラウザも外部のNode.jsもその言語実行環境として非同期ランタイムが組み込まれasync/await導入以前から非同期関数が標準として装備
そのため非同期関数が呼ばれたら次のスケジュールで即座に実行が始まりますね

一方でRustは標準の非同期ランタイムがなく用途に合わせて自由に非同期ランタイムを用意することが出来ます
さらにRustのasync/await自体はゼロコストで設計されており非同期関数が呼ばれても自動的にスケジューリングされない特徴があります

Rustはこれらに関して「何ができない」のではなく「何でもできる」わけなので
あとは記法の簡易性を求めるのならばその呼び出し関数等の設計とマクロでお好みの方面へ寄せることも可能です
72デフォルトの名無しさん
2021/09/11(土) 00:36:45.81ID:YO3o85Uj
>>71
これは良い書き方をしているが非同期ランタイムを自由に選べるのではなく、適切に選ばないと
インターフェースをサポートしない場合があるため、互換性が保てないでしょう。Rusterは
ゼロコストという話を良くしますが、Rustの非同期はタスクごとにステートマシンを作るために
確かにNode.jsなどと比べるjavascriptと比べれば、全体で非同期をスケジューリング管理する
ものと比べアロケーションや実行コストなどは小さいですが、それほど喧伝すべきことでもありません。
いずれにせよ多くの非同期はI/Oバウンドでありepollベースなどで管理されます。当然ながら
(Cに代わるようなハードウエア近い)システム言語なので出来ない事があってはイケていません。
私が言っているのは、Rustに限りませんがasync/awaitの記述が普通に考慮されてない設計の悪い
ライブラリが沢山あるという事です。Rustのマクロは最低だと思います、なぜわざわざ学習コストを
引き上げるのか理解できません
73デフォルトの名無しさん
2021/09/11(土) 01:17:56.12ID:PRM8i6LA
>>72
あなたの主張は意味がわからない
まず「互換性が保てないでしょう」は何との何の互換性が保てないのか?意味不明
次に「それほど喧伝すべきことでもありません。」は結局のところあなたは反論すら出来ずに同意してしまっている
さらに「Rustに限りませんが(略)設計の悪いライブラリが沢山あるという事です。」はRust言語に対する批判にすらなっていない
それぞれ具体的に問題点を述べましょう
74デフォルトの名無しさん
2021/09/11(土) 01:24:36.44ID:Q/hQI3Xf
唐突にマクロが登場するのも分かりませんね
async-awaitがマクロだった頃の話をしているのですか?
75デフォルトの名無しさん
2021/09/11(土) 01:41:58.05ID:YO3o85Uj
あんたの方が意味不明だけど(笑)
まず文書の書き方にケチを付けてロンパーする癖を直しましょう。

最初から非同期ランタイムの互換性と書いているでしょう。例えばasync-stdと
tokioは互換性がありません。今は互換性がほぼあるようになってきていますが
それでも完全ではありません。

ゼロコストFeatureという話は、VS Javascriptという言語のランタイムではその
通り認めていますが、コンパイル型の言語でコストが高い非同期は稀です。

Rust言語に対する批判しか書かないわけではありません。あなたは攻撃されたと
思い込む癖が強すぎる。「近年のjavascriptを発端とするasync/awaitにも疑問が
生じる。あまりにも多くの言語が同期実行のライブラリと整合性が無さすぎる」
という大本も読めない。まあそういう人間が増えすぎて居る訳で、こんな雑談で
怒り心頭になり、それぞれの具体的な問題点はあなたの性格でしょう。
言語的な反論をせずに文書の読解も出来ず、条件反射で相手を貶す。とてもでは
ないですが近寄りがたいですね

またマクロについても「マクロでお好みの方面へ寄せることも可能です」という
返答に関して感想を述べてるのに過ぎないのに、全く話を辿れていません。
76デフォルトの名無しさん
2021/09/11(土) 02:11:46.06ID:w5S7rLqj
>>75
具体的な問題点を述べましょう
例えばtokioの上に構築されたhttpモジュールであるhyperも互換レイヤーによりasync-std 上でも動作します

RustアンチスレでなぜJavaScriptを問題にしているのかも謎ですが
JavaScriptのasync/await/Promiseもあの環境で非常に優れて設計されています
この件についても具体的な問題点を述べておられないですね
77デフォルトの名無しさん
2021/09/11(土) 11:03:00.32ID:LLoV+Okg
>>75の勝ち
以上
78デフォルトの名無しさん
2021/09/11(土) 13:53:10.45ID:zUj2TAiQ
>>75
>「近年のjavascriptを発端とするasync/awaitにも疑問が生じる。
>あまりにも多くの言語が同期実行のライブラリと整合性が無さすぎる」

意味がちょっと不明です。
JavaScriptでそれらが用いられうる通信分野では、基本的に同期実行のライブラリは存在しません。
例えばhttpなどで取得してくるfetch()も非同期ですし、もっと低水準のモジュールも非同期です。
同期実行のライブラリと整合性が無さすぎるとは、何を意味しているのでしょうか?
79デフォルトの名無しさん
2021/09/11(土) 13:59:42.94ID:QGVH5OH8
発端と言ったらC#の方が古くね
80デフォルトの名無しさん
2021/09/12(日) 14:45:35.48ID:dsndgRWH
Rustって組み込み開発向いて無くね?
どう考えてもLinuxなりBSDなりある程度高度なOSがある事前提だ、OSのメモリーコンパクションが
無いとGCが無い故にメモリーの断片化が起こり、長時間稼働するタイプの小さな組み込みには向かない。
マイクロコントローラのメモリー付きSoCでブーストラップローダーがあるだけの組み込みには使えない
ま、サポートプラットフォームにTier1/Tier2でも、そういうのに使えるとは書いてないけど
81デフォルトの名無しさん
2021/09/12(日) 15:02:08.52ID:raaoGYn7
>>80
その文章だけならCにいれかえてもあってそうなんだが?
82デフォルトの名無しさん
2021/09/12(日) 15:22:52.56ID:lBuMyCBZ
>>80
つまりC/C++/Rustは組み込みやOSに向いていないとw
83デフォルトの名無しさん
2021/09/12(日) 15:26:04.82ID:Cf6Jz1Ay
そこで組み込みのために開発されたJavaですよw
84デフォルトの名無しさん
2021/09/12(日) 21:57:41.77ID:UrK9UNLE
それはリソースがたっぷりある組み込みのケースで感覚としてはアプリ開発に近い
組み込みはピンキリだからスクリプト言語が動く環境まである
一方でC/C++/Rustじゃないと厳しい環境もある
85デフォルトの名無しさん
2021/09/12(日) 22:17:14.89ID:Zjk1d74X
>>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が入ることだけです
おっしゃる『同期実行のライブラリと整合性が無さすぎる』との主張は間違っています
86デフォルトの名無しさん
2021/09/12(日) 22:19:55.41ID:s09Gb+ph
設計にバカが関わってなければC++で十分
87デフォルトの名無しさん
2021/09/12(日) 22:44:56.06ID:Q5FBinyU
コードの規模が大きくなると複雑さが増して相対的に知性下がるからバカが開発することを前提にした方が良い
88デフォルトの名無しさん
2021/09/13(月) 20:47:01.12ID:dBMpD8or
>>87
それは自覚症状が無いだけで自分が馬鹿なだけかも知れんが。
89デフォルトの名無しさん
2021/09/13(月) 20:51:25.89ID:9PNw/wOW
>>88
自分は馬鹿と思ってコード書いた方が良いよ本当に
これはバカにしてるとかじゃなくて心構えとして
90デフォルトの名無しさん
2021/09/14(火) 19:27:55.83ID:kyozNdb6
>>89は賢いお人

本来馬鹿は馬鹿を自覚できないから
平気でウンコを顔面につけたまま歩き回り
いろんなものを糞まみれにしてケロっとしてる
91デフォルトの名無しさん
2021/09/14(火) 20:13:08.96ID:Wng5bteL
>>89
お前と俺を一緒にスンナよ。
人間の頭脳は画一敵意ではなく差が大きい。
92デフォルトの名無しさん
2021/09/14(火) 23:33:28.66ID:9cp1Eg6y
微笑ましい
93デフォルトの名無しさん
2021/09/14(火) 23:52:38.24ID:BSh8VTqx
少なくともある程度以上の大きさの開発したことある人や
複数案件を同時進行した人なら
いくら完璧にしていても確率的にミスが入り込むとわかるはず
そしてC++とRustとの比較ならどちらが良いかも冷静に判断できる
94デフォルトの名無しさん
2021/09/15(水) 02:02:19.36ID:x4RgVtnC
>>85
そんな事を言ってるんじゃないと思いますよ、「複数のファイルのチェックサム計算」なんて単純な事なら
当然ながら同期と非同期でそれほど違いは出ないでしょうし互換性があるように見えるでしょう。なぜなら
チェックサム計算は一瞬で終わり非同期はファイル毎に区切っているから。チェックサム計算は同期コードで
いずれも書かれていて1つも違いがありません。
これをいくつかのファイルは巨大でファイル長が不明(無限では無い)が大きいファイルのチェックサム計算や
より複雑で時間のかかる計算を非同期で行いたいとすればどうしますか?チェックサム計算で、read_to_endは
使えずストリームを非同期に読み続けて計算することになるでしょう。という事はbytes.iter().foldも使えません

「同期実行ライブラリと整合性が無いというのはウソです」このように言い切ること自体に"気持ち悪い信仰"を
持っているのは良く分かりますが、元が「整合性が無さすぎる」と言っているのは、整合性がある1パターンを
示しても意味が全く無いという事です。多くの問題は「ウソです」と言い切れる浅はかさが問題です
http://qiita.comの記事なんて初心者のサンプルに過ぎません
95デフォルトの名無しさん
2021/09/15(水) 11:47:44.97ID:PYzW5a+n
>>93
確率的な話をするならコンパイラの塾制度考えた場合の確率を下回るくらいのメリットしかrustにはないよ。
96デフォルトの名無しさん
2021/09/15(水) 20:26:11.48ID:77IP/X5S
>>95
rustcで検出できるバグを仕込む確率よりもrustcのバグを踏む確率の方が高いということ?
97デフォルトの名無しさん
2021/09/15(水) 21:21:02.30ID:PYzW5a+n
rustcで検出できるバグよりcとのバインディングでの勘違いで生じるバグのが多いわな
98デフォルトの名無しさん
2021/09/16(木) 00:37:37.41ID:Efcezeu+
まあ静的チェックに過剰な期待してる奴は大抵クソだよ
99デフォルトの名無しさん
2021/09/18(土) 06:51:34.59ID:pceSJQ2d
>>93
そのうち上位層はビジュアルプログラミングに取って代わられて行ったりしてね
100デフォルトの名無しさん
2021/09/18(土) 07:04:45.25ID:WtcFUHdh
Rustのスレで何を頓珍漢な
101デフォルトの名無しさん
2021/09/25(土) 03:20:19.87ID:r08K7R9X
コンパイルチェックがゼロになるコードを書けるまでウンコ呼ばわりされる
102デフォルトの名無しさん
2021/10/20(水) 16:37:55.38ID:rOkBuggn
>80
>無いとGCが無い故にメモリーの断片化が起こり、長時間稼働するタイプの小さな組み込みには向かない。

ヒープも使わない(ことが多いから)、メモリーの断片化も起きない
当然GCなんかいらない
rustが組み込みに向かないのは同意する
103デフォルトの名無しさん
2021/10/20(水) 19:56:54.98ID:VGECjsMp
小さなの規模にもよるけど
スタックや初期化時以外で動的なメモリ確保がそもそもできなくない?
Unix風のプロセスモデルでもないとmallocし続けるだけでアウト
104デフォルトの名無しさん
2021/10/20(水) 20:18:24.99ID:rOkBuggn
組み込みの世界ではヒープじゃなくて、
リンクリストのノードを固定長メモリブロックとして使ったりする
例えばuItronのメモリプールの実装とかそんな感じ
ヒープはリアルタイム性がないから

で、rustはstatic mutが使い辛過ぎて、組み込みでは難しそう
105デフォルトの名無しさん
2021/10/20(水) 20:22:41.04ID:VyYhhIkP
D言語も忘れないで下さい。
106デフォルトの名無しさん
2021/10/20(水) 20:37:31.19ID:rOkBuggn
アンチスレとはいえ
将来性を考えると、さすがにD言語よりはrustの方が……
107デフォルトの名無しさん
2021/10/20(水) 22:36:34.87ID:VyYhhIkP
D言語:「忘れないで・・・」
108デフォルトの名無しさん
2021/10/20(水) 22:52:38.54ID:UtWr6ljA
Deprecated
Dormant
Dead
縁起悪いよ…(´・ω・`)
109デフォルトの名無しさん
2021/10/21(木) 18:37:53.89ID:wlIxx6Dc
言語と関係ないがrusterのこういう陰湿さが嫌、goに頻繁に嫌がらせしてるし、gcが選べるD言語など
まだまだマイナーな言語へ嫌がらせする
110デフォルトの名無しさん
2021/10/21(木) 20:22:29.58ID:s+sF4o2E
Dのことマイナーって呼ぶなよ
111デフォルトの名無しさん
2021/10/22(金) 20:07:55.54ID:BGSpAusK
>>106
将来を考えるなら、文字列でだらだら書くというスタイルが古臭いってなるかもね。
今のプログラミングは、分厚い本を読まされてる、書かされてるみたいなもん。
映像なら3秒でですむことを延々と書き連ねているようなもんだし。
112デフォルトの名無しさん
2021/10/22(金) 21:52:45.50ID:v3Yxx0iq
永遠に可能性が無いとは言わないが、テキスト以外の方法は生まれては消えてを繰り返してるのでどうも期待出来無い。
人間がコード書く役割が終わる方が先に来るんじゃないかな。
113デフォルトの名無しさん
2021/10/23(土) 08:17:48.59ID:126WIPxs
>>112
AIでも同じようなことが言われていて、
囲碁で人間に勝つには100年かかるなんて言われてたからね。
>人間がコード書く役割が終わる
まさにそれ。
人間は「こうしたい」というのを表現できればそれで良いわけで、それをわざわざ文字列で延々と書き連ねるというのが古臭いことになるんじゃない?ってことね。
114デフォルトの名無しさん
2021/10/23(土) 08:56:15.06ID:3BoTC/ER
現状人間同士である程度厳密に情報を伝えようとすると言葉に頼るわけでコンピューター相手でもそこは変わらない気がする
115デフォルトの名無しさん
2021/10/25(月) 17:46:30.13ID:a6PpXdhO
>>114
わざわざ人間が翻訳機になってるっていうのが古臭いって思うんよね。
116デフォルトの名無しさん
2021/10/25(月) 17:54:38.98ID:a6PpXdhO
>>114
文字によるプログラムっていうのが結局いつまで経っても1.5次元みたいなもんで、どことどこが関連しているのかということすらパッと見てわからないしね。
まあ、世の中には何百万行もあるプログラムでも簡単に目を通して全体像を把握できるような天才的な人もいるんだろうけど、私には無理だわ。

トシヨリガーとか、老害だとか言ってる割には旧来の手法に固執するんだな。
117デフォルトの名無しさん
2021/10/25(月) 20:15:43.78ID:cubP7NbG
>>116
グラフィカルなプログラミング環境とか、設計手法だけどUMLとかあるにも関わらず一般的なプログラミング言語を置き換えるには至ってないよね
旧来の手法を置き換えるには何かしらのブレークスルーが必要なんだと思う

現状プログラミングが主に言葉で書かれているのは、人間がプログラムを考えていることと、人間の考えを厳密にコンピューターに伝える必要があることに由来していると思う
人工知能が発達して人間の曖昧な指示に従ってコンピューターがプログラミングするとか、脳波読みとりなど言語化なしで人間の考えを伝える手段が現れれるなどすれば状況は変わるかも知れない
118デフォルトの名無しさん
2021/10/25(月) 20:53:20.91ID:IG0eAPOa
どの程度の複雑さをコンピュータ側に持って行っても、要求なり目的なりを記述する必要は残る。
いわゆる "プログラミング" では無いかもしれないが。
そこの記述はグラフィカルでどうのこうのと言っても汎用性を求めると結局はテキストになるんじゃないかな。

まあ要求記述のテキスト、というとSQLがその一つなんだけどさ。
119デフォルトの名無しさん
2021/10/28(木) 17:10:44.11ID:nJ3D7u2B
>>118
で、現実にやってるのは、やれCだなんだと、それぞれの方言に合わせて人間が一生懸命翻訳作業をして文字列で書き起こしている。
客観的に見れば実に珍妙な記号とあるふぁべっの羅列でね。
そして、流行りの方言が出るたびにその方言を覚えては翻訳作業。
でも、結局のところコードが大幅に減るわけでもなく、肥大化するにつれて誰も正しい全体像を把握できなくなるのは同じこと。そして、いつまで経っても無くならない誤訳…バグの山。

やはりこのスタイル自体に無理がきているんだと思うわ。まあ、究極はコンピュータそのものの考え方から変えないとダメかもしれないけどね。
120デフォルトの名無しさん
2021/10/28(木) 17:37:46.17ID:oV3TAAYO
>>119
そのレベルの話だとコーディングと言うよりも設計の問題なのでは
121デフォルトの名無しさん
2022/02/26(土) 07:53:14.27ID:BV4vpVpG
自分がどうしたいってことしか考えないから、言語が要らないなんて言い出す。

受けとる方を考えてみろ。
122デフォルトの名無しさん
2022/04/27(水) 15:55:20.74ID:1aIRuPS7
CとリリースモードのRustは、どちらも実行時間が最小限です。 Cは未定義の動作でそこに到達します。 Rustは、非常に堅牢な言語定義を使用して、コンパイラーが多くの危険なプラクティスを拒否し、多くの望ましい結果を安全で比較的便利にすることを可能にします。

しかし、Rustは、多くの人が望ましくないと考える特定の動作も許可します。許可されるように言語を定義するだけです。たとえば、整数のオーバーフローを考えてみましょう。デバッグモードでは、Rustは整数のオーバーフローでパニックになります。良い。リリースモードでは、2の補数としてラップします。悪い。つまり、それは言語定義に含まれているので、非常に優れていますが、私に関する限り、これは、符号付き整数のオーバーフローを未定義の動作として参照するCおよびC++言語定義とほぼ同じくらい悪いものです。
123デフォルトの名無しさん
2022/04/27(水) 16:14:27.17ID:fXEX2s7j
>>122
Rustはそのために例えば足し算でも
checked_add
overflow_add
wrapping_add
saturating_add
など用途毎に使い分けられるようになっている
124デフォルトの名無しさん
2022/04/27(水) 18:36:40.62ID:HjqqO7sC?2BP(0)

あかんところ列挙
・コンパイル型言語らしいけど、C++の方が速い(GCC万歳)
・CPLから派生した言語とかなり系統が違う(習得しづらい)
・関数宣言でわざわざfnをつけないといけない(文脈で理解できないのかコンパイラ)
以下、C++のあかんところ
・最近のは遅い->STL使わんかったらいい、もしくは自作
・バッファオーバーランとか、危ないことが起こる->そんな阿保プログラムを書かなかったらいい
125デフォルトの名無しさん
2022/04/27(水) 18:45:52.15ID:kbMyQ47R
>>124
RustとC++はほぼ同等の速度
その上でRustは様々な安全性とC++より便利な機能によりプログラミング生産性も良い
126デフォルトの名無しさん
2022/04/27(水) 18:53:45.96ID:DngKLmNp
>>123
そういうことを言いたいんじゃない。releaseとdebugで動きが異なることを言いたいのだ。例えばGoなどはどちらも動きはわからない。
Rustはどう考えても、プログラムの1つ1つを完全に知りえていなければプログラムを書いてはならず、安全な側へ倒すのではなく、releaseでオーバーフローを省略するのにそれで速いとゴマカしている。計算系のベンチマークテストなどまさにそう
また上のように「用意している」という表現も、限りなく敷居をわざと高くしているだけで、何の利点でもない。
127デフォルトの名無しさん
2022/04/27(水) 18:55:26.96ID:j3SjDNhs
>>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を超えて溢れる寸前まで求まっている
128デフォルトの名無しさん
2022/04/27(水) 18:57:07.63ID:DngKLmNp
このようにわざと貼り付けなくても良いことを書いて、不都合を指摘すると流すようにするのは本当に良くないコミュニティの態度
129デフォルトの名無しさん
2022/04/27(水) 19:00:24.43ID:QwtQyiYP
>>127と同じ関数を他のプログラミング言語で書くとどんなコードになるの?
具体的にコードを比較して客観的に判断したい
130デフォルトの名無しさん
2022/04/27(水) 22:32:13.33ID:Xa5DwGtB
>>126
release buildでもチェック有効にできるよ
https://doc.rust-lang.org/cargo/reference/profiles.html#overflow-checks

プログラムの一つ一つを理解しなくても書ける言語ってどういうものだろう
131デフォルトの名無しさん
2022/05/19(木) 17:01:33.84ID:YoVN/Jlg
>>125
今どきのC++は遅いっていうけど、新しいC++の仕様を使うからである。
つまり、Better Cみたいな使い方をすればRustより速くなる(実際そういう結果もある)。
まあ、体感はどっちもかわんねえべってとこだから、RustよりJava,C#とかスクリプト言語をアンチすればいいと思う。Rustで慣れてる人はRustで書けばいい。
132デフォルトの名無しさん
2022/05/21(土) 23:22:45.63ID:zNzebGu9
C++が遅いってコンパイル時間の話ちゃうん
133デフォルトの名無しさん
2022/05/23(月) 00:46:57.32ID:Fl/zPM6P
なんでJavaやC#がスクリプト言語に入ってんだ?
C#にはC#スクリプトがあるが実行時に中間言語にコンパイルするだけだろ
134デフォルトの名無しさん
2022/05/23(月) 00:55:18.95ID:Fl/zPM6P
一度だけ必要なメモリを確保して使い回せるものを
オブジェクトとして生成、消滅繰り返すようなプログラム組むと(普通にC++でかくとこっちになる)遅くなるよ
挙句の果てにメモリフラグメントが避けられない
普通にCで書くとよほどの馬鹿でも無い限り無駄なメモリ確保開放を繰り返すなんてことはしないから
135デフォルトの名無しさん
2022/05/23(月) 01:27:08.69ID:aUQlcplw
>>134
領域使い回せるってことは生成・解放するオブジェクトのサイズはだいたい一定なんだと思うけど
そうだとしたら最近の普通のmalloc実装ならそうそうフラグメント起こすことはない気がするけどどうなんだろ
ベンチマークとかあるの?
136デフォルトの名無しさん
2022/05/23(月) 01:35:14.45ID:Fl/zPM6P
>>135
行列クラス考えてみろ
while(1)
E = A*B+C/D
C++なら一行でかけるが
137デフォルトの名無しさん
2022/05/23(月) 01:45:51.46ID:Fl/zPM6P
誤送信
>>135
行列クラス考えてみろ
while(1)
E = A*B+C/D;
C++なら一行でかけるがテンポラリ領域を演算子の多重定義の中で確保開放繰り返さざるをえない
ETでなんとかなる部分もinverseがあるとそれもお手上げ
一時領域をwhileの外で確保してそれを使い回す方法と比べて早くしようがない。
138デフォルトの名無しさん
2022/05/23(月) 01:48:39.79ID:Fl/zPM6P
>>135
>普通のmalloc実装ならそうそうフラグメント起こすことはない

ヒープの動的確保でフラグメント興さないなら
RTOSでメモリプール確保する必要なんてないよなww
139デフォルトの名無しさん
2022/05/23(月) 02:08:18.18ID:aUQlcplw
>>137
速度に関してはC++の方が不利なことに対しては異論ないよ
ただフラグメントについては本当にそうなのか気になってた

今時のmallocなら直近にfreeされた領域再利用するから>>137みたいな例なら毎回同じ領域が割り当てられると思うよ
寿命が異なる複数のオブジェクトの確保・解放を繰り返すようなケースでも、オブジェクトが同サイズであればmalloc自体のフラグメントを防ぐ機構がうまく働いてくれるはず

まあ確かにRTOSのmalloc実装では問題起こるかもしれないけどね
ただ、そういうのは "最近の普通のmalloc" ではないと思う
140デフォルトの名無しさん
2022/05/23(月) 02:25:01.02ID:Fl/zPM6P
>>139
なんで同じ領域が確保されると保証されるのさ。今時のOSでww
そのエリアが外のタスクで割り当てられなかったことがなんで保証できるんだ?
とにかく動的確保、削除してフラグメント起こさないと思ってる方がどうかしてる。
そういう思い込みが通用するなら、所有権なんてもんは必要ないだろ。
あれはデフラグの対象にするかどうかが細大の目的

あと、普通のとか今時のとか、お前のあたのなかこっちは見られないんだから使うのやめろ
141デフォルトの名無しさん
2022/05/23(月) 02:44:22.59ID:Fl/zPM6P
>>137
>速度に関してはC++の方が不利

これもちょっと違うだろ
上で>>131が言ってるようにBetter cに留めて。
過度な見やすさや書きやすさを追求しなければ
C++はC機能包含してるんでC++で不利になることなんてない。
機能を使わなければいいんで不利になりようがない。
Pure C流ででもかけるわけだし
142デフォルトの名無しさん
2022/05/23(月) 08:16:07.89ID:aUQlcplw
>>140
とりあえずglibcのmallocでいいや
>>137のような解放直後に同じサイズで領域を確保する場合は領域再利用されるよね
143デフォルトの名無しさん
2022/05/23(月) 09:11:41.94ID:n2ZPTBPD
// ヒープを使う型Testを作って実証実験
#[derive(Debug)]
struct Test(Box<isize>);

// Test型が作成される時に使われるnew()を実装
impl Test {
fn new(n: isize) -> Self {
let new = Test(Box::new(n));
// その時にヒープで確保されたアドレスを表示
println!("{:p} = Test::new({n})", new.0);
new
}
}

// Test型の足し算を実装
impl std::ops::Add for Test {
type Output = Self;
fn add(self, rhs: Self) -> Self::Output {
Test::new(*self.0 + *rhs.0)
}
}

// 足し算の途中で使われる一時領域のアドレスはどうなるか?
fn main() {
let a = Test::new(1);
let b = Test::new(10);
let c = Test::new(100);
let d = Test::new(1000);
let e = Test::new(10000);
println!("{:?}", a + b + c + d + e);
}
144デフォルトの名無しさん
2022/05/23(月) 09:17:13.61ID:n2ZPTBPD
実行結果
0x55790623d9d0 = Test::new(1)
0x55790623d9f0 = Test::new(10)
0x55790623da10 = Test::new(100)
0x55790623da30 = Test::new(1000)
0x55790623da50 = Test::new(10000)
0x55790623da70 = Test::new(11)
0x55790623d9d0 = Test::new(111)
0x55790623da70 = Test::new(1111)
0x55790623d9d0 = Test::new(11111)
Test(11111)

つまり足し算で中間生成される一時的な領域は再利用されて使い回されていることが確認された
したがって>>140の主張がおかしい
145デフォルトの名無しさん
2022/05/23(月) 09:54:21.07ID:n2ZPTBPD
一般的に、今回のような多段の計算の場合は、中間領域が少なくとも2つ必要となる
なぜなら、一般的には「中間値2=中間値1+次の項目」と順に計算していくためである
つまり一般的な場合は、5つの変数の足し算ならば、中間値2つを加えて、計7つの領域を必要とする

しかし>>144の結果のアドレスを見ると、確かに中間値は交互にアドレスが異なり2種類だが、全体で6つの領域で済んでいるところに注目
5つの変数の領域は避けられないから、余分に確保されたのは1つのみで済んでいる
これがRust

今回用意したTest型はCopyを実装しなかったため、最初の「中間値1=a+b」を計算した時点てaとbは消費されてそれらの領域は解放される
そのため次の「中間値2=中間値1+c」の時に、中間値2の領域として既に解放されたaの領域が使われた
実際に中間値2のアドレスがaと同じになっていることで確認できる
同様に中間値3は中間値1と同じアドレスとなっている

結論
Rustでは消費し終えた変数や中間値が使用していたヒープ領域もすぐに再利用されて使い回されるため、
>>137のようなケースでも最小限のメモリしか必要とせずに済む
146デフォルトの名無しさん
2022/05/23(月) 11:54:34.12ID:n+tkR/ue
glibc mallocの仕様なのでCやC++でも同じです
147デフォルトの名無しさん
2022/05/23(月) 14:37:05.11ID:GiQn/B1E
Rubyを長期間動かすとGCがメモリを
細分化してしまうという話かなんかと
混同してんのかな
148デフォルトの名無しさん
2022/05/23(月) 15:10:34.13ID:K4XvBL00
>>145
> しかし>>144の結果のアドレスを見ると、確かに中間値は交互にアドレスが異なり2種類だが、全体で6つの領域で済んでいるところに注目
7つ使ってるように見えるんだけど、何を見て6つで済んでるって言えるの?
149デフォルトの名無しさん
2022/05/23(月) 15:44:46.83ID:dNJCbMGg
たぶん1行目も0x55790623d9d0なのを見落としてる
150デフォルトの名無しさん
2022/05/23(月) 15:46:07.93ID:wWZ2mUik
>>148
よく見ると2番目の中間値であるTest::new(111)のアドレスが変数aつまりTest::new(1)のアドレスと同じ
これはRust特有でその時点では変数a(や変数b)を使い終えて解放されているために再利用されたと推測できる
そのため6つメモリ領域で済んでいるのだろう

>>146
CやC++では使い終わった変数の領域が暗黙的には解放されないから7つのメモリ領域を使うと予想
151デフォルトの名無しさん
2022/05/23(月) 15:51:35.00ID:K4XvBL00
>>149-150 あ、ほんとだありがとう。
152デフォルトの名無しさん
2022/05/23(月) 16:28:21.49ID:wuIMUAe9
試しに>>143で中間値をもう一つ必要とする例でやってみた
println!("{:?}", (a + b) + (c + d) + e);
メモリ1 = Test::new(1)
メモリ2 = Test::new(10)
メモリ3 = Test::new(100)
メモリ4 = Test::new(1000)
メモリ5 = Test::new(10000)
メモリ6 = Test::new(11) // (a + b)
メモリ1 = Test::new(1100) // (c + d)
メモリ3 = Test::new(1111) // (a + b) + (c + d)
メモリ6 = Test::new(11111) // (a + b) + (c + d) + e
即座に解放された変数領域を2つ使う点で異なるが結果的に計6つ使用に収まっているな
153デフォルトの名無しさん
2022/05/24(火) 10:09:58.38ID:PPYrRT7r
https://wandbox.org/permlink/tYewWGlffMON9jxK

ところでこの結果とフラグメンテーションって特に関係あるんですかね
154デフォルトの名無しさん
2022/05/30(月) 14:58:44.37ID:MKPVbFKD
>>144
>>145
なーにを馬鹿な考察してんの?
おまえの実行するタスクの途中で他のタスクが実行され、そいつが解放したヒープを確保しないことを
なんで今時のマルチタスク、マルチユーザOSで保証できるのかと言ってる。
155デフォルトの名無しさん
2022/05/30(月) 15:12:27.13ID:MKPVbFKD
>>145
>Rustでは消費し終えた変数や中間値が使用していたヒープ領域もすぐに再利用されて使い回されるため

変数が確保されるのは関数コールの度に毎回上書きされるスタックであてtヒープではない
そもそもヒープ領域の確保廃棄で何も問題なければメモリフラグメントなど発生するはずがない。
したがって長期間リブートを想定しないRTOSで、
予めメモリプールを確保してその中で固定的にメモリ割り当てなど行うこと自体全くの無意味ってことだが、
現実はそーじゃない。こんなもんエンベ試験あたりのイロハだろw
156デフォルトの名無しさん
2022/05/30(月) 15:42:14.93ID:9QWL5Xmb
>>154
マルチタスク、マルチユーザーOSというキーワードが出てくるのがよくわからないけど、
物理アドレスの話してるとしたらスタックだろうがヒープだろうがOSの都合で変わりうるんだからヒープのフラグメントの話とはなんら関係ないよね

仮想アドレスの話をしているなら、自プロセスの他スレッドの挙動によってフラグメントしうると言うのは正しいけど
だいたいのmalloc実装ではarenaはスレッドローカルになるからフラグメントは置きにくいと思うよ

というか、どういうシチュエーションで何を実験したときにどのような問題が起きたのか、前提を明確にしてよ
組み込みのRTOSとかいう特殊環境が当たり前のように語られると意見のすりあわせができぬ
157デフォルトの名無しさん
2022/05/30(月) 15:55:38.95ID:MKPVbFKD
>>142
> >>137のような解放直後に同じサイズで領域を確保する場合は領

なんで、マルチタスクのOSが、おまえの都合のいいタイミングで解法直後に確保できるのかと言ってる。
例えば、解法直後に割込タスクがおまえのプログラムを一時実行停止し、
そこで開放したばかりのメモリエリアを確保しないとなんで言い切れるんだと聞いてる。

そして、ページングの発生もなんでおこらないと決めてかかってるんだ? 今時のOSでww
おまえが書き出したメモリエリアはあくまでプログラム側から見た論理アドレスだろ?
そこが実はページング対象になってなかったとなぜ断言できるんだ。
158デフォルトの名無しさん
2022/05/30(月) 15:57:12.40ID:MKPVbFKD
>>156
>物理アドレスの話してるとしたらスタックだろうがヒープだろうがOSの都

プログラムからは論理アドレスしか見えない
同じ領域を確保してるかどうかはプログラムからはわからない
159デフォルトの名無しさん
2022/05/30(月) 16:07:33.52ID:MKPVbFKD
>>156
>マルチタスク、マルチユーザーOSというキーワードが出てくるのがよくわからないけど

汎用OSで自分の起動したタスクしか動いてないと思ってるわけ?
RTOSを持ち出したのは自分のタスクしか実行していなくても、フラグメントを起こす具体例として持ち出した。
そのRTOSでも細心の実装心掛けてるのに汎用OSなんでいわずもがなって話。
今時は、HWのメモリが大きくなってせいぜいページング時のプチフリーズ程度で気付いてない奴もいるだろうが、
やっぱりフラグメントは常時発生してる。
てか、メモリデフラグとか動かしたことないのか?
160デフォルトの名無しさん
2022/05/30(月) 16:23:56.84ID:S6YD6bxt
それなんかRustと関係あるんすか?
161デフォルトの名無しさん
2022/05/30(月) 16:55:49.66ID:ccLFuKy8
>>154
まずは基礎知識を勉強しよう
Rustにおいてタスクとは非同期にスケジューリングされるスタックレスなコルーチンのこと
そうでない意味のタスクならばプログラミング言語Rustとは関係ない話

>>155
そのRustプログラム例はBoxを使っているのでスタック上てはなくちゃんとヒープを用いた実験となっている
そんな基本的なことも理解できないならば勉強して出直してきなさい

>>159
それはRustとは全く無関係ない話
基礎的なことを会得していないとそういった無関係な話を持ち出してしまう
162デフォルトの名無しさん
2022/05/30(月) 18:21:04.97ID:9QWL5Xmb
>>157
ページサイズより大きい領域の獲得解放を繰り返す想定で良いのかな?
malloc/freeがmmap/munmap呼び出しと一対一対応するような
で、どのOSの実装で問題が起きたの?
163デフォルトの名無しさん
2022/05/30(月) 22:33:20.68ID:SMH6yVl4
ページ単位で割り当てるのにどうやってフラグメンテーション起こすんだろう
164デフォルトの名無しさん
2022/05/31(火) 14:19:31.88ID:X/NoC31E
じゃあなんでLinuxやBSD、Windowsはメモリコンパクション機能を実装してるの?
165デフォルトの名無しさん
2022/05/31(火) 14:23:20.93ID:5HfxTPdy
>>164 LinuxやBSD、Windowsはメモリコンパクション機能を実装してるの?
166デフォルトの名無しさん
2022/05/31(火) 16:38:22.49ID:COFqsPBY
なんで、mallocの話がOSの話とすり替わってたの?
167デフォルトの名無しさん
2022/05/31(火) 19:29:31.55ID:6cb4XAup
>>140あたりでもう一緒くたにされてるからしょうがない
たぶん誰も問題意識を共有できてない
168デフォルトの名無しさん
2022/05/31(火) 20:07:12.82ID:qkI00F5r
たぶんmallocとOSが密に関連するようなRTOS?が前提なんだと思うよ
>>140は業務で触ってるとかで特性をよく知っているがそのコンテキストが他の人と共有できていないのだろう
169デフォルトの名無しさん
2022/05/31(火) 20:16:37.40ID:/PJVfDdU
ずっと暴れている>>140だけが『所有権』と『OS』を同時に登場させていて二つの別レイヤのメモリ管理の話を区別できていない
ここはRustアンチスレなのにプログラミング言語Rustとは無関係な話で暴れていている
170デフォルトの名無しさん
2022/05/31(火) 21:05:52.27ID:ycu/V5YM
便乗すんな複おじ
171デフォルトの名無しさん
2022/05/31(火) 22:22:41.63ID:qkI00F5r
まあ所有権の話は唐突でよく分かんないけど彼の中では理屈的に繋がりがあるのではないのかな
もうちょっと丁寧に書いてくれれば分かりそうな気もするんだけど
172デフォルトの名無しさん
2022/07/07(木) 09:23:29.02ID:kCv7I/gK
あーうぜー
1.61.0ビルドしてるけどなんだかいろいろとボコボコDLしてくる()
1.61.0なのに 1.60.0-xxx をDLしてくるし()

あーうぜー
173デフォルトの名無しさん
2022/07/09(土) 14:07:59.53ID:52J5yu6r
いつのまにかpython module のビルドに入り込んでるのな

悪質
174デフォルトの名無しさん
2022/08/26(金) 16:38:04.30ID:IVLb+hqW
腐れ言語

早く外せよ
175デフォルトの名無しさん
2022/09/04(日) 20:06:08.29ID:9yOWYxc4
なんか第二Javaという感じの臭いがする
非人間的な設計で人間を不幸にしていく悪しき文明というか
176デフォルトの名無しさん
2022/09/07(水) 04:11:07.00ID:h5FYCJvl
確かに奴隷言語っぽいね
177デフォルトの名無しさん
2022/10/08(土) 07:50:08.22ID:fwLI4Y/X
linus はこれがいいみたいだけどな()

git も Rust もゴミ
178デフォルトの名無しさん
2022/10/10(月) 15:43:56.96ID:OkLu+Ovr
meson のビルドで、

× Preparing metadata (pyproject.toml) did not run successfully.
│ exit code: 1
╰─> [64 lines of output]

こんなエラーが出た

すげーイラっとくる


> .toml

クズ言語
179デフォルトの名無しさん
2022/10/12(水) 21:08:34.50ID:BNoDz+WR
>>177
重要な部分はRustで作らないと思うよ
180デフォルトの名無しさん
2022/10/20(木) 18:29:22.69ID:uCae9JR1
なんでこれ、こんなにコンパイル遅いの?
181デフォルトの名無しさん
2022/10/20(木) 18:33:14.88ID:sgmqUmRA
>>177
俺もgitもgithubも使いにくいと思っていた。
182デフォルトの名無しさん
2022/10/20(木) 18:58:12.23ID:1LIQj8JQ
git自体は悪いと思わんが、なんかgit奉行が色々言い出すのがうざいわ。
rustもそういう匂いがぷんぷんする。
183デフォルトの名無しさん
2022/10/20(木) 19:21:40.91ID:LtHEChVu
どのバージョン管理ソフトが良いの?
184デフォルトの名無しさん
2022/10/21(金) 01:23:53.55ID:sdgXBR6P
>>183
名前は変わったと思うが、MS製のVisual Source Safeなんかは直感的で便利
だったな。特に何も学ばなくても普通に使えた。
185デフォルトの名無しさん
2023/08/11(金) 13:18:17.34ID:98F5eoJ/
cargo check error: failed to run custom build command for `glib-sys v0.17.10`

いい加減にしろよカス言語
186デフォルトの名無しさん
2023/08/11(金) 13:34:35.94ID:v1edpQDw
cargo publish して初めて出るエラー (cargo のあっち側の環境でコンパイルしてる) ってうざいよね
187デフォルトの名無しさん
2023/08/12(土) 00:05:38.13ID:qDONLKM9
>>185
Cコンパイラかリンカが入ってないんじゃね
そのメッセージの前に何か出ていると思うが

>>186
あっち側ってcrates.ioのこと?
リモート側でビルドなんか走るんだっけ
188デフォルトの名無しさん
2023/08/15(火) 08:53:12.04ID:ca01mENm
firefox のビルドもrust が邪魔しまくりだよね()
189デフォルトの名無しさん
2023/10/02(月) 13:43:22.96ID:sFvf9xp1
RustとC++の相性は最悪だが
RustとCはまあまあイケる
いいじゃんいいじゃん
190デフォルトの名無しさん
2023/10/03(火) 16:57:54.88ID:rr8MlNTB
カス言語ではない
191デフォルトの名無しさん
2023/10/05(木) 17:14:00.69ID:WXXGTjkD
C美しい
C++カス
Rustもうちょっとがんがれ
192デフォルトの名無しさん
2024/04/21(日) 15:50:07.23ID:aDRU4sod
Rust リファクタリングしてるときに
trait 境界が変わって
あれ?ってなることが多いな
193デフォルトの名無しさん
2024/04/21(日) 18:44:44.75ID:GAd5jyBU
>>192
trait境界を満たせなくなるとコンパイラが教えてくれるので安全にリファクタリングできて良いよね
194デフォルトの名無しさん
2024/04/23(火) 10:33:27.89ID:9zVe0TBb
>>0185
お前はディストリ自分で組まないの?
情弱だな(プ
195デフォルトの名無しさん
2024/04/23(火) 10:47:04.81ID:bJrnaJAq
創価
196デフォルトの名無しさん
2024/04/27(土) 21:26:16.94ID:+PotGQRe
crates.io が死ぬと詰むな・・・
197デフォルトの名無しさん
2024/04/28(日) 14:02:08.42ID:e+80DOh2
なんなの vendoring とか stable channel とか

意識高そうですね()
198デフォルトの名無しさん
2024/06/08(土) 09:22:59.84ID:Kcr3cAzI
Ruby批判だけど
https://qiita.com/scivola/items/17470c52641d3ffa1650
Rustにも同じことが言える
199デフォルトの名無しさん
2024/06/08(土) 10:03:29.15ID:9nPXIyFb
>>198
Rustに該当する話が一つもないのにRustを批判?
200デフォルトの名無しさん
2024/06/09(日) 16:29:53.15ID:IIKkP3Jm
信者は信者スレに帰れ
201デフォルトの名無しさん
2024/09/21(土) 15:07:34.01ID:v+xBeerr
おまいらホントRuby好きだな
202デフォルトの名無しさん
2024/09/21(土) 15:35:51.56ID:oJtK/qJ9
遅いのがなあ

lud20250519234632
このスレへの固定リンク: http://5chb.net/r/tech/1509028624/
ヒント:5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。

TOPへ TOPへ  

このエントリをはてなブックマークに追加現在登録者数177 ブックマークへ


全掲示板一覧 この掲示板へ 人気スレ | Youtube 動画 >50 >100 >200 >300 >500 >1000枚 新着画像

 ↓「Rustアンチスレ ->画像>1枚 」を見た人も見ています:
クッキー☆絵師アンチスレ61
クッキー☆絵師アンチスレ53
クッキー☆絵師アンチスレ35
クッキー☆絵師アンチスレ70
クッキー☆絵師アンチスレ75
クッキー☆絵師アンチスレ68
クッキー☆絵師アンチスレ44
けものフレンズ・ケムリクサアンチスレ
東方Projectアンチスレ in MANGO板 Part.6
東方Projectアンチスレ in MANGO板 Part.1
東方Projectアンチスレ in MANGO板 Part.3
【体は28歳】米津玄師アンチスレ23【精神年齢6歳】
【体は28歳】米津玄師アンチスレ18【精神年齢5歳】
【体は28歳】米津玄師アンチスレ19【精神年齢6歳】
【体は28歳】米津玄師アンチスレ29【精神年齢5歳】
【体は28歳】米津玄師アンチスレ44【精神年齢5歳】
【体は28歳】米津玄師アンチスレ28【精神年齢5歳】
【体は28歳】米津玄師アンチスレ22【精神年齢6歳】
【クソブス】米津玄師アンチスレ4【パクリ】
【YouTube】usagiアンチスレ2 【こなれ豚】
【戦わない】進撃の巨人ミカサアンチスレ12【守らない】
【戦わない】進撃の巨人ミカサアンチスレ18【守らない】
【青ルパン】淨園祐と関連スタッフアンチスレ【小池ルパン】
【こなれ豚】usagiアンチスレ8【毎日チートデイ】
【こなれ豚】usagiアンチスレ17【毎日チートデイ】
【整形ゴリラ】マリリン fukuse yuuri アンチスレpart43
【youtube】マリリンfukuse yuuri アンチスレ【メイク動画】 Part13
【バ一チャルYoutuber】にじさんじ有ンチスレ6691【フルメタルOUTLASTアンジュ応援スレ】
【youtube】マリリンfukuse yuuri アンチスレ【メイク動画】 Part10
【整形ゴリラ】マリリン fukuse yuuri アンチスレpart36【言語障害】
【整形ゴリラ】マリリン fukuse yuuri アンチスレpart26【言語障害】
【youtube】マリリンfukuse yuuri アンチスレ【メイク動画】 Part12
【整形ゴリラ】マリリン fukuse yuuri アンチスレ【Twitter自演】part24
クッキー☆絵師アンチスレ124
クッキー☆絵師アンチスレ103
クッキー☆絵師アンチスレ85
クッキー☆絵師アンチスレ117
クッキー☆絵師アンチスレ111
クッキー☆絵師アンチスレ 91
【体は29歳】米津玄師アンチスレ28【精神年齢4歳】
【体は28歳】米津玄師アンチスレ24【精神年齢6歳】
【体は29歳】米津玄師アンチスレ33【精神年齢3歳】
東方projectアンチスレ in東方project板 Part.47
【riya】eufonius アンチスレ【菊地創】
東方projectアンチスレ in東方project板 Part.60
東方projectアンチスレ in東方project板 Part.73
東方projectアンチスレ in東方project板 Part.57
東方projectアンチスレ in東方project板 Part.29
東方projectアンチスレ in東方project Part.35
橋本聖子及びUSMアンチスレ(荒川高橋宇野村上) Part.40
橋本聖子及びUSMアンチスレ(荒川高橋宇野村上) Part.56
【整形ゴリラ】マリリン fukuse yuuri アンチスレpart44 【言語障害】
東條希アンチスレ
林修アンチスレ
NTRアンチスレ
X1アンチスレ第1回
ザクアンチスレ
丘みどりアンチスレ
京急アンチスレ
lackアンチスレ
顔文字アンチスレ
農協アンチスレ
はねぴぴ アンチスレ
嵐アンチスレ204
名護さんアンチスレ51
嵐アンチスレ175
20:46:00 up 66 days, 21:44, 0 users, load average: 6.60, 7.24, 7.58

in 1.6367111206055 sec @1.6367111206055@0b7 on 062309