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

1 ：デフォルトの名無しさん：2022/08/29(月) 11:22:16.48 ID:5dAad4gs.net

スレタイ以外の言語もok

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

2 ：デフォルトの名無しさん：2022/08/29(月) 13:57:56.66 ID:rGElgR/G.net

>>1 乙

>>980 次スレ立ててね

3 ：デフォルトの名無しさん：2022/08/29(月) 17:39:40.63 ID:OPpJUiH3.net

文字列の変数sが与えられた時に
変数a (符号付き32bit整数)、
変数b (符号なし64bit整数)、
変数c (64bit浮動小数点数)へそれぞれ変換するコード

【Rust】
let s: &str = "12345";
let a: i32 = s.parse()?;
let b: u64 = s.parse()?;
let c: f64 = s.parse()?;

【Kotlin】
val s: String = "12345"
val a: Int = s.toInt()
val b: ULong = s.toULong()
val c: Double = s.toDouble()

【Swift】
let s: String = "12345"
let a: Int32 = Int32(s)!
let b: Uint64 = Uint64(s)!
let c: Double = Double(s)!

【Go】
var s string = "12345"
var err error
var a int32
a, err = strconv.ParseInt(s, 10, 32)
var b uint64
b, err = strconv.ParseUint(s, 10, 64)
var c float64
c, err = strconv.ParseFloat(s, 64)

4 ：デフォルトの名無しさん：2022/08/29(月) 18:02:10.99 ID:99yF6EBS.net

KotlinやSwiftは型推論できるやろ
それにパースとキャストは違うぞ

5 ：デフォルトの名無しさん：2022/08/29(月) 18:41:59.28 ID:bPAqKnWj.net

全然書き込みが無いけど

ypeScript Swift Go Kotlin Rust Nimって、需要も人気も無いの？

6 ：デフォルトの名無しさん：2022/08/29(月) 18:50:03.71 ID:9qXoEPFV.net

>>4
今どきのプログラミング言語はいずれも型推論が賢いね
昔は型推論が無いか弱くて
変数の型宣言が不要というだけで動的型付け言語のメリットされていた時代もあった

7 ：デフォルトの名無しさん：2022/08/29(月) 19:09:28.15 ID:bPAqKnWj.net

次世代言語と言われる

TypeScript も Swift も Go も Kotlin も Rust も Nim ←これらの言語を全然知らない、

昭和の時代から IT関連業で働き、稼いでいた者には、居場所が無いから別の職種に転業すべきかなぁ

8 ：デフォルトの名無しさん：2022/08/29(月) 19:33:16.23 ID:iMDvJogZ.net

>>7
TS、Go、Kotlinはいたるところで使われてるから、すでに現行言語では？

9 ：デフォルトの名無しさん：2022/08/29(月) 19:46:28.38 ID:vWUiNEGz.net

AWSがプログラミング言語「Rust」を使っている理由
https://japan.zdnet.com/article/35183866/

Amazon Web Services（AWS）は、同社のエンジニアたちがプログラミング言語「Rust」を
使っている大きな理由として、エネルギー効率の高さを挙げる。
AWSは早くからRustを採用し、GoogleやMicrosoftとともにRust Foundationの創設にも携わった。
現在もRustの普及に熱心に取り組んでいる。

AWSのソフトウェアエンジニアで、Rustの普及に取り組む、
Shane Miller氏と主任エンジニアのCarl Lerche氏の投稿によれば、
Rustはメモリー安全性を高め、セキュリティ関連の不具合を減らす役に立つだけでなく、
PythonやJavaよりもはるかに「エネルギー効率に優れている」という。
Amazonは、2025年までにデータセンターの100％を再生エネルギーでまかなうという目標を掲げ、
データセンターの環境負荷の軽減に取り組んでいる。
Rustの採用はその一翼を担うという。

Rustで構築されたAWSサービスの例としては、
コンテナーアプリ用のサーバーレスプラットフォーム「Lamba」を支える「Firecracker」、
「Amazon Simple Storage Service（S3）」「Amazon Elastic Compute Cloud（EC2）」、
コンテンツ配信ネットワーク「Amazon CloudFront」、
LinuxベースのコンテナーOS「Bottlerocket」がある。

「CやRustが他の言語よりもエネルギー効率に優れていることに驚きはない。
衝撃的なのは、その違いの大きさだ。CとRustを広範に採用すれば、
控えめに見積もってもコンピュートに使用されるエネルギーの量を50％削減できる可能性がある」と
Miller氏は述べ、その根拠として、C、GoogleのGo、Lua、Python、Ruby、Fortranなどをはじめとする
複数の言語のエネルギー効率を相対的に示した研究結果を紹介している。

10 ：デフォルトの名無しさん：2022/08/29(月) 20:29:24.84 ID:bPAqKnWj.net

>>8


そういった系統の言語は、
業務で使用した事が無いから知りませんね。

11 ：デフォルトの名無しさん：2022/08/29(月) 20:37:11.19 ID:bPAqKnWj.net

>>9

Lambdaといえば、Common Lisp だな。

LISP - Lambda Functions

12 ：デフォルトの名無しさん：2022/08/30(火) 08:16:39.53 ID:6rcI0yHq.net

>>9
AWSていつのまに会社になったの？

13 ：デフォルトの名無しさん：2022/08/30(火) 09:39:41.83 ID:AsY/BIgk.net

文末がセミコロンで終わらない言語は流行らない

14 ：デフォルトの名無しさん：2022/08/30(火) 09:45:30.28 ID:lk52xXWB.net

>>13
それなー

15 ：デフォルトの名無しさん：2022/08/30(火) 09:52:15.23 ID:hK2QX/pR.net

Pythonはセミコロン非推奨だが。

16 ：デフォルトの名無しさん：2022/08/30(火) 12:29:02.78 ID:OnpgRnR2.net

matzは構文に人間が寄り添うのではなく構文解析を言語が頑張るべき的なことを言ってたけど、現実は構文は厳格にしてformatterやlnterが曖昧さのないコードに導いてやるのが正解になってきたね。

人間なんてどこまでも適当な事をやらかせるんだから、それを実行時にうまく解釈してやるのは無理筋。

17 ：デフォルトの名無しさん：2022/08/30(火) 12:39:56.18 ID:BpLonSBR.net

>>16
構文の厳格さもformatterもlinterも関係ないじゃんw
頭悪過ぎる

18 ：デフォルトの名無しさん：2022/08/31(水) 00:25:17.21 ID:h52EUFtB.net

Pythonは当初の頓珍漢な理想を捨ててpython2を見捨てなかったのがえらいんだよ

19 ：デフォルトの名無しさん：2022/08/31(水) 16:57:16.44 ID:nshUFjI3.net

Rustを自分には向いてないと言った（恐らく本人は批判したつもりはない）一生懸命にmatzを叩くRust新興カルトが気持ちわる杉る....
CやC++でバリバリ書いてる人に所有権チェックなんて邪魔すぎるし、配列境界チェックだって速度が出ない足を引っ張る機能にしか見えないだろ
今は固定範囲の配列アクセスのチェックなんかは省略してるかもしれんが、恐らくそんな事はない（全てに係るから安全だと大口する）

20 ：デフォルトの名無しさん：2022/08/31(水) 18:05:12.54 ID:0pp++Yd3.net

matzは静的型付け言語は
変数に型定義を書きまくるのが面倒くさい
というようなとこを言ってて
型推論とか知ってるくせにそれは
無いんじゃねと思ったな

21 ：デフォルトの名無しさん：2022/08/31(水) 18:25:03.72 ID:Fgf/9Zy6.net

CやC++で困ってない人に無理にrustを勧めてくる人は相手しなくて良いよ

22 ：デフォルトの名無しさん：2022/08/31(水) 18:30:28.99 ID:kXQrZaUS.net

matzのおかげでプログラミング文化が進化したのはのは間違いない
RustもRuby文化のいい面をかなり受け継いでいる

23 ：デフォルトの名無しさん：2022/08/31(水) 18:32:18.02 ID:SRFkQuBk.net

>>19
所有権チェックって何？
そんな用語も概念も存在しない

配列境界チェックは
例えばインデックス値をforでループに回したとしても
最適化によりforでのチェックだけになり
インデックスを使った配列やスライスへのアクセス時に再びチェックすることはない
つまりC言語と同じになる

>>21
困ってる困っていないの問題ではない
回避策が確立されたのに欠陥言語を使い続けるか否かの問題
人間は必ずミスを起こしうる、との結論が出ていて
大手IT企業も挙ってRustを採用している

24 ：デフォルトの名無しさん：2022/08/31(水) 18:35:01.88 ID:Fgf/9Zy6.net

>>23
Rustこそが銀の弾丸って主張かな？

25 ：デフォルトの名無しさん：2022/08/31(水) 18:36:59.70 ID:Fgf/9Zy6.net

みんな所有権所有権言うけど、初学者がひっかかりがちなのって借用の方では
所有権というとRAIIの方を連想してしまうけど
C++でmove使いこなしてた人ならRustの所有権ではひっかからないだろうし、他の言語でもtry-with-resourcesとか類似の概念あるよね

26 ：デフォルトの名無しさん：2022/08/31(水) 18:55:37.66 ID:hNAJwBIT.net

うちの会社にもPHPで困ってないからと言いながらゴミを作り続けるおっさんいるわ

27 ：デフォルトの名無しさん：2022/08/31(水) 19:25:46.59 ID:Fgf/9Zy6.net

>>26
そういうおっさんが業務の阻害要因になってるならなんとかした方が良いけど
掲示板上でどういう問題抱えてるかすら分からない相手に闇雲に勧めるのとは全然違うよね

28 ：デフォルトの名無しさん：2022/08/31(水) 19:48:33.02 ID:SRFkQuBk.net

>>26
PHPは>>9の記事の観点からはエネルギー効率の悪い劣った言語かもしれないが
C/C++が現実に大量のセキュリティの穴も含むメモリ管理バグを引き起こし続けている危険な欠陥言語である点とは大きな開きがある

29 ：デフォルトの名無しさん：2022/08/31(水) 19:56:05.14 ID:D6khOQ0c.net

>>27
おっさん自身は問題を理解できてないってことを言ってるんだよ

30 ：デフォルトの名無しさん：2022/08/31(水) 19:56:39.74 ID:bi3oBo/Y.net

どんなに優れたプログラマーでもミスをするしバグも作るって考え方は大事だと思うけどな

31 ：デフォルトの名無しさん：2022/08/31(水) 19:58:59.48 ID:mLZrYK8Z.net

#define new old
で、全て解決では？

32 ：デフォルトの名無しさん：2022/08/31(水) 20:04:50.79 ID:mLZrYK8Z.net

でもウェブサイトの9割はPHPで出来てると言うからなあ。

33 ：デフォルトの名無しさん：2022/08/31(水) 20:33:48.91 ID:TBd/y3ES.net

PHPを馬鹿にするやつにその資格はない
PHPの作者を馬鹿にするやつにその資格はない
PHPよりも作者よりも糞なやつが鏡すら見ずに薄ら笑ってる

34 ：デフォルトの名無しさん：2022/08/31(水) 20:38:28.28 ID:PQ5q9d58.net

>>26
ゴミって言ってもそれでお金稼いでいる訳じゃなくて？

35 ：デフォルトの名無しさん：2022/08/31(水) 20:55:36.71 ID:bW00GV9W.net

>>24
んなこと言ってねーだろ。
ミスリードすんな。

36 ：デフォルトの名無しさん：2022/08/31(水) 21:00:04.57 ID:mLZrYK8Z.net

Haskellが見向きもされなくなったら、Rustの宣伝が増えたな。

37 ：デフォルトの名無しさん：2022/08/31(水) 21:11:47.88 ID:SRFkQuBk.net

>>36
宣伝？
例えば>>9の記事はクラウドのシェアトップであるAWSがそのサービス提供にRustを使って構築しているという現実の話
着実に様々なインフラがRustベースへと置き換わっていく現実の一つ

38 ：デフォルトの名無しさん：2022/08/31(水) 21:22:47.94 ID:10xvEXEy.net

Rust(笑)　時代はJavaだから

求人倍率はなんと21.8倍　「Java」を求める企業が絶えない理由とは
https://atmarkit.itmedia.co.jp/ait/articles/2208/31/news049.html

39 ：デフォルトの名無しさん：2022/08/31(水) 21:28:47.20 ID:h52EUFtB.net

限られた情報から善と悪を判断できない人達が
まだ公開されていないクソどうでもいいデータを欲しがる

40 ：デフォルトの名無しさん：2022/08/31(水) 22:11:23.35 ID:tQxzKhe2.net

オラクルに丸め込まれた会社本当にかわいそう

41 ：デフォルトの名無しさん：2022/08/31(水) 22:21:51.07 ID:PDiBd7bz.net

今日Helidonなるものを初めて知ったわ
オラクル足掻いてるよねー

42 ：デフォルトの名無しさん：2022/08/31(水) 23:06:38.28 ID:1xLvm1yy.net

rustは死産だったんだよ
このスレで頑張ってるのは水子供養みたいなもん

43 ：デフォルトの名無しさん：2022/08/31(水) 23:15:56.00 ID:V71AUGNS.net

Facebook、開発言語に「Rust」採用　Javaからも移行
https://www.itmedia.co.jp/news/articles/2107/28/news152.html

Rustを用いることで、どのような利点があるのか。
Facebookは記事の中で次の4つの項目を挙げています。

①Rustのasync/awaitシンタックスは、非同期のコードをとてもスムーズに記述できますし、
Rustは複雑な並行処理の詳細を正しく理解するのに役立ちます。
BuckのJavaの計算を一つ一つ並行処理に移行するのは数カ月に及ぶ困難な作業でしたし、
シングルスレッドの大きなボトルネックがまだ存在しています。

②Rustには、開発をより簡単で楽しいものにしてくれる多くの高レベルな言語機能があります。
それらはenum、パターンマッチング、trait、手続き型マクロなどで、
Rustの開発者の多くに愛されています。

③Rust はメモリの割り当てをより細かく制御することができます。
ガベージコレクションのある言語では、たとえジェネレーショナルコレクションであっても、
Buckが行うようなインクリメンタルな演算に対応するのは困難です。

④Rustは高性能です。
Rustに移植することで劇的な性能向上を私たちは見てきました。

44 ：デフォルトの名無しさん：2022/08/31(水) 23:21:00.54 ID:Fgf/9Zy6.net

>>35
いやいやC++で書かれたプログラムは無条件にRustで置き換えられるって主張は銀の弾丸って言ってるのと同じでしょ

45 ：デフォルトの名無しさん：2022/09/01(木) 00:44:24.52 ID:cwSyLQRT.net

善行を勧めることと、善行が必勝法であると主張することを区別する必要がある

46 ：デフォルトの名無しさん：2022/09/01(木) 07:30:51.13 ID:F4Y0rM7S.net

>>23
「最適化によりforでのチェックだけになり・・・つまりC言語と同じになる」
はい、明確すぎる嘘、Cは普通処理系によりけりだが通常は配列境界のチェックなんてしません。あほかｗなにが、つまりだｗ
必死すぎるのがほんと痛々しい

47 ：デフォルトの名無しさん：2022/09/01(木) 07:32:21.78 ID:fyMKlXgD.net

所有権を邪魔だと思ってる奴のC++コードは読みたくねえな
一緒に仕事したくねえ……

48 ：デフォルトの名無しさん：2022/09/01(木) 07:51:48.00 ID:TMFOnHT0.net

>>46
インデックス値でforループを回すとあるから
C言語でもループ1回に付き必ず1回のインデックス値の境界比較が必ず入るよ
境界チェック無しでforを回したら無限ループになる

49 ：デフォルトの名無しさん：2022/09/01(木) 07:57:15.00 ID:F8jNf2Yy.net

>>48
Cって、配列のインデックスアクセスに境界チェックとか無くて、プログラマに委ねられているのかと思ってた。Cも意外に安全性を気にしているんだね。

50 ：デフォルトの名無しさん：2022/09/01(木) 08:33:34.02 ID:5fR61KJN.net

>>38
javaのフレームワークって何使ってるの？

51 ：デフォルトの名無しさん：2022/09/01(木) 09:37:58.04 ID:wgtUDrt5.net

>>44
その通り
条件を絞って
予めRustに移植することを意識して描かれたC++のソースのみ自動変換出来る
なら正しいかも知れない

52 ：デフォルトの名無しさん：2022/09/01(木) 09:39:23.27 ID:wgtUDrt5.net

>>44 追加
ちなみに漏れは
「Rustに移植することを意識して描かれたC++のソース」
ならC++のままでええやん？的な立場

53 ：デフォルトの名無しさん：2022/09/01(木) 09:41:17.41 ID:wgtUDrt5.net

>>48 はCを知らない素人以下

54 ：デフォルトの名無しさん：2022/09/01(木) 09:48:59.81 ID:5fR61KJN.net

>>49
たぶん間違って読解してる。
良くも悪くも日本語って主語省略しちゃうからね。

55 ：デフォルトの名無しさん：2022/09/01(木) 09:50:52.96 ID:NH2cx+n6.net

>>53
え？
>>48で合ってるだろ
インデックスforループは境界比較しないと止まらん

56 ：デフォルトの名無しさん：2022/09/01(木) 09:57:04.30 ID:oWUbfflz.net

>>55
配列のインデックスチェックってここではモダンな言語は配列外にアクセスすると実行時エラーになるということを言ってるんだよ
Cはエラーじゃなく未定義だから何が起こるかわからん

57 ：デフォルトの名無しさん：2022/09/01(木) 09:57:34.15 ID:oWUbfflz.net

実行時じゃないわ
コンパイルエラーね

58 ：デフォルトの名無しさん：2022/09/01(木) 09:59:00.80 ID:oWUbfflz.net

いや動的配列ならやっぱ実行時か
どっちにしてもCみたいに変更しちゃいけないところを変更して暴走しないってこと

59 ：デフォルトの名無しさん：2022/09/01(木) 10:09:23.03 ID:flNKFTp5.net

>>56
元の話は>>23だからインデックス値のforループ
C言語でも他でもfor文で境界チェックが必ず入る

配列アクセス時はまた別の問題
Cならばチェックしないがfor文でチェック済なので安全上の問題なし
Rustならばチェックするがfor文でチェック済なので最適化によりここでのチェックは消えて問題なし

結果としてCでもRustでも同じ生成コードとなる

60 ：デフォルトの名無しさん：2022/09/01(木) 10:23:52.21 ID:oWUbfflz.net

>>59
動的配列のランダムアクセス時にC言語では入らない境界チェックが入るな

61 ：デフォルトの名無しさん：2022/09/01(木) 10:30:39.30 ID:KHPE1b9m.net

>>59
日本語で説明するよりコードと生成されるアセンブリ見せた方がわかりやすいのでは

62 ：デフォルトの名無しさん：2022/09/01(木) 10:31:44.69 ID:0sJGxogX.net

forループの例では同じ生成コードとなるが
範囲内かどうか不明なインデックス値がやってきてそれで配列をアクセスする場合は違いが出る

C/C++
プログラマーの自己責任で境界チェックを手動でしなければならない
忘れたときは未定義動作となりうるため危険

Rust含むその他の言語
プログラマーは気にせずとも自動的に境界チェックされるため安全

63 ：デフォルトの名無しさん：2022/09/01(木) 11:17:36.46 ID:nJgMln8j.net

>>43
もうRustの覇権確定だなｗ

64 ：デフォルトの名無しさん：2022/09/01(木) 12:16:04.06 ID:tWaffXfX.net

その技術を作られたのがこれか
https://i.imgur.com/ymYXnQr.jpg

65 ：デフォルトの名無しさん：2022/09/01(木) 12:46:30.05 ID:GpP6p1Yr.net

>>62
？？
範囲forは？

66 ：デフォルトの名無しさん：2022/09/01(木) 13:36:52.33 ID:wgtUDrt5.net

>>59
>Cならばチェックしないがfor文でチェック済なので安全上の問題なし

doubt
マジで言ってるなら去ね

67 ：デフォルトの名無しさん：2022/09/01(木) 19:55:15.23 ID:K2svajoy.net

>>66
forでインデックスの境界チェック済みとあるから
配列のアクセス時に再び境界チェックしなくても安全でしょ

68 ：デフォルトの名無しさん：2022/09/01(木) 20:39:52.39 ID:Wlby5VAy.net

いや、for文でのループ条件とか書き間違えてバグる筆頭だろ。
人力チェックの限界が見える典型。

69 ：デフォルトの名無しさん：2022/09/01(木) 21:06:01.62 ID:ms47s476.net

Rust方式が速さと安全の両立でベストだろう
基本的には配列(スライス)アクセス時にインデックス境界チェックが行われて必ず安全
その上でインデックスforなどでループ内のアクセスがコンパイラにより安全と保証できる場合は
最適化によりループ内の配列(スライス)アクセス時にインデックス境界チェックが無くなり速さと安全を両立

70 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>38
単価の中央値は？

71 ：デフォルトの名無しさん：2022/09/01(木) 22:04:15.15 ID:cwSyLQRT.net

もしもポインタが組み込み型ではなく外部のライブラリだったら
ライブラリを変更するだけでCはそこそこ安全になれた

C++はスマートポインタを追加することはできても
元からあるポインタ型を改善することは全然できなかった

72 ：デフォルトの名無しさん：2022/09/02(金) 00:56:06.09 ID:itc/vw5Y.net

>>69
slice::Iterは<[] as Index>::index使わないから最適化関係なく境界チェックは一度だけになるが

73 ：デフォルトの名無しさん：2022/09/02(金) 05:54:25.85 ID:shSg4CAC.net

>>59
痛いRustおじさんの代表例だね、境界チェックが必ず入る処理系があったとしてそれを、C言語は！なんて表現しないぞ？
「結果としてCでもRustでも同じ生成コードとなる 」絶対ならないからｗつーかアセンブラして貼り付けろよ？
それで常に100%が誰がやってもどのバージョンでもどの環境でも同じならあんたが正しい
そもそも配列ループの遅さをカバーするためにRustは速度を稼ぐために一部分ループ展開を勝手にするはずなので、gccとかなら
O2ではダメでO3でfunroll-loopsでコンパイルしないとならないよ

74 ：デフォルトの名無しさん：2022/09/02(金) 07:47:28.70 ID:h0CkE7tZ.net

>>72
もちろんRustはイテレータが強力だから
インデックスで回すよりもイテレータ利用が断然に多く
スライス(配列)アクセスに境界チェックを毎回しないのはおっしゃる通りだが
様々な理由でイテレータではなくインデックスでforで回す場合もあり
その時ですらforの終端チェックのみで最適化によりスライス(配列)アクセス時の境界チェックは消えている
という話だから両立する話

75 ：デフォルトの名無しさん：2022/09/02(金) 07:51:35.38 ID:h0CkE7tZ.net

>>73
配列ループで遅いなんて聞いたこともなく実際に遅くなっていない
何を根拠にそんなデタラメで叩いているのだろうか

76 ：デフォルトの名無しさん：2022/09/02(金) 08:11:51.41 ID:yReiMthF.net

他言語の範囲forとかイテレーターを無視して「Rustのforが一番」とかいうのは無知を通り越して無能。
「C++のforループは危険」というのはさすがに引っ込めたみたいだけど、cのforループと比較してRustを褒めるのは邪悪すぎるだろ。

77 ：デフォルトの名無しさん：2022/09/02(金) 08:20:26.86 ID:xKAOCFMw.net

>>76
みんなが話しているのは配列アクセスの安全と速さ
forはその時に出てくるだけであってfor自体の比較を誰もしていない
そこに優劣もない

78 ：デフォルトの名無しさん：2022/09/02(金) 08:36:58.81 ID:yReiMthF.net

>>77
その割にはforの安全チェックとか持ち出しているやついるけど。
それに配列ならコンパイル時にサイズが決定する／しないで全然違うけど、そこをごっちゃにしているアホがいない？

79 ：デフォルトの名無しさん：2022/09/02(金) 09:00:49.10 ID:r2oaJ0uT.net

ほんとダメだねえ、どうやっても遅いんだが？顔真っ赤にして人を罵倒する前にさ
https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=f46924c1a775bf93703ca7aead58b36c
real 0m0.111s
https://wandbox.org/permlink/iP4fPQ7bODKrg7mC
real 0m0.006s

「C言語でもループ1回に付き必ず1回のインデックス値の境界比較が必ず入る」
まず根本的に勘違いしてるのがあなたの言ってるのは境界チェックじゃなく、終了条件のチェックであり、これも、gccなどの処理系では
最適化で固定値だったりしてループ展開したら必ず入るとは限らないんですよ・・・同様のことがRustの勝手にループ展開でも言えますが
いずれもループ終了チェックであり、そんなのは比較していませんし、またあとから出てきたイテレータの話は全く違う話ですね

80 ：デフォルトの名無しさん：2022/09/02(金) 09:05:50.01 ID:kItyetcb.net

>>78
批判するにはちょっと知識不足すぎじゃない？
みんなが書いているRustのスライスはコンパイル時に長さが確定しないから、確定する配列だけでなく、どちらの場合でも大丈夫ってこと

81 ：デフォルトの名無しさん：2022/09/02(金) 09:13:12.31 ID:AlmyaYR1.net

前スレでも出てたけどrustがphpより遅いってマジっぽいね

82 ：デフォルトの名無しさん：2022/09/02(金) 09:17:24.54 ID:NtJICGnn.net

>>79
あまりにキチガイでワロタ
その約20倍差の数値で比較しちゃってるのかよ
本気で20倍速いと思い込んでる？

83 ：デフォルトの名無しさん：2022/09/02(金) 09:24:36.61 ID:r2oaJ0uT.net

>>74
レス番つけ忘れたけど、頑にCと（速度が）同じだ。遅くないというカルト信者みたいな態度はほんと反省してほしいわ・・・
根拠を示したのにキチガイと反論するばかりで、こんな簡単なプログラムにさえどこが悪いのか言えないし

84 ：デフォルトの名無しさん：2022/09/02(金) 09:32:20.12 ID:r2oaJ0uT.net

誰も20倍速いなんて一言もいってませんが？timeごときでこの程度の差が出るのであれば、「同じ」なんて言えないと思いますが？
むしろ境界チェックが機能してる結果であり、一方でCはそのような境界チェックは通常の処理系ではありえない＝チェックがないので
安全性はlintなどやプログラマーの能力に依存する
提言：”内容に反証を提示できず、人をキチガイ呼ばわりする人がキチガイ”

85 ：デフォルトの名無しさん：2022/09/02(金) 10:07:22.38 ID:3EJXZ/Ye.net

> C言語でも他でもfor文で境界チェックが必ず入る

std::vectorだと両方あるから説明しやすいけど

reference at(size_type n);
　n >= size()の場合、out_of_range例外を送出する。

reference operator[](size_type n);
　vector型のオブジェクトvに対して、v[n] と *(v.begin()+ n) は同じ結果になる
　n >= size()の場合、未定義動作となる
　この関数は、at()メンバ関数とちがって境界チェックを行うことが規定されない。

境界チェックってこれの話じゃないの？
index側のどうこうはさておき、要素アクセスのときにケアできてるかどうかの話じゃないの？

86 ：デフォルトの名無しさん：[ここ壊れてます] .net

ちなみにJavaのjava.util.Listは

https://docs.oracle.com/javase/jp/8/docs/api/java/util/List.html#get-int-
E get(int index)
　例外: IndexOutOfBoundsException - インデックスが範囲外の場合(index < 0||index>= size())

となってる。

87 ：デフォルトの名無しさん：[ここ壊れてます] .net

現代のCPUなら投機的実行で境界チェックみたいな処理は時間コストかからんけどなあ
それとRustのprintln!は非バッファでロックもするから配列性能計測に混ぜたらいかんでしょ
性能計測の初歩だと思うんだけど

88 ：デフォルトの名無しさん：[ここ壊れてます] .net

ここが応仁の乱か

89 ：デフォルトの名無しさん：2022/09/02(金) 11:14:19.45 ID:RkYzNFi/.net

Rustのスライスsでfor i in 0..s.len()でループ回して見たら
生成コードはforの終端チェックだけになってs[i]の境界チェックは消えるんだな
確かに論理的に正しい最適化だが賢いな
結局Cでfor (i = 0; i < len; i++) とした時と同じ

90 ：デフォルトの名無しさん：2022/09/02(金) 12:00:55.17 ID:kDm3gkwV.net

println!取り除いてもCより遅いけど？
勝手にコードを変更してs.lenとか悦にはいってるし、この人たちって絶対objdumpした結果を上げないね
同じ（＝100%一致）なんて絶対あり得ない、gccじゃなくclang/llvmにしたら分らんけど、それでも
”Ｃ言語は”なんてあんたさえも知らない処理系があるのに恥ずかし気もなくビックマウス披露出来るわけない
投機実行の境界チェックのバイパスは有名なスペクターとして脆弱性だから機能してないんちゃうか？知らんけどさ

91 ：デフォルトの名無しさん：2022/09/02(金) 12:40:37.54 ID:omdV4spc.net

>>80
固定長なら範囲チェック自体消えるだろ。

Rustの話をするなら、「ひとつの読み書き参照 xor 複数の読み取り参照のきっつい制約を課すことで範囲チェックの回数を減らしている」くらいの説明はできんのかね？オレも詳しくはないが。

92 ：デフォルトの名無しさん：2022/09/02(金) 18:35:42.02 ID:itc/vw5Y.net

引数で与えられた配列の中の最大要素をインデックスアクセスで探す関数をC (clang 14) と Rust (rustc 1.63.0) で書いた
使ってるレジスタこそ違うけど同じコンパイル結果になった

https://godbolt.org/z/TvdGf3dYq

Rust は他の書き方も試してみたけど生成されたコードは同じっぽい

forでsliceをイテレートした場合:
https://godbolt.org/z/38s1819hr
イテレータアダプターだけで書いた場合:
https://godbolt.org/z/cjqqYjKfE

93 ：デフォルトの名無しさん：2022/09/02(金) 19:48:54.34 ID:SRTIVbJR.net

っつーか今さらcでの開発なんて小規模じゃないとやりたくないわ。

94 ：デフォルトの名無しさん：2022/09/02(金) 20:22:00.68 ID:AlmyaYR1.net

遅いくせにCと同等とか言い出したのが発端じゃね？

95 ：デフォルトの名無しさん：2022/09/02(金) 20:51:46.96 ID:eOJxFMTK.net

>>92
凄いな
CとRustは同じ生成コードになるんだな
どちらも64バイトでループ展開か

96 ：デフォルトの名無しさん：2022/09/02(金) 20:58:00.60 ID:eOJxFMTK.net

>>94
生成コードが同じだからCとRustは速さも同等っぽい

97 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>96
マジか、rustすご過ぎ

98 ：デフォルトの名無しさん：2022/09/02(金) 21:41:46.84 ID:TRifMPKk.net

わざわざ境界値チェックが不要になるケースで比べたらそりゃそうだろって感じ
最初のサンプルコードが酷すぎた

99 ：デフォルトの名無しさん：2022/09/02(金) 21:45:38.80 ID:SRTIVbJR.net

>>98
境界値チェックが必要なケースをよろ

100 ：デフォルトの名無しさん：2022/09/02(金) 22:15:29.02 ID:ZICl4sMk.net

結論が出たな
Rustを攻撃してた人が以下のようなウソをついてた

> 「結果としてCでもRustでも同じ生成コードとなる 」絶対ならないからｗ
> つーかアセンブラして貼り付けろよ？

> そもそも配列ループの遅さをカバーするために
> Rustは速度を稼ぐために一部分ループ展開を勝手にするはず

生成アセンブラコード>92を見ると
CでもRustでも同じ生成コード
CもRustもループ内のインデックス境界チェックは無く同じコードとなっている
そしてCもRustも一部分ループ展開を同様にしてる
当然どちらも同じ速度となる

101 ：デフォルトの名無しさん：2022/09/02(金) 22:58:49.99 ID:SRTIVbJR.net

>>98
早くc言語で境界値チェックするコード出してよ。

102 ：デフォルトの名無しさん：2022/09/02(金) 23:27:03.89 ID:lqMLDpPB.net

全然読まない、勝手にコードを変更してs.lenとか悦にはいってる

103 ：デフォルトの名無しさん：2022/09/02(金) 23:59:11.14 ID:VC9smmde.net

>>102
配列やベクタやスライスなどを一般的に
C言語で扱う関数ならば先頭ポインタと長さを受け取る
Rustならばその二つがペアとなったスライスsを受け取りその長さ部分がs.len()
だから常識的なプログラマーならば誰が書いても>>92のソースコードとなる
そして生成アセンブラコードがCとRustで同等と判明した

104 ：デフォルトの名無しさん：2022/09/03(土) 01:19:34.52 ID:txSLq0y3.net

おじさん普通にC勉強した方が良いよ
Rust書ける人でC書けない人なんていないからズレまくった指摘してるんだよ
Rustであえてパフォーマンス出ないようなコードを書いてるとしか思えない

105 ：デフォルトの名無しさん：2022/09/03(土) 01:46:36.01 ID:2EHZBEma.net

>>92のシンプルなコードをこれ以上に速くするのは無理じゃね
そしてRustもCも同等のアセンブリコードを吐いてるから実行速度も同じで勝負ついた感じだな

106 ：デフォルトの名無しさん：2022/09/03(土) 03:19:04.56 ID:DRQBO0l9.net

バカ野郎！
Rustのおっちゃんは、日本を代表するトライアングル（楽器）奏者なんだぞ！

107 ：デフォルトの名無しさん：2022/09/03(土) 04:44:36.86 ID:22c5U/VG.net

少なくとも配列範囲外アクセスするようなコードで比べなければ意味がない。
誰も勝負なんてしてないだろ
こんな事やってるからRustを嫌う人が割と増えていく、言い逃れそのものだろｗ

そもそもforの終了条件チェックと配列境界チェックの違いすら分かってないやつだ
カルトRust信者「C言語でもループ1回に付き必ず1回のインデックス値の境界比較が必ず入る」

固定長のループがclang/llvmで同じになったとして、壺カルトRust信者曰く、「C言語は」という
デカすぎる主語と、Rustでのすべての配列境界チェックが無くなるわけではなし何が勝ちなんだか...

108 ：デフォルトの名無しさん：2022/09/03(土) 05:27:05.78 ID:lg2jZ6dQ.net

>>107
コードを読めない人なの？
固定長のループではなく長さは関数の引数として与えられている
したがってC言語でもループ1回に付き必ずインデックス値の境界比較(＝インデックス値が長さを超えないこと)がfor文の条件部で行われている

109 ：デフォルトの名無しさん：2022/09/03(土) 06:17:52.84 ID:Xvi3nnOL.net

>>92
例えばinline化とかで二つの配列/スライスがエイリアスされていることがコンパイラー(とプログラマー)に見えている場合があると思うんだけれど
Rustの方は自動ベクトル化してくれないのね。Cの方は自動ベクトル化されている。

極端に書くとこんな感じ。
ttps://godbolt.org/z/sbenoGEEa

inline
ttps://godbolt.org/z/M6qz3s3f7

max_value_slice_vwをどう書いたら自動ベクトル化されるの?

110 ：デフォルトの名無しさん：2022/09/03(土) 06:38:25.68 ID:peyYEDe5.net

何の争いかよくわからんけどつまりRustでサイズ10の配列を作ってその11番目の要素にアクセスしたらどうなるん？
Cだと境界チェックしないから未定義になるしセグフォ出たり他の変数を書き換えたり暴走したりすることもある

111 ：デフォルトの名無しさん：2022/09/03(土) 06:40:51.52 ID:peyYEDe5.net

11というのをリテラルで与えるともしかしたらコンパイルエラーになるかもしれんけどたとえばそれを乱数で生成した場合はどうなんの？

112 ：デフォルトの名無しさん：2022/09/03(土) 06:53:51.31 ID:peyYEDe5.net

Cが境界チェックしないと言うのは境界チェックがプログラマの責任だということだよね
Rust以外のモダンな言語では大抵範囲外の要素にアクセスしようとすると実行時例外を吐く
Cはそれをせず黙って暴走したりこっそり他の変数の値を書き換えたりして気づきにくいバグになる
Rustはどっち？

113 ：デフォルトの名無しさん：2022/09/03(土) 06:56:12.20 ID:TWgTITK1.net

>>109
わざわざw = v; とか
架空コードすぎて気持ち悪い

114 ：デフォルトの名無しさん：2022/09/03(土) 07:06:18.00 ID:z9CaUV9k.net

>>112
Rustは基本的には他の大多数の言語と同じで、アクセスする前に自動的にインデックスの境界チェックをする。

ただし、>>92などのように多くのプログラム利用例では、インデックスはforで指定範囲を動くため、アクセスする際のインデックス境界チェックは最適化により必要とせず行われなくなり、結果としてC言語と同じアセンブラコードが生成される。

115 ：デフォルトの名無しさん：2022/09/03(土) 07:13:36.64 ID:z9CaUV9k.net

つまり、Rustは安全性を常に保ちつつ、不要な境界チェックは最適化で無くすことで、安全かつ高速を実現。

116 ：デフォルトの名無しさん：2022/09/03(土) 07:29:39.97 ID:peyYEDe5.net

>>114
普通じゃね？

117 ：デフォルトの名無しさん：2022/09/03(土) 07:34:10.00 ID:/y6fxgdJ.net

CとRustは同じアセンブリコードを生成すると>>92で示されているから
あとは他の言語でもそうなるならそれを示せばよい

118 ：デフォルトの名無しさん：2022/09/03(土) 07:37:07.45 ID:lGqTIi1A.net

どうでもいい内容で盛り上がってるな
for文の仕様がボトルネックになることなんかないんだからどうでもいい

119 ：デフォルトの名無しさん：2022/09/03(土) 07:46:39.87 ID:1xBXpDYn.net

例えばfor (i=0;i<len;i++) arr[i*2]=0;
Rustはこの時もCと同じコードになるんだよね？

120 ：デフォルトの名無しさん：2022/09/03(土) 07:56:47.99 ID:mdxH418+.net

gccのコミッターのものだけどそんな単純な話じゃないよ
Rustのスティーブとはよく話をするけどね

121 ：デフォルトの名無しさん：2022/09/03(土) 08:03:29.06 ID:peyYEDe5.net

最後の一行で胡散臭さ出てくるの何なん

122 ：デフォルトの名無しさん：2022/09/03(土) 08:04:34.15 ID:2bPWyV3b.net

まあこんなマイクロコードの比較だのベンチだのに意味は無いわな
コンパイラも局所だけ見て処理するわけでもなし

123 ：デフォルトの名無しさん：2022/09/03(土) 08:23:27.57 ID:04g55wUA.net

>>119
Rustのfor文はそういう構文ではない
あとRustではその処理関数は引数をスライスxで受けることになり
lenはx.len()となる

そしてfor i in 0..lenのループの時
x[i] = 0ならばそのアクセスには境界チェックは最適化により生じない　(C言語と同じ)
x[i*2] = 0ならばそのアクセスには境界チェックが入りindex out of boundsとなる　(C言語と異なる)

