次世代言語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/18(金) 11:42:44.46

キーワードにunsafeがあるRustはダメ。
C/C++ならunsafeというキーワードは無いからオーケー。

**デフォルトの名無しさん** · 2022/03/18(金) 11:58:46.43

>>851
C/C++はプログラム全体がunsafeだもんね
もはやC/C++を使うメリットがない

**デフォルトの名無しさん** · 2022/03/18(金) 12:28:10.67

C/C++もunsafeな部分はコメントでunsafeって書いとけば安心安全だよ

**デフォルトの名無しさん** · 2022/03/18(金) 12:29:49.65

C++は最強言語なのでRustを使うメリットなんて皆無なんだが、人類には難しすぎるのが難点ｗ
Rustがゴミなのは、その人類が勘違いをして、unsafeまみれなのに安全とかぬかしてるところｗ

**デフォルトの名無しさん** · 2022/03/18(金) 13:22:00.60

>>853
C/C++はプログラム全てがunsafeだから人間が管理しきれておらず
その結果として様々な問題を引き起こしてきたと各IT大手も明言しているね

**デフォルトの名無しさん** · 2022/03/18(金) 13:27:25.17

まるで、有能大企業にたった一人のゴミを入れたら無能大企業になるみたいに

**デフォルトの名無しさん** · 2022/03/18(金) 13:55:30.43

Rustはプログラミングしやすいから使ってる
安全性の保証とかはオマケで付いてきてる

**デフォルトの名無しさん** · 2022/03/18(金) 16:31:30.68

C++と比較なら、Rustが良いよねとは素直に思う。

スレタイにある言語との比較だと、
メモリ管理を人がしないといけないRustは遠慮したい。

**デフォルトの名無しさん** · 2022/03/18(金) 16:37:15.84

>>858
Rustは自動メモリ解放されるからプログラマーが手間かけなくていいよ

**デフォルトの名無しさん** · 2022/03/18(金) 16:43:15.79

スコープアウトでメモリ解放だからね

**デフォルトの名無しさん** · 2022/03/18(金) 20:52:41.88

>>835
金払うから振込先を教えろ
24時間以内に反応が無ければコードを書けないと見なす

**デフォルトの名無しさん** · 2022/03/18(金) 21:04:11.21

>>861
いくらくれるの？

**デフォルトの名無しさん** · 2022/03/18(金) 21:35:18.09

ガイガー君はコード書けなくてコピペしか出来ない子だよ

**デフォルトの名無しさん** · 2022/03/18(金) 21:40:03.06

>>862
金額はお前が提示する側だろw

**デフォルトの名無しさん** · 2022/03/18(金) 21:44:32.74

>>864
>>861に聞いているｗ俺が聞いたんだから、答えるのは861ｗお前の勝手な思い込みは関係ないｗ

**デフォルトの名無しさん** · 2022/03/18(金) 21:55:24.90

>>861
日付が変わる前に同じIDでコテハンを用意して同一人物が分かるようにしとけよｗ

**デフォルトの名無しさん** · 2022/03/18(金) 22:35:08.48

ガイガー君はいつも金を無心しているから金が無いんだよ
コーディング能力も無いけど

**デフォルトの名無しさん** · 2022/03/18(金) 23:03:51.44

内容のない煽りしか出来ないビビリの単発ID連投構ってちゃん君じゃないから、どちらもあるけどねｗ

**デフォルトの名無しさん** · 2022/03/18(金) 23:36:40.84

>>854
subsetsイテレータのコード書けたの？
断念？

**デフォルトの名無しさん** · 2022/03/18(金) 23:42:11.74

>>849
その通りだが、それは「簡単」のメリットの一面であり、
日本人はそっちしか目指さないから駄目なんだ。つまり、

・従来難しかった事が簡単になった（≒バグを検出しやすくなった）

の使い方だが、日本人はこれを

・従来難しかった事が簡単になったから、『馬鹿でも出来る』ようになった --- (A)

と、下方向への拡張にしか使わない。
結果、よりもっと馬鹿＝人件費が安い連中に、という事で、
『文系でも出来た！』『中国人』『ベトナム人』とまあ、

・今までと同じ事を、より馬鹿を使う事によって、人件費を抑えようとする

から、エンジニアの給料が上がる事がない。
勘違いしてる社畜プログラマは
「エンジニアをもっと好待遇にしろ（≒給料を上げろ）」と簡単に言うのだが、
下方向への競争をやってる限り、給料が上がる事はない。
いつしかもっと安い連中を探し出してきて、代替されるからだ。
ならば、

・従来難しかった事が簡単になったから、同じ事が早く出来るようになった --- (B)

