Rustアンチスレ

1 ：デフォルトの名無しさん：2017/10/26(木) 23:37:04.08 ID:9syp6YaG.net

Hello World以上の事をやるとコンパイルが通らない()Rustのアンチスレです

50 ：デフォルトの名無しさん：2020/03/25(水) 12:40:37 ID:COJzGufp.net

>>49
RAD言語ならそれで良いが、システム言語では駄目。

51 ：デフォルトの名無しさん：2020/08/09(日) 13:48:40.83 ID:cPfQFxYQ8

>>48
愚直に実装すると複数ヶ所で同一のミュータブルな参照を保持する必要に迫られるけど，
それはRustではコンパイルエラー
じゃあどうするか？ → 内部でUnsafeな生ポインタを使う
みたいな話か

52 ：デフォルトの名無しさん：2020/08/28(金) 02:41:24.81 ID:BFWbiW8H.net

Rustは、コンテナは、配列(長さがコンパイル段階で静的に決まる固定長)、
ベクター(動的配列)が主で、LinkedList<T>は、せっかくのリンクトリストの
特徴である末尾以外の「途中」への追加は出来ない。
これではリンクリストの意味が無い。
また、公式ドキュメントに
「ベクターの方がLinkedList<T>より速い」
などと書いてあるが、それはとんでもない間違い。

53 ：デフォルトの名無しさん：2020/08/28(金) 17:13:22 ID:BFWbiW8H.net

リンクリストを実装するのはこんなに難しく、
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;
　　}
}

54 ：デフォルトの名無しさん：2021/01/08(金) 10:57:50.09 ID:4h6DBvmg.net

00年代半ばごろのゴミサイトがアクセス数を稼ぐのを思い出した


ゴミ

55 ：デフォルトの名無しさん：2021/05/05(水) 10:12:10.05 ID:Icux/Qfe.net

可読性低いな

56 ：デフォルトの名無しさん：2021/06/18(金) 18:36:38.41 ID:GgPo8kME.net

Ｒｕｓｔを含めた新手の言語の仕様が固まるまで、２０年ぐらい掛かるからなぁ

今２０代の連中がＲｕｓｔを使いこなせる様になっても、

システム開発に使える頃には、４０過ぎの中年だけど、まだプログラマー続けてるの？

57 ：デフォルトの名無しさん：2021/06/30(水) 12:11:47.40 ID:TGFkopCB.net

レッツ！ｍｕｔ　＆ｍｕｔ　もっと　＝　したい：ダメな日本語；

58 ：デフォルトの名無しさん：2021/07/07(水) 23:28:03.78 ID:3EDdhBYW.net

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

59 ：デフォルトの名無しさん：2021/07/16(金) 02:31:03.20 ID:UUn46lBk.net

もうお前のRustコード直すの嫌だわ

60 ：デフォルトの名無しさん：2021/07/21(水) 02:06:52.85 ID:DO3wSfvm.net

意識高い系が自己満足でめちゃくちゃなコードを他人に押し付ける言語

61 ：デフォルトの名無しさん：2021/08/10(火) 09:03:54.83 ID:fPg8NGNP.net

>>45
何かいいやり方があるはずだ。誰が見ても明らかな、たったひとつのやり方が。
そのやり方は一目見ただけではわかりにくいかもしれない。オランダ人にだけわかりやすいなんてこともあるかもしれない。

The Zen of Pythonの一節だけどRustの設計思想もこういうことなんじゃないか？
何通りもある書き方を統一することによってコードを読む人にも分かりやすくするってことだと思う。
もうそこは好みの問題だから気に入らなければやらないでいいんじゃないか？

62 ：デフォルトの名無しさん：2021/08/10(火) 09:10:56.61 ID:UUhRSoFC.net

Rustは組み込みシステムでも非常に多く使われているように何でも書ける
Cと同様に低レベルな部分でも記述可能でさらにインラインアセンブリも可

63 ：デフォルトの名無しさん：2021/08/10(火) 14:11:34.30 ID:mSeKT5En.net

raw pointer 使えるし C でできることはだいたい出来るのでは
できないのは variable length argument/array くらい？

64 ：デフォルトの名無しさん：2021/08/11(水) 07:11:51.41 ID:KlEtC9pi.net

そりゃunsafeすればなんでもかけるわ

