次世代言語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/15(火) 21:50:10.28

だから言葉の定義ｗ
関数やメソッド単位で見る人間にとっては、再入とかコールバックが輻輳してやらかす事件はとても似てるｗ
組込みの割込みとかシグナルとかのIPCも同様なので、まあ混ぜて考えてもいいと思うって人はいるんじゃないかと思ったｗ

**デフォルトの名無しさん** · 2022/03/15(火) 21:55:39.00

>>776
data race(英語)⇔データ競合(日本語)です
ETS (Erlang Term Storage)はErlangが標準で持っているインメモリの領域
ETSはErlangで色々辛いところを解決する魔法の道具であり抜け道でもありGCもなくデータ共有もOK

>>778
もちろん競合状態(race condition)もあるけど
それとは別に同じデータ(対象)に対して2者以上がルールを守っていなければデータ競合が発生
例えば>>766の言う『single writer XOR multiple readers』の原則が崩れていればデータ競合が発生ありうる

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

>>782
シングルスレッドでshared xor mutableで防げるバグがあるのはそう（イテレート中にイテレート元にデータ挿入しちゃうとか）だが
それはデータ競合とは言わないのでは
少なくともRust公式はdata raceの定義をマルチスレッド前提にしているし、一般的にもそうだろう
https://doc.rust-lang.org/nomicon/races.html

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

>>783
それは非同期でマルチグリーンスレッドでも全く同様に起きることであるし
それは非同期コールバックのあるJavaScriptでも同じく起きることであるし
シングルOSスレッドでも発生しちゃうな

**デフォルトの名無しさん** · 2022/03/15(火) 22:33:43.93

>>782
raceは競『争』。競『合』の訳はないと思うが、
まあお前らがレーシングコンディションの意味で使ってると分かれば俺はとりあえずはいい。
（とはいえ俺はもう終わりでいいが）

あと、JSの定義は>>774が言ってるとおり、
マルチスレッドでの前提で、シングルスレッドでは発生しない。（定義されてない）

多分wiki書いた奴が全く分かってない。
何か不思議な値になるみたいな書き方だが、そうはならない。
一発書きなら当たり前だがどちらかが書いた値にしかならない。殆どの場合はこれになる。
一発書きしない場合は混ざる事があるが、
多分これを著者が理解出来てないからあやふやな書き方になってる。

**デフォルトの名無しさん** · 2022/03/15(火) 22:36:34.90

データ競合(data race)という言葉の定義自体が言語によって違うんか

それならなんか人によって話が噛み合ってないのも納得

C++11だとマルチスレッドが前提になってた
https://timsong-cpp.github.io/cppwp/n3337/intro.multithread#def:data_race

**デフォルトの名無しさん** · 2022/03/15(火) 22:50:45.74

ここまで出た通りES/Rust/C++はマルチスレッド前提で、Javaも確かそうだったし
シングルスレッド派の人はちゃんと定義されてるやつを示してほしい
日本語Wikipediaじゃなくて

>>785
訳が競争というのはまぁそうかもしれないけど、CS系学部の教科書レベルで競合に統一されちゃってるので、いまさらどうしようもないね…

**デフォルトの名無しさん** · 2022/03/15(火) 22:52:23.31

というかよく考えたら日本語Wikipediaも間違ってはないんだな
引用した人がJSだからシングルスレッドって思い込んでただけで

**デフォルトの名無しさん** · 2022/03/15(火) 23:02:06.12

ほら定義の話になってんだろ
それって正解がないので、どっちかに合わせて結論出したら終わりなんだよ

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

データ競合(data race)だろうと競合状態(race condition)だろうと言語ごとに定義が違うなこりゃ

言葉の定義自体は規格書引っ張り出してきて殴り合うとして、
言語が別だとそもそも話し合うことすら難しいんじゃないの？
どっちかの定義に寄せることすら無理そうだし

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

