Rust part27

**デフォルトの名無しさん** · 2024/12/02(月) 22:32:50.31

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

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

**デフォルトの名無しさん** · 2025/01/29(水) 23:58:56.14

>>234
219と225は同一人物だぞ

**デフォルトの名無しさん** · 2025/01/30(木) 00:13:31.97

>>232
特定のプラットフォームに依存するコードはなるべく減らしたいという動機は理解できるんだよね？

可能な限り境界に近いところで外部表現と内部表現の変換を行うことがプラットフォーム依存のコードを減らすことに寄与するというのもわかるよね？

あとは外部の表現形式を内部でも維持したとしてもデメリットを上回る十分なメリットがあるかどうか
OsString/OsStrの主たる用途ではそれだけのメリットはないという判断
メリットがある用途ならOsString/OsStr以外を使いましょうということ

**デフォルトの名無しさん** · 2025/01/30(木) 00:26:18.93

str <-> OsStrの話は差異をうまく隠蔽しにくくシグニチャに影響しうるというのがあるけど仮に影響しなくても境界で変換するのが望ましいという判断は変わらなかったはず

**デフォルトの名無しさん** · 2025/01/30(木) 00:39:30.16

https://github.com/rust-lang/rfcs/pull/575
https://github.com/rust-lang/rfcs/blob/master/text/0517-io-os-reform.md#string-handling

**デフォルトの名無しさん** · 2025/01/30(木) 20:50:11.01

>>247
ありがとう、RFCのほう探せばよかったのか

> ## Wide string representation
> Downsides:
> * These conversions have inconsistent performance characteristics between platforms. (Need to allocate on Windows, but not on Unix.)

やっと納得できる理由が出てきた、これはたしかにな…いやでもなあ、直接OsString/OsStrを触るAPIがもっと充実していれば別にString/strとの変換をそこまで気にする必要もないのでは？
一気にString/str相当のAPIを実装するのも手間だし、OsString/OsStrで何かやりたかったらとりあえずString/strと変換してなんとかしてくれ、だからここではプラットフォームごとの差を付けたくない、って方針だったのかね？
とはいえ、考えられる発展としていろいろな文字列型を一般化する抽象化を作れるはずとかちゃんと書いてあるし、まあまあ納得できる経緯説明ではある
ありがとうね

> // and ultimately other functionality typically found on vectors,
> // but CRUCIALLY NOT as_bytes

…とか書いてるけど、今は普通にas_encoded_bytesとして実装しちゃってるし、結局なんだかよく分からんなあ

**デフォルトの名無しさん** · 2025/01/30(木) 23:18:13.05

>>248
>> * These conversions have inconsistent performance characteristics between platforms
こう書かれてるけどパフォーマンスという点では特にDownsideじゃないと思うんだけどね
今の実装でも発生してるし違う環境用のOsStringを1つのプログラムが実行時に混ぜて扱うわけでもないし

問題なのは内部コードにアロケーションタイミングの違いみたいなのが侵食して分岐が増えること
わかりやすい例としてはOsStr::new(“foo”)が&OsStrを返せなくてCow<OsString, OsStr>になるとか

**デフォルトの名無しさん** · 2025/01/30(木) 23:38:58.04

そうだね
だから現状の仕様で正しくて
10年間も問題視されていない
許容できない用途が仮にあるならWindows専用のクレートを作ればいい

**デフォルトの名無しさん** · 2025/01/30(木) 23:54:08.19

as_encoded_bytesの話はこれ
https://github.com/rust-lang/libs-team/issues/306

**デフォルトの名無しさん** · 2025/01/31(金) 02:25:28.04

> # Alternatives
> * A split_at(&self, pos: usize) -> (&OsStr, &OsStr) style method. This is ostensibly simpler than a slicing API. But:
> ** The OMG-WTF-8 encoding does not support this. It requires some splits to produce overlapping slices, so that left.len() + right.len() > orig.len(). The encoded bytes on one side of pos might form a valid OMG-WTF-8 string while those on the other side do not.
> *** RFC #2295 that proposes this encoding was merged five years ago (but has not been implemented).

