結局C++とRustってどっちが良いの？ 8traits

**デフォルトの名無しさん** · 2023/10/28(土) 13:45:00.38

「C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」
「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」

っていう雑談スレ。

・C/C++ <=> Rust いまさら聞けない移行質問なども適当にどぞ
・レスバはじめんのは勝手だけど、面白いこと・へぇなこと書いたヤツが優勝
・マな話は、マのスレもご活用ください↓

前スレ: 結局C++とRustってどっちが良いの？ 7traits
http://mevius.5ch.net/test/read.cgi/tech/1693451813/

関連スレ(マ板): Google&Microsoft「セキュリティバグの70%はC/C++のメモリ管理ミス。Rustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/

**デフォルトの名無しさん** · 2023/10/29(日) 11:55:56.89

デフォルトをsafeにするって話やろw
そうすると現行のライブラリはビルドできないので取り敢えず全部unsafeで囲う
バージョンを重ねてunsafeの部分を減らすって戦略でしょ?

**デフォルトの名無しさん** · 2023/10/29(日) 12:10:31.41

>>8
それ意味ないのわかんない？

**デフォルトの名無しさん** · 2023/10/29(日) 12:58:33.36

null safetyですら無理なんだからunsafeなんて夢のまた夢

**デフォルトの名無しさん** · 2023/10/29(日) 13:01:53.93

positive list と nagative list の違いやろ
どっちも一長一短があるってだけで
どっちが一方的に優れているということではない

**デフォルトの名無しさん** · 2023/10/29(日) 13:06:42.15

前者が明らかに劣ってるのは自衛隊見れば明らかじゃん

**デフォルトの名無しさん** · 2023/10/29(日) 14:22:40.43

青山繁晴ファンですね判ります

**デフォルトの名無しさん** · 2023/10/29(日) 14:24:26.17

ちなみに Rust の unsafe {} は positive list に相当すると思う

**デフォルトの名無しさん** · 2023/10/29(日) 16:22:18.96

時代は静的検出なので、冒頭に

#pragma safe

とかでも書くとかになるんじゃないかな
そのうしろに、縛りの識別子が入るのでもいい

**デフォルトの名無しさん** · 2023/10/29(日) 16:22:22.63

unsafe {}ってなに？
ポインタ扱えなくするやつ？

**デフォルトの名無しさん** · 2023/10/29(日) 18:07:40.10

｝ // あとでみなおす

とりあえず生ポはなしかな
ポインタはきちんと定義される

**デフォルトの名無しさん** · 2023/10/30(月) 01:11:12.37

>>9
あー、そういうことね。

**デフォルトの名無しさん** · 2023/10/30(月) 14:08:13.49

前スレ
>>997
HashMapはとVecは異なる型なので直接代入できない
一般的に入力イテレータinput_iterからHashMapを作るには
HashMap::from_iter(input_iter)とすればよい
これは代入先の型がHashMapの時のinput_iter.collect()と同じ
collect()の正体はfrom_iter()を呼ぶだけ

ちなみにfrom_iter()はFromIteratorトレイトのメソッド
引数としてIteratorだけでなくIntoIteratorも取れるため
今回の入力ベクタinput_vecに対してinto_iter()せずとも
そのままHashMap::from_iter(input_vec)と書ける
一方でcollect()を使う場合これはIteratorのメソッドなので
明示的に変換してinput_vec.into_iter().collect()となる

**デフォルトの名無しさん** · 2023/10/31(火) 05:55:29.82

ゲーム業界はC++かC#
Rustが入る余地なし

**デフォルトの名無しさん** · 2023/10/31(火) 08:54:10.63

Rust がリファクタリングと相性が悪いんじゃないか
と思うことが時々というより割と頻繁にある

**デフォルトの名無しさん** · 2023/10/31(火) 10:17:54.25

設計が悪いおじさん「設計が悪い」

…とはいうものの、書き味ってもんがあるよね言語って

**デフォルトの名無しさん** · 2023/10/31(火) 20:53:25.14

難しそうという直感でリファクタリングを中止できるのは損なのか得なのか

**デフォルトの名無しさん** · 2023/10/31(火) 22:01:39.08

Rustはリファクタリングや更新メンテとの相性いいと思う
C/C++で他人もしくは過去の自分が書いたコードの肝の部分をうっかり踏み抜いてメモリデバッグコースとなるところを
Rustは未然に防いでくれてる