65 ：デフォルトの名無しさん：2021/08/11(水) 07:16:15.10 ID:N49Uco17.net

>>64
C/C++/Rust以外の言語ではどうやっても無理

66 ：デフォルトの名無しさん：2021/08/12(木) 10:28:40.81 ID:whMOJJYX.net

なんかRustアンチは必要以上にunsafeを忌避してる気がする

unsafeは注意が必要な部分を限定するために用意された言語機能なのに
「unsafe使うならC/C++でいいじゃん」
とか考えてそうな雰囲気

67 ：デフォルトの名無しさん：2021/08/12(木) 10:57:49.37 ID:tXISMw6z.net

unsafeブロック内でもボローチェッカは仕事するって知らん人多そう

68 ：デフォルトの名無しさん：2021/09/04(土) 03:57:00.95 ID:kn1l/Q+t.net

>>24
いや、自走車椅子だろ

69 ：デフォルトの名無しさん：2021/09/04(土) 04:05:22.28 ID:iqtSb51S.net

>>24
C++より便利で安全だから
例えると醤油とソースかな

70 ：デフォルトの名無しさん：2021/09/06(月) 13:53:51.27 ID:kq9rR1L5.net

Rustスレでは場違いなので、イテレータというか高階関数の話にもう一度食いつくとする。

Juliaなんかだと並列・分散処理するために@distributed forなんて書くが、Erlangだとループ中に
spawnをして、Goもgoroutineを起動する。map/reduceなんかだと明らかにメニ―コアを使った方が
速いが、標準ではそうなっていなくて、外部ライブラリのrayonなどを使用する。
GoでもRustでもこれをさらに分散処理させるにはgRPCなど規格化されたインターフェースを通すが
やりたい事はJuliaの@distributed forなのに手間を感じさせる。
Rustにライトウェイトスレッドが言語仕様として入るとは思えないが、やはり言語には向き不向きが
存在する。近年のjavascriptを発端とするasync/awaitにも疑問が生じる。あまりにも多くの言語が
同期実行のライブラリと整合性が無さすぎる

71 ：デフォルトの名無しさん：2021/09/06(月) 14:51:17.48 ID:6RpN+EMp.net

DSLと同等の使い勝手を汎用的な言語に求めるのはつらいのでは

72 ：デフォルトの名無しさん：2021/09/06(月) 16:49:04.49 ID:7r7RF488.net

>>70
たしかにJavaScriptのasync/awaitとRustのは最も対照的ですがどちらも良い特徴があると思います
JavaScriptはブラウザも外部のNode.jsもその言語実行環境として非同期ランタイムが組み込まれasync/await導入以前から非同期関数が標準として装備
そのため非同期関数が呼ばれたら次のスケジュールで即座に実行が始まりますね

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

Rustはこれらに関して「何ができない」のではなく「何でもできる」わけなので
あとは記法の簡易性を求めるのならばその呼び出し関数等の設計とマクロでお好みの方面へ寄せることも可能です

73 ：デフォルトの名無しさん：2021/09/11(土) 00:36:45.81 ID:YO3o85Uj.net