何その絵に描いた餅を喉に詰まらせて死ぬみたいな話……

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

ほとんどのシステムはUTF-8以外のファイル名があったら無視かエラーでいいからどうでもええわ

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

https://mevius.5ch.net/test/read.cgi/tech/1691038333/514-528

ﾜｯﾁｮｲ付いてないとどこにでも出るな妖怪

**デフォルトの名無しさん** · 2025/02/07(金) 13:12:05.02

LinuxカーネルのメンテナがRustコードを混ぜることを「癌」と呼び、開発者間の対立が激化中 - TechFeed
https://techfeed.io/entries/67a52d4677bdbc0f2990eed9

争え……もっと争え……

**デフォルトの名無しさん** · 2025/02/07(金) 21:47:52.74

Linusが一喝するまで収めるの無理やろ

**デフォルトの名無しさん** · 2025/02/07(金) 22:08:06.65

そりゃドライバーはカーネルのインターフェイスに従って動作すべきだから、ラッパーなりで隠蔽すべきなんじゃないんかね。

個別のドライバーのためにカーネル側をカスタマイズするのはインターフェイスを侵食する越権行為だから、そんなのドライバーのラッパー側でやれ、と言いたくなるのはわかる。

**デフォルトの名無しさん** · 2025/02/08(土) 23:53:09.62

>>257
それは君の理解が間違っている

今回はRust製の各デバイスドライバが独自のCバインディングを持つ不便な状況を改善するためのパッチだ
つまりカーネルのC側に手を入れるパッチではなくC側は同じままで変更は一切ない
今回の件は該当部分dma_alloc_coherent()のC⇔Rustの抽象ラッパーのコードを含めるパッチだけだ
それさえメインテナーに拒否されたため大問題になっている

**デフォルトの名無しさん** · 2025/02/08(土) 23:57:46.16

デバドラはRustで書くのが普通になってきているから
そういう共通ラッパーという形のRustインターフェイスが色々と欲しいのよね
でもそれはいずれカーネル自体のRust化へ繋がる道になるから強く反対してるのよ

**デフォルトの名無しさん** · 2025/02/09(日) 00:59:41.26

普通に考えたら異種の言語が混ざるとデバッグと開発の障害でしかないからどこかで境目は必要

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

>>258
メンテナーがRust用コードのメンテナンスを拒否したということじゃないの？
Rust for Linuxでサポートするような話じゃないんかね。

**デフォルトの名無しさん** · 2025/02/09(日) 06:47:59.48

>>260
異種の言語を混ぜる話なんか誰もしていない
今回の事件のパッチも異種の言語を混ぜることなくCのAPIはそのままで
その上にRustの層を作る話

In response, Krummrich explained the Rust for Linux effort is creating Rust code that abstracts the C APIs for all Rust drivers and is maintained by Rust devs. In other words, the C side of the kernel stays the same, and Rust drivers use abstractions to that C code, and that these abstractions are maintained by a team centrally in rust/kernel, all of which is arguably better than drivers having their own individual C bindings.

**デフォルトの名無しさん** · 2025/02/09(日) 08:50:09.78

最終的にRust側のメンテナが切れてSNSで晒したりしたのは良くなかったけど
技術的にはC側に迷惑かからないように十分配慮して、出てきた懸念も全て潰したにも関わらず
「とにかくRustに関わりたくないから却下」だったからまぁ切れるのも分かる

**デフォルトの名無しさん** · 2025/02/09(日) 09:09:11.56

>>263
そのコードはcで使えるの？
使えるならともかく、Rust専用ならメンテナーが「そんなののメンテナンスで負担増えるのは嫌だからRustドライバー側でやってくれ」というのもわかる。

Rust for Linuxはこういうのの受け皿にならんのかしらん？

**デフォルトの名無しさん** · 2025/02/09(日) 09:24:37.62

>>264
受け皿も何もそもそもRust for Linuxでやってる話だし
完全にRustドライバー側でやるからCには影響しないって言ってるわけ
具体的にメンテナンスの負担が増える理由を挙げてくれれば対応策も考えられるけど
「とにかくお前らを邪魔するためなら何でもする」って言ってるからどうしようもない