124 ：デフォルトの名無しさん：2022/09/03(土) 08:27:29.75 ID:1xBXpDYn.net

>>123
境界チェックがあるって言われてるのはその場合のことだよ
最適化で無くなる時の話をしてるのは君だけじゃないかな多分

125 ：デフォルトの名無しさん：2022/09/03(土) 08:47:00.60 ID:pNlcpp9D.net

rust書けるやつはたいていcも書ける。
cは書けるがrust書けないなつはいる(俺とか)。
両方書けるほうがいいに決まってる。

126 ：デフォルトの名無しさん：2022/09/03(土) 08:47:14.13 ID:oioC2Qy2.net

>>123
後者はC言語だと範囲外をアクセスしてしまい破綻だな
境界チェックをするRustが正しい

127 ：デフォルトの名無しさん：2022/09/03(土) 09:09:01.93 ID:YIfnpCsY.net

>>124
正しい使用ならば最適化されて境界チェックが消える点も重要やで
それによりRustのコードがCとほぼ同じ速度で動いている

一方で間違った範囲外のアクセスが起きうる場合には境界チェックがなされる点も重要やで
それによりRustはCとは異なり安全となっている

128 ：デフォルトの名無しさん：2022/09/03(土) 09:12:44.80 ID:qprMzk1R.net

>>123,126
> あとRustではその処理関数は引数をスライスxで受けることになり
> lenはx.len()となる
配列の一部だけを処理したいとか普通にあるだろ

129 ：デフォルトの名無しさん：2022/09/03(土) 09:21:53.95 ID:YIfnpCsY.net

>>128
配列の一部分はスライス　(配列全体も可)
Vecの一部分もスライス　(Vec全体も可)
スライスの一部分もスライス
なのでRustで関数を書くときはスライスを対象にして記述する
そしてスライスとして扱った時点で既に境界チェック済み(＝元の範囲内)なので最適化が可能となる

130 ：デフォルトの名無しさん：2022/09/03(土) 09:24:37.68 ID:bVYJbA7l.net

さすが複オジ隔離スレやで
今日もいい仕事しとるww

131 ：デフォルトの名無しさん：2022/09/03(土) 09:27:25.47 ID:ezD68Vvz.net

Rustの実行速度がCと同等だと何か困ることでもあるの？

132 ：デフォルトの名無しさん：2022/09/03(土) 09:30:24.03 ID:qprMzk1R.net

>>129
関数内でlenが決まる場合でもいちいちスライス作るのか？

133 ：デフォルトの名無しさん：2022/09/03(土) 09:32:15.16 ID:91ZlUxrs.net

C/C++ で BITMAPINFOHEADER なんか扱うときは
意図的に範囲オーバーさせて bmp データにアクセスするよねω株 PI.3.14

134 ：デフォルトの名無しさん：2022/09/03(土) 09:37:13.56 ID:hKLkDwrb.net

>>131
Rustアンチの人にとって「Rustは遅い！」が信仰の砦。
ところが世間で言われてる通り、RustはCとほぼ同じ速さだと>>92で分かり、大変なことになってしまって大騒ぎ。

135 ：デフォルトの名無しさん：2022/09/03(土) 09:45:26.31 ID:peyYEDe5.net

困るとか困らないとかじゃなくCではやらない境界チェックがあるから現実に遅いよ

136 ：デフォルトの名無しさん：2022/09/03(土) 09:47:19.22 ID:peyYEDe5.net

Cと同じ速度で動くコード「も」あるというならその通り
他の言語でもある

137 ：デフォルトの名無しさん：2022/09/03(土) 09:52:51.38 ID:cKT2CTgA.net

>>132
Rustのスライスは抽象化された概念で扱われるけど
実体は先頭ポインタと長さのペア
だからスライスを作るって大層なことではなくC言語で処理対象の先頭ポインタと長さを用意するのと同じ

あと、Rustではforインデックス使わずにイテレータチェーンにすることも多いけどその時もスライス起点が多い
そのイテレータチェーン利用時も>>92の下でforインデックス時と同等の生成コードになることが示されてる
つまり境界チェックは起きずC言語と同じ速さで動く

>>136
C言語より遅いコードがあると主張したいならば
具体的に>92のように生成コードの比較を出せばよい

138 ：デフォルトの名無しさん：2022/09/03(土) 09:54:03.17 ID:peyYEDe5.net

境界チェックが消えたコードじゃなく消えてないコードで比べてみたらすぐわかるんじゃないですかね

139 ：デフォルトの名無しさん：2022/09/03(土) 09:54:19.38 ID:qprMzk1R.net

>>135
コンパイルオプションでチェック無効に出来ないの？

140 ：デフォルトの名無しさん：2022/09/03(土) 09:56:34.91 ID:RRdFGJ7i.net

>>139
C#はできるね

141 ：デフォルトの名無しさん：2022/09/03(土) 09:59:58.21 ID:qprMzk1R.net

>>137
> だからスライスを作るって大層なことではなくC言語で処理対象の先頭ポインタと長さを用意するのと同じ
いや、実装は想像できるからいちいち説明してもらわなくてもいいんだけどC言語だといちいちそんなもの作らないよ
先頭ポインタも長さ情報も既にあるのに同じ内容を持つスライスを作るのは（C言語脳としては）無駄に思える

142 ：デフォルトの名無しさん：2022/09/03(土) 10:03:47.05 ID:v+XVsXaf.net

>>138
CよりRustが遅いコードを具体的に出してよ
array[i*2]の例は危険な範囲外アクセスとなるコードだから境界チェックをするRustに軍配が上がるね
だから安全な正しいコードなのにCよりRustが遅いコードを具体的に生成コードと共に出しましょう

143 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>142
プログラマが完璧なら危険ではないので上司のしりぬぐいをしないというのがCのスタンス
Rustはチェックするので正しいが遅い

あのー、わざとやってるのかバカなのかどっちなの？

144 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>141
Rustではもっと抽象的に捉えてプログラミングするからそこに無駄と考える発想は出てこないし
同じだから無駄だといっても生成コードは最適化で無駄は消えるからCと同じ速さが出るでしょう

145 ：デフォルトの名無しさん：[ここ壊れてます] .net

実例と計測結果出さないと空論でしか無いわな
まあ速度差が無くて出せないんだろうけど

146 ：デフォルトの名無しさん：[ここ壊れてます] .net

チェックが入ると遅くなるから最適化でチェック省くことがあるんだろうに何で実測しなきゃわかんないんだよ
特定のスニペットじゃなく境界チェックが入る現実のコードの話をしてるのに実測なんてできるわけないだろ
境界チェックが原因で遅くなるコード作れと言うなら作るが、それ作ったら間違いを認めるんだろうな？

147 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>144
ホントに常に消えるの？
ダメなケースは存在しないの？

148 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>143
それは君が誤解してるようにみえるなあ
Rustでは安全に範囲内のアクセスとRustコンパイラが分析できれば境界チェックをしないためCと同じ速さが出る
そうでなく危険な範囲外のアクセスになりうるとRustコンパイラが判断すれば正しく境界チェックを行なう
C言語で書いても危険な範囲外のアクセスになりうる場合は手動で境界チェックをせざるを得ないから速さは同じ

149 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>148
同じじゃなく遅くなると認めろよ

150 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>149
遅くなる具体例ありそう？それ知りたい
RustとCのアセンブリ生成コードが同等になり速さが同じとなるケースは>>92で示されてるから
同じようにして遅くなるケースを示せばよいと思う
もちろん範囲外アクセスとならない例でw

151 ：デフォルトの名無しさん：[ここ壊れてます] .net

いつもの嘘つき複オジに必死に突っかかるアホ
どっちもどっち

152 ：デフォルトの名無しさん：2022/09/03(土) 10:49:11.71 ID:qprMzk1R.net

>>148
> そうでなく危険な範囲外のアクセスになりうるとRustコンパイラが判断すれば正しく境界チェックを行なう
C言語では外部からもらったデータは仕様で配列範囲に入るのが確実だからチェックをしないとかあるんだけど、Rustコンパイラとやらは仕様書まで読み込んでくれるのかなw

153 ：デフォルトの名無しさん：2022/09/03(土) 10:52:15.27 ID:BHvUMyM5.net

境界チェックによるペナルティが気になる箇所なら境界チェックのないget_unchecked使えば良いのでは
デフォルトは安全側に倒されてるけどプログラマの裁量で速度を優先することもできるので、適材適所でどちらを使うか選べば良い
C++でも境界チェックありのat()があるから、デフォルトが逆なだけでできることは同じだよね

154 ：デフォルトの名無しさん：2022/09/03(土) 11:03:40.39 ID:7pWn865H.net

結局プログラマーの手に委ねていると必ずミスが起きうるから
境界チェック省略の件も含めて全てについて
コンパイラが分析して安全かどうか判定できた時にはチェックを省略し
そうでない場合は安全のために自動的にチェックをするのがベスト
という方向へ向かっているんじゃないかな

GoogleやMicrosoftがRust言語でOS開発
https://xtech.nikkei.com/atcl/nxt/column/18/00692/042700054/
【脆弱性の70％がメモリー管理バグに起因】
GoogleによればAndroidに存在した深刻なセキュリティー脆弱性の70％近くがメモリー安全に関するバグに起因するという。
同様にマMicrosoftも、同社製品に存在したセキュリティー脆弱性の70％がメモリー安全に関するバグに起因すると述べている。
C/C++を使う限りセキュリティー脆弱性を根絶するのは不可能と考えて、Rustを採用するに至ったというわけだ。

155 ：デフォルトの名無しさん：2022/09/03(土) 11:21:29.31 ID:Vwpr/aZb.net

マジキチだった

156 ：デフォルトの名無しさん：2022/09/03(土) 11:53:26.95 ID:MAChL+qh.net

>>150
じゃあCよりRustが遅くなるコードを示せばごめんなさいすんのか？しないだろ？
ここまでの説明でわからないバカがいるはずないからレスバしたいだけだよな？

157 ：デフォルトの名無しさん：2022/09/03(土) 11:55:04.03 ID:OwwDkoRs.net

この話題、ここ数年で最もレベル低いんじゃないか？大丈夫か？

158 ：デフォルトの名無しさん：2022/09/03(土) 12:31:15.03 ID:ytBZTWHu.net

Rustは安心安全でC言語と同等の速度ってことでFAだな

159 ：デフォルトの名無しさん：2022/09/03(土) 12:34:45.63 ID:wLxz63Y2.net

体言止めおじさん

160 ：デフォルトの名無しさん：2022/09/03(土) 12:53:59.17 ID:91ZlUxrs.net

最近のレベル低下には目を見張るものがあるな

161 ：デフォルトの名無しさん：2022/09/03(土) 12:58:26.77 ID:91ZlUxrs.net

>>142
>array[i*2]の例は危険な範囲外アクセスとなるコードだから境界チェックをするRustに軍配が上がるね

array[i*2]の例は危険な範囲外アクセスとなるコードだから境界チェックをしないCに軍配が上がる
が正しい

162 ：デフォルトの名無しさん：[ここ壊れてます] .net

いやはや、時代についていけないCオジが暴れてるようだなw
Cオジもさぁ、自分の世界に引きこもってないでもっと外の世界見ないとねw

163 ：デフォルトの名無しさん：[ここ壊れてます] .net

Cこそ最強！
1個でもCより遅いケースあったらダメね！

164 ：デフォルトの名無しさん：[ここ壊れてます] .net

次世代言語スレなんだから変数の境界越えたアクセスは落とす一択だろ。

もうちょっと別の話したいわ。

165 ：デフォルトの名無しさん：[ここ壊れてます] .net

1個でもCより遅い場合あったら、他にメリットあっても意味ないから！

166 ：デフォルトの名無しさん：[ここ壊れてます] .net

誰も>>91の突っ込み無いんかよ。
Rustが速いのは非常にキツイxor条件を満たす範囲だけで、そこを超えるのはとても面倒。そこを無視して「Rustは安全で高速」とか言うのは詐欺じゃね？

あと、次世代スレなのに何でRustとcだけの比較なんだよ。rangeの最適化なんてイマドキc++ですらやるんじゃないの？

167 ：デフォルトの名無しさん：2022/09/03(土) 14:31:36.61 ID:RWiDbqEQ.net

このスレは何もかもをRustと比較したがる信者とそれに反応してしまうバカに乗っ取られた隔離スレです
次世代言語スレではありません
次世代言語の話がしたいかたはこちらへ↓

次世代言語27 Nim Zig Pony Carbon Gleam
https://mevius.5ch.net/test/read.cgi/tech/1659660050/

168 ：デフォルトの名無しさん：2022/09/03(土) 14:36:16.07 ID:peyYEDe5.net

ていうかこいつほんとにRust使ってプログラミングできるの？って思ったんだけど
あまりにも頭が残念すぎて論理的思考の必要なプログラミングができるとは思えない

169 ：デフォルトの名無しさん：2022/09/03(土) 14:49:28.41 ID:BHvUMyM5.net

>>165
Cで書いた方が良い箇所はCで書けば良いのでは
アプリケーション全体を単一言語で書かなければならない理由もなかろう

170 ：デフォルトの名無しさん：2022/09/03(土) 17:15:49.49 ID:jD7rh1Hd.net

>>167
最終レスが8月18日とか終わってんじゃねえか

171 ：デフォルトの名無しさん：2022/09/03(土) 17:17:49.88 ID:jD7rh1Hd.net

TypeScriptは次世代なのか？
そろそろ枯れてきてるし何ならバニラが復権しかけてんだが

172 ：デフォルトの名無しさん：2022/09/03(土) 17:37:42.10 ID:ytBZTWHu.net

>>169
そんなこと言ったらRsutを使う場面が無くなっちゃうだろ

173 ：デフォルトの名無しさん：2022/09/03(土) 18:07:45.82 ID:k38NcUnV.net

Rustはスライスに対して境界チェックをしないでアクセスする方法もunsafeで用意されている
つまり最適なプログラミング方法はC/C++を絶対に使わずに全てをRustで記述し
「コンパイラによる安全保証で最適化により安全に境界チェックを省略してくれる部分以外」かつ「人間による安全保証で境界チェックを不要としたい部分」のところのみunsafeで人間が安全保証し
その部分以外は全てコンパイラにより自動的にあらゆるメモリ安全保証させるのが最適な方法となる

174 ：デフォルトの名無しさん：2022/09/03(土) 18:32:15.93 ID:5Mn7+zh6.net

>>137
>>109は RustがC言語より圧倒的に遅いコードです

>>166 172
＞Rustが速いのは非常にキツイxor条件を満たす範囲だけ
＞「Rustは安全で高速」とか言うのは詐欺
＞そんなこと言ったらRsutを使う場面が無くなっちゃうだろ

完全同意
Rustの最適化度合いは一貫性がなくて信頼できない
「Rustで高速化」が少しでも視野に入っている人は
Cコードも書いて常にasmとBenchmarkで比較確認するしかない

＞173
109はRust版が10倍くらい遅いんだけどunsafe使ったら早くなるの？

175 ：デフォルトの名無しさん：2022/09/03(土) 18:40:11.28 ID:ytBZTWHu.net

え？↓これってデマなんだよね？

https://qiita.com/shadowTanaka/items/5fb99819629dcaab3e05

176 ：デフォルトの名無しさん：2022/09/03(土) 19:00:48.70 ID:2joIss6C.net

>>174
わざわざ　w = v; 　してそんな無意味なプログラムを書く人いないよ
>>92のような実際に使われているパターンの意味のあるプログラム例が欲しいな

177 ：デフォルトの名無しさん：2022/09/03(土) 19:10:31.55 ID:UqPpASXs.net

>>109
これって偶然とか意図に関係なく引数が手に負えなくなると
Rustが全く最適化をしない、というPOCじゃね?

>>92
はhello worldレベル過ぎて逆に意味なくない?

178 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>174
Cのコードを書く必要はない
Rustには一部エリアのみプログラマーに安全性の保証の義務を負わせるunsafeブロックがありCと同じことができる
ベンチも#[bench]等ですぐ比較できるから速さにシビアな場合は本件に限らずアルゴリズムの差異も含めてコストをかけるだろう
その点はどんな言語でも同じ

179 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>178
＞Cのコードを書く必要はない
＞ベンチも#[bench]等ですぐ比較できる
いやいやCコードなしにhello sliceどうしでいくら比較しても意味ない。>>174は信頼性の話でしょ

180 ：デフォルトの名無しさん：2022/09/03(土) 20:06:47.23 ID:BHvUMyM5.net

>>174
最適化度合いに一貫性のある言語って何？
Cだろうがasm確認しないといけないのは同じだと思うが

181 ：デフォルトの名無しさん：2022/09/03(土) 20:09:49.33 ID:amOq/bcL.net

>>109のコードを見てみたが書き方が酷いな
とりあえずそれと全く同じ関数仕様に合わせるとして
Rustならもっと簡潔にこのように書く

fn max_value_slice_vw(v: &[u32], w: &[u32]) -> u32 {
　std::iter::zip(v, w)
　　.map(|(m, n)| m + n)
　　.max()
　　.unwrap_or_default()
}

C言語バージョンより遥かに分かりやすいし
通常Rustでは返り値をu32でなくOption<u32>とするから最後のunwrap_or_default()も不要となる

これでC言語バージョンと全く同じ結果を得られるし
境界チェックも行われないし
そのC言語バージョンと全く同等のアセンブリコードが生成されることも確認できる
つまり今回の>>109の件もRustとCは同じ速さで動作する

182 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>180
現行C/C++だけがダントツトップレベル
Rustは裏でLLVM使ってるのに何で >>177 で信頼性がないと証明されたんだ...

>>181
あちゃちゃhello sliceと違う書き方をしないといけないなんて、これも無信頼性のPOCだ

183 ：デフォルトの名無しさん：2022/09/03(土) 20:34:30.71 ID:0512mxP9.net

「最適化度合い」ってあれだな
「クイックソートは最悪のケースの計算量が多過ぎる」みたいな
ヒープソート最強伝説に似ている

184 ：デフォルトの名無しさん：2022/09/03(土) 20:45:21.45 ID:GmjcSeRW.net

>>183
ほんとだね。アルゴリズム系は数学的に最悪ケースを予期回避できるのに、Rustの一貫性の無さは最悪
>>181で突然「このように書く」って言われてもPOCの積み増し

185 ：デフォルトの名無しさん：2022/09/03(土) 20:48:32.94 ID:nzn5OhxI.net

>>181
RustはわかりやすくシンプルにプログラミングできてCと同じ速度なのが素晴らしいね

186 ：デフォルトの名無しさん：2022/09/03(土) 20:51:48.37 ID:bnXlFS4K.net

>>185もはや自虐ネタ。嫌味ですか？

187 ：デフォルトの名無しさん：2022/09/03(土) 20:52:15.80 ID:jD7rh1Hd.net

Rustをむやみに褒めてるやつがアホすぎてRustのネガティブキャンペーンにしか見えない件

188 ：デフォルトの名無しさん：2022/09/03(土) 21:07:27.69 ID:ze3FTyL9.net

こういう争いは同じレベルのやつ同士でしか起きない
お互いに相手がアホだと思ってるけど両方同レベルのアホ

189 ：デフォルトの名無しさん：2022/09/03(土) 21:10:15.24 ID:amOq/bcL.net

for文を使わずにメソッドチェーンで書いたことが気に入らないのならば
>>181はfor文を使って以下のように書ける

fn max_value_slice_vw2(v: &[u32], w: &[u32]) -> u32 {
　let mut max = 0;
　for (m, n) in std::iter::zip(v, w) {
　　if max < n + m {
　　　max = n + m;
　　}
　}
　max
}

これもC言語バージョンと同じ動作をし
同等のアセンブリコードが生成されることも確認できる

190 ：デフォルトの名無しさん：2022/09/03(土) 21:13:41.03 ID:sVwwSPBV.net

せめてID変えずにやってくれればいいのにな
何回NGさせるんだか

191 ：デフォルトの名無しさん：2022/09/03(土) 21:15:53.68 ID:jlSkT3Xm.net

>>189
確認乙
POC(>>177,182)積み増し乙

192 ：デフォルトの名無しさん：2022/09/03(土) 21:25:28.83 ID:jfkeSYrB.net

Cだと速いけどRustだと遅くなるケースって存在しないの？
誰かそういう例を作ってほしい
ここまでRustがCと同じ速さで書ける例ばかりだから

193 ：デフォルトの名無しさん：2022/09/03(土) 21:30:23.63 ID:fcrVCCYN.net

本人はバレてないと思ってるらしいw

194 ：デフォルトの名無しさん：2022/09/03(土) 21:34:03.97 ID:hQBDJOi4.net

>>192
はい。Rustは一貫性がない(>>177,>>182)ので個別にCコードと比べて
書き方を変えることにより同程度にもって行ける
ケースが稀にあることが証明されました
多大な努力の結果です。感謝

195 ：デフォルトの名無しさん：2022/09/03(土) 21:55:58.00 ID:wxRR+ldD.net

Rustはfor文自体がイテレータを使うから、
for i in 0..s.len() {
　　println!("{}", s[i]);
}
とインデックスを使う書き方をするのは非常に稀で、
これはインデックスを使わず、
for n in s {
　　println!("{}", n);
}
と書くのがRustでは普通だから、
インデックス議論自体があまり意味のないものに思える。
そしてどちらの書き方をしてもCコードと同速度。

196 ：デフォルトの名無しさん：2022/09/03(土) 22:05:33.75 ID:lGqTIi1A.net

Rustがそんなに速いならなんで競プロはC++一択なの

197 ：デフォルトの名無しさん：2022/09/03(土) 22:19:33.41 ID:V+KjjP+f.net

>>196
それは単なる人口差・マニュアルやサンプル数差
C++に次いで多いのが言語としてはかなり遅いPythonなのを見ても分かる通り

198 ：デフォルトの名無しさん：2022/09/03(土) 22:30:44.07 ID:0512mxP9.net

まあ、型を正確に宣言しても速くならないし遅くなるというのがもし本当なら
バニラJSが復権するのもPythonが支持されるのも当然といえば当然

199 ：デフォルトの名無しさん：2022/09/03(土) 22:31:15.35 ID:pNlcpp9D.net

>>196
解説本がc++が多いからかな

200 ：デフォルトの名無しさん：2022/09/03(土) 22:34:08.49 ID:zAI/jpLH.net

例えば競プロAtCoderでABC182-E問題 i行目j列目のマス(i,j)を扱う問題
提出された各プログラミング言語別の実行時間分布
https://pbs.twimg.com/media/EmYvG8aVkAMdfFG.jpg

201 ：デフォルトの名無しさん：2022/09/03(土) 22:38:11.41 ID:DRQBO0l9.net

Rustはコーディングに時間がかかるから競プロでは使えない。
競プロにC++とPythonは良い選択。

202 ：デフォルトの名無しさん：2022/09/03(土) 22:41:39.07 ID:nzn5OhxI.net

>>200
競プロでもRustが速いね

203 ：デフォルトの名無しさん：2022/09/03(土) 23:18:47.73 ID:mp8eZIVB.net

>>196
そもそもC++もちゃんと書けるとは言えないでしょ
mainとグローバル変数しか使わないし

204 ：デフォルトの名無しさん：2022/09/03(土) 23:28:32.01 ID:DRQBO0l9.net

他言語を貶しても、Rustが使える言語にはならない。

205 ：デフォルトの名無しさん：2022/09/03(土) 23:28:44.38 ID:Ej5h9pmc.net

>>200
Pythonを選んだ時点でPyPy3にしたとしても負け戦が確定かよ
Rustは競プロでも強いのか

206 ：デフォルトの名無しさん：2022/09/03(土) 23:33:58.57 ID:SEYCHGY8.net

>>200 懐かしいなあ
ttps://ビット.ly/3CS8AuV
トップのuzzyさん始めC++勢がじわじわ最適化を進めているのがカッコイイ
ちらほらいるRust勢は一発屋だけでインクリメンタルな最適化が出来ていないね。
Rustは一貫性がない(>>177,>>182)から下手に弄れなかったのかな？

207 ：デフォルトの名無しさん：2022/09/03(土) 23:43:22.86 ID:0512mxP9.net

>>204
その定型文のどこが「使える」と思ったのかがさっぱり分からないよ

208 ：デフォルトの名無しさん：2022/09/03(土) 23:47:27.33 ID:YC+HIv6p.net

>>207 Rustって一発作ったらそれ以上で弄れないって開発現場では使えない言語だね(>>206)

209 ：デフォルトの名無しさん：2022/09/04(日) 00:08:42.58 ID:yt7jdRkq.net

>>206
インクリメンタルに最適化したと本気で思い込んでる？
uzzyの上位4つとも全てソース同じまま変化していない
つまり何度も同じのを提出してトライしただけ

210 ：デフォルトの名無しさん：2022/09/04(日) 00:27:20.06 ID:ULs4IOBU.net

で、その競プロでのc言語での参加率はどれくらい？> cオジ

211 ：デフォルトの名無しさん：2022/09/04(日) 00:31:23.21 ID:ygllKmJ5.net

4回ともC++コード同じだな
ただしその一つ前だけコードが違っていて二次元配列を一次元へと書き換えて改善してる
一方でRustの人は最初から一次元にしてるからその改善が必要なかった
つまり>>208はRustを叩きたいだけの完全に的外れ

212 ：デフォルトの名無しさん：2022/09/04(日) 02:03:59.28 ID:1GJgU4m+.net

たぶん必要なのは
葡萄を食べるべきでない理由ではなく
食べない自由なんだな

213 ：デフォルトの名無しさん：2022/09/04(日) 08:04:17.58 ID:IySRHUNr.net

>>200
プログラミング言語間の速度差が激しくて勝負にならないな
競プロで勝つためにはRustかC++を選ばざるを得ないのか

214 ：デフォルトの名無しさん：2022/09/04(日) 08:07:09.64 ID:gz8Ny9ff.net

>>213
いいや
Pythonは論外だけど他の言語で十分戦える

215 ：デフォルトの名無しさん：2022/09/04(日) 08:19:18.55 ID:ftO7cI3V.net

>>200
Rust最速レベルやん
てかC++の分布笑えるな
ギリ合格からトップクラスまでみっちり

216 ：デフォルトの名無しさん：2022/09/04(日) 10:34:00.57 ID:RQxkFcRF.net

本日のRustあげ会場はこちらですか？

217 ：デフォルトの名無しさん：2022/09/04(日) 11:16:04.09 ID:ubNPliW5.net

貶めれば誹謗中傷かも知れんけど、ほめれば気持ち悪いだけ
こんなの消去法でほめるに決まってんだろ

218 ：デフォルトの名無しさん：2022/09/04(日) 11:23:49.03 ID:YUzYugU5.net

参加者自体はRustも多い。
C++と同じくらい居る。
時間内に提出できる人が少ないだけ。

219 ：デフォルトの名無しさん：[ここ壊れてます] .net

つまりRustは生産性が低いor利用者の能力が低いってこと？

220 ：デフォルトの名無しさん：2022/09/04(日) 11:52:32.99 ID:r6qlMaZb.net

普通にガチ勢は昔からC++を使ってて今さら他の言語にしないというだけだろうな

221 ：デフォルトの名無しさん：2022/09/04(日) 12:28:01.29 ID:1n1CTU4P.net

CオジはCとC++比べてもやっぱCの方が早いからC++はダメとか言うのかな？

222 ：デフォルトの名無しさん：2022/09/04(日) 12:29:11.61 ID:RQxkFcRF.net

ダメな香具師が描いたダメなC++コードは本当に糞
Cのがマシ

223 ：デフォルトの名無しさん：2022/09/04(日) 12:57:20.84 ID:r6qlMaZb.net

>>201
Pythonはよほどうまくチューニングしないとすぐ時間制限越えるんで競プロだと使い物にならないんですわ
>>200のグラフから実行時間でのランキングができそうだけどぶっちゃけ時間内に結果が出れば速かろうが遅かろうが大差無いのでPython以外なら何使ってもいい
言語よりプログラマーの能力が大事だし、それよりむしろ暇の方が大事
とにかく参加し続けてなるべく正解を出してれば上位に行ける

224 ：デフォルトの名無しさん：2022/09/04(日) 13:11:43.10 ID:MfsHP/8v.net

pythonでアルゴリズム性能出ると思ってるのお前だけだよ。。

225 ：デフォルトの名無しさん：2022/09/04(日) 13:31:05.58 ID:r6qlMaZb.net

お前がアルゴリズムという言葉を知らないと言うことがわかった

226 ：デフォルトの名無しさん：2022/09/04(日) 14:04:04.57 ID:ubNPliW5.net

行列の和と積を英単語ではなく記号で書けるだけでC++と互角みたいになったのがPython

argv + 1000000 がnullを返したり計算中に例外を投げる実装が可能なだけでRustと互角になれる

227 ：デフォルトの名無しさん：2022/09/04(日) 14:42:33.66 ID:RQxkFcRF.net

何と戦ってるのか知らんがイミフな基準

228 ：デフォルトの名無しさん：2022/09/04(日) 14:46:33.79 ID:Pinnb9nG.net

>>223
うーん、いろんな言語で競プロやってる青色だからついコメントしたくなってしまう

CPythonは知らんけど、pypyは実行速度速いからマラソンでもなければ困ることないよ
再帰がしんどいと言われる問題も、コドフォではよく使われてるbootstrapデコレータを使えば簡単に解決する
Rustはusizeの扱いのために余分なコードが必要になることが多かったし、クロージャ使おうとすると引数の型とかめんどいしで、最近は専らPythonを使ってる
Pythonはクロージャを短めに書けることも競プロ的には気が楽だな

229 ：デフォルトの名無しさん：2022/09/04(日) 15:31:08.56 ID:YUzYugU5.net

Rustは競プロに向いて居ないからな。
避けるのが賢明。

230 ：デフォルトの名無しさん：2022/09/04(日) 15:33:36.35 ID:+XXjYupQ.net

複オジと
複オジにマジレスしちゃう人と
その両方を焚き付けて喜んでる人の三人でお送りしています

231 ：デフォルトの名無しさん：2022/09/04(日) 16:44:07.43 ID:nQgfFYZJ.net

Cが普通はintインデクスなのになんで、配列というかスライスをusizeにしたか何回も疑問に上がるよね....
まあインデックスループじゃなく、イテレート操作するからとか、std::ops::Index<T>でusizeだからとか
色々な回答があるけど、どうにもスッキリしない
usize以外の型（より小さい型やsigned)を使えるようにすることは将来ありうるかという開発者への質問も
ライブラリの互換性上ではすぐに実現できないみたいだし、ま、使う人の利便性・プログラマーへの負担軽減を
優先的に考えて作られた言語じゃないからだけど、let mutと書いてる時点でそうだが、せめてこれだけでも
1キーワードに出来なかったんだろうかな
それとCだとint a = 0, b = 1, c = 2;と宣言できるけど、let (mut a, mut b, mut c) = (0, 1, 2);
文末セミコロンで複数行に分けても、理解しやすいという話はどこに行った？使いやすさを求めては
イケないんだろうけど、どうもね....

232 ：デフォルトの名無しさん：2022/09/04(日) 16:46:11.53 ID:/0DHyjSi.net

ミュータブルを極力使うなということだろ

233 ：デフォルトの名無しさん：2022/09/04(日) 17:40:27.34 ID:YUzYugU5.net

韓国で最も愛される言語と銘打てば流行るのでは？

234 ：デフォルトの名無しさん：2022/09/04(日) 17:47:06.26 ID:rbLH55CO.net

>>231
わざと面倒臭くさせてることに意味がある
その辺りの思想は今までの言語とは違うかもしれん

235 ：デフォルトの名無しさん：2022/09/04(日) 17:48:26.12 ID:qbvnu5SJ.net

>>231
＞Cが普通はintインデクスなのに
そんなルール無いよね？
仕事で他社さん作ライブラリがuint使ってたことある。

236 ：デフォルトの名無しさん：2022/09/04(日) 18:06:41.17 ID:mP7WKJy6.net

普通にprintln!使うと遅いんだけど教プロ上位なんだな

237 ：デフォルトの名無しさん：2022/09/04(日) 18:17:28.78 ID:6TwASNhD.net

競プロではRustは間違いなく最速レベルだし、proconioみたいなマクロを使えば入出力もめちゃくちゃ扱いやすい
でもまあそれ以外のとこでかなり慣れがいる

238 ：デフォルトの名無しさん：2022/09/04(日) 18:21:48.03 ID:oPTKOfK9.net

安心安全最速、Rust最高じゃん

239 ：デフォルトの名無しさん：2022/09/04(日) 19:10:58.79 ID:brj4MXrP.net

>>231
インデックスやその長さはusize型で絶対に正しい
まずインデックスは負の数になってはいけないからunsigned型
サイズとしてはポインタなどと同じそのCPUで使われるサイズでなければならないからusizeとなる
そして実際のほとんどの様々なプログラミングにおいてインデックスはusize型で上手く動く

ところが例外が二つある
例外の一つは自分たちで決められない外部指定APIなど規定においてインデックスや長さがusize型でない場合でas usizeにより解決

例外のもう一つは一部の数値アルゴリズムでプログラミングする上で一時的もしくは最初あるいは終端で負の数になると便利なことがある
もちろんその一時的な負の数である時ははインデックスとして使われないようにプログラマーの責任でプログラミングしてインデックスとして使う時はas usize

240 ：デフォルトの名無しさん：2022/09/04(日) 19:29:23.15 ID:OkswyjL5.net

浮動小数点数から符号無し整数へキャストする命令なくね？
最近の処理系は直接キャスト出来るようなったん？

241 ：デフォルトの名無しさん：2022/09/04(日) 19:44:58.67 ID:brj4MXrP.net

>>231
その3-tupleはデータ型の一つでもありまとめて変数に格納できるし関数の引数や戻り値に3-tupleは使える
let foo = (1, 2, 3);

