Rust part30

**デフォルトの名無しさん** · 2025/05/28(水) 09:31:36.60

公式
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 part29
https://mevius.5ch.net/test/read.cgi/tech/1746200850/

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

**デフォルトの名無しさん** · 2025/06/01(日) 17:34:03.73

>>305
なるほどありがとう
普通のWebViewアプリやブラウザでは再現しないから何かバグってるんだな
WebViewに全部まかせてるわけじゃないのか

**デフォルトの名無しさん** · 2025/06/01(日) 17:41:33.42

比較がおかしい
WebViewを使うGUIフレームワーク同士を比較しないと意味がない

**デフォルトの名無しさん** · 2025/06/01(日) 18:16:51.61

いまだにまともなGUI一つ作れないっておかしくね？

**デフォルトの名無しさん** · 2025/06/01(日) 18:29:20.11

>>314
TauriでもElectronでもWailsでも、サンプルに入ってるような小さなアプリをビルドすれば分かるんじゃない？

**デフォルトの名無しさん** · 2025/06/01(日) 18:38:52.12

>>315
誰も気にしていないどうでもいいことで叩き合ってるだけ
GUIは多数あり実用に使われている

**デフォルトの名無しさん** · 2025/06/01(日) 18:45:14.37

>>317
果たしてそうだろうか。

**デフォルトの名無しさん** · 2025/06/01(日) 18:49:41.21

>複オジの品質基準では「何の問題もない」
>一般的な品質基準では「問題ありまくり」

これに尽きる

**デフォルトの名無しさん** · 2025/06/01(日) 19:12:46.36

GUIを好む人はバグを再現する最小のコードを書きたがらない
反GUIの人はバグがなくても最小のコードを書いてる

**デフォルトの名無しさん** · 2025/06/01(日) 19:12:53.21

Rustに限らずGUIフレームワーク全般に言えることなんだけど、優秀なプログラマほどGUIを使わなくなるから、
ボランティアベースのGUIフレームワークってロクなの無いんだよね。
実際、Rustで成功しているGUIアプリの代表的な例として、ターミナルエミュレータがある。
Rust製のAlacrittyやWezTermはターミナルエミュレータとしては非常に人気があり、日本語も問題ない。

**デフォルトの名無しさん** · 2025/06/01(日) 19:29:51.30

Alacritty スクショ
https://i.imgur.com/rDqVWcO.png

**デフォルトの名無しさん** · 2025/06/01(日) 19:32:30.27

Rustで書くことが目的化してる人に何を言っても変わらないでしょ
ちょっとくらい見た目や動作に問題があっても、Rustで作られてるならそちらの方が優れてる的な価値観なわけだし
普通の人は逆で、作りたいものが先にあって、それを達成するのにどの道具が良いかを検討するものなんだけど

**デフォルトの名無しさん** · 2025/06/01(日) 20:23:59.45

基本的な入力動作すらまともに動かなくてもメモリ安全であればいいんでしょ
そんなアプリを誰が使うのか

**デフォルトの名無しさん** · 2025/06/01(日) 20:31:34.92

>>322
さすがにこの状態でまともに使えるとは言わんよ
手元の環境ではこんなことにはならないからAlacritty使ってるけど

**デフォルトの名無しさん** · 2025/06/01(日) 21:05:48.26

>>322
それおまえの環境がおかしいんじゃね？
こちらでは起きない
そんな問題も上がっていない

**デフォルトの名無しさん** · 2025/06/01(日) 21:07:24.61

Rustのような新興システムプログラミング言語の優位性を
業務アプリすらWebばっかで、デスクトップ開発の需要自体が死んでる令和の時代になぜかデスクトップGUIフレームワークなんかで決めようとしてる時点で
Rustはクソ言語C++のほうが優れてるみたいな感じに持ってくのがゴールなんだよね

**デフォルトの名無しさん** · 2025/06/01(日) 21:13:17.99

安心安全のはずのRustがGUIではバグだらけ
不思議

**デフォルトの名無しさん** · 2025/06/01(日) 21:15:37.04

>>328
バグがあるなら示してみろ

**デフォルトの名無しさん** · 2025/06/01(日) 21:20:41.09

