次世代言語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(火) 01:43:01.13

Javaで関数ポインタ要らない例
// Main.java
import java.util.List;
import java.util.Arrays;
import java.util.ArrayList;
import java.util.function.Consumer;
public class Main {
public static class MyContainer<T> extends ArrayList<T> {
public MyContainer(List list) {super(list);}
public void foreach(Consumer<T> consumer) {
for(var e: this) {
consumer.accept(e);
}
}
}
public static void main(String[] args) {
MyContainer<Integer> mine = new MyContainer<Integer>(Arrays.asList(1,2,3));
mine.foreach((value)->{System.out.println(value);});
}
}

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

イテレーター原理主義なんじゃないの
コレクションの要素を列挙するものしかイテレーターと呼ばないと考えてるとか

**デフォルトの名無しさん** · 2022/03/15(火) 07:48:57.53

>>749
シングルスレッドでデータ競合起こるコード例あんの？

**デフォルトの名無しさん** · 2022/03/15(火) 07:58:16.07

void f(int*a){
int*b=a;
*a=(*b)++;
}

みたいのはただの未定義動作だから許さんぞ

**デフォルトの名無しさん** · 2022/03/15(火) 08:44:41.02

>>749
保証していないよ。unsafeがあるだろ。

**デフォルトの名無しさん** · 2022/03/15(火) 08:45:32.91

>>756
コンテナベースのイテレータを提供する言語もあるから誤解しているのだろうけど
本来のイテレータ自体はコンテナとは別の存在
例えばrustで以下のイテレータチェーン
(1..)
.map(|n| (n * n - n) / 2 * 3)
.take_while(|n| n < &23)
.map(|n| n % 4 + 114)
.map(char::from)
.for_each(|n| print!("{n}"))
これは「rust」と表示するけどコンテナ等は全く登場しない

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

>>760
シングルスレッドでデータ競合を起こす例がwikipedia及びそのソース元の言語公式仕様定義に明記されているね

https://ja.wikipedia.org/wiki/データ競合
> JavaScript (ECMAScript) において、read/writeイベントEとDが以下の条件を満たしている場合「EとDはデータ競合にある」と定義される[2]。
> ・EあるいはDに順序が定義されない（not SeqCst）
> ・EとDが重複したrangeを有する（overlapping range）

**デフォルトの名無しさん** · 2022/03/15(火) 18:54:21.48

https://ideone.com/AKsoei
javaの典型的なイベント処理はこう
多言語のようにonclick = と指定するのではなく
イベント発生元にaddListener()でリスナを追加する
その時匿名クラス式を使うのもまた大昔からのやり方
匿名クラスについては以下を参照のこと
https://docs.oracle.com/javase/tutorial/java/javaOO/anonymousclasses.html

**デフォルトの名無しさん** · 2022/03/15(火) 18:58:10.48

どの言語でも『single writer XOR multiple readers』の原則を守ればデータ競合は起こらない
逆にそれを破ればシングルスレッドでもデータ競合は発生し得る
ほとんどの言語でデータ競合が起きる

>>762
Rustは『single writer XOR multiple readers』を言語仕様で満たしている
そのためRustではメモリ安全性だけでなくデータ競合も起きないことを保証している
もちろんC/C++と同じように生ポインタを使えるunsafeを使った場合はその部分を人間が責任を持つ

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

>>765
匿名クラスは内部クラスの一種だけど、通常はそういう書き方だね
>>741で言ってるのもそれのこと

>>766
まあRustもunsafeまみれだから安全じゃないけどね

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

>>763
配列以外の実体に対しエミュレーションして配列メソッドを使いたい場合、イテレータはインタフェースとしては有効だ。
ただそれは「イテレーターパターン」使用箇所の1%以下だろ。

>>764
それは一般的にはレーシングコンディションと言う。(wiki書いた奴が無知なだけ)
そして、その定義ならErlangは問題ない。理由は、

・変数は再代入禁止なので、定義しか出来ず、書き換えようがないから

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

まあシングルスレッドでも普通にコールバック多いと意図しないデータ競合はいつでも起きるけどな
言葉の定義の問題になるので俺は黙ってたけど・・・

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

>>768
それはwikipediaにソースが明記されているように
JavaScript(ECMAScript)の公式仕様書の記載です

ErlangはETSが共有データとなるため
留意してコードを書かないとデータ競合が発生します

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

>>765
それもしかしてわざわざ書いてくれた？ならどうも。

