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

**デフォルトの名無しさん** · 2022/08/05(金) 08:26:38.87

スレタイ以外の言語もok

前スレ
https://mevius.5ch.net/test/read.cgi/tech/1655771266/

**デフォルトの名無しさん** · 2022/08/20(土) 04:00:19.70

>>700
コンパイル時にIOエラーに対処せよなんて話はしてないよ
そもそもコンパイル時にwrite(2)が呼び出されないんだからそのエラーに対処できるはずもない

drop内でエラーが発生しても検知できないから、dropの前にflushなどの呼び出しを強制できないの？という話

**デフォルトの名無しさん** · 2022/08/20(土) 05:07:56.91

>>702
なるほど。
4回目ワクチンのせいで読解力が低下してるようだ。エロいページ見て心を静めてくる。

**デフォルトの名無しさん** · 2022/08/20(土) 07:41:29.18

論理的にモノを考えられるヤツは４回も打たない

**デフォルトの名無しさん** · 2022/08/20(土) 09:18:15.53

医療従事者とか高齢者施設従業員とか正規の4回目来てるんですよ

**デフォルトの名無しさん** · 2022/08/20(土) 10:31:20.74

>>701
>そういうことではなくて、drop内でエラーが起きた場合の話を気にしている
わかってるよ
drop前に確実にflushが呼ばれるようにしてflushした場合のエラーをハンドリングしたいなら
context managerを自作するのがいいって話

buffer.len()をチェックしてcompile_error!でエラーにするようなAPIも作れなくは無いかもしれないけど
それをやる場合にもBufWriterへの一連操作をラップしたcontext manager的なのを作ることになるので
エラーにするんじゃなくてflushしてあげたほうが親切

**デフォルトの名無しさん** · 2022/08/20(土) 11:15:29.57

なにこれ
ワクチン接種証明書の例え話が役に立つという寓話なのか
fn hoge(&mut self) -> flush証明書 {
flush証明書::new(self.file)
}

**デフォルトの名無しさん** · 2022/08/20(土) 14:05:39.10

>>686
システムプログラミング向け言語という時点でGC言語は対象外となる
無条件RAIIによる自動デストラクタ呼びを前提としている点でもGC言語は対象外となる

>>689
書き忘れていたらコンパイルエラーにするという時点で
RAIIもどき実現のためのusingやdeferなど使うGC言語はそれを書き忘れてもエラーとしないから
GC言語は前提にすら辿り着けないことになる

結局その機能を現在もしくは今後に実現できる言語は非常に限られている

**デフォルトの名無しさん** · 2022/08/20(土) 14:47:10.43

>>706
context managerを知らないんだけど、pythonの用語で合っているかな？
スコープの入り口と出口に処理を差し込むようなものに見えたけど、こんな関数を用意するようなイメージ？

fn with_file(f: impl FnOnce(&mut File) -> io::Result<T>) -> io::Result<T> {
　let file = File::create(...)?;
　let res = f(&mut file)?;
　file.flush()?
　Ok(res)
}

確かにこれで解決するケースも多いね

**デフォルトの名無しさん** · 2022/08/20(土) 15:11:47.48

>>709
そういう単純な対応は他言語含めてよくあるパターンだが狭い範囲しかカバーできない欠点がある
例えば複数のファイルなどを順序前後して扱うと破綻
その観点の専用クロージャとなっているためそれ以外からの処理を巻き込みたい時にも破綻
ファイルディスクリプタを保持して戻りいつ解放かすぐ決定しない場合も破綻
並行並列化する時も破綻

**デフォルトの名無しさん** · 2022/08/20(土) 15:25:13.28

>>709
こういっては失礼かもしれないけど、なんて汚い実装だ....

**デフォルトの名無しさん** · 2022/08/20(土) 15:32:14.61

>>710
だからこれで解決するケース "も" あるって書いたでしょ
もっとよいワークアラウンド考えるか次世代言語の仕様提案してくれ

>>711
どこがご不満？

**デフォルトの名無しさん** · 2022/08/20(土) 16:19:57.30

>>712
Rustスレで半年前に出ている以下のアプローチはどう？
他の言語では無理だけどRustならば所有権の行方を静的に解析してコンパイラが持っているため