letはパターンマッチ文なので分解にも使う
let (a, mut b, c) = foo;
b += 100;
println!("{a} {b} {c}')
ここでbしかmutableを必要としていないのだから個別mut指定が自然
どの言語でも同様だがmutableをできる限り少なくするのがプログラミングのコツ

242 ：デフォルトの名無しさん：2022/09/04(日) 20:00:50.97 ID:wyRxABNd.net

>>231
Cも配列のインデックス関連は(s)size_tが基本では
strlenやmemcpyの引数や返値はsize_tだし
単にintから暗黙的にキャストできるというだけで

暗黙の数値キャストがないのは確かにめんどくさい

asでのキャストはリリースビルドだと範囲外の値になったときにエラーにならないし、
絶対成功するキャストと失敗する可能性のあるキャストが見た目からぱっと区別がつかないのもよろしくない
かといってn.try_into().unwrap()を書くのもだるい

せめてn.into()で済ませたいが16bitアーキもサポート対象だからusizeに From<u32> が実装されていない

ターゲットを32bit以上のアーキテクチャに限定するした場合はinto()使えるようにするとか、もう少し楽にできないだろうか

243 ：デフォルトの名無しさん：2022/09/04(日) 22:29:03.84 ID:rWQ8XHaT.net

>>242
Rustは基本としては正しい一貫した方針をとっていて
型変換が必ず成功するものはinto()つまりfrom()が定義されていて
型変換が成功しない可能性のあるものはtry_into()つまりtry_from()が定義されている
したがって基本的にはどちらかを用いればよい
新たな型に対しても同じ方針で実装していくしライブラリもそうなっている
usizeについても同様だが16bit環境もあるためbool, u8, u16からのみinto()となり一貫している
唯一の例外は浮動小数点で成功が定義されないためにinto()もtry_into()もない

上述のコンパイラが型変換を常に保証する方式に対して
プログラマーが型変換を保証する方式に利便性を兼ね備えたのがasによるキャスト
これは例えばu32を自動的に上位を切り捨ててu8に入れるといったことも含めた広義の型変換も含まれる
いずれのケースもキャストはプログラマーの責任で行なうという一貫した方針がある
わざわざ『as xxx』と記述させるのはそのためで意図的に目立つようにしている
プログラムをチェック、デバッグ、メンテする時にunsafeに準じてas xxxは注視すべきポイントとなる

244 ：デフォルトの名無しさん：2022/09/04(日) 23:03:51.17 ID:rWQ8XHaT.net

>>243の基本を踏まえた上で
例えば16bit環境でなければu32からusizeへのtry_into()は常に成功し安全にunwrap()できる
生成コードも以下のようにコストゼロ
https://godbolt.org/z/cEc5fKGjh

キャストasと同様にunwrapも注視ポイントとなるため
利便性も含めてinlineのto_usize()を用意してしまうのがよいかもしれない
bit環境依存性はそのメソッドに押し込めることで注視ポイントが散らばるのを防げる

245 ：デフォルトの名無しさん：2022/09/04(日) 23:05:01.26 ID:ULs4IOBU.net

危険のある操作は面倒にするべきなんだよ。

246 ：デフォルトの名無しさん：2022/09/04(日) 23:23:22.66 ID:nQgfFYZJ.net

>>239
それ絶対に正しいとは言えてないよね
下のほうに書いてるんだろうけど、よくある別の言語仕様だと、a[-1]が末尾を表したりできるし、数多くの言語でインデックスループだと
これもよくある相対位置やインデックス演算でa[i-1]とか書くけど、usizeをキャストしてi32にしてもう一度、スライスにアクセスするために
as usizeとか2回キャストを行う。これがどれほど醜くなるし、めんどくさくて労力を要するか
当然、メモリアドレッシングが0x00〜上に伸びていくことなんて言わなくてもわかるが、それが合理的であり、かつスライスがusizeで
支持できる理由かといえばどうだろう？少なくとも私はメンドクサイ
またもちろん、(a, b) = t がタプルのアンパッキングなどに使えるのも知ってるけど、それとまとめて変数の宣言と初期化を少ないタイプ量で
出来る話とは別だろう、上からアドバイス頂いてるようでケチをつけて申し訳ないけど、もちろん不変性はマルチスレッドでも有利だしコードの
リファクタリングなどもし易い、ファンクションの変更が良くわかる（そのくせ同じ変数名で別型再定義できたり）とか色々利点があるのは
当然分かってるけど、これもまたmutを多数宣言しなきゃならない時とは全く別の話だよ

247 ：デフォルトの名無しさん：2022/09/04(日) 23:56:45.66 ID:C1tkKKn6.net

>>246
Rustならばusize型そのままa[i-1]と書くことが出来ますが
2回キャスト面倒とは別の言語の話ですか？

例えば前の要素との差が指定のものを見つけてインデックスを返すRustコード例
fn find_diff(a: &[i32], diff: i32) -> Option<usize> {
　for i in 1..a.len() {
　　if a[i] - a[i-1] == diff {
　　　return Some(i);
　　}
　}
　None
}
もちろん最適化によりアクセス時のインデックス境界チェックは無くなります

248 ：デフォルトの名無しさん：2022/09/05(月) 00:30:20.92 ID:+iXq2ECO.net

まともにプログラム書いたことなさそうだね

249 ：デフォルトの名無しさん：2022/09/05(月) 00:34:33.72 ID:BTzrk4g4.net

>>241
Rustはletとmut指定を分離することでそのようにできるから大成功だな
mut指定が分離していない言語ではそのようにすることができずいつも困っている
方法がないからimmutableで十分な変数も含めてまとめてmutableな変数宣言にせざるをえない
初めて知ったときRustはよく考えられているなあと感動した

250 ：デフォルトの名無しさん：2022/09/05(月) 00:43:43.47 ID:+21R+/VD.net

>>246
・Rustは、数値リテラルに多くの言語ある固定の型がなく、文脈によりu32とかi32とか変わる（型推測）
・下のほうで境界チェックがないのも1..a.len()としているから
当然ながら、これは胸を張って一貫性があるとは言えないがa[-1]は言語仕様ではコンパイルエラーになるが
for i in 0..a.len()とすれば境界チェックが入り実行時にpanicする
君が勘違いしてるのはa[i+b]とかはbを宣言した場合、as castが必要で、色々ごっちゃになってるYO

アンダースタンド？ｗ

251 ：デフォルトの名無しさん：2022/09/05(月) 00:44:27.92 ID:ARttffD1.net

C++は型の特性を調べて、ユーザーがconst性を利用したバージョンの実装を生み出すことができる。
しかも利用時には、型の特性によってコンパイラにどのバージョンを使うか選択させる事が出来る。

252 ：デフォルトの名無しさん：2022/09/05(月) 00:48:14.12 ID:g3RfqaIY.net

RustもIndex<u32>とか実装はできるよ
標準のsliceに実装されてないというだけで

253 ：デフォルトの名無しさん：2022/09/05(月) 00:55:53.18 ID:ARttffD1.net

C++は、型の計算ができるんですよ。

254 ：デフォルトの名無しさん：2022/09/05(月) 01:07:57.19 ID:9iTWKe04.net

すまん、誰が聖闘士星矢で例えてくれないか？

255 ：デフォルトの名無しさん：2022/09/05(月) 01:12:56.84 ID:ARttffD1.net

>>254
くちから　たれている　みつは　２きろ　はなれていても　はなが　まがるほど　もうれつに　くさい。

256 ：デフォルトの名無しさん：2022/09/05(月) 01:19:02.56 ID:JbiV7xYP.net

>>211
一昨日は言葉が過ぎました。開発現場、携わっている人には心無い発言でした。反省してます。
強調したかったのは、最適化って難しいよ、速そうな言語を選んでコンパイラにお任せって言う易しい世界じゃないよ、という事です。

むしろ叩きたいのは、定期的に現れる無意味なRust上げ
スレッドの流れをフォローしている人間にはネガティブキャンペーンと受け取られているコメントです。
うすうす気づいているとは思いますが、これSEO対策なんですよ。
Rustをほとんど知らない人が検索をした時に、
チラッとその一部だけを見せてエコーチェンバーにはめ込むと言う仕掛けです
同様に時々現れる、会話の流れを修正したい時に持ち出す極論、逆説的にRustを卑下する冗談
これはわざとRsutとタイポしてチラ見に現れないようにしている。
複製おじとは別人だと思うのですがどんなんですかね。皆さんの意見を訊きたいな

257 ：デフォルトの名無しさん：2022/09/05(月) 01:22:23.34 ID:RaegMrzk.net

>>246はまともにプログラミングしたことないとまでは言えないが多くの勘違いをしてるのは確かだな
usizeを上に伸びていくと書いてあるから引き算出来ないとでも勝手に思い込んでa[i-1]ができないと勘違いしたのかもしれない
もう一件

＞ よくある別の言語仕様だと、a[-1]が末尾を表したりできるし

その件はa[-1]やマイナスのインデックスに意味を持たせたプログラミング言語の仕様ミス
もしくはお子様向け言語であるとの結論が大昔に出ている
プログラミングのミスでマイナスのインデックスとなり本来はエラーでミス発覚となるべきところか不可能となった
つまり言語仕様ミスなのかそんなこと気にしないお子様向け言語なのかどちらかということになる
ほとんどの言語はまともなのでa[-i]はエラーとなり正しくa[len-i]と書く

258 ：デフォルトの名無しさん：2022/09/05(月) 01:34:56.96 ID:9oDekVHu.net

>>257
複製おじ？usizeの議論は微笑ましいですね。盲目的ですが熱意にあふれてます。
速度、最適化に関する盲目的思い込みがなければ無害ですな
SEO対策(>>256)に加担していなければの話ですが

259 ：デフォルトの名無しさん：2022/09/05(月) 01:45:29.53 ID:ARttffD1.net

実力のある者はC++を利用するべきでは？

260 ：デフォルトの名無しさん：2022/09/05(月) 01:57:02.85 ID:b0NkdPU/.net

>>259
同意ですな
一方で熱意にあふれ盲目的で従順に車輪の開発をしてくれるプログラマが
無料で使えるのであれば使わない手は無いとLinus辺りは策略してそう
SEO対策(>>256)もあながち...？

261 ：デフォルトの名無しさん：2022/09/05(月) 02:02:44.86 ID:7mfke0+F.net

欠陥言語C++を使うメリットは何？
今はこれだけ多数の安全な言語があって色々選べるのに

262 ：デフォルトの名無しさん：2022/09/05(月) 02:05:41.16 ID:ARttffD1.net

アセンブラを使う理由はレジスタにアクセスできるから。
これはとても危険。
C/C++を使う理由はメモリーにアクセスできるから。
これはとても危険。

263 ：デフォルトの名無しさん：2022/09/05(月) 02:07:30.95 ID:ARttffD1.net

大いなる力には責任が伴う。
　　2019 - アフレシアさん

264 ：デフォルトの名無しさん：2022/09/05(月) 02:14:43.00 ID:ARttffD1.net

早くコンセプトが使いたいわー。

265 ：デフォルトの名無しさん：2022/09/05(月) 02:16:22.39 ID:E82kQidM.net

>>261 もしこの二日間程度のスレッドの流れをフォローしてもなお一つのメリットも見えないのであれば
あなたの長所は熱意だけです。周りを頼って上手に立ち振る舞ってください。

>>260 有料案件で活躍されているプログラマーを見下すものではありません

>>263 同意 正に実力の世界。去れよ無責任Kids

266 ：デフォルトの名無しさん：2022/09/05(月) 02:33:35.68 ID:sgxkT6js.net

C++にもメリットはありゼロじゃない
ただし世界的には>>154の結論が出ている
そして今回もC++で書かれたChromiumの穴のせいで、それを使うElectronを始め多數に影響が出て、それを使うVScodeにもセキュリティ脆弱性と連鎖
C++を使い続ける限りセキュリティの穴が量産されてしまう

267 ：デフォルトの名無しさん：2022/09/05(月) 02:57:07.57 ID:5U2utJMj.net

>>266
あなたの結論素晴らしいですね。
どうぞLinusあるいはMozillaの元へ
SEO対策(>>256)の一環ですか？

＞C++を使い続ける限りセキュリティの穴が量産されてしまう
ほんと怖いです。一刻も早くRustに書き換えて欲しいですね。もう10年経ったっけ？

ところでFirefoxのthird_party directoryを除いたsource repoでのRustの使用割合ってご存知？宿題ですよ

268 ：デフォルトの名無しさん：2022/09/05(月) 03:10:33.61 ID:9iTWKe04.net

何でもrustでやらんで、安全性第一のとことか機能が優れてるとこ(非同期やジェネリクス、健全なマクロ、パターンマッチ等)とかからでもrustを便利に使ってったらええ。
今のrustは少しずつ実用面で採用を広げて行ってる段階だろ。Linuxでの採用とかさ。
既存のcでやってることをイキなり全部rustで置き換えようとしてる人なんて居ない。
rustにその潜在能力があったもしてもマンパワーが足りない。だから大手は少しずつ小さな分野で使いだしてる、複数の大手でね。
ただrustはもっとc言語との連携が簡単だったらと思う。

269 ：デフォルトの名無しさん：2022/09/05(月) 03:31:45.52 ID:hQwE/dE/.net

>>268
＞何でもrustでやらんで、安全性第一のとこ
完全同意 話が合いそう
安全性アピールがマーケティング上有利な暗号通貨系の動きが早かったです

＞Linuxでの採用とかさ。
早いとこ第一歩を踏み出して欲しいです。偉大な一歩となることでしょう。

＞既存のc...イキなり全部rust...
10年なんてあっという間ですね

＞複数の大手でね。
大手って何やっても凄いです
ScalaでのNetflix分岐点 未満/以上の話を思い出した

＞ただrustはもっとc言語との連携が簡単だったらと思う。
完全同意 話が合いそう

>>266 が宿題(>>267)をサボったら手伝ってあげてください

270 ：デフォルトの名無しさん：2022/09/05(月) 03:36:29.05 ID:pmwagyd7.net

>>268
どの言語からどの言語の場合でも既存システムをそのまま言語置き換えはコストだけかかり効率がよろしくない
そのためシステム改修や新規システムを中心にRust採用となっているようだ
現在ある選択肢では人間が引き起こしうるミスをコンパイラに防止させてセキュリティ含む穴を無くしていく言語候補がRustの他にない

271 ：デフォルトの名無しさん：2022/09/05(月) 06:42:39.68 ID:ARttffD1.net

簡単に言えば、Pythonの代わりにRustを使うことはあっても、C/C++の代わりになることはない。
レジスタやメモリーを扱うのは大変危険だから。

272 ：デフォルトの名無しさん：2022/09/05(月) 07:16:47.41 ID:yWe543y4.net

>>271
Rustはinlineアセンブラ記述をサポートしていてレジスタ操作もできることを知らないのかね
Rust叩きの人はなぜ学習せずに無知なままなのだろうか

273 ：デフォルトの名無しさん：2022/09/05(月) 07:22:08.46 ID:ARttffD1.net

>>272
じゃあ安全じゃないじゃん。

274 ：デフォルトの名無しさん：2022/09/05(月) 07:51:21.51 ID:928S9Xdp.net

以前の言語
　・プログラムのメモリ安全性、null安全性、データ競合安全性をプログラマーの責任で保証する

Rust
　・それらの安全性を全てコンパイラが保証
　・プログラマーの責任でCと同じメモリ操作やインラインasmなどを記述できるunsafeブロックもサポート

Swift, Kotlinなど
　・null安全性をコンパイラが保証

275 ：デフォルトの名無しさん：2022/09/05(月) 08:33:46.56 ID:HWNfM8e/.net

>>268
Rustを使うにはガッツリ勉強しないと無理だから……THE BOOK一通り勉強しないと無理だから……

276 ：デフォルトの名無しさん：2022/09/05(月) 09:45:50.25 ID:KpRHtzI/.net

>>92
上に書いたように、当然gccでやったら同じコンパイル結果にならず全く違いますね？これを同じとは言えません
rustcの結果(-C opt-level=2)が138行あるが、x86-64 gcc 12.2(-O2)は16行です。
https://godbolt.org/z/v6TxTGGbT
max_value:
test rdi, rdi
je .L4
lea rcx, [rsi+rdi*4]
xor eax, eax
.L3:
mov edx, DWORD PTR [rsi]
cmp eax, edx
cmovb eax, edx
add rsi, 4
cmp rsi, rcx
jne .L3
ret
.L4:
xor eax, eax
ret

速度の比較はやはりrust（というかllvm)のほうが、ほんのちょっぴりから2倍以内ほど遅い結果になると思います。
今はC言語といえばclangなのかもしれませんが作られているソフトウェアはまだgccのほうが圧倒的に多いです。
gccを-O3にするとrustcと同じくSIMD拡張命令が使われますが、それでも84行と138行なので違います
それほど真剣に見ていませんが、C側はlenが引数として取るのに対して、もう一方はlen()を呼び出していますが
c/clangでほぼ同じになるのはなんでなんでしょうか？

277 ：デフォルトの名無しさん：2022/09/05(月) 09:57:13.85 ID:DUaqFrRV.net

>>276
やっぱりおまえアホだな
16行だから速いと思っている？？
行数で速さは決まらないが
その例なら16行のコードが無展開で一番遅くなる

278 ：デフォルトの名無しさん：2022/09/05(月) 10:24:45.85 ID:vkD3rEEb.net

>>276
Cでは引数にlenを取り、Rustではlen()を使っていて、両者は全く異なるのに、なぜ、ほぼ同じ生成コードになるのかが分からないって！？
もう少しRustを勉強してからアンチ活動しましょ

Cは先頭ポインタと長さの二つの引数を別々に渡しているのに対して、
Rustはスライス1つのみ引数を渡しているけど、「スライス＝ポインタと長さのセット」だから同じ情報を渡しています
そしてlen()はその長さ部分を示すだけだからCコード側のlenと同じ

そしてスライスとしてセットとなっているlen()だからこそデタラメな不正な値が来ることはなく、
コンパイラの管轄下で信頼できる正しい長さ数値情報として扱うことができて、
その長さ未満となるループ内でインデックス境界チェックも安全に省略できるのよ
そのためLLVMによりCのプログラムと同等の生成コードが出来上がります

279 ：デフォルトの名無しさん：2022/09/05(月) 12:00:09.73 ID:g3RfqaIY.net

>>276
rustにもgccバックエンドあるからそれで試してみてくれ

280 ：デフォルトの名無しさん：2022/09/05(月) 13:38:45.87 ID:hgtSwHCO.net

>>276
素晴らしいです。ブラウザで見るに留まらず実際に動かしたのですね。277 278は気にする必要なし

gccの中の人も訪れる場でおこがましいですが解説してみます
gccとclang/LLVMで同じ最適化オプションO2同士でも適用されるテクニックが異なるのです。
手っ取り早く最上級で比べる場合は gcc -O4 vs clang -O3 で比べたりします。
>>73の人も書いてますがclangはgccに比べてやたらとunrollしたがります。
clangが出始めの頃に持ち上げられた事がありましたが、新入りは背伸びをしたがるものです
大きなデータセットで見栄えのする、gccに引けを取らないベンチマーク結果が欲しかったのか
そういう状況にフォーカスした味付けがしてあったのかなと邪推したくなります

今回のケースで言うと
277 278はasmを表面的に見ただけの人で
データセットサイズに寄りけりだという常識(最速を目指すものには)がすっぽり抜けてます

gcc -O2 vs gcc -O3 vs clang -O2 (vs Rust)
ttps://godbolt.org/z/6E4Ksx34Y

gcc -O2 unroll なし blanchless move(cmovb)だけ
gcc -O3 unroll x 4 ( 4 byte/roll * 4roll/loop = 16 byte/loop = 128bit SSE LOAD x 1 / loop)
clang -O2 unroll x16 ( 4 byte/roll *16roll/loop = 64 byte/loop = 128bit SSE LOAD x 4 / loop)

lenが小さい時はせっかく用意したunroll loopに入れられず
unroll x 4 --> len <= 3 else の振り分け1回
unroll x 16 --> len <= 15 else len <= 7 else len <= 3 かどうかの振り分け3回
とunrollが大きいほど手間がかかり、CPUの分岐予測と投機実行の性能に寄りけりですが、
Benchmarkで数を回せば観測される確かな差が生まれます。

281 ：デフォルトの名無しさん：2022/09/05(月) 13:42:00.23 ID:KOsqPsuw.net

len>=16の場合はどうか

L1/L2/L3に収まっているかどうか
それぞれのcache階層間のデータ転送granularity
Hardware prefetchの効き具合 on the fly loadの上限数
surrounding code間とのcache pollution

いろんな要因がありすぎて 結局やって比べるのが手っ取り早いです
gccはcache pollutionへの対策かどうか確認したことはありませんが
unrollは控えめな印象は確かです(オプションで調整できます)

この辺のトレードオフを評価するコストモデルはCPU vendorがPRを出したりしますが
タイムリーかどうかはその時々です
個人的な印象ですが-march=znver2と-march=znver3が長いこと同一だった気がしてます...

お使いのCPU次第ですが AVX(128bit -mavx) AVX2(256bit -mavx2)で試したら
更なる発見があると思います
compiler exploreで -mavx2のasmを見てみるだけでも面白いですよ

Apple Siliconの方は判りません。どなたか解説お願いします

282 ：デフォルトの名無しさん：2022/09/05(月) 14:12:00.36 ID:++1d7Ak5.net

Java C#などのJIT勢は決まってピーク性能(大きなデータセット,warmup付きのbenchmark)を
アピールしますがピーク性能だけを見ていて十分かどうかは別途判断が必要です。

競プロ目標であれば
>>228の様にいろんな楽しみ方がありますよ
>>226で懐かしいと言ったのは途中で行列の転置をかますことで
劇的に速くなった記憶があるからです。O(数式)ビッグオー レベルで
まだsubmit出来るようなのでお試しください

283 ：デフォルトの名無しさん：[ここ壊れてます] .net

連投するのに何でいちいちID変えてるの？

284 ：デフォルトの名無しさん：2022/09/05(月) 15:42:20.01 ID:ORvHoQkv.net

気軽にNGされると困る

285 ：デフォルトの名無しさん：2022/09/05(月) 15:43:39.27 ID:4jBB7bRF.net

まるでRustがキチガイ用言語に見えてきた

286 ：デフォルトの名無しさん：2022/09/05(月) 16:07:08.66 ID:ZY4XQhp4.net

ヒント：複オジはワッチョイスレに一回も来たことがない

287 ：デフォルトの名無しさん：2022/09/05(月) 16:32:50.42 ID:NIbO6JQn.net

複オジも昔はコテハン使ってイキってたんだが
恥ずかしいレスを叩かれて匿名複オジに
今でもそのコテハンで書き込んだりもしてる

迷惑だよな

288 ：デフォルトの名無しさん：2022/09/05(月) 18:31:27.51 ID:i8gFMMFV.net

やっぱりワッチョイにしようぜ。

289 ：デフォルトの名無しさん：2022/09/05(月) 19:04:14.83 ID:iWQD5HeB.net

Haskellの時もそうだったけど、世界でアカン空気が流れ始めると、日本で流行らせようと宣伝し始めるのは何でだろな？

290 ：デフォルトの名無しさん：2022/09/05(月) 19:05:51.22 ID:JwYYQerB.net

日本のIT技術を遅らせたい勢力が存在するのかも

291 ：デフォルトの名無しさん：2022/09/05(月) 19:06:21.16 ID:iWQD5HeB.net

RoRの時みたいに、世界で流行るときは、日本ではアカン言うてアンチが増えるんだよね。

292 ：デフォルトの名無しさん：2022/09/05(月) 19:08:02.01 ID:XsUbtHe1.net

>>290
この件と関係あるかは知らんけどその勢力がいることだけは確か

293 ：デフォルトの名無しさん：2022/09/05(月) 19:11:19.28 ID:iWQD5HeB.net

このスレで紹介されるRustの良いところって、「定数の索引で配列アクセスする場合は、最適化されて境界チェックが消える、安心安全」だけでしょ？
定数の索引で配列アクセスなんて、一生に一度書くか書かないかくらいなんだから、そんな機能在っても嬉しくないわ。

294 ：デフォルトの名無しさん：2022/09/05(月) 19:12:38.64 ID:iWQD5HeB.net

その点Javaは、実行時最適化でRustの5倍速い。
知らんけど。

295 ：デフォルトの名無しさん：2022/09/05(月) 19:23:11.04 ID:g3RfqaIY.net

>>289
Rustだめな理由知りたいからあかんとされてるブログ記事なりニュースなりフォーラムなり教えて

296 ：デフォルトの名無しさん：2022/09/05(月) 19:28:42.10 ID:iWQD5HeB.net

https://chrisdone.com/posts/rust/
こんなのはどう？

TwitterやRedditは辛辣な意見が多いよね。
クリップしてないけど。

297 ：デフォルトの名無しさん：2022/09/05(月) 19:51:44.37 ID:wWfHpXgm.net

>>296
他にこういうのもあるの？
見てみたい

298 ：デフォルトの名無しさん：2022/09/05(月) 19:55:18.42 ID:x/Xug50w.net

非同期関連がごちゃごちゃしてて面倒くさいってのはあるよな
ゼロランタイムコストが売りだから仕方がないんだろうが

その点Goはランタイムに強力な並行並列処理が組み込まれてるから、基本的な文法から標準ライブラリ、サードパーティライブラリで全て共通のgoroutine、channel、selectを使えて非常に扱いやすい
DockerやKubernetesとかクラウド関連で流行ってるのはこの並行並列処理が言語、ランタイムレベルでサポートされてるのが最大の要因だな
Nodeも非同期処理を言語レベルでサポートしてるからこれだけWeb系で流行ってる
その点Rustは弱い

ライブラリによってAはサポートしてるけどBはしてないとかあって色々面倒くさい

299 ：デフォルトの名無しさん：2022/09/05(月) 20:01:50.03 ID:iWQD5HeB.net

基本的にRustは知られていないんだよね。
日本以外では。
とっくにオワコンだから。

300 ：デフォルトの名無しさん：2022/09/05(月) 20:04:19.99 ID:g3RfqaIY.net

>>296
割とソフトな意見でオワコンとまでは言ってないような
そもそも言語におけるオワコンって何？

301 ：デフォルトの名無しさん：2022/09/05(月) 20:10:04.95 ID:iWQD5HeB.net

Rustなんか構ってる暇あったら、PHPやれよって話。

302 ：デフォルトの名無しさん：2022/09/05(月) 20:13:42.10 ID:9iTWKe04.net

>>301
他部署の人たちのPHPのバージョンアップ追従に毎回ドタバタしてるの見ると関わりたくないなぁと思う。
もちろんそれだけのお金と時間くれたらいいけど、PHPの単価ってそれほどでも無いよね？

303 ：デフォルトの名無しさん：2022/09/05(月) 20:20:47.93 ID:kVCZ1c6R.net

>>293
君は相変わらずデタラメばかり言ってるなあ
定数の索引で配列アクセスしているコードは出てきていない
その件で出ているRustの関数の引数は全てスライスであり配列ではない
つまり始点ポインタも長さも未知のものが引数としてやってくる
さらに定数の索引とはa[5]などの例を指しそんな例も出ていない

正しくは
未知の始点ポインタと未知の長さが引数として与えられてその中を変数の索引が動くコード例であり
RustとCは同等の生成コードとなることが確認された

>>294
Cと同等の速さのRustより何倍も速いプログラミング言語は存在しない

304 ：デフォルトの名無しさん：2022/09/05(月) 20:25:02.75 ID:5VtMLQd9.net

>>300
最後まで読むと結局仕事では使ってるみたいだし
どちらかというと不満がある人でも使うくらいには広まってきている、というべきな気はする
オワコンっていうには他言語に移行したみたいな事例が必要なのでは

305 ：デフォルトの名無しさん：2022/09/05(月) 20:36:11.44 ID:e+uJj/tK.net

>>289
そもそもHaskellとRustに何の関係があると思った？
異なる言語って普通ならどうしようもなく分断されていて全く無関係な筈じゃないのかね

分断を回避する秘訣でもあるのか

306 ：デフォルトの名無しさん：2022/09/05(月) 20:50:10.83 ID:Xf3ARiO4.net

>>296
読んだけど少し偏った思想の人なだけだった
「いずれRustでガベージコレクターが人気になると予想する」とか今後も極一部の用途以外では使われないだろう
「XXXをRustで書き換えたら速くなったというのはRustのせいじゃない」は安全かつ速くなった利点を理解していない
「良いメンテされたコードを書いてるメンテナーは非同期を採用することに抵抗がある」は用途に応じて使い分ける人が正常なので抵抗なんてない
Rustを批判する人はちょっとおかしな人が多いと感じる

307 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>293
さすがにそのツッコミはRustゴリ押しの自作自演級に低レベルだぞ

308 ：デフォルトの名無しさん：[ここ壊れてます] .net

Haskellてあかんやつだったの？

309 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>305
Haskellはガベージを撒き散らしながら計算を進めるからRustとはその点で真逆な存在かな
強いて言えばHaskellの型クラスとRustのtraitが基本思想の一部で似てる程度
そのRustとHaskellを叩いてる人はどうせ何も理解していないでしょう

310 ：デフォルトの名無しさん：2022/09/05(月) 21:58:07.88 ID:59/nx/yB.net

例えばRustでhttpクライアント使いたかったからhyperやらreqwestやらsurfやらサードパーティのライブラリを使うことになると思う
別にこれでもいいが他人のコードを読む上で共通のコードが出てくるってのはかなりアドバンテージがある

それに対してGoが標準ライブラリで用意されてるから通常サードパーティのライブラリは使わない
コネクションプーリングも勝手にやってくれる上にhttp2対応も完璧
テストもhttptestパッケージで簡単に作れる
サーバー作る時も標準ライブラリを学んでおけばサードパーティライブラリの習得は容易

RDB扱う時もGoは標準ライブラリレベルでインターフェースを共通化したりコネクションプーリングをサポートしてる

ということで標準ライブラリが強力ってのは実用的なソフトを複数人で作っていく上で非常に重要

311 ：デフォルトの名無しさん：2022/09/05(月) 22:16:25.49 ID:LJb2ynoL.net

>>310
hyperとreqwest/surfはレイヤーが異なり比較する対象でないからそこで例として持ち出すのは適切ではないね
あと標準ライブラリの範囲や意味するところは言語によって異なるのだからあまり意味のない議論だと思う
その思想だとあらゆるものが標準ライブラリにあり他のライブラリを一切使わない言語が最上となってしまう
それぞれにメリットとデメリットがあります

312 ：デフォルトの名無しさん：2022/09/05(月) 22:16:42.44 ID:e+uJj/tK.net

実用品かどうかの定義が難しいけど
ほぼ原価で買える物は実用品と認定されやすい
原価より高い物は実用的ではない無駄な要素が入っている疑惑や誤解を招きやすい

313 ：デフォルトの名無しさん：2022/09/05(月) 22:20:06.23 ID:5dvrlWbj.net

しかしRustへの注目度たかいなｗ
もう実質 Rust vs その他次世代言語って感じｗ

314 ：デフォルトの名無しさん：2022/09/05(月) 22:33:58.90 ID:g3RfqaIY.net

Rustがオワコン言うからGitHubのPullReqに占める言語毎の割合のデータ見てみたけどTypeScriptとGoが圧倒的ということが分かった
Nimは残念ながらランク外、他はだいたい横ばいみたい

https://madnight.github.io/githut/#/pull_requests/2022/1/TypeScript,Swift,Go,Kotlin,Rust,Nim

GitHub全体のPullReq数も増加していると思われるので、個々の言語の利用者の増減を見るには不向きなデータかも
割合じゃなくて言語毎のPullReq数が分かるサイトがあったら教えて欲しい

315 ：デフォルトの名無しさん：2022/09/05(月) 22:39:25.77 ID:LWnBOcCn.net

利用される分野が違う言語を比較して、なんの参考にしたいんだろう
分野は気にならんの？

316 ：デフォルトの名無しさん：2022/09/05(月) 22:43:52.15 ID:098gBdTn.net

>>313
Rust以外は言語機能で本質的な改善になってないからね

317 ：デフォルトの名無しさん：2022/09/05(月) 22:45:04.42 ID:4OHy49Sd.net

>>314
jsのマイナスはtsに乗り換えてるんだろけど
Rubyの落下率がひどいな…

318 ：デフォルトの名無しさん：2022/09/05(月) 22:49:48.10 ID:TWq6epN6.net

GoとTypescript書ければ仕事には困らないな、うん

Rustは仕事の需要はないけど趣味やOSS活動でやる分にはいいかもしれない

319 ：デフォルトの名無しさん：2022/09/05(月) 23:05:10.53 ID:g3RfqaIY.net

>>315
それを言うとそもそもこのスレのスレタイがどうなのよという話になる

320 ：デフォルトの名無しさん：2022/09/05(月) 23:11:05.60 ID:LWnBOcCn.net

このスレは言語機能そのものについて語るスレだと思ってた
人気について話したいひともたくさんいるんだろうけど

321 ：デフォルトの名無しさん：2022/09/05(月) 23:26:38.48 ID:1hFtemgL.net

Nim言語マニュアルの日本語訳がスゴい

Nim ドキュメンテーションの総覧
https://nim-lang-081.osdn.jp/docs/index.html

Arigatou

322 ：デフォルトの名無しさん：2022/09/05(月) 23:26:43.28 ID:iWQD5HeB.net

Rustはオワコンだから使たらアカンやで。

323 ：デフォルトの名無しさん：2022/09/05(月) 23:27:36.08 ID:9iTWKe04.net

>>311
全てを最初から用意するのは不可能だけど、標準ライブラリで事足りるってのは利用側としてはメリットでかいぞ。
もちろんrustがあえてコア重視してるのはわかるが、お陰で非同期とか今時普通なものも乱立してる。

324 ：デフォルトの名無しさん：2022/09/05(月) 23:31:48.82 ID:iWQD5HeB.net

Rsutと云う泥船に乗せて一緒に沈没させようとしている奴らが居る。
どこの教団や！？

325 ：デフォルトの名無しさん：2022/09/05(月) 23:33:58.91 ID:9iTWKe04.net

>>324
はいはい、おじいちゃんもう寝る時間よ。

326 ：デフォルトの名無しさん：2022/09/05(月) 23:36:58.16 ID:iWQD5HeB.net

Redditの今年最悪の言語に早くもリーチかけてるからな。

327 ：デフォルトの名無しさん：2022/09/05(月) 23:57:58.08 ID:g3RfqaIY.net

>>326
どこで集計してるの？

328 ：デフォルトの名無しさん：2022/09/06(火) 00:00:31.26 ID:bpHcrLU1.net

>>318
俺は趣味ならnimにちょっと興味ありな感じ。まだ全く手は出せてないけど。

329 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>321
コンパイラの内部構造とかは勉強になるな。メモリ管理は種類多すぎな気もするが。

330 ：デフォルトの名無しさん：2022/09/06(火) 09:44:45.25 ID:9WMtC8UL.net

>>322
Rubyのことなら同意

331 ：デフォルトの名無しさん：2022/09/06(火) 09:47:23.91 ID:eR9fijNj.net

Rust使えない癖に持ち上げまくってるキチガイとRustとRubyの区別のつかないやつが論争する地獄のようなスレ

332 ：デフォルトの名無しさん：2022/09/06(火) 10:25:40.40 ID:VRQQIzRo.net

RustとRubyはほぼ同じや

333 ：デフォルトの名無しさん：2022/09/06(火) 10:30:10.58 ID:eR9fijNj.net

CのライブラリとJavaのライブラリと.NETが使えてWebAssemblyも記述できる言語ができれば最強
と思ったけどそれってC#やF#じゃん

334 ：デフォルトの名無しさん：2022/09/06(火) 10:33:00.76 ID:eR9fijNj.net

https://biotech-lab.org/articles/12849
numpyも使えたのか
もう全部C#でいいんじゃないかな

335 ：デフォルトの名無しさん：2022/09/06(火) 10:50:43.10 ID:c9hFcGPw.net

>>200のグラフを見ると
C#やNimは遅くて
C++やRustより2-3倍も遅い理由はなぜ？

336 ：デフォルトの名無しさん：2022/09/06(火) 10:54:20.03 ID:eR9fijNj.net

>>335
誤差
10の13乗ものループでそれだけのミリ秒数しか違いが出ないということは実際にその違いが問題になることはほとんどない

337 ：デフォルトの名無しさん：2022/09/06(火) 10:55:43.20 ID:eR9fijNj.net

要するにそのグラフの差は五十歩百歩でしかなくそれ以上の速度が必要ならスーパーコンピュータを視野に入れることになる

338 ：デフォルトの名無しさん：2022/09/06(火) 11:22:14.85 ID:7s2bxSL8.net

スーパーコンピュータなら速く動くとかいうことは全くないけどな
なんならオーバークロックしたゲーミングPCとかのほうが速い
スパコンはPCではそもそも実行不可能なレベルの超大規模な問題を解くためのもので
普通のプログラムが魔法のように速く動くという代物ではない

339 ：デフォルトの名無しさん：2022/09/06(火) 11:23:08.83 ID:VRQQIzRo.net

教プロで１３乗も扱わねえよ
多くても７，８ぐらい

340 ：デフォルトの名無しさん：2022/09/06(火) 11:38:16.60 ID:hbXRPtoA.net

>>331
そもそも地獄レベルの問題を処理する競技が流行ってるので

341 ：デフォルトの名無しさん：2022/09/06(火) 12:01:26.94 ID:6ZyYoNhQ.net

>>339
温すぎて笑う
ブルートフォースで解けるレベルじゃん
PaizaのAランクの話でもしてんの？

342 ：デフォルトの名無しさん：2022/09/06(火) 12:04:20.22 ID:6ZyYoNhQ.net

>>338
競プロの問題は並列化で速く解けることも多いからスパコンの得意とするところだぞ

343 ：デフォルトの名無しさん：2022/09/06(火) 12:31:10.58 ID:QxRWO4Sk.net

Ruby は遅いから、1秒で100万回ループ。
これがJIT で、1千万回になる

でも、Rails などでは、10万個をJITしても、そんなに速くならない。
I/O 中心の処理では効果がない

外部にアクセスせずに、延々と行列演算を繰り返すような、
CPU セントリックな処理では効果があるのかも

344 ：デフォルトの名無しさん：[ここ壊れてます] .net

Nimは始まる前に終わりそう
がんがれ

345 ：デフォルトの名無しさん：2022/09/06(火) 14:09:11.24 ID:0lLJmQPI.net

>>342
実際のスパコン触ってみれば分かるんだけど、競プロの問題って小さすぎて並列性がなさすぎるんよ
1秒以内で終わっちゃうようだとMPIのコストどころかGPUにオフロードするコストすら回収できるか怪しい

346 ：デフォルトの名無しさん：2022/09/06(火) 14:13:42.45 ID:zHtqeu+H.net

>>345
ダイクストラ法とか結構出番あるだろ
なんで並列化しねーの？

347 ：デフォルトの名無しさん：2022/09/06(火) 14:47:11.13 ID:Uhu0FGeL.net

Amazonが>>9の記事で書いているように
C/C++/Rustで書けば2〜10倍は速くなり
それは電気代やCo2排出も同様になる
さらに省メモリになる点も考慮すると
サーバーやクラウド利用コストは確実に数倍差
言語の選択を変えるだけで支出も激減

348 ：デフォルトの名無しさん：2022/09/06(火) 14:57:13.57 ID:zHtqeu+H.net

ハードウェアアクセスの速度が変わらんのにベンチマークだけで胡散臭いこと言うなよ

349 ：デフォルトの名無しさん：2022/09/06(火) 15:08:57.93 ID:gWeaoLnz.net

>>346
並列性がないというか、並列化しても元々の実行時間が短いからオーバーヘッドが大きすぎて割に合わないという話では
スパコンのジョブって短くても実行時間数十分だったりするから競プロとは前提が違う

350 ：デフォルトの名無しさん：2022/09/06(火) 15:28:54.40 ID:VRQQIzRo.net

元々の問題設計がN^2で失格 NやNlogNオーダーで通るようなってるとしたら
N^2で並列化出来てもTLEだわ

351 ：デフォルトの名無しさん：2022/09/06(火) 15:49:30.99 ID:hbXRPtoA.net

誰でも思いつくのはGCの並列化だが
GCは何言語で書かれているのかを誰も知らない

352 ：デフォルトの名無しさん：2022/09/06(火) 17:20:08.41 ID:ri7pjbsX.net

コンパイル型の実行速度でスクリプトでも実行でき、コンパイルもできる言語が欲しい。反対を言えばbashのように
１行ずつ実行し、実行中で書き換えられることまでは必要ない。
単純なスカラーのループを書いたら、一台のCPUのレジスターだけをブン回す機械語のコードが生成されて欲しい。
A*Bと書くだけで千の計算を搭載されているメジャーなGPUで勝手に計算したり、あるいは千のマシンに分散して
実行して巨大な行列の積をポンと計算してもらいたい。
型だって必要ないなら指定したくない。もしポリモーフィックな関数が必要な時には、ジェネリックプログラミングを
使ってアルゴリズムを一度だけ書いて、あとは全ての型に使いたい。
ガーベージコレクション、あるいはメモリーマネージメントは循環参照や多重参照がなければRustのようにスコープを
抜けたら基本は消えるだけで十分でもあるが、循環参照をもったら自動でサイクリックGCも欲しい
並列化、あるいは非同期化に余計なコストを払いたくない、async/awaitなんてもってのほか論外、世紀の間違い。
ErlangやGoのようにspawnやGoで軽量プロセス起動は仕方ないにしても、これは必須ではなく、デコレーションで
あって並列ではなくとも動ける控えめなヒント情報であってほしい
ドライバ、あるいはOSやカーネルなどのハードウェアよりな開発にも利用できてほしいけど、例外あるいはpanicも欲しい

353 ：デフォルトの名無しさん：2022/09/06(火) 18:45:34.78 ID:txnX2wDb.net

Amazonの言うこと信じる人もいるんだ。
そりゃ霊感商法もなくならないわ。

354 ：デフォルトの名無しさん：2022/09/06(火) 18:50:05.82 ID:iU1ybZ8L.net

GCしないでプロセスごと捨てるのがスマートよ

355 ：デフォルトの名無しさん：2022/09/06(火) 20:47:28.58 ID:NO/n5LTM.net

>>321
https://nim-lang-081.osdn.jp/docs/tut1.html
> # 前方宣言:
> proc even(n: int): bool

前方宣言てｗ
これ書かされる言語まだあるんだ

> プロシージャで呼び出し元の引数を変更する必要があるならば、 var パラメータを使います。
> proc divmod(a, b: int; res, remainder: var int) =

パスカルのVariable parameterっぽいなこれ
ちなパスカルだと

https://wiki.freepascal.org/Variable_parameter
> procedure xorSwap(var left, right: integer);

こっち側にvarを書く

356 ：デフォルトの名無しさん：2022/09/06(火) 21:02:15.19 ID:+TeoQt4K.net

>>355
immutableかmutableかの区別宣言は絶対に必要だから
あとは各言語でそれをどのように表現するかだけでしょ
それをvar val let const など各言語で色んな表現の使い分けがあり更に引数でどうするかだけ
>>241のケースも考慮するとRustのmut付加方式がベストな解決かな

357 ：デフォルトの名無しさん：2022/09/06(火) 21:05:47.04 ID:NO/n5LTM.net

ん？
パラメータのいわゆる参照渡しの話なんだけどな

358 ：デフォルトの名無しさん：2022/09/06(火) 21:17:25.60 ID:MV3crhGe.net

ponylangだとbehaviorが終わるごとに該当アクターでGCを回すからプログラムとしては停止しないんだけども、これを並列GCですって言うのもなんだかなといった風情

359 ：デフォルトの名無しさん：2022/09/06(火) 21:21:35.81 ID:3wQQbwTr.net

>>355
>>357

何が ? なのかも少し詳しく

360 ：デフォルトの名無しさん：2022/09/06(火) 21:31:19.57 ID:ItiT2cL1.net

MPIバリバリ使ってるけど競プロの問題を解くようなタスクでは使わないよ
課題設定があまりにも違い過ぎる

361 ：デフォルトの名無しさん：2022/09/06(火) 21:37:52.05 ID:6CvxnJgX.net

>>357
Rustはその2種類の区別もmutの位置で区別できてるね