とするのもの一つの作戦だ。回転数で勝負というわけだ。
これが得意な奴ならこれもありだろう。
ただ、安い連中の中には早い連中も居るから、安泰ではない。
(A)と同様、給料には下方向への圧力がかかり続けてる状態だ。

**デフォルトの名無しさん** · 2022/03/18(金) 23:42:29.09

本来は、

・従来難しかった事が簡単になったから、
　従来では現実的に不可能だった事が出来るようになった --- (C)

を目指さないといけない。これが上方向への拡張だ。
「俺は素晴らしい学歴を持ってるのだから、もっと給料を払え」と言うのなら、
その素晴らしい学歴を獲得する過程で得た知識を持っていないと出来ない事、
知識がない人（≒馬鹿）には出来ない事をやって差別化するしかない。
そしてそれでユーザーにメリットが有れば、製品は売れ、利益が出るので、給料も高く留まる。
馬鹿ではそれが作れないなら、安売り合戦になる事もない。
だからそれは何だと聞いてるんだよ。

(A)(B)は順当な進化だが、それを追求するのは文系プログラマでいい。
CSを学んでおり、それで高収入を得たいなら、
CSで学んだ知識がないと無理な領域を攻めるしかない。
勿論CSだからプログラミングは余裕で、
文系プログラマですら給料払ってくれる日本企業なら楽勝でスーダラ節状態、
「サラリーマンは気楽な稼業と来たもんだ」な人生もありだとは思うが、
何も考えずに(A)(B)しかないと思ってたのなら、ちゃんと(C)も意識しておけ、という事。

実際、アメリカ人とかは(C)も目指してて、
よくもまあこんなもん作りあげたな、というのも多いだろ。
一つ一つは小さな(C)の積み上げなんだよ。

で、話を戻すと、

従来：ロック周りは難しいので、出来るだけ書かないようにする
　＝　出来るだけ大きい単位(ジョブ)でしかマルチスレッドを適用出来ない
Rust：ロック周りもコンパイラサポートありなので、従来よりは気軽に書けます！
　→　それでロックが大量に書けてバグもないとして、
　　　ユーザーにとってのメリット(通常は速度)がある領域は何？

**デフォルトの名無しさん** · 2022/03/18(金) 23:46:57.28

>>806
思うにそれはGoに必要な機能だ。

今現在もロック周りは難しいとされているので、あまりそこを攻めようという奴はいない。
結果、通常は「ジョブ」という、最大単位でマルチスレッドにして、ロック記述は最小にしてる。

C#の場合は全てフレームワーク内に隠蔽し、ユーザーがロック記述をする必要が無くしてしまった。
メインスレッド＋スレッドプールで、共有部分はメインスレッドで処理し、
完全に独立している部分を非同期ジョブとして切り出す。
多分ジョブ内からでもInvokeを使えばメインスレッドにやらせる事は出来るはずだから、
この場合、mutexやatomicを全く使わなくても済む。
(mutexやatomicよりはInvokeの方が簡単だし静的に解析可能、と見たのだろう。
これは実際そうだし、Invoke《意味的には固有スレッドで動かすコルーチン》なら
どこをどう間違えてもデッドロックはしない)