**デフォルトの名無しさん** · 2025/02/09(日) 10:38:22.52

>>265
メンテナが「Rustは俺のサポート範囲に出てこないでドライバ内で閉じてやってくれ」と言うんだから、当面はrust fir linux でドライバーのテンプレートを作るなりCバインディングサポートライブラリを作るなりすればいいんじゃないんかね。

「Rust製の各デバイスドライバが独自のCバインディングを持つ不便な状況」というのもrust fir linuxでフレームワーク作ってサポートすれば解決するし。

**デフォルトの名無しさん** · 2025/02/09(日) 10:58:29.23

互いにブラックボックス内でなにが起ってるのかわからないとすると困るけどね

コレコレこういうコードを書いたらこういう結果が出るはずなのに出ないとコード提示されても
相手が理解できなければこじれるだけ

**デフォルトの名無しさん** · 2025/02/09(日) 11:17:45.05

>>266
そこで言う当面はってのは3-4年前の状況かな
今はもう準備も整って、Mac用のAsahiLinuxとかAndroidとかフォークしてる勢には普通に入ってる段階
だからそろそろ本体にって話になってるわけだけど、拒絶されるなら彼らはフォークに戻っていくだけだとは思う

**デフォルトの名無しさん** · 2025/02/09(日) 11:46:40.81

>>256
Linusの返答も出てるな
https://x.com/lauriewired/status/1888018962811863109

**デフォルトの名無しさん** · 2025/02/09(日) 12:46:41.58

内部の問題をSNSつかって文句言うなアホ
お前が問題じゃ

**デフォルトの名無しさん** · 2025/02/09(日) 13:50:57.72

ここや他のスレでRustに意味のわからん難癖つける人が
いるのは5ちゃん民度のせいではないのがわかった

**デフォルトの名無しさん** · 2025/02/09(日) 14:20:31.41

C++に似ている部分はC++と同じ程度に批判される
それとハイブリッド的な部分
100%ガソリンで動くか100%電気で動くかどっちかにしろという

**デフォルトの名無しさん** · 2025/02/09(日) 16:28:50.86

>>268
該当コード用のメンテナがRustを使いこなすようになるか、専用のメンテナが別に現れるか、現在のメンテナが引退してRust推進のメンテナに代わるまでじゃない？

これはメンテナの複雑性管理＆管理ポリシーの問題だから、普及具合とかはあんまり関係ない。

**デフォルトの名無しさん** · 2025/02/09(日) 23:42:15.23

色んなものがRust製になっていく中
最後まで残りそうなのが巨大でモノリシックなカーネルとブラウザになりそうだな

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

日本の古文漢文は残らないかもしれないが西洋では全部保存していて選択肢が増えるだけ
だから、向こうが世界の中心みたいな空気になる

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

firefoxはまだrust製にはならんの？

**デフォルトの名無しさん** · 2025/02/10(月) 17:38:09.01

Linux カーネルは保守的な方針だろ。
数年前まで C89 が前提だったんだぞ。
この速度感で考えるなら Rust 導入なんてまだまだ時期尚早じゃね？

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

Firefoxのレンダリングエンジンは大分前からRust製（Servo）でしょ

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

>>278
Servoにそんな完成度はない
実験レベル

**デフォルトの名無しさん** · 2025/02/10(月) 22:57:20.26

錆→癌

**デフォルトの名無しさん** · 2025/02/10(月) 22:59:57.28

Mozillaお金なさすぎて色々と切り捨てて
RustもRust Foundationへ移管されたもんな
結果的にRustにとっては中核が安定してラッキーになったけどさ

＞ 2020年にMozillaがすべてのServo開発者を解雇した後、プロジェクトのガバナンスはLinux Foundation Europeに移管された。
＞開発作業は公式には同じGitHubリポジトリで続けられており、プロジェクト自体は完全にボランティア主導です。

**デフォルトの名無しさん** · 2025/02/10(月) 23:42:58.20