名前からしてそれは「アダプターパターン」になるのか？まあこれはさておき、
これがデザインパターンの問題を典型的に示してるとも思う。
デザインパターンは「実際にこう書ける」であり、「こう書きたい/書ければいいのに」ではないので、
実践的ではあるが現状肯定的で、理想的では全くない。
だからどうしてもバッドパターンが混ざり、言語が酷ければ酷い程それが増える。
Javaの場合は関数ポインタを直接取り扱えない事が致命的に欠点で、結果、
関数ポインタ専用コンテナとしてクラスを用いて継承をこねくり回したパターンが多くなってるが、
それらは他言語では不要なものばかりだ。
本当は「あらゆる言語の中で一番美しい書き方」集にすれば良かったのだろう。

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

上記の通り、結局それは、関数ポインタを直接扱えなかった欠点を回避する為に、
関数ポインタ専用コンテナとして「匿名クラス」を用いているだけ。
素直に関数ポインタを直接扱えるようにすれば不要だった。
勿論ラムダの代替にもなるが、結局ラムダも入れてしまってるのだから、やっぱり「クラス」に見えるのは使いづらいんだよ。
(この辺はC++も同様で、ファンクタでいいだろ、でずいぶん粘ったようだが、結局ラムダも入れてしまってる。
C++に関しては仕様の直交性なんて誰も求めてないので、粘った意味も分からないが）

Java:：匿名クラスのところを
> label.addMouseListener(new MouseListener() {
> public void mouseClicked(MouseEvent e) {}
> public void mouseEntered(MouseEvent e) {}
> public void mouseExited(MouseEvent e) {}
> public void mousePressed(MouseEvent e) {}
> public void mouseReleased(MouseEvent e) {}
> });

JS：汎用コンテナで普通にかけるので、○○パターンとかの命名なんてされない。
> label.addMouseListener({
> mouseClicked: function(e) {},
> mouseEntered: function(e) {},
> mouseExited: function(e) {},
> mousePressed: function(e) {},
> mouseReleased: function(e) {},
> });
ただしこんな書き方は普通はせず、単に
elem.onclick = function()e){};
で済まされるが。

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

あとついでに言うと、Java的にあらゆるイベントを纏めて記述方式はコード的に無理があって、 --- (A)
だいたいclick系とmove系(Enterd/Exited/Pressed/Released)は別物になる。
前者はそのelemだけで完結するが、
後者はドラッグ&ドロップ等なので、大体周りのelemにも同じようなコードを走行させる事になるから。
だから「匿名クラスでその場に定義のみ」だとかなり悲惨なコピペだらけになる。
最低限、そのメソッドに直接関数を差し込める書き方、

function click(){}
function move(){}
label.addMouseListener({
mouseClicked: click,
mouseEntered: move,
mouseExited: move,
mousePressed: move,
mouseReleased: move,
});

とかが出来ないと死ねる。で、Javaはこれも出来なかったように見える,。(Java7までは)
だからJavaのGUIは完全に死んだ。

ただしイベントがバブルする場合は上記 (A) の問題は実質的にない。
(どうせ纏めて記述するに近い物になるので。
つってもJavaのGUIなんて全く整備されてないから未だにバブルしないんじゃないかとも思うが。
なお.NETはWPFからバブルする）

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

>>770
ESの仕様にあるデータ競合はWeb Worker（つまり別スレッド）とSharedArrayBufferなんかでメモリ共有した場合の話であって、シングルスレッドでデータ競合すると主張しているわけではないと思うが

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

シングルスレッドでもデータ競合は起きる
>>769氏も言っているように

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

>>770
> https://262.ecma-international.org/10.0/#sec-data-races
race　はレースであって、競合なら confliction だよ。訳が不適切。

ただ、レーシングコンディションならRustでもいくらでも作れるはずだけど。
shared memory が出来るのだから、
同じ場所を書き換える非同期ジョブを適当に流し込めば自動的にそうなる。

Erlangでは出来ない、ってのは、上記の「同じ場所を書き換える」事が出来ないからだよ。(共有メモリも出来ない）
ETSってのは知らんが。

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

>>771-773
だから内部クラスで書けるっての

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

>>775
>>769がコールバックの呼び出し順序が非決定的であることを言っているならそれは競合状態（race condition）
データ競合（data race）ではない

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

>>778
俺が言ってるのは単なる不注意だよ
順序は決定的だけど、離れすぎて分からなくなるパターン

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

>>779
決定的なら競合すらしないと思うが…
単に論理バグで値を壊してしまうことはデータ競合とは言わないのでは

**デフォルトの名無しさん** · 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は遠慮したい。