**デフォルトの名無しさん** · 2023/10/31(火) 22:13:21.13

リファクタリングでエンバグしにくいけど、そもそもリファクタリング自体しにくいよね

**デフォルトの名無しさん** · 2023/10/31(火) 22:25:05.59

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2687r0.pdf
C++はfeature gate方式でアノテーションした箇所のみ
static analyzerでチェックする方針で一応進み始めてるのね

なんというか過去の資産を生かすというのは大変なんだな
Rustと同レベルのsafetyが提供できるようになるかどうかまだわからないけどまあ頑張ってという感想

**デフォルトの名無しさん** · 2023/11/01(水) 03:51:28.75

悪い(かも知れない)設計を
良い(かも知れない)設計に
するのがリファクタリングのモチベだと思うので
元の設計が悪い(かも知れない)のは仕方ないが
良い(かも知れない)設計に変更するのを阻む力をRustはもってる
もちろんリファクタリングでエンバグしない利点は認めている

**デフォルトの名無しさん** · 2023/11/01(水) 03:53:16.74

更新メンテでエンバグしないと言っても
汚いコードが汚いまま増設されていく不安しかない

**デフォルトの名無しさん** · 2023/11/01(水) 05:10:40.48

リファクタリングなんてもんは無能な働き者がすることよ

**デフォルトの名無しさん** · 2023/11/01(水) 08:38:55.26

以上、無能な働き者の感想でした

**デフォルトの名無しさん** · 2023/11/01(水) 08:49:48.50