C/C++その他の知識を蒸留してないわけがないから
コストもコスパもないんだよ

**デフォルトの名無しさん** · 2025/02/12(水) 22:57:39.73

Pointers (this includes values of reference type) in Rust have two components.
- The pointer's "address" says where in memory the pointer is currently pointing.
- The pointer's "provenance" says where and when the pointer is allowed to access memory.
We have to know not only the address the pointer points to,
but also track which other pointer(s) it is "derived from".
Provenance is useful because it allows powerful optimizations.
Provenance can affect whether a program has undefined behavior.

**デフォルトの名無しさん** · 2025/02/16(日) 23:45:42.12

Rust Tokyo 2024 開催レポート
https://gihyo.jp/article/2024/12/rust-tokyo-2024-report

**デフォルトの名無しさん** · 2025/02/21(金) 06:52:59.68

edition = "2024" が来たね

**デフォルトの名無しさん** · 2025/02/25(火) 13:22:53.51

https://softantenna.com/blog/linus-rust-policy/

Linus が一喝して技術的に合理的説明のない
rust拒否は許さないことで決着か

**デフォルトの名無しさん** · 2025/02/25(火) 13:50:37.48

生メモリいじくるのが好きな人たちがいきなりrustやれって言われたらきつい気持ちはわかる
どうせメンテーなんてみんなジジイなんだし

**デフォルトの名無しさん** · 2025/02/25(火) 15:08:04.83

rustが嫌でもやれなんて言ってないが

**デフォルトの名無しさん** · 2025/02/25(火) 16:25:22.46

Linusの今回の発言は明瞭で
・Cだけ触りたい人はそのままRustを覚えなくてOK
・その代わりRustについて口を挟む権利はない
・CのAPIをその利用者は自由に使えてメンテナといえども用途用法に口を挟む権利はない

したがって今回もめていた「CのAPIの上にRustのAPIを設ける件」について
Cだけ触りたいメンテナは口を挟む権利はなくパッチを拒否する権利もない、ということ
大方の人々が考えていた通りに決着

**デフォルトの名無しさん** · 2025/02/25(火) 17:47:40.26

口を出せない=メンテナ失格ということと受け取った

**デフォルトの名無しさん** · 2025/02/25(火) 18:17:51.25

かつてカーネルを正しく修正した結果として (保証してない挙動に依存した) 間違ったアプリケーションのいくつかがまともに動かなくなったことがある。
そのときに Linux の理念としては技術的合理性でユーザー体験を損なってはならないということで間違っているアプリケーションに合わせて互換性が維持された。
ユーザは一方的な利用者に過ぎずカーネルに口出ししないなんてことはない。
絶対に、絶対に、絶対に、カーネルに口出しするよ。
まあそれが良いか悪いかは知らんけどな。

**デフォルトの名無しさん** · 2025/02/25(火) 18:41:48.14

>>291
そういう具体性を欠いた屁理屈言って拒否するのは
やめろと怒られてるのだね

**デフォルトの名無しさん** · 2025/02/26(水) 04:07:17.14

>>290
そういうデマを言うやつがいるとコミュニティー全体が嫌われるから止めるべき。

Linusが言っているのはせいぜい「Rustコードのメンテナじゃないだろ」ぐらいの話で、Linuxメンテナ失格とは全く言っていない。むしろメンテナが自分のメンテナンス範囲をCコードだけにするのを肯定している。
今回の件も、C APIユーザーとしてのRustコードがCコードとは独立した形で別のメンテナにメンテナンスされるんじゃないんかね。

**デフォルトの名無しさん** · 2025/02/26(水) 19:09:22.06

着実にRust APIを増やしていこう
脱libc

**デフォルトの名無しさん** · 2025/02/27(木) 14:26:32.38

Rustは清書用

**デフォルトの名無しさん** · 2025/02/27(木) 21:14:53.56

じゃあRoughって言語も要るな

**デフォルトの名無しさん** · 2025/02/27(木) 23:34:31.56

Rustはリファクタリングでの安定度も他より極めて高くて開発効率が良いので
まずは雑に書いて後から可読性を上げたり拡張性を上げたり実行効率性を上げたり普通に行われているね

