次世代言語25 TypeScript Swift Go Kotlin Rust Nim

**デフォルトの名無しさん** · 2022/04/17(日) 17:52:35.38

スレタイ（順番はRedMonk準拠）以外の言語もok

前スレ
次世代言語24 Go Nim Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1647887021/

**デフォルトの名無しさん** · 2022/04/29(金) 21:24:48.98

Reasonってどうですか？

https://reasonml.github.io/

**デフォルトの名無しさん** · 2022/04/29(金) 22:15:53.12

こんスレってなぜかJuliaの話、完全スルーするよな。Go？Rust？Zig？Nim？時代遅れのローエンド言語や

**デフォルトの名無しさん** · 2022/04/29(金) 22:27:03.12

>>370
GoとPHP、どっちも使わない人からしたら大して変わらない説。

**デフォルトの名無しさん** · 2022/04/29(金) 22:38:01.94

>>373
よっぽど根に持ってるんだな。
ちょっと病的な感じ。

**デフォルトの名無しさん** · 2022/04/29(金) 22:48:27.27

ローエンド言語なんて言葉ある？
ローレベル言語ならわかるけど

**デフォルトの名無しさん** · 2022/04/29(金) 22:57:18.29

>>375
単に知られてないから話題に反応できないだけだと思う
良いところ教えてよ

**デフォルトの名無しさん** · 2022/04/29(金) 23:02:55.81

Julia、せっかく新規言語で型付けと動的性のバランスを取れる立ち位置にあったのに、抽象-具象の継承ベースの型を採用した部分が個人的にジェネリクスと噛み合いが悪いと思っていて悲しい
1-originとかは正直瑣末事だと思ってる分そこだけが本当に合わない

一応最新バージョンだとパラメトリックな抽象型とそのパラメータに抽象型を使えるし、その部分型をパラメータにも抽象型コンストラクタ（？）にも適用できるから実用上十分なんだと思うが

**デフォルトの名無しさん** · 2022/04/29(金) 23:13:16.89

JuliaのユーザーってPythonは当然として、他にはMATLABやRが競合になるようなコミュニティだから、
このスレとはまるで層が違うんじゃないかな
MATLABやRの話も全く出ないし

**デフォルトの名無しさん** · 2022/04/29(金) 23:27:24.69

Juliaって計算科学や数値解析に特化した、R言語みたいなものでしょ？

**デフォルトの名無しさん** · 2022/04/29(金) 23:34:47.33

Julia厨はクソみたいな押し付けするくらいなら
自分で他言語のライブラリの移植でもした方がよっぽど使ってもらえるという当たり前のことすら理解してないからな。

**デフォルトの名無しさん** · 2022/04/29(金) 23:47:45.01

>>380
その継承が中途半端なことしかできないし
継承を採用したことも失敗してるし
Juliaはあかんね

**デフォルトの名無しさん** · 2022/04/30(土) 00:03:38.50

継承は基底クラスと派生クラスの役割（責務）の分担が非常に難しいです。
よほど上手く設計しないと、すぐに「スパゲッティ・オブジェクト・プログラム」ができあがります。
継承は実装の再利用という面があるので、得てしてコピペの代わりに使われがちでもあります。
既存のあるクラスの振る舞いをちょっとだけ変えたいから継承を使おうってやってしまうと、
派生クラスのソースを見ただけでは何をやってるのか全くわからない最悪のコードになります。
まだコピペのほうがマシなことも。

最初はちゃんとクラス階層の設計がされていたとしても、だんだん皆が使う共通ルーチンを基底クラスに持たせよう、としてしまうとか、
基底クラスは、すぐに、巨大かつ影響範囲が広すぎてイジれない「神クラス」になるでしょう。
この場合の基底クラスの役割は、グローバル変数そのものと言ってよいですね。

とにかく、継承を使うと、コピペ、グローバル変数の使用、といった「禁じ手」と実質的に同じことが簡単にできてしまいかねません。
もし継承を使うのであれば、かなり注意が必要です。

その一方で、継承でないと絶対にダメという用途もあんまりないのです。
継承を一律禁止してしまってもそんなに困らないところがあります。
そのため最近ではGoやRustなど言語の仕様として継承（インタフェースではない実装を持つクラスの継承）を禁止している言語が増えているという有り様です。