あと>>783の定義だと、concurrentだからシングルスレッドな並行もダメかもね
非同期シグナルとかもダメだし、シングルスレッドって前提だけではデータ競合起きちゃうね

**デフォルトの名無しさん** · 2022/03/15(火) 23:46:09.49

定義は両者で共有・合意するだけで問題ないよ
規格書を引っ張り出す必要もない
ただ出た結論は定義込みで語られないと意味がないだけｗ

**デフォルトの名無しさん** · 2022/03/16(水) 00:57:59.77

>>787
> CS系学部の教科書レベルで競合に統一されちゃってる
よしそいつを吊そう…
と言いたいところだが、語感的に

競争：所詮どっちが先か後か程度、結果はどっちかになる
競合：ぶつかってぶっ壊れるイメージ、結果がどうなるかは分からない

だから敢えて「競合」としたのだろう。
発端はただの競争でしかないが、甘く見てると、結果は全く身に覚えのないデータになってしまう事もあるので、
教育上は「競合」の方がいいのかもしれない。

有名どころはJavaのdouble-checked lockingイディオムが実は全く役に立たず、大騒ぎしてた件とか。
http://www-06.ibm.com/jp/developerworks/java/020726/j_j-dcl.html　（多分これだがリンク切れ）

残骸はあちこちに残ってるので雰囲気だけは分かるかも。
https://atmarkit.itmedia.co.jp/bbs/phpBB/viewtopic.php?topic=31199&;forum=12
なお言い分が食い違ってるが、俺はさらに違ってて、「初期化中のクラスが他スレッドに見えてしまって、
Javaの仕様ではこれを防ぐ方法もない」だと思ったが。
他の残骸は以下とか。（全部読んだわけではないけど）
https://en.wikipedia.org/wiki/Double-checked_locking
https://stackoverflow.com/questions/1625118/java-double-checked-locking
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

**デフォルトの名無しさん** · 2022/03/16(水) 01:28:32.65

別に毎回同期すればいいだけのところを無理に端折ろうとすると、複数CPU時代の現代ではインターロックが必要ってだけでしょ
volatileがないのは論外だけど…
競合を回避するには同期(ロック)しようねってだけ

**デフォルトの名無しさん** · 2022/03/16(水) 02:53:58.81

JSエアプだったからスルーしてたが >>764 の言う「順序」ってのが定義されていればデータ競合にはならんのだよな？

1スレッド内の操作で順序が定義されていないって状況がなんか想像できなかった

まさか value=value みたいのがデータ競合なんてならんだろうし

**デフォルトの名無しさん** · 2022/03/16(水) 06:15:40.53

え？そこは>>788でFAでは？ECMA Scriptだしな

**デフォルトの名無しさん** · 2022/03/16(水) 08:12:09.94

>>766
もちろんC/C++と同じように生ポインタを使えるunsafeを使った場合はその部分を人間が責任を持つ

そういうのは「Rustが保証する」とは言わん。

**デフォルトの名無しさん** · 2022/03/16(水) 21:28:41.83

>>797
それはあなたが理解できていない
プログラム全体に渡り言語仕様に基づきコンパイラが安全性を保証できる
その例外部分がunsafe宣言部分でありそこだけを人間が責任を持てばよい
他の言語はプログラム全体に渡り人間が責任を持たなければならない

**デフォルトの名無しさん** · 2022/03/16(水) 22:05:14.42

この際「Rustのunsafeは綺麗なunsafe」のダブスタは置いておくとして、
仮にRustではデータ競合をunsafe領域だけに局在化出来るとして、それで何が嬉しいんだ？
具体的にそれをどういうアプリに生かせるんだ？

他言語の場合はスレッドセーフにするのには細心の注意がいる。
だから一般的に最小限の部分しかスレッドセーフにしない。結果、共有も最小限だ。

対してこれがunsafe領域だけにできるとして、これだけなら
・ロック周りを記述している箇所は後から検索出来るように必ず　./// LOCK のコメントを付けとけ
程度の意味しかない。

