Rust part22

**デフォルトの名無しさん** · 2024/01/20(土) 23:21:40.08

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

公式ドキュメント
https://www.rust-lang.org/learn

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

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

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

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.2ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2024/02/14(水) 05:28:01.52

>732 >734
Rustのtrait boundはあらかじめ型の方でtraitを準備しておかなきゃいけない。
これはRustが嫌っているクラスの継承みたいなもので、genericsやるごとに元の型/traitを弄くり回す必要が出てこない？
呼び出し元が真に必要なのは機能だけなんだから、同じ名前で互換性のある引数型・戻り値型ならそのまま利用できる方が良い。

まあ、ダックタイプみたいに手を抜かずにAdapter作れ、と言う方針でも良いけど、それならAdapter helperをもっと充実して欲しいところ。
AdapterパターンとかDecorator パターンて重要なのに言語側のサポート薄いよなぁ。

**デフォルトの名無しさん** · 2024/02/14(水) 06:58:38.09

>>738
>>これはRustが嫌っているクラスの継承みたいなもの

クラス継承は基底クラスの実装をそのまま継承する実装継承になっていることが問題点
一方でRustはトレイト境界となるトレイトに対して自分で実装を用意する
したがってRustでは実装継承とはならず問題が生じない

**デフォルトの名無しさん** · 2024/02/14(水) 07:00:00.30

自演きもいなあ

**デフォルトの名無しさん** · 2024/02/14(水) 07:00:27.71

実装継承はゴミ

**デフォルトの名無しさん** · 2024/02/14(水) 07:05:57.04

>>737
Ninはコンパイル時間の無駄があるからゴミ
Pythonは実行までの速度が一番早い

**デフォルトの名無しさん** · 2024/02/14(水) 07:33:52.24

>>739
全然理解できていないね。
継承の問題点は、コンパイラ都合で早い段階で設計を固定しなきゃいけない「早すぎる最適化」。
機能とか実装の問題じゃなくて設計の問題。

**デフォルトの名無しさん** · 2024/02/14(水) 08:08:30.71

>>742
実運用はビルド済だから関係ないな。

**デフォルトの名無しさん** · 2024/02/14(水) 08:09:58.02

>>743
それは継承の問題点
Rustのトレイトは各型が自分で実装するため継承ではない

**デフォルトの名無しさん** · 2024/02/14(水) 08:41:45.06

>>745
早すぎる最適化が問題なんだから、トレイトもその問題を引き継いでるぞ

**デフォルトの名無しさん** · 2024/02/14(水) 08:51:32.74

>>746
早すぎる最適化が問題になるのは継承
Rustのトレイトは継承ではなく合成で用いる

**デフォルトの名無しさん** · 2024/02/14(水) 08:55:57.66

>>745
全然理解できていないね。
>>743根は設計の問題で実装関係無いし、継承特有の問題というわけでもない。
>729というとfはDrawable以外のトレイトのdrawが使えない制限あるし、Circleも、問題領域に関する知識の少ない設計初期にtrait Drawableを実装するという仕様固定を行う必要がある。
c++のtemplate concept はあくまでdrawのみに依存するという違いがある。

**デフォルトの名無しさん** · 2024/02/14(水) 09:07:35.89

真面目に理解したいなら>>730が正解だからstructural typingとnominal typingの意味を調べてくればいいよ

**デフォルトの名無しさん** · 2024/02/14(水) 09:20:06.07

>>729
C++は酷いな
struct定義の時点でdraw()宣言を要求してしまうのか

Rustなら
struct定義の時点でdraw()宣言を要求せずに済む
後からdraw()という機能(＝Drawableトレイト)が必要になった時点で
structに対してDrawableを実装すればいい
Rustの方が優れてるな

**デフォルトの名無しさん** · 2024/02/14(水) 09:36:07.02

>>738
複オジに毒されすぎ
オジが一つ覚えで繰り返し書いてる内容がRust開発陣の見解だと勘違いしないようにね

**デフォルトの名無しさん** · 2024/02/14(水) 09:47:17.10

>>738
根本的な理解がおかしいので説明すると
Rustのtraitは機能を抽象化している
各型はその機能が必要になった時にそのtraitを実装(impl)すればよい
必要な分の各機能(trait)を実装することで結果的に各機能の合成となる