**デフォルトの名無しさん** · 2025/02/28(金) 08:15:36.47

>>296
クレート境界をダックタイピング化した言語が欲しいわ。

**デフォルトの名無しさん** · 2025/02/28(金) 12:17:20.44

>>291
その動作は弊社製品の仕様です
（今後も動作は維持されます）

その動作は弊社製品の問題点です
（今後動作は変更されます）

**デフォルトの名無しさん** · 2025/02/28(金) 12:19:57.96

>>298
それがC++かもしれませんね

**デフォルトの名無しさん** · 2025/02/28(金) 22:27:33.84

>>298
ダックタイピングは各異なる型を統一的に安全に呼び出せる保証が人任せだから使うべきでない
トレイト境界を指定すれば安全が保証されるがそれはトレイトすなわち他言語で言うところのインターフェースに近い存在を仮定していてダックタイピングとは言い難い

**デフォルトの名無しさん** · 2025/02/28(金) 22:51:15.56

>>301
>298のダックタイピングは静的ダックタイピングで構造的部分型のことね。
型の機能的な共通部分を部分型として統一的に扱うから、普通の型と同程度には安全かと。

**デフォルトの名無しさん** · 2025/02/28(金) 23:05:54.93

>>298
Go だと型があるインターフェイスを満たす (満たすつもり) かどうかは明示的な宣言がない。
インターフェイスで定義されたのと同じメソッドを持っていればそのインターフェイスを実装したものと見做される。

**デフォルトの名無しさん** · 2025/02/28(金) 23:49:44.86

>>302
まずその共通部分が存在する保証がない
次に共通部分があったとしてもその部分への任意のアクセスメソッドが完全に同一である保証がない
さらにダックタイピングで用意されるメソッドがその共通部分のみにアクセスされる保証がない
共通部分型方式には問題が山積み

一方でトレイト境界を用いると
共通部分を持たなくても安全に共通メソッドを増やすことができる

**デフォルトの名無しさん** · 2025/03/01(土) 00:09:58.46

相変わらず日本語不自由だな

**デフォルトの名無しさん** · 2025/03/01(土) 08:37:01.16

言語によるとしか言えない
その言語にある道具なら、それが便利なら使って問題ないと思う
C++だと標準ライブラリでもダックタイピングをごく普通に使うけど、それに文句を言う人もいないでしょ

**デフォルトの名無しさん** · 2025/03/01(土) 08:57:54.01

C++のような古くてダサい言語は比較する意味ないだろ
ダサくて自己責任となるダッチタイピングはお似合いだが

**デフォルトの名無しさん** · 2025/03/01(土) 09:10:51.88

Rust書きやすいって言ってるのは大体c++から移った人間でそういう人がここに集ってる
GC付きの言語から来たらそこまでは思わない

**デフォルトの名無しさん** · 2025/03/01(土) 09:47:12.55

>>304
静的ダックタイピングとか構造的部分型はご存知で？

コンパイル時にメソッドとかプロパティとかの部分集合で互換性を判定しているので、通常の型と同じレベルで合致するよ。

**デフォルトの名無しさん** · 2025/03/01(土) 11:24:22.93

>>304 に賛成

**デフォルトの名無しさん** · 2025/03/01(土) 11:25:33.81

>>306
便利さと安全性は独立してるからな

**デフォルトの名無しさん** · 2025/03/01(土) 11:39:32.69

>>310
>>304を理解できるなんて君は天才だねｗ

**デフォルトの名無しさん** · 2025/03/01(土) 13:10:29.22

A:「〇〇な言語があったらいいのに」
B:「言語によるとしか言えない」
A:「・・・」

**デフォルトの名無しさん** · 2025/03/01(土) 18:25:43.33

Structural Typingでバイナリ境界を超えて新しいメソッドを追加できるようにしてしまうと衝突時のデメリットがメリットを上回る
Rustにcoherenceがあるのと同じ

**デフォルトの名無しさん** · 2025/03/01(土) 22:44:41.75