既に言ったが他言語ではロック周りは難しいので最小限に絞られている。
これがRustで楽に書け、もっとカジュアルに使えるとして、
出来上がるアプリは「スレッド間をもっと密結合させ、共有RAMをもっとカジュアルに使うもの」になる。
共有RAM方式は昨今言われている程遅くも悪くもないが、(x86の場合は)
ハードウェアとしては従来通りの「共有RAMは最小限」の方が断然速く動く。

だから単純には、
C++ではロック周りでバグが出まくって実装するにはとても無理だが、
言語サポートがあるRustなら平気で書けるからこそこの構造に出来、断然性能がいい、
とかいうアプリ（適用領域）がないといけないが、これは何？

Go/Rustはマルチスレッドがこなれてからの言語だからその辺に独自のアイデアを突っ込んできてるのは当然として、
Rustのが「ロックをもっとカジュアルに」なら多分ハズレだ。
簡単に書けるのは正義ではあるが、ロックを最小限に絞るのは『大』正義だからだ。
(そして一般的なフレームワークを使えば、
ロックなんてそれ用のクラスを使うしかないから、検索すればすぐに見つかる。
ロックすら考慮せず野良で共有してるようなコードは見逃すが、
これを防ぐ為だとしたらRustは相当の馬鹿向け言語という事になる。
C/C++だったら「そんな奴は死刑」で誰も反対しない)

**デフォルトの名無しさん** · 2022/03/16(水) 22:10:43.48

一応確認するけど触っちゃダメな人だよね？

**デフォルトの名無しさん** · 2022/03/16(水) 22:14:58.99

>>800
スレで一番筋の悪い人が
スレで一番の長文を書いて暴れる

しかしこれは珍しいことではない
自分と他人の力量が見えないことは
こういう風景を生みがちなのである

**デフォルトの名無しさん** · 2022/03/16(水) 22:41:00.48

そもそも何と何を比較したい、とか主張や前提が不明瞭だから長くなってんだよ
日記を書くなら他所にしてね

**デフォルトの名無しさん** · 2022/03/16(水) 23:55:27.76

>>799
Rustで実際に書けばわかるが
普通のプログラムでunsafeを使うことはないぜ
unsafeは特定のライブラリの中に閉じ込められていて外に影響なし
その部分を除くプログラム全体の安全性をRustコンパイラが保証
他の言語ではプログラム全体の安全性を人間が保証

**デフォルトの名無しさん** · 2022/03/17(木) 00:29:26.40

銀の弾丸は無いってことを理解できない人が暴れてるみたいだな。
たぶん今までの人生全ての出来事が100点じゃないとダメな人なんだろうけど、なんでまだ生きてるんだろう？

**デフォルトの名無しさん** · 2022/03/17(木) 00:41:54.94

>>803
ユーザーがunsafeを使う必要がないのはいいが、
それが何を作る時にどう利点になるんだ？

繰り返すが、C++等でロック等を自前で書く事はほぼ無い。
最小にする為にatomicにして、atomicは通常、フレームワークが用意してる物を使うからだ。
だから「ロック等を使う必要がある」事を認識してる奴が書いたコードなら、Rustと同程度に安全だ。
なぜなら、Rustでも「ロック等を使う必要がある」と認識して、特定のライブラリを使わないといけないんだろ。

この側面についてのRustの利点は、
・「ロック等を使う必要がある」とすら認識出来ない馬鹿が書いた時に、コンパイルが通らない --- (A)
というだけのように見える。

・「ロック等を使う必要がある」と認識出来る奴が、ロック等を『うっかり』忘れる --- (B)
のを想定しているなら、はっきり言ってこれはない。
マルチスレッドを直接扱う場合、何らかのロック等が『常に』必要であり、
最初にそこを設計して、かつそれはスレッドについて「入力」「出力」側１つずつとかの最小限に絞るからだ。
つまり、目で見て分かる程度でやってる。見落として苦労する事は無い。
これをRustだとコンパイラがチェックしてくれるから、大量に出来る！見落としもない！のはいいが、
それはどういう時に利点なんだ？という話。