**デフォルトの名無しさん** · 2024/02/14(水) 09:59:07.19

細かな実装上の違いはあるけど概念レベルでは Rustのトレイトも他言語のインターフェースも同じ
実装上の違いを見て異なる概念だと勘違いしてると本質を見失う

**デフォルトの名無しさん** · 2024/02/14(水) 10:10:46.95

>>750
そりゃダックタイピングでdrawを使いたいんだから、drawの無い型は対象外。

>>752
もともとの話はダックタイピングでtraitじゃないよ。
Rustで静的ダックタイピング・ダックテストする方法はあるかしらん？

**デフォルトの名無しさん** · 2024/02/14(水) 10:17:10.59

ダックタイピングという問題ありまくりのものを有り難がるのはバカだけ

**デフォルトの名無しさん** · 2024/02/14(水) 10:27:45.39

>>738
言語側のサポートならマクロで十分でしょ

macro_rules! impl_drawable {
($type:ty) => {
impl $crate::path::to::Drawable for $type {
fn draw(&self) -> f64 { self.draw() }
}
}}

を定義すれば

impl_drawable!(Circle);

だけでimpl Drawable for Cirle {...}を生成できる
渡された型が同じ引数＆戻り値のself.draw()をもってないとコンパイルできないから実質ダックタイピング
Drawableに関数を追加したらマクロにも追加すればいい

draw関数の有無だけで照合するのは別の意味のdrawも対象になるから危なっかしい
impl traitだとどのモジュールのDrawableを実装するかまで指定できるから混同の心配がなくなる

**デフォルトの名無しさん** · 2024/02/14(水) 10:44:54.87

ダックタイピングは使う側が気をつければなにも問題ないんだよなあ
そこらへん理解してないあたり実装をやったことのないエアプなんだろうな
かわいそう

**デフォルトの名無しさん** · 2024/02/14(水) 10:53:25.15

>>757
その「使う側が気をつければ問題ない」が最悪
ミスが入り込んだ時に気付かず問題を引き起こす
ダックタイピングを持ち上げるのはバカだけ

**デフォルトの名無しさん** · 2024/02/14(水) 11:07:38.32

使う側が気をつけるならC++も問題ないからな

**デフォルトの名無しさん** · 2024/02/14(水) 11:17:22.43

>>756
これがいわゆる実装継承の再発明
このケースはマクロよりも同じ実装継承のデフォルト実装のほうがベター

**デフォルトの名無しさん** · 2024/02/14(水) 11:23:15.20

>>759
そゆこと
だからRustは不要

**デフォルトの名無しさん** · 2024/02/14(水) 11:28:02.15

ダメ人間の思想「使う側が気をつければ問題ない」によって
今まで数多のなかなか見つからないバグやセキュリティホールを生じてきたのがプログラミング言語の黒歴史
今後はそのような言語を用いてはいけない

**デフォルトの名無しさん** · 2024/02/14(水) 11:51:49.92

ここで>>9-20の流れを振り返ってみましょう

**デフォルトの名無しさん** · 2024/02/14(水) 11:52:42.46

C の後置 ++ 演算子のようなことをする Rust の関数が標準で有ったりしますか？
リファレンスマニュアルをざっとみた感じでは見つけられないのですが……。
具体的に言えば

fn increment(dest: &mut u32) -> u32 {
let t = *dest;
*dest += 1;
t
}

みたいなことをしたくて、いかにもよくありそうなパターンなので標準内にあってもよさそうなもんだと思った次第です。

**デフォルトの名無しさん** · 2024/02/14(水) 12:13:59.14

>>760
どこをどう曲解しても実装継承にはならんだろ
すべてのケースでマクロ使うとでも思ってるの？
〇〇の思考回路はよく分からん

>>764
Atomic系統ならfetch_addがあるけど普通のincrementは単純＆限定的すぎて逆にないな
std::mem::replace使えば
replace(&mut t, t+1)
とかできるけど+1するだけなら大袈裟すぎる気がする

**デフォルトの名無しさん** · 2024/02/14(水) 12:19:27.37

>>761
だからの文が全然繋がってなくてワラタw
こういう低能はプログラミングしちゃダメだよ。