>>308
GCの有無は関係ない
異なる型に対するコードの共通化つまりジェネリクスの話

例えばクラスを使えば同じ基底を継承する派生同士は異なる型でも共通のメソッドやプロパティを使える
しかし同じクラス継承の関係しか扱えないのは制約がキツく各機能毎に継承で多重クラス継承など問題が多い

一方でダッチタイピングや構造的サブタイピングは無関係な型同士でも同じメソッドやプロパティがあるだけで暗黙に使える
しかし互換性がなく偶然同じメソッドやプロパティを持つ同士の利用をエラーにできない問題や暗黙であるため複雑化してくると分かりにくくなるなど問題が多い

そこで機能毎にインターフェース宣言と各型でのインターフェース利用宣言することで諸問題を解決し安全で保守しやすいコードにすることができる
そしてインターフェース名(機能名)が付くことで複数の機能の列挙や関係も宣言できるようになる
Rustではトレイトと称する

**デフォルトの名無しさん** · 2025/03/01(土) 22:55:40.18

llmの3B当たりが吐き出す文章みたいで何を言ってるのか意味不明だな

**デフォルトの名無しさん** · 2025/03/02(日) 00:27:51.62

丸一日調べてこれとか泣けてくるな
ついでにRustのトレイト問題も調べとけよ

**デフォルトの名無しさん** · 2025/03/02(日) 08:35:08.13

>>313
最初の一文は違うだろ
A. 「(Rustにない、他の言語では使われてる機能) は問題だらけ」
っていう主張に対して反論されてるだけ

**デフォルトの名無しさん** · 2025/03/02(日) 15:32:34.86

>>312
少なくとも君は馬鹿だよ

**デフォルトの名無しさん** · 2025/03/02(日) 17:14:53.44

わからんけどtypescriptやれば

**デフォルトの名無しさん** · 2025/03/02(日) 18:00:38.37

ま人生一度は型厨になるのは仕方ない

**デフォルトの名無しさん** · 2025/03/02(日) 18:29:41.49

ダックタイピングは動的か静的かに関わらずデメリットが多すぎて使うべきではないよ
唯一のメリットはinterface宣言が不要だけどこれが害悪を招いちゃう
interface名がないから可読性が悪く保守性も低いのはもちろん利用方法に制限も

**デフォルトの名無しさん** · 2025/03/02(日) 19:02:58.00

静的なダックタイピングにはinterface宣言もinterface名もあるやろ

**デフォルトの名無しさん** · 2025/03/02(日) 19:17:03.00

>>323
名前をつけて宣言したらそれはinterfaceそのものだよ
名前も宣言もなしで共通のメソッド名など構造が同じなら動作することがダックタイピングだよ

**デフォルトの名無しさん** · 2025/03/02(日) 21:10:41.61

ubyの罪は重い

**デフォルトの名無しさん** · 2025/03/02(日) 21:55:50.48

Rustってまだオワコンになってなかったんだな

**デフォルトの名無しさん** · 2025/03/02(日) 22:12:16.30

構造に頼るよりも、ジェネリック関数でトレイト境界で制約かけた方がRustっぽい気がする。
なんとなく。

**デフォルトの名無しさん** · 2025/03/02(日) 22:50:29.46

>>324
上に出てきてるように構造的部分型(Strructural Subtyping)を含めた話
まあ俺もStrructural Subtypingを静的ダックタイピングと呼ぶのは
誤解を招きやすいからあまり賛同しないがそこは問題じゃないでしょ

**デフォルトの名無しさん** · 2025/03/02(日) 23:00:19.17

>>327
ジェネリックの型パラメータをトレイトで制約するということと
その制約を満たしてるかどうかを型の構造に頼ってチェックするのは両立する話

**デフォルトの名無しさん** · 2025/03/02(日) 23:17:39.99

共通する構造＆機能がある時に
・interface名(Rustではtrait名)を付けて宣言するか
・名付けずにダックタイピングするか
の違いが最も大きい
後者は様々な点で劣る

両者の中間的な位置付けにいるのがGo
Goでは各型に対するinterface実装宣言を省略できてしまうため
省略すると可読性や保守性で劣ることになる