**デフォルトの名無しさん** · 2022/04/30(土) 00:45:40.28

今北産業

**デフォルトの名無しさん** · 2022/04/30(土) 00:48:57.89

長い。そして間違っている。
Rustは代わりにtraitで継承を表現できるが、Goは表現する方法はなく、似たことをするとデータ構造を弄くることになる。
そもそも継承においてはデータ構造と実装の併合が問題なので、あとは察してください。

**デフォルトの名無しさん** · 2022/04/30(土) 00:53:39.80

じゃあ継承使わないでプラグイン機構使いたいときはどうすんの？

**デフォルトの名無しさん** · 2022/04/30(土) 00:55:27.41

プラグイン機構とだけ言われても意味が一意じゃないと思うけど
mixinのことかいな？

**デフォルトの名無しさん** · 2022/04/30(土) 00:56:29.80

Composition over inheritanceは30年近くも前のGoFですでに広まってるのになぜ次世代言語スレで話題になるんだろう

**デフォルトの名無しさん** · 2022/04/30(土) 01:03:52.06

ていうかJuliaの型システム知らなかったから簡単に調べたけど具象型はsupertypeになれないとか書いてあるんですが
Juliaでもいわゆる継承の問題点はちゃんと回避されているんではないですかね

**デフォルトの名無しさん** · 2022/04/30(土) 01:17:16.86

>>391
継承とジェネリクスとの相性の悪さが問題なのではないかな

**デフォルトの名無しさん** · 2022/04/30(土) 01:19:25.03

>>390
その後に継承のデメリットの方が多いと分かってきたため
そのデメリットをどう回避するかが各言語の主題となっている

**デフォルトの名無しさん** · 2022/04/30(土) 02:04:17.75

>>390
知った気になって語りやすい話題だからだろう。

実装の拡張を肯定しつつデータ構造を直接拡張しないところが重要。
それを字面だけ解釈して、結局は妥協でデータ構造が暗黙に継承するような、先進言語の形だけ真似した言語もあるくらいだからね。

**デフォルトの名無しさん** · 2022/04/30(土) 02:17:19.37

>>387
Goだけがどの話題でも機能不足との結論になっていて悲しいです

**デフォルトの名無しさん** · 2022/04/30(土) 02:24:06.80

クラス継承しか知らないプログラマーは何でも継承で表現しようとするために失敗しているわけだから
継承のないプログラミング言語で修行させればそこは学習できるはずだ

**デフォルトの名無しさん** · 2022/04/30(土) 03:12:19.75

実際言うほど継承使わないからなぁ
共通的な部分を継承で済ます場合はあるけど
データもその共通部分がはっきりしているなら親クラスで定義するけど
ただフレームワークを使ってたらコントローラはControllerから継承みたいなのはどうしてもあるが

**デフォルトの名無しさん** · 2022/04/30(土) 03:18:56.57

>>397
そこは移譲ではダメなの？

**デフォルトの名無しさん** · 2022/04/30(土) 05:30:17.12

typescriptは不要だな。jscript .netといっしょで空虚だ。

**デフォルトの名無しさん** · 2022/04/30(土) 08:27:54.46

マイクロソフト、JavaScriptに型宣言を追加しつつトランスパイラ不要の「Types as Comments」をJavaScript仕様策定会議のTC39に提案へ
https://www.publickey1.jp/blog/22/javascripttypes_as_commentsjavascripttc39.html

**デフォルトの名無しさん** · 2022/04/30(土) 11:29:38.19

継承自体は悪くなくて設計が悪い
実際継承使わないパターンが多くなったのでそれもどうでもいい

クラスに当たるものに委譲で継承的なことをすると状態が問題になる
そしたら状態を持つのが悪いと言うまた不思議な話になる

そしてどんどん学習時間取られてみんな疲弊していく

**デフォルトの名無しさん** · 2022/04/30(土) 11:37:07.51

委譲元のクラスが単体では問題なく動くのに組み合わせるとテストを通らない

よく見ると以上元のクラスの内部状態が必要になってるけど公開されていない
完全な設計ミス

interfaceに必要な要素を追加…などできずデフォルト実装を追加
こうしてゴミが出来上がる

**デフォルトの名無しさん** · 2022/05/01(日) 13:19:33.60

