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

**デフォルトの名無しさん** · 2021/11/28(日) 16:59:19.16

スレタイ以外の言語もok

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

**デフォルトの名無しさん** · 2022/03/20(日) 01:44:23.98

>>888
比較対象がおかしいんじゃなくて、お前が無知なだけｗ
.NETはSynchronizedContextというのでスレッドのスケジューリングを調整できる
そして、GUIとコンソールでこのスケジューリングが違うから、GUIを出したんだよｗ
同じことをコンソールアプリでやってもデッドロックしないｗ
つまりあえておかしいのが何かを選ぶならお前の可哀想な頭ということになるｗ

**デフォルトの名無しさん** · 2022/03/20(日) 08:46:38.88

>>889
おかしいのはお前の頭だ馬鹿タレ
881は

int main() {
sleep();
return 0;
}

でアプリケーションが終了しない！デッドロックだ！と騒いでいるに等しい。

ぼくのすごいあぷりけーしょんのばぐはぜんぶすたてぃっくにけんしゅつされるべき
このていどすらぼくには「わかりにくいでっどろっく」なのだから！

と思うのなら、GoやRustを使っておけ。
C#は実用言語であって、一通りすら書けない馬鹿を救済しようとはしていない。

一般的に、ロック周りの難しさは再現性が低い事にある。
偶々同時にアクセスした時にのみバグるので、
初心者の「一度動いたから問題なし」ではバグを取りきれない。
そのコードなら必ず再現する＝再現率100%のバグを修正出来ないのはそいつの問題だ。
(881のバグは静的には検出出来ないのかもしれんが、動かせばすぐ分かるし、すぐ修正出来る）

一般的に難しいとされるバグは、データ依存性が有り、特定のデータ組でしかバグらないものだ。
そしてロック周りなら、データ依存性＋タイミング、となるので、さらに発見も遅れるし、
見た目動くし、実際99%以上の場合で全く問題ないしで、場所の特定が困難になる。
お前以外はこの前提で話していただろうよ。

**デフォルトの名無しさん** · 2022/03/20(日) 10:31:18.90

>>889
あと881については「Task.Waitの代わりにawaitを使え」とモロクソにドキュメントに書いてある。
(884が指摘してるのはこれだろう)

> タスクを待機するコードは非ブロッキング方式で作成します
> Task が完了するのを待機するための手段として現在のスレッドをブロックすると、
> デッドロックおよびコンテキストスレッドのブロックが発生するおそれがあり、複雑なエラー処理が必要になることがあります。
> 次の表では、非ブロッキング方式でタスクの待機に対処する方法について説明します。
> これを使う/これは使わない/行う処理
> await/Task.Wait または Task.Result/バックグラウンドタスクの結果の取得
> await Task.WhenAny/Task.WaitAny/任意のタスクの完了の待機
> await Task.WhenAll/Task.WaitAll/すべてのタスクの完了の待機
> await Task.Delay/Thread.Sleep/一定期間の待機
> https://docs.microsoft.com/ja-jp/dotnet/csharp/async

フレームワークには要求されたコードを書く必要があって、好き勝手書いていいわけではない。
ある程度の腕前があるつもりならドキュメントを先に読んだ方が正解だぞ。
（そもそもそんなコード書く必要すらないが）
それ、コンソールアプリなら(コンパイラがフォローしてくれた結果)動くだけの気がするが。

**デフォルトの名無しさん** · 2022/03/20(日) 11:59:41.08

GUIアプリだとWPFとかがメッセージループ回してくれる

コンソールアプリだとメッセージループがないからそもそもの土台が違うだけでしょ
GUI周りの制限とかもないだろうし

もしかしたらメッセージループを自前で回せばasyncとかのデッドロックをコンソールアプリからもできるかもしれん

**デフォルトの名無しさん** · 2022/03/20(日) 12:01:25.59

>>881
へんな例え出して突っ込まれてるお前好き！

**デフォルトの名無しさん** · 2022/03/20(日) 12:05:49.90

awaitが使用できないシチュエーションにしてる上に、引数なしのsleep()なんて存在しない上に仮にそれが永久スリープだとして、そういう現象ではないｗ
非常に自然な使い方なんだよｗ
またこの例は簡単＆再現性100%を挙げただけで、合せ技で再現性低のすごい分かりにくいバグ(終わらないスレッド)を混入させられるｗ
そしてその自然な使い方がNGであることがドキュメンテーションされていないとは一言も言ってないｗ
モデルが悪いと言っているｗ
だからお前はバカだと言われるんだよｗ

**デフォルトの名無しさん** · 2022/03/20(日) 12:08:13.64

>>892
書いたとおり、SynchronizedContextにより、await後のスレッドが何になるか？って話だ
コンソールとGUIで違う

**デフォルトの名無しさん** · 2022/03/20(日) 12:12:12.26

名前覚え間違ってたｗ
SynchronizationContext なｗ

**デフォルトの名無しさん** · 2022/03/20(日) 12:14:20.56

次世代言語にC#が名乗りを上げたのか？

**デフォルトの名無しさん** · 2022/03/20(日) 12:23:10.62

知らねーよｗ C#を引っ張り出してきたのは俺じゃないｗ

**デフォルトの名無しさん** · 2022/03/20(日) 12:36:36.62

>>894
まあとにかく君にはGoやRustがいいと思うよ。
どんなかきかたをしてもこんぱいるがとおりさえすればぼくのあぷりけーしょんにはばぐがないことをほしょうしてくれないといや！なんだろ。

既に言ったとおり、
フレームワークは一般的に「こう書け」と要求してるとおりに書かないと誤作動する。
async/awaitにてTask.Waitを使うなとはドキュメントに書いてあり、一般的にはそれで十分だ。
そもそもasync/awaitは細かく動作タイミングを指定する為の物ではないので、通常はそんなことしないし。

>>892
一応SynchronizationContextを弄くれば、
メッセージループやasync/awaitでのスレッドプールでの動作とかも変更出来るらしい。(override)
> https://devblogs.microsoft.com/dotnet/configureawait-faq/
ただ普通は必要ないからしないと思うが。
Forms/WPF/WinRTで異なるとは書いてある。
コンソールでどうなのかは知らんが、881のコードでも動くモデルが差し込んであるのだろう。
ただそれは間違ってるコードが偶々動いてるだけの気がするが。

**デフォルトの名無しさん** · 2022/03/20(日) 12:44:20.26

ここまで書いてやってもまだ理解できてないのか・・・
await後に元のスレッドで再開するのがGUI用のSynchronizationContext ｗ
だから、Task.Waitを同期的にやると同じスレッドなのでデッドロックする
GUIだとUIスレッドでawaitしたら復帰したときに同じUIスレッドで処理したいからそうする
コンソールだとそういう縛りがないから、await後は別のスレッドになる可能性がある(典型的には使用中なら別のスレッド)ｗ
それだけｗ
こんなこと言われないと分からないのなら、お前はC#を「使えていない」ｗ

**デフォルトの名無しさん** · 2022/03/20(日) 12:49:33.87

馬鹿はなぜ周りから馬鹿扱いされているか気が付かないからバカなんだ
周りが馬鹿なんじゃなくて本質的に理解してないでデッドロックがどうこう書いてくる

**デフォルトの名無しさん** · 2022/03/20(日) 12:50:34.94

周りが馬鹿なんじゃなくて本質的に理解してないでデッドロックがどうこう書いてくる人間が馬鹿

**デフォルトの名無しさん** · 2022/03/20(日) 12:56:56.16

ぼくちゃんたちには難しくて分からなかったかもねｗ
ぼくちゃんたちの頭が悪いのまで俺のせいにされても困るｗ

**デフォルトの名無しさん** · 2022/03/20(日) 13:06:31.37

C#とWPF使うとデッドロックが起こる！簡単には使えない！

GoとRustでCUIでやればデッドロックが起こらない！簡単だ！

↑馬鹿すぎますよね？

**デフォルトの名無しさん** · 2022/03/20(日) 13:09:30.45

バカの自己紹介ほどツマラナイものはないなｗ
.NETは玉石混交の継ぎ接ぎだらけでモデルが悪いと言ってるだけなんだがｗ

**デフォルトの名無しさん** · 2022/03/20(日) 13:11:24.97

この人がスゲー馬鹿なのは同意してくれないの？

876 名前：デフォルトの名無しさん[sage] 投稿日：2022/03/19(土) 00:33:29.03 ID:DslNhsx1 [1/4]
C#とGoとRustならGoでいいと思うけど…一番ラクじゃん
C#なんてTask.Delay()の代わりにThread.Sleep()使うだけで簡単にデッドロックするよｗ

**デフォルトの名無しさん** · 2022/03/20(日) 13:14:29.87

お前がバカなだけｗ

**デフォルトの名無しさん** · 2022/03/20(日) 13:25:26.04

>>900
それで君がC#を使えている事にもならないとは思うがな。

プログラミング言語は一般的に「正しく書けば正しく動く」であって、
「間違った使い方をした時にもそれなりに動く」事は期待されてない。
これが707で言った「自分の足を撃てるか」で、C#については、

> You forget precisely how to use the .NET interface and shoot yourself in the foot. You sue Microsoft for damages.

となっているが、君はまんまこれではないか。真っ当なら、

×　俺はSynchronizationContextの中身まで熟知しており、Task.Waitをコンソールアプリで使ってもフリーズしないと知っている。だから使う。
○　MSが「async/awaitではTask.Waitは使うな」と言ってるから、使わない。

だと思うが。

**デフォルトの名無しさん** · 2022/03/20(日) 13:39:56.48

アホだなｗ
じゃあUIイベントをasyncメソッドで受けてawaitしてからUI処理すんなよｗ
俺が言ったこと(await後のスレッドの話)はC#使えるやつなら基礎として知ってることなんだよｗ
知ってないとawaitしてUI処理できんからｗ
逆にTask.Waitがスレッドをロックしてしまうブロック処理かどうかはよく読まないと知らないことｗ
でも有名な話だからまともにC#使える人なら皆知っているけどねｗ
特定の状況でしか必要にならないから、await後でデッドロックすることがある、ということしか知らず、へぇ～コレか～という形になる人が稀にいる程度ｗ
なので、
○　俺はGUIアプリでawait後に元のスレッドで継続することと、コンソールアプリでは別スレッドになることがあることを知っており、だからC#を使える
×　俺はMSが「async/awaitではTask.Waitは使うな」と書いてあることを知っており、だからC#を使える
ってことだｗ

**デフォルトの名無しさん** · 2022/03/20(日) 14:07:36.11

>>909
そうじゃない。

何度も言ってるが、フレームワークはフレームワーク製作者が要求したとおりのコードじゃないと駄目なんだ。
これはどのフレームワークでもそう。
MSが「async/awaitではTask.Waitは使うな」と言ってるのだから、これに従う限り、
Task.Waitを混ぜた時の動作については知る必要はない、というのが一般論。

フレームワークにデタラメなコード（＝製作者が予期してないコード）を食わせたらどうなるか、を把握する為には、
フレームワークの中身まで知る必要がある。
一々こんな事をしてたら生産性なんて上がらないし、正しく使っている限り必要ないから、
一般的にはこれは要求されない。
だからお前の考え方は根本的にずれてるよ。

例えばHTML、これはWeb系に於いての暗黙のフレームワークHTML/CSS/JavaScriptの一角を担ってるわけだが、
実はデタラメなHTMLでもブラウザはそれなりには表示してしまう。
だからといって、「デタラメなHTMLを食わせた時にどう動くかを把握して、デタラメなHTMLを書いてもいい」とはならんし、
「デタラメなHTMLを食わせた時の各ブラウザの挙動を把握してこそWebを『使える』と言える」ともならんだろ。
「正しいHTMLを書け」で終わりだ。

ただまあこれはもう平行線だし、これについての俺の主張は上記だから、これで終わりでいい。
C#のモデルが悪いというのなら、
「MSが正しい使い方だと認めるコードでも容易にデッドロックが発生する事例」を持ってくるべきだ。
間違ったコードでフリーズしたところで、あっそう、でしかない。
一般的にはそんなのを書く奴が悪いとされるし、C#でも実際そうだと思うよ。

**デフォルトの名無しさん** · 2022/03/20(日) 14:19:36.23

お前が頓珍漢な主張を繰り返しているだけだろｗ
仕様通りの使い方が出来ているかどうかという話をしておらず、その仕様の出来が良いか悪いかの話をしているんだろうにｗ
理由はそういうスレだからｗ
俺はそういう話をするために事例を出し、.NETのモデルの悪さを指摘したｗ
ただ、その原因すらお前が理解していないようだから、一般常識レベルの説明をしただけだｗ
一応言っておくが、俺は使用するAPIはドキュメントを全て読んでから使用しているｗ
でもそんな話は今していないんだｗお前が言ってることが周回遅れすぎてるだけｗ
というかC#すら分かっておらず、当該言語もよく知らない上にスレの主旨も理解できてないなら口出してくんなｗ

**デフォルトの名無しさん** · 2022/03/20(日) 14:26:39.18

デッドロックの話ならGoなんてチャネルの扱いを間違えたら簡単にデッドロックするでしょ
C#もGoも両方プロダクションでそれなりに使い込んでるけど、感覚的にはGoの方が遥かにデッドロックを起こしやすいよ

**デフォルトの名無しさん** · 2022/03/20(日) 14:35:25.89

>>911
> その仕様の出来が良いか悪いか
フレームワークは『使い方』も含めて仕様なんだよ。

>>912
Goはチャネルの使い方を間違えればすぐデッドロックする。
(だからRust信者かな？とも思うのだけど)

ただしGoの出来が悪いわけではなく、
単に、「何であれ、スレッド間の同期を取ろうとするとデッドロックしやすい」ので、
C#ではasync/awaitでユーザーが同期周りを一切書かなくて済むようにしただけで、
自分で書けばGoと同程度にデッドロックするとも思うよ。

**デフォルトの名無しさん** · 2022/03/20(日) 14:41:39.54

rust - Mutexのロックが解除されない
https://ja.stackoverflow.com/questions/60337/mutex%E3%81%AE%E3%83%AD%E3%83%83%E3%82%AF%E3%81%8C%E8%A7%A3%E9%99%A4%E3%81%95%E3%82%8C%E3%81%AA%E3%81%84
Golangでデッドロックを作って遊んでみる
https://www.asobou.co.jp/blog/web/deadlock

**デフォルトの名無しさん** · 2022/03/20(日) 14:50:44.84

なるほどね
・チャネルを使わない
・ロックを使う場合のロック順序は守る
という制限があっても簡単にデッドロックが起きてしまうのがC#という結論かな

**デフォルトの名無しさん** · 2022/03/20(日) 14:59:33.25

>>914
その回答を見てもわかるように
RustではMutexなどのロックはそのブロックを抜けると自動的に解除されます
だからその質問のプログラムがそのロックしたブロックを完了していないというバグだということが今回の例でもすぐわかるわけです

**デフォルトの名無しさん** · 2022/03/20(日) 15:03:54.72

channelでデッドロックするのはよほど使い方悪いだけだろｗ
プロダクトでそれはありえないｗ
channelを使わずにmutex使うとかバカとしか言いようがないｗ
mutexなどの同期リソースを手動で使う場合は、どんな言語でも細心の注意を払わないとデッドロックなどのバグが発生するｗ
goのchannelはgo固有ｗ
IPCの接続をsocketと呼ばずにchannelと呼ぶフレームはあるけどねｗ

**デフォルトの名無しさん** · 2022/03/20(日) 15:07:57.75

まあでも並列動作で一番厄介なのはMutexを使わずにatomic readを期待しちゃった系読み書きのバグかなｗ

**デフォルトの名無しさん** · 2022/03/20(日) 15:13:13.79

デッドロック起きないことを保証できたらまさに次世代言語って感じがするな
そんな言語あるのかは知らんが

**デフォルトの名無しさん** · 2022/03/20(日) 15:20:14.57

非同期プログラミング(async/awaitなど)は正にその辺を狙った技術だよｗ
非同期処理完了の戻り値としてデータ授受をすることで複数スレッドからのデータアクセスの同期処理をなくしやすくしているｗ
保証するものじゃないし、する必要もないけどｗ

**デフォルトの名無しさん** · 2022/03/20(日) 15:24:25.24

>>917
> channelを使わずにmutex使うとかバカとしか言いようがないｗ

それは失言です
データ読み書き競合をchannelで防ぐことは出来ません
mutexなどのロックが必要となります

**デフォルトの名無しさん** · 2022/03/20(日) 15:28:04.92

lock要求された順番を検証して、
順序にループがあればlock要求時にthrowする仕組みは作れそう

lock/unlockのたびに全threadのlock状況を検証する必要があるからパフォーマンスがお察しになるが

**デフォルトの名無しさん** · 2022/03/20(日) 15:39:08.57

>>915
どの言語でも、間違った使い方をすればデッドロックはする。

（Task.Waitなどを使うという、明らかに間違った事をせず、）
async/awaitだけで(ジョブ間に依存性がないように)書けばデッドロックしない。
これはC#でもJSでも他言語でも同じのはずだけど。

ID:1+CNf8az だけが
まちがったつかいかたもできるし、それがぼくにとってはわかりにくいからもんだいだ！！！
と言ってるだけ。

**デフォルトの名無しさん** · 2022/03/20(日) 15:39:50.43

>>921
何を言ってるの？？？？
共有データを作らないためのchannelではないの？
channelだけではどうしても無理な場合だけmutex使って共有データにアクセスするだけだろｗ
まずは例を出せｗ

**デフォルトの名無しさん** · 2022/03/20(日) 15:42:03.81

>>923
お前がお味噌なだけｗ
俺も含め誰もそんな話はしてないｗお前が無知だっただけで僻むなｗ

**デフォルトの名無しさん** · 2022/03/20(日) 15:45:30.35

>>922
function method1() { lock(objA) { lock(objB) {
処理;
}}}
function method2() { lock(objB) { lock(objA) {
処理;
}}}
みたいなmethod1とmethod2が別のスレッドで同時に動いたときにデッドロックする

**デフォルトの名無しさん** · 2022/03/20(日) 16:07:28.81

>>926
バカなのか？
そのコードは皆が共通して言ってることすら守れていない

>>915
> ・ロックを使う場合のロック順序は守る

>>922
> lock要求された順番を検証

**デフォルトの名無しさん** · 2022/03/20(日) 16:12:06.86

>>927
バカはお前ｗデッドロックを検出することは可能だが、順序がループするわけではないｗ

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

順序がループ？w

**デフォルトの名無しさん** · 2022/03/20(日) 16:28:20.05

>>929
>>922

**デフォルトの名無しさん** · 2022/03/20(日) 17:43:56.42

https://github.com/ghc/ghc/blob/d45bb70178e044bc8b6e8215da7bc8ed0c95f2cb/libraries/base/Control/Concurrent.hs#L643-L649
Haskellは参照されていない＝デッドロックしているスレッドをGCが検出しているらしい。素人意見ですが、もしかして他のGC言語も同じことをすると良いのでは？

**デフォルトの名無しさん** · 2022/03/20(日) 18:10:14.51

別にGCじゃなくても検出はできるよｗただのバグだから余計なコストがかかる処理を入れてないだけでｗ

**デフォルトの名無しさん** · 2022/03/20(日) 18:40:40.29

毎度毎度、c#もあんまり詳しくないよねこの人。
Rustは俺はわからんのだけど、c#とgoの話だとこの人が言ってんのは重箱の隅をつついて「これが大問題であるっ！！」って騒いでるような感じ。
まあGoでコンパイラ書いたらGCから逃れられないみたいなアホも居たわけだからアレなんだけど。

**デフォルトの名無しさん** · 2022/03/20(日) 18:48:20.78

>>933
GC言語はどうしてもそれ故の種々の制限があるからしょうがない
もちろんGC言語はその代わりに有利な面もある
そこへGC言語でないRustが初めてGC言語と対等に比較可能な存在として登場した
しかもGCのない有利さを保ったままで

**デフォルトの名無しさん** · 2022/03/20(日) 18:57:31.06

この人rustスレではc++に比べてrustはクソと
同じように知ったかぶりでトンチンカンな叩き
してるからまあこういうことやるのが目的なんだろ

**デフォルトの名無しさん** · 2022/03/20(日) 18:57:43.35

> そこへGC言語でないRustが初めてGC言語と対等に比較可能な存在として登場した

SwiftにもGCは無いよね
ARC(Automatic Reference Counting)でやりくりするんよね
Swift使っこと無いし完全に俺はニワカだけど

**デフォルトの名無しさん** · 2022/03/20(日) 19:14:52.51

>>934
Goでコンパイラ書いたらバイナリにもGCが入るっていう誤解の正当化？

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

>>936
C++とRustでも所有権を共有する時だけはARCと同じ方法を使っている
しかしC++とRustはそういう特殊なケースでのみ使用だからGC言語とは言われない
一方でSwiftは常にインスタンスに対してARCでメモリ管理をするため非常に重く効率が悪い
そしてARCが常に行われるということは参照カウント方式のGCそのものである
そのためSwiftは非GC言語とは言い難い

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

>>937
そのGo製コンパイラ自体はGCランタイムを含むしGCを起こすよ
他にもGoで記述して例えばWebAssemblyをブラウザ上で動かそうとすると
当然GCを含むGoの巨大なランタイムがWASM上でそのまま必要となるため
Goを使うと巨大で重くて遅い

**デフォルトの名無しさん** · 2022/03/20(日) 19:50:10.66

> そのためSwiftは非GC言語とは言い難い

https://docs.swift.org/swift-book/LanguageGuide/AutomaticReferenceCounting.html
> In systems that use garbage collection, (略).
> However, with ARC, (略).

ここでは「ガベージコレクションを使用するシステム」と「ARC」を対比させてるっぽいね
あと個人的にもやっぱりスマートポインタの一種でしか無いように見える
RustのRcといっしょ
循環参照はプログラマが頑張ってweak使ってなんとかしてね、ってのも
ただおっしゃるとおりRustはRcを全部に使うわけじゃあないからまた雰囲気も違うのは確か

**デフォルトの名無しさん** · 2022/03/20(日) 22:21:15.61

C++のshared_ptrやRustのRcは必要不可欠な最小限でしか用いないから必須なコストを払っているだけと言えるが
SwiftのARCは全てのインスタンスに適用されるから無駄なコストを浪費しているとしか言いようがない

**デフォルトの名無しさん** · 2022/03/20(日) 23:09:41.16

>>933
実際大問題だっつーのｗ
C#の非同期系の諸問題は大抵これが原因ｗ
ごく稀にスレッド間の同期(排他制御)が不足してる競合が原因のがあるって感じ
お前こそC#使った開発とか本当にしたことあるのか？ｗ

**デフォルトの名無しさん** · 2022/03/20(日) 23:37:15.53

あとgoについて何か文句を言ったことはないｗ

**デフォルトの名無しさん** · 2022/03/20(日) 23:38:33.20

なんかそういうデータあるんですか？

**デフォルトの名無しさん** · 2022/03/20(日) 23:47:54.68

どういうデータだよおバカさんｗ

**デフォルトの名無しさん** · 2022/03/20(日) 23:56:02.86

>>942
それは主にお前の問題だな

**デフォルトの名無しさん** · 2022/03/21(月) 00:04:44.37

>>946
仕事で作った数人ｘ半年レベルのWindowsアプリ(製品)の話だよｗ
全然違う分野のだけど、C#は1.xと2.0と4.6？で作ったかなｗ
なので俺の問題ではないｗ全員C#の練度はお前よりは上だったけどｗ

**デフォルトの名無しさん** · 2022/03/21(月) 00:15:23.07

>>939
そんな話はしてないが。

>>942
GUIじゃない部分で不用意にTaskを処理しようとすると死にがちよね。
コピペで毎回FireAndForget持って来て慎重に使ってるわw
ID:1+CNf8azの事ではないよ、ごめん。

**デフォルトの名無しさん** · 2022/03/21(月) 00:31:38.49

>>947-948
ならそれはお前らの技量が足りなかっただけだ。
そもそもデッドロックするかどうかは言語関係ないだろ。

新旧の仕様を混ぜて使えるようになってるのが落とし穴だ、というのなら、
それはそうかもしれんが、C#としてはそこをすぐに塞ぐのは無理だ。
それでRust使えば全く問題ない！と思うのならガンガン使ってみればいいだけ。
そんな単純な話ではないと思うけどね。

**デフォルトの名無しさん** · 2022/03/21(月) 00:58:46.04

>>949
俺は助っ人で行っただけだからなｗ
現象はデッドロックだけではないし、まあお前には想像もできないし、遭遇しても解決できないから安心しろｗ
そして何度でも言うが、彼らはお前よりはC#についての知見が遥かに多かったよｗ
デッドロックの話にピンと来ないC#erは初めて見たし、await後のスレッドの話、GUIにおけるUIスレッドの役割に対する見解の話、全ての話において、お前は最低限C#技術者に必要な知見を有していないｗ

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

小学生ですがみなさんの情報たいへんおもしろいです
でもどうして大人のひとってけんかばかりしてるのですか？

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

こんなところに来る小学生はあんまり小学生とか言わないで使いそうだけどなｗ
喧嘩なんてしなくて、じゃれ合ってるだけだからだよｗ

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

>>947
＞C#は1.xと2.0と4.6？で作ったかなw

古すぎだろ
最新はバージョン10だぞww

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

もちろん.NET Frameworkのバージョンだよｗ C#のバージョンなんて誰も覚えてないだろｗ

**デフォルトの名無しさん** · 2022/03/21(月) 09:13:23.58

>>950
それはやり方を間違ってるからおかしな事になってるだけ。
例えて言うなら、舗装道路が用意されてるのにイキって荒地を走行してパンクしてるようなもの。
天の邪鬼も自由だが、それでフレームワークや言語のせいにするのは違う。

**デフォルトの名無しさん** · 2022/03/21(月) 09:56:39.42

結局程度の低いプログラマーがC#が悪い！って言ってるだけだろ？
話を見てるだけでも.netのフレームワークも別に悪くない

C++で文字コードの扱いが悪いと言うならわかるけど…

**デフォルトの名無しさん** · 2022/03/21(月) 09:57:03.43

お前まだいたの？ｗここでの話は
・.NETのモデルは出来が悪い
・お前C#erに必要な最低限の知見がない
これだけだし結論出てんだよｗ

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

>>957
C#erって言葉を使ってるだけで相手を見下してるよね

Rustで同じ状況じゃ競合が起きないとかいうならわかるけどそういう話でもないし
あなたが勝手に出来が悪いと言ってるようにしか見えないんだから
出された例も馬鹿らしくて.NETのモデルも別に悪くないと思う

誰もあなたに同意できない
それだけの技量があなたにはない

他人を見下したり自分が悪いと思える謙虚さがないと低級プログラマにしかなれない

いい加減に静かにしてもらえないかな
それかどこか別に行ってやるか

**デフォルトの名無しさん** · 2022/03/21(月) 10:12:21.44

デッドロックに対応できないのは言語やフレームワークのせいじゃないだろ

実際にモデルが悪いのはそっちの設計の方だろ？

**デフォルトの名無しさん** · 2022/03/21(月) 10:38:31.66

まだ言ってるしｗｗｗｗｗ
普通にTaskをwaitするのがawaitなのにTask.Waitって名前でデッドロックする仕様はモデルが悪いとしか言いようがないだろｗｗｗｗ

**デフォルトの名無しさん** · 2022/03/21(月) 10:39:34.38

謙虚さとかプログラマには要らないからｗ
色眼鏡かけてなければ問題ないよｗ

**デフォルトの名無しさん** · 2022/03/21(月) 11:52:23.94

>>961
謙虚さがないからおまえみたいに色眼鏡かけるようになるんだよ。少しは学べよ。

**デフォルトの名無しさん** · 2022/03/21(月) 11:56:12.36

ろくに調べもしないで不具合だしてるだけじゃん
名前で判断するなよ

**デフォルトの名無しさん** · 2022/03/21(月) 12:07:23.76

色眼鏡かけてるのはお前だけだよｗ
公平に見るために謙虚さはむしろ要らないｗ
謙虚にすると周囲に合わせることになり、自分の意見が100%反映されなくなるｗ
迎合してエコーチェンバーの一部になると、色眼鏡をかけることになり、公平な判断は出来なくなるｗ

不具合出したわけではなく、.NETのモデルが悪いだけｗ日本語不自由なんだねｗ

**デフォルトの名無しさん** · 2022/03/21(月) 12:20:03.99

Tas.Waitでデッドロックする条件分かってんだからライブラリ側で例外投げてくれよとは思うが

1ライブラリのクソ要素を根拠に言語自体をクソと言い張る思考には感心するよ

**デフォルトの名無しさん** · 2022/03/21(月) 12:38:23.15

C#をクソと言ったことはないぞｗ日本語不自由さには事欠かないねｗ
マルチスレッド同期機構と非同期処理を言語で比較する話で、やれデッドロックがどうのと言っており、かつC#が良いという結論を出していたので、>>876で.NET Frameworkのモデルの悪さを指摘し、goでいいのでは？と言っただけだろうにｗ
話を続けた結果、彼は案の定デッドロックの話を把握しておらず、Task機構についても誤解しており、await後のスレッドについても知見がなかったので、彼の知見は一般のC#erに劣るという結論を出しただけｗ

**デフォルトの名無しさん** · 2022/03/21(月) 14:48:44.25

いい加減に辞めたら？

それを持ってライブラリのモデルが悪いと言うのは変じゃないか
あなたの主張が誰一人説得できないのはあなたの問題であってスレの住人の問題じゃない

**デフォルトの名無しさん** · 2022/03/21(月) 14:55:29.99

次スレでも不毛な話が続く予感

と言うか最初からこのスレは不毛地帯だった

**デフォルトの名無しさん** · 2022/03/21(月) 18:06:00.78

こんなに分かりやすいモデルの悪さを納得できないとか、お前がプログラマ向いてないだけｗｗｗｗ

**デフォルトの名無しさん** · 2022/03/21(月) 21:10:25.40

この人色々なスレでスレごとに違うもの叩いてるから
おかしな人なんだろ

**デフォルトの名無しさん** · 2022/03/21(月) 21:29:05.60

ついに俺のファンまで出現ｗ

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

>>966
まあ君は「ぼくはわるくない！まわりがわるいんだ！」のタイプで、一生間違いを認めないんだろうけどさ。

C#はasync/awaitの導入で、『正しく使えば』、同期周りをユーザーが全く書く必要がなくなった。
結果、『意図的に間違えるような事をしなければ』、デッドロックはしなくなった。
そして見た目はほぼ同期であり、素晴らしく分かりやすかったので、他も追従した。
（だから他言語でもasync/awaitを『正しく』使ってる限りデッドロックはしないはず）

『正しく使えば』『意図的に間違えるような事をしなければ』なんて一々言わずともまともな人には大前提だし、
そもそもフレームワークは規定通り使わないとまともに動かない。
君がイカレてるから君の周りも同様の人しか居らず、自分達が掘った墓穴に落ちて大騒ぎしてただけだと思うぞ。
(「正しく使おう」とか、君は考えた事ないだろ)

とはいえ、平行線だし、合意を取る必要はないので、まあこれで終わりだね。

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

ちなRustの所有権とか見直してみたが、
以前読んだ時よりは大分文面が修正されてるのか、マシな印象だが、
いずれにしてもゴミなのは事実だね。RustはC++の出来損ないになってる。
一番の問題は、所有権でライフタイム管理を「入れ子」ではなく「投げ捨て」型にした事であり、
これで余分に手間が増えてしまってる。
「入れ子」の方が自然なので殆どの言語で採用されており、
問題は「入れ子」にならない場合にどうするかだが、

C：全部プログラマが管理しろ
C++：スマポ入荷しました
Rust：スマポと所有権（投げ捨て型）

なら、全く進歩してない。
必要なのはスマポに変わる何かであり、Rustは何ら役に立つ新規提案がない。
基本的にC++の構成をなぞっただけであり、おかしな補助輪を付けてしまってるので、
C++で苦労してない人にとってはC++の方がマシだろう。
それで改善点がメモリリークしなくなった程度では、流行りようがないよ。
(そもそもC++も『正しく使えば』メモリリークはしない。
君の視点だと文法的に問題がない＝コンパイルが通る＝正しく使う、なのだろうし、
実際こう出来ればいいのも確かだが、現状のプログラミング言語の大半はこうなってない。
これは一概に悪いというわけでもなく、プログラミングスタイルに自由度を与える為には必要でもある。
文法エラー＝新しいスタイルを試しようがない＝進歩しない言語、という事になるので)

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

記述や理解が楽になる言語、ってわけじゃなくて、そもそも安全で高性能な言語であることが前提の言語だし、別にRustはメモリリークは解決してない
手間が少なく、安全である必要もないなら、Rustを使う必要性は薄れる

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

>手間が少なく、
手間を少なくしたくて、

の書き間違い

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

>>973
Rustはメモリリークは保証してないのに
そこを叩いてるのは何を調べたの？

**デフォルトの名無しさん** · 2022/03/21(月) 23:25:18.39

>>974,976
「GC無しで！！！」と謳ってたから「メモリリーク無し」は当然だと思ってたのだが違うのか？
(なお見てるのは主に公式勝手訳日本語版。そこすら全部読んでもないので)

> 手間を少なくしたくて、安全である必要もないなら
手間は少なくなってない気もするが。
安全って型安全の事？なら俺は型無しでもまあいいや程度なので、
確かに俺には意味がない言語なんだろう。
（型があっても困らないが、
C++みたいに関数ポインタを常用しようとするとテンプレートを書きまくらなくてはいけなくなるのは困る。
この点、関数型やスクリプト言語がどれもこれも型無しなのは非常に納得)

