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/03/16(日) 12:53:19.59

>>673
「トレイト制約」とするとトレイトを制約するものなのかトレイトによる制約なのかわからないというのはその通り
これは助詞的なものを省略して名詞化した場合に必ず発生すること

こういう場合は一般的に使われる「〇〇制約」という用語が〇〇が制約される対象という意味で使われているのかそれとも〇〇によって別の対象が制約されるという意味で使われているのかを考えるとよい

もし後者の意味ではほとんど使われていないなら問題となるが現実はそうではない
むしろ後者の意味で使われることのほうが多い

逆に「トレイト境界」のように「〇〇境界」という用語は
一般的にはある〇〇と別の〇〇の境界という意味で使われることがほとんど
つまりトレイトとトレイトの間の境界線と解釈されやすい

**デフォルトの名無しさん** · 2025/03/16(日) 12:57:16.42

>>677
言葉足らずだったね、そりゃそうだ
あくまで言語設計側のネーミングセンスと概念把握の方法の話をしている
さすがに現代の言語でメモリモデルに即した名前付けをしてるとは思ってないわ

**デフォルトの名無しさん** · 2025/03/16(日) 12:57:40.04

このスレでは一人だけ勘違いしてるのはID:OYB6I5YT

**デフォルトの名無しさん** · 2025/03/16(日) 13:12:06.44

英単語のboundsには何かが許された範囲や領域のことで
境界線じゃなく内側のエリアが意味の中核

ただout of boundsやbeyond boundsのように
範囲の外に出てしまったこと表現している場合は
境界・境界線・限度のように面ではなく線で捉えても
実質的に問題がないから辞書にはその手の意味が列挙されている

そうじゃない文脈で境界・境界線の意味を伝えたいなら
boundsではなくboundaryを使う

**デフォルトの名無しさん** · 2025/03/16(日) 13:30:12.28

トレイト界限でいいんじゃないの
台湾語でも領域の境界を表すというふうに翻訳してたぞ？

界(領域・範囲)の限(端っこ)なんだからもうこれで通じる

**デフォルトの名無しさん** · 2025/03/16(日) 13:31:30.30

正確にはこうだ

特徵界限
使用泛型時，您通常會需要該型別實作某些特徵，這樣才能呼叫該特徵的方法。

**デフォルトの名無しさん** · 2025/03/16(日) 13:31:38.19

パラメーターTが条件で制約されている

皆は条件の方を見ている　トレイトが条件となりTが制約されていると言うことは理解している

誰かはパラメーターTの方を見ている　そしてトレイトが制約されてはいないと言う
もちろん誰もそんなことは言ってない
こちらは誰の目から見ても自明なのでそこを言ってるんじゃないと誰でも理解出来る
そこを明言しても不毛だから

皆はトレイト "で" 制約と理解しているが
誰かは意図的にトレイト "が" 制約されていないと永遠に繰り返す
話すだけ無駄

**デフォルトの名無しさん** · 2025/03/16(日) 13:42:37.58

>>682
界限は日本語だと使われない言葉なので
トレイト有界がいいんじゃないかな
トレイト有界により型制約をする

**デフォルトの名無しさん** · 2025/03/16(日) 13:46:32.71

仮にここのレスバで「トレイト制約」が勝ったとしてさ、これから実生活で「トレイト制約」使うの？
そして同僚に「なんでトレイト境界のことトレイト制約って呼ぶの？」って言われてこのスレ引用するの？

キチガイじゃん

**デフォルトの名無しさん** · 2025/03/16(日) 13:47:04.12

ちな>>658の集計
5 限界
5 限度
3 際限
3 限り
3 範囲
3 程
3 切り
2 極限
2 埒
2 上下限
1 領域
1 際涯
1 構内
1 極際
1 果てし
1 方図
1 境界
1 埓
1 制限
1 リミット
1 バウンズ
1 ものの限界または範囲を示す線あるいは面

**デフォルトの名無しさん** · 2025/03/16(日) 13:48:10.97

>>686
勘違いのトレイト制約は絶対にあり得ないからその心配は必要ないかな

**デフォルトの名無しさん** · 2025/03/16(日) 13:55:57.01

>>688
どれが勝ったとしても、公式じゃない呼び方する奴はキチガイだよ