>>72
これは良い書き方をしているが非同期ランタイムを自由に選べるのではなく、適切に選ばないと
インターフェースをサポートしない場合があるため、互換性が保てないでしょう。Rusterは
ゼロコストという話を良くしますが、Rustの非同期はタスクごとにステートマシンを作るために
確かにNode.jsなどと比べるjavascriptと比べれば、全体で非同期をスケジューリング管理する
ものと比べアロケーションや実行コストなどは小さいですが、それほど喧伝すべきことでもありません。
いずれにせよ多くの非同期はI/Oバウンドでありepollベースなどで管理されます。当然ながら
(Cに代わるようなハードウエア近い）システム言語なので出来ない事があってはイケていません。
私が言っているのは、Rustに限りませんがasync/awaitの記述が普通に考慮されてない設計の悪い
ライブラリが沢山あるという事です。Rustのマクロは最低だと思います、なぜわざわざ学習コストを
引き上げるのか理解できません

74 ：デフォルトの名無しさん：2021/09/11(土) 01:17:56.12 ID:PRM8i6LA.net

>>73
あなたの主張は意味がわからない
まず「互換性が保てないでしょう」は何との何の互換性が保てないのか？意味不明
次に「それほど喧伝すべきことでもありません。」は結局のところあなたは反論すら出来ずに同意してしまっている
さらに「Rustに限りませんが(略)設計の悪いライブラリが沢山あるという事です。」はRust言語に対する批判にすらなっていない
それぞれ具体的に問題点を述べましょう

75 ：デフォルトの名無しさん：2021/09/11(土) 01:24:36.44 ID:Q/hQI3Xf.net

唐突にマクロが登場するのも分かりませんね
async-awaitがマクロだった頃の話をしているのですか？

76 ：デフォルトの名無しさん：2021/09/11(土) 01:41:58.05 ID:YO3o85Uj.net

あんたの方が意味不明だけど（笑）
まず文書の書き方にケチを付けてロンパーする癖を直しましょう。

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

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

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

またマクロについても「マクロでお好みの方面へ寄せることも可能です」という
返答に関して感想を述べてるのに過ぎないのに、全く話を辿れていません。

77 ：デフォルトの名無しさん：2021/09/11(土) 02:11:46.06 ID:w5S7rLqj.net

>>76
具体的な問題点を述べましょう
例えばtokioの上に構築されたhttpモジュールであるhyperも互換レイヤーによりasync-std 上でも動作します

RustアンチスレでなぜJavaScriptを問題にしているのかも謎ですが
JavaScriptのasync/await/Promiseもあの環境で非常に優れて設計されています
この件についても具体的な問題点を述べておられないですね

78 ：デフォルトの名無しさん：2021/09/11(土) 11:03:00.32 ID:LLoV+Okg.net

>>76の勝ち
以上

79 ：デフォルトの名無しさん：2021/09/11(土) 13:53:10.45 ID:zUj2TAiQ.net

>>76
＞「近年のjavascriptを発端とするasync/awaitにも疑問が生じる。
＞あまりにも多くの言語が同期実行のライブラリと整合性が無さすぎる」

意味がちょっと不明です。
JavaScriptでそれらが用いられうる通信分野では、基本的に同期実行のライブラリは存在しません。
例えばhttpなどで取得してくるfetch()も非同期ですし、もっと低水準のモジュールも非同期です。
同期実行のライブラリと整合性が無さすぎるとは、何を意味しているのでしょうか？

80 ：デフォルトの名無しさん：2021/09/11(土) 13:59:42.94 ID:QGVH5OH8.net

発端と言ったらC#の方が古くね

81 ：デフォルトの名無しさん：2021/09/12(日) 14:45:35.48 ID:dsndgRWH.net

Rustって組み込み開発向いて無くね？
どう考えてもLinuxなりBSDなりある程度高度なOSがある事前提だ、OSのメモリーコンパクションが
無いとGCが無い故にメモリーの断片化が起こり、長時間稼働するタイプの小さな組み込みには向かない。
マイクロコントローラのメモリー付きSoCでブーストラップローダーがあるだけの組み込みには使えない
ま、サポートプラットフォームにTier1/Tier2でも、そういうのに使えるとは書いてないけど

82 ：デフォルトの名無しさん：2021/09/12(日) 15:02:08.52 ID:raaoGYn7.net

>>81
その文章だけならCにいれかえてもあってそうなんだが？

83 ：デフォルトの名無しさん：2021/09/12(日) 15:22:52.56 ID:lBuMyCBZ.net

>>81
つまりC/C++/Rustは組み込みやOSに向いていないとｗ

84 ：デフォルトの名無しさん：2021/09/12(日) 15:26:04.82 ID:Cf6Jz1Ay.net

そこで組み込みのために開発されたJavaですよｗ

85 ：デフォルトの名無しさん：2021/09/12(日) 21:57:41.77 ID:UrK9UNLE.net

それはリソースがたっぷりある組み込みのケースで感覚としてはアプリ開発に近い
組み込みはピンキリだからスクリプト言語が動く環境まである
一方でC/C++/Rustじゃないと厳しい環境もある

86 ：デフォルトの名無しさん：2021/09/12(日) 22:17:14.89 ID:Zjk1d74X.net

>>76
同期実行ライブラリと整合性が無いというのはウソです
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 ：デフォルトの名無しさん：2021/09/12(日) 22:19:55.41 ID:s09Gb+ph.net

設計にバカが関わってなければC++で十分

88 ：デフォルトの名無しさん：2021/09/12(日) 22:44:56.06 ID:Q5FBinyU.net

コードの規模が大きくなると複雑さが増して相対的に知性下がるからバカが開発することを前提にした方が良い

89 ：デフォルトの名無しさん：2021/09/13(月) 20:47:01.12 ID:dBMpD8or.net

>>88
それは自覚症状が無いだけで自分が馬鹿なだけかも知れんが。

90 ：デフォルトの名無しさん：2021/09/13(月) 20:51:25.89 ID:9PNw/wOW.net

>>89
自分は馬鹿と思ってコード書いた方が良いよ本当に
これはバカにしてるとかじゃなくて心構えとして

91 ：デフォルトの名無しさん：2021/09/14(火) 19:27:55.83 ID:kyozNdb6.net

>>90は賢いお人

本来馬鹿は馬鹿を自覚できないから
平気でウンコを顔面につけたまま歩き回り
いろんなものを糞まみれにしてケロっとしてる

92 ：デフォルトの名無しさん：2021/09/14(火) 20:13:08.96 ID:Wng5bteL.net

>>90
お前と俺を一緒にスンナよ。
人間の頭脳は画一敵意ではなく差が大きい。

93 ：デフォルトの名無しさん：2021/09/14(火) 23:33:28.66 ID:9cp1Eg6y.net

微笑ましい

94 ：デフォルトの名無しさん：2021/09/14(火) 23:52:38.24 ID:BSh8VTqx.net

少なくともある程度以上の大きさの開発したことある人や
複数案件を同時進行した人なら
いくら完璧にしていても確率的にミスが入り込むとわかるはず
そしてC++とRustとの比較ならどちらが良いかも冷静に判断できる

95 ：デフォルトの名無しさん：2021/09/15(水) 02:02:19.36 ID:x4RgVtnC.net

>>86
そんな事を言ってるんじゃないと思いますよ、「複数のファイルのチェックサム計算」なんて単純な事なら
当然ながら同期と非同期でそれほど違いは出ないでしょうし互換性があるように見えるでしょう。なぜなら
チェックサム計算は一瞬で終わり非同期はファイル毎に区切っているから。チェックサム計算は同期コードで
いずれも書かれていて１つも違いがありません。
これをいくつかのファイルは巨大でファイル長が不明（無限では無い）が大きいファイルのチェックサム計算や
より複雑で時間のかかる計算を非同期で行いたいとすればどうしますか？チェックサム計算で、read_to_endは
使えずストリームを非同期に読み続けて計算することになるでしょう。という事はbytes.iter().foldも使えません

「同期実行ライブラリと整合性が無いというのはウソです」このように言い切ること自体に"気持ち悪い信仰"を
持っているのは良く分かりますが、元が「整合性が無さすぎる」と言っているのは、整合性がある１パターンを
示しても意味が全く無いという事です。多くの問題は「ウソです」と言い切れる浅はかさが問題です
http://qiita.comの記事なんて初心者のサンプルに過ぎません

96 ：デフォルトの名無しさん：2021/09/15(水) 11:47:44.97 ID:PYzW5a+n.net

>>94
確率的な話をするならコンパイラの塾制度考えた場合の確率を下回るくらいのメリットしかrustにはないよ。

97 ：デフォルトの名無しさん：2021/09/15(水) 20:26:11.48 ID:77IP/X5S.net

>>96
rustcで検出できるバグを仕込む確率よりもrustcのバグを踏む確率の方が高いということ？

98 ：デフォルトの名無しさん：2021/09/15(水) 21:21:02.30 ID:PYzW5a+n.net

rustcで検出できるバグよりcとのバインディングでの勘違いで生じるバグのが多いわな

99 ：デフォルトの名無しさん：2021/09/16(木) 00:37:37.41 ID:Efcezeu+.net

まあ静的チェックに過剰な期待してる奴は大抵クソだよ

100 ：デフォルトの名無しさん：2021/09/18(土) 06:51:34.59 ID:pceSJQ2d.net

>>94
そのうち上位層はビジュアルプログラミングに取って代わられて行ったりしてね

101 ：デフォルトの名無しさん：2021/09/18(土) 07:04:45.25 ID:WtcFUHdh.net

Rustのスレで何を頓珍漢な

102 ：デフォルトの名無しさん：2021/09/25(土) 03:20:19.87 ID:r08K7R9X.net

コンパイルチェックがゼロになるコードを書けるまでウンコ呼ばわりされる

103 ：デフォルトの名無しさん：2021/10/20(水) 16:37:55.38 ID:rOkBuggn.net

>81
>無いとGCが無い故にメモリーの断片化が起こり、長時間稼働するタイプの小さな組み込みには向かない。

ヒープも使わない（ことが多いから）、メモリーの断片化も起きない
当然GCなんかいらない
rustが組み込みに向かないのは同意する

104 ：デフォルトの名無しさん：2021/10/20(水) 19:56:54.98 ID:VGECjsMp.net

小さなの規模にもよるけど
スタックや初期化時以外で動的なメモリ確保がそもそもできなくない？
Unix風のプロセスモデルでもないとmallocし続けるだけでアウト

105 ：デフォルトの名無しさん：2021/10/20(水) 20:18:24.99 ID:rOkBuggn.net

組み込みの世界ではヒープじゃなくて、
リンクリストのノードを固定長メモリブロックとして使ったりする
例えばuItronのメモリプールの実装とかそんな感じ
ヒープはリアルタイム性がないから

で、rustはstatic mutが使い辛過ぎて、組み込みでは難しそう

106 ：デフォルトの名無しさん：2021/10/20(水) 20:22:41.04 ID:VyYhhIkP.net

D言語も忘れないで下さい。

107 ：デフォルトの名無しさん：2021/10/20(水) 20:37:31.19 ID:rOkBuggn.net

アンチスレとはいえ
将来性を考えると、さすがにD言語よりはrustの方が……

108 ：デフォルトの名無しさん：2021/10/20(水) 22:36:34.87 ID:VyYhhIkP.net

D言語：「忘れないで・・・」

109 ：デフォルトの名無しさん：2021/10/20(水) 22:52:38.54 ID:UtWr6ljA.net

Deprecated
Dormant
Dead
縁起悪いよ…(´・ω・`)

110 ：デフォルトの名無しさん：2021/10/21(木) 18:37:53.89 ID:wlIxx6Dc.net

言語と関係ないがrusterのこういう陰湿さが嫌、goに頻繁に嫌がらせしてるし、gcが選べるD言語など
まだまだマイナーな言語へ嫌がらせする

111 ：デフォルトの名無しさん：2021/10/21(木) 20:22:29.58 ID:s+sF4o2E.net

Dのことマイナーって呼ぶなよ

112 ：デフォルトの名無しさん：2021/10/22(金) 20:07:55.54 ID:BGSpAusK.net

>>107
将来を考えるなら、文字列でだらだら書くというスタイルが古臭いってなるかもね。
今のプログラミングは、分厚い本を読まされてる、書かされてるみたいなもん。
映像なら3秒でですむことを延々と書き連ねているようなもんだし。

113 ：デフォルトの名無しさん：2021/10/22(金) 21:52:45.50 ID:v3Yxx0iq.net

永遠に可能性が無いとは言わないが、テキスト以外の方法は生まれては消えてを繰り返してるのでどうも期待出来無い。
人間がコード書く役割が終わる方が先に来るんじゃないかな。

114 ：デフォルトの名無しさん：2021/10/23(土) 08:17:48.59 ID:126WIPxs.net

>>113
AIでも同じようなことが言われていて、
囲碁で人間に勝つには100年かかるなんて言われてたからね。
>人間がコード書く役割が終わる
まさにそれ。
人間は「こうしたい」というのを表現できればそれで良いわけで、それをわざわざ文字列で延々と書き連ねるというのが古臭いことになるんじゃない？ってことね。

115 ：デフォルトの名無しさん：2021/10/23(土) 08:56:15.06 ID:3BoTC/ER.net

現状人間同士である程度厳密に情報を伝えようとすると言葉に頼るわけでコンピューター相手でもそこは変わらない気がする

116 ：デフォルトの名無しさん：2021/10/25(月) 17:46:30.13 ID:a6PpXdhO.net

>>115
わざわざ人間が翻訳機になってるっていうのが古臭いって思うんよね。

117 ：デフォルトの名無しさん：2021/10/25(月) 17:54:38.98 ID:a6PpXdhO.net

>>115
文字によるプログラムっていうのが結局いつまで経っても1.5次元みたいなもんで、どことどこが関連しているのかということすらパッと見てわからないしね。
まあ、世の中には何百万行もあるプログラムでも簡単に目を通して全体像を把握できるような天才的な人もいるんだろうけど、私には無理だわ。

トシヨリガーとか、老害だとか言ってる割には旧来の手法に固執するんだな。

118 ：デフォルトの名無しさん：2021/10/25(月) 20:15:43.78 ID:cubP7NbG.net

>>117
グラフィカルなプログラミング環境とか、設計手法だけどUMLとかあるにも関わらず一般的なプログラミング言語を置き換えるには至ってないよね
旧来の手法を置き換えるには何かしらのブレークスルーが必要なんだと思う

現状プログラミングが主に言葉で書かれているのは、人間がプログラムを考えていることと、人間の考えを厳密にコンピューターに伝える必要があることに由来していると思う
人工知能が発達して人間の曖昧な指示に従ってコンピューターがプログラミングするとか、脳波読みとりなど言語化なしで人間の考えを伝える手段が現れれるなどすれば状況は変わるかも知れない

119 ：デフォルトの名無しさん：2021/10/25(月) 20:53:20.91 ID:IG0eAPOa.net

どの程度の複雑さをコンピュータ側に持って行っても、要求なり目的なりを記述する必要は残る。
いわゆる "プログラミング" では無いかもしれないが。
そこの記述はグラフィカルでどうのこうのと言っても汎用性を求めると結局はテキストになるんじゃないかな。

まあ要求記述のテキスト、というとSQLがその一つなんだけどさ。

120 ：デフォルトの名無しさん：2021/10/28(木) 17:10:44.11 ID:nJ3D7u2B.net

>>119
で、現実にやってるのは、やれCだなんだと、それぞれの方言に合わせて人間が一生懸命翻訳作業をして文字列で書き起こしている。
客観的に見れば実に珍妙な記号とあるふぁべっの羅列でね。
そして、流行りの方言が出るたびにその方言を覚えては翻訳作業。
でも、結局のところコードが大幅に減るわけでもなく、肥大化するにつれて誰も正しい全体像を把握できなくなるのは同じこと。そして、いつまで経っても無くならない誤訳…バグの山。

やはりこのスタイル自体に無理がきているんだと思うわ。まあ、究極はコンピュータそのものの考え方から変えないとダメかもしれないけどね。

121 ：デフォルトの名無しさん：2021/10/28(木) 17:37:46.17 ID:oV3TAAYO.net

>>120
そのレベルの話だとコーディングと言うよりも設計の問題なのでは

122 ：デフォルトの名無しさん：2022/02/26(土) 07:53:14.27 ID:BV4vpVpG.net

自分がどうしたいってことしか考えないから、言語が要らないなんて言い出す。

受けとる方を考えてみろ。

123 ：デフォルトの名無しさん：2022/04/27(水) 15:55:20 ID:1aIRuPS7.net

CとリリースモードのRustは、どちらも実行時間が最小限です。 Cは未定義の動作でそこに到達します。 Rustは、非常に堅牢な言語定義を使用して、コンパイラーが多くの危険なプラクティスを拒否し、多くの望ましい結果を安全で比較的便利にすることを可能にします。

しかし、Rustは、多くの人が望ましくないと考える特定の動作も許可します。許可されるように言語を定義するだけです。たとえば、整数のオーバーフローを考えてみましょう。デバッグモードでは、Rustは整数のオーバーフローでパニックになります。良い。リリースモードでは、2の補数としてラップします。悪い。つまり、それは言語定義に含まれているので、非常に優れていますが、私に関する限り、これは、符号付き整数のオーバーフローを未定義の動作として参照するCおよびC++言語定義とほぼ同じくらい悪いものです。

124 ：デフォルトの名無しさん：2022/04/27(水) 16:14:27.17 ID:fXEX2s7j.net

>>123
Rustはそのために例えば足し算でも
checked_add
overflow_add
wrapping_add
saturating_add
など用途毎に使い分けられるようになっている

125 ：デフォルトの名無しさん：2022/04/27(水) 18:36:40.62 ID:HjqqO7sC.net ?2BP(0)

http://img.5ch.net/ico/2iyou_2.gif
あかんところ列挙
・コンパイル型言語らしいけど、C++の方が速い(GCC万歳)
・CPLから派生した言語とかなり系統が違う(習得しづらい)
・関数宣言でわざわざfnをつけないといけない(文脈で理解できないのかコンパイラ)
以下、C++のあかんところ
・最近のは遅い->STL使わんかったらいい、もしくは自作
・バッファオーバーランとか、危ないことが起こる->そんな阿保プログラムを書かなかったらいい

126 ：デフォルトの名無しさん：2022/04/27(水) 18:45:52.15 ID:kbMyQ47R.net

>>125
RustとC++はほぼ同等の速度
その上でRustは様々な安全性とC++より便利な機能によりプログラミング生産性も良い

127 ：デフォルトの名無しさん：2022/04/27(水) 18:53:45.96 ID:DngKLmNp.net

>>124
そういうことを言いたいんじゃない。releaseとdebugで動きが異なることを言いたいのだ。例えばGoなどはどちらも動きはわからない。
Rustはどう考えても、プログラムの１つ１つを完全に知りえていなければプログラムを書いてはならず、安全な側へ倒すのではなく、releaseでオーバーフローを省略するのにそれで速いとゴマカしている。計算系のベンチマークテストなどまさにそう
また上のように「用意している」という表現も、限りなく敷居をわざと高くしているだけで、何の利点でもない。

128 ：デフォルトの名無しさん：2022/04/27(水) 18:55:26.96 ID:j3SjDNhs.net

>>124
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を超えて溢れる寸前まで求まっている

129 ：デフォルトの名無しさん：2022/04/27(水) 18:57:07.63 ID:DngKLmNp.net

このようにわざと貼り付けなくても良いことを書いて、不都合を指摘すると流すようにするのは本当に良くないコミュニティの態度

130 ：デフォルトの名無しさん：2022/04/27(水) 19:00:24.43 ID:QwtQyiYP.net

>>128と同じ関数を他のプログラミング言語で書くとどんなコードになるの？
具体的にコードを比較して客観的に判断したい

131 ：デフォルトの名無しさん：2022/04/27(水) 22:32:13.33 ID:Xa5DwGtB.net

>>127
release buildでもチェック有効にできるよ
https://doc.rust-lang.org/cargo/reference/profiles.html#overflow-checks

プログラムの一つ一つを理解しなくても書ける言語ってどういうものだろう

132 ：デフォルトの名無しさん：2022/05/19(木) 17:01:33.84 ID:YoVN/Jlg.net

>>126
今どきのC++は遅いっていうけど、新しいC++の仕様を使うからである。
つまり、Better Cみたいな使い方をすればRustより速くなる(実際そういう結果もある)。
まあ、体感はどっちもかわんねえべってとこだから、RustよりJava,C#とかスクリプト言語をアンチすればいいと思う。Rustで慣れてる人はRustで書けばいい。

133 ：デフォルトの名無しさん：2022/05/21(土) 23:22:45.63 ID:zNzebGu9.net

C++が遅いってコンパイル時間の話ちゃうん

134 ：デフォルトの名無しさん：2022/05/23(月) 00:46:57.32 ID:Fl/zPM6P.net

なんでJavaやC#がスクリプト言語に入ってんだ?
C#にはC#スクリプトがあるが実行時に中間言語にコンパイルするだけだろ

135 ：デフォルトの名無しさん：2022/05/23(月) 00:55:18.95 ID:Fl/zPM6P.net

一度だけ必要なメモリを確保して使い回せるものを
オブジェクトとして生成、消滅繰り返すようなプログラム組むと(普通にC++でかくとこっちになる)遅くなるよ
挙句の果てにメモリフラグメントが避けられない
普通にCで書くとよほどの馬鹿でも無い限り無駄なメモリ確保開放を繰り返すなんてことはしないから

136 ：デフォルトの名無しさん：2022/05/23(月) 01:27:08.69 ID:aUQlcplw.net

>>135
領域使い回せるってことは生成・解放するオブジェクトのサイズはだいたい一定なんだと思うけど
そうだとしたら最近の普通のmalloc実装ならそうそうフラグメント起こすことはない気がするけどどうなんだろ
ベンチマークとかあるの？

137 ：デフォルトの名無しさん：2022/05/23(月) 01:35:14.45 ID:Fl/zPM6P.net

>>136
行列クラス考えてみろ
while(1)
E = A*B+C/D
C++なら一行でかけるが

138 ：デフォルトの名無しさん：2022/05/23(月) 01:45:51.46 ID:Fl/zPM6P.net

誤送信
>>136
行列クラス考えてみろ
while(1)
E = A*B+C/D;
C++なら一行でかけるがテンポラリ領域を演算子の多重定義の中で確保開放繰り返さざるをえない
ETでなんとかなる部分もinverseがあるとそれもお手上げ
一時領域をwhileの外で確保してそれを使い回す方法と比べて早くしようがない。

139 ：デフォルトの名無しさん：2022/05/23(月) 01:48:39.79 ID:Fl/zPM6P.net

>>136
>普通のmalloc実装ならそうそうフラグメント起こすことはない

ヒープの動的確保でフラグメント興さないなら
RTOSでメモリプール確保する必要なんてないよなww

140 ：デフォルトの名無しさん：2022/05/23(月) 02:08:18.18 ID:aUQlcplw.net

>>138
速度に関してはC++の方が不利なことに対しては異論ないよ
ただフラグメントについては本当にそうなのか気になってた

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

まあ確かにRTOSのmalloc実装では問題起こるかもしれないけどね
ただ、そういうのは "最近の普通のmalloc" ではないと思う

141 ：デフォルトの名無しさん：2022/05/23(月) 02:25:01.02 ID:Fl/zPM6P.net

>>140
なんで同じ領域が確保されると保証されるのさ。今時のOSでww
そのエリアが外のタスクで割り当てられなかったことがなんで保証できるんだ?
とにかく動的確保、削除してフラグメント起こさないと思ってる方がどうかしてる。
そういう思い込みが通用するなら、所有権なんてもんは必要ないだろ。
あれはデフラグの対象にするかどうかが細大の目的

あと、普通のとか今時のとか、お前のあたのなかこっちは見られないんだから使うのやめろ

142 ：デフォルトの名無しさん：2022/05/23(月) 02:44:22 ID:Fl/zPM6P.net

>>138
>速度に関してはC++の方が不利

これもちょっと違うだろ
上で>>132が言ってるようにBetter cに留めて。
過度な見やすさや書きやすさを追求しなければ
C++はC機能包含してるんでC++で不利になることなんてない。
機能を使わなければいいんで不利になりようがない。
Pure C流ででもかけるわけだし

143 ：デフォルトの名無しさん：2022/05/23(月) 08:16:07.89 ID:aUQlcplw.net

>>141
とりあえずglibcのmallocでいいや
>>138のような解放直後に同じサイズで領域を確保する場合は領域再利用されるよね

144 ：デフォルトの名無しさん：2022/05/23(月) 09:11:41 ID:n2ZPTBPD.net

// ヒープを使う型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);
}

145 ：デフォルトの名無しさん：2022/05/23(月) 09:17:13.61 ID:n2ZPTBPD.net

実行結果
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)

つまり足し算で中間生成される一時的な領域は再利用されて使い回されていることが確認された
したがって>>141の主張がおかしい

146 ：デフォルトの名無しさん：2022/05/23(月) 09:54:21.07 ID:n2ZPTBPD.net

一般的に、今回のような多段の計算の場合は、中間領域が少なくとも2つ必要となる
なぜなら、一般的には「中間値2＝中間値1＋次の項目」と順に計算していくためである
つまり一般的な場合は、5つの変数の足し算ならば、中間値2つを加えて、計7つの領域を必要とする

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

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

結論
Rustでは消費し終えた変数や中間値が使用していたヒープ領域もすぐに再利用されて使い回されるため、
>>138のようなケースでも最小限のメモリしか必要とせずに済む

147 ：デフォルトの名無しさん：2022/05/23(月) 11:54:34.12 ID:n+tkR/ue.net

glibc mallocの仕様なのでCやC++でも同じです

148 ：デフォルトの名無しさん：2022/05/23(月) 14:37:05.11 ID:GiQn/B1E.net

Rubyを長期間動かすとGCがメモリを
細分化してしまうという話かなんかと
混同してんのかな

149 ：デフォルトの名無しさん：2022/05/23(月) 15:10:34.13 ID:K4XvBL00.net

>>146
> しかし>>145の結果のアドレスを見ると、確かに中間値は交互にアドレスが異なり2種類だが、全体で6つの領域で済んでいるところに注目
7つ使ってるように見えるんだけど、何を見て6つで済んでるって言えるの？