細かいオブジェクトを大量に共有出来たら素晴らしくパフォーマンスが上がる、なんて構造、無いだろ。

**デフォルトの名無しさん** · 2022/03/17(木) 01:37:02.04

>>805
Rustコンパイラが保証するのは
・そういうマルチスレッド時の、狭義のデータ競合、だけでなく
・シングルスレッドでの非同期コールバックなどの、普通のデータ競合、や
・ロジックミスなどにより生じる、広義のデータ競合、に加えて
・様々なメモリ安全性、に至るまで
コンパイル時に検出が可能なことを保証
色んな言語で書いてきたプログラマーならば以上の説明で恩恵を納得できる

**デフォルトの名無しさん** · 2022/03/17(木) 01:38:54.54

C++って何か理由があってピンポイントで使うことが多いと思う
だからフレームワークってあんまりないよね
間違ってる上に風呂敷広げすぎ

Rustもそんなこと保証できない

**デフォルトの名無しさん** · 2022/03/17(木) 01:39:14.78

もう相手すんなよ
うっかりがありえないとかまともなプログラマならそれこそありえないことを知ってるだろうし

**デフォルトの名無しさん** · 2022/03/17(木) 01:49:00.20

　:::....　　　／|＼||　　　
　　　　／／|'＼＼.... ...:::.. .......
　　　　|／　,'|-､＼＼
　　　　|／　,'|-､＼＼＼
　　　　|／　,'|-､＼＼＼|.... ...:::.. .......
　　　　|／　,'|-､＼＼＼|:..。..... ...:::.. .......
　　　　|／　,'|-､＼＼＼|__|
　　　　|／　,'|-､＼＼＼|:...|ヽ　.... ...:::.. .......
　　　　|／　,'|-､＼＼＼|::::|　|::.....　
　|￣￣￣￣￣＼､'＼＼|;;:.|_,,|＿＿＿　　　
　| □□ □□ |　|＼, ＼|;;::....　　　　　|＼
　| □□ □□ |　|　 |￣￣￣￣|＼;: . |　 |
　| □□ □□ |　|　 |□□□□|　 |::...|　 |;;:
　| □□ □□ |　|　 |□□□□|　 |::...|　 |:;:.／
　| □□ □□ |　|　 |□□□□|　 |::...|　／
　| □□ □□ |.._|__,,|□□□□|　 |::...|／　　
,,|￣￣￣||￣￣＼≡＼,□□□|／ ,／

今北産業 [IMAKITA INDUSTRIAL CO.,LTD]
　　　　　（1978～　日本）

**デフォルトの名無しさん** · 2022/03/17(木) 01:53:13.45

彼は確かに色々と間違っているが
彼の言う通りロックが必要なところでうっかり忘れたとすると
Rustコンパイラはそれが引き起こすデータ競合を通さないから
結局ロックが必要な型を使うことになり結果としてそれも保証されたことになる

**デフォルトの名無しさん** · 2022/03/17(木) 02:47:42.05

また保証話で嘘ついてRustの評価を地に落としているバカがいるなｗ

**デフォルトの名無しさん** · 2022/03/17(木) 02:49:58.34

>>806で保証合ってると思うぜ
違うと言うなら具体的に反論しないとな

**デフォルトの名無しさん** · 2022/03/17(木) 02:57:11.72

Rustを叩く連中は
長々と長文で頓珍漢なやつと
理由も言わずに嘘とか違うとか言うだけのやつがいる

**デフォルトの名無しさん** · 2022/03/17(木) 02:58:10.57

昨日もう散々話したよｗ異論があるなら昨日の話に続ければいいｗ