耳が痛いわ～ｗ (横から

>>27
走り読み…と思ったら、かっちりしたまとめだった
型に含めることばっかり(自分なりに)考えてたが、属性かー。

ああそういや、VCの属性プロバイダ、API公開まだだったよな

**デフォルトの名無しさん** · 2023/11/01(水) 09:15:51.82

borrow! またお前かっ!!
ですね
判ります

あとは C# みたいな PartialTrait があれば良いのに

**デフォルトの名無しさん** · 2023/11/01(水) 09:29:13.02

>>28
他の言語との比較も含めて具体的な例を上げてくれないと
何が困ってるのかよくわからん

**デフォルトの名無しさん** · 2023/11/01(水) 11:28:14.65

>ゼークトの組織論において、もっとも害のある存在とされるのが、無能な働き者（愚鈍：勤勉）タイプの人材です。正しい判断力や行動力が備わっていないにもかかわらず、自身の判断で行動してしまう特徴を持っています。いわゆる「余計なことをしてくれる」タイプの人材です。無能な働き者が動くことで間違った判断により損害が出たり、周囲が後始末に追われたりといった混乱を招きます。しかも、本人は「よかれと思って動いている」点が、大きな問題となるのです。

**デフォルトの名無しさん** · 2023/11/01(水) 11:36:32.25

無能な働き者は放置しておくことで、組織にとって大きな損害をもたらすリスクとなります。
努力や判断のベクトルが間違っているだけで、意欲的な人材であるかもしれません。適切に関わり軌道修正を図れば、組織に貢献してくれる人材になってくれるかもしれません。この困ったちゃんを相手にする余力が会社や関係者にあればよいのですが、そうでない場合は自己都合退職へ誘導し、早めに組織から追い出しましょう。

**デフォルトの名無しさん** · 2023/11/01(水) 12:40:12.80

軍人を4つのタイプに分類する「ゼークトの組織論」と呼ばれる軍事ジョークがあり[注釈 2]、ゼークトが以下のように語ったとされる。
---------8<----------8=------
これは実際には同時期のドイツ軍人であったクルト・フォン・ハンマーシュタイン＝エクヴォルトが副官に述べたとされるもの[31]が元になっている。

**デフォルトの名無しさん** · 2023/11/01(水) 19:08:00.09

いつの間に、こんなに積極的に、異物は排除しましょうなんて世の中に深化したのかねえ
世知辛い

**デフォルトの名無しさん** · 2023/11/01(水) 19:59:16.09

>>38
>いつの間に
いつと問われれば人が集落として生活するようになるぐらい古代から…なんじゃね
村八分とか神隠しとかぐらいは聞いたことあると思うけど
司法がない時代は私刑が日常的に行われていたんだよ
今は法律もあるしネットで大騒ぎすれば助けてくれる奴も出てくるだろうけど
属していた会社なり組織からは切り離される形に落ち着くだろうね

**デフォルトの名無しさん** · 2023/11/01(水) 20:11:22.67

Rustはリファクタリングでのエンバグ防止も強力で開発効率良いな

**デフォルトの名無しさん** · 2023/11/01(水) 22:31:20.11

>>38
嫌なら見るな
嫌なら出ていけ

**デフォルトの名無しさん** · 2023/11/01(水) 23:11:21.03

競技プログラミングでは何でみんなc++なのですか

**デフォルトの名無しさん** · 2023/11/02(木) 02:07:29.05

>>42
Rust使ったことないだろ

**デフォルトの名無しさん** · 2023/11/02(木) 09:27:36.71

>>36
東近江市市長ですね判ります

**デフォルトの名無しさん** · 2023/11/02(木) 09:30:06.68

>>39
私刑の大半は「自分が気に入らない相手を消す」だろ

**デフォルトの名無しさん** · 2023/11/02(木) 10:28:31.37

ゼロサムゲームなんだよねえあいつがいると、こっちの幸せの取り分が減る

**デフォルトの名無しさん** · 2023/11/02(木) 11:00:23.03

C++のchrono
Sun=0, Mon=1, ..., Sat=6
Rustのchrono
Mon=0, Tue=1, ..., Sun=0
なんかの嫌がらせか？これ

**デフォルトの名無しさん** · 2023/11/02(木) 11:01:31.85

訂正
C++のchrono
Sun=0, Mon=1, ..., Sat=6
Rustのchrono
Mon=0, Tue=1, ..., Sun=6
なんかの嫌がらせか？これ

**デフォルトの名無しさん** · 2023/11/02(木) 11:38:23.20

>>48
enumで処理するもんじゃないの？

**デフォルトの名無しさん** · 2023/11/02(木) 12:27:57.80

いっしょは嫌だったんじゃない? (はなほじ

**デフォルトの名無しさん** · 2023/11/02(木) 13:14:01.78

>>49
0と7が日曜だと便利なんだよ
なんで変えちゃったのかね

**デフォルトの名無しさん** · 2023/11/02(木) 14:01:21.75

おまえら全員エアプログラマーだな
Rustのchronoは両対応で困ることはない
num_days_from_sunday()だと日曜日から0発進
num_days_from_monday()だと月曜日から0発進

**デフォルトの名無しさん** · 2023/11/02(木) 14:21:03.74

ISO8601では月曜は1で日曜は7なんだよな。

**デフォルトの名無しさん** · 2023/11/02(木) 14:43:04.82

>>53
Rustのchronoが日曜スタートと月曜スタートの両対応にしている理由がそれ
C++のchronoでISOに変換するには日曜日だけif文するか再び%7する必要がある

**デフォルトの名無しさん** · 2023/11/02(木) 15:51:19.67

たぶん何も考えてない+誰も使わないから放置されているだけだね
Mon=0固定の前提でTryFrom<u8>なんか実装してるし

**デフォルトの名無しさん** · 2023/11/02(木) 16:27:45.50

そこは言語によって異なるんだよ

Pythonは月曜スタート
weekday() 月曜日=0 ～日曜日=6
isoweekday() 月曜日=1 ～日曜日=7

Javaも月曜スタート
DayOfWeek 月曜日=1 ～日曜日=7

だから両対応しているRustが最も良い状況

**デフォルトの名無しさん** · 2023/11/02(木) 20:37:31.47

曜日の内部表現とかどうでもいいだろ…

**デフォルトの名無しさん** · 2023/11/02(木) 21:59:20.29

HTTPでJSONやりとりしてるとき思い込みで
バグになるというのはあるかも

**デフォルトの名無しさん** · 2023/11/02(木) 23:52:30.67

今回のchronoでイチャモン始めたやつも
日曜日開始のC++しか知らなくてそれが正しいと思い込みをしてたからな
月曜日開始のISO8601とそれに従うプログラミング言語を一つでも知っていればそんな勘違いは起きなかった

**デフォルトの名無しさん** · 2023/11/03(金) 00:21:59.00

と、C言語のtm構造体から続くC/C++/UNIX系全般の伝統を知らなかった人が申しております

**デフォルトの名無しさん** · 2023/11/03(金) 00:34:37.66

恥ずかしいのぉ
ああ恥ずかしい

**デフォルトの名無しさん** · 2023/11/03(金) 00:58:32.47

>>60
それも常識だな
そしてISOおよびそれに準じるJavaやPythonも常識
両派あることを知っていれば両対応のRustを批判しだすような愚かな言動はしない

**デフォルトの名無しさん** · 2023/11/03(金) 03:57:01.11

>>62
コウモリ野郎が一番嫌われるんだよ
おまえは獣なのか鳥なのか

**デフォルトの名無しさん** · 2023/11/03(金) 06:56:19.57

伝統的には日曜始まり、商用的には月曜始まり、ということだろ。

そもそも現代主流のグレゴリオ暦自体が欠陥だらけ (素数の7を週単位にしている、月の日数がバラバラ) だから、効率を気にしてもしょうがない。
完全数の6と3素数積の30を基準にすれば全然違ったのにな。

**デフォルトの名無しさん** · 2023/11/03(金) 08:41:35.38

>>59
おまい望月衣望子そっくりな人間だな

**デフォルトの名無しさん** · 2023/11/03(金) 08:41:37.96

>>64
だからその日曜始まり日曜終わり両方に対応できる日曜0,7が有能だった話よ

**デフォルトの名無しさん** · 2023/11/03(金) 10:30:38.41

C++もc_encodingとiso_encodingで両方対応はしてる
簡単に変換できるから正直どうでもいいけど

https://en.cppreference.com/w/cpp/chrono/weekday/encoding
このドキュメントはReturn valueの2) の内容が間違ってる
レビュープロセスが心配になるな

**デフォルトの名無しさん** · 2023/11/03(金) 11:42:31.25

>>58
シリアライズ時と異なるエンコーディングで復元しようとしたらそりゃバグるわな
でもそんなやつらのために内部表現を統一しろと言われても誰も相手にしないでしょ

**デフォルトの名無しさん** · 2023/11/03(金) 12:30:23.11

>>56
JavaはWeekFields経由で日曜始まりにもできる
Pythonは日曜始まりのインデックスを直接取得することはできないがcalenderモジュールで日曜始まりのカレンダーを扱える

どちらもRustほど低レイヤーやC++を意識する必要がないからRust比べて少し高いレイヤーで日曜始まりにも対応している
Rustの開発者にとって最もいい状況が他の言語の開発者にとっても最もいい状況とは限らない

**デフォルトの名無しさん** · 2023/11/03(金) 13:42:53.76

=== 複製おじさん（通称複おじ）について ===
Rustスレを中心に活動し、2023年4月現在で1年以上ム板に住み着くRustacean。無自覚な荒らし。

Rustスレでは、基本的に他住民の意見を聞いて糧とすることなく、自らのコードが最善であると、ID変更自演を交えいつまでも主張し続ける。
同スレで「所有権が複製される」という違和感のある表現を、「違和感がある」とする他住民の意見をすべて否定してしつこく擁護し続けたことから、「複製おじさん」というあだ名が付けられた。
それ以外のム板スレでは、基本的に他住民の意見を聞いて糧とすることなく、Rustこそが最善であると、ID変更自演を交えいつまでも主張し続ける。
その基本戦術は、「GC言語は遅い」の一声でC/C++/Rust以外の言語を否定し、残ったC/C++は安全ではないので、Rustが最善であるとするもの。

しかしながら、Rust以外の言語に関しては、正当な批判を展開するのに十分な知識を持っているとは言いがたい。
本スレPart1では、C++の問題点を指摘しようとして多数の誤り・知識不足を露呈することとなった。特にしつこく食い下がったのが「動的ディスパッチ」に関する誤解である。
https://mevius.5ch.net/test/read.cgi/tech/1677286186/786-799（ID:Evbafc70とID:RiLc+pIfが複製おじさんであると考えられている）
要約すると、通常「条件分岐」と呼ばれるものを「動的ディスパッチ」と呼ぶのが正しいと主張し続けたのである。
常識的にはあり得ない誤解だが、提示されたC++のコードが自らの主張（C++にはパターンマッチが無い）に不都合であると感じたためか、C++のコードを正しく読み解くことができないにもかかわらず脊髄反射的に否定してしまい、その根拠として誤った論理をこじつけてしまったものと思われる。

ちなみにこの後、同種の誤解を持って書き込むID:wHEiYRW7（これはID使用歴的に複製おじさんとは考えにくい）に対して、正しい理解に基づく指摘を行う単発IDが複数出現するが、この中にも複製おじさんが多数含まれていると考えられている。
このように自分の誤りを認識した場合、それを認める書き込みは決して行わず、別人の振りをして最初から正しく理解していた体を装うのも複製おじさんの特徴である。

**デフォルトの名無しさん** · 2023/11/03(金) 13:43:15.14

テンプレ忘れてるぞ

**デフォルトの名無しさん** · 2023/11/03(金) 15:43:05.53

ゲームプログラミングに向かない時点でRustに勝ち目は無い

**デフォルトの名無しさん** · 2023/11/03(金) 16:17:15.97

ゲームとかどうでもいい

**デフォルトの名無しさん** · 2023/11/03(金) 16:35:04.29

プログラミング言語はとにかくユーザ数が増えて裾野が広がらないとだめよ

とはいっても、Rustはその性格上エンジン系にはとても強いと思う

**デフォルトの名無しさん** · 2023/11/03(金) 20:01:25.17

なんでゲームに向いてないの？

**デフォルトの名無しさん** · 2023/11/03(金) 20:18:57.74

ビルド時間が長いとか主要なゲームエンジンが対応してないとかかな？

**デフォルトの名無しさん** · 2023/11/03(金) 20:23:49.80

>>74
ゲームエンジンこそどうでもいい
どうせ他人の成果物使うだけやし
つまりRustはゲームプログラミングに向いてない

**デフォルトの名無しさん** · 2023/11/03(金) 20:27:09.44

>>75
オブジェクト指向じゃないから大規模開発に向いてない

**デフォルトの名無しさん** · 2023/11/03(金) 20:27:51.26

ゲームはプログラムの積み上げ方式
Rustなんか使い物にならん

**デフォルトの名無しさん** · 2023/11/03(金) 20:48:01.15

え？rustってオブジェクト指向じゃないの？

**デフォルトの名無しさん** · 2023/11/03(金) 20:54:38.72

>>77
エンジンを作る側の話やで

**デフォルトの名無しさん** · 2023/11/03(金) 21:23:41.57

>>78
むしろRustは大規模開発にも適するように設計された言語
今どきの普通にマルチパラダイムで当然オブジェクト指向もサポート

**デフォルトの名無しさん** · 2023/11/03(金) 22:56:37.98

これすごいわ
https://www.youtube.com/watch?v=62ZcxDGawd4
Rust もびっくり

**デフォルトの名無しさん** · 2023/11/03(金) 22:58:02.02

>>75
>>79
グローバル変数が超絶面倒臭いからじゃね

**デフォルトの名無しさん** · 2023/11/03(金) 23:50:14.81

オブジェクト指向を理解してない無能が多すぎる

**デフォルトの名無しさん** · 2023/11/03(金) 23:54:28.74

オブジェクト指向なんてもはや有害じゃねという
話も出てるようだけど

**デフォルトの名無しさん** · 2023/11/04(土) 00:10:04.03

既存のオブジェクト指向言語の置き換えを狙ってるなら
既存のオブジェクト指向言語の機能は備えんとなぁ
設計からやり直す必要が生じてまんどくさってなる
スクラッチから新たに書くのなら支障ないだろうけども
それではいつまで経ってもマイナー言語だよ
この先生きのこれん

**デフォルトの名無しさん** · 2023/11/04(土) 00:22:53.36

みんな反発しても結局オブジェクト指向に帰ってくる
みんなC++に帰ってくる

**デフォルトの名無しさん** · 2023/11/04(土) 00:23:19.27

最近のプログラミング言語は基本的にオブジェクト指向だがクラス継承だけは亡くなったらしい

最近のプログラミング言語
【クラス継承がない】Elixir、Go、Julia、Nim、Rust、Zig
【クラス継承がある】Kotlin(=Javaの後継)、Swift(=Objective-Cの後継)
つまり過去のしがらみでクラス継承を含めざるを得なかったKotlinとSwiftを除いて
全ての言語でクラス継承は亡くなった

**デフォルトの名無しさん** · 2023/11/04(土) 00:27:29.67

おかげでみんなマイナー言語のままじゃんw

**デフォルトの名無しさん** · 2023/11/04(土) 00:28:23.25

人間は保守的なんだから
互換性を軽視したらユーザは絶対にぶんどれん

**デフォルトの名無しさん** · 2023/11/04(土) 02:16:54.87

>>89
GUI開発用言語とそうでない言語にきれいに分かれてんね

**デフォルトの名無しさん** · 2023/11/04(土) 03:14:34.51

GUIはクラス継承要らないだろ
有害なクラス継承しかないとクラス継承を使って巨大なピラミッドを作ってしまい
その反省も各新言語が揃って意図的にクラス継承を廃止した要因

**デフォルトの名無しさん** · 2023/11/04(土) 03:24:41.20

継承無くした結果、馬鹿なことをやらされる
https://qiita.com/muumu/items/a0d111d129d20240d182

**デフォルトの名無しさん** · 2023/11/04(土) 05:01:54.27

それはクラスの継承というよくない古い考え方しかできない人向けの方法だな
様々に方向性も異なる方針の新プログラミング諸言語がクラスの継承だけは導入しない同じ結論に至った重みは大きい

**デフォルトの名無しさん** · 2023/11/04(土) 05:58:52.07

IUnk教わい、なくなるといわれるとちょっとさみしい (なくなるとは言われてない

**デフォルトの名無しさん** · 2023/11/04(土) 06:13:35.65

継承がない言語には大抵はmix-inという優れた代替が用意されてる
継承もmix-inもないRustは無能

**デフォルトの名無しさん** · 2023/11/04(土) 07:37:08.58

そうゆうのがない、切り捨ててるから、Linuxカーネルに来てよろしいって言われたのかもねしらんけど

やっぱり必要となりゃ、そのうち解禁(追加)になるでしょ

**デフォルトの名無しさん** · 2023/11/04(土) 07:50:02.45

>>95
極端だな
そんな考えじゃC++から移行なんて益々困難だし
こんなスレ立てて対立煽りするレベルにも達してないじゃないか
>この記事ではC++やJavaで継承を使っていた人がRustで同様の実装をしたいときにどうすればよいのかを説明します。
この課題については君はどうしたらいいと思ってる？

**デフォルトの名無しさん** · 2023/11/04(土) 08:26:29.68

第1スレはわからんけど、このスレの>>1は俺

**デフォルトの名無しさん** · 2023/11/04(土) 09:10:11.30

>>89
Javaの開発者も継承だけは間違いだったと言ってるみたいだね

**デフォルトの名無しさん** · 2023/11/04(土) 09:32:38.86

64 デフォルトの名無しさん 2023/09/26(火) 09:36
以前Javaのユーザグループミーティングに出席した際、James Gosling（Javaの生みの親）がメインの講演者として招かれていました。
すばらしいQ&Aセッションの途中に、こんな質問が出ました。
「もう一度最初からJavaを作り直すとしたら、どこを変更したいですか？」
答えは「クラスを除外するでしょうね」というものでした。
笑いが静まった後、彼が説明したのは、本当の問題はクラス自体ではなく実装継承(extendsの関係)なのだということでした。
インターフェースによる継承（implementsの関係）のほうが望ましいのです。できる限り実装継承は避けたほうがよいでしょう。

**デフォルトの名無しさん** · 2023/11/04(土) 09:32:49.65

やっぱりコミットするならシープラだなとおもいました

**デフォルトの名無しさん** · 2023/11/04(土) 09:56:14.27

その論法に乗っかってやると過去の
言語のパラダイム変化はどうやって起きたのか
謎になるな

**デフォルトの名無しさん** · 2023/11/04(土) 09:59:34.34

>>93
>GUIはクラス継承要らないだろ
要るか要らないかという話はしてないよ

1) Elixir、Go、Julia、Nim、Rust、Zig
2) Kotlin、Swift

1)の言語でGUI作れなくはないけど実際に作る開発者がかなり少ない
逆に2)の言語は大半の開発者がGUIを作ってる
それには理由があるということ
もっと言えばクラス継承的な機能の有無はトレードオフだからそれを理解しましょうねという話

**デフォルトの名無しさん** · 2023/11/04(土) 10:34:34.64

多くの高機能webサイトはGUIアプリと言って良いと思うが
ts jsのクラス機能はあるけど使わないな

**デフォルトの名無しさん** · 2023/11/04(土) 10:49:05.41

やっぱりRustが最強だなっておもいました

**デフォルトの名無しさん** · 2023/11/04(土) 11:16:32.88

最強はRust世代

俺のおかんはC++