見た目Rustは、C++をある特定の使い方（と言っても多分本流本筋だが）に特化しただけのように見える。
だからそのプログラミングスタイルだった人には素晴らしく嵌るのだろうけど。

**デフォルトの名無しさん** · 2022/03/21(月) 23:37:51.67

>>973
あまりにもデタラメすぎてむしろ苦笑
理解できなかったこと自体は仕方がないが
それにも関わらず他の言語をデタラメに叩くのはまともな人がすることではない

あまりにも間違いが多すぎて指摘しきれないが
例えば所有権はC++のスマートポインタ(unique_ptr/shared_ptr)で導入された概念
それなのになぜかC++にはスマポと書きながら所有権がなくRustのみに所有権と書いている
まずこの時点でC++の所有権とスマートポインタからして理解が出来ていない
さらにその後のRustに関することは妄想だらけになってしまっている

**デフォルトの名無しさん** · 2022/03/21(月) 23:38:20.57

>>977
変にrust叩きするのは恥かくだけなので
そのあたりでやめといたほうが

**デフォルトの名無しさん** · 2022/03/21(月) 23:51:09.41

>>973
貴方がC#に関して戦っている相手ID:BAdp3agq (>>966など)も同じくRustのアンチでRust関係スレで暴れているが
貴方は同じRustのアンチでもダメな彼より劣る
貴方は他の言語の知識も薄くRustについては何も理解しないまま嘘を書いている