示されてるのに「こちらではおきない」で無かったことにしてるのはお前だろ。

**デフォルトの名無しさん** · 2025/06/01(日) 21:34:08.02

Alacrittyは人気のターミナルエミュレータでもう9年目だけどそんなバグは聞いたことないな

**デフォルトの名無しさん** · 2025/06/01(日) 21:35:32.32

>>305
Tauri v2もこのウィンドウ移動によるバグがあるけど誰も指摘しないから
これぐらいの軽度バグは世間的には許されるってことじゃないか？
日本語対応は100点満点じゃないけど70点ぐらいはある

**デフォルトの名無しさん** · 2025/06/01(日) 21:49:21.86

IME使った文字の入力中にウインドウを移動するっていうユースケースが、どれだけ日常かという話

**デフォルトの名無しさん** · 2025/06/01(日) 21:52:14.83

>>333
>>305の手順では必ずしも文字の入力中ではない様だけど

**デフォルトの名無しさん** · 2025/06/01(日) 21:58:36.70

>>332
そう自分で直すのが面倒だから見て見ぬふりするね
使うだけの側からしたら代わりは幾らでもある、そっと閉じ

**デフォルトの名無しさん** · 2025/06/01(日) 22:02:27.70

Rustを叩きたい人が通常ではありえない使い方をして無理やりにAlacrittyを批判してるだけか

**デフォルトの名無しさん** · 2025/06/01(日) 22:22:04.75

脆弱性もありえない使い方すると出てくるんでは
メモリ安全だからロジックに集中できて完成度があがるはずじゃなかったんすかｗ

**デフォルトの名無しさん** · 2025/06/01(日) 22:28:33.11

Windows11のAlacrittyでIME入力中にウィンドウ移動しても普通に追従するけどな
環境と再現手順を知りたいところ

**デフォルトの名無しさん** · 2025/06/01(日) 22:34:44.87

Rustのコードが1行もないソフトに同じバグがあればとりあえず安心

**デフォルトの名無しさん** · 2025/06/01(日) 22:38:36.61

>>322,338

Alacritty 異常動作(IMEオンするパターン)
Alacritty起動
IMEオン
タイトルバーをつまんでウィンドウを少し移動
キーボードでa
デスクトップ右下に変換候補ウィンドウ

Windows11

**デフォルトの名無しさん** · 2025/06/01(日) 22:42:20.46