Goの場合はもっと小さい単位(コルーチン程度)でマルチスレッドを使うのが正解だと踏んだのだろう。
それでアクターモデルでやればmutexやatomic系は必要なくなる。
問題はランタイムの設計が不適切で無駄にgoroutineが重い事だが、これは言語自体の問題ではない。
(ただしアクターモデルよりはオブジェクト指向でatomicした方が断然速いので、
Go以外の言語は全部そうしてるわけだが。
この意味ではC#はメインスレッドだけアクター用のインタフェースを持ってる事になるが)

**デフォルトの名無しさん** · 2022/03/18(金) 23:47:15.18

とはいえ、マルチスレッドで細かく共有する構造はGoだと圧倒的に記述しやすいのは事実だ。
ただし現実的には容易にデッドロックするから無理だし、
何故か分からんがGoの連中は共有RAMを必要以上に嫌ってて、原則「チャネルで繋げ」となってる気はする。
ここに「ロック周りもコンパイラサポート！バグは静的に検出！！！」出来れば、
新境地が開ける可能性はある。
ついでに言うと、Goの場合は同期チャネルなので、
レーシングコンディションも強引に潰していく事が可能
(EDと来た場合にも、EにD待ちさせてDEと整列させる記述は凄く簡単)なわけだが、
これもデッドロックの巣でしかないので今現在は現実的に無理だ。
ここら辺の扉も開く可能性はある。

ただ一般論としては、

Rust：ロック周りもコンパイラサポートがあるので、気楽に書けます！
C#：ロック周りはフレームワーク内部に隠蔽したので、全く書く必要有りません。

なら、C#の方が正解だとされる。

**デフォルトの名無しさん** · 2022/03/18(金) 23:48:34.69

>>869
そんなコード書けないやついねーよｗｗｗｗ
>>861はもうID変えちゃってないんだなｗ

**デフォルトの名無しさん** · 2022/03/18(金) 23:52:00.45

今北産業

**デフォルトの名無しさん** · 2022/03/19(土) 00:33:29.03

C#とGoとRustならGoでいいと思うけど…一番ラクじゃん
C#なんてTask.Delay()の代わりにThread.Sleep()使うだけで簡単にデッドロックするよｗ

**デフォルトの名無しさん** · 2022/03/19(土) 00:45:29.31

>>876
俺が言ってるのはasync。
あと、C#の場合はもはやその辺も使う必要がない。同期周りを一切書かずに済む。
そしてtry-catchも強引に持ってきてしまったから、C#が目指しているのは、

・同期のノリで書いて、ほぼ問題なし。
　一切マルチスレッド周りの知識も必要なし。単なる高火力コンロとして使用可能。
　ただし、中身はマルチスレッドなので、分離はしてないと駄目だし、処理順も規定出来ない。

というところかと。殆どの場合はこれで済むのも事実だし。
C#の場合は(B)の生産性最重視だからこれも一つの解だよ。

**デフォルトの名無しさん** · 2022/03/19(土) 01:10:20.44

C#はそうはいかんぞ。

**デフォルトの名無しさん** · 2022/03/19(土) 01:46:49.15

C#はこれだけだぞ（他言語もasyncなら同様だが）
https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/concepts/async/media/task-asynchronous-programming-model/navigation-trace-async-program.png#lightbox

元記事は
https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/concepts/async/task-asynchronous-programming-model

**デフォルトの名無しさん** · 2022/03/19(土) 01:51:16.86

すまん、877の１つ目の中身は以下。(テキストは無いと勝手に勘違いしてた）

public async Task<int> GetUrlContentLengthAsync()
{
var client = new HttpClient();

Task<string> getStringTask =
client.GetStringAsync("https://docs.microsoft.com/dotnet";);

DoIndependentWork();

string contents = await getStringTask;

return contents.Length;
}

void DoIndependentWork()
{
Console.WriteLine("Working...");
}

**デフォルトの名無しさん** · 2022/03/19(土) 01:57:24.25

例えば、Sleepじゃなくて(同期)Waitだけど、WPFなどGUIのプロジェクトでこんなコードを走らせてみれば、デッドロックするよｗ
// MainWindow.xaml.cs
...
public partial class MainWindow : Window {
private async Task DelayAsync() {
await Task.Delay(1000);
}
public MainWindow() {
DelayAsync().Wait();
InitializeComponent();
}
}
...
.NETのモデルは同期と非同期を混ぜると結構簡単に(分かりにくい)デッドロックを起こす

**デフォルトの名無しさん** · 2022/03/19(土) 02:11:20.46

>>881
waitするのが悪いんだろ。
asyncは同期的にずらずら書く用で、手動でマルチスレッドする用ではないので。

C#はそこまで馬鹿な奴を救済する用には出来てない。
正しく書いた時に正しく動く用だ。
(つか、Taskを流用したから混ぜられるのであって、多分それも仕様なんだろう。
新しくAsyncTaskにしてWaitメソッドを無くせば済んだ話だし)

まあとにかく、簡単に書ける、馬鹿でも書ける、ってことを目指してる限り、
給料なんて一生上がるはずもない事は認識しておくべきだよ。

**デフォルトの名無しさん** · 2022/03/19(土) 02:31:56.02

そもそもTaskはasync/await前から同じような動きをする書き方が出来てて、手動でマルチスレッドする用ではないｗ
給料の問題ではなく、他の言語と比較して、不測の事態を起こしやすいモデルなんだよね
名前に統一感がないまま、いろいろ出来るようになっているからｗ

**デフォルトの名無しさん** · 2022/03/19(土) 08:49:20.14

>>881
そこはawait

**デフォルトの名無しさん** · 2022/03/19(土) 08:50:39.38

>>883
注意欠陥障害者乙☆

**デフォルトの名無しさん** · 2022/03/19(土) 09:44:10.95

>>884
コンストラクタがasyncじゃないから使えないんじゃね？

**デフォルトの名無しさん** · 2022/03/19(土) 13:49:16.76

あえてカスタマイズしにくいコンストラクタを選んだんだよｗ

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

>>881
C#はWPFとしてGo,RustではどんなGUIが標準的に用意されてんの？
それでは同様の障害は起こらないの？

あからさまに比較対象がおかしい

**デフォルトの名無しさん** · 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

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