**デフォルトの名無しさん** · 2022/03/21(月) 23:54:59.16

>>978
書き方が悪かったかもしれんが、
ブロックスコープで済み、それが最適な場所にすら所有権を強制して、
結果的に無駄に借用とかする羽目になってるのは事実だろ。

問題は、プログラミングでは大半の場合で「入れ子」が最適な事。
「投げ捨て」が向いてるのは、上から下に流れて終わり、のようなプログラムで、
サーバーは確かにそうだが。

**デフォルトの名無しさん** · 2022/03/21(月) 23:58:58.49

あの子みたいにまともに議論する気がないのはお話にもならないけど、
知識が足りないのはまあしょうがないやろ

全部わかってるひとなんてこんなスレには1人もいないだろうし

>>977
伝わらなかったみたいだけど、そうそう、Rustは手間を少なくする言語でもないよ

データ競合なくして型も省略しまくりたい、みたいなのだったらHaskellみたいに型推論がやたら強い言語とかもあるし

**デフォルトの名無しさん** · 2022/03/21(月) 23:59:10.41

>>981
入れ子って何？

**デフォルトの名無しさん** · 2022/03/22(火) 00:10:38.80

>>981
他の言語を批判したいなら、せめてもう少しは勉強したほうがいいよ
その意味不明な文章は理解不足が引き起こしている
もしどうしてもRustについて理解できないのならば、先にC++のunique_ptrを学んで所有権とは何かを理解すべき
あと他の人たちも指摘しているが「入れ子」や「投げ捨て」が意味不明