①引数が値渡しで来て関数内で値を書き換える場合
例: fn func1(mut x: i32) { …
　→値渡しなので呼び出し元には影響なし

➁引数が参照渡しで来て関数内で参照元を書き換える場合
例: fn func2(x: &mut i32) { …
　→可変参照渡しなので呼び出し元の対象は書き換わりうる

362 ：デフォルトの名無しさん：2022/09/06(火) 22:22:04.19 ID:jOWG7AxE.net

あんた上手に振る舞えって言われてたやつだろ
Rustは出来るじゃねえよw 当たり前だ
お前が議論を理解出来てなかっただけだろ
そういうところが周りをイラつかせてるんだぜ

363 ：デフォルトの名無しさん：2022/09/06(火) 22:30:02.86 ID:NO/n5LTM.net

>>361
> Rustはその2種類の区別もmutの位置で区別できてるね

二種類の区別？

> 例: fn func1(mut x: i32) { …
> 例: fn func2(x: &mut i32) { …

これリファレンスかどうかってmutの位置関係ある？
Rustよくわからんけど & つけたらリファレンスになるだけじゃないの？
何の話を俺にしたいの？

>>359
Nimの参照渡しの表現に見覚えあるわってレスしただけなんよ俺はｗ

364 ：デフォルトの名無しさん：2022/09/06(火) 22:34:57.09 ID:2HxKYUoj.net

Rustだと両方ができて当たり前だが
プログラミング言語の中には
値を渡すか参照を渡すかをプログラマーが選べない言語も意外と多い
全てがどちらかに決められていたり
型によって各々どちらかに決められたり
メジャーな言語でも制限があったりする

365 ：デフォルトの名無しさん：2022/09/06(火) 22:40:49.84 ID:V53xvAGb.net

>>363
Rustは2種類の参照渡しがある
Tを参照元の型とすると
&T が(可変じゃない)参照
&mut T が可変参照
だから貴方が書いた>>355の話と同じじゃないかな

366 ：デフォルトの名無しさん：2022/09/06(火) 22:43:24.65 ID:ZgGRtw1t.net

>>362 >>364 本当だ自分の勘違いを棚に上げている

367 ：デフォルトの名無しさん：2022/09/06(火) 22:44:16.65 ID:NO/n5LTM.net

パスカル書いてた人なら
「パスカルなついｗ　引数んとこにvarって書いてたなｗ」
で終わる話
皆の衆なんか混乱させてすまんかったな(´・ω・｀)

368 ：デフォルトの名無しさん：2022/09/06(火) 22:47:53.44 ID:ZgGRtw1t.net

上手いね 見習いたまえ

369 ：デフォルトの名無しさん：2022/09/06(火) 22:53:11.35 ID:tijl2CjL.net

複オジに相手にしてもイライラするだけやぞ
もう少しスルー力の鍛えようや

370 ：デフォルトの名無しさん：2022/09/06(火) 22:53:17.60 ID:2HxKYUoj.net

可変参照を渡すか可変じゃない参照を渡すかの区別がない言語もある
区別がある言語でもさらに2種類に分かれて
呼び出される関数でその参照が可変かどうか区別するだけの言語と
呼び出し側でも渡す参照が可変かどうか区別できる言語に分かれる
それら3種類のうち最後のタイプの言語が最も安全にプログラミングできる

371 ：デフォルトの名無しさん：2022/09/06(火) 22:58:14.58 ID:ZgGRtw1t.net

野放しは危険やで NGワードでtag付けする?
>>NNN複オジ

372 ：デフォルトの名無しさん：2022/09/06(火) 23:04:31.77 ID:V53xvAGb.net

&Tを渡すか&mut Tを渡すかを渡す側で区別できない言語だと書き換えられちゃうのか分からない点で困るね
その場合でも呼び出す関数の引数宣言を見に行けばいいけど、そこにも可変かどうか宣言できない言語もあって絶望的なことも

373 ：デフォルトの名無しさん：2022/09/06(火) 23:10:15.88 ID:ZgGRtw1t.net

自演でしょ
>>372
複オジ

374 ：デフォルトの名無しさん：2022/09/06(火) 23:12:00.01 ID:p3/oNdmv.net

その点もRustが一番考えられてる仕様のような
色んな言語の中で一番ちゃんときちんと区別してくれていてプログラミングする上で安心感もあるなあ

375 ：デフォルトの名無しさん：2022/09/06(火) 23:18:07.56 ID:ZgGRtw1t.net

一番宣言
>>374
複オジ

376 ：デフォルトの名無しさん：2022/09/06(火) 23:23:59.02 ID:MV3crhGe.net

ponyなら書き込みどころか読み込みまで制限できるぜ
参照の持ち方だけで6つもあるのやばいだろと思ったが減らせる見込みもないぜ

377 ：デフォルトの名無しさん：2022/09/06(火) 23:27:00.72 ID:ZgGRtw1t.net

>>376いいねこのスレにふさわしい

378 ：デフォルトの名無しさん：2022/09/06(火) 23:29:15.38 ID:ItiT2cL1.net

Nim好きなんだけど何で売れんかね
pythonからの乗り換えに最適なんだが

379 ：デフォルトの名無しさん：2022/09/06(火) 23:30:19.86 ID:ZgGRtw1t.net

よく考えたらこれも組織票野党が投票率下がった方が有利なように、スレ乗っ取りの下地作り？
>>369複？オジ？

380 ：デフォルトの名無しさん：2022/09/06(火) 23:30:47.03 ID:3jr2SH77.net

ponyとか真面目な話がしたいならﾜｯﾁｮｲスレ行ったほうがいいよ
複おじをいじって遊びたいならここでいいけど

381 ：デフォルトの名無しさん：2022/09/06(火) 23:34:47.24 ID:V53xvAGb.net

昔は変数もmutableとimmutableの区別をしないのが多数派だった時代もあったそうだから
新しく作られた言語のほうが色々と新たな進化ができて有利なのかもね

382 ：デフォルトの名無しさん：2022/09/06(火) 23:36:47.66 ID:ZgGRtw1t.net

>>378いいね ちょっと動かせるデモサイトで乗り換え例のようなものはあるの？

383 ：デフォルトの名無しさん：2022/09/06(火) 23:39:56.37 ID:W/Xh3l1r.net

>>376
マジ？
ponyで読み込みを制限して書き込みのみにするのはどの修飾子を使えばいいの？

384 ：デフォルトの名無しさん：2022/09/06(火) 23:42:44.75 ID:ZgGRtw1t.net

>>380いや このスレが乗っ取られないことが重要 tag付けhelp me pls

385 ：デフォルトの名無しさん：2022/09/06(火) 23:50:57.29 ID:ZgGRtw1t.net

>>381そうそう設計時点での思想って重要 増改築は面倒だから でも増改築できる柔軟性も必要

そろそろ落ちます tag付けhelp us pls

386 ：デフォルトの名無しさん：2022/09/06(火) 23:55:28.57 ID:k32oXi62.net

Ponyで参照はsingle writer xor multiple readersが課されているためwriterがいる時は読み込みができない
つまりRustと同じ

387 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>383
食いつかれると思ってなかったから少し語弊がある書き込みだったかもしれない
ponyは変数ごとにReference Capabilityという修飾子を持ってて、それで読み書きと変数をコピーしたときの権限を管理してる
読みを制限しながら書き込めるのはisoとtrn

>>386
Rustって変数の参照を作らせないって設定はできるんだっけ？
あと読み書きしないけど値の存在だけは確認したいときってどうすんの？

388 ：デフォルトの名無しさん：2022/09/07(水) 00:39:18.74 ID:8j1OJp6D.net

ほとんどの言語はオブジェクトとかヒープで確保したものとか参照のみサポートが多いよね
参照を作らせなかったらどうやってアクセスするのだろう
移動しかないか

389 ：デフォルトの名無しさん：2022/09/07(水) 01:29:02.34 ID:zcaR9K+x.net

>>388
へーRustにできないことがあるんだね
スタックかヒープなんて聞いてないよ

390 ：デフォルトの名無しさん：2022/09/07(水) 02:20:15.23 ID:NRm/XQ9U.net

Rustなら&selfメソッドを作らずにselfメソッドだけを用意すれば
その型は参照に対して全く働かずに移動に対してのみ使える型にすることはできるな
もちろんそのままだと移動で消費してしまい消えるのでそれを避けたい時Selfで再び自分を返すことになる
不便だが参照を全く使わずともその範囲で色々やれるようだ

391 ：デフォルトの名無しさん：2022/09/07(水) 02:31:29.39 ID:nvFpxuri.net

移動も聞いてないぞ

392 ：デフォルトの名無しさん：2022/09/07(水) 03:01:09.81 ID:NRm/XQ9U.net

>>391
参照を使わないなら値そのものを移動するしかないだろ
他に何を期待してるんだ？

393 ：デフォルトの名無しさん：2022/09/07(水) 03:02:32.55 ID:ossJLtb4.net

>>380
ここは複おじを育てるスレだからな
育成ゲームみたいなもん

394 ：デフォルトの名無しさん：2022/09/07(水) 03:08:26.53 ID:FVgAnmdd.net

ははぁーん

聞かれたことに答えない
息をはくように話をそらす
それた話を修正しない
そもそも何を聞かれたかわかっていない

これって？

もしかして国語で苦労した？
tag付けて欲しい？

395 ：デフォルトの名無しさん：2022/09/07(水) 03:19:36.97 ID:2H+EvabS.net

Ponyでもconsumeにより参照を使わず移動になるよ

396 ：デフォルトの名無しさん：2022/09/07(水) 03:25:07.36 ID:Lg2r352+.net

それた話を修正しない

Goスレで論破されて敗走してきたんだ
でここに居つくために育成ゲームだとホザキ始めた

397 ：デフォルトの名無しさん：2022/09/07(水) 04:13:08.28 ID:2H+EvabS.net

なんのことやら
参照を全く使わないのは無理だけど
単独参照となり読み書き自由に専有できるのならあるよー
Ponyならiso
Rustなら&mut

398 ：デフォルトの名無しさん：2022/09/07(水) 04:15:54.48 ID:GNmKbNsR.net

そらした話は修正しない
そもそも何を聞かれたかわかっていないフリ

Flutterスレ盛り上げてこいよ

399 ：デフォルトの名無しさん：[ここ壊れてます] .net

誰にも参照されてないのにGCされない現象を実現したいわけではなさそう
ということは「参照を作らせない」とはいえ参照は作れるんだよね

400 ：デフォルトの名無しさん：[ここ壊れてます] .net

そらした話は修正しない
すり替えた土俵ではRustと〜は同等
そもそも何を聞かれたかなんて知らない。無意味 気持ち悪い
参照とかGCの事は実はよく知らない。育成してくれ

Flutterスレ盛り上げてこいよ

401 ：デフォルトの名無しさん：2022/09/07(水) 06:26:49.06 ID:t2gi/CWf.net

>>378
Pythonで十分だからじゃね
情報の多さが違う
Pythonは遅いのが欠点だけど遅いのが問題になることってそんなにないんだよねえ

402 ：デフォルトの名無しさん：2022/09/07(水) 06:52:15.00 ID:ordz3g2+.net

>>390
Rustの構造体は中身が非公開だからメソッド制限でいけるのか
失念してたわ
あとはtrnあたりの挙動を再現できるかだな

>>397
&mutだと新しい読み取り専用の参照が出てくるの防げなくない？

403 ：デフォルトの名無しさん：2022/09/07(水) 06:53:00.83 ID:nA6d9voX.net

どうしても速さが必要なところだけRustにするとしても
それ以外はPythonで十分な気がする

404 ：デフォルトの名無しさん：2022/09/07(水) 07:00:12.32 ID:7SEt3XdA.net

>>403
実は速度の事、よく知らない
つい先日 自動ベクトル化とかSIMDとか育成された。育成を要求した俺すごい

Flutterスレ盛り上げてこいよ

405 ：デフォルトの名無しさん：2022/09/07(水) 07:13:06.99 ID:+WGAm7/P.net

>>386 >>397
GoスレでSIMDをふりかざしたのに論破された。更なる育成を要求する

Flutterスレ盛り上げてこいよ

406 ：デフォルトの名無しさん：2022/09/07(水) 07:16:05.47 ID:hRBB26Yn.net

>>402
弱くなる方向は何も問題無いでしょう
しかもRustは参照のライフタイムもコンパイラが管理把握できているため大丈夫でしょう
Ponyはその分をプログラマーが細かく指定して更にrecoverなど変化させていくことで補うわけです

407 ：デフォルトの名無しさん：2022/09/07(水) 07:18:00.16 ID:ordz3g2+.net

>>399
ponyだとどの変数も参照だから最初の参照は作れる
で、その参照から新しい参照を複製するときに複製さきの権限を制御する

Rustだと最初に作る変数は値のはずだから雑に変えてる

408 ：デフォルトの名無しさん：2022/09/07(水) 07:21:36.81 ID:6xyGFf7w.net

>>406
Rustはコンパイラが管理で安全 Pnoyはプログラマーの責任
Rustスレでビット幅なんて間違えていない。コンパイラが保証した

Flutterスレ盛り上げてこいよ

409 ：デフォルトの名無しさん：2022/09/07(水) 07:23:19.72 ID:8x7iT+wj.net

ponyは面倒すぎて萎える
こんな参照の管理くらいコンパイラが自動的にやるべきで人間に押し付けるのは悪手

410 ：デフォルトの名無しさん：2022/09/07(水) 07:30:00.20 ID:ANYrsupz.net

>>409
参照とか永遠に分からなくてもコンパイラが保証してくれるRustすごい、俺すごい。成長した

Flutterスレ盛り上げてこいよ

411 ：デフォルトの名無しさん：2022/09/07(水) 07:42:15.35 ID:ordz3g2+.net

>>406
確かにborrow checkerも働くみたいだし機能上の問題はないようだね
とはいえ、元の発言は単独参照で読みを占有できると言ってるからね

412 ：デフォルトの名無しさん：2022/09/07(水) 07:45:25.38 ID:+d3zlyKh.net

参照とかスタックとかヒープ、移動、元の発言なんて実はよく知らない。
所有権の複製こそ最善手
永遠に分からなくてもコンパイラが保証してくれるRustすごい、俺すごい。成長した
だがいつでも育成を要求する扉は開いている

Flutterスレ盛り上げてこいよ

413 ：デフォルトの名無しさん：2022/09/07(水) 07:57:54.75 ID:eUEKoWnI.net

>>412
すみません、所有権の複製ってなんですか...?
clone()とかでオブジェクトをコピーすると、複製後のオブジェクトに対して、別の新しい所有権がただ一つ代入先の変数に束縛されるという認識だったのですが...

414 ：デフォルトの名無しさん：2022/09/07(水) 08:06:19.67 ID:gZR3Yo8R.net

>>413
ゴネれば相手が勝手に折れる
ゴネ権の複製こそ最善手
いつでも妥協を要求するカードを複製している

Flutterスレ盛り上げてこいよ

415 ：デフォルトの名無しさん：2022/09/07(水) 08:09:45.92 ID:41cUJGIp.net

>>387
＞読み書きしないけど値の存在だけは確認したいときってどうすんの？

Null安全な言語では値が存在しないことを表すNullなどを普通の型には代入できないことでNull安全性を実現している
そのためNullを代入できるNullableな型が用意されておりNullかどうかは値自体の読み書きとは別に可能な言語が多い

RustならばOption<T>がNullableな型でNullはNoneと表記する
Option<T>のメソッドis_some()かis_none()によって値自体の読み書きをせずに値の存在だけを確認できる

416 ：デフォルトの名無しさん：2022/09/07(水) 08:19:14.45 ID:C9aPpQqG.net

>>415
ボールは投げ返した
メモリレイアウトがどう変わるか、何も知らなくてもコンパイルが通る範囲でRustが保証する
どうだ怖いか

Flutterスレ盛り上げてこいよ

417 ：デフォルトの名無しさん：2022/09/07(水) 08:23:50.75 ID:E0QYSaMt.net

Rustは低レベルの対応も必要だから、mutable必要なんだろうけれど、理想はImmutableだけじゃないの？

418 ：デフォルトの名無しさん：2022/09/07(水) 08:26:20.07 ID:AY0Q59m9.net

>>417
イミュータブルを使わないと再帰が増えてハードル上がるから

419 ：デフォルトの名無しさん：2022/09/07(水) 08:34:10.43 ID:ASjGwh81.net

同じforループでも

for (i = 0; i < 10; i++)
これは見るからにmutableだけど

for i in 0..10
これは毎回別のimmutableがやってくる感じ

420 ：デフォルトの名無しさん：2022/09/07(水) 08:39:03.96 ID:SuR+St8r.net

いいかげん 俺ウザいだろ
tagが自然発生したぞ
どうだ怖いか

Flutterスレ盛り上げてこいよ

421 ：デフォルトの名無しさん：2022/09/07(水) 09:44:51.32 ID:XqqYtKGz.net

イミュータブルはzero overhead abstractionとは対極だからな
特にRustの場合は関数型みたいにオブジェクトの一部を書き換える度に新しいオブジェクト作るとかやってたら細切れに解放が必要になってコンパイルも実行もクソ効率悪そう

422 ：デフォルトの名無しさん：2022/09/07(水) 10:24:02.90 ID:aeiTHGZS.net

>>241
必要性もないコピーを部分可変にするアンパックは例が悪すぎる。let t = (0, 1, 2);として
let (a, mut b, c) = foo; こんな風に書くより
println!("{} {} {}", t.0, t.1+100, t.2);アンパックせず、このように書くか
let (a, b, c) = t;
println!("{} {} {}", a, b+100, c);アンパックしても即値計算ならわざわざmutは必要ないですよね
あるいはもっと複雑な算術する必要があるなら、単独でlet mut で、let mut b= t.1+100;
どっちにしてもlet (a, mut b, c) = foo; なんてほとんど使わないのではないか、なにより見た目が気持ち悪い。
これが最高だという人もいるけど、個人的にはなんかしっくりこないな
ほかの言語の多値戻り値のように()カッコさえなければ良いのに・・・・

423 ：デフォルトの名無しさん：2022/09/07(水) 11:56:35.70 ID:a104GDG0.net

>>393
それめちゃくちゃしっくりくる
誰もあんな嫌なやつ育てたくないわな

424 ：デフォルトの名無しさん：2022/09/07(水) 13:08:54.29 ID:ossJLtb4.net

>>401
俺仕事でNLPやってるけどトークナイザの実装がクソ遅いんだよ
英語だとRustで実装されたfastバージョンがあるんだけど
日本語対応のやつはゼロ
作らしてくれーと言ってるけど許可降りない

425 ：デフォルトの名無しさん：2022/09/07(水) 13:44:11.23 ID:AY0Q59m9.net

>>424
日本語の字句解析なんてやったことあんの？
片手間でできるようなもんじゃないぞ
Cで書かれたありもの使えよ

426 ：デフォルトの名無しさん：2022/09/07(水) 14:05:06.57 ID:ossJLtb4.net

>>425
やったことあるから言ってるんだが？
それに今時の自然言語処理って転移学習は必須
そのためにはトークナイザとモデルを合わせなきゃいけなくてこれがめちゃくちゃ使いにくい

427 ：デフォルトの名無しさん：2022/09/07(水) 14:09:08.42 ID:AY0Q59m9.net

>>426
やったことあるならその時のが残ってるだろ
それをプレゼンしてだめなら自分の思ってるほどの性能は出てないてことじゃね

428 ：デフォルトの名無しさん：2022/09/07(水) 18:37:19.13 ID:eUEKoWnI.net

>>421
オブジェクト作るって、ヒープのアロケーションを想定してる？

429 ：デフォルトの名無しさん：2022/09/07(水) 19:13:42.89 ID:ge/fWvoV.net

いるよな、知りもしない癖に口出してくるやつ。

430 ：デフォルトの名無しさん：2022/09/07(水) 19:20:29.73 ID:OCYL1nNS.net

>>428
所有権の複製こそ最善手

431 ：デフォルトの名無しさん：2022/09/07(水) 20:04:27.92 ID:t2gi/CWf.net

>>429
論破されて自演はみっともないぞw

432 ：デフォルトの名無しさん：2022/09/07(水) 20:06:49.94 ID:/qhkAnst.net

今夜のAAPLの発表まで暇つぶし

早いもので2年か、改めて見る
Scalaが日本で衰退し始めている理由を説明します
https://www.yout
ube.com/watch?v=kFzLia7YZQU

433 ：デフォルトの名無しさん：2022/09/07(水) 20:17:13.33 ID:dqzrycJl.net

https://madnight.github.io/githut/#/pull_requests/2022/1

上げ幅で言うとC++が一番上がってるんだよね。

434 ：デフォルトの名無しさん：2022/09/07(水) 20:18:37.12 ID:dqzrycJl.net

C++は3年ごとに改定されるので、歴史ある言語でありながら、次世代言語でもあるんだよね。
素晴らしいことだと思います。

435 ：デフォルトの名無しさん：2022/09/07(水) 20:21:49.10 ID:F4QYab6d.net

3年ごとに改定って道路工事かよ
おいしい

436 ：デフォルトの名無しさん：2022/09/07(水) 20:31:13.48 ID:g9jqSBBW.net

SDGs的に完成は最悪手
発注側も分かってる

Scalaは完成しちゃったの？

437 ：デフォルトの名無しさん：[ここ壊れてます] .net

Haskellも完成
Goはver2いつ出すんだレベル

438 ：デフォルトの名無しさん：[ここ壊れてます] .net

いい意味で
言葉足らずでした

439 ：デフォルトの名無しさん：2022/09/07(水) 20:47:36.68 ID:g+neltEd.net

>>422
プログラミングをしたことがないからそんな発想になる
関数からタプルなどが返ってきて別々に使うなど日常茶飯事
例
let (tx, mut rx) = mpsc::channel(10);
個別にmut指定する仕様は尊い

440 ：デフォルトの名無しさん：2022/09/07(水) 20:52:51.19 ID:nXW6tumg.net

>>439
Goスレでpromise/channelの育成を要求して成長した

441 ：デフォルトの名無しさん：2022/09/07(水) 20:58:01.38 ID:g+neltEd.net

>>440
Goにpromiseができたの？
Goスレ見に行くほど追ってないので知らんけど

442 ：デフォルトの名無しさん：2022/09/07(水) 21:00:46.44 ID:mFj19fp9.net

>>441
Rustの仕様は完成した
俺尊い

443 ：デフォルトの名無しさん：2022/09/07(水) 21:14:05.84 ID:g+neltEd.net

>>442
Rustは公開されている山のようにあるTODOリストが常に少しずつ進行中
大きなことから小さなことまで機能追加でどんどん便利になっている

444 ：デフォルトの名無しさん：[ここ壊れてます] .net

機能追加はcrate/macroで起こってる だがcoreは封鎖した
Go動向を追う最善手はGoスレ見に行くことである
知らんけど

445 ：デフォルトの名無しさん：2022/09/07(水) 21:36:37.03 ID:LgczABzT.net

そろそろ風呂に入ってくる
だが隙あらばスタックとヒープ mpscとスレッド安全の育成を要求する扉はまだ開いている 乗り遅れるな

446 ：デフォルトの名無しさん：2022/09/07(水) 21:44:22.20 ID:g+neltEd.net

>>444
外部crateの話は一切していなくて
Rust言語が日々進化しているとは
Rustコンパイラによる機能追加と改善
および標準ライブラリの機能追加を指す
もちろんcoreライブラリ部分にも追加やstable化などがある

447 ：デフォルトの名無しさん：2022/09/07(水) 21:53:02.05 ID:En8I5Kb5.net

>>428
その人じゃないけどRustでは特に指定しなければオブジェクトなどもスタック上に作られるよ
例えばCのコードと同じ動作をRustで書かれた>>181のイテレータメソッドチェーンのコード
各イテレータ毎にそのオブジェクトがスタック上に作られるね
結果としてC言語でforを回したり関数ローカルのmax変数を使うのと同じ
そのため全く見た目が異なるRustコードとCで同等の生成コードが出来上がってるわけ

448 ：デフォルトの名無しさん：2022/09/07(水) 22:26:11.82 ID:bnLUEQYt.net

>>447
>各イテレータ毎にそのオブジェクトがスタック上に作られる
スタックもヒープもasmもhardware levelは何も知らない。育成ry

449 ：デフォルトの名無しさん：2022/09/07(水) 22:36:50.03 ID:g+neltEd.net

ヒープ利用は確保と解放操作が必要だから必ず遅い
スタック利用はスタックポインタの増減を関数の最初と最後でまとめてするだけで速い
さらに最適化でレジスタ利用になりうるから超速い

450 ：デフォルトの名無しさん：2022/09/07(水) 22:37:48.00 ID:SiZHOEm5.net

>>447
職場でその言葉を知ったかしたら相手が勝手に納得しました。魔法のコトバ

育成無用 ヒント無用

451 ：デフォルトの名無しさん：2022/09/07(水) 22:41:11.76 ID:fqrBDyte.net

>>449
隙をみて恥をかき捨てた事でたった今 1mm成長した。俺すごい

452 ：デフォルトの名無しさん：2022/09/07(水) 22:54:26.21 ID:5lmH+vKI.net

>>449
重箱の隅だけど malloc/freeは最適化で消えることがあるから "必ず遅い" は言い過ぎ
ヒープ利用でもレジスタが使われることもある
https://godbolt.org/z/crxTse4vG

453 ：デフォルトの名無しさん：2022/09/07(水) 23:04:02.99 ID:JYc4oRyX.net

>>452
重大なヒントleakかと思ったけど最低限で良かった
明日 職場で知ったかしてもらう予定

454 ：デフォルトの名無しさん：2022/09/07(水) 23:18:52.05 ID:MCKgMvZG.net

>>453
ボッチ自宅開発者だからオジが知ったかできる場所は5chだけ
リアルでやってたらここまで酷いことにはならない

455 ：デフォルトの名無しさん：2022/09/07(水) 23:25:44.51 ID:4U49yzDh.net

>>454またはPython職場でRust勉強会をしてて自分が一番詳しいと思われたい&
Rust使わせてくれない上司を見返したくて頑張ってるんだよ。
ウルウルくるぅ

456 ：デフォルトの名無しさん：2022/09/07(水) 23:27:02.51 ID:g+neltEd.net

>>452
ご指摘ありがとう
誤解させる書き方してしまいごめん

457 ：デフォルトの名無しさん：2022/09/07(水) 23:39:50.25 ID:LgsdK3r3.net

>>456その謝り方リアルでやっちゃだめだぞ

458 ：デフォルトの名無しさん：2022/09/07(水) 23:41:58.89 ID:En8I5Kb5.net

>>452
その例は現実的ではないよね
実際の使われ方だと新規オブジェクト生成は通常は別関数だから
それをinline指定でもしない限りは別関数にあるmallocは消えないです
ヒープ確保は常に行われてしまいます

一方でRustでは新規オブジェクト生成が同様に別関数でinlineでなくても
オブジェクトを「値返し」するので大丈夫です
オブジェクト生成する別関数でも呼び出す側でもヒープの利用はありません

459 ：デフォルトの名無しさん：2022/09/07(水) 23:58:53.34 ID:a/h0B3rR.net

RustよりもCが遅いケースが生じる一因だな

460 ：デフォルトの名無しさん：2022/09/08(木) 00:52:54.26 ID:8UoQH6yi.net

ヒープを使ってしまったら、>>452のような重箱の隅をつつくレアケースを除くと、最適化で消えないので不利
Rustのようにオブジェクトの生成すらスタック上で行なう方が有利

Rustはオブジェクトを値返しする点がそれを可能としている
オブジェクトをレジスタ群に格納して返せるときは最も速くなり、
その大きさを超えても、呼び出し元のスタック領域に確保された場所へ直接書き込んで渡すためこれも速い

461 ：デフォルトの名無しさん：2022/09/08(木) 01:00:14.34 ID:U6/gufpm.net

>>458
重箱の隅だけどinline指定しなくても関数のインライン化は行われるよ
同一翻訳単位の場合はもちろん、リンク時最適化でインライン化されることもある

462 ：デフォルトの名無しさん：2022/09/08(木) 01:01:41.29 ID:U6/gufpm.net

必ず○○とか必要以上に強い言葉を使うから重箱の隅をつつきたくなってしまうわけで、
ほとんどの場合○○とか適切な言葉遣いをしてくれれば良いのに

463 ：デフォルトの名無しさん：2022/09/08(木) 01:21:29.31 ID:bfKvyn62.net

>>461
inline化だけの話ならそうだね
でも今回はmalloc部分が消えるかどうかで単純なパターンだとinline化されて消えるときもある話じゃないかな
オブジェクト生成関数のmallocが常に消えたら大問題なのでそれは特殊なケースでしか起きないと思うよ

464 ：デフォルトの名無しさん：2022/09/08(木) 01:24:09.17 ID:4nByTxu8.net

Vecとかヒープ使ってないと思ってそう

465 ：デフォルトの名無しさん：2022/09/08(木) 01:25:35.66 ID:N4CSjuGd.net

値返しおじさん

466 ：デフォルトの名無しさん：2022/09/08(木) 01:50:13.51 ID:bfKvyn62.net

>>464
RustではVec(オブジェクト)生成new()でヒープは使わないよ
サイズ1以上になって遅延して初めてヒープ確保

SmallVecを使えば指定サイズ以上になって遅延して初めてヒープ確保
それまではスタック上のみを使う

ArrayVecはヒープを一切使わない
スタック上の指定サイズの中でのみで使う

だから「上限サイズがなく、かつ、想定サイズを超えた」時でなければヒープを使わずに済むようになっているよ

467 ：デフォルトの名無しさん：2022/09/08(木) 01:51:32.30 ID:M4A7wjs7.net

TS以外だと実際どれやればいいん？
理由添えて教えてほしい

468 ：デフォルトの名無しさん：2022/09/08(木) 02:21:09.08 ID:KnWQjklo.net

>>467
TypeScriptやっている人ならRustかな
まずウェブブラウザのフロントエンドで少し処理することが出てくるとWebAssemblyを使うがそこでの使用言語シェア1位はRust
次にブラウザではなくデスクトップ上などで作るときもJS/TSとRustを使った安全に高速なフレームワークTauriがある
もちろんサーバーサイドでもRustを使って安全に高速な構築ができてサーバーやクラウドコストも他言語より有利になる

469 ：デフォルトの名無しさん：2022/09/08(木) 02:43:12.05 ID:M4A7wjs7.net

>>468
めっちゃ丁寧な解説ありがとう
汎用系のCOBOL3年から未経験でWEB系に最近転職したんだ
自主学習でReactやったんでとりあえずフロントエンドで採用されたけど
今後サーバーサイドやその他の技術を習得
しようとしたとき何をやろうか？と悩んでたんだ

参考にしてみます。本当にありがとう。

470 ：デフォルトの名無しさん：2022/09/08(木) 06:11:54.46 ID:fF3EwaLJ.net

>>466-469
誘い球連投でほっこりした

471 ：デフォルトの名無しさん：2022/09/08(木) 07:07:05.36 ID:KnWQjklo.net

連投なんてしていないぞ

472 ：デフォルトの名無しさん：2022/09/08(木) 07:10:41.61 ID:BSPkqs+x.net

>>471
>>466も召喚してくれ

473 ：デフォルトの名無しさん：2022/09/08(木) 08:06:25.89 ID:VJlBI8uM.net

>>449
c++のvectorすら予約するからなぁ。
449はどれだけ時代遅れなんだろう。

474 ：デフォルトの名無しさん：2022/09/08(木) 08:22:43.32 ID:zqAFLdB2.net

こんなに優秀なRustなのになんでFirefoxは遅いし、著名なあまりソフトウェアが出てこないの？

475 ：デフォルトの名無しさん：2022/09/08(木) 08:26:35.79 ID:BdGA/lpu.net

>>449 >>456は行儀よく振る舞う練習
>>473は自演否定を一旦諦め 蒸し返しの誘い球
温存している自宅回線IDで後ほど再び自演否定
こんな流れで戦ってる

476 ：デフォルトの名無しさん：2022/09/08(木) 08:37:41.52 ID:WNih/Uq3.net

>>466
Rustはスタック上だけでVec操作できるよう充実してるね

477 ：デフォルトの名無しさん：2022/09/08(木) 08:51:41.58 ID:+LoUe6Y0.net

>>474
安全とハイリスクハイリターンの対立と分断があるから
優秀の反対は別の優秀だから

478 ：デフォルトの名無しさん：2022/09/08(木) 09:47:44.75 ID:RfxdukXg.net

俺仕事でPython NLPやってるチームに配属された どうだ怖いか
周りのDr持ちが段違過ぎてRustで戦いを挑むカードを推進してる
Rustで作らしてくれーと言ってるけど許可降りない
無意味な上司のせいでRustはパーソナルプロジェクトだ

そのプロジェクトとは CLI Tools だ
JetBrainsのDeveloper Ecosystem Surveyでは
2021に待望のCLI Toolsカテゴリーが新設された。
突然Systems Programmingが激減したのは誤差だ

479 ：デフォルトの名無しさん：2022/09/08(木) 09:51:36.54 ID:JEMfdspa.net

Project Crasher

480 ：デフォルトの名無しさん：2022/09/08(木) 09:56:34.95 ID:Txzh6OM/.net

2020に新設された仕事での利用率は、2020→2021の伸びは0だが、
キャンペーンが実を結ぶのは今年2022だ
何しろ2022はtauriがv1に到達し Desktop/GUI Applications がエンタープライズで飛躍的に伸びる
WebAssemblyの使用言語シェア1位とかいう話もある
メモ帳レベル機能でもawesome扱いしてくれるのは今だけだ 車輪に乗り遅れるな

481 ：デフォルトの名無しさん：2022/09/08(木) 10:52:23.96 ID:PN9YNiO2.net

どうしてID変えるんですか？やめてください迷惑です

482 ：デフォルトの名無しさん：2022/09/08(木) 10:56:40.75 ID:+LoUe6Y0.net

迷惑かけるまでがハイリスクです

483 ：デフォルトの名無しさん：2022/09/08(木) 11:06:23.80 ID:KnWQjklo.net

>>480
いずれ多くの分野でRustを使って当たり前の時代が来るだろうけど
まだしばらくは限定される気がするね

484 ：デフォルトの名無しさん：2022/09/08(木) 11:23:21.29 ID:JEMfdspa.net

あと10年くらいかな

485 ：デフォルトの名無しさん：2022/09/08(木) 12:25:34.25 ID:gDKj2SJw.net

>>480
曲芸師かよ ＞車輪に乗り遅れるな

486 ：デフォルトの名無しさん：2022/09/08(木) 12:50:52.48 ID:VIOSuMTh.net

>>480
今は、Rustで実装ってバリューあるけれど、もう何年もしたら、当たり前になって誰も気にしなくなるんだろうね。

487 ：デフォルトの名無しさん：2022/09/08(木) 13:45:08.90 ID:WNih/Uq3.net

スクリプト言語で十分な分野はそのままじゃないかな
それ以外の分野はRustを使うことが当たり前に

488 ：デフォルトの名無しさん：2022/09/08(木) 14:10:48.26 ID:+LoUe6Y0.net

言語仕様が優秀でも実装で失敗すれば終わり
標準ライブラリがーっていうのもどちらかといえば実装側の問題

489 ：デフォルトの名無しさん：2022/09/08(木) 14:53:25.83 ID:LIDvvnz0.net

ライブラリを選ぶコストや年単位で変更をウォッチしてアップデートの要否を判断して適用するコストって馬鹿にならんのよね
最近の言語なら言語そのものの生産性の差より言語の違いによるライブラリ周りの生産性の差の方が大きい

490 ：デフォルトの名無しさん：2022/09/08(木) 19:00:05.87 ID:aaaIAhtE.net

そう考えるとBoostのあるC++は素晴らしいよね。

491 ：デフォルトの名無しさん：2022/09/09(金) 19:27:35.69 ID:J0h2kR8b.net

https://www.jpcert.or.jp/sc-rules/00.introduction.html

CERT セキュアコーディングスタンダードは、C、C＋＋、Javaを対象としたセキュアなコーディング標準を公開した。
RustとBashは安全なのでCERT/CCの対象外とした。

492 ：デフォルトの名無しさん：2022/09/09(金) 19:40:15.23 ID:GpFRRbzJ.net

>>491
マイナー言語はふつうにスルーされてるだけ

493 ：デフォルトの名無しさん：2022/09/09(金) 19:48:53.77 ID:NJZb/x50.net

>>491
歴史を考えろよ
これはgoやrust登場前に作られた規約だぞ

494 ：デフォルトの名無しさん：2022/09/09(金) 20:16:31.91 ID:J0h2kR8b.net

あ”あ”〜〜ワクワクが止まらねえ〜〜。

495 ：デフォルトの名無しさん：2022/09/09(金) 22:47:37.83 ID:B0h43lqZ.net

>>491
CもC++も対象バージョンが古すぎ。

496 ：デフォルトの名無しさん：2022/09/10(土) 07:21:33.57 ID:uXnvxxOp.net

本日のRustおつ夜会場はこちらですか？

>Rustで作らしてくれーと言ってるけど許可降りない
https://www.jetbrains.com/lp/devecosystem-2021/rust/

497 ：デフォルトの名無しさん：2022/09/10(土) 09:06:15.64 ID:ZPKzDOJp.net

>>352
途中までJuliaのコピペ乙

498 ：デフォルトの名無しさん：2022/09/10(土) 16:00:01.13 ID:0VnbKdes.net

>>491
そんな古いのどこから見つけてきたんだ？

499 ：デフォルトの名無しさん：2022/09/10(土) 18:40:23.49 ID:830ybrIN.net

CERT知らんのか。

500 ：デフォルトの名無しさん：2022/09/10(土) 19:10:24.81 ID:OQaV5j6q.net

>>498
さすがに恥ずかしいぞ

501 ：デフォルトの名無しさん：2022/09/10(土) 20:44:33.04 ID:BhJh8aSd.net

C固有の話やメモリ安全性に関わるものはともかく、
シグナル安全性とかモダンな言語でも気にしないといけない部分はそれなりにあると思うので、
モダンな言語向けにまとめ直したものがあると嬉しいとは思う

502 ：デフォルトの名無しさん：2022/09/10(土) 20:56:11.13 ID:R3UqRaV2.net

pythonみたくマルチスレッド禁止にすりゃええねん

503 ：デフォルトの名無しさん：2022/09/10(土) 21:28:21.07 ID:q8enYz1J.net

goとnimに興味あります
rustはある程度触ってみたけどもういいや

504 ：デフォルトの名無しさん：2022/09/10(土) 21:31:16.53 ID:PkiDAnmE.net

小鳥んはいつまで次世代なんだよ
まだJavaから覇権を奪えないのか

505 ：デフォルトの名無しさん：2022/09/10(土) 23:11:12.68 ID:pCQRIeiF.net

Nimは本質的なメリットが何もないから
今後も企業が採用することがないと思うよ

506 ：デフォルトの名無しさん：2022/09/10(土) 23:23:36.54 ID:a77H3leG.net

Rustは本質的なメリットが何もないから
今後も企業が採用することがないと思うよ

507 ：デフォルトの名無しさん：2022/09/10(土) 23:50:11.76 ID:I8LDMMGc.net

>>502
Pythonはマルチスレッド禁止ではなく
グローバルインタプリタロックをしてるから真の並列処理ができないだけ
I/Oブロッキングされてる間に他が動けるなど完全に無意味というわけではない
これはRubyも同じで所詮はスクリプト言語だからしょうがない

508 ：デフォルトの名無しさん：2022/09/10(土) 23:59:58.32 ID:WfJh9xF9.net

Rustは企業による採用が多い
例えば>>9の記事、>>43の記事、154の記事など
各企業がRustのメリットを様々な観点から語っている

509 ：デフォルトの名無しさん：2022/09/11(日) 00:34:56.10 ID:Iy8wr1LO.net

>>508のような重箱の隅をつつくレアケースを除くと、Rustの現実>>496

510 ：デフォルトの名無しさん：2022/09/11(日) 00:47:20.06 ID:XM7RcVpf.net

理解のある有能な上司・経営者がいる企業はRustを適切に導入しつつあり
ダメな企業はそれらの記事にもある多大なメリットを理解できないまま差が広がるのだろう

511 ：デフォルトの名無しさん：2022/09/11(日) 01:10:08.71 ID:fTsZYMd7.net

配属して間もなくの歓迎会で>>510の話をしたら周りが凍りついた

統計的Rustの現実
https://www.jetbrains.com/lp/devecosystem-2021/rust/

512 ：デフォルトの名無しさん：2022/09/11(日) 01:26:31.38 ID:VONtFQ6w.net

>>510
統計とか言ってる時点でズレてるからな
俺はもう1番安全な言語しか使いたくないよ

513 ：デフォルトの名無しさん：2022/09/11(日) 01:28:14.37 ID:b0yVF+AE.net

>>512
じゃあRustは危険だからだめだな

514 ：デフォルトの名無しさん：2022/09/11(日) 01:31:47.64 ID:VONtFQ6w.net

>>513
ストローマン

515 ：デフォルトの名無しさん：2022/09/11(日) 02:13:14.46 ID:QQU6OFWg.net

>>509
トヨタやNTTも採用しているし
それらGAFAMによる採用も含めて
レアケースというよりも適切な判断ができる企業がRustを採用していってる感じ

516 ：デフォルトの名無しさん：2022/09/11(日) 02:47:04.45 ID:St3yVzYk.net

企業体力がある企業が採用していってる感じ！
って感じ？

517 ：デフォルトの名無しさん：2022/09/11(日) 03:35:13.96 ID:7JragUBO.net

昔から同じ傾向だけど
余裕のない会社(人)や無学習な会社(人)はそのまま古い言語、遅い言語、安全でない言語を使い続けるね
これは言語に限らずあらゆる対象について同じ

518 ：デフォルトの名無しさん：2022/09/11(日) 06:11:01.67 ID:B/NO1QVJ.net

本日の もはやRustはどうでも良くて
Rustで誘い球 ヒント乞い儀式の会場はこちらですか？

異次元超大手GAFAM御用達 老舗第三者機関jetbrainsによる
大規模統計調査結果 #Rustの不都合な真実 #責任転嫁論法

尾ひれはひれ抜きで

一言でまとめ

>Rustで作らしてくれーと言ってるけど許可降りない

詳しくは JetBrains ソースで👆

519 ：デフォルトの名無しさん：2022/09/11(日) 07:38:24.36 ID:+BbjejVS.net

調査結果を誤読している人がいるようだけど
昔から良いプログラミング言語が出てきたらまずは趣味や個人的な用途から使われ始めるのでこの第一条件をクリアしていることを意味している
仕事で強いられるのとは異なり自ら選べるところで進んで使われることはプログラマーにとっても良い言語であることを意味する

一方で多くの会社や客先などで使われる言語は良い悪いと関係なく惰性的にもしくは周りに流されて決まることも多い
よってその大衆的な調査よりも第二条件としては趣味範囲に留まらず実用的なプログラミング言語かどうかが重要となる
その点では>>9や>>154の記事などで世界的な大手IT企業たちがRustの実用性を証明してくれている

520 ：デフォルトの名無しさん：2022/09/11(日) 07:44:27.84 ID:uuKi7qIG.net

RustスレやGoスレ、Pythonスレはレベルが低くて使えない
やっぱC/C++を煽らないと重箱の隅をつつく レアヒント情報は出てこない

4回線で戦ってるから、両側のサクラを演じてるが、本物がなかなか釣れない

521 ：デフォルトの名無しさん：2022/09/11(日) 08:16:22.32 ID:Iv+s/rR9.net

Rustが実用的に使えるようになったからC/C++は既存メンテを除いて不要じゃないか？
しばらくの時間が経った以後は重箱の隅をつつくレアケースでしかC/C++は使われなくなると思う

522 ：デフォルトの名無しさん：2022/09/11(日) 08:26:29.84 ID:dBVHZlNB.net

>>521
その条件だけじゃ不十分だよ
それに、Rustに慣れた技術者が不足なく増えること、の条件が加わればもうC/C++は使われなくなる

523 ：デフォルトの名無しさん：2022/09/11(日) 08:44:00.50 ID:iHJIv4qn.net

そもそも今その言語が使われてるのって8割方保守だろ

524 ：デフォルトの名無しさん：2022/09/11(日) 08:56:08.15 ID:SEdmppON.net

あるいは毎年、既存システム比、2割も新規があると考えるのは現実的ではない。

525 ：デフォルトの名無しさん：[ここ壊れてます] .net

RustがC/C++分野に食い込めても2割いくことはないということか

526 ：デフォルトの名無しさん：[ここ壊れてます] .net

あるいは新規があればRustであると考えるのは現実的ではない。すべて架空の話。英語で言えば仮定法過去

527 ：デフォルトの名無しさん：2022/09/11(日) 09:44:14.66 ID:+PEbrMUs.net

C++は酷い言語だったが科学的な誤りはなかった
商業的に不要とか言われてもそれは倫理的に悪と言われる程度の説得力しかない

528 ：デフォルトの名無しさん：2022/09/11(日) 09:50:44.97 ID:WKW/SVys.net

あるいはRustでは保証するとか証明可能とか言う話は全て架空だ
数学的証明された事実は一つもない

529 ：デフォルトの名無しさん：2022/09/11(日) 09:59:03.59 ID:+PEbrMUs.net

まあ数学自体が架空だと思ってる奴もいるんだよな
複素数には不等号も最大も最小もないという事実は架空で
最大と最小しかない1bitも架空で
実数が現実だと思ってるようだ

530 ：デフォルトの名無しさん：2022/09/11(日) 10:01:44.26 ID:vhHBIWRc.net

>Rustは数学自体が架空だと思ってる™

531 ：デフォルトの名無しさん：2022/09/11(日) 10:06:19.83 ID:sTwbodpe.net

>Rustは数学自体が架空だと思ってる™
>Rustスレはレベルが低くて使えない
完全一致

532 ：デフォルトの名無しさん：2022/09/11(日) 10:12:56.55 ID:qCGvqebh.net

>Rustは数学自体が架空だと思ってる™ ←New
>Rustスレはレベルが低くて使えない
>Rustで作らしてくれーと言ってるけど許可降りない™
完全一致

533 ：デフォルトの名無しさん：2022/09/11(日) 11:42:55.72 ID:1/0HqANi.net

Scalaが実用的に使えるようになったからJavaは既存メンテを除いて不要じゃないか？

534 ：デフォルトの名無しさん：2022/09/11(日) 12:14:21.26 ID:P3VqydEe.net

GAFAMが揃って採用したら実用的＆安泰
1社のみだと細々と消える可能性あり

535 ：デフォルトの名無しさん：2022/09/11(日) 13:06:46.07 ID:e58aNhcI.net

アリババに採用されないと無理だろ。

536 ：デフォルトの名無しさん：2022/09/11(日) 13:25:09.93 ID:F0iOH4S5.net

>>529
実数が架空の可能性も出てきたけどな。

537 ：デフォルトの名無しさん：2022/09/11(日) 13:26:02.18 ID:HFx3mOt8.net

日本の場合、Rust実務3級みたいな怪しい資格が出てきたら、人の確保に困らないレベルだと考えられるのでは。

538 ：デフォルトの名無しさん：2022/09/11(日) 13:33:45.44 ID:e58aNhcI.net

実数が存在する可能性もゼロではない。

539 ：デフォルトの名無しさん：2022/09/11(日) 13:41:11.64 ID:fLFeKmlL.net

ゼロって実在したっけ？

540 ：デフォルトの名無しさん：2022/09/11(日) 13:42:33.06 ID:VMVpvyTB.net

>>535
アリババのレポジトリ見たらRustで書いてるプロジェクトが既にあるのな
あとアリババクラウド公式ブログでもRust推奨
Why Should You Learn Rust?
https://www.alibabacloud.com/blog/why-should-you-learn-rust_598680

541 ：デフォルトの名無しさん：2022/09/11(日) 15:00:31.37 ID:e58aNhcI.net

アリババのメイン言語になってるならワンチャンあるかもしれないなあ。

でも、日本で使われてるならダメそうじゃないか？
日本人が良いというものは、だいたいダメだったぞ。
この30年間。

542 ：デフォルトの名無しさん：2022/09/11(日) 15:06:26.74 ID:e58aNhcI.net

ある意味、日本を釣るためにGAFAが手を組んだのかもしれないしな。

543 ：デフォルトの名無しさん：2022/09/11(日) 15:16:40.87 ID:VMVpvyTB.net

>>542
GAFAだけならともかく
HuaweiもAlibabaもRust使ってる

544 ：デフォルトの名無しさん：2022/09/11(日) 15:24:35.80 ID:e58aNhcI.net

>>543
中国とアメリカが手を組んだってことかな？

ますます嵌められる予感しかしない。

545 ：デフォルトの名無しさん：2022/09/11(日) 15:44:25.20 ID:9L9UahOO.net

すべてのゼロに単位はない、オールハイルゼロ！

546 ：デフォルトの名無しさん：2022/09/11(日) 16:37:16.95 ID:vfKVIBQc.net

GAFAというが
アップルはRustに言及してないだろ
社内でどうしてるかは知らんが

547 ：デフォルトの名無しさん：2022/09/11(日) 16:42:02.78 ID:F99gXeAJ.net

そういや GAFA の F は Facebook の F だったので Meta に変わった今は GAMA になる筈だよね。

548 ：デフォルトの名無しさん：2022/09/11(日) 16:43:11.94 ID:XyeJ2q+G.net

>>546
Appleは2~3年前からクラウドサービスのバックエンドで使ってるって話だよ
公式発表とかしてるかは知らんけど中の人がしゃべってたし採用サイト見ればわかる

549 ：デフォルトの名無しさん：2022/09/11(日) 16:47:35.25 ID:PJg7Eu+i.net

ID:e58aNhcIは陰謀論とかにころっと騙されそう
日航機墜落はアメリカの陰謀だとか信じてそう

550 ：デフォルトの名無しさん：2022/09/11(日) 16:48:54.21 ID:y06ekIr1.net

>>541
CもJavaもPHPも日本じゃ昔から至るところで使われていたし、過去資産を一気に捨てるのでなけれこれからも世界中で使われるだろうけど？

551 ：デフォルトの名無しさん：2022/09/11(日) 16:50:26.98 ID:e58aNhcI.net

逆に、自民党は某宗教団体と無関係とか思ってる人のほうがオカシイのでは？
宗教と組んでるから安泰と党大会でも言ってるのに。

552 ：デフォルトの名無しさん：2022/09/11(日) 17:02:25.87 ID:p+Qu5PiK.net

陰謀論はたまに真実が混ざってるから厄介
9.11はサウジが糸を引いてたみたいなやつとかね

553 ：デフォルトの名無しさん：2022/09/11(日) 17:06:29.54 ID:vF4tz2Bt.net

>>547
GoogleはAlphabetになってるからAAMAかAAMAM

わざと没個性的にした企業名に追随する必要は全くないと思うが

554 ：デフォルトの名無しさん：2022/09/11(日) 17:11:27.93 ID:e58aNhcI.net

>>552
それ、最近話題の某宗教団体が主張してるけど。

陰謀論じゃなく真実。

陰謀論と言えばごまかせるという風潮がオカシイのでは？

555 ：デフォルトの名無しさん：2022/09/11(日) 17:13:50.83 ID:wKzSFZtE.net

☆js
var a = []
for (var i = 0; i < 3; i++) {
a.push(() => console.log(i))
}
a.forEach(f => f()) // 3 3 3

☆js let j = i
var a = []
for (var i = 0; i < 3; i++) {
let j = i
a.push(() => console.log(j))
}
a.forEach(f => f()) // 0 1 2

556 ：デフォルトの名無しさん：2022/09/11(日) 17:14:49.46 ID:wKzSFZtE.net

☆go
package main
import "fmt"
func main(){
var a []func()
for i := 0; i < 3; i++ {
a = append(a, func() {fmt.Println(i)})
}
for _, f := range a {f()} // 3 3 3
}

☆go i := i
package main
import "fmt"
func main(){
var a []func()
for i := 0; i < 3; i++ {
i := i
a = append(a, func() {fmt.Println(i)})
}
for _, f := range a {f()} // 0 1 2
}

☆dart
void main() {
var a = [];
for (var i = 0; i < 3; i++) {
a.add(() => print(i));
}
a.forEach((f) => f()); // 0 1 2
}

557 ：デフォルトの名無しさん：2022/09/11(日) 17:18:39.40 ID:wKzSFZtE.net

https://go.dev/doc/faq#closures_and_goroutines
> Even easier is just to create a new variable,
> using a declaration style that may seem odd but works fine in Go:

558 ：デフォルトの名無しさん：2022/09/11(日) 18:43:29.45 ID:wKzSFZtE.net

☆js let
var a = []
for (let i = 0; i < 3; i++) {
a.push(() => console.log(i))
}
a.forEach(f => f()) // 0 1 2

559 ：デフォルトの名無しさん：2022/09/11(日) 21:41:46.79 ID:+PEbrMUs.net

登場人物等が実在しないと意味がないのが陰謀論
実在してもしなくても仮定するだけでいい感じになるのは防災とか護身術とかかな

560 ：デフォルトの名無しさん：2022/09/11(日) 21:56:48.27 ID:3JeGkSLy.net

☆rust
fn main() {
let mut a = vec![];
for i in 0..3 {
a.push(|| println!("{i}"));
}
a.iter().for_each(|f| f());
}
error[E0597]: `i` does not live long enough

☆rust
fn main() {
let mut a = vec![];
for i in 0..3 {
a.push(move || println!("{i}"));
}
a.iter().for_each(|f| f()); // 0 1 2
}

561 ：デフォルトの名無しさん：2022/09/11(日) 22:01:38.23 ID:PJg7Eu+i.net

いい感じになってないからただの陰謀論だわな

562 ：デフォルトの名無しさん：2022/09/11(日) 22:32:59.60 ID:wKzSFZtE.net

☆ruby
a = []
for i in 0..2 do
a << lambda {print i}
end
a.each(&:call) # 222

☆ruby
(0..2).inject([]) {|a, i| a << lambda {print i}}.each(&:call) # 012

563 ：デフォルトの名無しさん：2022/09/11(日) 23:47:28.92 ID:VMVpvyTB.net

>>560
ライフタイムを管理してるRustだけが
問題を回避してコンパイルエラーにすることができているね

564 ：デフォルトの名無しさん：2022/09/12(月) 12:00:10.83 ID:hkEaTFQf.net

それで最強？言語Rustで崇高なパーフェクト言語？Rustでいま何作ってるんですか？
ぜんぜんRust製の良いソフトウエアが出てこないですね
まさかウンコ臭い業務コードや、趣味のじこまんオナニーコード書いてるんですか？あ、ごめん業務ですら案件ほとんどないか！ｗ

565 ：デフォルトの名無しさん：2022/09/12(月) 12:19:44.25 ID:5bihwCS7.net

ごめんrustって駄目なの？
goとかのがいいんか？

566 ：デフォルトの名無しさん：2022/09/12(月) 12:20:19.70 ID:pKAQjQJa.net

>>564
オモチャと馬鹿にするのは筋が良くないよ。
適用領域や生産性が十分であればオモチャがエンタープライズ(笑)を置き換える例は枚挙にいとまがない。

下げたいなら欠点や解決できていない課題を指摘するのがよいよ。

567 ：デフォルトの名無しさん：2022/09/12(月) 12:25:48.21 ID:ks2jCYJ6.net

>>565
いい言語だよ
ただちょーっとキチガイが贔屓の引き倒ししてるだけ

568 ：デフォルトの名無しさん：2022/09/12(月) 12:30:55.10 ID:8xQYKjTB.net

>>565
他人に書かせたコードを管理する立場なら現状ベター。
自分でコーティングするなら微妙。

ガチガチに固めたコーティング規約のついてくるc++くらいに考えればいいかと。

569 ：デフォルトの名無しさん：2022/09/12(月) 12:50:12.25 ID:tyJETXG8.net

>>565
Rustはプログラミングがめっちゃ快適なのでプログラマーたちに愛されている

「Stack Overflow」で7万人以上のITエンジニアの調査結果、最も愛されている言語は7年連続で「Rust」
https://survey.stackoverflow.co/2022/#most-loved-dreaded-and-wanted-language-love-dread

570 ：デフォルトの名無しさん：2022/09/12(月) 13:15:12.14 ID:1QsSN3wZ.net

>>568
つまりGoはOSS、エンタープライズ
Rustは言語オタク

に向いてるってこと？

571 ：デフォルトの名無しさん：2022/09/12(月) 13:42:12.36 ID:vGI5q7L7.net

料理下手な奴って
調味料とかの用法用量をガチガチに守らない方が美味しくなる
って思い込みが強いんだよな

572 ：デフォルトの名無しさん：2022/09/12(月) 13:53:17.15 ID:QNBEnsOG.net

カレーの箱には材料全て炒めて煮込めって書いてあるけど実際には炒めるのは玉ねぎだけでいいし煮込むのはジャガイモだけでいいんだよね
あとはレンジで下処理できる
全部同じ処理方法だと玉ねぎは香りが飛ぶしジャガイモのデンプンが十分スープに出なかったりする
火を止めてから仕上げにインスタントコーヒーを少し加えると味音痴でもはっきりわかるくらいコクが変わるがそれは書いてない
なぜなら商業的にはコーヒーはルーに最初から入っているべきもので必要なスパイスや味付け等を一つのパッケージで提供することがルーの役割だから
ところがコーヒーは最後に入れるもので最初から入れるとただ苦味を加えただけになる
従ってレシピには載ってない

俺って料理音痴だなあ

573 ：デフォルトの名無しさん：2022/09/12(月) 14:23:43.00 ID:vGI5q7L7.net

自分で作る時の規約と同じ規約を他人にすすめるのは正しい

574 ：デフォルトの名無しさん：2022/09/12(月) 14:26:53.27 ID:o/NFQNbK.net

>>570
OSSこそ他人のpull req受け入れたりするから規約は堅い方が良いのでは

書いてもらったコードを書き直すようお願いしたり、自分で書き直したりするのは二度手間だよね

575 ：デフォルトの名無しさん：2022/09/12(月) 14:53:09.61 ID:nQ3vrjGe.net

JetBrainsの方はテックメディアやblog等がこぞって取り上げてる印象がないけど日本だけ？
あと2~3週間で今年の結果が出る頃だけど、RustとGoをヘッドラインに入れ込んでViewが稼げそう
どっちがどう転んでもw

576 ：デフォルトの名無しさん：2022/09/12(月) 15:23:46.11 ID:/ImN/Q+4.net

どっち転んでるって分かってるくせに...

Goスレから出張ですか？ このスレは>>518となりました

577 ：デフォルトの名無しさん：2022/09/12(月) 15:35:48.60 ID:1EVPKhq8.net

>>565
scalaって知ってる？

578 ：デフォルトの名無しさん：2022/09/12(月) 15:45:21.43 ID:U3gTQ3k2.net

>>577
この話をしたいのか？
>GAFAMが揃って採用したら実用的＆安泰
>1社のみだと細々と消える可能性あり

飽きたわ
Scalaは細々でも生き残る実稼働分野を見出した

579 ：デフォルトの名無しさん：2022/09/12(月) 15:52:19.48 ID:D724xnZb.net

>>565
Rustは史上最強のプログラミング言語だ
コンピュータサイエンスとプログラミング言語理論の成果を全て取り入れた唯一の言語だろう
安全性とパフォーマンスを両立させた唯一の言語
まずRustを使うべき
しかしスクリプト言語使いの人などはハードルが高いのでGoやNimなんかを経由するのはあり
最終的にRustへ至る道への修行と考えれば全然あり

580 ：デフォルトの名無しさん：2022/09/12(月) 15:55:18.32 ID:xojxIqPL.net

キチガイがRustのアホな持ち上げ方するネガティブキャンペーンやめてくんないかな
いい加減流行ってくんないと不便なんだよいつまでも

581 ：デフォルトの名無しさん：2022/09/12(月) 15:56:53.20 ID:+dWR9IC9.net

Go　　実稼働分野でバリバリ活躍中
Scala 実稼働分野でバリバリ活躍中
Rust　試食コーナーで食べてもらって狂喜乱舞

582 ：デフォルトの名無しさん：2022/09/12(月) 15:58:05.79 ID:D724xnZb.net

バリバリ使ってるレベルの高い人が周りにいないから知らないんだね
かわいそう

583 ：デフォルトの名無しさん：2022/09/12(月) 16:00:17.03 ID:xojxIqPL.net

>>582
Rustは足りない物だらけでバリバリ使えるレベルにないんですわ
ユーザー増える邪魔すんなよ

584 ：デフォルトの名無しさん：2022/09/12(月) 16:04:01.87 ID:mWclCycs.net

今すでにC/C++を使ってるようなプロジェクトでなければ、基本的にはRustなんて出番ないよ
Java、JavaScript、Python、Swift、Kotlinみたい言語が使われてる分野でRustが使われることはない。あっても非常にマレ
wasmでRustの需要があると騒ぐひともいるけどまだ新しすぎてなんともいえない

585 ：デフォルトの名無しさん：2022/09/12(月) 16:06:50.08 ID:D724xnZb.net

「自分のレベルが低い」ことを認識できないとレベルアップなんてできないぞ
Rust書ける？って言って勉強すれば書けます！とか言ってるやつが数ヶ月後も書けなくて
どういう反応するのか見たら「学習コストが高い」とかいうよくわからない言い訳をしたことがあった
Rustチームに入ってもらおうと思ったけどやめた

586 ：デフォルトの名無しさん：2022/09/12(月) 16:10:13.94 ID:D724xnZb.net

俺の経験上C/C++を書けないとRustは書けないと思う
だから急がば回れでC++の勉強をするのも良いと思う
Rustが持ってる機能の元ネタがそこらにあるから
やる価値はあると思う
なぜ継承がクソなのかコピーが悪なのか全て理解できると思う
この感覚を理解してないとRustの機能のありがたさはわからない

587 ：デフォルトの名無しさん：2022/09/12(月) 16:14:15.82 ID:D724xnZb.net

結論を言うとRustから逃げてるエンジニアは二流　ここで逃げるとあらゆることから逃げるだろう

588 ：デフォルトの名無しさん：2022/09/12(月) 16:16:36.57 ID:tOT7j8yQ.net

完成した

Go　　実稼働分野でバリバリ活躍中
Scala 実稼働分野でバリバリ活躍中
Rust　試食コーナーで食べてもらって狂喜乱舞
　　　俺 >Rustで作らしてくれーと言ってるけど許可降りない
　　　有能社員 >Rustは学習コストが高い割に使えない
　　　有能社員 >C/C++を書けないとRustは書けない、Rustは意味なし
Nim 試食コーナーでスルーされて意気消沈
Pony 開店前

589 ：デフォルトの名無しさん：2022/09/12(月) 16:19:39.20 ID:ogCOvAZv.net

>>585
それが現実。

Rustを「とりあえず」使えるレベルになるだけでも深くプログラムに精通している必要があり、JavaとかPython開発で使えるレベルの人材では全く歯が立たない。
Rustコミニティは初心者にマウントする人間ばかりで教育手法は全然整備されていない。

こんなのでユーザーが増えるわけが無い。順当にHaskellと同じ道を歩んでいるわな。

590 ：デフォルトの名無しさん：2022/09/12(月) 16:21:55.50 ID:mWclCycs.net

当然だけど万能な言語なんてないから、ユースケースに選んで使えばいいだけ
プログラミング言語なんて5個や10個使えて当然

591 ：デフォルトの名無しさん：2022/09/12(月) 16:27:17.65 ID:a0Vw3QfF.net

>>585 >>589
うむうむ。KentaのScalar動画で見た。
viewが30くらい伸びた しみじみくる

592 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>585
だからお前はレベルアップできないんだな
Rust使えるようになってからそういうことは言え

593 ：デフォルトの名無しさん：2022/09/12(月) 16:44:01.30 ID:D724xnZb.net

>>590
それは一昔前
今はRustだけで良い

594 ：デフォルトの名無しさん：2022/09/12(月) 16:45:35.34 ID:D724xnZb.net

とはいえRustが普及しないのは俺も困る
レベルが低いものが結託してRust を潰そうとする動きは感じてる
なので何とか使えるように指導したいとは思ってる

595 ：デフォルトの名無しさん：2022/09/12(月) 16:47:00.99 ID:p/0uZlw7.net

>>584
それはちよっと無知すぎるんじゃないかね
そのJavaなどの言語が現実にRustへの移行対象となって進んでいる
単純にRustならば自動メモリ解放で高速化できるだけでなく
>>43の記事に具体的にあるように非同期な並行＆並列プログラミングなどでの優位性も大きい
どんなに複雑化してもデータ競合がないことをRustコンパイラが保証する点は現在最も求められていることの最重要の一つ

596 ：デフォルトの名無しさん：2022/09/12(月) 16:54:20.00 ID:Sl+PHmf/.net

入れ食い状態

Go　　実稼働分野でバリバリ活躍中
Scala 実稼働分野でバリバリ活躍中
　　　KENTA >日本では衰退しました ←New
Rust　試食コーナーで食べてもらって狂喜乱舞
　　　俺 >Rustで作らしてくれーと言ってるけど許可降りない
　　　レベルアップできない俺 >今はRustだけで良い。レベルアップはお断りだ ←New
　　　レベルアップできない俺 >試食コーナーで食べてもらって狂喜乱舞 ←New
　　　レベルアップできない俺 >数学出来ないけど有能社員を指導したいとは思ってる ←New
　　　有能社員 >Rustは学習コストが高い割に使えない
　　　有能社員 >C/C++を書けないとRustは書けない、Rustは意味なし
　　　有能社員 >Rustは言語オタク Haskellと同じ道 ←New
Nim 試食コーナーでスルーされて意気消沈
Pony 開店前
Haskell 衰退しました ←New

597 ：デフォルトの名無しさん：2022/09/12(月) 17:02:30.41 ID:mWclCycs.net

>>595
それも知ってるから、非常にマレと書いた

598 ：デフォルトの名無しさん：2022/09/12(月) 17:02:59.62 ID:D724xnZb.net

「できない人の気持ち」をずっと考えてたんだけど
スタックとかヒープとか所有権とかライフサイクルとか
そういう説明の仕方が悪いんじゃないかと
概念的な説明って意外と理解されないんだなと言うのが実感としてある
もう割り切って「この場合はこう書け」という説明の方が良いのではないかと思い始めた

599 ：デフォルトの名無しさん：2022/09/12(月) 17:06:35.50 ID:fbgm2yKh.net

入れ食い状態
ちょっと手加減してください

Rust　
　　　レベルアップできない俺 >スタックとかヒープとか、概念的 ←New

600 ：デフォルトの名無しさん：2022/09/12(月) 17:09:10.23 ID:UHoWNRxl.net

言語だけで低レベルな連中を排除できるから便利よ
前の会社でOCaml,Haskell,Scalaできる奴限定チーム作ったら
お守りの要る奴が居なくなって超快適だったw
まあ社内のできる奴が皆来たから他チームからの技術問い合わせ集中→丸投げが始まったからウンザリして転職したけどw
Rustも活かして行こw

601 ：デフォルトの名無しさん：2022/09/12(月) 17:10:31.29 ID:MdKMUdvB.net

>>598
あー
それわかる
C++とかも最初は割り切りパターンが大事だからね
例えばコンテナの要素にはunique_ptrを必ず使えとかかなり有用なパターンだと思うし

602 ：デフォルトの名無しさん：2022/09/12(月) 17:15:38.21 ID:D724xnZb.net

>>601
このような意見は有り難い
ちょっとその方針で社内ドキュメント書き直してみる
もしかしたらRust使い育成の成功体験が得られるかもしれん

603 ：デフォルトの名無しさん：2022/09/12(月) 17:16:14.15 ID:pGdD9pkE.net

まるで就職してるみたいなことを言うじゃないか

604 ：デフォルトの名無しさん：2022/09/12(月) 17:17:24.65 ID:6spEgeO/.net

問題：ヒント乞い儀式は何処から始まって、何処まで続く？
　　　今、何人目？

605 ：デフォルトの名無しさん：2022/09/12(月) 17:22:27.34 ID:1EVPKhq8.net

こうしてRustはささやかに終わり、時代は変わっていくんですなぁ

606 ：デフォルトの名無しさん：2022/09/12(月) 17:28:16.89 ID:mWclCycs.net

Rustでやってる案件いくつか見たことあるけどどれも最初の開発者がめちゃくちゃ優秀だから、
変なことになってないし後から参加する人も自然とベストプラクティスを学びやすい感じになってる
まあどれもドメインを絞ってて規模が小さいから社内ドキュメントなんてあんまないけど…

>>602
社内ドキュメントで入門記事とか書こうとしてるの…？？

607 ：デフォルトの名無しさん：2022/09/12(月) 17:30:40.29 ID:GOcHN1Zf.net

C/C++/低レイヤーの間違い指摘・揚げ足取りは思う壺です。
プロレスに終始してください。

608 ：デフォルトの名無しさん：2022/09/12(月) 17:36:03.29 ID:vGI5q7L7.net

static変数でいいと思った人の気持ちをOO棒でぶん殴ってた時代に戻ってやり直せばいいのでは

609 ：デフォルトの名無しさん：2022/09/12(月) 17:44:05.96 ID:AXUzp/Io.net

感想

Rustが高速で省メモリで安全という新分野を切り開いたのは確かなようで
クラウドコスト・使用電力量・Co2排出量でも有利なのは間違いなさそうだから
今後のシナリオは以下の2パターンかな～？

パターン1
慣れれば大半のプログラマーがRustを使いこなせるようになりRustはコモディティ化して人類の役に立つ

パターン2
Rustを使いこなせる層と使えない層に二極化する
企業などもRustを使いこなせる人材を集められる層と無理な層に二極化する
そのためサーバー＆クラウドコスト支出・使用電力量・Co2排出量などあらゆる点で二極化してしまう
Rustを使えない側は様々な点で不利を背負ってしまう

610 ：デフォルトの名無しさん：2022/09/12(月) 18:36:26.99 ID:w++AQN2S.net

>>KENTA
Rustについてもいろんな過去動画で語ってるんだけど今一古い
古い動画では低レイヤー向けだから関係ないみたく言ってるけど最新版2022年下半期の意見が欲しい
KENTA周りでwasmってまだ見えてないんじゃないの？
過去の試食ニュースくらい？とか(tauriはKENTAに関係ないか)

だれか本人に伝えてきて下さいm(__)m

611 ：デフォルトの名無しさん：2022/09/12(月) 18:42:10.96 ID:1EVPKhq8.net

Rust使うとIDを簡単に変えることができる裏技みたいなのがあるの？

612 ：デフォルトの名無しさん：2022/09/12(月) 18:58:12.12 ID:cIAUh/V3.net

あえてKENTA周り煽るような否定形で聞いてるあたり
最新版では提灯コメントが出てくると思ってるんだろ

KENTAはScalaコミュニティ分析してるしガリ勉オジ嫌いって言ってたから
内心は言語オタクRust(コミュニティ)を良く思ってない

でも表面上では良い顔してくれると思うよ

613 ：デフォルトの名無しさん：2022/09/12(月) 18:59:15.13 ID:1QsSN3wZ.net

低レイヤー向きなのはガチ
Webやバッグエンドで扱うのはなかなかピーキーすぎるわ

614 ：デフォルトの名無しさん：2022/09/12(月) 19:06:29.84 ID:ctaSs0ih.net

低レイヤー向きなのはガチ(ただし既存システムは置き換えない)
Webやバッグエンド(その他もろもろ)はピーキー

こんなんじゃ提灯コメント出てこない

615 ：デフォルトの名無しさん：2022/09/12(月) 19:07:05.31 ID:hOTkFqgR.net

RustはHaskellと同じことを言ってる。

616 ：デフォルトの名無しさん：2022/09/12(月) 19:08:23.81 ID:M7cyS1TF.net

>>613
現実を見よう
バックエンド・クラウドサイドがRustで最も盛ん
フロントエンドもWasm記述言語トップがRust

617 ：デフォルトの名無しさん：2022/09/12(月) 19:11:01.61 ID:H3lrVzsc.net

Haskellが衰退したという結果は判るけど、何を言ってたかとか経緯はよく知らない

618 ：デフォルトの名無しさん：2022/09/12(月) 19:14:40.26 ID:k0iYs0el.net

こんな中、Clojureの勉強始めたわ。

Common Lispは、なかなか良い実装見つけられなくて挫折したけれど、ClojureはJVMの資産が使えるし、少し期待してる。

619 ：デフォルトの名無しさん：2022/09/12(月) 19:14:42.35 ID:iaJVMLEF.net

>フロントエンドもWasm記述言語トップ
どこぞのビルボード部門別1位みたいな言い方だな

620 ：デフォルトの名無しさん：2022/09/12(月) 19:19:34.74 ID:FpwHUZnr.net

>>618
Clojureも愛され言語ランキング上位だったな ガンガレ

621 ：デフォルトの名無しさん：2022/09/12(月) 19:21:10.92 ID:D0TZxDhn.net

WebAssemblyをGC言語で書くと実行速度もバイナリサイズも無駄すぎるため
現実的な記述言語がRustとC++しかないので当たり前
ただしこの対等勝負でC++にRustが勝っている点は注目に値するかもしれない

622 ：デフォルトの名無しさん：2022/09/12(月) 19:26:50.51 ID:R6La1yEF.net

>>621
所詮どこぞのビルボード部門別1位だからな

KENTA周りでwasmが見えてるのかどうか
重箱の隅をつつくレアケース、まだ試食タイムかとか
話はそれから

623 ：デフォルトの名無しさん：2022/09/12(月) 19:28:16.63 ID:6xErrG1k.net

WasmはJavaとか変わんないのになんでアセンブリ名乗ってんの
いくらなんでもリテラシーが低すぎないか

624 ：デフォルトの名無しさん：2022/09/12(月) 19:58:51.59 ID:M7cyS1TF.net

>>623
そこは起源がasm.jsから来てるのだろうけど
決定的な違いとしてJava仮想マシンはガベージコレクション前提
Wasmはガベージコレクション無しで始まった点からもWasmがアセンブリに近いかな

625 ：デフォルトの名無しさん：2022/09/12(月) 20:44:55.38 ID:yQQmK+X7.net

コンパイル通れば問題ないとかそういうところやね

626 ：デフォルトの名無しさん：2022/09/12(月) 20:55:33.71 ID:o4fglLbA.net

なるほど確かにそう言ってました
型システムが重厚長大でトランスフォーマーだらけで
「正しいコード」をコンパイラ通しづらくなるのよ。
とうせるんだけどそのための変更の労力が馬鹿になんなくなる。
で、やーめた、となる。。

627 ：デフォルトの名無しさん：2022/09/12(月) 21:06:58.74 ID:UhYQaJnf.net

コンパイル通れば問題ない

コンパイル通れば コードが成長すると加速度的にコンパイル通し辛くなる
コンパイル通っても 「問題ない」なんて理想でした

Rustでもどっちも当てはまる

628 ：デフォルトの名無しさん：2022/09/12(月) 21:13:22.93 ID:o/NFQNbK.net

コードが成長すると全体把握が難しくなるというのは分かるがコンパイル通すのが難しくなるというのは分からんな
イディオムに従えばコンパイルは通せるでしょ普通に

629 ：デフォルトの名無しさん：2022/09/12(月) 21:20:13.29 ID:fZo/hnBr.net

C/C++/低レイヤー/wasm/GC/大規模コード/概念的理解の精密化の
ヒント・間違い指摘・揚げ足取りは思う壺です。

プロレスに終始

630 ：デフォルトの名無しさん：2022/09/12(月) 21:41:14.55 ID:M7cyS1TF.net

>>626
Rustはコンパイル通し辛いとかないよ
もちろんどの言語でも慣れるまでは大変だけど
Rustも他の言語と同様に慣れたら大丈夫

631 ：デフォルトの名無しさん：2022/09/12(月) 21:44:33.36 ID:7cpDGgxf.net

荒らし本人は4回線で、ID維持、単発ID織り交ぜてサクラ、ごく稀に便乗

プロレスに終始

632 ：デフォルトの名無しさん：2022/09/12(月) 22:18:50.83 ID:CmFXNZxi.net

Scalaレベルで着地できれば御の字、あるいは...
Haskellはアカデミック勢が根強い、果たしてRustは...

633 ：デフォルトの名無しさん：2022/09/12(月) 22:27:46.58 ID:68AKLxnx.net

>>609
シナリオどちらかになるんだろうけど
どちらになってもRustを使いこなせる人が勝ち組じゃん

634 ：デフォルトの名無しさん：2022/09/12(月) 22:29:18.43 ID:Paw7Qaib.net

しょうもない感想 プロレス乙

635 ：デフォルトの名無しさん：2022/09/12(月) 23:18:05.19 ID:vGI5q7L7.net

スタックとかヒープとかはC++の方から来た性質だから
Haskellは本当の敵ではないね

636 ：デフォルトの名無しさん：2022/09/12(月) 23:46:25.23 ID:7g4swwEZ.net

>>589
そこに上がってるのもほとんどがフレームワーク使ってシステム作ってますな使い方しか日本じゃしてないから、そういうとこにRustが入り込むにはもっと周辺が充実してからじゃないと日本じゃ無理じゃね？

637 ：デフォルトの名無しさん：2022/09/12(月) 23:47:46.93 ID:7g4swwEZ.net

>>596
COBOLとFORTRAN忘れてるぞ。

638 ：デフォルトの名無しさん：2022/09/13(火) 07:23:17.27 ID:gWDv6hSm.net

stackoverflow
73,268 response

fullプロ率は 73%
パート等込み 73+8+2 = 83%

JetBrains
31,743 developers →有効補正換算 47,000 people (Data cleaning 地域間格差補正が入る)

fullプロ率は 63+5+5 = 73%
パート等込み 73+7+2 = 82%

単純回答者数でstackoverflowが倍以上
調査参加者の構成割合は似たり寄ったり

JetBrains調査で関心したのがデータクリーニングの明確化
ちゃんとした集計であると言う信頼感はある

>Data cleaning process
>identical IP addresses
>overwhelmingly similar ... Szymkiewicz-Simpson overlap coefficient
>Surveys with conflicting answers
>...

stackoverflowがごみデータ混じりだと言うつもりはないけど同等の記述がないのは不安要素
stackoverflowはロックオンされやすい？

数のstackoverflow v.s. 質のJetBrains
こんなところ

639 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>631
やっぱりワッチョイ必須だな。

640 ：デフォルトの名無しさん：2022/09/13(火) 08:14:25.37 ID:y6KzmKzo.net

>>636
Rustだと所有権とかsingle mutable xor immutable referenceとかのキツイ制約があるから、フレームワークを作るのも使うのも大変。
まぁ、Rustフレームワークが充実することなんて無いんじゃない？

641 ：デフォルトの名無しさん：2022/09/13(火) 08:41:26.44 ID:6PkwAjCS.net

>>640 荒らし本人の主張
この後いつもの世迷言が始まる

642 ：デフォルトの名無しさん：2022/09/13(火) 09:59:52.44 ID:zBh9FomI.net

小学生は方程式を使ってはならない的なキツイ規制が無いからこそ
C++やRustがやりたい放題やってる

643 ：デフォルトの名無しさん：2022/09/13(火) 10:12:26.30 ID:loRx10nA.net

>>642
それを言うなら Rustはキツイ規制の鶴亀算

644 ：デフォルトの名無しさん：2022/09/13(火) 10:43:48.12 ID:eyEnRRRC.net

「なんで鶴亀算だけで全て解かなきゃなんねえんだよ」
「鶴亀算だけなら俺が安全性や正しさを確実に保証してやれるからだよ！！！」

645 ：デフォルトの名無しさん：2022/09/13(火) 11:41:37.83 ID:4BnmNWCa.net

お待たせしました(1/2)

Go　　実稼働分野でバリバリ活躍中
　　　GitHub PullReq >TypeScriptとGoが圧倒的 ←New
Scala 実稼働分野でバリバリ活躍中
　　　KENTA >日本では衰退しました
Clojure StackOverflow >愛され言語ランキング上位 ←New

Rust　試食コーナーで食べてもらって狂喜乱舞
　　　StackOverflow >愛され言語ランキング1位
　　　JetBrains >Rustで作らしてくれーと言ってるけど許可降りない
　　　KENTA >提灯コメント出さない ←New
　　　俺 >数学出来ないのでRustはキツイ規制の鶴亀算が史上最強 ←New
　　　俺 >鶴亀算でRustフレームワークが充実することなんて無い ←New
　　　Rust >鶴亀算だけなら俺が安全性や正しさを確実に保証 unsafeは関知しない お前の責任だ ←New
　　　俺 >今はRustだけで良い。レベルアップはお断りだ
　　　俺 >数学出来ないけど有能社員を指導したいとは思ってる
　　　俺 >すべての理解が概念的 概念的に理解すれば簡単だ
　　　有能社員 >Rustは学習コストが高い割に使えない
　　　有能社員 >C/C++を書けないとRustは書けない、Rustは意味なし
　　　有能社員 >Rustは言語オタク Haskellと同じ道
Nim 試食コーナーでスルーされて意気消沈
　　　英語できないので言語マニュアルの日本語訳がスゴい ←New
　　　Pythonからの乗り換えに最適(未確認 実例が待たれる) ←New
Pony 開店前
　　　唯一無二の売りがある模様 ripgrep並みの実例が待たれる ←New
　　　awesome-ponyが2年以上更新されていない ←New

646 ：デフォルトの名無しさん：2022/09/13(火) 11:43:15.62 ID:t741VCGK.net

お待たせしました(2/2)
↓New
Haskell アカデミック勢が根強い
　　　それ以外は衰退しました
OCaml 関数型で速度を最優先するならこれ1択
　　　StackOverflow >愛され言語ではない
FORTRAN 科学技術方面で強い、しばしば1択
Julia 科学技術方面開拓中
　　　StackOverflow >愛され言語ランキング上位
COBOL 金融機関方面では既存システムで根強い
　　　それ以外は衰退しました

647 ：デフォルトの名無しさん：2022/09/13(火) 11:46:20.50 ID:k/lRopxK.net

愛され言語で上位になったらかなり高確率で衰退言語になる。

648 ：デフォルトの名無しさん：2022/09/13(火) 12:01:05.28 ID:tpYV5tct.net

>>641
もっとまともな反論したら？
せめて「actix-web最強」ぐらい言えよ。使ったこと無いから知らんけど。

649 ：デフォルトの名無しさん：2022/09/13(火) 12:03:41.56 ID:pHZbxmIz.net

愛され言語≒仕事で使ってない言語 楽しい趣味

650 ：デフォルトの名無しさん：2022/09/13(火) 12:30:34.07 ID:zBh9FomI.net

お金を儲けることの何が苦痛なんですか？

651 ：デフォルトの名無しさん：2022/09/13(火) 12:33:48.30 ID:rcRzJ+qQ.net

かなり高確率で新しいおもちゃを見つけて衰退言語になる

652 ：デフォルトの名無しさん：2022/09/13(火) 12:41:31.43 ID:y6KzmKzo.net

>>650
苦痛だから他人が金を払うんだろ。

653 ：デフォルトの名無しさん：2022/09/13(火) 12:43:32.14 ID:gIIyLcDU.net

>>646
関数型最速はF#

654 ：デフォルトの名無しさん：2022/09/13(火) 12:52:26.68 ID:x5Pd+Z34.net

>>653
実例根拠が待たれる

655 ：デフォルトの名無しさん：2022/09/13(火) 13:22:39.32 ID:B87y3gGt.net

>>609
既にそのパターン２で進んでるように見える
状況を認識できている世界的IT大手はいずれもRustを採用して高速と安全の両立へ
そしてまともなところは今後追随していくのが確実だからダメなクズが取り残される

656 ：デフォルトの名無しさん：2022/09/13(火) 13:32:39.70 ID:C2XVu2lz.net

>>609
バスに乗り遅れるな論法
日本人には通用しなくなった

657 ：デフォルトの名無しさん：2022/09/13(火) 13:41:48.64 ID:zBh9FomI.net

弱肉強食がもう通用しない
早く生まれた年寄りが遅く生まれた子供の肉を食うから

658 ：デフォルトの名無しさん：2022/09/13(火) 13:43:26.99 ID:H2N4SaFr.net

C++だって誕生当初からこれまで、先行投資なんか必要なく、
陳腐コモディティでも二極化でもないんだから

Rustも先行投資なんて必要なくてGAFAMのトリクルダウンをどっしり待つくらいで十分
トリクルダウンなんて期待してないけど

659 ：デフォルトの名無しさん：2022/09/13(火) 13:46:36.71 ID:m7X9WFNl.net

GAFAMって、、永遠に試食タイムでしょ

660 ：デフォルトの名無しさん：2022/09/13(火) 13:50:43.06 ID:/+RM8oAP.net

「甘ま〜〜い」ってさけんでる食レポ

661 ：デフォルトの名無しさん：2022/09/13(火) 14:16:27.24 ID:/5hyl5nT.net

Rustの動きが興味深いのは、
C++の分野だけでなく幅広い分野で用いられてる点だが、
C++と異なり現代的な様々なパラダイムを簡潔に扱えるようシンプルに統合されてることも大きいのではないか。

もちろん、常に安全に自動的にメモリが解放される手軽さを得つつ、
少し注視するだけでC並みの高速化を安全に得られることが決定打なのだろうが。

662 ：デフォルトの名無しさん：2022/09/13(火) 14:30:44.11 ID:37EvHtEx.net

>>661
そう、Rustには興味のアンテナ張るだけ
先行投資なんてしない トリクルダウンって何年後？

663 ：デフォルトの名無しさん：2022/09/13(火) 15:06:51.76 ID:xxUpITvK.net

全プログラミング学習者へ。ハーバード大の入門講座「CS50」が無償かつ日本語で学べるようになりました！
https://www.lifehacker.jp/article/2209_cs50_new/
＞「CS50」ではコンピュータサイエンスとプログラミングに関する概念や考え方、C、Python、SQL、JavaScriptなど主要言語を学べる

Rustは対象外(笑)

664 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>663
GAFAMの一角が協賛してるのにどうしてこうなった(笑)
https://media.loom-app.com/loom/2022/09/07/6d29489f-719f-4f30-91ec-bed1c0a7d52c/original.png

665 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>609の二極化が進みそうだな
企業もプログラマーもRustを使いこなして高速と安全とリソースコスト削減をできるか否か

666 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>609 >>663
二極化だと思ってたらHaskell衰退の道を追う

667 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>664
おまえ頭悪そうだな
Rustがコモディティ化するのと二極化するのとどちらがGAFAMなどの寡占を維持できるか？
C言語と同等に高速で安全も満たす言語がRustの他にない

668 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>667
ショックを隠しきれない(笑)

669 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>645
１行に収まらない文章は見た目悪いから短くして

670 ：デフォルトの名無しさん：2022/09/13(火) 15:38:06.45 ID:urKAOro+.net

>>667 >>662

GAFAMがRustを寡占するんだったら尚のこと先行投資なんてしない

GAFAM >Rustエコシステムには投資しない トリクルダウン無し 寡占する

671 ：デフォルトの名無しさん：2022/09/13(火) 15:39:48.42 ID:ywmd5ThV.net

>>667 >>662
GAFAM >だか今は試食タイムだ

672 ：デフォルトの名無しさん：2022/09/13(火) 15:44:54.29 ID:nrX2Avhq.net

>>667 >>669
ショックを隠しきれない(笑)
>>663

673 ：デフォルトの名無しさん：2022/09/13(火) 15:45:37.89 ID:zuI+ipCK.net

>>667
あーあ、D言語と戦争すんのか....

674 ：デフォルトの名無しさん：2022/09/13(火) 16:26:40.14 ID:NZjV2Lo6.net

Rustを使える企業とプログラマーが有利になるだけで
あとは置いてきぼりを喰らって不利になるだけだろう

675 ：デフォルトの名無しさん：2022/09/13(火) 16:28:34.29 ID:MR/SvflR.net

こんな風に攻撃的に擁護する人のいる言語は使ってはいけない
高確率で地雷

676 ：デフォルトの名無しさん：2022/09/13(火) 16:33:18.32 ID:tpYV5tct.net

>>664
教育コストが高すぎて、大学で教えられないということだろ。
情報工学でLispをやらなくなったのと一緒だよ。

677 ：デフォルトの名無しさん：2022/09/13(火) 16:35:31.99 ID:O8KoebnP.net

>>646
明らかによくわかってなくて草

678 ：デフォルトの名無しさん：2022/09/13(火) 16:38:07.57 ID:uqmbOE3c.net

>>676
MITのことを言っているなら勘違いが過ぎる

679 ：デフォルトの名無しさん：2022/09/13(火) 16:38:33.78 ID:O8KoebnP.net

>>676
Lispがわかりにくいのは単なる構文の問題
やってることはJavaScriptと変わらんよ
なぜかそれを凄いことのようにブランディングした先人たちのマーケティング能力の方が驚きだよ

680 ：デフォルトの名無しさん：2022/09/13(火) 16:44:59.43 ID:0TrGa1vI.net

>>679
Clojureの人たちは「本物のREPL」とか言ってるよね

681 ：デフォルトの名無しさん：2022/09/13(火) 17:04:48.92 ID:zuI+ipCK.net

プログラミング言語で闘争を続けて、１つも新しいソフトウエアやサービスを生み出せない日本の縮図だな・・・
欧米企業なら、「最初のバージョンは常に捨てられる」の格言通り、いかにいち早く世に出すか注力する。
なんで書いてあるかは余り関係ない
日本にも有名なソフトウェアのコミッターは数多くいるけど、コンピューターサイエンスというほとんど役に立たない事が
ものすごいマウントポジションをとるだけに使われ、人より早く書くや、人より多く書く人はありがたがらない。
欧米だと「アイデアは価値がない、アイデアを誰より早く形にして価値がある」とまでされる

682 ：デフォルトの名無しさん：2022/09/13(火) 17:14:35.35 ID:jv6QQJzV.net

そもそも向こうの技術者土方じゃないだろ

683 ：デフォルトの名無しさん：2022/09/13(火) 17:15:56.27 ID:Zt4ZmGLP.net

>>681
はい、言語選択が決定的要因だとは思いません。

相関はあると思うのであえて言語/frameworkで聞きますが
Ruby(Rails)は現在で良い選択だと思いますか？
スタートアップだとかのサイト作成の場合

684 ：デフォルトの名無しさん：2022/09/13(火) 17:20:10.04 ID:zBh9FomI.net

書くのが遅いというか
お金をいくらもらえるか決めるのが早過ぎるのでは
カンバン方式みたいな

685 ：デフォルトの名無しさん：2022/09/13(火) 17:24:48.85 ID:v8x42YYy.net

>>684
Rustは書くのが遅いという前提の話かな

686 ：デフォルトの名無しさん：2022/09/13(火) 17:28:11.67 ID:rqfJwBbj.net

システムプログラミング系の講義ならrust使うものとかあるんじゃないの

687 ：デフォルトの名無しさん：2022/09/13(火) 17:30:11.70 ID:TeDe9n0i.net

>>686
ないと思うけど、どこかで見つけた？

688 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>687
スタンフォードだったわ
https://web.stanford.edu/class/cs110l/handouts/course-information/

689 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>688
Rustでメンタルモデル(概念)だけを教えてC++で仕上げとは
上手く行くといいね

690 ：デフォルトの名無しさん：[ここ壊れてます] .net

サイバーエージェントの広告配信サーバーもRustだし
クックパッドもRustだし
日本でもどんどんRustへ置き換わっていってるな

691 ：デフォルトの名無しさん：[ここ壊れてます] .net

rust system programming course university
でググったらUMDとかTUMとか出てくるわ
大学で教えられないほど教育コスト高いということはなさそう

692 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>690 >>691
じゃあなんでRustがTIOBEで20位に入れないのか
https://news.mynavi.jp/techplus/article/20220907-2448116/
>Rustのように20位以内の常任入りが予測されつつも長期にわたって実現していないプログラミング言語

693 ：デフォルトの名無しさん：[ここ壊れてます] .net

ソフトは無料でも教科書には課金した方が
教科書の劣化コピーがネット上で大量生産されやすい

694 ：デフォルトの名無しさん：2022/09/13(火) 18:35:59.90 ID:Ouug8JCC.net

>>692
Rustは勝者のためのプログラミング言語だから敗者には必要ない
敗者は遅い言語や危険な言語を使い続ければよい

695 ：デフォルトの名無しさん：2022/09/13(火) 18:41:40.88 ID:rqfJwBbj.net

>>692
大学で教えられているかどうかとTIOBEのランクに関係がある理屈がよくわからんのだけど

696 ：デフォルトの名無しさん：2022/09/13(火) 19:16:06.70 ID:da5BeFTI.net

>>694
スゲー

697 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>694
素晴らしい。
Haskell目指して頑張ろう。

698 ：デフォルトの名無しさん：[ここ壊れてます] .net

ClojureはあれでCircleCIとかいくつかの実用サービスに使われてるのがすごいよ。

lispは遊びでいくつか書いたけど、実用的なサービスをこれで書く気はなかなか起きないんだよなぁ。

699 ：デフォルトの名無しさん：2022/09/13(火) 23:26:20.76 ID:CJstPXh2.net

>>663
コンパイル方式がメインな言語はCしかないの？

700 ：デフォルトの名無しさん：2022/09/14(水) 07:41:49.23 ID:JkmtTv17.net

ClojureにはLogSeqでお世話になってる。Obsidianと併用

701 ：デフォルトの名無しさん：2022/09/14(水) 09:46:52.30 ID:ZrnGb3cN.net

型でプログラミングってこういうこと？

Rustで型レベルプログラミング
https://zenn.dev/yyu/articles/1eefb8f547dc1b

702 ：デフォルトの名無しさん：2022/09/14(水) 09:49:05.48 ID:RK5VR+Qw.net

>>701
素晴らしい。
Haskell目指して頑張ろう。

703 ：デフォルトの名無しさん：2022/09/14(水) 10:07:19.36 ID:K2Ymv4YJ.net

上ので思い出したけど
先にtypescriptやったあとrust入ったせいでリテラル型がないの違和感なんだけどなんか理由あるん？
enumでいいじゃん的な理由？

704 ：デフォルトの名無しさん：2022/09/14(水) 10:42:39.99 ID:gVevfQX/.net

>>703
文字列との相互変換とかIDE補完とかtypoエラーチェックとかExhaustive matchingとか他
どっちがどうなのかまとめて

705 ：デフォルトの名無しさん：2022/09/14(水) 11:18:49.59 ID:qMxoDGM7.net

お待たせしました(awesomeレス 1of2 ※)

Clojure StackOverflow >愛され言語ランキング上位
　　　　2つあるawesome-clojureがどちらもマメに更新される ←🆕
　　　　CircleCIとかいくつかの実用サービスに使われてるのがすごい ←🆕
　　　　「本物のREPL」(未確認) ←🆕　LogSeq(未確認) ←🆕
D　　　 C言語と同等に高速で安全も満たす言語 ←🆕
　　　　better C/C++の先駆者　breaking changeは日常茶飯事　awesome-d 老舗の割にマメ ←🆕
Rust　　試食コーナーで食べてもらって狂喜乱舞
　　　　GAFAM >Rustエコシステムには投資しない トリクルダウン無し 寡占する ←🆕
　　　　GAFAM >だか今は試食タイムだ ←🆕
　　　　GAFAM >「あま〜〜い」ってさけんで食レポしてる😏みんな食べに来てね😛 ←🆕
　　　　StackOverflow >愛され言語ランキング1位
　　　　JetBrains >Rustで作らしてくれーと言ってるけど許可降りない
　　　　KENTA >提灯コメント出さない
　　　　俺 >数学出来ないのでRustはキツイ規制の鶴亀算が史上最強
　　　　俺 >鶴亀算でRustフレームワークが充実することなんて無い
　　　　Rust >鶴亀算だけなら俺が安全性や正しさを確実に保証 unsafeは関知しない お前の責任だ
　　　　俺 >今はRustだけで良い。レベルアップはお断りだ
　　　　俺 >数学出来ないけど有能社員を指導したいとは思ってる
　　　　俺 >すべての理解が概念的 概念的に理解すれば簡単だ
　　　　有能社員 >Rustは学習コストが高い割に使えない
　　　　有能社員 >C/C++を書けないとRustは書けない、Rustは意味なし
　　　　有能社員 >Rustは言語オタク 二極化だと思ってたらHaskell衰退の道を追う ←🆕
　　　　有能社員 >Rustには興味のアンテナ張るだけ 先行投資なんてしない ←🆕
OCaml　 関数型で速度を最優先するならこれ1択(or F#？) ←🆕　StackOverflow >愛され言語ではない
F#　　　関数型最速はF#(実例根拠が待たれる) ←🆕

706 ：デフォルトの名無しさん：2022/09/14(水) 11:21:13.69 ID:puz0kIZm.net

お待たせしました(awesomeレス 2of2 ※)

Go　　　実稼働分野でバリバリ活躍中　GitHub PullReq >TypeScriptとGoが圧倒的
Scala　 実稼働分野でバリバリ活躍中　KENTA >日本では衰退しました
　　　　ScalaでのNetflix分岐点(未確認) ←🆕
Nim 　　試食コーナーでスルーされて意気消沈　英語できないので言語マニュアルの日本語訳がスゴい
　　　　Pythonからの乗り換えに最適(未確認 実例が待たれる)
Pony　　開店前　唯一無二の売りがある模様 ripgrep並みの実例が待たれる　awesome-ponyが2年以上更新されていない
　　　　参照の持ち方だけで6つもある(Reference Capability) ←🆕
　　　　behaviorが終わるごとに該当アクターでGCを回す ←🆕
Haskell アカデミック勢が根強い　それ以外は衰退しました
FORTRAN 科学技術方面で強い、しばしば1択
Julia　 科学技術方面開拓中　StackOverflow >愛され言語ランキング上位
COBOL　 金融機関方面では既存システムで根強い　それ以外は衰退しました
LISP　　JavaScriptと変わらん ブランディングした先人たちのマーケティング能力が驚き ←🆕

※ジョーク集です。「未確認」表示の有無に関わらず真偽を保証するものではありません。

707 ：デフォルトの名無しさん：2022/09/14(水) 14:26:54.73 ID:zwrBt+Xf.net

wsl2のdebian入れたら何故かgrepコマンドがなくてrust製のripgrep(rg)をいれたわ

708 ：デフォルトの名無しさん：[ここ壊れてます] .net

それ遅くないの？

709 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>708
どっちの立ち位置のコメントかわからないけれどripgrepを知らない設定は不自然
ugrepとの比較のこと？

710 ：デフォルトの名無しさん：2022/09/14(水) 17:43:41.36 ID:glLuISAD.net

WSL2にdebianの方の話だろ？

711 ：デフォルトの名無しさん：2022/09/14(水) 17:45:19.09 ID:e1B1zDJm.net

>>703
パターンマッチ使えば同じことはできるよ
なんならマクロでもいい
ゼロコスト抽象化に反することはしないのがRust

712 ：デフォルトの名無しさん：2022/09/14(水) 17:52:32.97 ID:9tETuf2A.net

>>711
値が"foo"という文字列以外が渡されるとコンパイルエラーになる関数とか書けないでしょ

713 ：デフォルトの名無しさん：2022/09/14(水) 18:00:21.72 ID:jv9cR4Ls.net

ただ単にコンパイルがこれ以上遅くなる言語仕様を入れたくないだけ、何がゼロコスト抽象化だわｗまったく見当違いも良いところ

714 ：デフォルトの名無しさん：2022/09/14(水) 18:22:00.72 ID:e1B1zDJm.net

>>712
だからマクロでできるっての
お前が何も知らないだけ

715 ：デフォルトの名無しさん：2022/09/14(水) 18:26:53.48 ID:9tETuf2A.net

>>714
うん、分からないから教えてよ

716 ：デフォルトの名無しさん：2022/09/14(水) 18:35:03.91 ID:v4ijbwnI.net

typescript(+javascript)を言語機能(優劣、同等性)で敵に回すのは無謀だ
数的優位、実績が半端ない Rustがゴミの様だ

https://madnight.github.io/githut/#/pull_requests/2022/1/JavaScript,TypeScript,Swift,Go,Kotlin,Rust,Scala

717 ：デフォルトの名無しさん：2022/09/14(水) 18:40:04.75 ID:fEwp+zOJ.net

マクロでコンパイル時型エラーにできる？
実行時ならアサーション入れたりでマクロで何とかなりそうだけどコンパイル時に検出は無理くない？

個人的にはTypeScriptみたいな複雑さって本来過剰で、ブラウザ上のJSという特別な実行環境がゆえに必要になったもので、本来はenumとかで済までいいと思う。

718 ：デフォルトの名無しさん：2022/09/14(水) 18:45:22.21 ID:NFr/kVLx.net

>>698
lispは惑星探査機とか、特殊な用途で使われてるイメージ。
身近なところだと、ルンバがlispで動いてたはず。

719 ：デフォルトの名無しさん：2022/09/14(水) 18:49:12.89 ID:lL+9RYqC.net

>>718
>惑星探査機
何にも知らないけどAdaとかどうなんだろう

720 ：デフォルトの名無しさん：2022/09/14(水) 18:53:12.24 ID:KdAr4qV+.net

>>717
マクロの引数をリテラル限定にしてその値をコンパイル時にチェックするくらいならできそうだけど
変数経由で渡されたときにその中身を確認するのは無理だろうな
Rustの依存型は提案されたけど入らなかったね（理由は忘れた）

721 ：デフォルトの名無しさん：2022/09/14(水) 18:56:03.38 ID:eqqO6UXU.net

自動車 船舶 航空宇宙のプログラムで求められる安全性ってRustは保証しないの？

722 ：デフォルトの名無しさん：2022/09/14(水) 19:13:40.15 ID:Jmciqxd+.net

>>714
>だからマクロでできるっての
>お前が何も知らないだけ

↓
>>720
>できそうだけど

これってまさか同一人物の発言?

723 ：デフォルトの名無しさん：2022/09/14(水) 19:22:13.99 ID:KdAr4qV+.net

いや別人
自分はマクロを使っても完全なサポートは無理だと思ってるよ
マクロを使ってなんとか実現できそうなことを書いてみただけで

724 ：デフォルトの名無しさん：2022/09/14(水) 19:35:40.12 ID:ynFB7Nxb.net

現実派の>>723さん、>>721についてはどう思いますか？
突き詰めるとメモリ安全性って自動車 船舶 航空宇宙でも大きなウェイトを占めていてもおかしくない気がするのです。
Rust方面の意識として乗り物関連は避けたいとかあるんですか？

「Chrome」で対処されているバグの種類
https://asset.watch.impress.co.jp/img/wf/docs/1439/971/image3.png

725 ：デフォルトの名無しさん：2022/09/14(水) 19:39:33.00 ID:9tETuf2A.net

中身読んでないけどこんなのがあるらしい
https://codezine.jp/article/detail/15541

726 ：デフォルトの名無しさん：2022/09/14(水) 19:41:21.82 ID:ynFB7Nxb.net

>>724画像の記事
「Chrome」は「MiraclePtr」でさらに安全に 〜Googleが「解放後メモリ利用」対策を開設 診断性が向上するという副次的効果も
https://forest.watch.impress.co.jp/docs/news/1439971.html

727 ：デフォルトの名無しさん：2022/09/14(水) 19:44:04.15 ID:PyjIicam.net

>>724
トヨタが自動運転関係でRust使ってる話を見たことあるね
ChromeはRustで書き直せばバグを1/4に減らせると言われているね

728 ：デフォルトの名無しさん：2022/09/14(水) 19:46:27.51 ID:ynFB7Nxb.net

>>725
>安全を認定されたAdaツールチェーンの開発で培ってきた専門知識をRustコミュニティへ拡大する機会を提供する。
こういうのを待ってました!

>Ferrocene Rustコンパイラ
多分有償なんだろなorz

729 ：デフォルトの名無しさん：2022/09/14(水) 19:50:08.79 ID:BmzwXpH0.net

>>724
GC言語だと赤と青はまず発生しないからやっぱりRustは別にそれを置き換えることはないな
あくまでもCやC++を置き換える有力候補

730 ：デフォルトの名無しさん：2022/09/14(水) 19:53:28.65 ID:ynFB7Nxb.net

>>727
トヨタはRust資産をOSSしてくれるんだろうか...

731 ：デフォルトの名無しさん：2022/09/14(水) 19:54:27.88 ID:KdAr4qV+.net

>>728
FerroceneはRustコンパイラのISO26262認証取得を目指してるから
通れば自動車とかへの採用はあり得るよ
スポンサーもついているようだから少なくとも興味のある企業があるのは間違いない
Ferrocene自体はRustの特定バージョンの仕様を文書化して認証を取るという試みだから
コンパイラが別途有償になる予定はないはず

732 ：デフォルトの名無しさん：2022/09/14(水) 19:55:03.16 ID:AxsRNHLb.net

>>726
その記事を読むとChromeはC++のまま情けない解決策を取ろうとしてるなあ
特に参照カウンタ方式を強制するのは敗北に見える
メモリ使用量が増えると明記されているのはともかく
参照カウンタのデータ競合回避保護のためのオーバヘッドでパフォーマンスも大幅に悪化が予想されているのか

733 ：デフォルトの名無しさん：2022/09/14(水) 19:58:45.25 ID:ynFB7Nxb.net

>>727 >>729
>ChromeはRustで書き直せばバグを1/4に減らせると言われているね
>あくまでもCやC++を置き換える有力候補
この辺はタラレバくらいに思ってます、軍事関係みたく湯水の様にお金をつぎ込まない限り

734 ：デフォルトの名無しさん：2022/09/14(水) 20:00:07.72 ID:c3IeBynX.net

>>729
GC言語からRustへ置き換えるケースが多いのは別の理由でメリットが多いためだよ
・高速化
・省メモリ化
・データ競合の完全防止

735 ：デフォルトの名無しさん：2022/09/14(水) 20:05:15.38 ID:ynFB7Nxb.net

>>731
続報待ちます

>>732,734
>データ競合回避保護 データ競合の完全防止
難しそう。自動化してほしい

736 ：デフォルトの名無しさん：2022/09/14(水) 20:09:59.80 ID:c3IeBynX.net

>>735
データ競合をコンパイル時点でゼロにすることに成功したのがRust

737 ：デフォルトの名無しさん：2022/09/14(水) 20:16:19.59 ID:tyPb8uvV.net

Rustのデータ競合防止のやり方は効率性を犠牲にして安全側に倒してるだけでしょ
程度の違いこそあれ、純粋関数型で全部イミュータブルにすりゃデータ競合なんか起こらねえというのと同じようなもんだ

738 ：デフォルトの名無しさん：2022/09/14(水) 20:16:52.96 ID:ynFB7Nxb.net

現実派の>>723さん、>>736についてはどう思いますか？

739 ：デフォルトの名無しさん：2022/09/14(水) 20:27:11.32 ID:KdAr4qV+.net

ゼロってことはないよ
標準ライブラリ内とか人間がデータ競合しないことを保証してるところはそれなりにあって、そこにバグが入ることはありうる
実際過去に発見されたことはあったはず
ただまぁ他言語はほとんどなにも保証してくれないから
それに比べれば十分メリットはあると思うけど

740 ：デフォルトの名無しさん：2022/09/14(水) 20:33:35.83 ID:KdAr4qV+.net

あと今人間が保証してるとこを機械的に証明しようという試みはあって
そういうのがうまくいけばゼロだと言える日がくるかもね
（そうはいっても証明手順に抜けがあるかもとかあるので真にゼロとはいえないかもだけど）

741 ：デフォルトの名無しさん：2022/09/14(水) 20:34:31.90 ID:SxGO9/pM.net

並行安全がーとかいうけど言語自体やライブラリを跨いで共通のお作法で並行並列処理を書けるGoと違って
Rustはあまりにもお粗末すぎるから結局無駄なことしてるだけとしか思わない

742 ：デフォルトの名無しさん：2022/09/14(水) 20:42:58.80 ID:9tETuf2A.net

>>737
効率が必要ならunsafe使うとか、適材適所で手段を選べるようにしてるから純粋関数型のたとえはちょっと違う気もする

743 ：デフォルトの名無しさん：2022/09/14(水) 20:49:55.99 ID:7hx6Nwjm.net

>>737
一般的にデータ競合安全性のためには
1. まず前提としてデータ競合の可能性がある場合にコンパイル時に自動的に必ず検知できること
2. プログラマーはデータ競合の可能性がある部分のうち下記3.以外の方法(アルゴリズムやデータ構造などの変更)が取れる場合は変更
3. データ競合の可能性があるとして残った部分はロックなどで競合回避

Rustが用意しているのは1.の実施と3.の機構の提供
効率性を高めるか犠牲にするかは2.の実施と3.の利用をどう行なうか次第でありプログラマーによる自由度がある

744 ：デフォルトの名無しさん：2022/09/14(水) 20:58:16.45 ID:tyPb8uvV.net

うん、だからそれデフォルトの挙動が安全側になってるという話だよね
そのレベルなら、デフォルトで全部immutableで必要に応じてmutableにできる言語なら十分に対策になってると言えるのでは

745 ：デフォルトの名無しさん：2022/09/14(水) 20:59:30.08 ID:1TdDwC+y.net

>>741
Goは並行しない場合もする場も様々な安全をプログラマーの自己責任で確保しなければいけないことが多すぎてそれ以前の問題があります
例えば非常に単純な>>556の例でもGoコンパイラはエラーとしてくれないためプログラマーが自己責任で防がなければなりません
一方で同じ問題例をRustならば>>560のようにコンパイルエラーとして検知できます

746 ：デフォルトの名無しさん：2022/09/14(水) 21:07:13.43 ID:PNfc8XBO.net

>>744
mutableを使った時点でデータ競合の可能性が発生するためコンパイラ等が検出する必要がある
一方で全てをimmutableにすると大量のガベージが発生して効率が悪い
効率と安全性を両立しているのはRust言語のみ

747 ：デフォルトの名無しさん：2022/09/14(水) 21:15:24.31 ID:c9vZvFEM.net

GCあり言語ならストップザワールドやGCスパイクとか体験できるじゃん。
でもRustだとそれができなくなる。

748 ：デフォルトの名無しさん：2022/09/14(水) 21:18:22.32 ID:I1qCwdEP.net

>>747
だからなに？

749 ：デフォルトの名無しさん：2022/09/14(水) 21:23:32.90 ID:9tETuf2A.net

>>744
mutableな共有領域に対するアクセスについてはコンパイラは特になにも保証しなくても良いということ？
そんな安全機構は邪魔なだけだから不要と

750 ：デフォルトの名無しさん：2022/09/14(水) 21:58:51.43 ID:VKXXNtX1.net

全部immutableと言うけど、スレッド間で通信するメッセージがimmutableなだけで
スレッド自体の状態は刻々と変化する

マルチスレッドが何の役に立つのかさっぱり分からない人にとっては
状態遷移をするにはスレッドを使うしかない言語の方が分かりやすい

751 ：デフォルトの名無しさん：2022/09/14(水) 22:33:42.94 ID:ynFB7Nxb.net

話が盛り上がっていたので見守ってました...
>>739 >>740
>機械的に証明
この辺もタラレバくらいに思ってます。「ゼロってことはないよ」の方が逆に説得力w

自分の現場は、石橋を叩いて渡る、です。(能力体力は十分)
RustはGAFAMなんかより自動車ISO認証級の実績積み上げがないと、下っ端が言い出すのも怖いくらいです。
Rust現実派の人が現れたので便乗してしまいました。ありがとうございました。

752 ：デフォルトの名無しさん：2022/09/14(水) 23:00:59.98 ID:wGnSnwqD.net

>>751
Rustは一貫して以下のルールでシンプルに安全性を保証している
「Rustコンパイラはunsafe部分を除いてプログラム全体の安全性を自動的に保証する」
「unsafe部分の保証と影響を外部に出さない保証のみプログラマーの責任となる」
つまりunsafeを用いたとしてもその局所的なコードのみ人間が注視するだけでプログラム全体が保証される仕組みをRustが提供している
従来の言語は安全でない部分がプログラム全体に散らばっている、かつ、言語が安全を保証する仕組みがない、という悲惨な状況であった

753 ：デフォルトの名無しさん：2022/09/14(水) 23:22:08.01 ID:c9vZvFEM.net

>>751
自動車業界はCやC++を使ってる。

754 ：デフォルトの名無しさん：2022/09/14(水) 23:41:24.29 ID:ynFB7Nxb.net

>>752
今後、オカタイところや人命に係る分野での採用記事事例など宣伝してもらえると嬉しいです。

>>753
自動車ISO認証取得+自動車への採用(どちらも今後の可能性)レベル、と書くべきでした。
「話はそれから」です。

755 ：デフォルトの名無しさん：2022/09/14(水) 23:48:26.40 ID:9tETuf2A.net

>>754
ちなみに今はどんな言語使ってるの？
枯れたツールチェインとなると結構古めのCとかかな

756 ：デフォルトの名無しさん：2022/09/14(水) 23:51:29.95 ID:ynFB7Nxb.net

>>755
>結構古めのCとかかな
様々な都合によりC、としか言えません

757 ：デフォルトの名無しさん：2022/09/14(水) 23:56:26.57 ID:ynFB7Nxb.net

普段は見てるだけなのですが、いいタイミングで便乗出来ました。
こういう現場もあるよという話が出来てよかったです。では。

758 ：デフォルトの名無しさん：2022/09/15(木) 00:02:18.55 ID:PSTi1Gas.net

GoogleとMicrosoftが共に各々で語っているようにC/C++で書かれた大規模ソフトのバグの7割はメモリ関係
例えば>>724のChromeでも7割がメモリ管理バグ
これがRustに移行すれば無くせるのだから新たなシステム作りでC/C++を採用するのはバカだけ

759 ：デフォルトの名無しさん：2022/09/15(木) 00:05:23.23 ID:nmd+p/jZ.net

>>746
それは、両立じゃなくて、選択肢があるってことだよね？
両立出来ていれば、わざわざ選択させる必要もないし。

760 ：デフォルトの名無しさん：[ここ壊れてます] .net

ファブルって最初は絵が受け付けなくて読んでなかったけど、いざ読んでみたら面白かった。

761 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>759
Rustの場合は常に安全が成立するから安全は選択肢ではない
アルゴリズムやデータ構造などを工夫することにより排他ロックなどを必要最小限にして効率化することはプログラマーの自由裁量
Rustにおいて安全と効率は両立できる

762 ：デフォルトの名無しさん：2022/09/15(木) 02:14:17.68 ID:/Qo8z/Hb.net

Rust「統一教会のほうから来ました」

763 ：デフォルトの名無しさん：2022/09/15(木) 08:27:21.28 ID:fhKzGp48.net

Rustは教官付き教習車だから、コンパイラの言うとおりに運転しないとブレーキ踏まれて前に進めない。

ソースコードのマネージャーにとっては福音だけどな。自分でコーティング規約を用意してコーダーに強制しなくても、コーダーが自分勝手にプログラムしてトラブルになる可能性が減る。
コーダーがコーティングしやすいかどうか、とかどうでもいい。

企業がRustを推奨し始めたのは、企業がマネージャーサイドでソースコードの管理コストを減らしたいから。コーダーは言うこと聞くやつを連れてくればいいという発想だよ。

764 ：デフォルトの名無しさん：2022/09/15(木) 08:31:31.13 ID:P/wAPOM3.net

>>762
統一教会は違くね？

765 ：デフォルトの名無しさん：2022/09/15(木) 08:56:48.93 ID:Z4cppPos.net

>>763
Rustはプログラマーに愛されている言語No.1しかも7年連続
快適なプログラミングのしやすさが特徴の一つ

766 ：デフォルトの名無しさん：2022/09/15(木) 09:07:58.83 ID:P/wAPOM3.net

>>707
grepに続いてtarも無い、と思ったらPATHから /bin が抜けてたわ。
/usr/bin にあるわけじゃないのか。

767 ：デフォルトの名無しさん：2022/09/15(木) 10:01:50.79 ID:rrfffa1i.net

お待たせしました(awesomeレス 1of2 ※)

Clojure StackOverflow >愛され言語ランキング上位　2つあるawesome-clojureがどちらもマメに更新されてる
　　　　CircleCIとかいくつかの実用サービスに使われてるのがすごい　「本物のREPL」(未確認)　LogSeq
　　　　Apple,CircleCI,Cisco,Cognitect,Nubank🏧,Walmart >使ってますが何か？ https://docs.google.com/spreadsheets/d/1jBQD-rzOeGeKgLjsQ21r4YfEHp8XOpB_vl6TGJEBj3g/edit#gid=0 🆕
Rust　　試食コーナーで食べてもらって狂喜乱舞
　　　　GAFAM >Rustエコシステムには投資しない トリクルダウン無し 寡占する　GAFAM >だが今は試食タイムだ
　　　　GAFAM >「あま〜〜い」ってさけんで食レポしてる😏みんな食べに来てね😛
　　　　StackOverflow >愛され言語ランキング1位
　　　　JetBrains >Rustで作らしてくれーと言ってるけど許可降りない
　　　　KENTA >提灯コメント出さない
　　　　俺 >数学出来ないのでRustはキツイ規制の鶴亀算が史上最強
　　　　俺 >鶴亀算でRustフレームワークが充実することなんて無い
　　　　Rust >鶴亀算だけなら俺が安全性や正しさを確実に保証 unsafeは関知しない お前の責任だ
　　　　俺 >今はRustだけで良い。レベルアップはお断りだ
　　　　俺 >数学出来ないけど有能社員を指導したいとは思ってる
　　　　俺 >すべての理解が概念的 概念的に理解すれば簡単だ
　　　　有能社員 >Rustは学習コストが高い割に使えない
　　　　有能社員 >C/C++を書けないとRustは書けない、Rustは意味なし
　　　　有能社員 >Rustは言語オタク 二極化だと思ってたらHaskell衰退の道を追う
　　　　有能社員 >Rustには興味のアンテナ張るだけ 先行投資なんてしない
　　　　現実派 >データ競合がコンパイル時点でゼロってことはない。JARO⚠案件だ 🆕
　　　　下っ端社員 >RustはGAFAMなんかより自動車ISO認証級(仮)の実績積み上げがないと、言い出すのも怖い😩 🆕
　　　　Rustは教官付き教習車だから、コンパイラの言うとおりに運転しないとブレーキ踏まれて前に進めない。 🆕

768 ：デフォルトの名無しさん：2022/09/15(木) 10:04:34.27 ID:HopAynZ9.net

お待たせしました(awesomeレス 2of2 ※)

D　　　 C言語と同等に高速で安全も満たす言語　better C/C++の先駆者　breaking changeは日常茶飯事　awesome-d 老舗の割にマメ
OCaml　 関数型で速度を最優先するならこれ1択(or F#？)　StackOverflow >愛され言語ではない
F#　　　関数型最速はF#(実例根拠が待たれる)
Go　　　実稼働分野でバリバリ活躍中　GitHub PullReq >TypeScriptとGoが圧倒的
Scala　 実稼働分野でバリバリ活躍中　KENTA >日本では衰退しました　ScalaでのNetflix分岐点(未確認)
Nim 　　試食コーナーでスルーされて意気消沈　英語できないので言語マニュアルの日本語訳がスゴい
　　　　Pythonからの乗り換えに最適(未確認 実例が待たれる)
Pony　　開店前　唯一無二の売りがある模様 ripgrep並みの実例が待たれる　awesome-ponyが2年以上更新されていない
　　　　参照の持ち方だけで6つもある(Reference Capability)
　　　　behaviorが終わるごとに該当アクターでGCを回す
Haskell アカデミック勢が根強い　それ以外は衰退しました(未確認)
　　　　Tesla,Microsoft,Meta,GitHub,一流銀行🏧 >使ってますが何か？ https://serokell.io/blog/top-software-written-in-haskell 🆕
　　　　Tesla >We use Haskell to auto-generate C code that is compiled into vehicle🚗 firmware. 🆕
　　　　下っ端社員 >いい話だ。だが結局☪かよ 🆕
Julia　 科学技術方面開拓中　StackOverflow >愛され言語ランキング上位
FORTRAN 科学技術方面で強い、しばしば1択
COBOL　 金融機関方面では既存システムで根強い　それ以外は衰退しました
Lisp　　JavaScriptと変わらん ブランディングした先人たちのマーケティング能力が驚き
　　　　惑星探査機🛰とか特殊な用途、身近なところでルンバ🤖がLisp 🆕
　　　　Awesome Lisp Company https://github.com/azzamsa/awesome-lisp-companies 🆕

※ジョーク集です。「未確認」表示の有無に関わらず真偽を保証するものではありません。

769 ：デフォルトの名無しさん：2022/09/15(木) 10:16:05.31 ID:AewR1FC3.net

>>763
これってrustに限った話ではないのでは
例えば今話題のgoの未使用変数をエラーにするとかは同じ考え方だよね

770 ：デフォルトの名無しさん：2022/09/15(木) 10:17:45.56 ID:P/wAPOM3.net

>>768
C言語がないぞ

771 ：デフォルトの名無しさん：2022/09/15(木) 10:18:10.05 ID:P/wAPOM3.net

>>768
C言語がないぞ

772 ：デフォルトの名無しさん：2022/09/15(木) 10:39:25.20 ID:zVxtxmNw.net

>>769
Goは元々>>556の例を始めとして落とし穴があちこち多数仕掛けられている言語なので
まずは様々な落とし穴パターンをできるだけ多く習得して自分で責任を持って回避していかないとすぐに事故を起こしかねない言語でもある
だからそこで言う教官(コンパイラ)が指導ダメ出ししてくれないケースが多い中で未使用変数の件は親切に指導してくれる良い例

773 ：デフォルトの名無しさん：2022/09/15(木) 10:59:43.56 ID:OR8C0I/3.net

>>769
これ実質的に自己責任論だから
人間はみんな自己だよねと言っても無駄で、自己はこの世に一人しかいないという考え方なのさ

774 ：デフォルトの名無しさん：2022/09/15(木) 11:07:06.60 ID:P/wAPOM3.net

Rust を使用した Windows での開発の概要
https://docs.microsoft.com/ja-jp/windows/dev-environment/rust/overview

775 ：デフォルトの名無しさん：2022/09/15(木) 12:17:06.07 ID:YIKrY0vS.net

なんでRust信者ってID変えんの？
自信ないからかな？

776 ：デフォルトの名無しさん：2022/09/15(木) 12:24:52.85 ID:Yrdeu38e.net

>>765 >>769
『Rustの作法に慣れたコーダーなら』コンパイラにブレーキを踏まれて止まることも少なくて快適だろうけど、慣れていない初級者・初学者のストレスは半端無い。

絶壁の学習曲線はRustの重大な問題で、これを何とかしない限りはHaskellくらいの普及率が関の山かと。

777 ：デフォルトの名無しさん：2022/09/15(木) 12:49:54.52 ID:6n/goZ6T.net

「教官、時速40キロで走っていると原付に追い抜かれて行きます。それに時間に遅れます!」
「奴は自己責任だ。お前は俺だけを見ろ」
「はい! あっ、事故っちゃいました、テヘ」
「ばっかも〜ん。しょうがないやつだな」

Rust、愛され言語No.1

778 ：デフォルトの名無しさん：2022/09/15(木) 13:02:27.27 ID:AewR1FC3.net

>>776
初学者が躓きがちなところって例えばどこなんだろう
学習曲線が急という話はあるが実際に初心者が苦しんでる箇所が知りたいなぁ

>>777
これって具体的に何のことを揶揄してるの？
安全性のために効率性が損なわれるという論はあるけどスレで出てきた事例が配列の境界チェックくらいでコンパイラ関係ないという

779 ：デフォルトの名無しさん：2022/09/15(木) 13:21:46.17 ID:N+NQH7M1.net

>>778
実効速度の事は揶揄してなくて、前半は>>681 >アイデアを誰より早く形にして価値がある
のことだと思うけど、
後半は手取り足取りでもChrome>>726でいう25%側で事故る(25%じゃ済まなくなる)、とか？

または愛されRust教官と生徒の...
大した意味はないと思う。

780 ：デフォルトの名無しさん：2022/09/15(木) 14:34:36.53 ID:7O/O6eid.net

まあ実際はrustで開発なんてほとんどしてないからな。
だから自信のない奴が無理矢理褒めてるんだよ。

781 ：デフォルトの名無しさん：2022/09/15(木) 14:42:23.71 ID:AewR1FC3.net

>>780
褒めてる側に怪しい人がいるのはそうだけど貶してる側も具体的な話に乏しくて印象だけで語っている人がいるような

782 ：デフォルトの名無しさん：2022/09/15(木) 14:58:36.52 ID:YdvnBlXp.net

Rustは荒れるので話題転換

Clojure Haskell Lisp辺りの過去に一世風靡？した言語が先端分野で地道に使われ続けてるのは
単純に個別要因(研究者の好みとか)なのだろうか。
Lispくらいの歴史があるのならともかくClojure Haskellである必要性必然性が理解できない。

リストにあるNimも何を目指してるのか、何が得意なのか見えない。
Pythonからの乗り換えに最適、って出てくるのはNumpyも使ってないPythonコードの高速化例が主で、
この程度で「研究者の好み」に響くのか疑問

783 ：デフォルトの名無しさん：2022/09/15(木) 15:09:17.30 ID:YdvnBlXp.net

率直に言うと、Nimには開発者、コミュニティの言語オタク感が、、(いい意味で)

784 ：デフォルトの名無しさん：2022/09/15(木) 15:26:45.00 ID:5tgK0LqN.net

>>763
ソースコードのマネージャーw
妄想が過ぎるやろww
お前やっぱり複オジと同じ種類の人間やな

785 ：デフォルトの名無しさん：2022/09/15(木) 15:28:52.49 ID:YnVRyWH8.net

>>782
エンジニアの単なる個人的な好みだよ
スタートアップの開発はだいたいエンジニア1人～せいぜい2,3人で始まり、作り方について外から誰も口出さないから、何でも好きなものを採用できる
とはいえあまり変なものは後からリプレースされることも多いが、あえて関数型使いたがるような奴は比較的優秀だから結果的に生き残りやすいんだろうね

786 ：デフォルトの名無しさん：2022/09/15(木) 17:40:49.72 ID:DPUhxpSw.net

>>776
どの言語もそうだけど慣れの問題だけだよ
慣れるまでは躓きやすいけど
慣れてしまえばそこに何か支障があるわけではなく快適

もちろん手続き型言語しか使ったことがなかった人が関数型言語を始めれば　最初だけカルチャーショック的なものもあるかもしれない

Rustは従来の手続き型言語のバリエーションの範囲内であり難しい点はなにもない
最近は増えてる関数型プログラミングを積極的にサポートしているだけの普通の手続き型言語である

787 ：デフォルトの名無しさん：2022/09/15(木) 18:14:28.13 ID:OR8C0I/3.net

ブレーキ云々は関数型ではなく静的型に責任がある
と理解するまでに10年単位の時間を消費してるのが現実

788 ：デフォルトの名無しさん：2022/09/15(木) 18:19:41.49 ID:uryhzbE3.net

lispはプロトタイプから本番に移行するに向いている的な事をどこかで見かけたんだけど、何か理由あるのかな？

本番であれば、今時は静的型付けの方が実行前にミスを減らせて良さそうって思うんだけど。

789 ：デフォルトの名無しさん：2022/09/15(木) 18:30:04.54 ID:AewR1FC3.net

lispで思い出される文章はこれ
http://practical-scheme.net/trans/beating-the-averages-j.html

790 ：デフォルトの名無しさん：2022/09/15(木) 18:42:43.79 ID:/dOm+x1c.net

Concurrencyについては詳しくないんだけど
goはやっぱりつよいの？
erlangよりつよいの？

791 ：デフォルトの名無しさん：2022/09/15(木) 18:55:22.88 ID:fhKzGp48.net

>>786
マニュアル教習車の運転を「慣れの問題」と言っているようなもんだな。
最初はエンストしまくっていても、慣れればいつかは運転できるようになるわな。それがいつだか知らんけど。

792 ：デフォルトの名無しさん：2022/09/15(木) 19:08:20.73 ID:QksYVlPK.net

>>777
そういえば前スレでrustは原付（php）に速度で負けてたよね

793 ：デフォルトの名無しさん：2022/09/15(木) 19:48:17.43 ID:/Qo8z/Hb.net

統一教会「Rustをお持ちしました」

794 ：デフォルトの名無しさん：2022/09/15(木) 20:20:12.75 ID:+mjTxJT1.net

嫌いなものにはとりあえず統一教会と絡ませておけば批判したことにできる頭の具合が羨ましい

795 ：デフォルトの名無しさん：2022/09/15(木) 21:03:43.45 ID:/Qo8z/Hb.net

統一教会「晋三を捧げよ」

796 ：デフォルトの名無しさん：2022/09/15(木) 21:29:46.27 ID:/Qo8z/Hb.net

>>794
いやあ、それほどでも（照

797 ：デフォルトの名無しさん：2022/09/15(木) 21:32:22.04 ID:z9CUv+9j.net

世界統一平和自民党から怒られるぞw

798 ：デフォルトの名無しさん：2022/09/15(木) 21:55:28.22 ID:/Qo8z/Hb.net

マジか。

799 ：デフォルトの名無しさん：2022/09/15(木) 22:18:19.78 ID:rqzHv7Xe.net

>>788
common lisp とかだとあとから型書いてパフォーマンス上がる処理系とかあった気がするし、プロトタイプから色々柔軟に改修しやすいとかあったのかもね。

800 ：デフォルトの名無しさん：2022/09/15(木) 23:09:10.28 ID:KFRYW2wo.net

次スレはこれらの言語を入れてください
Zig
https://ziglang.org/ja/
Jakt
https://github.com/SerenityOS/jakt

801 ：デフォルトの名無しさん：2022/09/15(木) 23:18:38.32 ID:M8k2LDUe.net

バージョンが 1.0 に達していない言語は混乱するだけだから入れなくていいよ
必要なら専用スレを立てた方がいい

802 ：デフォルトの名無しさん：[ここ壊れてます] .net

genesisを入れろ

803 ：デフォルトの名無しさん：[ここ壊れてます] .net

ちゃんと>>1に「スレタイ以外の言語もok」と書かれているように
それ以外の言語の話もこのスレでは歓迎です

スレタイは文字数制限があるため全ての言語を列挙することはできません
もし話題の多い言語が出てくれば話題の少ない言語と交代することになるでしょう
登場して20年以上経つ古い言語はもちろん対象外です

804 ：デフォルトの名無しさん：2022/09/16(金) 06:52:08.13 ID:fjE4y/uE.net

Rustを外せ（コッソリ

805 ：デフォルトの名無しさん：2022/09/16(金) 06:56:42.28 ID:3KsrPmkI.net

ここが隔離スレだろ

806 ：デフォルトの名無しさん：2022/09/16(金) 07:49:14.15 ID:9X7PH4Bp.net

Rustの話題はRustスレでいいだろ

807 ：デフォルトの名無しさん：2022/09/16(金) 07:52:17.18 ID:ATWJ//93.net

>>796
彼女が企画もののAVに出てそう

808 ：デフォルトの名無しさん：2022/09/16(金) 08:18:42.51 ID:g+vpwU6C.net

>>790
goは聞きかじりだけどもシングルスレッドのコードを気楽に拡張して同時実行にできることが売りに見える
erlangは最初から並列であることを求めてるから方向性が違う
どっちも強いは成り立つんじゃないかな

809 ：デフォルトの名無しさん：2022/09/16(金) 10:19:44.03 ID:0Y0F2QEG.net

お待たせしました(awesomeレス 1of3 ※)

Clojure StackOverflow >愛され言語ランキング上位　2つあるawesome-clojureがどちらもマメに更新されてる
　　　　CircleCIとかいくつかの実用サービスに使われてるのがすごい　「本物のREPL」(未確認)　LogSeq
　　　　Apple,CircleCI,Cisco,Cognitect,Nubank🏧,Walmart >使ってますが何か？ https://docs.google.com/spreadsheets/d/1jBQD-rzOeGeKgLjsQ21r4YfEHp8XOpB_vl6TGJEBj3g/edit#gid=0
Rust　　試食コーナーで食べてもらって狂喜乱舞
　　　　GAFAM >Rustエコシステムには投資しない トリクルダウン無し 寡占する　GAFAM >だが今は試食タイムだ
　　　　GAFAM >「あま〜〜い」ってさけんで食レポしてる😏みんな食べに来てね😛
　　　　StackOverflow >愛され言語ランキング1位
　　　　JetBrains >Rustで作らしてくれーと言ってるけど許可降りない
　　　　KENTA >提灯コメント出さない
　　　　俺 >数学出来ないのでRustはキツイ規制の鶴亀算が史上最強　鶴亀算でRustフレームワークが充実することなんて無い
　　　　Rust >鶴亀算だけなら俺が安全性や正しさを確実に保証 unsafe☢は関知しない お前の責任だ
　　　　俺 >今はRustだけで良い。レベルアップはお断りだ　数学出来ないけど有能社員を指導したいとは思ってる　すべての理解が概念的 概念的に理解すれば簡単だ
　　　　有能社員 >Rustは学習コストが高い割に使えない　C/C++を書けないとRustは書けない、Rustは意味なし
　　　　有能社員 >Rustは言語オタク 二極化だと思ってたらHaskell衰退の道を追う　Rustには興味のアンテナ張るだけ 先行投資なんてしない
　　　　現実派 >データ競合がコンパイル時点でゼロってことはない。JARO⚠案件だ
　　　　下っ端社員 >RustはGAFAMなんかより自動車ISO認証級(仮)の実績積み上げがないと、言い出すのも怖い😩
　　　　Rustは教官付き教習車だから、コンパイラの言うとおりに運転しないとブレーキ踏まれて前に進めない。
　　　　現実派 >具体的な話マダー？😡 >絶壁の学習曲線はRustの重大な問題 🆕

810 ：デフォルトの名無しさん：2022/09/16(金) 10:22:00.77 ID:RyrM8365.net

お待たせしました(awesomeレス 2of2 ※)

D　　　 C言語と同等に高速で安全も満たす言語　better C/C++の先駆者　breaking changeは日常茶飯事　awesome-d 老舗の割にマメ
OCaml　 関数型で速度を最優先するならこれ1択(or F#？)　StackOverflow >愛され言語ではない
F#　　　関数型最速はF#(実例根拠が待たれる)
Go　　　実稼働分野でバリバリ活躍中　GitHub PullReq >TypeScriptとGoが圧倒的
Scala　 実稼働分野でバリバリ活躍中　KENTA >日本では衰退しました　ScalaでのNetflix分岐点(未確認)
Nim 　　試食コーナーでスルーされて意気消沈　英語できないので言語マニュアルの日本語訳がスゴい
　　　　Pythonからの乗り換えに最適(未確認 Numpy使ってないPythonコードの高速化例が主？) 🆕
Pony　　開店前　awesome-ponyが2年以上更新されていない
　　　　参照の持ち方だけで6つもある(Reference Capability)　behaviorが終わるごとに該当アクターでGCを回す
　　　　湧く沸くRust >High-Performance Safe Actor Programming https://news.ycombinator.com/item?id=25957307 🆕
Haskell アカデミック勢が根強い　それ以外は衰退しました(未確認)
　　　　Tesla,Microsoft,Meta,GitHub,一流銀行🏧 >使ってますが何か？ https://serokell.io/blog/top-software-written-in-haskell
　　　　Tesla >We use Haskell to auto-generate C code that is compiled into vehicle🚗 firmware.
　　　　下っ端社員 >いい話だ。だが結局☪かよ
Julia　 科学技術方面開拓中　StackOverflow >愛され言語ランキング上位
FORTRAN 科学技術方面で強い、しばしば1択
COBOL　 金融機関方面では既存システムで根強い　それ以外は衰退しました

811 ：デフォルトの名無しさん：2022/09/16(金) 10:24:50.31 ID:bc2jlm7t.net

Lisp　　JavaScriptと変わらん ブランディングした先人たちのマーケティング能力が驚き
　　　　惑星探査機🛰とか特殊な用途、身近なところでルンバ🤖がLisp
　　　　Awesome Lisp Company https://github.com/azzamsa/awesome-lisp-companies
　　　　プロトタイプから本番に移行 柔軟に改修しやすい common lisp あとから型書いてパフォーマンスUp 🆕
　　　　思い出 >https://practical-scheme.net/trans/beating-the-averages-j.html >オジさん🧓は言語を変えない 🆕
C　　　 C言語がないぞ C言語がないぞ(大事なことだから2回) 🆕
php　　 原付 >静的型はブレーキ🛵 俺にブレーキはない 10年経って分かった <matz😚 🆕
欧米企業「最初のバージョンは常に捨てられる」 🆕
　　　　「アイデアは価値がない、アイデアを誰より早く形にして価値がある」 🆕
Jakt　　https://github.com/SerenityOS/jakt 🆕
　　　　Memory safety, Math safety, performance, transpiles to C++, Inline C++ 🆕
Zig　　 https://ziglang.org/(ja/) en >英語勉強しろ 話はそれからだ 🆕
Erlang　方向性が違う どっちも強い >お気楽Goはやっぱりつよいの？ 🆕
　　　　php >原付🛵より遅いぞ https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html 🆕

※ジョーク集です。「未確認」表示の有無に関わらず真偽を保証するものではありません。

812 ：デフォルトの名無しさん：2022/09/16(金) 10:25:11.62 ID:FmJF7Gxj.net

病気の人かな
書き込むなよ

813 ：デフォルトの名無しさん：2022/09/16(金) 14:24:20.93 ID:JbBUDOVI.net

>>jakt 追加は
Bounds checking, Sound null safety
try/catchは文
Dict Set TupleがPython並みに簡単 この辺はlife-time-analysysに頼らないでARCで実行時管理してるからかな

814 ：デフォルトの名無しさん：2022/09/16(金) 15:16:00.68 ID:5FcoWQIv.net

ARCメインの言語はいずれも遅いから興味ないな
とはいえZigの手動メモリ管理の面倒さと危険さは今の時代ニッチに終わるだろう

815 ：デフォルトの名無しさん：2022/09/16(金) 15:25:53.62 ID:EVJZN8ya.net

あっちのスレでやりなよ
こっちは隔離スレ

816 ：デフォルトの名無しさん：2022/09/16(金) 15:55:51.13 ID:lXNxdC5B.net

ﾜｯﾁｮｲスレのリンク見たら
Written on May 19, 2022 時点で >It’s two weeks old.
っていくらなんでもホヤホヤ過ぎでしょw

817 ：デフォルトの名無しさん：2022/09/16(金) 16:35:54.10 ID:5ihvg/eP.net

https://awesomekling.github.io/Memory-safety-for-SerenityOS/
には
>Q: Why ARC (automatic reference counting) instead of a borrow checker?
>ARC allows the language to feel lightweight without constantly asking the user to make decisions about memory management.

Jakt作者の考えは、Rustの方こそメモリ管理に絶え間ない気配りが必要で、自動のフリして実際にはプログラマーの負担、という事

これも具体的な話がない
>ARCメインの言語は「いずれも」遅い

Rustは都合の良い例だけ持ち出して「境界チェックは消える」とか言いがち

818 ：デフォルトの名無しさん：2022/09/16(金) 16:47:16.92 ID:74dom6Tp.net

スマポの時点で自動じゃないわなｗ
循環参照はWeak使ってなんとかしてくれっていうね
あとライフタイムにも参照の排他にも
全部頑張って気をつけないといけないのは書き手

メモリはGCに押しつけてしまうのがスッキリなのかもね
そっちはそっちで工夫してねっていう分離ができてる
nimなんかはそこを交換可能にしてて清々しいよね

819 ：デフォルトの名無しさん：2022/09/16(金) 17:31:52.57 ID:EVJZN8ya.net

メモリに気配りしたいからこそrustを使うのであってGCで良ければGC言語使えば良いよ

820 ：デフォルトの名無しさん：2022/09/16(金) 17:39:38.21 ID:hXa4CTix.net

>>819 == >>814 だろ

形勢が不利になって面倒くさくなった？

じゃなかったら「Zigの手動メモリ管理の面倒さ」-->「Rustは自動メモリ管理で簡単」
みたいな書き方を明示的に否定してくれ

そういうところがRustの胡散臭いところ

821 ：デフォルトの名無しさん：2022/09/16(金) 17:50:54.65 ID:5FcoWQIv.net

プログラマーに負担と責任を押し付けるZigは安全を軽視している

822 ：デフォルトの名無しさん：2022/09/16(金) 17:51:15.64 ID:rsr6X2sj.net

GC言語使いたいなら止めはしないけど
それならスクリプト言語使った方がマシだよ

823 ：デフォルトの名無しさん：2022/09/16(金) 17:54:38.33 ID:l9zi2+Dh.net

笑った >>819 == >>814 ==821==822 だろ 何回線目？
Zigの話じゃなくて、「Rustは嘘ついてました」って謝罪しろよ

824 ：デフォルトの名無しさん：2022/09/16(金) 18:01:54.76 ID:5FcoWQIv.net

ARC方式のSwiftはクソ遅い

825 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>818
嫁や彼女が援交やってそうだな。

826 ：デフォルトの名無しさん：[ここ壊れてます] .net

プロレス終わった？

827 ：デフォルトの名無しさん：2022/09/16(金) 18:28:16.66 ID:fQY5NM7R.net

GCはメモリ確保やコンパクションや解放をまとめてやりやすいからパフォーマンス出しやすい。
そのおかげでストップザワールドやGCスパイクも享受できる。
負荷を予測したい奴には向いてないかもな。
そういう意味ではGC言語はピーキーなんよ。
お前にはまだ早いかもしれん。

828 ：デフォルトの名無しさん：2022/09/16(金) 18:32:35.16 ID:fQY5NM7R.net

>>824
swiftは問答無用でretain,releaseもつくからじゃんよ

829 ：デフォルトの名無しさん：2022/09/16(金) 18:38:52.62 ID:9KGaiKu/.net

GCは〜って言って思考停止してるとRustでも使っているepochとか知らなそう

830 ：デフォルトの名無しさん：2022/09/16(金) 18:46:51.84 ID:RqiYn650.net

いずれGCがメモリレイアウトを動的に最適化したり必要に応じて確定的なメモリ解放を行うように動的にJITしたりするようになるから、究極的にはGCが勝利するだろうね

831 ：デフォルトの名無しさん：2022/09/16(金) 18:48:15.45 ID:j69kQS4p.net

Zigの良さがよくわからない
C言語より安全なのはわかるけどでもそれって結局Cでいいじゃんってなるよね
Rustみたいに静的メモリ安全は実現するのは端から諦めてC言語よりちょっと安全な言語を目指しているんだよね
本当にニッチって言葉が似合いすぎている
構文も無駄に複雑だし汚いし将来性ないと思う

832 ：デフォルトの名無しさん：2022/09/16(金) 18:49:54.01 ID:LN15iZX2.net

>>830
それ結構難しい話に聞こえるけど、具体的な進展があるの？

833 ：デフォルトの名無しさん：2022/09/16(金) 18:52:48.51 ID:LN15iZX2.net

>>831 ZigはBinary生成が優秀だから、依存dll/soとかクロスコンパイルとか。Rustでも使っているよ

834 ：デフォルトの名無しさん：2022/09/16(金) 18:59:55.32 ID:xvE1RXjk.net

Zigは構文が好きじゃない
わかりにくいよね

835 ：デフォルトの名無しさん：2022/09/16(金) 19:00:01.75 ID:EVJZN8ya.net

>>820
変なこと言ってる人と同一視するのは勘弁してくれ

836 ：デフォルトの名無しさん：2022/09/16(金) 19:04:06.25 ID:xvE1RXjk.net

>>820
そういう決めつけで妄想してると統合失調症になるよ

837 ：デフォルトの名無しさん：2022/09/16(金) 19:04:06.82 ID:LN15iZX2.net

Zigは作者が会社辞めて専念してるから、華々しくブレイクしなくてもずっと続けてくコミットがすごい
「安全性」は流行っているからリップサービス。マインドは常に実行速度。キレイなBinary。低レイヤー。
構文はちょこちょこ変わるイメージ。ときどき触るだけだけと直ぐに昔のがコンパイル通らなくなる。

838 ：デフォルトの名無しさん：2022/09/16(金) 19:13:49.58 ID:LN15iZX2.net

Faster than Cが自慢なのはぶっ飛んでるように聞こえるけど、一時期あったVは嘘だったけど、Zigはときどき本当。
LuaJitでもHaskellでもハマる処理では「簡単な記述で」Cより速いときがある。やってみないとわからない。

839 ：デフォルトの名無しさん：2022/09/16(金) 19:19:50.21 ID:LN15iZX2.net

構文なんて飾りですよ。狭い特定の処理がたまたま「簡単な記述で」書けるかどうかだけ。今はまだ時々実験するくらいで十分。深入りは先の話。

840 ：デフォルトの名無しさん：2022/09/16(金) 19:23:23.65 ID:HUefBg/J.net

Zigの時代ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!

841 ：デフォルトの名無しさん：2022/09/16(金) 19:24:40.95 ID:LN15iZX2.net

>>830 これ嘘大袈裟かな？w

842 ：デフォルトの名無しさん：2022/09/16(金) 19:25:42.72 ID:LN15iZX2.net

まいいや

843 ：デフォルトの名無しさん：2022/09/16(金) 19:35:28.83 ID:xvE1RXjk.net

>>830
それインクリメンタルコピーCGのことでは？

844 ：デフォルトの名無しさん：2022/09/16(金) 19:36:49.01 ID:xvE1RXjk.net

今のところZig使うならCで良いかな
使う気にはなれないな

845 ：デフォルトの名無しさん：2022/09/16(金) 19:54:10.89 ID:eTFy07in.net

ム板のゲハスレ

846 ：デフォルトの名無しさん：2022/09/16(金) 20:01:08.19 ID:0J+L4jjc.net

すみませんZigはまだβ、Nimはver1.6という事で....

>>818
>nimなんかはそこを交換可能

NimのGC/ORC/ARCは興味深いですね
https://nim-lang.org/blog/2020/12/08/introducing-orc.html

もっと選べるようだけど、循環参照などデータ構造別に切り替えて混在出来るのかな？
https://nim-lang.github.io/Nim/mm.html

>>843 上記のリストに入ってますか？

847 ：デフォルトの名無しさん：2022/09/16(金) 20:08:18.02 ID:0J+L4jjc.net

>>843 教えてください。検索すると30年位前の論文なんかも出てきて実現しているのかどうか、
それが>>830で言っているGCと一致しているのか、ちょっと理解が追いつきません....

848 ：デフォルトの名無しさん：2022/09/16(金) 20:23:30.89 ID:74dom6Tp.net

GCの研究が進んでよりよいものができるようになったとき
GC言語はそれをまんまと拝借できるから旨味あるよな

849 ：デフォルトの名無しさん：2022/09/16(金) 20:34:49.53 ID:0J+L4jjc.net

>>848 そうなんです。
ただ >>843の「incremental copy garbage collector」が30年以上まえから未だに研究されているのは検索すればすぐにわかるのですが、
nimで選べるくらいの実用段階なのか、更には>>830で言っている ものと一致しているのか、 重要ですよね。
30年以上の研究なんて逆に絵に描いた餅に思えたりするので。

850 ：デフォルトの名無しさん：2022/09/16(金) 20:51:30.89 ID:paysycNa.net

GC活用するだけじゃなくて、スタックフレームからエスケープしにくくする仕組みがあると面白いと思うけどね。

Rustほどガチガチだとだるいから、エスケープをコントロールするスマポみたいなクラスを用意するとか。

851 ：デフォルトの名無しさん：2022/09/16(金) 21:07:42.67 ID:8k9s5Jiv.net

GC以外だと、JVMや. NetなんかのVMも結構に改善してるんじゃない？

852 ：デフォルトの名無しさん：2022/09/16(金) 21:21:31.00 ID:74dom6Tp.net

GCもVMもどんどん改善してくれたまへ
JavaでHotSpotだのJITだの言い出したころワクワク感あったな
プログラマはプラットフォームに対してでなくて
これからはGCやVMに対してプログラミングをするだけでよくて
さらにGCやVMは誰かのおかげで勝手に改善されていくらしいという

853 ：デフォルトの名無しさん：2022/09/16(金) 21:27:14.70 ID:z5XcLMe6.net

http://www.kmonos.net/alang/d/garbage.html

ガベージコレクトされたプログラムの方が高速です。 これは直感に反するかもしれませんが、その理由は：

明示的なメモリ管理の際によく使われる手法は、参照カウントです。 代入があるたびにカウントを増やしたり減らしたリソースを挿入するのは、 速度低下の原因になっています。スマートポインタクラスでラップしても、 速度的な解決にはなりません。
(またいずれにせよ、 循環参照を削除できない参照カウント方式は、 一般的な解決策ではありません。)

オブジェクトによって獲得されたリソースの解放には、 デストラクタが使用されます。多くのクラスでは、このリソースとは 割り当てられたメモリのことです。
GCを使えば、 ほとんどのデストラクタが空になり、完全に削除してしまえます。

メモリ管理のためのデストラクタは、 オブジェクトがスタックに置かれたときに影響が顕著になります。
例外が発生したときに、全てのスタックフレームでデストラクタが呼び出され、 メモリを解放するような仕組みが必要となるのです。 もしデストラクタが関係しなければ、例外を処理する特別なスタックフレームを 設定する必要がなくなり、コードは高速に実行されます。

メモリ管理に必要なコードは全てを合わせるとちょっとした量になります。 大きなプログラムになるほど、キャッシュに入らない部分が増え、 ページングが多く発生し、 プログラムが遅くなります。

GCは、メモリが残り少なくなってきたときのみ実行されます。 メモリに余裕があれば、プログラムは全速力で実行され、 メモリ解放に一切時間を取られません。

モダンなGCは、過去の遅いものより遙かに発展しています。 世代型のコピーGCには、 昔のマーク＆スイープアルゴリズムの非効率さはありません。

モダンなGCはヒープの詰め直しを行います。 これによってプログラムが活発に参照するページの数を減らし、 キャッシュヒット率を高め、 スワップ回数が減ります。

GCを使うプログラムは、メモリリークの積み重ねで次第にパフォーマンスが悪化、 という事態に縁がありません。

854 ：デフォルトの名無しさん：2022/09/16(金) 21:34:12.96 ID:W9x6+yw/.net

>>830
どちらもJVMで実現済みのことに思えるが…。

メモリレイアウトの最適化
→ 世代別GC(長寿命なオブジェクトは頻繁にGCしない領域に移動する)

確定的なメモリはJITで開放
→ エスケープ解析(短命でスタックに乗せても構わないオブジェクトはスタックに乗せる)

855 ：デフォルトの名無しさん：2022/09/16(金) 21:36:23.95 ID:9X7PH4Bp.net

deno=Rust
bun=zig


https://res.cloudinary.com/practicaldev/image/fetch/s--HAhtlbw8--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/oi6yfxenbfcuhlrkl6j7.png

856 ：デフォルトの名無しさん：2022/09/16(金) 21:39:12.85 ID:paysycNa.net

>>853
近現代の言語だと例外は飛び抜けて重い機能だよな。c++使うときも自分から例外を使うこと無いし。
例外みたいなエラーフローあると便利なことあるんかね？

857 ：デフォルトの名無しさん：2022/09/16(金) 21:39:55.16 ID:W9x6+yw/.net

>>855
それも言語の良し悪しよりもbanがやるべきことをやってないだけだったり、nodeが本質的には不必要なことをやりすぎているだけっぽいと思うんだよな。

858 ：デフォルトの名無しさん：2022/09/16(金) 21:44:51.39 ID:PbYmvI2Z.net

>>854 等号の左右、ずいぶん曲解しましたね。

859 ：デフォルトの名無しさん：2022/09/16(金) 21:45:22.11 ID:lW11Z1GI.net

GC言語、メモリを山のように積んでるマシンだと走りきるまでGC走らなかったりするしな。
mallocしてfreeしないアプリみたいなもんで、ケースによってはそりゃ速い。

860 ：デフォルトの名無しさん：2022/09/16(金) 21:55:33.67 ID:9X7PH4Bp.net

>>857
そうなんだね

861 ：デフォルトの名無しさん：2022/09/16(金) 22:04:21.30 ID:N1Gu8JHK.net

>>857
要約すると、RustはZigに比べて本質的には不必要なことをやりすぎている、という事でOK

862 ：デフォルトの名無しさん：2022/09/16(金) 22:10:48.13 ID:oJjxTP0V.net

Rust「zero overhead abstraction」は嘘でした

863 ：デフォルトの名無しさん：2022/09/16(金) 22:15:51.87 ID:8FnpT4Fe.net

>>856
C++使ってないな。C#ユーザー

864 ：デフォルトの名無しさん：2022/09/16(金) 22:19:05.45 ID:EVJZN8ya.net

>>853
この文章10年以上前からあるけど今でも成り立つのだろうか

確かにメモリ解放を遅延させることによって実行命令数がGCの方が少なくなる場合はあると思う
一方でいくつかのmalloc実装がやっているような、直近にfreeされた領域を優先的に再割り当てするようなことは、GCが走らない限り、つまり、メモリを使い切るまではできない
freeされた領域はキャッシュに載っていて高速にアクセスできる可能性が高いので、直近にfreeされた領域を使い回すことはキャッシュヒット率を高める効果がある
GC言語は命令数は少なかったとしても、メモリのアクセスレイテンシの影響をより多く受け、トータルでは遅かったりしないだろうか

この文章の元ネタのベンチマークがあるなら現在のマシンで比較してみたら面白そう

865 ：デフォルトの名無しさん：2022/09/16(金) 22:26:31.57 ID:EVJZN8ya.net

>>861
アプリの実装の善し悪しの話と実装言語の善し悪しを意図的に混同させるのはよくないよ

866 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>865 Chrome by C++の場合について聞かせて

867 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>864
それソースある？
必ず再利用するにあたって領域を書き換えてんだから、直前にfreeしたかどうかに関わらず書き換え直後にキャッシュに乗るのは当たり前じゃないの？
チープな環境でスワップインを回避する効果はあるかもしれんが

868 ：デフォルトの名無しさん：2022/09/16(金) 22:47:07.20 ID:W9x6+yw/.net

>>858
曲解してるかなとは我ながら思った。
けど、GCが勝つというほどインパクトある伸び代が挙げられた項目にこれ以上あると感じないんだよね。

869 ：デフォルトの名無しさん：2022/09/16(金) 22:47:38.62 ID:aq1cgc5a.net

>>876 スワップインて。。>>864はまっとうな意見だと思うよ。

870 ：デフォルトの名無しさん：2022/09/16(金) 22:54:48.64 ID:aq1cgc5a.net

>>868
>GCが勝つという
そんな場合もある、程度では。

GraalVMでNativeにした場合で
Native Java(+GC) vs Native other(no GC)は気になる

871 ：デフォルトの名無しさん：2022/09/16(金) 23:06:36.63 ID:yQqW5GbJ.net

escapeするかしないか、静的と動的でそんなに違うもんかね。
むしろエラー以外はescapeする・しないは静的で相当範囲カバー出来てそう。データはないけど。

872 ：デフォルトの名無しさん：2022/09/16(金) 23:12:50.46 ID:lW11Z1GI.net

>>864
これはそう。ただ投機的実行(と昨今のその去勢)とかを考えると結構難しいかなとは。

873 ：デフォルトの名無しさん：2022/09/16(金) 23:22:07.28 ID:rsr6X2sj.net

GCを止めたら速いという話は藁人形論法なのでやめませんか？

874 ：デフォルトの名無しさん：2022/09/16(金) 23:25:00.60 ID:lW11Z1GI.net

どこが藁人形なの？

875 ：デフォルトの名無しさん：2022/09/16(金) 23:26:02.22 ID:3cBZTpx6.net

>>872 vulnerability詳しくないけど、mitigationでfree->mallocがどの程度影響するのか気になるな。

876 ：デフォルトの名無しさん：2022/09/16(金) 23:34:42.72 ID:ATWJ//93.net

>>853
＞GCを使うプログラムは、メモリリークの積み重ねで次第にパフォーマンスが悪化、 という事態に縁がありません。

嘘言うな

877 ：デフォルトの名無しさん：2022/09/16(金) 23:42:23.80 ID:n2V9aTfB.net

GCは解放の実タイミングは調整するけど「メモリリーク」とは見なしてないのでは。

むしろ Rust「メモリリークはメモリ安全性保障の範囲外」 の方なんとかして

878 ：デフォルトの名無しさん：2022/09/16(金) 23:44:19.41 ID:EVJZN8ya.net

>>867
GCはそもそもfreeから再利用まで間が開くのでその間にキャッシュから外れる可能性が高くなるし、
再利用に当たって領域を書き換えるなら、キャッシュに載ってない場合書き換え処理に時間がかかるのでは
スワップインはよくわからない

879 ：デフォルトの名無しさん：2022/09/16(金) 23:45:28.20 ID:EVJZN8ya.net

>>877
メモリリークを静的に検知するのはプログラムに対する制限が相当大きくなってしまうのでは

880 ：デフォルトの名無しさん：2022/09/16(金) 23:53:17.42 ID:MTo4LOAu.net

>>879 動的にでも検知する仕組み/試みがあったりするのかな。テスト、プロファイル、そりゃあるかな。

881 ：デフォルトの名無しさん：2022/09/17(土) 00:04:48.75 ID:Qv9rB708.net

>>880
valgrindとかAddressSanitizerとかmallocをhookするやつとかいろいろあるよ

882 ：デフォルトの名無しさん：2022/09/17(土) 00:05:17.29 ID:guSBFHBz.net

GCはいわばメモリ管理の専門家に幅広い裁量を持たせて仕事させているわけで、
それに比べるとアプリケーションコード内でのメモリ管理はCenter of Excellence的な意味では原理的にどうしても不利よね
メモリ管理の専門家が十分な裁量を持って仕事できるのはせいぜいアロケータの実装くらいで、ほかは高水準のプログラミングモデルやプログラマの能力の制約を強く受けることになる

883 ：デフォルトの名無しさん：2022/09/17(土) 00:13:57.81 ID:WaM/gYIx.net

Javaは実行時最適化によりRustの3倍速い。

884 ：デフォルトの名無しさん：2022/09/17(土) 00:21:14.46 ID:Qv9rB708.net

>>883
(場合もある)

885 ：デフォルトの名無しさん：2022/09/17(土) 00:44:08.92 ID:wgXFenVD.net

スパイクの出ないGC出たら即乗り換える予定

886 ：デフォルトの名無しさん：2022/09/17(土) 01:02:29.41 ID:HP4MaZ5C.net

それ以来30年間GC技術が進んだ結果の現状が既出のこれ

>>200
>> https://pbs.twimg.com/media/EmYvG8aVkAMdfFG.jpg

全く対等に同条件で多くの人々が同じ問題に対して様々な言語で記述した結果の各実行時間
速く実行できた言語はRustとCとC++の3つでいずれもGCなし
GCする言語は軒並み遅い
一部をGC対象とならないよう回避の努力をしているGoがGC言語の中で最も速い
そうでない普通のGC言語は遅すぎる

887 ：デフォルトの名無しさん：2022/09/17(土) 01:35:11.26 ID:Qv9rB708.net

>>886
これってGC性能が支配的になる問題なの？

888 ：デフォルトの名無しさん：2022/09/17(土) 01:41:35.46 ID:wgXFenVD.net

pythonさん

889 ：デフォルトの名無しさん：2022/09/17(土) 01:47:29.96 ID:5sn184WB.net

>>887
(1) GCが発生している場合
　　→ GC性能が改善された現在でもGC言語は遅い

(2) GCが発生していない場合
　　→ GC性能と関係なくGCが起きない段階でもGC言語は遅い

どちらのケースであってもGC言語はダメな存在になってしまいますね

890 ：デフォルトの名無しさん：[ここ壊れてます] .net

あれ、D言語はかなり早いイメージだったけど、Goに負けることもあるのか

891 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>884
無いよ（笑

892 ：デフォルトの名無しさん：[ここ壊れてます] .net

LDCじゃなくてGDC使ってんのかな

893 ：デフォルトの名無しさん：[ここ壊れてます] .net

Goは速いよ。

アンチGCはGC言語じゃなければ速い、と思い込みすぎでは？

ミッション車みたいなもんで、自分の設計力の無さがパフォーマンス劣化に直結するというか、いわゆるベンチのスペックは素直には出ないよ。
Rustアンチじゃないけど、これはRustの目的でもない(あくまで安全が目的)

GC言語みたいにだれでも80点が取れます、エンストしませんよ、みたいなもんじゃないんよ。

コンパイラが叱ってくれるからハイパフォーマンスとか、書いてて言ってんのかほんとに謎。

894 ：デフォルトの名無しさん：[ここ壊れてます] .net

ゲハでやれ

895 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>886
そいつの読み方は「C＋＋とPyPy3圧倒的じゃないか」ですよ。
新参者から熟練者まで数と質すべてが圧倒的。
C++は熟練すると、黒魔術を含め、やりたいことが全てできる言語なので、突き詰めていく性質の企業におすすめ。
逆に、手数で勝負の乱打スタイル企業には、PythonやRoRがお勧め。

896 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>893
Javaも速いですよ。
Rustの3倍は冗談だけど。
欠点はメモリーを使いすぎること。
一般的なパソコンはメモリーが少し足りない。
だから、Javaは遅いと思われてる。
ミスマッチです。

897 ：デフォルトの名無しさん：[ここ壊れてます] .net

ハードウェアを売りたい言語だから、ハードウェアに対する要求が少し厳しかったですね。

898 ：デフォルトの名無しさん：2022/09/17(土) 02:25:11.61 ID:YHpfxvp6.net

>>886
やはりGCの言語はいずれも遅いな
GCのせいで遅くなるのではなく
ヒープでメモリ確保するからGCの言語は遅くなる

899 ：デフォルトの名無しさん：2022/09/17(土) 03:31:52.64 ID:5J0Fty65.net

>>896
Java速いよね。あんまり適切なXmx知られてないだけだと思う。

>>898
少なくとも知ってる範囲だとGoもc#も取れるときはスタックを確保するぞ。

900 ：デフォルトの名無しさん：2022/09/17(土) 03:42:09.24 ID:o0T2dyfd.net

>>899
Javaは遅いです
どのベンチマークでもC/C++/Rustの2倍～数倍はJavaが遅いです
>>886の例でもJavaは数倍遅くなっています

901 ：デフォルトの名無しさん：2022/09/17(土) 03:53:04.00 ID:5J0Fty65.net

>>900
abc 182-eはakariって問題なんだけど、読んだ？
Javaで雑に書くとパフォーマンスでない類の問題だよ。

このグラフは言語オタ勢には有名かと思ってたけど、ベンチマークのグラフではなくて、あくまで競技者が書いた言語毎の統計のグラフなので、ポンコツが多ければそれが表現される。
言語人口が多いものの箱ひげが偉いことになってるでしょ。

902 ：デフォルトの名無しさん：2022/09/17(土) 04:54:39.17 ID:1eeK5YMC.net

>>901
なるほど
しかしJavaで書いて最も速くできた人でも遅くて
Rustで書いた平均的な人たちにすら負けているな>>886
どんなに優れた人であってもJavaを使った時点で遅いと確定してしまうのは辛いな

903 ：デフォルトの名無しさん：2022/09/17(土) 07:28:28.63 ID:8assD4qG.net

>>877
これ訳わからんよね。
そこまでして「GC不要でメモリ安全」を売りにしたかったのか、と思うわ。
c++とかだとメモリリークも普通にバグ扱いされるのに、それを「メモリ安全」と言い切るのは詐欺臭い。

904 ：デフォルトの名無しさん：2022/09/17(土) 07:39:14.89 ID:8assD4qG.net

>>902
そもそもRust使える人間は他の言語に詳しい人間しか居ないだろ。

他の言語に詳しく無い人間がRustの絶壁の学習曲線をクリアできるとは思えん。
「Rustしか使えません」なんて人間は存在するのかね？

905 ：デフォルトの名無しさん：2022/09/17(土) 07:46:13.48 ID:TM5e0HO7.net

>>903
それは常識
一般的に循環参照の安全な解放を静的に記述したり静的にチェックすることは不可能
デッドロックも同じで静的に発生をチェックして防止することは不可能
だからコンパイラ(＝静的にチェックする存在)がそれらを防ぐことは対象外となる

906 ：デフォルトの名無しさん：2022/09/17(土) 07:50:22.53 ID:XDvVGFlj.net

>>904
バカは遅い言語や危険な言語を使い続ければよい
時代の要請は高速で安全でプログラミング効率の良い言語でありそれはRust
使えないバカがついていけずに切り捨てられていくことは業界にとっても朗報だ

907 ：デフォルトの名無しさん：2022/09/17(土) 08:47:42.31 ID:+hLuAY/P.net

早い言語は適当に書いても2秒の時間制限に間に合うけど
遅い言語は問題の想定解法じゃないと通らないから結果的に早い言語は上髭多くなるだけ

908 ：デフォルトの名無しさん：2022/09/17(土) 09:18:54.40 ID:vRd8nzJr.net

>>902
execution timeの単位はミリ秒だぞ
ベンチヲタは気にするが1000000回ループして1秒か2秒しか差がつかないのに現実的に問題になることってないぞw
現実のループは多くてもせいぜい1000回程度だろ

909 ：デフォルトの名無しさん：2022/09/17(土) 09:57:15.90 ID:BhE3E6/v.net

>>908
あんたには遅くてダメな言語で十分なのだから他を気にせず不満を持たずそのままでいいじゃないか
あんたには無縁だが世の中には速くて安全で保守性も良い言語が求められているだけの話だ

910 ：デフォルトの名無しさん：2022/09/17(土) 10:21:27.92 ID:ktSmkMDB.net

Rustの他の言語と比べた速度向上って、俺にじゃなく世のほとんどのプロジェクトにとって五十歩百歩の微々たるものなんですわw

911 ：デフォルトの名無しさん：2022/09/17(土) 10:29:26.87 ID:KEhwIc0k.net

前に、rustでtsc実装した人、さらにgoで作り直すって、理由がrustには向いてないからって。翻訳記事だからニュアンス違うのかもしれないけれど。

912 ：デフォルトの名無しさん：2022/09/17(土) 10:29:40.60 ID:8assD4qG.net

>>905
プログラマサイドにそんな「常識」は無い。プログラマ視点なら「メモリリークはバグ。メモリを圧迫してトラブルになる危険がある」の方が常識。Rust関係者はそういうことを説明の奥の方に隠して「メモリ安全」とか誇大広告するから詐欺だと指摘しているわけで。

常識とかけ離れた俺俺定義を使うならちゃんと注意書きしろよ。
「メモリ安全*」
*メモリリークを除きます。
みたいに。

913 ：デフォルトの名無しさん：2022/09/17(土) 10:35:04.81 ID:xfq0iQEs.net

Amazonの>>9の記事にもあるけど
Rustへ書き換えるだけだけでリソースコストや電気代それに伴うCo2排出量などが少なくとも50%は削減できる
さらにセキュリティの要請から安全性も求められている
土方でないまもともなプログラマーならばJavaでもRustでも他の言語でもプログラミングに支障なく書ける
それらの状況から選ぶべき言語がRust一択になっているだけでしょう

914 ：デフォルトの名無しさん：2022/09/17(土) 10:39:04.61 ID:ktSmkMDB.net

https://stackoverflow.com/questions/55553048/is-it-possible-to-cause-a-memory-leak-in-rust
> Is it possible to cause a memory leak in Rust?
> You can also leak memory if you create a cycle of shared references:
> You can also use Box::leak to create a static reference, or Box::into_raw in an FFI situation.
> You might've forgotten about Box::leak and Box::into_raw which are pretty common in ffi situations for passing around states.

https://doc.rust-lang.org/book/ch15-06-reference-cycles.html#reference-cycles-can-leak-memory
> Reference Cycles Can Leak Memory

915 ：デフォルトの名無しさん：2022/09/17(土) 10:46:39.42 ID:vRd8nzJr.net

RustでなくVBAを使うことでエネルギー削減になることもあるな

916 ：デフォルトの名無しさん：2022/09/17(土) 10:55:22.36 ID:8assD4qG.net

>>913
Rustを学習した人間の感想の多くが「Rustは難解」と言っているのに、「まともなプログラマなら支障なく書ける」とする根拠は？
根拠が個人の感想なら、「まともなドライバーならマニュアル車を支障なく運転できる」と言うくらい傲慢だと思うがね。

917 ：デフォルトの名無しさん：2022/09/17(土) 10:55:41.70 ID:gI44iNXP.net

>>912
それはちょっと知識不足じゃないかしら
もし循環参照を作っちゃった場合はそれを安全に解放する局所的な方法は理論的に存在しないんですよ
GCでも局所的に解決できる参照カウント方式では循環参照を解放できないため
GCの中でも全体のマークスイープ方式や全体の使用中分コピー方式でようやく解放されます
そららは非常にコストが重いだけでなく発動までに時差もあります

したがってプログラミング言語界ではそんなコストがかかるものに依存するのではなく
最初から循環参照を作らない方向で進んでいます
そのため最近は多くの言語で弱参照がサポートされており循環参照の発生を防ぐことができます

今回の話のJavaでももちろん弱参照が用意されていて最初から循環参照を作らないようにプログラミングします
そのほうが有利だからです

918 ：デフォルトの名無しさん：2022/09/17(土) 11:04:35.77 ID:ktSmkMDB.net

>>917
C#では参照はツリーで管理されるから循環参照も問題なく一瞬で開放される

919 ：デフォルトの名無しさん：2022/09/17(土) 11:12:08.51 ID:/Lpl+zOG.net

>>917
Wikipediaですら「メモリ安全性」の解説でメモリリークをメモリエラーとしているのに、実装側の都合で一般に使われている用語の意味をひん曲げて「常識」とな？

そういうのが詐欺だと指摘しているだけだけどなぁ。

今度からちゃんと
「メモリ安全*」
*メモリリークを除きます。
と注釈付けろよ。

920 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>918
それはC#でもJavaでもRustでも他の言語でも全て同じ方法です
どの言語も弱参照を併用して参照はツリー状のみにすることで循環参照の発生を防ぎます
もちろんそこには弱参照による弱い循環参照がありますが通常の参照はツリー状なので
おっしゃる通りに一瞬で解放することが可能です

921 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>919
wikipediaのメモリ安全性のメモリリークで挙げられてる項目は循環参照によるリークは含まれてないっぽいが
https://ja.m.wikipedia.org/wiki/%E3%83%A1%E3%83%A2%E3%83%AA%E5%AE%89%E5%85%A8%E6%80%A7

922 ：デフォルトの名無しさん：[ここ壊れてます] .net

ところで所有権は複製されるってことでいいの？

923 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>921
リンク先にある「メモリリーク」の項ぐらい読めよ。

924 ：デフォルトの名無しさん：[ここ壊れてます] .net

今時循環参照くらいでメモリリークするような言語でよく安全を名乗れたもんだ
退化してるやん

925 ：デフォルトの名無しさん：2022/09/17(土) 11:39:26.07 ID:/MEkW9dR.net

昔は保守的GCというGCに人気があった
本当はゴミなのにゴミではないと判断することはバグではなく安全、という注釈つきのGCだった

この注釈は嘘だったという見方の方が今は優勢

926 ：デフォルトの名無しさん：2022/09/17(土) 11:42:22.70 ID:yVMylSLT.net

予想される次の手：
・循環参照の矮小化
　循環参照なんてめったに起こらないし
　普通に書いてたら発生しようがない
・問題の転嫁
　循環参照なんて書くほうが悪い
　循環参照によるメモリリークなんかを問題視するほうが悪い
・飛躍した結論
　とにかくRustは素晴らしい

927 ：デフォルトの名無しさん：2022/09/17(土) 11:43:45.86 ID:5J0Fty65.net

>>902
「この設問は」ね。だから競プロは複数言語できると面白い。

928 ：デフォルトの名無しさん：2022/09/17(土) 11:45:32.10 ID:bMZyj00L.net

今は強い循環参照を作ってしまったら負けの世界
Pythonですら強い循環参照を避けるために弱参照が用意されていて回避できる
もちろんC#やJavaにKotlinやSwiftにも弱参照が当然あって回避できる
Rustなどのように強い循環参照が自然には発生しない言語仕様だと更に良い

929 ：デフォルトの名無しさん：2022/09/17(土) 11:46:24.15 ID:w5Ud45eS.net

メモリ安全とは何なのがまとまってるページとかは作れないんだろうか

930 ：デフォルトの名無しさん：2022/09/17(土) 11:48:55.60 ID:5J0Fty65.net

>>925
Bohemとかもそうだっけ？

循環参照に関しては、確かにメモリリークだけど、危険ではないんでは？
Dangling pointerにならんかったら良いんじゃ無いかなあ。

循環参照で放置されているものの解放に時間がかかっても、別に問題ないと思うんだけどな。メモリに極端な制約がある環境下でなければ。

最初から循環参照を作らないというのは一つなんだけど、そういうわけにもいかんのよ。
最近書いたけど、グラフなオブジェクトなんかは循環参照するじゃん。

931 ：デフォルトの名無しさん：2022/09/17(土) 11:49:36.37 ID:5J0Fty65.net

>>929
Rustの話ならこれかな？
https://doc.rust-jp.rs/rust-nomicon-ja/meet-safe-and-unsafe.html

932 ：デフォルトの名無しさん：2022/09/17(土) 11:57:30.35 ID:w5Ud45eS.net

ようやくわかってきたよ
C 言語 に大量にある 未定義な挙動が ないことをsafeって言ってんのか
ならメモリリークっていう現象事態はたしかにsafeだ

933 ：デフォルトの名無しさん：2022/09/17(土) 12:01:39.81 ID:Qv9rB708.net

>>923
単にメモリリークと言ったら含まれるけど、
メモリ安全性に関わるメモリリークの文脈では循環参照は言及されてなさそうなんだよね
メモリ安全性という言葉の定義だけの問題で、実用上問題になるという点ではよろしくないとは思うけど

934 ：デフォルトの名無しさん：2022/09/17(土) 12:02:36.48 ID:rp+oVngt.net

循環参照はコールバック等で普通に発生する
トレーシングGCでは全く何の問題にもならないから弱参照なんか使わんよ

935 ：デフォルトの名無しさん：2022/09/17(土) 12:05:32.37 ID:w5Ud45eS.net

ttps://doc.rust-jp.rs/book-ja/ch15-06-reference-cycles.html
循環参照は、メモリをリークすることもある

ここか
なるほど

936 ：デフォルトの名無しさん：2022/09/17(土) 12:06:42.34 ID:ktSmkMDB.net

>>928
強い弱いの意味がわかってなくて草

937 ：デフォルトの名無しさん：2022/09/17(土) 12:07:05.26 ID:8assD4qG.net

>>931
今まである「メモリ安全性」の常識を無視して『メモリ安全性』という言葉を使わなきゃいいんだけどねぇ。
「プログラムの安全性にこだわった」くらいの宣伝ならまだわかる。

Rustはわざわざ「メモリ安全性」という言葉を使って宣伝しているんだからダメだろ。

938 ：デフォルトの名無しさん：2022/09/17(土) 12:24:51.56 ID:J+gZaL34.net

確定的なタイミングでトレーシングGCしてくれるようなスマートポインタって実現不可能なの？

939 ：デフォルトの名無しさん：2022/09/17(土) 12:27:39.54 ID:bwIIEGYu.net

勘違いしてる人がいるようなので正しい知識をまとめておきます

C++やRustのような非GC言語やリファレンスカウント方式のGC言語では(強い)循環参照の解放は原理的に不可能です
これらの言語ではデッドロック等と同様に(強い)循環参照は発生させてはいけない禁忌として扱われ発生自体を避けます
対処方法としては弱い参照を用いた弱い循環参照を用いるのが主流ですが
プログラムが自分で管理する範囲内で循環参照を作ってまとめて解放したり範囲内GCなどを用いる方式もあります

マーク＆スイープ方式やコピー方式のGC言語ならば(強い)循環参照も解放することができます
ただしそれらの方式は全体空間を全てマークしたり辿ったりコピーしたりとコストが重いことの裏返しでもあります
さらにGCが起こるまで無駄にメモリを専有してしまう問題もあります
そのためこれらの方式のGC言語でも弱参照が用意されて(強い)循環参照を作らないようにすることが一般化しつつあります

940 ：デフォルトの名無しさん：2022/09/17(土) 12:35:09.02 ID:w5Ud45eS.net

>>939
ちなみに誰が勘違いしてんの？

941 ：デフォルトの名無しさん：2022/09/17(土) 12:37:10.60 ID:8assD4qG.net

>>940
>>939

942 ：デフォルトの名無しさん：2022/09/17(土) 12:39:43.66 ID:vRd8nzJr.net

>>939
ちょっと本垢でQiitaにでも書いてくれマサカリ投げに行くから

943 ：デフォルトの名無しさん：2022/09/17(土) 13:12:35.27 ID:5J0Fty65.net

>>937
Rustのメモリ安全性、というのを先に定義しとるからなぁ。
そこはまぁ定義次第なのはその通りだと思う。

944 ：デフォルトの名無しさん：2022/09/17(土) 13:18:40.25 ID:Ct2ljdlf.net

>>938
無理だよ
だから各言語は現実的な対応をとってる
例えばC++のshared_ptrでも循環参照を起こしたらメモリ解放できない
回避策は強い循環参照を作らないようにweak_ptrを使う
Rustでは意図的に頑張らない限り循環参照が勝手に作られることはないけど
同様に参照をWeakにできるからメモリ解放可能な弱参照を用いた循環参照にして扱う
これはARC方式のSwiftでも同様で循環参照を起こしたらメモリ解放できない
Swiftでもweak宣言で弱参照にできるので解放できない循環参照を避けられる
いずれの言語もほぼ同じ仕組み

945 ：デフォルトの名無しさん：2022/09/17(土) 13:55:15.51 ID:Dua3tl/G.net

>>944 >Rustでは意図的に頑張らない限り循環参照が勝手に作られることはない
よくわからないので聞くけど、
Rustでは意図的に頑張れば、Weakにせずに循環参照データ構造を定義してzeroじゃない実データ構築をするコードがコンパイル通るの？

946 ：デフォルトの名無しさん：2022/09/17(土) 13:59:18.77 ID:8assD4qG.net

>>943
ならトップページに「Rustにおけるメモリ安全性」として「*メモリリークは除く」くらいはやらないと優良誤認だろ。

947 ：デフォルトの名無しさん：2022/09/17(土) 14:14:04.83 ID:Qv9rB708.net

>>945
https://doc.rust-jp.rs/book-ja/ch15-06-reference-cycles.html

948 ：デフォルトの名無しさん：2022/09/17(土) 14:16:59.16 ID:Dua3tl/G.net

>>947 ありがとう

949 ：デフォルトの名無しさん：2022/09/17(土) 14:26:47.74 ID:Dua3tl/G.net

>>945

https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=0d4932743de9a2d3f91b215fe3a4757b

>最後のprintln!のコメントを外してプログラムを実行したら、aがbを指して、bがaを指してと、 スタックがオーバーフローするまでコンパイラはこの循環を出力しようとするでしょう。

確かに
thread 'main' has overflowed its stack
fatal runtime error: stack overflow
timeout: the monitored command dumped core

950 ：デフォルトの名無しさん：2022/09/17(土) 14:30:22.04 ID:Qv9rB708.net

>>937
循環参照によるリークを含むようにメモリ安全性を定義してる文献ってある？

Wikipediaの定義ではメモリリークという分類はあるけど、
"メモリ使用量が追跡されていない又は誤って追跡されている場合"
と説明されていて、前者は当てはまらないし、後者はダングリングポインタなどを意図しているようで、循環参照は含まないように読める

SwiftやChromeやAOSPやDのメモリ安全性に関するドキュメントでもメモリリークについては触れられていないようだった

951 ：デフォルトの名無しさん：2022/09/17(土) 14:33:34.46 ID:Dua3tl/G.net

>>949
[BUILD]にしてみたが「循環しるよ」的なwarningはないのね

952 ：デフォルトの名無しさん：2022/09/17(土) 14:37:56.61 ID:Dua3tl/G.net

>>951
>>944 >Rustでは意図的に頑張らない限り循環参照が勝手に作られることはない
warningがないし、当該データの使い方次第で実行時エラーにもならないので
意図しなくても、「偶発的に」循環参照が作られることはありそうだ。

953 ：デフォルトの名無しさん：2022/09/17(土) 14:42:00.12 ID:Dua3tl/G.net

潜伏した循環参照が後々深刻な事態になるかどうかは別の話だが
Rustだからと言って、コンパイル通ったからと言って、油断は禁物で

954 ：デフォルトの名無しさん：2022/09/17(土) 14:43:28.60 ID:Dua3tl/G.net

「常識」でしょw

955 ：デフォルトの名無しさん：2022/09/17(土) 14:44:11.19 ID:EEEbWrXO.net

>>937
> 今まである「メモリ安全性」の常識
お前の脳内の話じゃないなら具体的にどういう事なのか示してみそ

956 ：デフォルトの名無しさん：2022/09/17(土) 15:27:41.65 ID:lGXhfZzC.net

すげーくだらないことで盛り上がってんなw
さすが次世代w言語wwスレwww

957 ：デフォルトの名無しさん：2022/09/17(土) 15:28:08.55 ID:5J0Fty65.net

メモリリークだけでは安全性には差し障らんでしょ。一般的に。
スタック、ヒープが枯渇することはメモリ安全性に差し障るけど。

リークしてるけど走りきった、とか、GCがまとめて解放した、はセーフだと思うよ。

958 ：デフォルトの名無しさん：2022/09/17(土) 15:58:19.63 ID:8assD4qG.net

>>950
そんなことよりもまず
「メモリ安全性は(プログラムによる)メモリエラーを許容するのか、しないのか」
はどちらだと思うのか考えてもらいたいね。Rustは「メモリエラーが発生するけどRustはメモリ安全」て言っている。
>>955も同じな。お前もRustみたいに断言するのかね。

まぁ、「c++よりもメモリ安全」というならまだ正確だが、それならそうと正直に言うべきだと思うがね。俺俺メモリ安全をwebページの奥の方に置かないで。

959 ：デフォルトの名無しさん：2022/09/17(土) 16:03:03.55 ID:37/3YRxM.net

>>957
いやメモリリークはDoS攻撃に対する脆弱性になりうるから安全性に差し障るよ

960 ：デフォルトの名無しさん：2022/09/17(土) 16:11:02.02 ID:Qv9rB708.net

>>958
「メモリ安全性」という用語の定義の話に変な造語持ち込んで話題そらすのやめてよ

Rustによるメモリ安全性の定義が俺俺というなら、ちゃんとした定義を示して欲しいな
「常識だから分かるでしょ？」というのは自分の思いの表明にしかならないよ

961 ：デフォルトの名無しさん：2022/09/17(土) 16:15:15.87 ID:EEEbWrXO.net

>>958
だからお前の思う「メモリー安全性」の定義を示せよ
まあ示せないからぐだぐだはぐらかすしか無いんだろうけどw

962 ：デフォルトの名無しさん：2022/09/17(土) 16:22:09.35 ID:8assD4qG.net

>>957
だとするとRustで常駐系のプログラムの開発をするのは安全では無いですな。
常駐系プログラムがメモリを食い潰すのは良くあるバグだけど、Rustだとそれは「仕様」で「メモリ安全の対象外」なんだから。
まぁ、Rcの循環参照だけの話だから、外部のコードを含めてRc使っていないor循環参照していないことを検証できれば安全なんだろうけど、Rustファンが言うような「Rustを使えば安全」というようなことは無い。

>>960
素直にWikipediaの「RAMアクセス時に発生するバグやセキュリティホールなどから保護されている状態のこと」でいいだろ。
Rust公式はなんて定義しているの？>>931は定義じゃないよな。

963 ：デフォルトの名無しさん：2022/09/17(土) 17:12:30.63 ID:Y2R7c2nA.net

「定義」や「常識」「一般的に」の話とは別だが、このスレ見てる個人的印象だと、
Rustで宣伝商売したい人たちは、Rustを知らない人(意思決定者)が「メモリ安全性」を「優良誤認」(自己責任)するのを密かに期待してそう
Rustプログラマーはそうじゃないと言い切れるのか

964 ：デフォルトの名無しさん：2022/09/17(土) 17:14:19.56 ID:d1cxOtJi.net

>>962
あんさんキチガイやな
それはRustの問題じゃない
>>939の説明が一番わかりやすいが言語全般における問題で原理的に解決できない問題やで

965 ：デフォルトの名無しさん：2022/09/17(土) 17:28:19.48 ID:HhHvs5OG.net

https://insights.stackoverflow.com/survey/2021#section-most-popular-technologies-programming-scripting-and-markup-languages
頑張ってるじゃないか
Rubyよりは使われてるみたいだな

966 ：デフォルトの名無しさん：2022/09/17(土) 17:33:54.35 ID:F49YQPus.net

>>925
今はしらんがrubyのgcも保守的gcだったよ。

967 ：デフォルトの名無しさん：2022/09/17(土) 17:35:17.75 ID:F49YQPus.net

>>934
じゃあなんで弱参照が用意されてるんですかねぇ？

968 ：デフォルトの名無しさん：2022/09/17(土) 17:40:51.90 ID:nFfh6PUY.net

>>926の論法分析が的中してる

>>964
>言語全般における問題で原理的に解決できない問題やで

言語全般が「メモリ安全性」を宣伝してるって言ってる？

>原理的に解決できない問題

原理的もなにもRustプログラマーが常に:

>>919
>「メモリ安全*」
>*メモリリークを除きます。
>と注釈付

すれば良い

969 ：デフォルトの名無しさん：2022/09/17(土) 17:42:57.37 ID:Qv9rB708.net

>>962
メモリ安全性に循環参照によるメモリリークの抑止が含まれないことは認めてくれた感じかな？

Rustを使えば絶対安全とか言ってる人の言うことを信じるのは良くないよ
匿名掲示板の変な人の発言じゃなくてちやんとしたドキュメントを読んだ方が良い

Rustはメモリ安全性について独自の定義はしてなくて、Wikipediaに書かれているような意味でのメモリ安全性を保証するよ

970 ：デフォルトの名無しさん：2022/09/17(土) 17:46:34.02 ID:37/3YRxM.net

>>967
グローバルなキャッシュを実装するときなど、参照先のGCを妨げることなく長時間参照を持ち続ける必要がある場合に使用する
基本的にトレーシングGCで弱参照が必要になるのは極めてレアケース

971 ：デフォルトの名無しさん：2022/09/17(土) 17:54:50.07 ID:8assD4qG.net

>>964
新しい藁人形連れてくんなよ。
最初から
Rustの問題は>>903で、本来なら
「メモリ安全*」
*メモリリークを除きます。
とちゃんと注意書きすべき
という主張。原理的に解決できるかどうかとか主張していない。

>>964の言うとおり、原理的に解決できないのに>>963を狙って「メモリ安全」と宣伝しているなら邪悪すぎるな。>>964は「Rust公式は邪悪」と言いたいのかな？

972 ：970：2022/09/17(土) 17:57:12.28 ID:37/3YRxM.net

なお、トレーシングGCにおいて循環強参照を避けることを目的に弱参照を使用することは全く何の意味もない
トレーシングGCのアルゴリズムを知っていれば循環強参照がGCのパフォーマンスやメモリ効率を悪化させることが無いのは明らかであるし、
弱参照の使用はレアケース故に概してあまり最適化されていないため、パフォーマンスは大抵の処理系においてむしろ悪化する

973 ：デフォルトの名無しさん：2022/09/17(土) 18:01:07.97 ID:F49YQPus.net

GCあるほうが楽だと思うんだけど、スパイクの無いGCって実現できないの？

974 ：デフォルトの名無しさん：2022/09/17(土) 18:02:24.90 ID:cg31Hi2x.net

>965
>Rubyよりは使われてるみたいだな
逆逆 Stackoverflowは精度がイマイチ

jetbrains
Ruby https://i.imgur.com/zqmf96u.png お一人様 7% ほとんどの人が仕事で使っている
Rust https://i.imgur.com/olB9F6L.png お一人様 86% ほとんどの人が個人の趣味

975 ：デフォルトの名無しさん：2022/09/17(土) 18:03:21.53 ID:8assD4qG.net

>>969
いや？全然。
循環参照によるメモリリークはメモリエラーだろ。メモリ安全「RAMアクセス時に発生するバグやセキュリティホールなどから保護されている状態」じゃない。

それにRustファンの言うことを信じているとか、冗談を言うのはやめてくれよ。気持ち悪いから。

976 ：デフォルトの名無しさん：2022/09/17(土) 18:04:26.55 ID:RkjWnqae.net

>>972
え？
C#では循環参照を避けるためなどの目的で弱参照を使うけど
これは悪化させているとでも言いたいの？

977 ：デフォルトの名無しさん：2022/09/17(土) 18:05:04.82 ID:5J0Fty65.net

>>962
「どの言語でも基本的には、OOMキラーに殺される前にGCが走らせたり、手動でメモリーを解放できること」ができないと安全では無いんじゃないかな。なので環境依存よ。
そう、Rustを使えば安全では無い。

978 ：デフォルトの名無しさん：2022/09/17(土) 18:07:30.72 ID:37/3YRxM.net

>>976
そんな事実はない
嘘だと思うならC#スレで聞いてきなさい

979 ：デフォルトの名無しさん：2022/09/17(土) 18:17:28.35 ID:DwuaYi+a.net

今回の件でGC言語がなぜ何倍も遅いのかよく分かった
世代別ガベージコレクションをするため頻繁にコピーGCを行なうことが遅くなる敗因の一つ

980 ：デフォルトの名無しさん：2022/09/17(土) 18:27:42.60 ID:nd18Koff.net

>>973
昔、ハードウェア側でGCするJVM(?)があったような…。

981 ：デフォルトの名無しさん：2022/09/17(土) 18:30:08.29 ID:NCiJs45P.net

>>973
RustはGC無いけど即座に自動的にメモリ解放されて楽だよ

982 ：デフォルトの名無しさん：2022/09/17(土) 18:36:24.89 ID:w5Ud45eS.net

参照カウントって GC じゃないの?

983 ：デフォルトの名無しさん：2022/09/17(土) 18:37:21.32 ID:5PJHomtk.net

四天王で最弱のGC。

984 ：デフォルトの名無しさん：2022/09/17(土) 18:37:25.76 ID:DA06Eolw.net

>>981 それの何が楽だと言っているの?

985 ：デフォルトの名無しさん：2022/09/17(土) 18:38:14.76 ID:5PJHomtk.net

俺の考えたGCが最強だけど、サブマリン特許やる予定だから教えない。

986 ：デフォルトの名無しさん：2022/09/17(土) 18:39:44.29 ID:iNOCwuLa.net

はよ次スレ

987 ：デフォルトの名無しさん：2022/09/17(土) 18:40:19.19 ID:ykXCo787.net

GC言語を使うと大して楽になるわけではないのに劇的に遅くなるからな
無能にはGC言語が向いている

988 ：デフォルトの名無しさん：2022/09/17(土) 18:40:33.78 ID:5J0Fty65.net

>>979
世代間GCのアリナシもそうだし、
>>927と同じく、言語と解決したい課題によるよ。

989 ：デフォルトの名無しさん：2022/09/17(土) 18:42:13.95 ID:5PJHomtk.net

Java製アプリはオメガテーつこてるけど、遅いとか重いとか一切ない。
サクサク快適。
だがしかし、キャレットの位置が異常なのでテキストの選択がやりにくい。
この動作はJava GUIの仕様だが、仕様が間違っていると思う。
Windowsと同じ動作にするべき。

990 ：デフォルトの名無しさん：2022/09/17(土) 18:47:25.27 ID:lRvi//fY.net

>>980 次スレ気づいてない 誰か代理 俺は無理

991 ：デフォルトの名無しさん：2022/09/17(土) 18:47:35.21 ID:kG69OWVT.net

>>982
プログラマー指定せずとも自動的に参照カウントが使われる言語(PerlとかPythonとかSwiftなど)の場合はGCで合ってるよ
C++のshared_ptrやRustのRcのように特殊な用途のみにプログラマーが明示的に指定して使うものはGCとは呼ばれず単なるデータ管理構造

992 ：デフォルトの名無しさん：2022/09/17(土) 18:48:56.73 ID:KEhwIc0k.net

>>981
いつも出てくるこの自動解放されて楽って感覚がわからない。自動解放とか出来て当たり前じゃないの？

GCありと同等のルーズさが許されなら良いけれど、実際はメモリ管理を明確にさせられるよね。

993 ：デフォルトの名無しさん：2022/09/17(土) 18:51:00.89 ID:fAQVBQ3R.net

>>989
Javaは遅い
少なくともC/C++/Rustなどの2倍～数倍は遅い
Javaは仮想マシンだしGCあるし遅くなるのは仕方ない

994 ：デフォルトの名無しさん：2022/09/17(土) 18:51:29.16 ID:5PJHomtk.net

お子様　→　Python
おんな　→　Ruby
真の男　→　Rust

こう言いたいのでは？
岡くんは。

995 ：デフォルトの名無しさん：2022/09/17(土) 18:52:46.32 ID:5PJHomtk.net

>>993
ってことは、2~3倍遅くても何も問題ないってことだろ。

996 ：デフォルトの名無しさん：2022/09/17(土) 18:55:08.60 ID:5PJHomtk.net

パイソンとかジャッカルには厨二を惹きつける響きがある。
女がなぜRubyを使いたがるのかはよく知らん。
岡くんがRust推しなのは本読んでわかった気になったから。

997 ：デフォルトの名無しさん：2022/09/17(土) 18:55:32.40 ID:lBhMDjlR.net

>>992
C並に高速なプログラミング言語では自動メモリ解放は普通は行われない
これは例えば新世代言語であるZigなどでも同じで手動メモリ解放となる
唯一の例外が常に自動的にメモリ解放されるRust

998 ：デフォルトの名無しさん：2022/09/17(土) 18:56:42.77 ID:8assD4qG.net

次スレはワッチョイ付けるよね。

999 ：デフォルトの名無しさん：2022/09/17(土) 18:57:28.27 ID:8assD4qG.net

>>997
循環参照除く

1000 ：デフォルトの名無しさん：2022/09/17(土) 18:58:09.16 ID:8assD4qG.net

1000

1001 ：2ch.net投稿限界：Over 1000 Thread

2ch.netからのレス数が1000に到達しました。