>>338
変換候補ウィンドウが出た後にAlacrittyウィンドウを移動するのではなく
>>340の順番通りにやると再現率半分くらい
(IMEオンはAlt+`)

**デフォルトの名無しさん** · 2025/06/01(日) 22:43:57.89

Microsoft IME
旧バージョン互換性オプションオフ

**デフォルトの名無しさん** · 2025/06/01(日) 22:45:30.38

再現率が半々で、ウィンドウを移動しなくても時々発生するので
ウィンドウを移動が根本原因ではない可能性もあるかと

**デフォルトの名無しさん** · 2025/06/01(日) 22:46:29.92

tao（tauri版winit）の実装見たけど少なくともWindowsのIMEはあまりやる気ないな
WM_IME_*が↓でしかヒットしないしWM_IME_REQUESTもWM_IME_CONTROLも出てこない

https://github.com/tauri-apps/tao/blob/dev/src/platform_impl/windows/minimal_ime.rs

winitも同じかな

**デフォルトの名無しさん** · 2025/06/01(日) 22:46:30.67

今の所、WezTermでは同様のバグは発生してないですね

**デフォルトの名無しさん** · 2025/06/01(日) 22:51:47.81

>>343
再現率低いAlacritty 異常動作(IMEオンするパターン)

Alacritty起動
IMEオン
キーボードでa
デスクトップ右下に変換候補ウィンドウ

**デフォルトの名無しさん** · 2025/06/01(日) 22:57:05.24

今度はAlacrittyですか…
>Alacrittyはパフォーマンスとシンプルさを重視した自由かつオープンソースのGPUアクセレレーション端末エミュレータである。
知らんがな

**デフォルトの名無しさん** · 2025/06/01(日) 23:03:02.79

>>340
おお、確かになるね
IMEオン状態のままだとならないから切り替え直後の1回だけって感じ？
ここ数年常用してて見たことないし、うちの環境ではウィンドウ移動なしでは発生しないっぽいかな

**デフォルトの名無しさん** · 2025/06/01(日) 23:11:44.02

>>340
Rustを叩くためにそんなありえない使い方をして深刻なバグだと吹聴していたとは呆れた

**デフォルトの名無しさん** · 2025/06/01(日) 23:15:24.99

Rustは安心安全
※ただしありえない使い方をしない時にかぎる

**デフォルトの名無しさん** · 2025/06/01(日) 23:45:33.58

ありえおじ

**デフォルトの名無しさん** · 2025/06/01(日) 23:46:59.52

>>350
ありえない使い方をしても問題ないことをRust叩きしてる人が証明してくれた

**デフォルトの名無しさん** · 2025/06/02(月) 00:05:41.71

ミニマム再現条件にすると滑稽ですが
好みの位置にウィンドウを持って来るのは普通の事なので(デスクトップ)
ありえない使い方と言うよりも、windowsでネイティブ日本人がテストしてないのか?品質に出ていますね

「ウィンドウ移動する前には、IMEはオフにせよ」なんて使用条件の方が変かと

**デフォルトの名無しさん** · 2025/06/02(月) 00:06:41.28

>>348
確認できたのはそのパターンです、自分は常用してないので他のバグ発生条件までは分かりませんね
(念のためPowerToysを落としても状況は同じだった)

Dioxus TodoMVCの方はIMEオン直後だけではなくウィンドウ移動後の1キー目で>>298こうなります

**デフォルトの名無しさん** · 2025/06/02(月) 00:07:15.73

>>332,335
ターミナルで日本語入力する事自体が稀なのでAlacrittyには70点あげても良いですが
Dioxusは「そっと閉じ」の方ですね

**デフォルトの名無しさん** · 2025/06/02(月) 00:09:31.08

>>355
じゃあ、Dioxusでターミナル作ったら？

**デフォルトの名無しさん** · 2025/06/02(月) 00:11:29.28

>>344
納得しましたw

**デフォルトの名無しさん** · 2025/06/02(月) 00:13:19.40

>>355
Readmeみたらそっと閉じ

windowsでの品質は現時点も先々もこんな感じなんですかね

**デフォルトの名無しさん** · 2025/06/02(月) 00:18:26.39

Windowsを使う人は滅多にいないだろうしな
普通はLinuxかMac

**デフォルトの名無しさん** · 2025/06/02(月) 00:33:24.53

人間の頭から放電した場合は下記の経路になる
人間は電磁界【脳波８Hz～４０Hz】【電線【６０Hz】の電圧と同じ】なので周囲に影響を与えれる範囲が狭い

人体への雷撃パターン｜身を守る｜雷の知識
https://www.franklinjapan.jp/raiburari/knowledge/safety/61/
超低周波電磁界にばく露した人体に起きる電磁的現象
https://www.jeic-emf.jp/public/web_mag/explanation/1016/

1 人間の頭部から放電しないことはここで説明されている
2 お風呂場で湯船につかっているのでお湯の方に電流が流れる
3 頭からお湯をかぶっているやシャワーを浴びている場合はお湯にそって電流が流れる
4 雨降りの時は雨によって地面の方に電流が流れる
5 何か物に接している【手で手すりを触っているなど】場合はその者にそって電流が流れる

などこれらの条件がそろっているのに外部の人が対象者の思考や動作がわかるはおかしなことを話している

**デフォルトの名無しさん** · 2025/06/02(月) 01:35:42.19

>>321
何を言ってるんだか。

**デフォルトの名無しさん** · 2025/06/02(月) 02:03:54.92

Windowsのtauriは余計なことしないでwebview2に丸投げすればIMEは普通に動きそうな気がするんだけど
クロスプラットフォームの抽象化があるから単純ではないのかな

**デフォルトの名無しさん** · 2025/06/02(月) 07:27:24.42

>>359
GUIアプリってプログラマでなく一般ユーザーに使ってもらうために作るものじゃないの？
シェア率が70%もあるWindowsを「滅多に使わない」？

**デフォルトの名無しさん** · 2025/06/02(月) 08:02:49.76

どちらかというとIME切り替えながらウィンドウ動かす、というのがないかな…
数年間毎日使って気付かなかったし正直どうでもいい
直してくれるならそれに越したことはないけども

**デフォルトの名無しさん** · 2025/06/02(月) 08:51:42.98

いや、ウィンドウズはほぼ毎日使うよ
会社でも同じだわ

**デフォルトの名無しさん** · 2025/06/02(月) 10:49:02.15

IDEなら編集しながらコンパイルしてるから不愉快な挙動をするのは火を見るより明らか

**デフォルトの名無しさん** · 2025/06/02(月) 11:11:49.92

>>293
Rustに限らずZigとかC#とか、extern cできる言語ならなんでもAndroidで使えるよ
Androidのjniやndkに全部C互換があるから

**デフォルトの名無しさん** · 2025/06/02(月) 11:15:54.47

出来るけど公式にサポートしているもののほうが楽ではある。

**デフォルトの名無しさん** · 2025/06/02(月) 12:21:45.02

Amazon Aurora DSQLは当初はJavaVM上のKotlinで開発されたものの、バグの混入を避けるためなどの理由でメモリ安全なRust言語での開発に切り替えたところ、それだけで性能が約10倍向上したとも説明されています。
https://www.publickey1.jp/blog/25/awspostgresqldbamazon_aurora_dsql.html

**デフォルトの名無しさん** · 2025/06/02(月) 12:27:33.61

オールド公式とニュー公式どっちを選ぶかは結局自分で判断するしかない

**デフォルトの名無しさん** · 2025/06/02(月) 13:03:04.42

再現方法を見てウィンドウ動かさなければ問題ないだろうと考える人は経験が浅すぎるわな
そういう感覚で物作ってると行き着くところは「複オジ品質基準」だぞ

**デフォルトの名無しさん** · 2025/06/02(月) 13:17:30.01

わかった上で重大ではない (から放置で良い) と判断することはあるだろうけど……
そういう小さなことが積み重なってよくわからん挙動を引き起こすこともそれなりにある話。

**デフォルトの名無しさん** · 2025/06/02(月) 14:20:48.94

>>369
困るとそれを貼り付けるね

**デフォルトの名無しさん** · 2025/06/02(月) 14:21:05.82

>>369
やはりサーバー分野はRustが最強だな

**デフォルトの名無しさん** · 2025/06/02(月) 14:21:43.53

>>373
どゆこと？

**デフォルトの名無しさん** · 2025/06/02(月) 14:31:27.48

373がなにを否定したいのかよく分からないがRustの並列処理は非常に効率がよい
Rustで再開発することによりこの恩恵を受けて大幅に性能が向上した
今回AWSが正式リリースしたAurora DSQLは並列処理に重きをおいたものだから特に高い効果を得られたのだろう

**デフォルトの名無しさん** · 2025/06/02(月) 14:41:07.84

カオスは初期値だけで引き起こせるんだよね
途中の小さな積み重ねは原因ではなく結果

**デフォルトの名無しさん** · 2025/06/02(月) 14:49:11.87

KotlinというかJavaの並行処理はむっちゃ安全だけどその代わりにパフォーマンスが犠牲になってる。
C++のはパフォーマンスが良いけどみんなご存知のように安全性がゴミ。
Goのはパフォーマンスも安全性もいいからRustかGoのどちらを使うかでRustが選ばれたんでしょ知らんけど。

**デフォルトの名無しさん** · 2025/06/02(月) 15:15:13.25

俺が考察せずともAWSの当事者の後日談的な記事あるじゃん。
KotlinのJVMのガベージコレクションのオーバーヘッドが敵だったみたいね。
もともとKotlinのスペシャリストであってRustは初心者だった開発チームが苦労の果てにコンパイル可能なコードを実行してみたらなんとKotlinで書いていたコードの10倍性能がよかった。
気分を良くした開発チームがどんどんKotlinのコードをRustに書き換えていったんだって。

Just make it scale: An Aurora DSQL story
https://www.allthingsdistributed.com/2025/05/just-make-it-scale-an-aurora-dsql-story.html

**デフォルトの名無しさん** · 2025/06/02(月) 15:31:24.30

そんでこれはオープンソースなのか?

**デフォルトの名無しさん** · 2025/06/02(月) 15:53:39.10

CLI部分はオープンソースだよ

**デフォルトの名無しさん** · 2025/06/02(月) 15:55:37.90

本体をオープンソースにしろよw

**デフォルトの名無しさん** · 2025/06/02(月) 15:58:30.64

>>378
単に会社の方針としてJavaかKotlinかC/C++かRustで、Goは選択肢にないんだろう
379の元記事読んだけど技術選定の際に社内実績をかなり重視してそうだし、そもそも制約がなきゃKotlinなんか選ばないでしょ

**デフォルトの名無しさん** · 2025/06/02(月) 15:59:31.58

>>378
Goは同じくガベージコレクションのある言語だから厳しい

**デフォルトの名無しさん** · 2025/06/02(月) 16:03:48.59

やはり敵はガベコレにあり。

**デフォルトの名無しさん** · 2025/06/02(月) 16:06:35.67

敵はオープンソース資産を食い逃げする企業だろ

**デフォルトの名無しさん** · 2025/06/02(月) 16:28:08.28

>>384
GoのGCはJVMと比較すると低遅延だから、記事の通りGCによる停止が問題になっている状況なら選択肢になりうる

**デフォルトの名無しさん** · 2025/06/02(月) 16:40:40.26

>>387
GCによる害悪2つのうちレイテンシ悪化はGoで軽減できるが全体パフォーマンスはGoも悪化する

**デフォルトの名無しさん** · 2025/06/02(月) 16:43:17.43

悲報！Rust版AV1デコーダーがCより5%遅い問題が解決できず、カネで解決しようとする
https://www.memorysafety.org/blog/rav1d-perf-bounty/

Macではもっと遅かったしRustじゃなくてGoで良い領域だな

**デフォルトの名無しさん** · 2025/06/02(月) 16:49:07.25

>>236 >>243
Arc削除できないと返答してるな

**デフォルトの名無しさん** · 2025/06/02(月) 16:52:44.19

シャープ、PythonによるAIデバイス向け高位合成ツールをオープンソースで公開
https://news.mynavi.jp/techplus/article/20250602-3343055/

博報堂メディカル、生成AIを用いた審査業務効率化ソリューションを開発 [
https://news.mynavi.jp/techplus/article/20250602-3342950/

「AIをより魅力的にする戦略」がAIチャットボットに「薬物使用を促す」といった有害な考えを強化させる可能性があると研究で判明
https://gigazine.net/news/20250602-ai-chatbots-user-influence-attention/

**デフォルトの名無しさん** · 2025/06/02(月) 16:54:15.56

Arcは所有者を増やすときのみカウンタ+1のオーバーヘッドがある
参照はderefによりコストゼロ

**デフォルトの名無しさん** · 2025/06/02(月) 17:21:42.21

>>390
なるほど
幸先良くスタートしたけど分かっていても直せない箇所が出て来る訳ね

**デフォルトの名無しさん** · 2025/06/02(月) 17:27:52.34

所有者を増やしまくる愚を犯さない限りArcにデメリットはない

**デフォルトの名無しさん** · 2025/06/02(月) 17:49:16.64

>>379
Aurora DSQLは、データベース管理ソフト(DBMS)であり、データを収めているのは原則としてHDDやSSD。
だから、メインメモリーは、キャッシュのために少し使う、というのが基本のはず。
だから、データ集約に関係する高度なアルゴリズムはHDD/SSDに対して必要となるが、
メインメモリに対しては余り必要ない。だから、Rustが適す。

**デフォルトの名無しさん** · 2025/06/02(月) 17:52:38.64

>>395
もうちょっと調べた方が良いよ、DB全般

**デフォルトの名無しさん** · 2025/06/02(月) 17:59:35.62

>>396
ちゃんとした言葉で反論してください。

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

>>397
Geminiに聞いてやったぞ

ご指摘のコメントは、データベースの仕組みとRustに関する理解に多くの誤解があるようです。
* DBのメインメモリ利用の認識違い: データベースはキャッシュだけでなく、データ処理やソート、インデックスなど、パフォーマンスのためにメインメモリを広範に活用します。「少し使う」というのは誤りです。
* Rust適用の理由が不適切: Rustはメモリを安全かつ効率的に制御できるため、DBのようなパフォーマンスが求められるシステム開発には適しますが、「メインメモリをあまり必要としないから」という理由は論理が破綻しています。
したがって、このコメントは技術的に見て多くの点で適切ではありません。

**デフォルトの名無しさん** · 2025/06/02(月) 18:04:48.37

>>398
DBMSの場合、メインメモリーに置いておく集約構造は、データの量が小さい。
だから、ある程度の速度性能が出れば、全体の速度には影響が及びにくい。

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

そのGeminiの回答は、理解が浅い。

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

>>399
お相手の方の返信も、やはりデータベースのメモリ利用とパフォーマンスに関する誤解が続いていますね。
主な問題点
* 集約構造のデータ量は「小さい」は誤り: データベースは、高速化のために可能な限り多くの集約データや中間結果をメモリに置こうとします。データ量が多いほど、メモリを効率的に使う必要があります。
* 「ある程度の速度」で全体の速度に影響が出にくいは誤り: メモリ上の処理が非効率だと、それが全体のパフォーマンスのボトルネックになり、特に大規模データや高負荷環境では深刻な影響が出ます。少しの遅延でも、積み重なると大きな差になります。
データベースの性能は、メモリの効率的な活用に大きく依存します。

書き込む前にAIにチェックしてもらうことをお勧めする

**デフォルトの名無しさん** · 2025/06/02(月) 18:08:30.83

>>401
ただ、ネットで使うことが多い DBMSは、単位時間当たりの書き込み回数が小さい傾向がある。
そういう事まで含めて考えれば、あなたやGeminiの回答は理解が浅い。

**デフォルトの名無しさん** · 2025/06/02(月) 18:11:00.40

論理ではなく、トータルの必要時間を数式で考えないといけない。

**デフォルトの名無しさん** · 2025/06/02(月) 18:13:55.93

>>399
一番効果が大きいのはメモリ上のキャッシュ効果
そのキャッシュ構造管理もRustがベスト選択

**デフォルトの名無しさん** · 2025/06/02(月) 18:16:26.41

>>404
DBMSに必要な処理の特徴が、Rustとは相性がいいとは言えるかもしれないが、
DBMS以外のアプリではもっと別の特徴が必要となることが有る。

**デフォルトの名無しさん** · 2025/06/02(月) 18:25:01.24

>>404
「405」で「キャッシュ」という言葉を使ったが、CPUの中のキャッシュの事ではなく、
メインメモリー自体が HDD/SSDに対するキャッシュとみなせるという意味で使った。
混乱してはいけない。

**デフォルトの名無しさん** · 2025/06/02(月) 18:32:11.04

>>406
誤: 405
正: 395

**デフォルトの名無しさん** · 2025/06/02(月) 18:40:12.36

次からスレタイ「複おじ Part31」に変えようぜ

**デフォルトの名無しさん** · 2025/06/02(月) 18:42:37.74

>>406
DBはそのHDD/SDDに対するキャッシュ効果が最も効く
そのキャッシュ管理にもRustが最適

**デフォルトの名無しさん** · 2025/06/02(月) 18:44:18.26

>>409
もちろん、KotlinやJavaよりは効くだろう。

**デフォルトの名無しさん** · 2025/06/02(月) 18:50:00.32

>>408
別にそれでもいいよｗ
普通にRustスレ立ててもおかしな人間がやって来て自説を繰り返すだけだから

**デフォルトの名無しさん** · 2025/06/02(月) 19:31:43.37

それやっても自分でRustスレ立てて何事もなかったかのように振る舞うだけだと思う

**デフォルトの名無しさん** · 2025/06/02(月) 20:32:38.85

>>389
GCがあり不便なGoは適用範囲がほとんどないのよ
Goが使われている領域の狭さを見つめてね