**デフォルトの名無しさん** · 2022/03/17(木) 03:13:31.40

>>814
昨日って>>799？
意味不明で説得力ゼロ

**デフォルトの名無しさん** · 2022/03/17(木) 03:38:46.21

データ競合の話に決まってんだろ
頭にボウフラ湧いてない？
昨日のまとめ的見解は大枠>>786のような感じｗ

**デフォルトの名無しさん** · 2022/03/17(木) 03:44:26.34

データ競合の意味する範囲が様々あるのはその通り
一方で>>806はそれを3種類に分けているのもその通り
いずれにしてもそれら全てに対してRustコンパイラはデータ競合が起きていないことを保証するので問題なし

**デフォルトの名無しさん** · 2022/03/17(木) 04:03:48.44

データ競合の定義が複数あるのがそのとおりなら、もうそれだけで常に真になるわけではないことになる
それを「保証する」なら「嘘」と言わざるを得ない

**デフォルトの名無しさん** · 2022/03/17(木) 04:12:17.15

どの定義のデータ競合も共通している点がある
それは『single writer XOR multi readers』を厳守しているならばデータ競合が起きない点
そしてRustコンパイラはどんなに複雑な状況でも『single writer XOR multi readers』の厳守/破綻を検知できる
つまりRustコンパイラはどのタイプのデータ競合も起きていないことを保証できる

**デフォルトの名無しさん** · 2022/03/17(木) 04:23:35.25

>>819
出来たらいくらくれる？

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

unsafeが無くなった完全なrustが出来たら起こして！！

**デフォルトの名無しさん** · 2022/03/17(木) 21:19:19.10

privateとかprotectedの保証が時代遅れになった原因もそれかなあ

**デフォルトの名無しさん** · 2022/03/17(木) 21:23:32.01

なんでここまでunsafeにこだわってるんだろう

**デフォルトの名無しさん** · 2022/03/17(木) 21:25:25.12

>>821
Rustにアンチな人はunsafeを持ち出した時点で敗北だと気付かなきゃ
Rust以外の言語ではプログラム全体がそのunsafe状態なのだから

**デフォルトの名無しさん** · 2022/03/17(木) 21:31:34.22

Rustのunsafeは質が非常に悪いからな
まさに邪悪の一言に尽きるｗ
ピカピカのRustが一瞬にして継ぎ接ぎだらけのボロ雑巾に生まれ変わるｗ

かたや他の言語は長い歴史が積み上げた研鑽のたまもので、そこそこ綺麗に保たれているのであったｗ

**デフォルトの名無しさん** · 2022/03/17(木) 21:47:24.40

>>825
unsafeは普通のプログラミング言語と同じという意味ですよ
つまり普通のプログラミング言語はプログラム全てがunsafeなのでデータ競合やメモリ安全などを人間が確実に保証しなければなりません
一方でRustはプログラムのほとんどの部分がunsafeではないのでコンパイラが安全性を保証できます

**デフォルトの名無しさん** · 2022/03/17(木) 21:56:08.91

COBOL最強伝説は続く

**デフォルトの名無しさん** · 2022/03/17(木) 22:15:39.17

>>823
もうそこしか攻められないってことだろ
そんなところ攻められても痛くも痒くもないけどw

**デフォルトの名無しさん** · 2022/03/17(木) 22:18:34.26

そこだけでぶっ壊れるガラス細工なRustなわけだがｗ

**デフォルトの名無しさん** · 2022/03/17(木) 23:08:20.88

>>806
やっぱり俺にはRustは要らないという結論だね。

> 色んな言語で書いてきたプログラマーならば以上の説明で恩恵を納得できる
新興言語にかなり有利に出るPYPLですらC/C++比1/6の現実を見た方がいい。

**デフォルトの名無しさん** · 2022/03/17(木) 23:13:07.24

C/C++とRustならば
両方使いこなせる人が常にRustを選ぶことからも言語の優劣差がはっきりしている