https://mevius.5ch.net/test/read.cgi/tech/1636247099/700
＞コンパイラは解析してdropさせるべき位置を把握しているから
＞そこへ至る全ての経路上で例えばFinalize trait実装型はそのメソッドfinalize()を呼んでいないとコンパイルエラーとなる
＞というような制約をするFinalize trait

**デフォルトの名無しさん** · 2022/08/20(土) 16:55:09.50

>>713
それは良さそう
dropに至るまでの処理でエラーが発生した場合はFinalize不要にするとかの考慮は必要そうだね
?で脱出したか否かで区別できるかな？

**デフォルトの名無しさん** · 2022/08/20(土) 18:48:46.98

>>709
そう、そういうイメージ
FileManager的なstructを定義してnewするときに内部でFile::createして持っておいて
withでクロージャを受け取るようにするとネストしたりしやすい気がする

buffer.len()とcompile_error!マクロでどうにかする方法は無理そうだった

あとは明示的flush未実行の型と実行済みの型とをそれぞれ作って
一連のI/O処理の戻り値をflush実行済みの型にしておくことで
flush忘れたらコンパイルエラーにするという方法ならできそう
面倒くさいけど

**デフォルトの名無しさん** · 2022/08/20(土) 19:18:04.66

>>715
後半のアイディアについてはコンパイルエラーにするのは難しそうだね
dropの呼び出しを禁止したりコンパイルエラーにしたりする方法は多分ないと思う
リンク時エラーにするアイデアはあるみたいだけど、ちとやり過ぎな感がある
https://mevius.5ch.net/test/read.cgi/tech/1636247099/695

**デフォルトの名無しさん** · 2022/08/20(土) 21:47:48.47

リソース確保、開放といった共通化できる操作はテンプレート化したいが、そのために真にやりたい操作をクロージャや関数にして一段ネストを深くしてしまうのがなんか違う気がするんだよなぁ。

**デフォルトの名無しさん** · 2022/08/20(土) 21:56:02.14

システムプログラミングじゃそれが本質的に指摘すべきことなんだから仕方ないだろ。

**デフォルトの名無しさん** · 2022/08/20(土) 22:17:19.61

>>713のやり方ならば
そのような対応も不要でプログラムの構造も変えずに済むし
関数から返したり長生きしてもよいし
デストラクタでエラーが起きうる型に適用しておくだけでよく
利用側プログラムに他の付加コードは不要だから理想的にみえる

**デフォルトの名無しさん** · 2022/08/20(土) 22:34:29.93

>>719
特定条件のときだけ開放処理が行われるみたいな分岐があるケースとか考え出すと難しくないかな。

まだ finalize してなければ finalize するみたいな処理を Rust が決定したdrop位置の直前に書かせるという制約を課すだけでいいのか？

**デフォルトの名無しさん** · 2022/08/20(土) 23:34:50.48

>>720
>>713のメソッドfinalize()は最後に呼ばれるべきものだから
Selfで受けて消費しちゃう仕様でもいいよね
するとコンパイルエラーが起きない正しいプログラムでは自動drop()が全てfinalize()の中で起きる
つまりfinalize()以外で自動drop()が起きる部分をコンパイルエラーとすればよいのではないか？
例えばfinalize()を呼ばずにスコープブロックエンドに達しているコードと
ブロックから脱出return/breakしているコードをコンパイルエラーとする

**デフォルトの名無しさん** · 2022/08/21(日) 00:02:05.58

>>713は実現不可能だよ

**デフォルトの名無しさん** · 2022/08/21(日) 00:50:42.36

>>722
実現できる
コンパイラはdropする可能性のある場所を全て把握していて、そこへdrop()呼び出しコードを埋め込んでいる
つまり>>713を>>721の方法で実現するのは容易
finalize()内以外でdrop()呼び出すコードを必要としたらコンパイルエラーとする対応をコンパイラ加えるだけで実現できる

**デフォルトの名無しさん** · 2022/08/21(日) 01:16:56.45

こういう時は自前主義の方が冷静
自前でできないことを期待するのは虫が良過ぎる

**デフォルトの名無しさん** · 2022/08/21(日) 02:47:44.56

絵に描いた餅はおいしいですか？