継承はそのオブジェクトの内に閉じた処理、オブジェクトの外の処理でもリスコフ置換原則が成立する範囲ではスマートでいいと思うよ
ただ現実的な話、ビジネスルール自体がそうなってないケースが多い
オブジェクトの外の処理は多くの場合、処理対象の子クラスの型で分岐を求められる
これにオブジェクト指向で対処しようとすると、めんどくさいデザインパターンの洪水に呑まれる

オブジェクトの内側のことは継承でエレガントに実現しておｋ（嫌いなら使わなくてもおｋ）
外側のことは地道にpattern matchingで泥臭く頑張る
これでいいと思うね

**デフォルトの名無しさん** · 2022/05/01(日) 14:26:43.52

キチガイ隔離すれの本領発揮

**デフォルトの名無しさん** · 2022/05/01(日) 15:30:58.63

RustもJuliaやGoみたいに廃れて消えていく気がしている。
https://qiita.com/AKKYM/items/78c04840bc72d9db834d

**デフォルトの名無しさん** · 2022/05/01(日) 15:37:27.28

ポエムすぎ。

**デフォルトの名無しさん** · 2022/05/01(日) 16:13:59.61

このRustと同じ分類となる、更に便利な言語が登場しないと、Rustを置き換えることが出来ないだろう

＞プログラミング言語は以下の3つに分類される
＞ CとC++　←『省メモリ高速』だが、「メモリ解放でミスると危険」
＞ GC言語　←『省メモリ高速』ではないが、「メモリ解放は自動で気にしなくていい」
＞ Rust　←『省メモリ高速』だが、「メモリ解放は自動で気にしなくていい」

**デフォルトの名無しさん** · 2022/05/01(日) 16:14:52.25

>>405
妄想でつか？

**デフォルトの名無しさん** · 2022/05/01(日) 21:23:49.61

JuliaはFORTRANを駆逐できましたか？

**デフォルトの名無しさん** · 2022/05/01(日) 22:23:58.30

https://mun-lang.org/
Mun触ったことのある人いる？
ぱっと見GCつきのrustみたいに見える

**デフォルトの名無しさん** · 2022/05/01(日) 23:42:24.67

>>410
文法や基本型はRustと同じっぽいね
ドキュメントを見る限りでは非常に小さいサブセットで開発途上なのかよくわからない

**デフォルトの名無しさん** · 2022/05/02(月) 12:37:31.52

>>407
その分類、そもそもニーズが大きくない気がするし、
このまま競合は現れずに行きそうだよね。

**デフォルトの名無しさん** · 2022/05/02(月) 13:23:34.89

>>410

Dlang: C++風のGC言語
Crystal: Ruby風のGC言語
nim: Python風のGC言語
Vlang: Go風のGC言語
Mun: Rust風のGC言語 ← New!

こういうこと？

**デフォルトの名無しさん** · 2022/05/02(月) 13:56:24.42

VlangはGC無かったと思った

**デフォルトの名無しさん** · 2022/05/02(月) 14:17:19.74

>>414
ほんとだ、ありがとう

**デフォルトの名無しさん** · 2022/05/02(月) 16:08:02.28

>>412
重視されているからこそ
C/C++からRustへの移行(安全化)だけでなく
各種GC言語からRustへの移行(高速化)が起きている現実

**デフォルトの名無しさん** · 2022/05/02(月) 16:39:23.58

>>416
ないわ～
pythonからRustってありえないよ

**デフォルトの名無しさん** · 2022/05/02(月) 17:38:01.22

NumPy, SciPyのライブラリの実装FORTRANをCにベタ移植して更にC++でラップしたような物ばかりだったけどRsutへの移行は順調に進んでいますか？ｗ

**デフォルトの名無しさん** · 2022/05/02(月) 18:06:45.99

それらPythonの使い方は単なる皮言語だからな
次世代言語スレで皮言語を持ち出す時点で頭おかしい

**デフォルトの名無しさん** · 2022/05/02(月) 18:19:24.75

>>418
どの分野でもどの言語でも同じだけど
他の言語に移行するのは新たな物(仕組み・システム)を作る時だよ
そのまま移植は非常にレアケース
例えば古すぎるたり性能面で難があるけどアルゴリズムだけだから再設計せずそのまま他言語へ移植など

**デフォルトの名無しさん** · 2022/05/02(月) 18:33:01.46