**デフォルトの名無しさん** · 2022/03/17(木) 23:26:04.14

>>831
> 両方使いこなせる人が常にRustを選ぶ
Rust界隈でインタビューすればそりゃそうなる。そういうところがエコーチェンバーだと思うんだけどね。

まあasyncはだいぶ筋が良さそうだし、今後どうなるかだね。

**デフォルトの名無しさん** · 2022/03/17(木) 23:27:19.56

両方使いこなせるけど、常にC++を選んじゃってるんだがｗ
まあ趣味だし他人にC++は勧めないけどねｗ
だからといってRustも全く勧めない
言語の優劣は圧倒的にC++が優っている

**デフォルトの名無しさん** · 2022/03/17(木) 23:30:33.62

>>833
おまえこの前もRustコードを書けずに敗走したアンチじゃん

**デフォルトの名無しさん** · 2022/03/17(木) 23:39:33.80

ここでそんなこと言われたことないし、このスレ系列にも俺が書いたコードあるけどｗ
コードくれくれビビリ単発IDがココにも湧き始めたねｗ
書けると何度も言ってるし金くれるなら書くって言ってるんだがな

**デフォルトの名無しさん** · 2022/03/17(木) 23:48:09.01

その人は>>825を見るとunsafeの意味も
Rustがunsafeを分離することに成功した価値も理解できていないようだから
コードも書くことができないだろうと思う

**デフォルトの名無しさん** · 2022/03/17(木) 23:52:24.83

お前みたいな胡散臭いのが余計なことしてるからRustがいつまで経っても広まらないんだよｗ
理念は悪くないのに、嘘までつくからこうなるｗ

**デフォルトの名無しさん** · 2022/03/17(木) 23:58:29.79

理解してるとかどうか以前に、精神レベルがどうみても小学生以下じゃん
何を書こうが議論するに値しないよ

**デフォルトの名無しさん** · 2022/03/17(木) 23:59:13.49

この真っ赤な人はRust叩きばかりしているダメな人でRustスレを出入り禁止になった人でしょ

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

俺はRustスレでRust以外の話はしてない(Rustの説明に必要なときだけ他言語を書く場合がある)し、もちろん出禁になってもいないし、Rustのコードも書いたしお前より貢献してる気がするんだけどｗ
ビビリの単発連投構ってちゃん君ｗ

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

>>840
もしやガイガー狂人か
精神病かね

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

cargo geigerは忘れずにしような☢
頭おかしいと思っちゃうなら患者は恐らく君のほうだと思うよ
俺は専門家じゃないから知らんけどｗ

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

このガイガー小学生はいつまでスレに張り付いてるんだろう

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

お前同様ずっといるんじゃないかなｗビビリの単発ID連投構ってちゃん君ｗ
プログラミングのお勉強()はしなくていいのかな？ｗ

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

連投するほうが上という謎の価値観🤔

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

どうしてそういう解釈になったのかは知らんし、君の頭が悪いのまで俺のせいにされても・・・

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

ガイガー君はプログラム組むこと出来るようになったのかな

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

勝手に名前付けてんなよｗビビリの単発ID連投構ってちゃん君ｗプログラミングできないのは君だけだよｗ

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

>>799
他の言語では細心の注意が払えていなかったことが実行時まで分からない部分が、Rustではコンパイル時に分かることが嬉しいんだろ
だから実際には細心の注意を払わなくても大抵の入力で問題ないケースにも制約が掛かってRustでは難しくなる場合がある
それにその制約を強制されたところであらゆるバグがなくなるわけではない
Rustが定義するバグの範囲に収まるだけ
これを嬉しいと思うかどうかで選べば良いんじゃないの？

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

>>824
そもそもユーザーがunsafeだからね

**デフォルトの名無しさん** · 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のモデルは同期と非同期を混ぜると結構簡単に(分かりにくい)デッドロックを起こす