**デフォルトの名無しさん** · 2022/08/21(日) 05:02:05.10

>>723
> finalize()内以外でdrop()呼び出すコードを必要としたらコンパイルエラーとする対応をコンパイラ加えるだけで実現できる
それは「現状では」実現不可能って言うんでは？

**デフォルトの名無しさん** · 2022/08/21(日) 05:25:55.50

Rustならば現状のコンパイラで実現できる
finalize()を呼び忘れていたらコンパイルエラーとすることが可能

**デフォルトの名無しさん** · 2022/08/21(日) 09:26:43.80

他人の現状よりも
自前でできそうな願望がいい

**デフォルトの名無しさん** · 2022/08/21(日) 10:53:20.77

>>721,723
「つまり」の前後の論理が全くつながってない

**デフォルトの名無しさん** · 2022/08/21(日) 11:04:13.82

つまり
絵にすらなってない餅

**デフォルトの名無しさん** · 2022/08/21(日) 11:37:20.10

つまり霊感商法

**デフォルトの名無しさん** · 2022/08/21(日) 12:28:30.42

容易と言い切るなら実装見せて欲しいな

**デフォルトの名無しさん** · 2022/08/21(日) 13:05:23.69

つまり複製おじさん論法

**デフォルトの名無しさん** · 2022/08/21(日) 15:07:41.13

つまり「募ってはいるが募集はしていない」的な話？

**デフォルトの名無しさん** · 2022/08/21(日) 16:22:57.49

つまり
現状のコンパイラで容易に実現できるが
コンパイラに手を加えずに実現できるわけではない
ということでしょw

**デフォルトの名無しさん** · 2022/08/21(日) 17:39:47.32

>>735
現状のrustならできるらしいよ ⇒ >>727
なおどうやるかは本人しか知らないみたいだけどw

**デフォルトの名無しさん** · 2022/08/21(日) 18:17:26.66

>>735
「現状のコンパイラで実現できる」
というのは
「現状のコンパイラ(の機能を活用してfinalize()内以外でdrop()呼び出すコードを必要としたらコンパイルエラーとする新機能をコンパイラに加えるだけ)で実現できる」
という意味なんでしょw

**デフォルトの名無しさん** · 2022/08/21(日) 19:08:55.38

次世代言語の話だから、現行言語をもとに「原理的には可能」で議論も悪かないと思うけどね。

**デフォルトの名無しさん** · 2022/08/21(日) 19:35:37.95

悪くはないがコンパイラに手を加える必要があるならそう言わんといかんわな。
しょーもないわかりやすいプライド見せられてもなって気分になるわけで。

**デフォルトの名無しさん** · 2022/08/21(日) 21:17:28.45

行動経済学あるある
実験前の説明では「原理的にはどっちを選んでもOK」と言う
実験後「経済的にはこっちを選ぶのはバカ」と言い出す

**デフォルトの名無しさん** · 2022/08/21(日) 21:53:47.95

話題の要件は「finalize()等の関数を呼び忘れていたらコンパイルエラーにすることができるかどうか」でいいんだよな
そして他の言語ではそれを実現できなくて「Rustで実現できるか否か」という話でいいんだよな

それならば現行のRustで実現可能　実行確認可能なソースコード
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=7086ce3b73ad74a5375e970c7dfc5951

fn main() -> std::io::Result<()> {
let foo = Foo::new("Hello, World!");
foo.finalize()?; // この行をコメントにするとコンパイルエラー
Ok(())
}