>>416
GCあり言語では、データ構造は気にしても、
メモリ操作を意識している人は、少数じゃない？
だから置き換えは、結構ハードル高いと思うけれど。

>>417
Pythonは、グルー言語でもあるから、
単純な置き換えは、そうそう進まなさそうだよね。

**デフォルトの名無しさん** · 2022/05/02(月) 18:40:21.71

>>421
メモリ操作とは具体的になあに？
めったにない特殊なケースは除くとしてハードルが高いことなんて無いんじゃないかしら

**デフォルトの名無しさん** · 2022/05/02(月) 18:48:20.40

>>422
低レイヤー言語だとメモリ読む前にキャッシュしたりアライメント揃えたりするでしょ

**デフォルトの名無しさん** · 2022/05/02(月) 18:52:18.84

>>423
何それ？
よほど特殊なことをしない限りそんなコードを書くことはないよ
C言語でもアライメント気にせずに変数に値が入るし変数そのものがキャッシュだし

**デフォルトの名無しさん** · 2022/05/02(月) 18:55:15.58

>>424
ｗ

**デフォルトの名無しさん** · 2022/05/02(月) 19:01:36.90

>>424
他人のこさえたライブラリと構造体を受渡するときなんかは意識せざるを得んよな。
コレはレアケース？

**デフォルトの名無しさん** · 2022/05/02(月) 19:06:45.80

>>426
それはFFIと言って低レイヤー言語だけの問題ではない
PythonでもJavaScriptでもある

元の話題
>>423
> 低レイヤー言語だとメモリ読む前にキャッシュしたりアライメント揃えたりするでしょ

**デフォルトの名無しさん** · 2022/05/02(月) 19:16:29.24

例えばSIMD命令使うのが "よほど特殊なこと" に該当するかどうかという話？

**デフォルトの名無しさん** · 2022/05/02(月) 19:29:07.60

この流れでFFIもSIMDも関係ないと思います
GCあり言語の普通のプログラムをGCなし言語へ置き換える話をしています

>>421
> GCあり言語では、データ構造は気にしても、
> メモリ操作を意識している人は、少数じゃない？
> だから置き換えは、結構ハードル高いと思うけれど。

>>422
> メモリ操作とは具体的になあに？
> めったにない特殊なケースは除くとしてハードルが高いことなんて無いんじゃないかしら

**デフォルトの名無しさん** · 2022/05/02(月) 19:31:38.61

メモリ操作って言い方が曖昧なら、スタックとヒープを意識するかしないかって言い方ならどう？

GCあり言語でスタックとヒープを意識するような事ってあまり無いと思うんどけど。

**デフォルトの名無しさん** · 2022/05/02(月) 19:44:24.10

>>430
GCなし言語でどうしてもスタックとヒープを意識しないとプログラミングできないことってある？？

**デフォルトの名無しさん** · 2022/05/02(月) 20:03:38.83

>>431
ありなしで言ったらあるでしょ
性能意識するコードとか

**デフォルトの名無しさん** · 2022/05/02(月) 20:09:21.38

>>432
それは性能をよっぽど気にする特殊な場合だけでしかもその中の一部のコードだけやろ
それ以外は関係ないやん

**デフォルトの名無しさん** · 2022/05/02(月) 20:41:15.68

言うほど低レイヤーコード書いてるやつはここにはおらん。
だから話がおかしな方向に行く。

**デフォルトの名無しさん** · 2022/05/02(月) 20:50:55.80

>>434
GCあり言語のコードをGCなし言語にする話だから
低レイヤーコードなんて一切関係ない

**デフォルトの名無しさん** · 2022/05/02(月) 22:55:54.22

スタックは普通に意識するでしょう、末尾最適化されてないナンチャッテ意識高い系の再帰呼び出しとか直すけど・・・
GCアリ言語でも無しでも、スタックサイズは普通に意識する。
ヒープは言うほどRustは組み込みに使わないし、トヨタが使うというてもそれはメモリコンパクションのあるようなOSが載ってる場合だから
本当の組み込みじゃないし、でもアロケーターが64byte-4kでもVec::with_capacity(size);とか普通にIO系の処理では意識するでしょ

**デフォルトの名無しさん** · 2022/05/02(月) 23:14:26.49