**デフォルトの名無しさん** · 2024/02/14(水) 12:25:13.12

>>755
そうして無駄な依存関係を負の遺産として引きずるか、設計が破綻して再構築するか。
DbCとか勉強したほうがいいよ。

**デフォルトの名無しさん** · 2024/02/14(水) 12:29:23.30

>>767
ダックタイピングが負の遺産であることは自明だが
ダックタイピングを使わないことが負の遺産だと主張する君は破綻している

**デフォルトの名無しさん** · 2024/02/14(水) 12:49:07.16

>>768
自明だと検証できる証明を示して頂戴。

検証可能性の無い主張は単なる疑似科学だし。

**デフォルトの名無しさん** · 2024/02/14(水) 12:52:16.39

欠点がない言語なんて無いから言い争ってもね。

**デフォルトの名無しさん** · 2024/02/14(水) 12:57:57.69

そもそも人間自体が欠陥なんだからその人間の作った言語に欠陥があるのは自明

**デフォルトの名無しさん** · 2024/02/14(水) 13:07:28.33

たし🦀

**デフォルトの名無しさん** · 2024/02/14(水) 13:09:31.24

おれたちは欠陥と共存してよりよいプログラミングスタイルを目指すべき

**デフォルトの名無しさん** · 2024/02/14(水) 13:16:05.40

drawという名前のメソッドを作ったらそれらが全部ダックタイピングとして使われうることを想定しないといけないのきつすぎる
適当な名前つけたら想定外の使われ方をすることをケアしないといけないわけだ

**デフォルトの名無しさん** · 2024/02/14(水) 13:33:10.33

境界知能が可視化されてる

**デフォルトの名無しさん** · 2024/02/14(水) 13:53:52.28

>>774
当たり前だろ。
インターフェイスは利用者に対する契約だからな。使わせる気が無ければ公開するな。

**デフォルトの名無しさん** · 2024/02/14(水) 13:55:32.21

>>776
ダックタイピングはその契約書が定義されてないのが良くない
Traitは契約書の定義みたいなもんだ

ダックタイピングは白紙の契約書にサインするようなものだ

**デフォルトの名無しさん** · 2024/02/14(水) 13:57:04.55

>>775
お前のこと？

**デフォルトの名無しさん** · 2024/02/14(水) 14:31:04.48

>>777
これな

**デフォルトの名無しさん** · 2024/02/14(水) 14:41:15.13

>>765
replace だと借用規則に引っかかってエラーになるようです。
まあ自分で書いてもたいしたものじゃないのでなければなくても困りはしないんですが……

**デフォルトの名無しさん** · 2024/02/14(水) 15:12:12.70

>>780
Copy型だから通りそうな気がしたけど無理だったか
何か技がありそうだけどそこまでするほどの問題じゃないよな

**デフォルトの名無しさん** · 2024/02/14(水) 15:36:36.14

>>764
Rustで++は排除されている

理由はたくさんあるようだが
例えば今回のそのCコードは*dst++では動かず(*dst)++とする必要があるようにミスが増えるとか
前置と後置の間違いミスも多いことに加えて
生ポインタはsafe Rustから排除されたため*ptr++の形が出て来ないことや
move/copy問題もあったかな

**デフォルトの名無しさん** · 2024/02/14(水) 16:02:27.29

>>782
そんな話はしてないです。
役に立つことを言えないなら余計な茶々入れるな。

**デフォルトの名無しさん** · 2024/02/14(水) 16:29:39.74

>>783
おまえ質問してる分際でキチガイなのか？
そういう態度を改めないなら二度と教えてやらんぞ

fn increment(dest: &mut u32) -> u32 {
　std::mem::replace(dest, *dest + 1)
}

**デフォルトの名無しさん** · 2024/02/14(水) 16:36:51.93

質問している人間相手なら関係ないことを書いて良いわけではない

**デフォルトの名無しさん** · 2024/02/14(水) 16:42:22.39

>>784
結果的に役に立たないことがあってもしょうがないですが、関係ないことをアンカーで書くのは正当化できない迷惑行為です。
質問者 (特に初心者？) には迷惑をかけてよいと考えているのだとしたらそれは改めるべき悪です。