struct Foo { s: String, }
impl Foo {
fn new(s: impl Into<String>) -> Self {
Foo { s: s.into() }
}
fn finalize(self) -> std::io::Result<()> {
let mut me = std::mem::ManuallyDrop::new(self);
println!("Finalizing... {}", me.s);
drop(&mut me.s);
Ok(())
}
}
impl Drop for Foo { ...

**デフォルトの名無しさん** · 2022/08/21(日) 22:38:05.89

>>741
それ>>716に書いてあるリンクエラーのコードを改変したんだとおもうが
let fooとfoo.finalize()の間に処理挟むだけでリンクエラー発生する

**デフォルトの名無しさん** · 2022/08/21(日) 22:51:41.20

使い勝手を含めて改善すべき点はあるから
それらはRustコンパイラが直接サポートすることで解決すればよい
例えば>>741でも用いているManuallyDropはコンパイラサポートによりその機能を実現している

**デフォルトの名無しさん** · 2022/08/21(日) 22:54:16.54

リンクエラーってコンパイルエラーではなくない？

**デフォルトの名無しさん** · 2022/08/21(日) 22:56:51.95

この人これで日曜日丸1日潰したのかな

**デフォルトの名無しさん** · 2022/08/21(日) 23:03:08.26

proc-macro作るとかclippyのlint追加するとかそういう方向性ならやりようはあるんでないの

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

型情報必要だからproc-macroは無理そう
compiler-pluginでなんとかしてくれ

**デフォルトの名無しさん** · 2022/08/21(日) 23:07:11.79

コンパイラがサポートすればリンク使わずに済むから真のコンパイルエラーとなるのでプロトタイプとしてはいいんじゃない

**デフォルトの名無しさん** · 2022/08/21(日) 23:13:22.78

実用上は実行前に検出できれば良いのでリンク時エラーでも問題ないとは思うけど
リンクまでしないcargo checkやrust-analyzerやclippy等で検出できないという違いはあるから
コンパイルエラーとリンク時エラーは区別はした方が良いだろうね

**デフォルトの名無しさん** · 2022/08/21(日) 23:26:12.30

Rustではコンパイラ対応で完全版も実現できる見込みが立ったようだけど
他の言語ではどうなの？

**デフォルトの名無しさん** · 2022/08/21(日) 23:31:54.00

https://yoshitsugu.net/posts/2021-02-13-linear-haskell.html

Haskellはもうできるってさ

**デフォルトの名無しさん** · 2022/08/21(日) 23:38:38.83

>>743
使い勝手の問題に矮小化すんなよ
根本的に使えないじゃん

**デフォルトの名無しさん** · 2022/08/21(日) 23:43:44.98

>>742
確かに5行目に関係ないprintln!入れるだけでもエラーになる
何で？？

**デフォルトの名無しさん** · 2022/08/21(日) 23:46:14.60

>>751
関数型言語らしい観点からの拡張だね
Haskell側でもRustのborrow checkerについて言及してる点も興味深い
でもそのHaskellの拡張で今回のfinalize未呼び出し検知を静的に実現できるの？

**デフォルトの名無しさん** · 2022/08/21(日) 23:54:38.26

そもそものアプローチが間違ってるから
他の言語でどうこう言っても意味がない

**デフォルトの名無しさん** · 2022/08/21(日) 23:59:27.31

>>753
そこで関数呼び出しなどがあると
panicなどで巻き戻される時にfooを解放する必要があるためdropを必要とするからかな
コンパイラが直接サポートすればそこは区別できるしリンク方式を取らなくてもよいから大丈夫じゃないかな

**デフォルトの名無しさん** · 2022/08/22(月) 00:06:59.32

でもコンパイラはお前のこと嫌いって言ってたしサポートしないんじゃない？

**デフォルトの名無しさん** · 2022/08/22(月) 00:20:24.88

そもそものアプローチというか
エラーが起きない時か気にしなくてよい時　→　デストラクタによる自動処理任せでOK
エラーやその有無を必ず欲しい時　→　flushやcloseなど自分で呼べばエラー取得できる

とはいえそれさえ書くのを忘れた時に
Rustコンパイラがコンパイルエラーとする機能も持てそうだとわかったから
さらなる機能向上に期待

GC言語はデストラクタによる自動処理すらないからそれ以前の問題だし
後始末の処理や指示を忘れてもエラーとならないし
忘れてクローズされていないファイルディスクリプタが多数溜まっていくこともよくあるｗ

**デフォルトの名無しさん** · 2022/08/22(月) 01:49:28.39

>>758
>Rustコンパイラがコンパイルエラーとする機能も持てそうだとわかったから
持てそうじゃないって
Drop Obligationとは全く異なるフロー解析が必要になるからゼロから作る新機能だよ

**デフォルトの名無しさん** · 2022/08/22(月) 07:51:24.23

>>756
その仮説で正しそうだが念のため確認してみた

まず>>741の通りだとdrop()を呼び出さずに当然コンパイルが通るので
何でもいいから関数呼び出し(演算含む)するものを間に挟んでみた
　let foo = Foo::new("Hello, World!");
　println!("test"); // ←ここに挿入
　foo.finalize()?;
するとこの形はdrop()を呼び出ように変化するようでリンクエラーとなる
この関数呼び出しはfooの参照を使うか否かに関係なく同じ結果

ところがfoo生成前に置くとコンパイルが通る
　println!("test");
　let foo = Foo::new("Hello, World!");
　foo.finalize()?;

さらにfoo消滅後に置いてもコンパイルが通る
　let foo = Foo::new("Hello, World!");
　foo.finalize()?;
　println!("test");

したがってfooが有効な期間に何か関数呼び出しがそこで起きる時のみ
drop()が呼ばれるコードが用意されてリンクエラーとなっている
これはRustがpanic時もメモリ解放をきちんと扱う話とも合致する
つまりpanic時の巻き戻し時のfoo解放をコンパイラが用意している仮説で正しいようだ

**デフォルトの名無しさん** · 2022/08/22(月) 08:10:55.66

>>759
そのような別のフロー解析は不要

Rustコンパイラは常に正しくメモリ解放を行うために所有権が尽きてdropを呼び出すべきところを全て把握している
それとは区別する形で>>760のようにpanic時の巻き戻し時のdrop呼び出しも正解に把握している
したがって以下のように検出できる

・finalize()をどのパスでも常に忘れずに呼び出しているコード
　　→　非panic時のdropは必ずfinalize()内のみで起こる

・finalize()を呼び忘れているパスが存在するコード
　　→　非panic時のdropがfinalize()以外で起こる　→検出

よってRustコンパイラは新たな仕組みを必要とせずに
現在把握している情報のみでfinalize()呼び忘れを検出可能
容易に対応できることが確認された

**デフォルトの名無しさん** · 2022/08/22(月) 10:01:20.83

つまり現状はできないってことw

**デフォルトの名無しさん** · 2022/08/22(月) 17:26:44.21

>>760
これってつまりリソース確保してから通常想定されるdropの位置までの間にある
すべての関数呼び出しの panic の可能性を考慮しないといけないから実用不可って事にならんか。

まだ try ... finally ... の方が実用的やないか。

**デフォルトの名無しさん** · 2022/08/22(月) 19:22:34.50

正解

**デフォルトの名無しさん** · 2022/08/22(月) 20:08:33.05

>>763
大きな誤解をしているようだが
C++やRustなどは関数(正解にはブロックスコープ)を抜ける時に常にデストラクタ(dropなど)を呼んでいる
これが即座のメモリ解放でありC++やRustが高速に動作するな理由
ただしC++でもRustでも所有権が移動したときにはそのデストラクタを呼ばず移動先に委ねられる

以上の基本事項の上でC++の例外やRustのpanicなどが起きたときには
関数呼び出しを自動的に多段に巻き戻して各々のメモリ解放つまりデストラクタ呼び出しをする
これは所有権が移動する場合でも移動する前に例外やpanicが起きればデストラクタが呼び出される
それが>>760のfooの生成と移動の間に挟まれたときのみデストラクタ(drop)が呼び出される仕組み

これらは全てコンパイル時点で静的に簡単に確定するため複雑さはなく実行時の余分なコストも発生しない
ここまでの話は現状のC++/Rustコンパイラがやっている普通のことである

>>761のfinalize記述忘れをコンパイルエラーとする新機能の話は
上述した現状の仕組みをそのまま活用できるため
その新機能を付加することがたやすいというだけの話だろう

**デフォルトの名無しさん** · 2022/08/22(月) 21:09:18.36

複製おじさんがまーた嘘ついてる

Rustが所有権(=dropする義務)をどう管理してるか知りたければ
“Drop Obligations”でググるといいよ

**デフォルトの名無しさん** · 2022/08/22(月) 21:19:17.98

>>763
try ... finally ... を書かなきゃいけない時点で大きく負けてるやん
RAII言語は何も書かずともデストラクタで自動処理される
そのデストラクタでエラーが発生する可能性がある時にfinalize呼び出しを強制させる選択肢も用意する話が今のテーマ

**デフォルトの名無しさん** · 2022/08/22(月) 21:21:32.89

>>765
それってコンパイラがどのAPIがfinalizeが必要か必要ないか全て把握してないといけないよね。
OS毎に低レベルAPIなんて異なるし組込み向けだってあるだろうし、無理じゃね？

**デフォルトの名無しさん** · 2022/08/22(月) 21:33:37.66

>>766
Drop obligationsはその話と関係ないじゃない？
RustコンパイラDevelopment Guideを見ても "Drop obligations" は変数の構造つまりenumやstructの中身とそのフィールド連鎖などについての話

**デフォルトの名無しさん** · 2022/08/22(月) 21:47:48.22

>>765
いや、その付加した機能が実用にならないねという話をしたんだが。

**デフォルトの名無しさん** · 2022/08/22(月) 21:49:45.94

>>768
みんなが一貫してずっと型の話をしているのに唐突にAPIとか場違いの話を出すのはヤバいな
finalize呼び出しを義務付ける型は>>713の方式ならばFinalize trait実装型と書かれている
あるいは>>743のManuallyDropのようにラッピング方式での指定の可能性もありうる
いずれも明白に宣言を伴うためコンパイラにとってもプログラマーにとっても明瞭に区別できる

**デフォルトの名無しさん** · 2022/08/22(月) 21:56:10.02

>>770
実用的じゃないとはどういう意味だ？
現行でも実用的になっているコード（明示的に書けばエラーを捕捉できて、書き忘れてもデストラクタで自動実行される）に対して
書き忘れを防止できる選択機能を新たに用意しよう、という話だろ

**デフォルトの名無しさん** · 2022/08/22(月) 21:57:46.65

>>769
関係ないわけないやん複オジw

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

>>773
複オジって何

**デフォルトの名無しさん** · 2022/08/22(月) 22:32:14.28

finalize強制の話は7年前から線形型として提案はされてる
具体的なユースケースとしてFinalizeトレイトなんかも出てるし

https://github.com/rust-lang/rfcs/issues/814

ただまぁ大改造だし他にやることもたくさんあるから当分検討されることはないだろうな

**デフォルトの名無しさん** · 2022/08/22(月) 23:20:29.01

zenは急げ

**デフォルトの名無しさん** · 2022/08/22(月) 23:32:48.78

>>772
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f27f2dc5668cded5f61f8f23e030df61

本当はこういうことがやりたかったんだろ？
newとfinalizeの間に一切コードが書けないんじゃ使い道が皆無

もともと「スコープ終端でのdropまでに特定の関数を呼び出していない場合コンパイルエラー」にしたいだけだったのが
「newした直後に特定の関数を呼び出していない場合コンパイルエラー」という厳しすぎる条件になってるのが問題

**デフォルトの名無しさん** · 2022/08/22(月) 23:35:51.97

>>775
そこに書いてる実現方法でも現実的だけどそれでも相当大変そうだね
各種API変更まで考慮すると費用対効果的に無さそう

**デフォルトの名無しさん** · 2022/08/22(月) 23:43:22.53

>>777
間に別の処理を入れてもエラーが起きないようにしたコードかと思って試しちゃったじゃないかw

**デフォルトの名無しさん** · 2022/08/22(月) 23:47:06.94

費用の問題というのも間違い
安くすれば需要がどんどん増えると思ったら大間違いだよ

**デフォルトの名無しさん** · 2022/08/23(火) 00:19:09.94

>>777
> newとfinalizeの間に一切コードが書けないんじゃ使い道が皆無

なぜそんな自虐的な設定を勝手に設けているの？
この話の発端は>>686だと思うけどそんな制限ないし
ここ最近に出ているコンパイラ拡張提案でもそんな制限した案はないよ

**デフォルトの名無しさん** · 2022/08/23(火) 00:38:06.00

そういえばHaskellのLinearTypesのやつ自分で試してから貼ろうと思ってたけど
実際hCloseを消したり2回呼んだりして出てきたエラーメッセージで検索したら
同じことやってた記事があったんでもうこれ貼ればいいやってなった

https://scrapbox.io/mrsekut-p/%E7%B7%9A%E5%BD%A2%E5%9E%8B%E3%81%A7%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9%E7%AE%A1%E7%90%86%E3%82%92%E3%81%99%E3%82%8B%E4%BE%8B

**デフォルトの名無しさん** · 2022/08/23(火) 00:51:58.53

>>781
>>741に聞けば？

**デフォルトの名無しさん** · 2022/08/23(火) 01:09:26.07

>>783
それは未対応の現在のコンパイラでの話だよね
そんなことも区別つかないの？

**デフォルトの名無しさん** · 2022/08/23(火) 01:19:05.91

>>784
うん区別付いてない
その「対応」は具体的に何を指して言ってる？
>>775の線形型のpre-RFCのこと？

**デフォルトの名無しさん** · 2022/08/23(火) 01:31:34.47

>>783
ヒント: 781 == 741

**デフォルトの名無しさん** · 2022/08/23(火) 02:13:39.19

現状ではどの言語でも実現できていない話と、
新たに新機能追加／拡張を考えようという話の、
区別がついていないというよりも、
現状では出来ていないと叩いたり制限があると叩いたり、
ものごとの理解ができないキチガイか文句をつけて叩ければいいアンチのどちらか

**デフォルトの名無しさん** · 2022/08/23(火) 02:47:14.79

SFCエミュを2ヶ月くらいで組んでるから
Rustの生産性が低いって事はなさそうね
https://zenn.dev/tanakh/articles/nes-and-snes-emulator-in-rust

**デフォルトの名無しさん** · 2022/08/23(火) 02:49:40.76

いや1ヶ月か

**デフォルトの名無しさん** · 2022/08/23(火) 07:50:29.67

やっと出てきたのがファミコンのエミュかあ

**デフォルトの名無しさん** · 2022/08/23(火) 08:28:00.41

つまり複オジは反省しない嘘つき常習犯

**デフォルトの名無しさん** · 2022/08/23(火) 11:42:15.69

>>782
さすがHaskellさん

**デフォルトの名無しさん** · 2022/08/23(火) 12:20:50.32

この人何回もゲーム機エミュ書いてるからこの人の事例で言語の生産性は測れないよ。

絵師()みたいな人がよく言う
「これまでの人生+10分なんです」
と同じ。

**デフォルトの名無しさん** · 2022/08/23(火) 12:30:30.94

>>793
何回も書いてるなら
他の言語で書いた時と比較すれば多少は参考になりそうだけど

**デフォルトの名無しさん** · 2022/08/23(火) 12:39:54.59

>>794
書くたびに習熟度が上がるからダメ
記憶をリセットしないと

**デフォルトの名無しさん** · 2022/08/23(火) 12:40:44.01

Rustの生産性が高い原因はプログラミングの書きやすさとコンパイル時点で確定保証されることの多さ

**デフォルトの名無しさん** · 2022/08/23(火) 12:43:43.35

ISUCONでGoに匹敵するぐらい入賞チーム増えてきたらどんな用途でも生産性が高いと証明されるな

**デフォルトの名無しさん** · 2022/08/23(火) 12:57:16.80

>>797
限られた時間内で場当たり的な対応をどれだけこなすかを競うISUCONは現実と離れすぎていてあまり意味がない
もちろん欠陥だらけのシステムの数々の問題点を見抜いて各々に対応する能力は非常に重要
現実にはその能力は安全かつ高速なシステム設計開発に使うものであり短時間での場当たり的な対応に競うものではない

**デフォルトの名無しさん** · 2022/08/23(火) 13:33:30.00

時間は正しく計測できるという仮定の下で
「時間が短過ぎる」等の判断をすることもまた現実から乖離していることがよくある

数年前の過去問と同じ問題がテストに出れば、時間は数年間あってもそれを計測する時計はない

**デフォルトの名無しさん** · 2022/08/23(火) 13:45:48.88

知識を問うテストじゃないはずなのに、ある特定の知識を知ってる人だけがサクッと解けるようなテストだったら、それは問題が悪問なだけ
出題者が悪い

**デフォルトの名無しさん** · 2022/08/23(火) 13:55:00.75

良問を出すべきというのは道徳か？
富裕層は貧困層に寄付するべきと言ってるのと同じ？