>>436
Rustはヒープ無しでも動作するからヒープを意識しなくていいのはその通りだが
ヒープが有る場合でもVec::with_capacity(size);等は動作最適化を手動でする時のみ必要であって、
プログラマーは何もしなくても全自動でcapacity拡張してくれるから意識しなくてもよい

**デフォルトの名無しさん** · 2022/05/02(月) 23:25:13.41

>>433
そもそもの質問が「ヒープ意識しないとプログラムできないことってある？」だから、反論になってないよ
頻度は問題にしてなくて有無の話だから

**デフォルトの名無しさん** · 2022/05/02(月) 23:32:26.49

>>438
それは君の方がおかしい
今回のこの文脈ではそこは意識する必要がない

＞GCあり言語の普通のプログラムをGCなし言語へ置き換える話をしています

ベクタの使用領域の大きさはどちらの言語でも自動的に拡張してくれるのに任せればよいから意識しなくてよい

**デフォルトの名無しさん** · 2022/05/02(月) 23:45:32.15

GCありの言語で循環参照するようなデータの持ち方をしまくってるようなコードだったりすると、
そのまま移植できないだろうし面倒かな？
場合によってはRustでいうArenaみたいなのまで持ち出して再設計しないといけなそう

移植なんてしたことないしあくまでも想像だけど

**デフォルトの名無しさん** · 2022/05/03(火) 00:46:48.18

>>437
”Rustはヒープ無しでも動作する”、不正確でダウトといっても良い。”Box<T>を使わない場合、Rustは最小のメモリで動作する”
一般的に最小のメモリとはプログラムをメインメモリにロードした領域であり、それ以外にも、ヒープ解析すればRustの場合は、
Config structなどが多数メモリにロードされていることが分かります。後半の文は意味不明。

**デフォルトの名無しさん** · 2022/05/03(火) 00:49:19.56

GCあり言語って一絡げにできるほど似通ってるんだっけ

**デフォルトの名無しさん** · 2022/05/03(火) 01:10:00.15

>>441
知識が浅すぎる
Rustはヒープ無しでも動作する、で正しい
そのためRustの標準コアライブラリcore::はヒープ無しで動作するように作られている
std::のうちcore::以外の部分はヒープを用いており明確に両者は区別されている

>> ”Box<T>を使わない場合、Rustは最小のメモリで動作する”

意味不明
Box<T>はヒープを使う型の一つに過ぎない
それ以降の記述は全く意味不明

**デフォルトの名無しさん** · 2022/05/03(火) 02:44:39.08

まじきち隔離所、顔真っ赤になってｗｗ

**デフォルトの名無しさん** · 2022/05/03(火) 02:45:30.07

まーたRust信者がスレハイジャックしてる

**デフォルトの名無しさん** · 2022/05/03(火) 02:51:30.24

ベアメタル等OSなしでも動作しないといけないため
Rustはヒープを前提とせずに動くよう設計されている

**デフォルトの名無しさん** · 2022/05/03(火) 04:29:19.13

>>444
本当はスレ民のことが気になって仕方ないだろ？
隠しても無駄ｗｗｗ

**デフォルトの名無しさん** · 2022/05/03(火) 06:00:49.14

なぜせっかくRustで作られたブラウザを除外するかね？

「NHKプラス」、「Firefox」での視聴が不可能に　5月23日から推奨ブラウザを「Microsoft Edge」「Google Chrome」「Safari」に限定 [孤高の旅人★]
https://asahi.5ch.net/test/read.cgi/newsplus/1651490664/

**デフォルトの名無しさん** · 2022/05/03(火) 06:33:11.84

>>448
そのどれかのブラウザがインストールされてない端末って何がある？
Linuxと組み込みくらい？

**デフォルトの名無しさん** · 2022/05/03(火) 08:05:32.71

「Firefoxはバグ

**デフォルトの名無しさん** · 2022/05/03(火) 08:06:08.35

訂正：firefoxはバグが多いの？

**デフォルトの名無しさん** · 2022/05/03(火) 10:17:41.36

Chromeより軽くてFirefoxオススメ

**デフォルトの名無しさん** · 2022/05/03(火) 11:37:27.15

>>448
もし本当に視聴不可となったら技術力が無さすぎる
昔ならともかく今の時代にブラウザ依存なコードを書くのはダメなプログラマーの典型
視聴不可ではなく動作確認するブラウザの数を絞るなら理解できる