**デフォルトの名無しさん** · 2024/02/14(水) 16:46:13.61

ついに存在しないCコードの幻覚が見えるようになってしまった複製おじさん……

**デフォルトの名無しさん** · 2024/02/14(水) 16:46:26.67

一方、質問文を誤読して解答してしまった人間に対して強く当たって良いわけでもない

**デフォルトの名無しさん** · 2024/02/14(水) 16:51:03.66

>>788
あれは誤読 (?) なんでしょうか。
茶化しているように受け取ったので腹立たしかったのですが、
そうだとしたら >>783 は言い過ぎですね。

ID:S2bQYQek さん、すいません

**デフォルトの名無しさん** · 2024/02/14(水) 17:05:32.23

人間の注意力読解力は実際この程度なので、人間にC++を扱うことは難しい

**デフォルトの名無しさん** · 2024/02/14(水) 17:06:20.11

だから境界知能なんでしょ

**デフォルトの名無しさん** · 2024/02/14(水) 17:19:45.82

腹立てるのもわからなくはないがそんなにキレてレスするようなことではないだろ
気に入らなかったらスルーする程度には心に余裕を持っておこう

**デフォルトの名無しさん** · 2024/02/14(水) 17:26:03.70

tmuxよりscreen派だよ。

**デフォルトの名無しさん** · 2024/02/14(水) 17:50:47.59

個人的には後置インクリメントだけを関数化するのは微妙に感じる

fetch_addとかは必要性を理解できるけど単純なpost_addやpost_incrementは一段階上の処理を関数化するので十分でそのほうが見通しがいいように思う

**デフォルトの名無しさん** · 2024/02/14(水) 19:51:05.67

>>762
こういう偉そうなこと散々言ってたhaskellがなぜ流行らなかったのかすら理解できてないというのが愚かだよね。

**デフォルトの名無しさん** · 2024/02/14(水) 19:57:21.78

>>777
c++ template conceptも碌に知らないでダックタイピングをけなしているのか。なかなか……
ダックタイピングは契約の主体・時期・範囲が違うという話だかね。

**デフォルトの名無しさん** · 2024/02/14(水) 20:14:14.28

>>796
C++では機能の異なる同名メソッドを区別できないから欠陥品

**デフォルトの名無しさん** · 2024/02/14(水) 20:52:10.35

>>797
引数・戻り値で区別できるだろ。

**デフォルトの名無しさん** · 2024/02/14(水) 21:01:37.45

>>798
それに依存してしまうのがC++の限界

**デフォルトの名無しさん** · 2024/02/14(水) 21:18:41.79

>>799
名前も引数も戻り値も区別できないんだったら、ダックタイピングで呼び出す側はそもそも区別する必要あるんですかねぇ。

**デフォルトの名無しさん** · 2024/02/14(水) 21:58:58.38

>>796
それだとRustでいうところのトレイト境界を課すことができないな
つまりC++では安全に呼び出すことができない
呼び出したメソッド内で出来ること出来ないことが定まらないため

**デフォルトの名無しさん** · 2024/02/14(水) 22:13:29.10

>>801
「呼び出したメソッド内で出来ること出来ないこと」
て何？

Rustのtraitて、副作用のコントロールできたっけ？

**デフォルトの名無しさん** · 2024/02/14(水) 22:26:20.82

traitのprovided methodのdefault実装で呼び出せるのはrequired methodと
trait境界がある場合はそのtraitのmethod
そしてそれらで構成された他のprovided methodのみ
って制限をC++でどうするんだろ

**デフォルトの名無しさん** · 2024/02/14(水) 23:19:42.33

>>803
コンセプト。

**デフォルトの名無しさん** · 2024/02/14(水) 23:20:56.22

>>792
毎度毎度のことで余裕を削られた最後だったんだよ。

**デフォルトの名無しさん** · 2024/02/15(木) 00:20:11.01

毎度毎度のことという認識を持っていながらなぜここに書き込むのか

**デフォルトの名無しさん** · 2024/02/15(木) 00:23:07.31

>>806
せやな。
けど日本で比較的活発な Rust コミュニティというとここなんよ。

**デフォルトの名無しさん** · 2024/02/15(木) 07:06:08.60