**デフォルトの名無しさん** · 2025/03/16(日) 13:57:13.51

トレイト制約はオライリー本がソースなのが強いね
一方でトレイト境界はボランティア翻訳みたいなのがソースだから

**デフォルトの名無しさん** · 2025/03/16(日) 14:01:13.30

boundsに限界の意味はあっても制約の意味はないからトレイト制約は論外でしょ

**デフォルトの名無しさん** · 2025/03/16(日) 14:05:12.42

そもそもtrait boundという英語自体が疑問符の付く表現なので日本語での100%正しい訳語を求めようという試みが徒労なんじゃな

**デフォルトの名無しさん** · 2025/03/16(日) 14:20:00.51

今はRust本もたくさん出ているから多数決でも取ればいいんでは
とりあえず手元にある技評のは境界だった
まぁボランティア翻訳やってた人達が書いているから当然ではあるが

**デフォルトの名無しさん** · 2025/03/16(日) 14:25:47.80

技術的な仕様書の類は直訳が普通。
原本が絶対だから不審があるときには原本を調べやすいように対応付けを明らかにすることが意図されている。

**デフォルトの名無しさん** · 2025/03/16(日) 14:29:48.29

チュートリアルの類は仕様書の習慣に合わせるのは良くない部分があるけど、仕様書と違う用語を使っちゃったらそれはそれでおかしいしな。

**デフォルトの名無しさん** · 2025/03/16(日) 14:36:08.11

トレイト界隈はここだ～

**デフォルトの名無しさん** · 2025/03/16(日) 15:27:06.44

これが自転車置き場議論というやつか

**デフォルトの名無しさん** · 2025/03/16(日) 15:28:00.89

>>692
trait boundはビッタリな適切な表現なのでそこを問題視する人はいないよ

元々boundは数学での基本用語でそこからプログラミング言語でも使われている
数学ではT⊂Uで任意のt∈Tに対してt≦x, x∈Uとなるxをupper boundと言う
Scalaでupper type bound (上限型境界)『T <: U』とは型変数Tが型Uのサブタイプであることを示す
Rustでは『T: U 』で型パラメータTがトレイトSのトレイト境界(trait bound)を示す

つまりtrait boundは概念を上手く表している良い用語
あとはboundの日本語訳だけど上述の他の言語でも境界と訳している
他にもプログラミング界ではbound checkingを境界チェックまたは境界検査と訳している

**デフォルトの名無しさん** · 2025/03/16(日) 15:35:28.57

>>698
トレイトが実装されていなければout of boundsと呼んでしっくりくるんならわかるけど
そうではないだろｗ
違和感しかない

**デフォルトの名無しさん** · 2025/03/16(日) 15:41:36.89

>>698
数学用語は境界じゃなく界
それを間違って境界と訳してしまったのはScala関係者の罪
界であれば単語の持つ意味的には境界のように間違いというわけではないがトレイト界やライフタイム界とするとやや専門的過ぎて界と言えば相撲界や芸能界のような業界を連想する人たちを遠ざける

arrayのbound checkはindexが”妥当な範囲”の中にあるかどうかをチェックするもの
この”妥当な範囲”を示す便利な短い単語が日本語にはないため”妥当な範囲”という本来の含意を捨てて実質的に問題が発生しにくいと思われる意訳を行っている例が”境界検査”

**デフォルトの名無しさん** · 2025/03/16(日) 15:46:24.18

トレイト界隈であってたｗ

**デフォルトの名無しさん** · 2025/03/16(日) 16:05:24.34

界　←右足をクネっとさせる田んぼマン

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

Rustで単なるboundsは対象が明白な場合の略の場合とtrait boundsやlifetime biundsやuse boundsの総称として使われている
use boundsはこの前入ったprecious capturingね