**デフォルトの名無しさん** · 2025/03/02(日) 23:37:21.79

その「保守性が劣る」というGoは世間的には保守しやすい言語と言われてるんだが
型で守るという意味ではなく、多くの人に分かりやすい簡易な構文だからという理由でだけど

**デフォルトの名無しさん** · 2025/03/02(日) 23:44:33.72

各型に対するinterface実装宣言を省略すると可読性や保守性で劣る
その事実以外の話には言及していない

**デフォルトの名無しさん** · 2025/03/02(日) 23:54:11.22

その可読性や保守性の劣化というのは現実にどの程度問題と言われてるの？
「自分は嫌い」というお気持ちじゃなくて？
あるいは「Rustが採用してないから正しい」とか？

**デフォルトの名無しさん** · 2025/03/02(日) 23:57:06.79

一般的に必要な情報は暗黙ではなく明記されている方が保守性も高いんだよ
そして多くの人に分かりやすい
省略できるようにしたことはGoの仕様の失策だね

**デフォルトの名無しさん** · 2025/03/03(月) 00:08:35.40

Goの場合は「省略できる」というよりも「書かない」というのが正しい
選択できるものではなく、常に書かないものだから

正直自分も好きではないし、だいぶクセのある言語だけど、世間的には受け入れられてる
世の中の人は案外そこまで型にこだわりはなくて、それよりも分かりやすさの方が好まれたりする
それは単に「考えが違う」というだけで、劣るとか優れてるとかいうものではない
(それなら何でGoは人気なの？ってなるし)

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

あとRust開発者はC++から来た人が多いと思うけど、C++のテンプレートは思いきり静的ダックタイプでしょ
あれで実際「可読性ガー」ってなるより、便利だと思う場面もあるよね？

**デフォルトの名無しさん** · 2025/03/03(月) 00:12:13.08

>>334
明記されていたほうが分かりやすいというのは正しい。
その一方で、明記しなくても分かるような設計にしろ (分かり難くなるなら設計が誤っている) という哲学が Go の根底にある。

**デフォルトの名無しさん** · 2025/03/03(月) 00:19:18.53

structural vs nominalならが安全性はnominalのほうが高いが
保守性や可読性はどちらか一方が常に優れてるわけではないな

Rustはよりメタルに近いOSやライブラリでの利用を重視してるから
安全性の面からより保守的な選択をしてる
coherenceとかもアプリケーション開発者観点だと不必要に厳しい

**デフォルトの名無しさん** · 2025/03/03(月) 00:25:34.97

Goでは省略しちゃうことが多くて、
ある型についてどんなinterface群を満たしているのか、を把握するために、
対象となりそうな全てのinterface群の各々のメソッド群と見比べて、
そのメソッド群すべてを実装していることを確認することで、
ようやくそのinterfaceを満たしていることを把握できる。
たった1行を省略できる利便性(?)のために、大きく可読性が落ちているのは否めない。

**デフォルトの名無しさん** · 2025/03/03(月) 01:43:43.47

gopls implementationとかで確認すればいいよ

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

今どき珍しい真面目なスレッドだな

**デフォルトの名無しさん** · 2025/03/03(月) 04:54:41.57

>>330
静的ダックタイピングは明示的インターフェイスでも成り立つよ。>336で言うならテンプレートとコンセプトみたいにテンプレート引数の要件を明示するやり方。

>330の言い方なら、
共通する構造＆機能がある時に
・共通することを型としてあらかじめ宣言するか
・共通部分を使う時に判別するか
の違いですな。
後者は共通する構造＆機能の決定を実際に使用する時まで遅らせることができるので、型の設計時点で決めなくてはならない前者よりも設計の自由度が増す。

Adapterパターンのサポートが充実していれば問題を緩和できるけど、Rustて充実してたっけ？

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

Rustは各型で共通事項をあらかじめ宣言する必要がなく
共通する構造＆機能の決定を実際に使用する時まで遅らせて
それらが決まってから後から実装すればよいため
設計の自由度が高いね