Rustアンチスレ
AAS
2017/10/26(木)23:37:04.08(9syp6YaG.net)
2デフォルトの名無しさん [sage]
あなたの触ってる言語がRustじゃない可能性のが高そうだね
2017/10/26(木)23:40:36.83(LSWABSRs.net)
3デフォルトの名無しさん
自動的な並列化によりメニーコア時代に対応。
メモ化サポート、動的計画法が自動的に実装できる、AI時代に必須。
Rust使いというだけで尊敬される、自動的に彼女ゲット。
C/C++の20倍高速。
2017/10/27(金)00:11:03.46(8v9HsLU9.net)
4デフォルトの名無しさん [sage]
2017/10/27(金)01:38:19.39(HS++Psw6.net)
5デフォルトの名無しさん [sage]
2017/10/27(金)01:59:27.69(zibA1NJ/.net)
6デフォルトの名無しさん
いま核ミサイルの集中制御システムに携わっています。
Rustが世界を変える、Rustで世界を変える。
アッラーアクバール。
2017/10/27(金)02:21:16.33(8v9HsLU9.net)
7デフォルトの名無しさん [sage]
Rustはなんだ？ぼうっ切れか？たしかに銃と違って暴発したりはしないな
2017/10/27(金)09:45:57.32(T+eCoUsJ.net)
8デフォルトの名無しさん
2017/10/27(金)18:02:33.63(cUZom3KZ.net)
9デフォルトの名無しさん
2017/10/27(金)18:02:45.00(697iydar.net)
10デフォルトの名無しさん [sage]
2017/10/27(金)19:54:56.14(Ql9mpjN/.net)
11デフォルトの名無しさん [sage]
2017/10/29(日)18:15:04.59(COmwxbJI.net)
12デフォルトの名無しさん [sage]
本当に木っ端だったらなんも言わねえよ
モジラが言語自体をゴミクズのままにしておきながら
ステマに工数と金をぶっこんで自社ブランドの肥やしにして
それに騙されてゴミクズ掴まされる被害者がでてることに文句つけてるんだよ
2017/10/30(月)15:46:08.82(a0o0t6OO.net)
13デフォルトの名無しさん
2017/10/30(月)17:28:53.44(ExtYgMew.net)
14デフォルトの名無しさん [sage]
2017/11/05(日)09:42:11.34(/OpyHVwj.net)
15デフォルトの名無しさん
2018/02/10(土)22:35:12.01(gZwa/8Tz.net)
16デフォルトの名無しさん [sage]
Rustに傷つけられたアンチと戯れるスレだからね、仕方ないね
Swiftは騙されるアポー信者が多くてめっちゃウハウハだったな、Swiftやってますだけでクッソ仕事多かったのwww
Rustは、、、上流工程には知名度がなく、下流工程には難易度が高く、どこ行っても誰も騙せNEEEEEEEE
どこの業界(分野)に行けば騙されてくれる被害者がいますか？マジで教えてください
2018/02/11(日)09:24:51.51(YryqqCkE.net)
17デフォルトの名無しさん [sage]
enumをforループするだけのことが面倒なのもクソ
ボローチェッカーとの戦い(笑)以前に生産性低すぎるわこんなもん
C++を置き換えるとか言ってるやつは頭お花畑やろな
2018/02/11(日)20:02:48.65(JG+HYHMD.net)
18デフォルトの名無しさん [sage]
だって実現方法はともかく意味的に整数はenumではないもの
>enumをforループするだけのことが面倒なのもクソ
forループしようと思う時点でそれはenumを使うべき場所でないのでは……
2018/02/11(日)20:26:21.53(PouFYKRN.net)
19デフォルトの名無しさん [sage]
何をしようとしてenumメンバをforで回す機会があるのかサッパリ分からんが
生産性悪い書き方して生産性悪いと言ってるのはよく分かった
ちょっとオモロイから、生産性悪いと思った事例をもっと教えてくれよ
2018/02/11(日)21:47:14.09(YryqqCkE.net)
20デフォルトの名無しさん
2018/02/11(日)23:22:44.25(18bG+VQL.net)
21デフォルトの名無しさん [sage]
結果、メモリ非安全で生産性悪いRustクソ!!!!
俺はアホだから危ないunsafe使うのやめよ、整数型からenumにするのはfn new使おう
結果、メモリ安全で生産性良いなー
Rustはアホ向けの学習難易度の低い言語だった可能性が微レ存？
2018/02/12(月)11:06:57.76(+5PXSpLD.net)
22デフォルトの名無しさん [sage]
無理する奴がバグを生む。俺はアホで良い。
2018/02/12(月)13:03:15.96(JDol8IEk.net)
23デフォルトの名無しさん [sage]
enumの定義時にマクロを使って全メンバーを含む配列も同時に定義するなどがある
これだけをやってくれるcrateも作れそうだ
2018/02/12(月)19:04:43.26(1V20MNhs.net)
24デフォルトの名無しさん [sage]
2018/02/14(水)22:58:26.65(0r3oW/nt.net)
25デフォルトの名無しさん [sage]
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆
2018/02/16(金)06:49:37.38(W1XJdyx1.net)
26デフォルトの名無しさん [sage]
2018/02/22(木)15:21:57.27(H839Tp+8.net)
27デフォルトの名無しさん
2018/02/23(金)17:07:47.78(ZuaVfjvd.net)
28デフォルトの名無しさん
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
P5EA8
2018/05/23(水)20:21:30.55(Au5e7VGg.net)
29デフォルトの名無しさん
2018/07/05(木)01:24:10.02(RfoszcD2.net)
30デフォルトの名無しさん [sage]
参照の借用渡しが＆にしたんだろう
ねえ
2018/07/16(月)21:36:50.20(LulkQD8r.net)
31デフォルトの名無しさん [sage]
2018/07/18(水)21:34:09.40(uzHZzsnA.net)
32デフォルトの名無しさん [sage]
安全なだけでめっちゃわかりづらいだろ
ふつうの=でコピーと動きが違いすぎる
2018/07/19(木)20:56:32.22(zpCf8yuT.net)
33デフォルトの名無しさん [sage]
2018/07/21(土)00:47:19.79(mSZJjtkc.net)
34デフォルトの名無しさん [sage]
2018/07/21(土)04:00:07.64(PpAF+dgy.net)
35デフォルトの名無しさん [sage]
2018/07/21(土)23:33:24.37(SCDZUWz8.net)
36デフォルトの名無しさん [sage]
2018/07/23(月)21:30:42.22(2ez6F7EW.net)
37デフォルトの名無しさん
2019/07/28(日)18:59:39.61(5UHV96py.net)
38デフォルトの名無しさん [sage]
2019/07/28(日)19:00:55.44(5UHV96py.net)
39デフォルトの名無しさん [sage]
2019/07/29(月)21:44:34.57(CSar0obt.net)
40デフォルトの名無しさん [sage]
グロ
2019/07/30(火)00:56:59.74(ZDjzCSg/.net)
41デフォルトの名無しさん
キング・オブ・クソ
作ったゴミも使うカスも肥溜めで溺死すればいい
2019/10/30(水)14:37:39.93(4EQH++wv.net)
42デフォルトの名無しさん
2020/03/21(土)17:46:30.14(vJ0Lurek.net)
43デフォルトの名無しさん [sage]
馬鹿がなぜか選民思想やり出して終了。
2020/03/21(土)17:51:42.22(20ZHUxLS.net)
44デフォルトの名無しさん [sage]
2020/03/21(土)18:38:21.24(txJMIm7g.net)
45デフォルトの名無しさん
などと言われる。
しかし、コンパイル時エラーが出ると言うことは、裏を返せば、書けないアルゴリズムが存在するということだ。
直感的ではない回りくどい書き方が必要となり記述量が多くなる。
他の言語では好きな書き方が出来て、それはどれも正解だが、Rustでは正解が非常に狭くなる。
正解が狭いことがエラーを減らすなどという人がいるが、実際には、Rustは
書けるアルゴリズムが狭い、と言うことなのである。
これは言語設計の問題である。
なお、ここで言っているアルゴリズムは、全体的なものではなく、細かいミクロ的なものである。
通常の言語では、1つの仕事を細かい変数の使い方まで含めれば数万通り以上に書けるだろう。
そして、そのどれもが正解であり、結果が正しくバグも無いのだから、内のどれかが悪い書き方という
ことは特にない。
ところが、Rustでは、その大部分の書き方が出来ないのである。
駄目だから敢えてできなくしているのではなく、Rustが設計上、書けないアルゴリズムがあるということに他ならない。
つまり、Rustは書けるアルゴリズムが、本来コンピュータが書けるアルゴリズムの内の、非常に狭いサブセットに限られてしまうということである。
これは、Rustの大きな欠陥である。
2020/03/25(水)01:29:02 COJzGufp.net
46デフォルトの名無しさん [sage]
「駄目な書き方だからエラーにしている」
と言うのは間違いで、正しくは、
「Rustコンパイラの静的解析能力では、書き方を非常に限定しないと
正しいことを保障できなかったり、自動化できなかったりするため、
しょうがなく狭い書き方しか出来なくしている」
と言うことに他ならない。
人間には脳内の静的解析で明らかに正しいことが分かる書き方でも、
Rustコンパイラではでは同じことができないため、敢えて
変数束縛、借用、単一参照など、コンパイラでも解析できる程度の
範囲に書き方を限定して無理やり人間のプログラミングの可能性を
狭めているに過ぎない。
2020/03/25(水)01:29:24 COJzGufp.net
47デフォルトの名無しさん [sage]
2020/03/25(水)01:31:01 COJzGufp.net
48デフォルトの名無しさん [sage]
しかし、自分で独自にリンクリストを作ろうと思うと事態は一変する。
そこまで深く入った人ほど、Rustは難しい言語だと感じるはずで、
RustがC++程度で理解できると思ってる人は、99%、浅い所までしか使ってない
と言えよう。
2020/03/25(水)01:41:15 COJzGufp.net
49デフォルトの名無しさん [sage]
2020/03/25(水)08:33:39.98(atIoOIeM.net)
50デフォルトの名無しさん [sage]
RAD言語ならそれで良いが、システム言語では駄目。
2020/03/25(水)12:40:37 COJzGufp.net
51デフォルトの名無しさん
2020/08/09(日)13:48:40.83(cPfQFxYQ8)
52デフォルトの名無しさん [sage]
ベクター(動的配列)が主で、LinkedList<T>は、せっかくのリンクトリストの
特徴である末尾以外の「途中」への追加は出来ない。
これではリンクリストの意味が無い。
また、公式ドキュメントに
「ベクターの方がLinkedList<T>より速い」
などと書いてあるが、それはとんでもない間違い。
2020/08/28(金)02:41:24.81(BFWbiW8H.net)
53デフォルトの名無しさん [sage]
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;
}
}
2020/08/28(金)17:13:22 BFWbiW8H.net
54デフォルトの名無しさん [sage]
ゴミ
2021/01/08(金)10:57:50.09(4h6DBvmg.net)
55デフォルトの名無しさん [sage]
2021/05/05(水)10:12:10.05(Icux/Qfe.net)
56デフォルトの名無しさん
今２０代の連中がＲｕｓｔを使いこなせる様になっても、
システム開発に使える頃には、４０過ぎの中年だけど、まだプログラマー続けてるの？
2021/06/18(金)18:36:38.41(GgPo8kME.net)
57デフォルトの名無しさん
2021/06/30(水)12:11:47.40(TGFkopCB.net)
58デフォルトの名無しさん
2021/07/07(水)23:28:03.78(3EDdhBYW.net)
59デフォルトの名無しさん
2021/07/16(金)02:31:03.20(UUn46lBk.net)
60デフォルトの名無しさん
2021/07/21(水)02:06:52.85(DO3wSfvm.net)
61デフォルトの名無しさん [sage]
何かいいやり方があるはずだ。誰が見ても明らかな、たったひとつのやり方が。
そのやり方は一目見ただけではわかりにくいかもしれない。オランダ人にだけわかりやすいなんてこともあるかもしれない。
The Zen of Pythonの一節だけどRustの設計思想もこういうことなんじゃないか？
何通りもある書き方を統一することによってコードを読む人にも分かりやすくするってことだと思う。
もうそこは好みの問題だから気に入らなければやらないでいいんじゃないか？
2021/08/10(火)09:03:54.83(fPg8NGNP.net)
62デフォルトの名無しさん
Cと同様に低レベルな部分でも記述可能でさらにインラインアセンブリも可
2021/08/10(火)09:10:56.61(UUhRSoFC.net)
63デフォルトの名無しさん [sage]
できないのは variable length argument/array くらい？
2021/08/10(火)14:11:34.30(mSeKT5En.net)
64デフォルトの名無しさん [sage]
2021/08/11(水)07:11:51.41(KlEtC9pi.net)
65デフォルトの名無しさん
C/C++/Rust以外の言語ではどうやっても無理
2021/08/11(水)07:16:15.10(N49Uco17.net)
66デフォルトの名無しさん [sage]
unsafeは注意が必要な部分を限定するために用意された言語機能なのに
「unsafe使うならC/C++でいいじゃん」
とか考えてそうな雰囲気
2021/08/12(木)10:28:40.81(whMOJJYX.net)
67デフォルトの名無しさん [sage]
2021/08/12(木)10:57:49.37(tXISMw6z.net)
68デフォルトの名無しさん [sage]
いや、自走車椅子だろ
2021/09/04(土)03:57:00.95(kn1l/Q+t.net)
69デフォルトの名無しさん
2021/09/04(土)04:05:22.28(iqtSb51S.net)
70デフォルトの名無しさん
Juliaなんかだと並列・分散処理するために@distributed forなんて書くが、Erlangだとループ中に
spawnをして、Goもgoroutineを起動する。map/reduceなんかだと明らかにメニ―コアを使った方が
速いが、標準ではそうなっていなくて、外部ライブラリのrayonなどを使用する。
GoでもRustでもこれをさらに分散処理させるにはgRPCなど規格化されたインターフェースを通すが
やりたい事はJuliaの@distributed forなのに手間を感じさせる。
Rustにライトウェイトスレッドが言語仕様として入るとは思えないが、やはり言語には向き不向きが
存在する。近年のjavascriptを発端とするasync/awaitにも疑問が生じる。あまりにも多くの言語が
同期実行のライブラリと整合性が無さすぎる
2021/09/06(月)13:53:51.27(kq9rR1L5.net)
71デフォルトの名無しさん [sage]
2021/09/06(月)14:51:17.48(6RpN+EMp.net)
72デフォルトの名無しさん
たしかにJavaScriptのasync/awaitとRustのは最も対照的ですがどちらも良い特徴があると思います
JavaScriptはブラウザも外部のNode.jsもその言語実行環境として非同期ランタイムが組み込まれasync/await導入以前から非同期関数が標準として装備
そのため非同期関数が呼ばれたら次のスケジュールで即座に実行が始まりますね
一方でRustは標準の非同期ランタイムがなく用途に合わせて自由に非同期ランタイムを用意することが出来ます
さらにRustのasync/await自体はゼロコストで設計されており非同期関数が呼ばれても自動的にスケジューリングされない特徴があります
Rustはこれらに関して「何ができない」のではなく「何でもできる」わけなので
あとは記法の簡易性を求めるのならばその呼び出し関数等の設計とマクロでお好みの方面へ寄せることも可能です
2021/09/06(月)16:49:04.49(7r7RF488.net)
73デフォルトの名無しさん
これは良い書き方をしているが非同期ランタイムを自由に選べるのではなく、適切に選ばないと
インターフェースをサポートしない場合があるため、互換性が保てないでしょう。Rusterは
ゼロコストという話を良くしますが、Rustの非同期はタスクごとにステートマシンを作るために
確かにNode.jsなどと比べるjavascriptと比べれば、全体で非同期をスケジューリング管理する
ものと比べアロケーションや実行コストなどは小さいですが、それほど喧伝すべきことでもありません。
いずれにせよ多くの非同期はI/Oバウンドでありepollベースなどで管理されます。当然ながら
(Cに代わるようなハードウエア近い）システム言語なので出来ない事があってはイケていません。
私が言っているのは、Rustに限りませんがasync/awaitの記述が普通に考慮されてない設計の悪い
ライブラリが沢山あるという事です。Rustのマクロは最低だと思います、なぜわざわざ学習コストを
引き上げるのか理解できません
2021/09/11(土)00:36:45.81(YO3o85Uj.net)
74デフォルトの名無しさん [sage]
あなたの主張は意味がわからない
まず「互換性が保てないでしょう」は何との何の互換性が保てないのか？意味不明
次に「それほど喧伝すべきことでもありません。」は結局のところあなたは反論すら出来ずに同意してしまっている
さらに「Rustに限りませんが(略)設計の悪いライブラリが沢山あるという事です。」はRust言語に対する批判にすらなっていない
それぞれ具体的に問題点を述べましょう
2021/09/11(土)01:17:56.12(PRM8i6LA.net)
75デフォルトの名無しさん [sage]
async-awaitがマクロだった頃の話をしているのですか？
2021/09/11(土)01:24:36.44(Q/hQI3Xf.net)
76デフォルトの名無しさん
まず文書の書き方にケチを付けてロンパーする癖を直しましょう。
最初から非同期ランタイムの互換性と書いているでしょう。例えばasync-stdと
tokioは互換性がありません。今は互換性がほぼあるようになってきていますが
それでも完全ではありません。
ゼロコストFeatureという話は、VS Javascriptという言語のランタイムではその
通り認めていますが、コンパイル型の言語でコストが高い非同期は稀です。
Rust言語に対する批判しか書かないわけではありません。あなたは攻撃されたと
思い込む癖が強すぎる。「近年のjavascriptを発端とするasync/awaitにも疑問が
生じる。あまりにも多くの言語が同期実行のライブラリと整合性が無さすぎる」
という大本も読めない。まあそういう人間が増えすぎて居る訳で、こんな雑談で
怒り心頭になり、それぞれの具体的な問題点はあなたの性格でしょう。
言語的な反論をせずに文書の読解も出来ず、条件反射で相手を貶す。とてもでは
ないですが近寄りがたいですね
またマクロについても「マクロでお好みの方面へ寄せることも可能です」という
返答に関して感想を述べてるのに過ぎないのに、全く話を辿れていません。
2021/09/11(土)01:41:58.05(YO3o85Uj.net)
77デフォルトの名無しさん [sage]
具体的な問題点を述べましょう
例えばtokioの上に構築されたhttpモジュールであるhyperも互換レイヤーによりasync-std 上でも動作します
RustアンチスレでなぜJavaScriptを問題にしているのかも謎ですが
JavaScriptのasync/await/Promiseもあの環境で非常に優れて設計されています
この件についても具体的な問題点を述べておられないですね
2021/09/11(土)02:11:46.06(w5S7rLqj.net)
78デフォルトの名無しさん [sage]
以上
2021/09/11(土)11:03:00.32(LLoV+Okg.net)
79デフォルトの名無しさん [sage]
＞「近年のjavascriptを発端とするasync/awaitにも疑問が生じる。
＞あまりにも多くの言語が同期実行のライブラリと整合性が無さすぎる」
意味がちょっと不明です。
JavaScriptでそれらが用いられうる通信分野では、基本的に同期実行のライブラリは存在しません。
例えばhttpなどで取得してくるfetch()も非同期ですし、もっと低水準のモジュールも非同期です。
同期実行のライブラリと整合性が無さすぎるとは、何を意味しているのでしょうか？
2021/09/11(土)13:53:10.45(zUj2TAiQ.net)
80デフォルトの名無しさん [sage]
2021/09/11(土)13:59:42.94(QGVH5OH8.net)
81デフォルトの名無しさん
どう考えてもLinuxなりBSDなりある程度高度なOSがある事前提だ、OSのメモリーコンパクションが
無いとGCが無い故にメモリーの断片化が起こり、長時間稼働するタイプの小さな組み込みには向かない。
マイクロコントローラのメモリー付きSoCでブーストラップローダーがあるだけの組み込みには使えない
ま、サポートプラットフォームにTier1/Tier2でも、そういうのに使えるとは書いてないけど
2021/09/12(日)14:45:35.48(dsndgRWH.net)
82デフォルトの名無しさん [sage]
その文章だけならCにいれかえてもあってそうなんだが？
2021/09/12(日)15:02:08.52(raaoGYn7.net)
83デフォルトの名無しさん [sage]
つまりC/C++/Rustは組み込みやOSに向いていないとｗ
2021/09/12(日)15:22:52.56(lBuMyCBZ.net)
84デフォルトの名無しさん [sage]
2021/09/12(日)15:26:04.82(Cf6Jz1Ay.net)
85デフォルトの名無しさん [sage]
組み込みはピンキリだからスクリプト言語が動く環境まである
一方でC/C++/Rustじゃないと厳しい環境もある
2021/09/12(日)21:57:41.77(UrK9UNLE.net)
86デフォルトの名無しさん [sage]
同期実行ライブラリと整合性が無いというのはウソです
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がが入ることと
2021/09/12(日)22:17:14.89(Zjk1d74X.net)
87デフォルトの名無しさん [sage]
2021/09/12(日)22:19:55.41(s09Gb+ph.net)
88デフォルトの名無しさん [sage]
2021/09/12(日)22:44:56.06(Q5FBinyU.net)
89デフォルトの名無しさん [sage]
それは自覚症状が無いだけで自分が馬鹿なだけかも知れんが。
2021/09/13(月)20:47:01.12(dBMpD8or.net)
90デフォルトの名無しさん [sage]
2021/09/13(月)20:51:25.89(9PNw/wOW.net)
91デフォルトの名無しさん
2021/09/14(火)19:27:55.83(kyozNdb6.net)
92デフォルトの名無しさん [sage]
2021/09/14(火)20:13:08.96(Wng5bteL.net)
93デフォルトの名無しさん [sage]
2021/09/14(火)23:33:28.66(9cp1Eg6y.net)
94デフォルトの名無しさん [sage]
複数案件を同時進行した人なら
いくら完璧にしていても確率的にミスが入り込むとわかるはず
そしてC++とRustとの比較ならどちらが良いかも冷静に判断できる
2021/09/14(火)23:52:38.24(BSh8VTqx.net)
95デフォルトの名無しさん
そんな事を言ってるんじゃないと思いますよ、「複数のファイルのチェックサム計算」なんて単純な事なら
当然ながら同期と非同期でそれほど違いは出ないでしょうし互換性があるように見えるでしょう。なぜなら
チェックサム計算は一瞬で終わり非同期はファイル毎に区切っているから。チェックサム計算は同期コードで
いずれも書かれていて１つも違いがありません。
これをいくつかのファイルは巨大でファイル長が不明（無限では無い）が大きいファイルのチェックサム計算や
より複雑で時間のかかる計算を非同期で行いたいとすればどうしますか？チェックサム計算で、read_to_endは
使えずストリームを非同期に読み続けて計算することになるでしょう。という事はbytes.iter().foldも使えません
「同期実行ライブラリと整合性が無いというのはウソです」このように言い切ること自体に"気持ち悪い信仰"を
持っているのは良く分かりますが、元が「整合性が無さすぎる」と言っているのは、整合性がある１パターンを
示しても意味が全く無いという事です。多くの問題は「ウソです」と言い切れる浅はかさが問題です
http://qiita.comの記事なんて初心者のサンプルに過ぎません
2021/09/15(水)02:02:19.36(x4RgVtnC.net)
96デフォルトの名無しさん [sage]
確率的な話をするならコンパイラの塾制度考えた場合の確率を下回るくらいのメリットしかrustにはないよ。
2021/09/15(水)11:47:44.97(PYzW5a+n.net)
97デフォルトの名無しさん [sage]
rustcで検出できるバグを仕込む確率よりもrustcのバグを踏む確率の方が高いということ？
2021/09/15(水)20:26:11.48(77IP/X5S.net)
98デフォルトの名無しさん [sage]
2021/09/15(水)21:21:02.30(PYzW5a+n.net)
99デフォルトの名無しさん [sage]
2021/09/16(木)00:37:37.41(Efcezeu+.net)
100デフォルトの名無しさん [sage]
そのうち上位層はビジュアルプログラミングに取って代わられて行ったりしてね
2021/09/18(土)06:51:34.59(pceSJQ2d.net)
101デフォルトの名無しさん [sage]
2021/09/18(土)07:04:45.25(WtcFUHdh.net)
102デフォルトの名無しさん
2021/09/25(土)03:20:19.87(r08K7R9X.net)
103デフォルトの名無しさん [sage]
>無いとGCが無い故にメモリーの断片化が起こり、長時間稼働するタイプの小さな組み込みには向かない。
ヒープも使わない（ことが多いから）、メモリーの断片化も起きない
当然GCなんかいらない
rustが組み込みに向かないのは同意する
2021/10/20(水)16:37:55.38(rOkBuggn.net)
104デフォルトの名無しさん
スタックや初期化時以外で動的なメモリ確保がそもそもできなくない？
Unix風のプロセスモデルでもないとmallocし続けるだけでアウト
2021/10/20(水)19:56:54.98(VGECjsMp.net)
105デフォルトの名無しさん [sage]
リンクリストのノードを固定長メモリブロックとして使ったりする
例えばuItronのメモリプールの実装とかそんな感じ
ヒープはリアルタイム性がないから
で、rustはstatic mutが使い辛過ぎて、組み込みでは難しそう
2021/10/20(水)20:18:24.99(rOkBuggn.net)
106デフォルトの名無しさん
2021/10/20(水)20:22:41.04(VyYhhIkP.net)
107デフォルトの名無しさん [sage]
将来性を考えると、さすがにD言語よりはrustの方が……
2021/10/20(水)20:37:31.19(rOkBuggn.net)
108デフォルトの名無しさん
2021/10/20(水)22:36:34.87(VyYhhIkP.net)
109デフォルトの名無しさん [sage]
Dormant
Dead
縁起悪いよ…(´・ω・`)
2021/10/20(水)22:52:38.54(UtWr6ljA.net)
110デフォルトの名無しさん
まだまだマイナーな言語へ嫌がらせする
2021/10/21(木)18:37:53.89(wlIxx6Dc.net)
111デフォルトの名無しさん [sage]
2021/10/21(木)20:22:29.58(s+sF4o2E.net)
112デフォルトの名無しさん [sage]
将来を考えるなら、文字列でだらだら書くというスタイルが古臭いってなるかもね。
今のプログラミングは、分厚い本を読まされてる、書かされてるみたいなもん。
映像なら3秒でですむことを延々と書き連ねているようなもんだし。
2021/10/22(金)20:07:55.54(BGSpAusK.net)
113デフォルトの名無しさん [sage]
人間がコード書く役割が終わる方が先に来るんじゃないかな。
2021/10/22(金)21:52:45.50(v3Yxx0iq.net)
114デフォルトの名無しさん [sage]
AIでも同じようなことが言われていて、
囲碁で人間に勝つには100年かかるなんて言われてたからね。
>人間がコード書く役割が終わる
まさにそれ。
人間は「こうしたい」というのを表現できればそれで良いわけで、それをわざわざ文字列で延々と書き連ねるというのが古臭いことになるんじゃない？ってことね。
2021/10/23(土)08:17:48.59(126WIPxs.net)
115デフォルトの名無しさん [sage]
2021/10/23(土)08:56:15.06(3BoTC/ER.net)
116デフォルトの名無しさん [sage]
わざわざ人間が翻訳機になってるっていうのが古臭いって思うんよね。
2021/10/25(月)17:46:30.13(a6PpXdhO.net)
117デフォルトの名無しさん [sage]
文字によるプログラムっていうのが結局いつまで経っても1.5次元みたいなもんで、どことどこが関連しているのかということすらパッと見てわからないしね。
まあ、世の中には何百万行もあるプログラムでも簡単に目を通して全体像を把握できるような天才的な人もいるんだろうけど、私には無理だわ。
トシヨリガーとか、老害だとか言ってる割には旧来の手法に固執するんだな。
2021/10/25(月)17:54:38.98(a6PpXdhO.net)
118デフォルトの名無しさん [sage]
グラフィカルなプログラミング環境とか、設計手法だけどUMLとかあるにも関わらず一般的なプログラミング言語を置き換えるには至ってないよね
旧来の手法を置き換えるには何かしらのブレークスルーが必要なんだと思う
現状プログラミングが主に言葉で書かれているのは、人間がプログラムを考えていることと、人間の考えを厳密にコンピューターに伝える必要があることに由来していると思う
人工知能が発達して人間の曖昧な指示に従ってコンピューターがプログラミングするとか、脳波読みとりなど言語化なしで人間の考えを伝える手段が現れれるなどすれば状況は変わるかも知れない
2021/10/25(月)20:15:43.78(cubP7NbG.net)
119デフォルトの名無しさん [sage]
いわゆる "プログラミング" では無いかもしれないが。
そこの記述はグラフィカルでどうのこうのと言っても汎用性を求めると結局はテキストになるんじゃないかな。
まあ要求記述のテキスト、というとSQLがその一つなんだけどさ。
2021/10/25(月)20:53:20.91(IG0eAPOa.net)
120デフォルトの名無しさん [sage]
で、現実にやってるのは、やれCだなんだと、それぞれの方言に合わせて人間が一生懸命翻訳作業をして文字列で書き起こしている。
客観的に見れば実に珍妙な記号とあるふぁべっの羅列でね。
そして、流行りの方言が出るたびにその方言を覚えては翻訳作業。
でも、結局のところコードが大幅に減るわけでもなく、肥大化するにつれて誰も正しい全体像を把握できなくなるのは同じこと。そして、いつまで経っても無くならない誤訳…バグの山。
やはりこのスタイル自体に無理がきているんだと思うわ。まあ、究極はコンピュータそのものの考え方から変えないとダメかもしれないけどね。
2021/10/28(木)17:10:44.11(nJ3D7u2B.net)
121デフォルトの名無しさん [sage]
そのレベルの話だとコーディングと言うよりも設計の問題なのでは
2021/10/28(木)17:37:46.17(oV3TAAYO.net)
122デフォルトの名無しさん [sage]
受けとる方を考えてみろ。
2022/02/26(土)07:53:14.27(BV4vpVpG.net)
123デフォルトの名無しさん [age]
しかし、Rustは、多くの人が望ましくないと考える特定の動作も許可します。許可されるように言語を定義するだけです。たとえば、整数のオーバーフローを考えてみましょう。デバッグモードでは、Rustは整数のオーバーフローでパニックになります。良い。リリースモードでは、2の補数としてラップします。悪い。つまり、それは言語定義に含まれているので、非常に優れていますが、私に関する限り、これは、符号付き整数のオーバーフローを未定義の動作として参照するCおよびC++言語定義とほぼ同じくらい悪いものです。
2022/04/27(水)15:55:20 1aIRuPS7.net
124デフォルトの名無しさん [sage]
2022/04/27(水)16:14:27.17(fXEX2s7j.net)
125デフォルトの名無しさん
あかんところ列挙
・コンパイル型言語らしいけど、C++の方が速い(GCC万歳)
・CPLから派生した言語とかなり系統が違う(習得しづらい)
・関数宣言でわざわざfnをつけないといけない(文脈で理解できないのかコンパイラ)
以下、C++のあかんところ
・最近のは遅い->STL使わんかったらいい、もしくは自作
・バッファオーバーランとか、危ないことが起こる->そんな阿保プログラムを書かなかったらいい
2022/04/27(水)18:36:40.62(HjqqO7sC.netBE:557647423-2BP(0))
126デフォルトの名無しさん [sage]
2022/04/27(水)18:45:52.15(kbMyQ47R.net)
127デフォルトの名無しさん
そういうことを言いたいんじゃない。releaseとdebugで動きが異なることを言いたいのだ。例えばGoなどはどちらも動きはわからない。
Rustはどう考えても、プログラムの１つ１つを完全に知りえていなければプログラムを書いてはならず、安全な側へ倒すのではなく、releaseでオーバーフローを省略するのにそれで速いとゴマカしている。計算系のベンチマークテストなどまさにそう
また上のように「用意している」という表現も、限りなく敷居をわざと高くしているだけで、何の利点でもない。
2022/04/27(水)18:53:45.96(DngKLmNp.net)
128デフォルトの名無しさん [sage]
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を超えて溢れる寸前まで求まっている
2022/04/27(水)18:55:26.96(j3SjDNhs.net)
129デフォルトの名無しさん
2022/04/27(水)18:57:07.63(DngKLmNp.net)
130デフォルトの名無しさん [sage]
具体的にコードを比較して客観的に判断したい
2022/04/27(水)19:00:24.43(QwtQyiYP.net)
131デフォルトの名無しさん [sage]
release buildでもチェック有効にできるよ
https://doc.rust-lang.org/cargo/reference/profiles.html#overflow-checks
プログラムの一つ一つを理解しなくても書ける言語ってどういうものだろう
2022/04/27(水)22:32:13.33(Xa5DwGtB.net)
132デフォルトの名無しさん
今どきのC++は遅いっていうけど、新しいC++の仕様を使うからである。
つまり、Better Cみたいな使い方をすればRustより速くなる(実際そういう結果もある)。
まあ、体感はどっちもかわんねえべってとこだから、RustよりJava,C#とかスクリプト言語をアンチすればいいと思う。Rustで慣れてる人はRustで書けばいい。
2022/05/19(木)17:01:33.84(YoVN/Jlg.net)
133デフォルトの名無しさん [sage]
2022/05/21(土)23:22:45.63(zNzebGu9.net)
134デフォルトの名無しさん [sage]
C#にはC#スクリプトがあるが実行時に中間言語にコンパイルするだけだろ
2022/05/23(月)00:46:57.32(Fl/zPM6P.net)
135デフォルトの名無しさん [sage]
オブジェクトとして生成、消滅繰り返すようなプログラム組むと(普通にC++でかくとこっちになる)遅くなるよ
挙句の果てにメモリフラグメントが避けられない
普通にCで書くとよほどの馬鹿でも無い限り無駄なメモリ確保開放を繰り返すなんてことはしないから
2022/05/23(月)00:55:18.95(Fl/zPM6P.net)
136デフォルトの名無しさん [sage]
領域使い回せるってことは生成・解放するオブジェクトのサイズはだいたい一定なんだと思うけど
そうだとしたら最近の普通のmalloc実装ならそうそうフラグメント起こすことはない気がするけどどうなんだろ
ベンチマークとかあるの？
2022/05/23(月)01:27:08.69(aUQlcplw.net)
137デフォルトの名無しさん [sage]
2022/05/23(月)01:35:14.45(Fl/zPM6P.net)
138デフォルトの名無しさん [sage]
>>136
行列クラス考えてみろ
while(1)
E = A*B+C/D;
C++なら一行でかけるがテンポラリ領域を演算子の多重定義の中で確保開放繰り返さざるをえない
ETでなんとかなる部分もinverseがあるとそれもお手上げ
一時領域をwhileの外で確保してそれを使い回す方法と比べて早くしようがない。
2022/05/23(月)01:45:51.46(Fl/zPM6P.net)
139デフォルトの名無しさん [sage]
2022/05/23(月)01:48:39.79(Fl/zPM6P.net)
140デフォルトの名無しさん [sage]
速度に関してはC++の方が不利なことに対しては異論ないよ
ただフラグメントについては本当にそうなのか気になってた
今時のmallocなら直近にfreeされた領域再利用するから>>138みたいな例なら毎回同じ領域が割り当てられると思うよ
寿命が異なる複数のオブジェクトの確保・解放を繰り返すようなケースでも、オブジェクトが同サイズであればmalloc自体のフラグメントを防ぐ機構がうまく働いてくれるはず
まあ確かにRTOSのmalloc実装では問題起こるかもしれないけどね
ただ、そういうのは "最近の普通のmalloc" ではないと思う
2022/05/23(月)02:08:18.18(aUQlcplw.net)
141デフォルトの名無しさん [sage]
なんで同じ領域が確保されると保証されるのさ。今時のOSでww
そのエリアが外のタスクで割り当てられなかったことがなんで保証できるんだ?
とにかく動的確保、削除してフラグメント起こさないと思ってる方がどうかしてる。
そういう思い込みが通用するなら、所有権なんてもんは必要ないだろ。
あれはデフラグの対象にするかどうかが細大の目的
あと、普通のとか今時のとか、お前のあたのなかこっちは見られないんだから使うのやめろ
2022/05/23(月)02:25:01.02(Fl/zPM6P.net)
142デフォルトの名無しさん [sage]
>速度に関してはC++の方が不利
これもちょっと違うだろ
上で>>132が言ってるようにBetter cに留めて。
過度な見やすさや書きやすさを追求しなければ
C++はC機能包含してるんでC++で不利になることなんてない。
機能を使わなければいいんで不利になりようがない。
Pure C流ででもかけるわけだし
2022/05/23(月)02:44:22 Fl/zPM6P.net
143デフォルトの名無しさん [sage]
2022/05/23(月)08:16:07.89(aUQlcplw.net)
144デフォルトの名無しさん [sage]
#[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);
2022/05/23(月)09:11:41 n2ZPTBPD.net
145デフォルトの名無しさん [sage]
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の主張がおかしい
2022/05/23(月)09:17:13.61(n2ZPTBPD.net)
146デフォルトの名無しさん [sage]
なぜなら、一般的には「中間値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のようなケースでも最小限のメモリしか必要とせずに済む
2022/05/23(月)09:54:21.07(n2ZPTBPD.net)
147デフォルトの名無しさん [sage]
2022/05/23(月)11:54:34.12(n+tkR/ue.net)
148デフォルトの名無しさん [sage]
細分化してしまうという話かなんかと
混同してんのかな
2022/05/23(月)14:37:05.11(GiQn/B1E.net)
149デフォルトの名無しさん [sage]
> しかし>>145の結果のアドレスを見ると、確かに中間値は交互にアドレスが異なり2種類だが、全体で6つの領域で済んでいるところに注目
7つ使ってるように見えるんだけど、何を見て6つで済んでるって言えるの？
2022/05/23(月)15:10:34.13(K4XvBL00.net)
150デフォルトの名無しさん [sage]
2022/05/23(月)15:44:46 dNJCbMGg.net
151デフォルトの名無しさん [sage]
よく見ると2番目の中間値であるTest::new(111)のアドレスが変数aつまりTest::new(1)のアドレスと同じ
これはRust特有でその時点では変数a(や変数b)を使い終えて解放されているために再利用されたと推測できる
そのため6つメモリ領域で済んでいるのだろう
>>147
CやC++では使い終わった変数の領域が暗黙的には解放されないから7つのメモリ領域を使うと予想
2022/05/23(月)15:46:07 wWZ2mUik.net
152デフォルトの名無しさん [sage]
2022/05/23(月)15:51:35 K4XvBL00.net
153デフォルトの名無しさん [sage]
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つ使用に収まっているな
2022/05/23(月)16:28:21.49(wuIMUAe9.net)
154デフォルトの名無しさん [sage]
2022/05/24(火)10:09:58.38(PPYrRT7r.net)
155デフォルトの名無しさん [sage]
>>146
なーにを馬鹿な考察してんの?
おまえの実行するタスクの途中で他のタスクが実行され、そいつが解放したヒープを確保しないことを
なんで今時のマルチタスク、マルチユーザOSで保証できるのかと言ってる。
2022/05/30(月)14:58:44.37(MKPVbFKD.net)
156デフォルトの名無しさん [sage]
>Rustでは消費し終えた変数や中間値が使用していたヒープ領域もすぐに再利用されて使い回されるため
変数が確保されるのは関数コールの度に毎回上書きされるスタックであてｔヒープではない
そもそもヒープ領域の確保廃棄で何も問題なければメモリフラグメントなど発生するはずがない。
したがって長期間リブートを想定しないRTOSで、
予めメモリプールを確保してその中で固定的にメモリ割り当てなど行うこと自体全くの無意味ってことだが、
現実はそーじゃない。こんなもんエンベ試験あたりのイロハだろw
2022/05/30(月)15:12:27.13(MKPVbFKD.net)
157デフォルトの名無しさん [sage]
マルチタスク、マルチユーザーOSというキーワードが出てくるのがよくわからないけど、
物理アドレスの話してるとしたらスタックだろうがヒープだろうがOSの都合で変わりうるんだからヒープのフラグメントの話とはなんら関係ないよね
仮想アドレスの話をしているなら、自プロセスの他スレッドの挙動によってフラグメントしうると言うのは正しいけど
だいたいのmalloc実装ではarenaはスレッドローカルになるからフラグメントは置きにくいと思うよ
というか、どういうシチュエーションで何を実験したときにどのような問題が起きたのか、前提を明確にしてよ
組み込みのRTOSとかいう特殊環境が当たり前のように語られると意見のすりあわせができぬ
2022/05/30(月)15:42:14 9QWL5Xmb.net
158デフォルトの名無しさん [sage]
> >>138のような解放直後に同じサイズで領域を確保する場合は領
なんで、マルチタスクのOSが、おまえの都合のいいタイミングで解法直後に確保できるのかと言ってる。
例えば、解法直後に割込タスクがおまえのプログラムを一時実行停止し、
そこで開放したばかりのメモリエリアを確保しないとなんで言い切れるんだと聞いてる。
そして、ページングの発生もなんでおこらないと決めてかかってるんだ? 今時のOSでww
おまえが書き出したメモリエリアはあくまでプログラム側から見た論理アドレスだろ?
そこが実はページング対象になってなかったとなぜ断言できるんだ。
2022/05/30(月)15:55:38.95(MKPVbFKD.net)
159デフォルトの名無しさん [sage]
2022/05/30(月)15:57:12.40(MKPVbFKD.net)
160デフォルトの名無しさん [sage]
>マルチタスク、マルチユーザーOSというキーワードが出てくるのがよくわからないけど
汎用OSで自分の起動したタスクしか動いてないと思ってるわけ?
RTOSを持ち出したのは自分のタスクしか実行していなくても、フラグメントを起こす具体例として持ち出した。
そのRTOSでも細心の実装心掛けてるのに汎用OSなんでいわずもがなって話。
今時は、HWのメモリが大きくなってせいぜいページング時のプチフリーズ程度で気付いてない奴もいるだろうが、
やっぱりフラグメントは常時発生してる。
てか、メモリデフラグとか動かしたことないのか?
2022/05/30(月)16:07:33.52(MKPVbFKD.net)
161デフォルトの名無しさん [sage]
2022/05/30(月)16:23:56.84(S6YD6bxt.net)
162デフォルトの名無しさん [sage]
まずは基礎知識を勉強しよう
Rustにおいてタスクとは非同期にスケジューリングされるスタックレスなコルーチンのこと
そうでない意味のタスクならばプログラミング言語Rustとは関係ない話
>>156
そのRustプログラム例はBoxを使っているのでスタック上てはなくちゃんとヒープを用いた実験となっている
そんな基本的なことも理解できないならば勉強して出直してきなさい
>>160
それはRustとは全く無関係ない話
基礎的なことを会得していないとそういった無関係な話を持ち出してしまう
2022/05/30(月)16:55:49 ccLFuKy8.net
163デフォルトの名無しさん [sage]
2022/05/30(月)18:21:04.97(9QWL5Xmb.net)
164デフォルトの名無しさん [sage]
2022/05/30(月)22:33:20 SMH6yVl4.net
165デフォルトの名無しさん [sage]
2022/05/31(火)14:19:31.88(X/NoC31E.net)
166デフォルトの名無しさん [sage]
2022/05/31(火)14:23:20.93(5HfxTPdy.net)
167デフォルトの名無しさん [sage]
2022/05/31(火)16:38:22.49(COFqsPBY.net)
168デフォルトの名無しさん [sage]
たぶん誰も問題意識を共有できてない
2022/05/31(火)19:29:31.55(6cb4XAup.net)
169デフォルトの名無しさん [sage]
>>141は業務で触ってるとかで特性をよく知っているがそのコンテキストが他の人と共有できていないのだろう
2022/05/31(火)20:07:12.82(qkI00F5r.net)
170デフォルトの名無しさん [sage]
ここはRustアンチスレなのにプログラミング言語Rustとは無関係な話で暴れていている
2022/05/31(火)20:16:37.40(/PJVfDdU.net)
171デフォルトの名無しさん [sage]
2022/05/31(火)21:05:52.27(ycu/V5YM.net)
172デフォルトの名無しさん [sage]
もうちょっと丁寧に書いてくれれば分かりそうな気もするんだけど
2022/05/31(火)22:22:41.63(qkI00F5r.net)
173デフォルトの名無しさん [sage]
1.61.0ビルドしてるけどなんだかいろいろとボコボコDLしてくる()
1.61.0なのに 1.60.0-xxx をDLしてくるし()
あーうぜー
2022/07/07(木)09:23:29 kCv7I/gK.net
174デフォルトの名無しさん [sage]
悪質
2022/07/09(土)14:07:59.53(52J5yu6r.net)
175デフォルトの名無しさん [sage]
早く外せよ
[ここ壊れてます].net
176デフォルトの名無しさん
非人間的な設計で人間を不幸にしていく悪しき文明というか
2022/09/04(日)20:06:08.29(9yOWYxc4.net)
177デフォルトの名無しさん [sage]
2022/09/07(水)04:11:07.00(h5FYCJvl.net)
178デフォルトの名無しさん [sage]
git も Rust もゴミ
2022/10/08(土)07:50:08.22(fwLI4Y/X.net)
179デフォルトの名無しさん
× Preparing metadata (pyproject.toml) did not run successfully.
│ exit code: 1
╰─> [64 lines of output]
こんなエラーが出た
すげーイラっとくる
> .toml
クズ言語
2022/10/10(月)15:43:56.96(OkLu+Ovr.net)
180デフォルトの名無しさん [sage]
重要な部分はRustで作らないと思うよ
2022/10/12(水)21:08:34.50(BNoDz+WR.net)
181デフォルトの名無しさん [age]
2022/10/20(木)18:29:22.69(uCae9JR1.net)
182デフォルトの名無しさん [sage]
俺もgitもgithubも使いにくいと思っていた。
2022/10/20(木)18:33:14.88(sgmqUmRA.net)
183デフォルトの名無しさん [sage]
rustもそういう匂いがぷんぷんする。
2022/10/20(木)18:58:12.23(1LIQj8JQ.net)
184デフォルトの名無しさん [sage]
2022/10/20(木)19:21:40.91(LtHEChVu.net)
185デフォルトの名無しさん [sage]
2022/10/21(金)01:23:53.55(sdgXBR6P.net)
186デフォルトの名無しさん
いい加減にしろよカス言語
2023/08/11(金)13:18:17.34(98F5eoJ/.net)
187デフォルトの名無しさん
2023/08/11(金)13:34:35.94(v1edpQDw.net)
188デフォルトの名無しさん [sage]
2023/08/12(土)00:05:38.13(qDONLKM9.net)
189デフォルトの名無しさん [sage]
2023/08/15(火)08:53:12.04 ca01mENm.net
190デフォルトの名無しさん
RustとCはまあまあイケる
いいじゃんいいじゃん
2023/10/02(月)13:43:22.96 sFvf9xp1.net
191デフォルトの名無しさん
2023/10/03(火)16:57:54.88 rr8MlNTB.net
192デフォルトの名無しさん
C++カス
Rustもうちょっとがんがれ
2023/10/05(木)17:14:00.69(WXXGTjkD.net)
193デフォルトの名無しさん
trait 境界が変わって
あれ？ってなることが多いな
2024/04/21(日)15:50:07.23(aDRU4sod.net)
194デフォルトの名無しさん [sage]
trait境界を満たせなくなるとコンパイラが教えてくれるので安全にリファクタリングできて良いよね
2024/04/21(日)18:44:44.75 GAd5jyBU.net
195デフォルトの名無しさん
2024/04/23(火)10:33:27.89(9zVe0TBb.net)
196デフォルトの名無しさん [sage]
2024/04/23(火)10:47:04.81(bJrnaJAq.net)
197デフォルトの名無しさん
2024/04/27(土)21:26:16.94(+PotGQRe.net)
198デフォルトの名無しさん [sage]
意識高そうですね()
2024/04/28(日)14:02:08.42(e+80DOh2.net)