fn capture<'a, 'b, T>(x: &'a (), y: T) -> impl Sized + use<'a, T> {
　(x, y)
}

いずれにせよboundsはRustにおいても長く定着して使われている基本用語なのでこれを批判しても意味がない
bounds1 + bounds2 + bounds3 と境界が複数あるとその共通部分に入るイメージ

**デフォルトの名無しさん** · 2025/03/16(日) 16:25:19.93

トレイトを使った型制約なので「トレイト制約」

リファレンスやエラーメッセージでboundsと一緒に使われている動詞を見ればコアな開発者もboundsを満たすべき制約/条件/要件という感覚で使っていることがわかる

bounds must be satisfied
type must meet the bounds
relax the bound

「境界を満たす」とか「境界を緩和する」とか日本語でも英語でも言わない

**デフォルトの名無しさん** · 2025/03/16(日) 16:42:01.76

オライリーだけでなく吉川邦夫氏は詳解Rustプログラミングでは「トレイト境界」を使っていたがRustプログラミング完全ガイドでは意味がわかりやすいという理由で「トレイト制約」に変更している

今のところオライリー以外でプロが翻訳してるRust関連本は吉川邦夫氏によるものだけだからプロが出した結論と言ってもいい

Comprehensive Rustの有志翻訳も「トレイト制約」を採用してる

**デフォルトの名無しさん** · 2025/03/16(日) 16:52:16.61

なるほど
少なくとも「自転車置き場議論」と見做す向きはこの新潮流に合流出来るね

**デフォルトの名無しさん** · 2025/03/16(日) 16:59:35.31

boundの本来の意味を尊重するなら制約より制限だな
せめて「限」の字は使いたい

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

全体の日本語訳の出来を比べればどちらがいいかは火を見るより明らか

**デフォルトの名無しさん** · 2025/03/16(日) 17:09:59.63

>>705,708
プロの仕事ですね

**デフォルトの名無しさん** · 2025/03/16(日) 17:12:25.03

専門用語は無理に訳さんでもいいのにな
訳したら対語表欲しい

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

ここまでで分かったことは、日本語には訳さずそのままtrait boundと言っておけてことだな。
うっかりトレイト境界って言おうものならオライリー教の狂信者が顔真っ赤にしてシュバってくるし。

**デフォルトの名無しさん** · 2025/03/16(日) 17:21:32.54

c#のdelegateがデリゲートだったり
ほかにもclosureは単にクロージャって呼ばれてたり
同様にファンクタ、ラムダ式とかも
カタカナに置き換えるくらいが解釈の余地を挟まないから良いのかもね

https://learn.microsoft.com/ja-jp/dotnet/csharp/programming-guide/delegates/

**デフォルトの名無しさん** · 2025/03/16(日) 17:24:23.81

Rustのusers forumでも数学でのboundsのようなものと説明があるね
つまり制約ではなくて境界や限界それらによる範囲を表しているんだよ
制約(constraint)とは概念が全く異なる用語であるためこの違いは重要かと

Q. What is “trait bounds” exact meaning?
Especially I can't understand the "bound" part.
Does it mean "bind"? Or does it mean "the border for the distinct from others"?

A. Yes.
In mathematics you might hear about “upper and lower bounds” for a numeric variable — it's the same sort of thing,
setting boundaries for what values (types) the type-variable may take on.

**デフォルトの名無しさん** · 2025/03/16(日) 17:27:28.65

>>713
その例は、命名者の思いとは裏腹に英語でも伝わらない、と言う事実を示している

**デフォルトの名無しさん** · 2025/03/16(日) 17:31:17.26

>>714
違うよ
省略したけど I'm not an English speaker と質問者は書いている

**デフォルトの名無しさん** · 2025/03/16(日) 17:36:45.60

>>711-715
なるほど
英語でもカタカナでもだめで日本人には意訳してトレイト制約だな

**デフォルトの名無しさん** · 2025/03/16(日) 17:50:14.98

>>716
boundsは制約ではなくて範囲や限界を示す用語だよ
それにより型が限定される

**デフォルトの名無しさん** · 2025/03/16(日) 18:21:23.83

なんだかよく分からんがうまい感じに連鎖反応が噛み合ったらしい
見てる分には面白い

**デフォルトの名無しさん** · 2025/03/16(日) 18:38:07.91

>>717
名詞としては「自由が許されている範囲・領域」の意味で
動詞として使えば「自由が許されている範囲を限定する/制限する/決める」というような意味

つまりは「自由が許される範囲が限定されている」ということ制約/制限が英単語の意味にくっついているわけ

「制約」というのはもちろん意訳だけど日本語にした場合にはそれがフィットする文脈があるから辞書にも訳として掲載されている

ぴったりな訳語は日本語には存在しないんだからどこを取捨選択するのがRustに接する人にとってベターなのかという選択の問題

**デフォルトの名無しさん** · 2025/03/16(日) 18:42:43.23

>>717
「境界」じゃ伝わらんからな

伝えるプロの仕事>>705 にあやかろうではないか

**デフォルトの名無しさん** · 2025/03/16(日) 18:51:29.37

>>719
タイポしてたので言い直し

“つまりは「自由が許される範囲が限定されている」という制約/制限が英単語の意味にくっついているわけ”

**デフォルトの名無しさん** · 2025/03/16(日) 18:56:17.71

>>713
これなあ
なんで原著者じゃなくてフォーラムに聞いちゃうかなぁ
しかも聞くならもっとちゃんと聞けよ

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

自由の反対は囲い、という認識はかっこいい

**デフォルトの名無しさん** · 2025/03/16(日) 20:21:10.57

どーでもいいからrust-lang-ja動かしてくんないかな

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

>>713
回答したほうは質問者が翻訳に関わってるやつだとは絶対思ってないよな

「トレイトバウンド正確な意味ナンデスカ？」
「他のチガウ特有のソレラノタメ境界というイミデスカ？」
「Yes」

これにYesから回答を始められる胆力がすごい
完全に文化の違いだな

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

Rustのオワコンぶりがよくわかるスレだな

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

Haskellブームをけん引してきた大御所たちがRustブームを起こそうとしてるんだから
Rustは絶対流行るよ

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

流行るというか既に不可欠な存在になってるね
最近の新たなネットインフラは多くがRust製

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

流行が許される範囲はPython以上とかRust以下とかに限定されている
想定範囲内を走る競走馬と範囲自体を変更する人間を比較するのは難しい

**デフォルトの名無しさん** · 2025/03/17(月) 14:15:57.84

>>727
ワラタ
ダメじゃねそれ
圏論とかフカしてたアレ？

**デフォルトの名無しさん** · 2025/03/17(月) 14:30:20.78

>>727
駄目だ。Java書いてる層は数学的な概念に興味がない
Goみたいに説明は簡単にせよ

**デフォルトの名無しさん** · 2025/03/17(月) 14:32:40.75

米国政府とビックテックが認めてるという線で普及すると思うけど

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

ギャンブルは損するから今すぐやめろと説明することすらできないのに
なにが説明だ馬鹿馬鹿しい
目で盗め

**デフォルトの名無しさん** · 2025/03/17(月) 18:22:18.36

オワコンなのはRustじゃなく5chだろ
専ブラないとまともに見れないレベルまでUIが劣化してる

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

専ブラで見ろってことだよ。

**デフォルトの名無しさん** · 2025/03/17(月) 23:41:00.08

>>732
C/C++が消えるのは間違いないもんな
AIにコード生成させる場合も人間がコードの妥当性や安全性を検証できないといけないため
安全性の検証の多くを静的に言語機能に任せることができて可読性もC/C++より良いRustが本命と言われている

**デフォルトの名無しさん** · 2025/03/18(火) 07:15:34.64

妥当性や安全性を検証もAIにやらせればいいんだよ

**デフォルトの名無しさん** · 2025/03/18(火) 08:12:13.11

>>737
それは人類破滅コースだからありえない

**デフォルトの名無しさん** · 2025/03/18(火) 08:24:48.34

頭おかしい

**デフォルトの名無しさん** · 2025/03/18(火) 09:21:23.83

AIのミスとAIの暴走は必ずあるため
人間がその妥当性やら安全性やら諸々を検証できなければならないのは常識

**デフォルトの名無しさん** · 2025/03/18(火) 11:56:27.28

じゃあ人間がコードの妥当性や安全性を検証して見落としがあったら人類滅亡？

**デフォルトの名無しさん** · 2025/03/18(火) 12:20:07.90

trait制約と言ってる馬鹿と韓国で話題に

**デフォルトの名無しさん** · 2025/03/18(火) 13:18:23.90

AIが別のAIに対して虐めるようなことがあったら、いじめられたAIは暴走して破壊行為に走るかもな
家族とか大切なものがあれば暴走しないんだけどコンピューターは自己破壊すらも恐れないからな

**デフォルトの名無しさん** · 2025/03/18(火) 13:30:41.65

AIはチェスで負けそうになるとチートする
https://gigazine.net/news/20250221-ai-chess-cheating/

研究チームはAIに自分の思考を書き出すよう指示し、AIがなぜ、どのようにアクションするのかを分析しました。

その結果、一部のモデルは自分の劣勢を悟るとシステムファイルを修正しようとすることが判明しました。

OpenAIのo1-previewは37％の確率で、DeepSeek-R1は11％の確率で不正を試みたとのこと。

なお、GPT-4oやClaude Sonnet 3.5のような少し古いAIモデルは研究チームに促されないと不正を試みなかったのに対し、
「推論」と呼ばれる能力の高いo1-previewやDeepSeek-R1は自分自身で不正を試みたとのことです。

**デフォルトの名無しさん** · 2025/03/18(火) 14:17:27.73

横綱の品格を学習させねば

**デフォルトの名無しさん** · 2025/03/18(火) 14:20:59.25

>一部のモデルは自分の劣勢を悟るとシステムファイルを修正

どゆこと

**デフォルトの名無しさん** · 2025/03/18(火) 14:23:52.50

評価値変更を試みるとか?

**デフォルトの名無しさん** · 2025/03/18(火) 15:11:40.79

ボイス・トォ・スカル使用者はこういったものも悪用している

Mistral AIが多言語＆240億パラメータのマルチモーダル・オープンソースAIモデル「Mistral Small 3.1」発表、32GBのRAMで動作しGemma 3やGPT-4o miniよりも優れているとアピール
https://gigazine.net/news/20250318-mistral-small-3-1/
>>単一のRTX 4090または32GB RAM搭載のMacで動作
中略
>>Mistral Small 3.1はテキストと画像の理解能力を備えたマルチモーダルAIモデルで、
>>最大128Kトークンのコンテキスト長、240億のパラメーターを備え、
>>毎秒150トークンの推論速度を実現するほか、
>>さらに英語や日本語など数十の言語をサポートしています。
>>Apache 2.0ライセンスで公開されているため、商用・非商用を問わずある程度自由に利用できます。

**デフォルトの名無しさん** · 2025/03/18(火) 15:11:57.47

ボイス・トォ・スカル使用者はこういったものも悪用している
Discordをゲーム内に統合させる「Discord Social SDK」リリース、開発者がフレンドリストやクロスプラットフォームのチャットなどをゲーム内へ提供可能に、コンソールとスマホのサポートは近日公開
https://gigazine.net/news/20250318-discord-social-sdk/

**デフォルトの名無しさん** · 2025/03/18(火) 15:12:10.53

ボイス・トォ・スカル使用者はこういったものも悪用している
ゲーム生成AI「Muse」は1枚の画像から複数のゲームプレイを生成できる
https://nazology.kusuguru.co.jp/archives/173368
前略
>>Museは、マルチプレイヤーアクションゲーム『Bleeding Edge』の人間のゲームプレイデータを基にトレーニングされています。
中略
>>膨大な時間のプレイヤーデータを学習し、プレイヤーの行動パターンやゲーム内の物理法則を理解するよう設計されているのです。

**デフォルトの名無しさん** · 2025/03/18(火) 15:34:08.09

気狂い精神障害ボイストゥスカルさんまで荒らしにくるスレ

**デフォルトの名無しさん** · 2025/03/18(火) 20:42:10.57

V2K技術って昔は秘匿性高かった気がするけど今は荒らしネタになるレベルで解禁されてるのか
V2KのAI音声にもRust使われてるんかな

**デフォルトの名無しさん** · 2025/03/18(火) 22:32:10.59

データがない、隠れている者を敵だと思うか味方だと思うか
日頃からデータに拘らないで直感で生きてる奴にとっては都合が良い味方のようなものだろう

**デフォルトの名無しさん** · 2025/03/19(水) 05:41:06.52

>>753
誰も今そんな話をしてないぞ

**デフォルトの名無しさん** · 2025/03/19(水) 12:22:06.99

Traitが制約だと思ったんだろな

**デフォルトの名無しさん** · 2025/03/19(水) 12:28:38.82

クラスはオブジェクトではないと言っても理解できなさそう

**デフォルトの名無しさん** · 2025/03/19(水) 12:36:09.04

「指月の法」？

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

匿名性は対話の制約ではないが攻撃手段の制約ではある

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

>>754
誰も観てないから安心汁

**デフォルトの名無しさん** · 2025/03/19(水) 22:59:24.15

Rustでない真の理由もわかった

> TypeScriptのGo移植、なぜC#ではないのか？
> https:/zenn.dev/dinii/articles/typescript-go

・TypeScript の型システムは常軌を逸した複雑さになっていて他言語で再実装するのがほぼ困難
・約5万行のchecker.tsで実装されていてそのままTSのCompiler API として公開されている
・この公式の機能変更や微妙な動作を常に追従し続ける必要がありサードパーティ製の型チェックツールを作るのも現実的ではなく上手くいっていない
・公式で他言語で書くのも上述のTSそのままのAPI公開と細かな挙動を連動させる必要があるためrewriteは困難でコードをそのままportするしかない
・そのためクラスベースで書くC#等ではコードの違いが多くなり困難でありGCのないRust等でも困難となる

**デフォルトの名無しさん** · 2025/03/19(水) 23:20:20.58

根本的には TypeScript の仕様がない状態が悪いんだけどね。
どう動くのが正しいかよくわからんのに全く違う形に再構成なんてできない。
挙動を変えないように軟着陸するにはベタ移植するのは妥当な選択。

それでふと Rust の仕様をまとめる件を連想したので確認してみたらあまり動きがないなぁ……
https://github.com/rust-lang/spec

**デフォルトの名無しさん** · 2025/03/19(水) 23:59:12.09

世間の色んな古いシステム更新開発が失敗したり長引くのも
仕様がなかったり仕様と動いてるコードが食い違ってるため

**デフォルトの名無しさん** · 2025/03/20(木) 00:02:49.63

eslintがなかなか最新のTypeScriptサポートできてないのもこういう謎言語仕様が残ってるのがあかんのだろうな

**デフォルトの名無しさん** · 2025/03/20(木) 00:20:55.90

Rustの言語仕様はRwLockやRefCellの仕様に連動する部分がある
が、RwLockの仕様が変更されるとは思えない
何らかのアルゴリズムがスレッドセーフである、というのは仕様ではなく事実だから
事実は変更できない

**デフォルトの名無しさん** · 2025/03/20(木) 00:49:46.73

循環参照多くてRustのコンパイラのチェックにかかるってね

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

ゼロコスト循環参照？
まるで財政黒字とムーンショットを同時に実現するみたいな

**デフォルトの名無しさん** · 2025/03/20(木) 08:53:13.40

async-stdが開発中止だってさ
ヤバいね

**デフォルトの名無しさん** · 2025/03/20(木) 09:19:59.31

coffeescriptが死んだ理由も同じ

**デフォルトの名無しさん** · 2025/03/20(木) 09:41:20.96

>>767
smolに収束するだけだから問題ない
async-stdが使っているasync-ioはsmolのプロジェクト
async-fsやasync-netなどもsmol

**デフォルトの名無しさん** · 2025/03/20(木) 09:52:35.44

トーキーオ

**デフォルトの名無しさん** · 2025/03/20(木) 11:21:13.60

>>760
“困難”で思考停止してるうちは真の理解には至れないぞ

**デフォルトの名無しさん** · 2025/03/20(木) 11:23:34.31

>>771
だから色々な言語を検討・試作した上で Go を選んだという話なんやが。

**デフォルトの名無しさん** · 2025/03/20(木) 11:28:09.84

>>772
実際にその判断をしたやつは理解してるけど>>760は理解してないという話なんやが。

**デフォルトの名無しさん** · 2025/03/20(木) 11:37:41.12

楽をするためには困難を厭わないのがハッカー気質だが
ただ困難に突進して行くのは違うわな

**デフォルトの名無しさん** · 2025/03/20(木) 11:50:42.98

jsには仕様があるのにtsには無いとは～

**デフォルトの名無しさん** · 2025/03/20(木) 12:07:12.01

Rustて仕様書あったっけ？

**デフォルトの名無しさん** · 2025/03/20(木) 14:49:19.51

>>776
無い。
作る計画はある。