>>804
concept記述が多すぎて書いててイヤになるな
普及しそうにない仕様がまたC++に増えた感じ
Rustが必要な機能を洗練して提供しているのと対照的

**デフォルトの名無しさん** · 2024/02/15(木) 07:43:10.62

>>808
洗練されすぎてて「早すぎる最適化」がバンバン起きるけどな。
枯れた既存プログラムの置き換え用途が無難なところかと。
コード破棄前提のプロトタイピングはコスト的にキツイか。問題領域の知識がほとんど無い開発初期で使えるのは未来を予測できる天才ぐらいだろ。

**デフォルトの名無しさん** · 2024/02/15(木) 07:55:56.64

>>809
Netflixの天才プログラマーが丸2年間Rustに全力費やして周りに吹聴した挙句に
RustやめてGoにする宣言してる
理由を真面目に話してるから一見の価値のあり

**デフォルトの名無しさん** · 2024/02/15(木) 08:11:38.37

>>810
検索したけど見つからなかった……
リンクある？

**デフォルトの名無しさん** · 2024/02/15(木) 08:17:50.82

[Why I Use Golang In 2024](https://www.youtube.com/watch?v=6gwF8mG3UUY)

**デフォルトの名無しさん** · 2024/02/15(木) 08:19:40.94

>>812
サンクス。
家帰ったら見るわ。

**デフォルトの名無しさん** · 2024/02/15(木) 08:48:36.69

>>812
見た
ほとんどの話がプログラミング言語の比較よりももっと抽象的な話で中身が薄い
そして批判されてるのはなぜかTypeScrpt
Goについてはシンプルなのが好きでジェネリックが導入されてワクワク
Rustはifに括弧がないのたスネークケースが嫌いだけどGoもifに括弧がないよ
Rustの型システムはとても素晴らしいけど、

**デフォルトの名無しさん** · 2024/02/15(木) 09:52:51.93

>>808
過去のコードと矛盾しない形での後付けだからな。
C++ を根本から変えるような大革新なのに (ほとんど) 互換性を損なわないように出来ているという意味ではかなり気が利いた設計ではある。
簡単に互換性を切り捨てていると資産が蓄積されないし、かといって変わらないままでもいられないのは宿命というもんだよ。
Rust だって歴史が積み重なればいずれそうなる。
「綺麗なのは使われないもの」という格言を聞いたことないか？
Rust は C++ の歴史のグダグダから学んだ反省としてエディションという概念を導入したが、これがどれくらい上手く機能するかは現時点では未知数だ。
規格策定・処理系保守のリソースは無限なわけではないしな。

**デフォルトの名無しさん** · 2024/02/15(木) 09:55:25.99

エディションはすでに複数あるけど
あっても無理とか問題起きるとか
実例あるの？

**デフォルトの名無しさん** · 2024/02/15(木) 10:07:56.04

>>816
問題が抑えられているのは問題がないように保守されているからで、
その体制を「ずっと」続けられるものかどうかはずっと続けてみないとわからない。
今問題があるとかそういう話じゃないから未知数と述べてる。

**デフォルトの名無しさん** · 2024/02/15(木) 10:11:47.35

C++は貧弱な家を土台に増築工事をしまくって部屋数は多いが使われていない部屋だらけ
C++プログラマーの多くが知らない部屋、見たことない部屋、たどり着けない部屋が多数あるまま、さらに増築工事が進んでいる

**デフォルトの名無しさん** · 2024/02/15(木) 10:21:13.40

まあいうてもRustも将来的には増築されたバケモノになるか途中で破壊的変更的なものを入れるかするかの選択になるのでは

Cから呼べてCを呼べる限りはどの言語を使っても良いとする立場であれば今一番使いたい言語はRustではある

**デフォルトの名無しさん** · 2024/02/15(木) 10:32:36.57

>>817
今は良くても未来は何が起こるかわからない論法は
何にでも使えるから意味ある話とは思えないけど…

**デフォルトの名無しさん** · 2024/02/15(木) 10:37:24.02

「出来る」ということを大前提として確信できて、
その上で「上手く出来る」ならより良いってのが産業的な考え方だ。
おおよその場合に上手く出来ても
ちょっとした想定外に直面したときに破綻するようでは使い物にならない。

現実の問題ってのは想定してないところから出てくるものだから
そういうことも乗り越えられることを証明するには
実績 (歴史) を重ねるしかしょうがないんだ。

C++ は上手くやったとは言えなくても、汚くても打てる手が有る道具として信頼を得た。

Rust は今の時点では実に使いやすいように見えるが、
本当の意味で現実の使用に耐えうるものなのかは現実に使い倒してみるまでわからない。

**デフォルトの名無しさん** · 2024/02/15(木) 10:38:37.60

今の時点で使いやすければなんでもいいんだYO

**デフォルトの名無しさん** · 2024/02/15(木) 10:45:22.07

C++コンパイラが諸問題を指摘してコンパイルエラーにしてくれる状況は来そうにない
これだけ増築工事を重ねてもまだ見込みが立たないまま

**デフォルトの名無しさん** · 2024/02/15(木) 11:47:28.36

C++の知識は大いに再利用されているので現実世界の変化は小さい
想定外かもしれないのは変化の大きさではなく
現実世界を定義できないことだ
定義できるのは理論だけ

**デフォルトの名無しさん** · 2024/02/15(木) 12:02:34.79

>>821
今の想定が甘いとか具体的指摘なかったら
想定外の対処ができてないから駄目は無敵論法

**デフォルトの名無しさん** · 2024/02/15(木) 14:40:35.94

そりゃWeb系だとGoのほうが使いやすいに決まってるでしょ
パフォーマンスもスクリプト言語よりはめちゃくちゃ速いから十分

**デフォルトの名無しさん** · 2024/02/15(木) 14:47:01.34

サーバーサイドは群雄割拠時代よね
Rust、Go、Java/Kotlin、C#いっぱいある

**デフォルトの名無しさん** · 2024/02/15(木) 16:20:13.71

>>825
駄目とは言ってない。
駄目かどうかも「わからない」ことが産業的なハードルだよねって話なんだが、わからんかな。

**デフォルトの名無しさん** · 2024/02/15(木) 16:46:19.25

>>828
あなたの話相手してもrustでも他言語でもいいけど
問題回避のためにこういう仕様や実装にすべきじゃないか
みたいな議論が成り立たないのでそちらがおよそ産業的じゃないね

**デフォルトの名無しさん** · 2024/02/15(木) 16:50:52.01

すべてを疑っても産業だけは疑いようがないって話なら
想定内と想定外の境界がどの辺にあるのかはなんとなくわかる

**デフォルトの名無しさん** · 2024/02/15(木) 17:21:54.77

>>814
Rustは型〇ナニーで長時間バトルだったと言ってるぞw
>>812動画の人がいくら天才でも2年間かき回したのは頂けない

**デフォルトの名無しさん** · 2024/02/15(木) 17:26:25.25

Rustは非同期処理がC++より扱いやすいおかげでサーバー方面に進出したのは良い
さすがにフロントでRustは微妙そうだけど、このままどんどん多方面に普及してほしい

**デフォルトの名無しさん** · 2024/02/15(木) 17:31:26.55

Ruby は、Go/Rust/Elixir の3大言語を超えた！
Rust の上昇は止まったか？

Stack Overflow 米国年収。2022 -> 2023

Ruby : 9.3 -> 9.9 万ドル
Elixir : 9.3 -> 9.6
Go : 8.9 -> 9.3
Rust : 8.7 -> 8.7

多くの言語 : 6.5～7 -> 7.3～7.8

PHP : 5 -> 5.9
Dart : 4.4 -> 5.6

**デフォルトの名無しさん** · 2024/02/15(木) 17:35:21.87

>>832 夢見てないで現実見ては？
https://active.nikkeibp.co.jp/atcl/act/19/00546/011500001/

**デフォルトの名無しさん** · 2024/02/15(木) 17:41:41.98

>>812
流し聞きしたけど複雑だとかしょーもない構文の好き嫌いみたいな話しかしてなくて草

**デフォルトの名無しさん** · 2024/02/15(木) 17:53:07.04

>>835
Rustインフルエンサーの成れの果てですなw

**デフォルトの名無しさん** · 2024/02/15(木) 18:08:05.70

>>834
せめて用途別のプログラミング順位を挙げてくれ

…単発に言っても無駄か😭