**デフォルトの名無しさん** · 2022/03/22(火) 00:14:23.89

>>982
なら何を目指してんのよ？
他に謳ってたのは「ゼロコスト抽象化」だが。

公式勝手訳日本語版まえがき、には
> 既に低レベルコードに取り組んでいるプログラマは、Rustを使用してさらなる高みを目指せます。
> 例えば、 Rustで並列性を導入することは、比較的低リスクです: コンパイラが伝統的なミスを捕捉してくれるのです。
一文目は素晴らしい。
が、二文目は、無いよりまし程度だし、そもそも無駄に手間が増えてる部分もあるから意味なくね？

**デフォルトの名無しさん** · 2022/03/22(火) 00:14:49.50

>>982
Rustを使うことで様々な手間が省けるのは事実
もちろん元の言語が何であるかによって、どんな手間が省けるようになるのか変わる
だから手間が省ける議論に関しては、比較対象を毎回固定しないと一般的な議論は無意味

**デフォルトの名無しさん** · 2022/03/22(火) 00:23:48.60

>>985
色んな言語やればわかるが
その並列性に関してはRustがベストで間違いない
データ競合が起きないことをRustは保証する
言いがかりをつけているだけの君の負けだ

**デフォルトの名無しさん** · 2022/03/22(火) 00:31:00.32

知識不足指摘されて意味のわからん逆ギレ起こすのは
同程度だったな