**デフォルトの名無しさん** · 2022/05/03(火) 11:57:44.21

> 「Firefox」など、上記3ブラウザ以外での動作はもともと確認しておらず、推奨ブラウザには加えていなかったという。
> 「5月23日以降に予定している設備更新に伴い、Firefoxでは動画が完全に再生できなくなる

どういう設備更新なんだろうな・・・
WebKit系じゃないと使えない仕組みがあるのか

**デフォルトの名無しさん** · 2022/05/03(火) 12:01:19.67

今どきはブラウザ依存な書き方する方が面倒だろう。普通にテストしてないだけでは。

**デフォルトの名無しさん** · 2022/05/03(火) 12:02:22.58

>>454
あ、本当に動かなくなるのか。

**デフォルトの名無しさん** · 2022/05/03(火) 12:10:09.97

chromiumにしか実装されていない独自拡張機能に依存したAPIに手を出したとか？？
でもSafariで動くなら違うか
Firefoxでだけ動かないコードなんて可能なのか？？

**デフォルトの名無しさん** · 2022/05/03(火) 12:29:47.29

Chromiumは現代のIE6ですから

**デフォルトの名無しさん** · 2022/05/03(火) 12:49:05.47

そういえばchromeにrust使う話ってどうなったんだ？

**デフォルトの名無しさん** · 2022/05/03(火) 19:12:46.20

>>459
ああ、ごめん。さぼってたわｗ

**デフォルトの名無しさん** · 2022/05/03(火) 19:19:05.53

たしかFirefoxもまだ全部はRustに治せてないんだろ

**デフォルトの名無しさん** · 2022/05/03(火) 19:33:27.34

>>461
君は何らかの大きなシステム開発に関わったことがないのかね？
どんな言語と言語の場合でも一気にやることは不可能かつムダ
新規部分や改修部分に絞って手を付けていく

**デフォルトの名無しさん** · 2022/05/03(火) 20:16:20.57

>>462
なるほど
だからよそと違ってバグまみれとか言われるんやなｗ

**デフォルトの名無しさん** · 2022/05/03(火) 20:22:09.94

Chromeの方がセキュリティバグ多いよな
頻繁にバージョンアップしろと言ってくる

**デフォルトの名無しさん** · 2022/05/04(水) 19:26:52.80

>>464
JVN iPedia - 脆弱性対策情報データベース。https://jvndb.jvn.jp/
期間指定なし
・safari 884件
・edge 1054件
・firefox 1989件
・chrome 3464件
期間指定2018/01から
・safari 48件
・edge 391件
・firefox 492件
・chrome 937件

とはいえ、Chromeのほうがローリングリリース・ローリングアップデートの期間が短い（現在は４週間)2021/3頃から6週間から変更された。
以前はFirefoxはローリングリリースを採用していないかった。またChormeの使用者がFirefoxより10倍なので脆弱性も発見されやすい。
何かと問題なSafariの脆弱性がこれだけのはずが無く、脆弱性報告数＝危険なブラウザとははっきり言えない

**デフォルトの名無しさん** · 2022/05/04(水) 19:52:07.53

途中まで数字で語ってるのに最後だけ願望になっててワロタ

**デフォルトの名無しさん** · 2022/05/04(水) 21:47:24.52

go-tour-ko.appspot
.com

**デフォルトの名無しさん** · 2022/05/05(木) 01:24:23.06

>>466
Appleに報告した脆弱性、数カ月放置の後に「現在、調査中です」の返答
https://appleinsider.com/articles/21/09/27/apple-still-investigating-unpatched-security-flaws-in-ios-15

**デフォルトの名無しさん** · 2022/05/05(木) 09:45:52.65

木を見て森を見ずという言葉を考えた昔の人はいいセンスしてる

**デフォルトの名無しさん** · 2022/05/05(木) 13:55:59.94

Appleって莫大な利益を何に消費しているのだろうね

**デフォルトの名無しさん** · 2022/05/05(木) 17:00:01.71

>>448
そもそもNHKは見ないのでどうでも良い。

**デフォルトの名無しさん** · 2022/05/05(木) 19:17:07.87

>>470
そんなこと気にして何になるの？

**デフォルトの名無しさん** · 2022/05/05(木) 19:26:31.90

>>472
ウィグル弾圧に使われてる可能性が高い。