X



次世代言語28 TypeScript Swift Go Kotlin Rust Nim
レス数が1000を超えています。これ以上書き込みはできません。
0003デフォルトの名無しさん2022/08/29(月) 17:39:40.63ID:OPpJUiH3
文字列の変数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)
0005デフォルトの名無しさん2022/08/29(月) 18:41:59.28ID:bPAqKnWj
全然書き込みが無いけど

ypeScript Swift Go Kotlin Rust Nimって、需要も人気も無いの?
0006デフォルトの名無しさん2022/08/29(月) 18:50:03.71ID:9qXoEPFV
>>4
今どきのプログラミング言語はいずれも型推論が賢いね
昔は型推論が無いか弱くて
変数の型宣言が不要というだけで動的型付け言語のメリットされていた時代もあった
0007デフォルトの名無しさん2022/08/29(月) 19:09:28.15ID:bPAqKnWj
次世代言語と言われる

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

昭和の時代から IT関連業で働き、稼いでいた者には、居場所が無いから別の職種に転業すべきかなぁ
0008デフォルトの名無しさん2022/08/29(月) 19:33:16.23ID:iMDvJogZ
>>7
TS、Go、Kotlinはいたるところで使われてるから、すでに現行言語では?
0009デフォルトの名無しさん2022/08/29(月) 19:46:28.38ID:vWUiNEGz
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などをはじめとする
複数の言語のエネルギー効率を相対的に示した研究結果を紹介している。
0010デフォルトの名無しさん2022/08/29(月) 20:29:24.84ID:bPAqKnWj
>>8


そういった系統の言語は、
業務で使用した事が無いから知りませんね。
0011デフォルトの名無しさん2022/08/29(月) 20:37:11.19ID:bPAqKnWj
>>9

Lambdaといえば、Common Lisp だな。

LISP - Lambda Functions
0015デフォルトの名無しさん2022/08/30(火) 09:52:15.23ID:hK2QX/pR
Pythonはセミコロン非推奨だが。
0016デフォルトの名無しさん2022/08/30(火) 12:29:02.78ID:OnpgRnR2
matzは構文に人間が寄り添うのではなく構文解析を言語が頑張るべき的なことを言ってたけど、現実は構文は厳格にしてformatterやlnterが曖昧さのないコードに導いてやるのが正解になってきたね。

人間なんてどこまでも適当な事をやらかせるんだから、それを実行時にうまく解釈してやるのは無理筋。
0018デフォルトの名無しさん2022/08/31(水) 00:25:17.21ID:h52EUFtB
Pythonは当初の頓珍漢な理想を捨ててpython2を見捨てなかったのがえらいんだよ
0019デフォルトの名無しさん2022/08/31(水) 16:57:16.44ID:nshUFjI3
Rustを自分には向いてないと言った(恐らく本人は批判したつもりはない)一生懸命にmatzを叩くRust新興カルトが気持ちわる杉る....
CやC++でバリバリ書いてる人に所有権チェックなんて邪魔すぎるし、配列境界チェックだって速度が出ない足を引っ張る機能にしか見えないだろ
今は固定範囲の配列アクセスのチェックなんかは省略してるかもしれんが、恐らくそんな事はない(全てに係るから安全だと大口する)
0020デフォルトの名無しさん2022/08/31(水) 18:05:12.54ID:0pp++Yd3
matzは静的型付け言語は
変数に型定義を書きまくるのが面倒くさい
というようなとこを言ってて
型推論とか知ってるくせにそれは
無いんじゃねと思ったな
0021デフォルトの名無しさん2022/08/31(水) 18:25:03.72ID:Fgf/9Zy6
CやC++で困ってない人に無理にrustを勧めてくる人は相手しなくて良いよ
0022デフォルトの名無しさん2022/08/31(水) 18:30:28.99ID:kXQrZaUS
matzのおかげでプログラミング文化が進化したのはのは間違いない
RustもRuby文化のいい面をかなり受け継いでいる
0023デフォルトの名無しさん2022/08/31(水) 18:32:18.02ID:SRFkQuBk
>>19
所有権チェックって何?
そんな用語も概念も存在しない

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

>>21
困ってる困っていないの問題ではない
回避策が確立されたのに欠陥言語を使い続けるか否かの問題
人間は必ずミスを起こしうる、との結論が出ていて
大手IT企業も挙ってRustを採用している
0025デフォルトの名無しさん2022/08/31(水) 18:36:59.70ID:Fgf/9Zy6
みんな所有権所有権言うけど、初学者がひっかかりがちなのって借用の方では
所有権というとRAIIの方を連想してしまうけど
C++でmove使いこなしてた人ならRustの所有権ではひっかからないだろうし、他の言語でもtry-with-resourcesとか類似の概念あるよね
0026デフォルトの名無しさん2022/08/31(水) 18:55:37.66ID:hNAJwBIT
うちの会社にもPHPで困ってないからと言いながらゴミを作り続けるおっさんいるわ
0027デフォルトの名無しさん2022/08/31(水) 19:25:46.59ID:Fgf/9Zy6
>>26
そういうおっさんが業務の阻害要因になってるならなんとかした方が良いけど
掲示板上でどういう問題抱えてるかすら分からない相手に闇雲に勧めるのとは全然違うよね
0028デフォルトの名無しさん2022/08/31(水) 19:48:33.02ID:SRFkQuBk
>>26
PHPは>>9の記事の観点からはエネルギー効率の悪い劣った言語かもしれないが
C/C++が現実に大量のセキュリティの穴も含むメモリ管理バグを引き起こし続けている危険な欠陥言語である点とは大きな開きがある
0029デフォルトの名無しさん2022/08/31(水) 19:56:05.14ID:D6khOQ0c
>>27
おっさん自身は問題を理解できてないってことを言ってるんだよ
0030デフォルトの名無しさん2022/08/31(水) 19:56:39.74ID:bi3oBo/Y
どんなに優れたプログラマーでもミスをするしバグも作るって考え方は大事だと思うけどな
0031デフォルトの名無しさん2022/08/31(水) 19:58:59.48ID:mLZrYK8Z
#define new old
で、全て解決では?
0032デフォルトの名無しさん2022/08/31(水) 20:04:50.79ID:mLZrYK8Z
でもウェブサイトの9割はPHPで出来てると言うからなあ。
0033デフォルトの名無しさん2022/08/31(水) 20:33:48.91ID:TBd/y3ES
PHPを馬鹿にするやつにその資格はない
PHPの作者を馬鹿にするやつにその資格はない
PHPよりも作者よりも糞なやつが鏡すら見ずに薄ら笑ってる
0035デフォルトの名無しさん2022/08/31(水) 20:55:36.71ID:bW00GV9W
>>24
んなこと言ってねーだろ。
ミスリードすんな。
0036デフォルトの名無しさん2022/08/31(水) 21:00:04.57ID:mLZrYK8Z
Haskellが見向きもされなくなったら、Rustの宣伝が増えたな。
0037デフォルトの名無しさん2022/08/31(水) 21:11:47.88ID:SRFkQuBk
>>36
宣伝?
例えば>>9の記事はクラウドのシェアトップであるAWSがそのサービス提供にRustを使って構築しているという現実の話
着実に様々なインフラがRustベースへと置き換わっていく現実の一つ
0039デフォルトの名無しさん2022/08/31(水) 21:28:47.20ID:h52EUFtB
限られた情報から善と悪を判断できない人達が
まだ公開されていないクソどうでもいいデータを欲しがる
0042デフォルトの名無しさん2022/08/31(水) 23:06:38.28ID:1xLvm1yy
rustは死産だったんだよ
このスレで頑張ってるのは水子供養みたいなもん
0043デフォルトの名無しさん2022/08/31(水) 23:15:56.00ID:V71AUGNS
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に移植することで劇的な性能向上を私たちは見てきました。
0044デフォルトの名無しさん2022/08/31(水) 23:21:00.54ID:Fgf/9Zy6
>>35
いやいやC++で書かれたプログラムは無条件にRustで置き換えられるって主張は銀の弾丸って言ってるのと同じでしょ
0045デフォルトの名無しさん2022/09/01(木) 00:44:24.52ID:cwSyLQRT
善行を勧めることと、善行が必勝法であると主張することを区別する必要がある
0046デフォルトの名無しさん2022/09/01(木) 07:30:51.13ID:F4Y0rM7S
>>23
「最適化によりforでのチェックだけになり・・・つまりC言語と同じになる」
はい、明確すぎる嘘、Cは普通処理系によりけりだが通常は配列境界のチェックなんてしません。あほかwなにが、つまりだw
必死すぎるのがほんと痛々しい
0047デフォルトの名無しさん2022/09/01(木) 07:32:21.78ID:fyMKlXgD
所有権を邪魔だと思ってる奴のC++コードは読みたくねえな
一緒に仕事したくねえ……
0048デフォルトの名無しさん2022/09/01(木) 07:51:48.00ID:TMFOnHT0
>>46
インデックス値でforループを回すとあるから
C言語でもループ1回に付き必ず1回のインデックス値の境界比較が必ず入るよ
境界チェック無しでforを回したら無限ループになる
0049デフォルトの名無しさん2022/09/01(木) 07:57:15.00ID:F8jNf2Yy
>>48
Cって、配列のインデックスアクセスに境界チェックとか無くて、プログラマに委ねられているのかと思ってた。Cも意外に安全性を気にしているんだね。
0050デフォルトの名無しさん2022/09/01(木) 08:33:34.02ID:5fR61KJN
>>38
javaのフレームワークって何使ってるの?
0051デフォルトの名無しさん2022/09/01(木) 09:37:58.04ID:wgtUDrt5
>>44
その通り
条件を絞って
予めRustに移植することを意識して描かれたC++のソースのみ自動変換出来る
なら正しいかも知れない
0052デフォルトの名無しさん2022/09/01(木) 09:39:23.27ID:wgtUDrt5
>>44 追加
ちなみに漏れは
「Rustに移植することを意識して描かれたC++のソース」
ならC++のままでええやん?的な立場
0053デフォルトの名無しさん2022/09/01(木) 09:41:17.41ID:wgtUDrt5
>>48 はCを知らない素人以下
0054デフォルトの名無しさん2022/09/01(木) 09:48:59.81ID:5fR61KJN
>>49
たぶん間違って読解してる。
良くも悪くも日本語って主語省略しちゃうからね。
0056デフォルトの名無しさん2022/09/01(木) 09:57:04.30ID:oWUbfflz
>>55
配列のインデックスチェックってここではモダンな言語は配列外にアクセスすると実行時エラーになるということを言ってるんだよ
Cはエラーじゃなく未定義だから何が起こるかわからん
0058デフォルトの名無しさん2022/09/01(木) 09:59:00.80ID:oWUbfflz
いや動的配列ならやっぱ実行時か
どっちにしてもCみたいに変更しちゃいけないところを変更して暴走しないってこと
0059デフォルトの名無しさん2022/09/01(木) 10:09:23.03ID:flNKFTp5
>>56
元の話は>>23だからインデックス値のforループ
C言語でも他でもfor文で境界チェックが必ず入る

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

結果としてCでもRustでも同じ生成コードとなる
0061デフォルトの名無しさん2022/09/01(木) 10:30:39.30ID:KHPE1b9m
>>59
日本語で説明するよりコードと生成されるアセンブリ見せた方がわかりやすいのでは
0062デフォルトの名無しさん2022/09/01(木) 10:31:44.69ID:0sJGxogX
forループの例では同じ生成コードとなるが
範囲内かどうか不明なインデックス値がやってきてそれで配列をアクセスする場合は違いが出る

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

Rust含むその他の言語
プログラマーは気にせずとも自動的に境界チェックされるため安全
0066デフォルトの名無しさん2022/09/01(木) 13:36:52.33ID:wgtUDrt5
>>59
>Cならばチェックしないがfor文でチェック済なので安全上の問題なし

doubt
マジで言ってるなら去ね
0067デフォルトの名無しさん2022/09/01(木) 19:55:15.23ID:K2svajoy
>>66
forでインデックスの境界チェック済みとあるから
配列のアクセス時に再び境界チェックしなくても安全でしょ
0068デフォルトの名無しさん2022/09/01(木) 20:39:52.39ID:Wlby5VAy
いや、for文でのループ条件とか書き間違えてバグる筆頭だろ。
人力チェックの限界が見える典型。
0069デフォルトの名無しさん2022/09/01(木) 21:06:01.62ID:ms47s476
Rust方式が速さと安全の両立でベストだろう
基本的には配列(スライス)アクセス時にインデックス境界チェックが行われて必ず安全
その上でインデックスforなどでループ内のアクセスがコンパイラにより安全と保証できる場合は
最適化によりループ内の配列(スライス)アクセス時にインデックス境界チェックが無くなり速さと安全を両立
0070デフォルトの名無しさん2022/09/01(木) 21:29:24.74ID:xF4gFfdK
>>38
単価の中央値は?
0071デフォルトの名無しさん2022/09/01(木) 22:04:15.15ID:cwSyLQRT
もしもポインタが組み込み型ではなく外部のライブラリだったら
ライブラリを変更するだけでCはそこそこ安全になれた

C++はスマートポインタを追加することはできても
元からあるポインタ型を改善することは全然できなかった
0072デフォルトの名無しさん2022/09/02(金) 00:56:06.09ID:itc/vw5Y
>>69
slice::Iterは<[] as Index>::index使わないから最適化関係なく境界チェックは一度だけになるが
0073デフォルトの名無しさん2022/09/02(金) 05:54:25.85ID:shSg4CAC
>>59
痛いRustおじさんの代表例だね、境界チェックが必ず入る処理系があったとしてそれを、C言語は!なんて表現しないぞ?
「結果としてCでもRustでも同じ生成コードとなる 」絶対ならないからwつーかアセンブラして貼り付けろよ?
それで常に100%が誰がやってもどのバージョンでもどの環境でも同じならあんたが正しい
そもそも配列ループの遅さをカバーするためにRustは速度を稼ぐために一部分ループ展開を勝手にするはずなので、gccとかなら
O2ではダメでO3でfunroll-loopsでコンパイルしないとならないよ
0074デフォルトの名無しさん2022/09/02(金) 07:47:28.70ID:h0CkE7tZ
>>72
もちろんRustはイテレータが強力だから
インデックスで回すよりもイテレータ利用が断然に多く
スライス(配列)アクセスに境界チェックを毎回しないのはおっしゃる通りだが
様々な理由でイテレータではなくインデックスでforで回す場合もあり
その時ですらforの終端チェックのみで最適化によりスライス(配列)アクセス時の境界チェックは消えている
という話だから両立する話
0075デフォルトの名無しさん2022/09/02(金) 07:51:35.38ID:h0CkE7tZ
>>73
配列ループで遅いなんて聞いたこともなく実際に遅くなっていない
何を根拠にそんなデタラメで叩いているのだろうか
0076デフォルトの名無しさん2022/09/02(金) 08:11:51.41ID:yReiMthF
他言語の範囲forとかイテレーターを無視して「Rustのforが一番」とかいうのは無知を通り越して無能。
「C++のforループは危険」というのはさすがに引っ込めたみたいだけど、cのforループと比較してRustを褒めるのは邪悪すぎるだろ。
0077デフォルトの名無しさん2022/09/02(金) 08:20:26.86ID:xKAOCFMw
>>76
みんなが話しているのは配列アクセスの安全と速さ
forはその時に出てくるだけであってfor自体の比較を誰もしていない
そこに優劣もない
0078デフォルトの名無しさん2022/09/02(金) 08:36:58.81ID:yReiMthF
>>77
その割にはforの安全チェックとか持ち出しているやついるけど。
それに配列ならコンパイル時にサイズが決定する/しないで全然違うけど、そこをごっちゃにしているアホがいない?
0079デフォルトの名無しさん2022/09/02(金) 09:00:49.10ID:r2oaJ0uT
ほんとダメだねえ、どうやっても遅いんだが?顔真っ赤にして人を罵倒する前にさ
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の勝手にループ展開でも言えますが
いずれもループ終了チェックであり、そんなのは比較していませんし、またあとから出てきたイテレータの話は全く違う話ですね
0080デフォルトの名無しさん2022/09/02(金) 09:05:50.01ID:kItyetcb
>>78
批判するにはちょっと知識不足すぎじゃない?
みんなが書いているRustのスライスはコンパイル時に長さが確定しないから、確定する配列だけでなく、どちらの場合でも大丈夫ってこと
0082デフォルトの名無しさん2022/09/02(金) 09:17:24.54ID:NtJICGnn
>>79
あまりにキチガイでワロタ
その約20倍差の数値で比較しちゃってるのかよ
本気で20倍速いと思い込んでる?
0083デフォルトの名無しさん2022/09/02(金) 09:24:36.61ID:r2oaJ0uT
>>74
レス番つけ忘れたけど、頑にCと(速度が)同じだ。遅くないというカルト信者みたいな態度はほんと反省してほしいわ・・・
根拠を示したのにキチガイと反論するばかりで、こんな簡単なプログラムにさえどこが悪いのか言えないし
0084デフォルトの名無しさん2022/09/02(金) 09:32:20.12ID:r2oaJ0uT
誰も20倍速いなんて一言もいってませんが?timeごときでこの程度の差が出るのであれば、「同じ」なんて言えないと思いますが?
むしろ境界チェックが機能してる結果であり、一方でCはそのような境界チェックは通常の処理系ではありえない=チェックがないので
安全性はlintなどやプログラマーの能力に依存する
提言:”内容に反証を提示できず、人をキチガイ呼ばわりする人がキチガイ”
0085デフォルトの名無しさん2022/09/02(金) 10:07:22.38ID:3EJXZ/Ye
> 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側のどうこうはさておき、要素アクセスのときにケアできてるかどうかの話じゃないの?
0087デフォルトの名無しさん2022/09/02(金) 10:33:22.77ID:icfpnsJw
現代のCPUなら投機的実行で境界チェックみたいな処理は時間コストかからんけどなあ
それとRustのprintln!は非バッファでロックもするから配列性能計測に混ぜたらいかんでしょ
性能計測の初歩だと思うんだけど
0089デフォルトの名無しさん2022/09/02(金) 11:14:19.45ID:RkYzNFi/
Rustのスライスsでfor i in 0..s.len()でループ回して見たら
生成コードはforの終端チェックだけになってs[i]の境界チェックは消えるんだな
確かに論理的に正しい最適化だが賢いな
結局Cでfor (i = 0; i < len; i++) とした時と同じ
0090デフォルトの名無しさん2022/09/02(金) 12:00:55.17ID:kDm3gkwV
println!取り除いてもCより遅いけど?
勝手にコードを変更してs.lenとか悦にはいってるし、この人たちって絶対objdumpした結果を上げないね
同じ(=100%一致)なんて絶対あり得ない、gccじゃなくclang/llvmにしたら分らんけど、それでも
”C言語は”なんてあんたさえも知らない処理系があるのに恥ずかし気もなくビックマウス披露出来るわけない
投機実行の境界チェックのバイパスは有名なスペクターとして脆弱性だから機能してないんちゃうか?知らんけどさ
0091デフォルトの名無しさん2022/09/02(金) 12:40:37.54ID:omdV4spc
>>80
固定長なら範囲チェック自体消えるだろ。

Rustの話をするなら、「ひとつの読み書き参照 xor 複数の読み取り参照のきっつい制約を課すことで範囲チェックの回数を減らしている」くらいの説明はできんのかね?オレも詳しくはないが。
0092デフォルトの名無しさん2022/09/02(金) 18:35:42.02ID:itc/vw5Y
引数で与えられた配列の中の最大要素をインデックスアクセスで探す関数を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
0093デフォルトの名無しさん2022/09/02(金) 19:48:54.34ID:SRTIVbJR
っつーか今さらcでの開発なんて小規模じゃないとやりたくないわ。
0095デフォルトの名無しさん2022/09/02(金) 20:51:46.96ID:eOJxFMTK
>>92
凄いな
CとRustは同じ生成コードになるんだな
どちらも64バイトでループ展開か
0098デフォルトの名無しさん2022/09/02(金) 21:41:46.84ID:TRifMPKk
わざわざ境界値チェックが不要になるケースで比べたらそりゃそうだろって感じ
最初のサンプルコードが酷すぎた
0099デフォルトの名無しさん2022/09/02(金) 21:45:38.80ID:SRTIVbJR
>>98
境界値チェックが必要なケースをよろ
0100デフォルトの名無しさん2022/09/02(金) 22:15:29.02ID:ZICl4sMk
結論が出たな
Rustを攻撃してた人が以下のようなウソをついてた

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

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

生成アセンブラコード>92を見ると
CでもRustでも同じ生成コード
CもRustもループ内のインデックス境界チェックは無く同じコードとなっている
そしてCもRustも一部分ループ展開を同様にしてる
当然どちらも同じ速度となる
0101デフォルトの名無しさん2022/09/02(金) 22:58:49.99ID:SRTIVbJR
>>98
早くc言語で境界値チェックするコード出してよ。
0102デフォルトの名無しさん2022/09/02(金) 23:27:03.89ID:lqMLDpPB
全然読まない、勝手にコードを変更してs.lenとか悦にはいってる
0103デフォルトの名無しさん2022/09/02(金) 23:59:11.14ID:VC9smmde
>>102
配列やベクタやスライスなどを一般的に
C言語で扱う関数ならば先頭ポインタと長さを受け取る
Rustならばその二つがペアとなったスライスsを受け取りその長さ部分がs.len()
だから常識的なプログラマーならば誰が書いても>>92のソースコードとなる
そして生成アセンブラコードがCとRustで同等と判明した
0104デフォルトの名無しさん2022/09/03(土) 01:19:34.52ID:txSLq0y3
おじさん普通にC勉強した方が良いよ
Rust書ける人でC書けない人なんていないからズレまくった指摘してるんだよ
Rustであえてパフォーマンス出ないようなコードを書いてるとしか思えない
0105デフォルトの名無しさん2022/09/03(土) 01:46:36.01ID:2EHZBEma
>>92のシンプルなコードをこれ以上に速くするのは無理じゃね
そしてRustもCも同等のアセンブリコードを吐いてるから実行速度も同じで勝負ついた感じだな
0106デフォルトの名無しさん2022/09/03(土) 03:19:04.56ID:DRQBO0l9
バカ野郎!
Rustのおっちゃんは、日本を代表するトライアングル(楽器)奏者なんだぞ!
0107デフォルトの名無しさん2022/09/03(土) 04:44:36.86ID:22c5U/VG
少なくとも配列範囲外アクセスするようなコードで比べなければ意味がない。
誰も勝負なんてしてないだろ
こんな事やってるからRustを嫌う人が割と増えていく、言い逃れそのものだろw

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

固定長のループがclang/llvmで同じになったとして、壺カルトRust信者曰く、「C言語は」という
デカすぎる主語と、Rustでのすべての配列境界チェックが無くなるわけではなし何が勝ちなんだか...
0108デフォルトの名無しさん2022/09/03(土) 05:27:05.78ID:lg2jZ6dQ
>>107
コードを読めない人なの?
固定長のループではなく長さは関数の引数として与えられている
したがってC言語でもループ1回に付き必ずインデックス値の境界比較(=インデックス値が長さを超えないこと)がfor文の条件部で行われている
0109デフォルトの名無しさん2022/09/03(土) 06:17:52.84ID:Xvi3nnOL
>>92
例えばinline化とかで二つの配列/スライスがエイリアスされていることがコンパイラー(とプログラマー)に見えている場合があると思うんだけれど
Rustの方は自動ベクトル化してくれないのね。Cの方は自動ベクトル化されている。

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

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

max_value_slice_vwをどう書いたら自動ベクトル化されるの?
0110デフォルトの名無しさん2022/09/03(土) 06:38:25.68ID:peyYEDe5
何の争いかよくわからんけどつまりRustでサイズ10の配列を作ってその11番目の要素にアクセスしたらどうなるん?
Cだと境界チェックしないから未定義になるしセグフォ出たり他の変数を書き換えたり暴走したりすることもある
0111デフォルトの名無しさん2022/09/03(土) 06:40:51.52ID:peyYEDe5
11というのをリテラルで与えるともしかしたらコンパイルエラーになるかもしれんけどたとえばそれを乱数で生成した場合はどうなんの?
0112デフォルトの名無しさん2022/09/03(土) 06:53:51.31ID:peyYEDe5
Cが境界チェックしないと言うのは境界チェックがプログラマの責任だということだよね
Rust以外のモダンな言語では大抵範囲外の要素にアクセスしようとすると実行時例外を吐く
Cはそれをせず黙って暴走したりこっそり他の変数の値を書き換えたりして気づきにくいバグになる
Rustはどっち?
0114デフォルトの名無しさん2022/09/03(土) 07:06:18.00ID:z9CaUV9k
>>112
Rustは基本的には他の大多数の言語と同じで、アクセスする前に自動的にインデックスの境界チェックをする。

ただし、>>92などのように多くのプログラム利用例では、インデックスはforで指定範囲を動くため、アクセスする際のインデックス境界チェックは最適化により必要とせず行われなくなり、結果としてC言語と同じアセンブラコードが生成される。
0115デフォルトの名無しさん2022/09/03(土) 07:13:36.64ID:z9CaUV9k
つまり、Rustは安全性を常に保ちつつ、不要な境界チェックは最適化で無くすことで、安全かつ高速を実現。
0117デフォルトの名無しさん2022/09/03(土) 07:34:10.00ID:/y6fxgdJ
CとRustは同じアセンブリコードを生成すると>>92で示されているから
あとは他の言語でもそうなるならそれを示せばよい
0118デフォルトの名無しさん2022/09/03(土) 07:37:07.45ID:lGqTIi1A
どうでもいい内容で盛り上がってるな
for文の仕様がボトルネックになることなんかないんだからどうでもいい
0119デフォルトの名無しさん2022/09/03(土) 07:46:39.87ID:1xBXpDYn
例えばfor (i=0;i<len;i++) arr[i*2]=0;
Rustはこの時もCと同じコードになるんだよね?
0120デフォルトの名無しさん2022/09/03(土) 07:56:47.99ID:mdxH418+
gccのコミッターのものだけどそんな単純な話じゃないよ
Rustのスティーブとはよく話をするけどね
0122デフォルトの名無しさん2022/09/03(土) 08:04:34.15ID:2bPWyV3b
まあこんなマイクロコードの比較だのベンチだのに意味は無いわな
コンパイラも局所だけ見て処理するわけでもなし
0123デフォルトの名無しさん2022/09/03(土) 08:23:27.57ID:04g55wUA
>>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言語と異なる)
0124デフォルトの名無しさん2022/09/03(土) 08:27:29.75ID:1xBXpDYn
>>123
境界チェックがあるって言われてるのはその場合のことだよ
最適化で無くなる時の話をしてるのは君だけじゃないかな多分
0125デフォルトの名無しさん2022/09/03(土) 08:47:00.60ID:pNlcpp9D
rust書けるやつはたいていcも書ける。
cは書けるがrust書けないなつはいる(俺とか)。
両方書けるほうがいいに決まってる。
0126デフォルトの名無しさん2022/09/03(土) 08:47:14.13ID:oioC2Qy2
>>123
後者はC言語だと範囲外をアクセスしてしまい破綻だな
境界チェックをするRustが正しい
0127デフォルトの名無しさん2022/09/03(土) 09:09:01.93ID:YIfnpCsY
>>124
正しい使用ならば最適化されて境界チェックが消える点も重要やで
それによりRustのコードがCとほぼ同じ速度で動いている

一方で間違った範囲外のアクセスが起きうる場合には境界チェックがなされる点も重要やで
それによりRustはCとは異なり安全となっている
0128デフォルトの名無しさん2022/09/03(土) 09:12:44.80ID:qprMzk1R
>>123,126
> あとRustではその処理関数は引数をスライスxで受けることになり
> lenはx.len()となる
配列の一部だけを処理したいとか普通にあるだろ
0129デフォルトの名無しさん2022/09/03(土) 09:21:53.95ID:YIfnpCsY
>>128
配列の一部分はスライス (配列全体も可)
Vecの一部分もスライス (Vec全体も可)
スライスの一部分もスライス
なのでRustで関数を書くときはスライスを対象にして記述する
そしてスライスとして扱った時点で既に境界チェック済み(=元の範囲内)なので最適化が可能となる
0133デフォルトの名無しさん2022/09/03(土) 09:32:15.16ID:91ZlUxrs
C/C++ で BITMAPINFOHEADER なんか扱うときは
意図的に範囲オーバーさせて bmp データにアクセスするよねω株 PI.3.14
0134デフォルトの名無しさん2022/09/03(土) 09:37:13.56ID:hKLkDwrb
>>131
Rustアンチの人にとって「Rustは遅い!」が信仰の砦。
ところが世間で言われてる通り、RustはCとほぼ同じ速さだと>>92で分かり、大変なことになってしまって大騒ぎ。
0135デフォルトの名無しさん2022/09/03(土) 09:45:26.31ID:peyYEDe5
困るとか困らないとかじゃなくCではやらない境界チェックがあるから現実に遅いよ
0136デフォルトの名無しさん2022/09/03(土) 09:47:19.22ID:peyYEDe5
Cと同じ速度で動くコード「も」あるというならその通り
他の言語でもある
0137デフォルトの名無しさん2022/09/03(土) 09:52:51.38ID:cKT2CTgA
>>132
Rustのスライスは抽象化された概念で扱われるけど
実体は先頭ポインタと長さのペア
だからスライスを作るって大層なことではなくC言語で処理対象の先頭ポインタと長さを用意するのと同じ

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

>>136
C言語より遅いコードがあると主張したいならば
具体的に>92のように生成コードの比較を出せばよい
0138デフォルトの名無しさん2022/09/03(土) 09:54:03.17ID:peyYEDe5
境界チェックが消えたコードじゃなく消えてないコードで比べてみたらすぐわかるんじゃないですかね
0141デフォルトの名無しさん2022/09/03(土) 09:59:58.21ID:qprMzk1R
>>137
> だからスライスを作るって大層なことではなくC言語で処理対象の先頭ポインタと長さを用意するのと同じ
いや、実装は想像できるからいちいち説明してもらわなくてもいいんだけどC言語だといちいちそんなもの作らないよ
先頭ポインタも長さ情報も既にあるのに同じ内容を持つスライスを作るのは(C言語脳としては)無駄に思える
0142デフォルトの名無しさん2022/09/03(土) 10:03:47.05ID:v+XVsXaf
>>138
CよりRustが遅いコードを具体的に出してよ
array[i*2]の例は危険な範囲外アクセスとなるコードだから境界チェックをするRustに軍配が上がるね
だから安全な正しいコードなのにCよりRustが遅いコードを具体的に生成コードと共に出しましょう
0143デフォルトの名無しさん2022/09/03(土) 10:06:50.84ID:RRdFGJ7i
>>142
プログラマが完璧なら危険ではないので上司のしりぬぐいをしないというのがCのスタンス
Rustはチェックするので正しいが遅い

あのー、わざとやってるのかバカなのかどっちなの?
0144デフォルトの名無しさん2022/09/03(土) 10:11:51.77ID:774mvNvo
>>141
Rustではもっと抽象的に捉えてプログラミングするからそこに無駄と考える発想は出てこないし
同じだから無駄だといっても生成コードは最適化で無駄は消えるからCと同じ速さが出るでしょう
0145デフォルトの名無しさん2022/09/03(土) 10:14:07.95ID:Rys3iPM9
実例と計測結果出さないと空論でしか無いわな
まあ速度差が無くて出せないんだろうけど
0146デフォルトの名無しさん2022/09/03(土) 10:17:36.98ID:RSYLNmWc
チェックが入ると遅くなるから最適化でチェック省くことがあるんだろうに何で実測しなきゃわかんないんだよ
特定のスニペットじゃなく境界チェックが入る現実のコードの話をしてるのに実測なんてできるわけないだろ
境界チェックが原因で遅くなるコード作れと言うなら作るが、それ作ったら間違いを認めるんだろうな?
0148デフォルトの名無しさん2022/09/03(土) 10:20:52.59ID:0TSBfRU/
>>143
それは君が誤解してるようにみえるなあ
Rustでは安全に範囲内のアクセスとRustコンパイラが分析できれば境界チェックをしないためCと同じ速さが出る
そうでなく危険な範囲外のアクセスになりうるとRustコンパイラが判断すれば正しく境界チェックを行なう
C言語で書いても危険な範囲外のアクセスになりうる場合は手動で境界チェックをせざるを得ないから速さは同じ
0150デフォルトの名無しさん2022/09/03(土) 10:28:32.67ID:ypKv7OZi
>>149
遅くなる具体例ありそう?それ知りたい
RustとCのアセンブリ生成コードが同等になり速さが同じとなるケースは>>92で示されてるから
同じようにして遅くなるケースを示せばよいと思う
もちろん範囲外アクセスとならない例でw
0152デフォルトの名無しさん2022/09/03(土) 10:49:11.71ID:qprMzk1R
>>148
> そうでなく危険な範囲外のアクセスになりうるとRustコンパイラが判断すれば正しく境界チェックを行なう
C言語では外部からもらったデータは仕様で配列範囲に入るのが確実だからチェックをしないとかあるんだけど、Rustコンパイラとやらは仕様書まで読み込んでくれるのかなw
0153デフォルトの名無しさん2022/09/03(土) 10:52:15.27ID:BHvUMyM5
境界チェックによるペナルティが気になる箇所なら境界チェックのないget_unchecked使えば良いのでは
デフォルトは安全側に倒されてるけどプログラマの裁量で速度を優先することもできるので、適材適所でどちらを使うか選べば良い
C++でも境界チェックありのat()があるから、デフォルトが逆なだけでできることは同じだよね
0154デフォルトの名無しさん2022/09/03(土) 11:03:40.39ID:7pWn865H
結局プログラマーの手に委ねていると必ずミスが起きうるから
境界チェック省略の件も含めて全てについて
コンパイラが分析して安全かどうか判定できた時にはチェックを省略し
そうでない場合は安全のために自動的にチェックをするのがベスト
という方向へ向かっているんじゃないかな

GoogleやMicrosoftがRust言語でOS開発
https://xtech.nikkei.com/atcl/nxt/column/18/00692/042700054/
【脆弱性の70%がメモリー管理バグに起因】
GoogleによればAndroidに存在した深刻なセキュリティー脆弱性の70%近くがメモリー安全に関するバグに起因するという。
同様にマMicrosoftも、同社製品に存在したセキュリティー脆弱性の70%がメモリー安全に関するバグに起因すると述べている。
C/C++を使う限りセキュリティー脆弱性を根絶するのは不可能と考えて、Rustを採用するに至ったというわけだ。
0156デフォルトの名無しさん2022/09/03(土) 11:53:26.95ID:MAChL+qh
>>150
じゃあCよりRustが遅くなるコードを示せばごめんなさいすんのか?しないだろ?
ここまでの説明でわからないバカがいるはずないからレスバしたいだけだよな?
0160デフォルトの名無しさん2022/09/03(土) 12:53:59.17ID:91ZlUxrs
最近のレベル低下には目を見張るものがあるな
0161デフォルトの名無しさん2022/09/03(土) 12:58:26.77ID:91ZlUxrs
>>142
>array[i*2]の例は危険な範囲外アクセスとなるコードだから境界チェックをするRustに軍配が上がるね

array[i*2]の例は危険な範囲外アクセスとなるコードだから境界チェックをしないCに軍配が上がる
が正しい
0162デフォルトの名無しさん2022/09/03(土) 13:35:09.09ID:EiHHJiSw
いやはや、時代についていけないCオジが暴れてるようだなw
Cオジもさぁ、自分の世界に引きこもってないでもっと外の世界見ないとねw
0163デフォルトの名無しさん2022/09/03(土) 13:37:41.33ID:EiHHJiSw
Cこそ最強!
1個でもCより遅いケースあったらダメね!
0164デフォルトの名無しさん2022/09/03(土) 13:38:08.80ID:mKqqa6mD
次世代言語スレなんだから変数の境界越えたアクセスは落とす一択だろ。

もうちょっと別の話したいわ。
0165デフォルトの名無しさん2022/09/03(土) 13:38:32.50ID:EiHHJiSw
1個でもCより遅い場合あったら、他にメリットあっても意味ないから!
0166デフォルトの名無しさん2022/09/03(土) 13:50:50.43ID:uXzSzfSl
誰も>>91の突っ込み無いんかよ。
Rustが速いのは非常にキツイxor条件を満たす範囲だけで、そこを超えるのはとても面倒。そこを無視して「Rustは安全で高速」とか言うのは詐欺じゃね?

あと、次世代スレなのに何でRustとcだけの比較なんだよ。rangeの最適化なんてイマドキc++ですらやるんじゃないの?
0168デフォルトの名無しさん2022/09/03(土) 14:36:16.07ID:peyYEDe5
ていうかこいつほんとにRust使ってプログラミングできるの?って思ったんだけど
あまりにも頭が残念すぎて論理的思考の必要なプログラミングができるとは思えない
0169デフォルトの名無しさん2022/09/03(土) 14:49:28.41ID:BHvUMyM5
>>165
Cで書いた方が良い箇所はCで書けば良いのでは
アプリケーション全体を単一言語で書かなければならない理由もなかろう
0171デフォルトの名無しさん2022/09/03(土) 17:17:49.88ID:jD7rh1Hd
TypeScriptは次世代なのか?
そろそろ枯れてきてるし何ならバニラが復権しかけてんだが
0173デフォルトの名無しさん2022/09/03(土) 18:07:45.82ID:k38NcUnV
Rustはスライスに対して境界チェックをしないでアクセスする方法もunsafeで用意されている
つまり最適なプログラミング方法はC/C++を絶対に使わずに全てをRustで記述し
「コンパイラによる安全保証で最適化により安全に境界チェックを省略してくれる部分以外」かつ「人間による安全保証で境界チェックを不要としたい部分」のところのみunsafeで人間が安全保証し
その部分以外は全てコンパイラにより自動的にあらゆるメモリ安全保証させるのが最適な方法となる
0174デフォルトの名無しさん2022/09/03(土) 18:32:15.93ID:5Mn7+zh6
>>137
>>109は RustがC言語より圧倒的に遅いコードです

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

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

>173
109はRust版が10倍くらい遅いんだけどunsafe使ったら早くなるの?
0176デフォルトの名無しさん2022/09/03(土) 19:00:48.70ID:2joIss6C
>>174
わざわざ w = v;  してそんな無意味なプログラムを書く人いないよ
>>92のような実際に使われているパターンの意味のあるプログラム例が欲しいな
0177デフォルトの名無しさん2022/09/03(土) 19:10:31.55ID:UqPpASXs
>>109
これって偶然とか意図に関係なく引数が手に負えなくなると
Rustが全く最適化をしない、というPOCじゃね?

>>92
はhello worldレベル過ぎて逆に意味なくない?
0178デフォルトの名無しさん2022/09/03(土) 19:29:43.18ID:MArlT4a7
>>174
Cのコードを書く必要はない
Rustには一部エリアのみプログラマーに安全性の保証の義務を負わせるunsafeブロックがありCと同じことができる
ベンチも#[bench]等ですぐ比較できるから速さにシビアな場合は本件に限らずアルゴリズムの差異も含めてコストをかけるだろう
その点はどんな言語でも同じ
0179デフォルトの名無しさん2022/09/03(土) 19:37:31.78ID:+aRAkEDC
>>178
>Cのコードを書く必要はない
>ベンチも#[bench]等ですぐ比較できる
いやいやCコードなしにhello sliceどうしでいくら比較しても意味ない。>>174は信頼性の話でしょ
0180デフォルトの名無しさん2022/09/03(土) 20:06:47.23ID:BHvUMyM5
>>174
最適化度合いに一貫性のある言語って何?
Cだろうがasm確認しないといけないのは同じだと思うが
0181デフォルトの名無しさん2022/09/03(土) 20:09:49.33ID:amOq/bcL
>>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は同じ速さで動作する
0182デフォルトの名無しさん2022/09/03(土) 20:17:46.35ID:yFkzTBSQ
>>180
現行C/C++だけがダントツトップレベル
Rustは裏でLLVM使ってるのに何で >>177 で信頼性がないと証明されたんだ...

>>181
あちゃちゃhello sliceと違う書き方をしないといけないなんて、これも無信頼性のPOCだ
0183デフォルトの名無しさん2022/09/03(土) 20:34:30.71ID:0512mxP9
「最適化度合い」ってあれだな
「クイックソートは最悪のケースの計算量が多過ぎる」みたいな
ヒープソート最強伝説に似ている
0184デフォルトの名無しさん2022/09/03(土) 20:45:21.45ID:GmjcSeRW
>>183
ほんとだね。アルゴリズム系は数学的に最悪ケースを予期回避できるのに、Rustの一貫性の無さは最悪
>>181で突然「このように書く」って言われてもPOCの積み増し
0185デフォルトの名無しさん2022/09/03(土) 20:48:32.94ID:nzn5OhxI
>>181
RustはわかりやすくシンプルにプログラミングできてCと同じ速度なのが素晴らしいね
0187デフォルトの名無しさん2022/09/03(土) 20:52:15.80ID:jD7rh1Hd
Rustをむやみに褒めてるやつがアホすぎてRustのネガティブキャンペーンにしか見えない件
0188デフォルトの名無しさん2022/09/03(土) 21:07:27.69ID:ze3FTyL9
こういう争いは同じレベルのやつ同士でしか起きない
お互いに相手がアホだと思ってるけど両方同レベルのアホ
0189デフォルトの名無しさん2022/09/03(土) 21:10:15.24ID:amOq/bcL
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言語バージョンと同じ動作をし
同等のアセンブリコードが生成されることも確認できる
0192デフォルトの名無しさん2022/09/03(土) 21:25:28.83ID:jfkeSYrB
Cだと速いけどRustだと遅くなるケースって存在しないの?
誰かそういう例を作ってほしい
ここまでRustがCと同じ速さで書ける例ばかりだから
0194デフォルトの名無しさん2022/09/03(土) 21:34:03.97ID:hQBDJOi4
>>192
はい。Rustは一貫性がない(>>177,>>182)ので個別にCコードと比べて
書き方を変えることにより同程度にもって行ける
ケースが稀にあることが証明されました
多大な努力の結果です。感謝
0195デフォルトの名無しさん2022/09/03(土) 21:55:58.00ID:wxRR+ldD
Rustはfor文自体がイテレータを使うから、
for i in 0..s.len() {
  println!("{}", s[i]);
}
とインデックスを使う書き方をするのは非常に稀で、
これはインデックスを使わず、
for n in s {
  println!("{}", n);
}
と書くのがRustでは普通だから、
インデックス議論自体があまり意味のないものに思える。
そしてどちらの書き方をしてもCコードと同速度。
0197デフォルトの名無しさん2022/09/03(土) 22:19:33.41ID:V+KjjP+f
>>196
それは単なる人口差・マニュアルやサンプル数差
C++に次いで多いのが言語としてはかなり遅いPythonなのを見ても分かる通り
0198デフォルトの名無しさん2022/09/03(土) 22:30:44.07ID:0512mxP9
まあ、型を正確に宣言しても速くならないし遅くなるというのがもし本当なら
バニラJSが復権するのもPythonが支持されるのも当然といえば当然
0199デフォルトの名無しさん2022/09/03(土) 22:31:15.35ID:pNlcpp9D
>>196
解説本がc++が多いからかな
0201デフォルトの名無しさん2022/09/03(土) 22:38:11.41ID:DRQBO0l9
Rustはコーディングに時間がかかるから競プロでは使えない。
競プロにC++とPythonは良い選択。
0202デフォルトの名無しさん2022/09/03(土) 22:41:39.07ID:nzn5OhxI
>>200
競プロでもRustが速いね
0203デフォルトの名無しさん2022/09/03(土) 23:18:47.73ID:mp8eZIVB
>>196
そもそもC++もちゃんと書けるとは言えないでしょ
mainとグローバル変数しか使わないし
0204デフォルトの名無しさん2022/09/03(土) 23:28:32.01ID:DRQBO0l9
他言語を貶しても、Rustが使える言語にはならない。
0205デフォルトの名無しさん2022/09/03(土) 23:28:44.38ID:Ej5h9pmc
>>200
Pythonを選んだ時点でPyPy3にしたとしても負け戦が確定かよ
Rustは競プロでも強いのか
0206デフォルトの名無しさん2022/09/03(土) 23:33:58.57ID:SEYCHGY8
>>200 懐かしいなあ
ttps://ビット.ly/3CS8AuV
トップのuzzyさん始めC++勢がじわじわ最適化を進めているのがカッコイイ
ちらほらいるRust勢は一発屋だけでインクリメンタルな最適化が出来ていないね。
Rustは一貫性がない(>>177,>>182)から下手に弄れなかったのかな?
0209デフォルトの名無しさん2022/09/04(日) 00:08:42.58ID:yt7jdRkq
>>206
インクリメンタルに最適化したと本気で思い込んでる?
uzzyの上位4つとも全てソース同じまま変化していない
つまり何度も同じのを提出してトライしただけ
0210デフォルトの名無しさん2022/09/04(日) 00:27:20.06ID:ULs4IOBU
で、その競プロでのc言語での参加率はどれくらい?> cオジ
0211デフォルトの名無しさん2022/09/04(日) 00:31:23.21ID:ygllKmJ5
4回ともC++コード同じだな
ただしその一つ前だけコードが違っていて二次元配列を一次元へと書き換えて改善してる
一方でRustの人は最初から一次元にしてるからその改善が必要なかった
つまり>>208はRustを叩きたいだけの完全に的外れ
0212デフォルトの名無しさん2022/09/04(日) 02:03:59.28ID:1GJgU4m+
たぶん必要なのは
葡萄を食べるべきでない理由ではなく
食べない自由なんだな
0213デフォルトの名無しさん2022/09/04(日) 08:04:17.58ID:IySRHUNr
>>200
プログラミング言語間の速度差が激しくて勝負にならないな
競プロで勝つためにはRustかC++を選ばざるを得ないのか
0215デフォルトの名無しさん2022/09/04(日) 08:19:18.55ID:ftO7cI3V
>>200
Rust最速レベルやん
てかC++の分布笑えるな
ギリ合格からトップクラスまでみっちり
0216デフォルトの名無しさん2022/09/04(日) 10:34:00.57ID:RQxkFcRF
本日のRustあげ会場はこちらですか?
0217デフォルトの名無しさん2022/09/04(日) 11:16:04.09ID:ubNPliW5
貶めれば誹謗中傷かも知れんけど、ほめれば気持ち悪いだけ
こんなの消去法でほめるに決まってんだろ
0218デフォルトの名無しさん2022/09/04(日) 11:23:49.03ID:YUzYugU5
参加者自体はRustも多い。
C++と同じくらい居る。
時間内に提出できる人が少ないだけ。
0220デフォルトの名無しさん2022/09/04(日) 11:52:32.99ID:r6qlMaZb
普通にガチ勢は昔からC++を使ってて今さら他の言語にしないというだけだろうな
0221デフォルトの名無しさん2022/09/04(日) 12:28:01.29ID:1n1CTU4P
CオジはCとC++比べてもやっぱCの方が早いからC++はダメとか言うのかな?
0222デフォルトの名無しさん2022/09/04(日) 12:29:11.61ID:RQxkFcRF
ダメな香具師が描いたダメなC++コードは本当に糞
Cのがマシ
0223デフォルトの名無しさん2022/09/04(日) 12:57:20.84ID:r6qlMaZb
>>201
Pythonはよほどうまくチューニングしないとすぐ時間制限越えるんで競プロだと使い物にならないんですわ
>>200のグラフから実行時間でのランキングができそうだけどぶっちゃけ時間内に結果が出れば速かろうが遅かろうが大差無いのでPython以外なら何使ってもいい
言語よりプログラマーの能力が大事だし、それよりむしろ暇の方が大事
とにかく参加し続けてなるべく正解を出してれば上位に行ける
0226デフォルトの名無しさん2022/09/04(日) 14:04:04.57ID:ubNPliW5
行列の和と積を英単語ではなく記号で書けるだけでC++と互角みたいになったのがPython

argv + 1000000 がnullを返したり計算中に例外を投げる実装が可能なだけでRustと互角になれる
0227デフォルトの名無しさん2022/09/04(日) 14:42:33.66ID:RQxkFcRF
何と戦ってるのか知らんがイミフな基準
0228デフォルトの名無しさん2022/09/04(日) 14:46:33.79ID:Pinnb9nG
>>223
うーん、いろんな言語で競プロやってる青色だからついコメントしたくなってしまう

CPythonは知らんけど、pypyは実行速度速いからマラソンでもなければ困ることないよ
再帰がしんどいと言われる問題も、コドフォではよく使われてるbootstrapデコレータを使えば簡単に解決する
Rustはusizeの扱いのために余分なコードが必要になることが多かったし、クロージャ使おうとすると引数の型とかめんどいしで、最近は専らPythonを使ってる
Pythonはクロージャを短めに書けることも競プロ的には気が楽だな
0229デフォルトの名無しさん2022/09/04(日) 15:31:08.56ID:YUzYugU5
Rustは競プロに向いて居ないからな。
避けるのが賢明。
0230デフォルトの名無しさん2022/09/04(日) 15:33:36.35ID:+XXjYupQ
複オジと
複オジにマジレスしちゃう人と
その両方を焚き付けて喜んでる人の三人でお送りしています
0231デフォルトの名無しさん2022/09/04(日) 16:44:07.43ID:nQgfFYZJ
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);
文末セミコロンで複数行に分けても、理解しやすいという話はどこに行った?使いやすさを求めては
イケないんだろうけど、どうもね....
0233デフォルトの名無しさん2022/09/04(日) 17:40:27.34ID:YUzYugU5
韓国で最も愛される言語と銘打てば流行るのでは?
0234デフォルトの名無しさん2022/09/04(日) 17:47:06.26ID:rbLH55CO
>>231
わざと面倒臭くさせてることに意味がある
その辺りの思想は今までの言語とは違うかもしれん
0235デフォルトの名無しさん2022/09/04(日) 17:48:26.12ID:qbvnu5SJ
>>231
>Cが普通はintインデクスなのに
そんなルール無いよね?
仕事で他社さん作ライブラリがuint使ってたことある。
0237デフォルトの名無しさん2022/09/04(日) 18:17:28.78ID:6TwASNhD
競プロではRustは間違いなく最速レベルだし、proconioみたいなマクロを使えば入出力もめちゃくちゃ扱いやすい
でもまあそれ以外のとこでかなり慣れがいる
0239デフォルトの名無しさん2022/09/04(日) 19:10:58.79ID:brj4MXrP
>>231
インデックスやその長さはusize型で絶対に正しい
まずインデックスは負の数になってはいけないからunsigned型
サイズとしてはポインタなどと同じそのCPUで使われるサイズでなければならないからusizeとなる
そして実際のほとんどの様々なプログラミングにおいてインデックスはusize型で上手く動く

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

例外のもう一つは一部の数値アルゴリズムでプログラミングする上で一時的もしくは最初あるいは終端で負の数になると便利なことがある
もちろんその一時的な負の数である時ははインデックスとして使われないようにプログラマーの責任でプログラミングしてインデックスとして使う時はas usize
0240デフォルトの名無しさん2022/09/04(日) 19:29:23.15ID:OkswyjL5
浮動小数点数から符号無し整数へキャストする命令なくね?
最近の処理系は直接キャスト出来るようなったん?
0241デフォルトの名無しさん2022/09/04(日) 19:44:58.67ID:brj4MXrP
>>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をできる限り少なくするのがプログラミングのコツ
0242デフォルトの名無しさん2022/09/04(日) 20:00:50.97ID:wyRxABNd
>>231
Cも配列のインデックス関連は(s)size_tが基本では
strlenやmemcpyの引数や返値はsize_tだし
単にintから暗黙的にキャストできるというだけで

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

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

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

ターゲットを32bit以上のアーキテクチャに限定するした場合はinto()使えるようにするとか、もう少し楽にできないだろうか
0243デフォルトの名無しさん2022/09/04(日) 22:29:03.84ID:rWQ8XHaT
>>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は注視すべきポイントとなる
0244デフォルトの名無しさん2022/09/04(日) 23:03:51.17ID:rWQ8XHaT
>>243の基本を踏まえた上で
例えば16bit環境でなければu32からusizeへのtry_into()は常に成功し安全にunwrap()できる
生成コードも以下のようにコストゼロ
https://godbolt.org/z/cEc5fKGjh

キャストasと同様にunwrapも注視ポイントとなるため
利便性も含めてinlineのto_usize()を用意してしまうのがよいかもしれない
bit環境依存性はそのメソッドに押し込めることで注視ポイントが散らばるのを防げる
0245デフォルトの名無しさん2022/09/04(日) 23:05:01.26ID:ULs4IOBU
危険のある操作は面倒にするべきなんだよ。
0246デフォルトの名無しさん2022/09/04(日) 23:23:22.66ID:nQgfFYZJ
>>239
それ絶対に正しいとは言えてないよね
下のほうに書いてるんだろうけど、よくある別の言語仕様だと、a[-1]が末尾を表したりできるし、数多くの言語でインデックスループだと
これもよくある相対位置やインデックス演算でa[i-1]とか書くけど、usizeをキャストしてi32にしてもう一度、スライスにアクセスするために
as usizeとか2回キャストを行う。これがどれほど醜くなるし、めんどくさくて労力を要するか
当然、メモリアドレッシングが0x00〜上に伸びていくことなんて言わなくてもわかるが、それが合理的であり、かつスライスがusizeで
支持できる理由かといえばどうだろう?少なくとも私はメンドクサイ
またもちろん、(a, b) = t がタプルのアンパッキングなどに使えるのも知ってるけど、それとまとめて変数の宣言と初期化を少ないタイプ量で
出来る話とは別だろう、上からアドバイス頂いてるようでケチをつけて申し訳ないけど、もちろん不変性はマルチスレッドでも有利だしコードの
リファクタリングなどもし易い、ファンクションの変更が良くわかる(そのくせ同じ変数名で別型再定義できたり)とか色々利点があるのは
当然分かってるけど、これもまたmutを多数宣言しなきゃならない時とは全く別の話だよ
0247デフォルトの名無しさん2022/09/04(日) 23:56:45.66ID:C1tkKKn6
>>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
}
もちろん最適化によりアクセス時のインデックス境界チェックは無くなります
0249デフォルトの名無しさん2022/09/05(月) 00:34:33.72ID:BTzrk4g4
>>241
Rustはletとmut指定を分離することでそのようにできるから大成功だな
mut指定が分離していない言語ではそのようにすることができずいつも困っている
方法がないからimmutableで十分な変数も含めてまとめてmutableな変数宣言にせざるをえない
初めて知ったときRustはよく考えられているなあと感動した
0250デフォルトの名無しさん2022/09/05(月) 00:43:43.47ID:+21R+/VD
>>246
・Rustは、数値リテラルに多くの言語ある固定の型がなく、文脈によりu32とかi32とか変わる(型推測)
・下のほうで境界チェックがないのも1..a.len()としているから
当然ながら、これは胸を張って一貫性があるとは言えないがa[-1]は言語仕様ではコンパイルエラーになるが
for i in 0..a.len()とすれば境界チェックが入り実行時にpanicする
君が勘違いしてるのはa[i+b]とかはbを宣言した場合、as castが必要で、色々ごっちゃになってるYO

アンダースタンド?w
0251デフォルトの名無しさん2022/09/05(月) 00:44:27.92ID:ARttffD1
C++は型の特性を調べて、ユーザーがconst性を利用したバージョンの実装を生み出すことができる。
しかも利用時には、型の特性によってコンパイラにどのバージョンを使うか選択させる事が出来る。
0252デフォルトの名無しさん2022/09/05(月) 00:48:14.12ID:g3RfqaIY
RustもIndex<u32>とか実装はできるよ
標準のsliceに実装されてないというだけで
0253デフォルトの名無しさん2022/09/05(月) 00:55:53.18ID:ARttffD1
C++は、型の計算ができるんですよ。
0254デフォルトの名無しさん2022/09/05(月) 01:07:57.19ID:9iTWKe04
すまん、誰が聖闘士星矢で例えてくれないか?
0255デフォルトの名無しさん2022/09/05(月) 01:12:56.84ID:ARttffD1
>>254
くちから たれている みつは 2きろ はなれていても はなが まがるほど もうれつに くさい。
0256デフォルトの名無しさん2022/09/05(月) 01:19:02.56ID:JbiV7xYP
>>211
一昨日は言葉が過ぎました。開発現場、携わっている人には心無い発言でした。反省してます。
強調したかったのは、最適化って難しいよ、速そうな言語を選んでコンパイラにお任せって言う易しい世界じゃないよ、という事です。

むしろ叩きたいのは、定期的に現れる無意味なRust上げ
スレッドの流れをフォローしている人間にはネガティブキャンペーンと受け取られているコメントです。
うすうす気づいているとは思いますが、これSEO対策なんですよ。
Rustをほとんど知らない人が検索をした時に、
チラッとその一部だけを見せてエコーチェンバーにはめ込むと言う仕掛けです
同様に時々現れる、会話の流れを修正したい時に持ち出す極論、逆説的にRustを卑下する冗談
これはわざとRsutとタイポしてチラ見に現れないようにしている。
複製おじとは別人だと思うのですがどんなんですかね。皆さんの意見を訊きたいな
0257デフォルトの名無しさん2022/09/05(月) 01:22:23.34ID:RaegMrzk
>>246はまともにプログラミングしたことないとまでは言えないが多くの勘違いをしてるのは確かだな
usizeを上に伸びていくと書いてあるから引き算出来ないとでも勝手に思い込んでa[i-1]ができないと勘違いしたのかもしれない
もう一件

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

その件はa[-1]やマイナスのインデックスに意味を持たせたプログラミング言語の仕様ミス
もしくはお子様向け言語であるとの結論が大昔に出ている
プログラミングのミスでマイナスのインデックスとなり本来はエラーでミス発覚となるべきところか不可能となった
つまり言語仕様ミスなのかそんなこと気にしないお子様向け言語なのかどちらかということになる
ほとんどの言語はまともなのでa[-i]はエラーとなり正しくa[len-i]と書く
0258デフォルトの名無しさん2022/09/05(月) 01:34:56.96ID:9oDekVHu
>>257
複製おじ?usizeの議論は微笑ましいですね。盲目的ですが熱意にあふれてます。
速度、最適化に関する盲目的思い込みがなければ無害ですな
SEO対策(>>256)に加担していなければの話ですが
0259デフォルトの名無しさん2022/09/05(月) 01:45:29.53ID:ARttffD1
実力のある者はC++を利用するべきでは?
0260デフォルトの名無しさん2022/09/05(月) 01:57:02.85ID:b0NkdPU/
>>259
同意ですな
一方で熱意にあふれ盲目的で従順に車輪の開発をしてくれるプログラマが
無料で使えるのであれば使わない手は無いとLinus辺りは策略してそう
SEO対策(>>256)もあながち...?
0261デフォルトの名無しさん2022/09/05(月) 02:02:44.86ID:7mfke0+F
欠陥言語C++を使うメリットは何?
今はこれだけ多数の安全な言語があって色々選べるのに
0262デフォルトの名無しさん2022/09/05(月) 02:05:41.16ID:ARttffD1
アセンブラを使う理由はレジスタにアクセスできるから。
これはとても危険。
C/C++を使う理由はメモリーにアクセスできるから。
これはとても危険。
0263デフォルトの名無しさん2022/09/05(月) 02:07:30.95ID:ARttffD1
大いなる力には責任が伴う。
  2019 - アフレシアさん
0264デフォルトの名無しさん2022/09/05(月) 02:14:43.00ID:ARttffD1
早くコンセプトが使いたいわー。
0265デフォルトの名無しさん2022/09/05(月) 02:16:22.39ID:E82kQidM
>>261 もしこの二日間程度のスレッドの流れをフォローしてもなお一つのメリットも見えないのであれば
あなたの長所は熱意だけです。周りを頼って上手に立ち振る舞ってください。

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

>>263 同意 正に実力の世界。去れよ無責任Kids
0266デフォルトの名無しさん2022/09/05(月) 02:33:35.68ID:sgxkT6js
C++にもメリットはありゼロじゃない
ただし世界的には>>154の結論が出ている
そして今回もC++で書かれたChromiumの穴のせいで、それを使うElectronを始め多數に影響が出て、それを使うVScodeにもセキュリティ脆弱性と連鎖
C++を使い続ける限りセキュリティの穴が量産されてしまう
0267デフォルトの名無しさん2022/09/05(月) 02:57:07.57ID:5U2utJMj
>>266
あなたの結論素晴らしいですね。
どうぞLinusあるいはMozillaの元へ
SEO対策(>>256)の一環ですか?

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

ところでFirefoxのthird_party directoryを除いたsource repoでのRustの使用割合ってご存知?宿題ですよ
0268デフォルトの名無しさん2022/09/05(月) 03:10:33.61ID:9iTWKe04
何でもrustでやらんで、安全性第一のとことか機能が優れてるとこ(非同期やジェネリクス、健全なマクロ、パターンマッチ等)とかからでもrustを便利に使ってったらええ。
今のrustは少しずつ実用面で採用を広げて行ってる段階だろ。Linuxでの採用とかさ。
既存のcでやってることをイキなり全部rustで置き換えようとしてる人なんて居ない。
rustにその潜在能力があったもしてもマンパワーが足りない。だから大手は少しずつ小さな分野で使いだしてる、複数の大手でね。
ただrustはもっとc言語との連携が簡単だったらと思う。
0269デフォルトの名無しさん2022/09/05(月) 03:31:45.52ID:hQwE/dE/
>>268
>何でもrustでやらんで、安全性第一のとこ
完全同意 話が合いそう
安全性アピールがマーケティング上有利な暗号通貨系の動きが早かったです

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

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

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

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

>>266 が宿題(>>267)をサボったら手伝ってあげてください
0270デフォルトの名無しさん2022/09/05(月) 03:36:29.05ID:pmwagyd7
>>268
どの言語からどの言語の場合でも既存システムをそのまま言語置き換えはコストだけかかり効率がよろしくない
そのためシステム改修や新規システムを中心にRust採用となっているようだ
現在ある選択肢では人間が引き起こしうるミスをコンパイラに防止させてセキュリティ含む穴を無くしていく言語候補がRustの他にない
0271デフォルトの名無しさん2022/09/05(月) 06:42:39.68ID:ARttffD1
簡単に言えば、Pythonの代わりにRustを使うことはあっても、C/C++の代わりになることはない。
レジスタやメモリーを扱うのは大変危険だから。
0272デフォルトの名無しさん2022/09/05(月) 07:16:47.41ID:yWe543y4
>>271
Rustはinlineアセンブラ記述をサポートしていてレジスタ操作もできることを知らないのかね
Rust叩きの人はなぜ学習せずに無知なままなのだろうか
0273デフォルトの名無しさん2022/09/05(月) 07:22:08.46ID:ARttffD1
>>272
じゃあ安全じゃないじゃん。
0274デフォルトの名無しさん2022/09/05(月) 07:51:21.51ID:928S9Xdp
以前の言語
 ・プログラムのメモリ安全性、null安全性、データ競合安全性をプログラマーの責任で保証する

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

Swift, Kotlinなど
 ・null安全性をコンパイラが保証
0275デフォルトの名無しさん2022/09/05(月) 08:33:46.56ID:HWNfM8e/
>>268
Rustを使うにはガッツリ勉強しないと無理だから……THE BOOK一通り勉強しないと無理だから……
0276デフォルトの名無しさん2022/09/05(月) 09:45:50.25ID:KpRHtzI/
>>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でほぼ同じになるのはなんでなんでしょうか?
0277デフォルトの名無しさん2022/09/05(月) 09:57:13.85ID:DUaqFrRV
>>276
やっぱりおまえアホだな
16行だから速いと思っている??
行数で速さは決まらないが
その例なら16行のコードが無展開で一番遅くなる
0278デフォルトの名無しさん2022/09/05(月) 10:24:45.85ID:vkD3rEEb
>>276
Cでは引数にlenを取り、Rustではlen()を使っていて、両者は全く異なるのに、なぜ、ほぼ同じ生成コードになるのかが分からないって!?
もう少しRustを勉強してからアンチ活動しましょ

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

そしてスライスとしてセットとなっているlen()だからこそデタラメな不正な値が来ることはなく、
コンパイラの管轄下で信頼できる正しい長さ数値情報として扱うことができて、
その長さ未満となるループ内でインデックス境界チェックも安全に省略できるのよ
そのためLLVMによりCのプログラムと同等の生成コードが出来上がります
0280デフォルトの名無しさん2022/09/05(月) 13:38:45.87ID:hgtSwHCO
>>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で数を回せば観測される確かな差が生まれます。
0281デフォルトの名無しさん2022/09/05(月) 13:42:00.23ID:KOsqPsuw
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の方は判りません。どなたか解説お願いします
0282デフォルトの名無しさん2022/09/05(月) 14:12:00.36ID:++1d7Ak5
Java C#などのJIT勢は決まってピーク性能(大きなデータセット,warmup付きのbenchmark)を
アピールしますがピーク性能だけを見ていて十分かどうかは別途判断が必要です。

競プロ目標であれば
>>228の様にいろんな楽しみ方がありますよ
>>226で懐かしいと言ったのは途中で行列の転置をかますことで
劇的に速くなった記憶があるからです。O(数式)ビッグオー レベルで
まだsubmit出来るようなのでお試しください
0287デフォルトの名無しさん2022/09/05(月) 16:32:50.42ID:NIbO6JQn
複オジも昔はコテハン使ってイキってたんだが
恥ずかしいレスを叩かれて匿名複オジに
今でもそのコテハンで書き込んだりもしてる

迷惑だよな
0289デフォルトの名無しさん2022/09/05(月) 19:04:14.83ID:iWQD5HeB
Haskellの時もそうだったけど、世界でアカン空気が流れ始めると、日本で流行らせようと宣伝し始めるのは何でだろな?
0291デフォルトの名無しさん2022/09/05(月) 19:06:21.16ID:iWQD5HeB
RoRの時みたいに、世界で流行るときは、日本ではアカン言うてアンチが増えるんだよね。
0293デフォルトの名無しさん2022/09/05(月) 19:11:19.28ID:iWQD5HeB
このスレで紹介されるRustの良いところって、「定数の索引で配列アクセスする場合は、最適化されて境界チェックが消える、安心安全」だけでしょ?
定数の索引で配列アクセスなんて、一生に一度書くか書かないかくらいなんだから、そんな機能在っても嬉しくないわ。
0294デフォルトの名無しさん2022/09/05(月) 19:12:38.64ID:iWQD5HeB
その点Javaは、実行時最適化でRustの5倍速い。
知らんけど。
0295デフォルトの名無しさん2022/09/05(月) 19:23:11.04ID:g3RfqaIY
>>289
Rustだめな理由知りたいからあかんとされてるブログ記事なりニュースなりフォーラムなり教えて
0296デフォルトの名無しさん2022/09/05(月) 19:28:42.10ID:iWQD5HeB
https://chrisdone.com/posts/rust/
こんなのはどう?

TwitterやRedditは辛辣な意見が多いよね。
クリップしてないけど。
0298デフォルトの名無しさん2022/09/05(月) 19:55:18.42ID:x/Xug50w
非同期関連がごちゃごちゃしてて面倒くさいってのはあるよな
ゼロランタイムコストが売りだから仕方がないんだろうが

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

ライブラリによってAはサポートしてるけどBはしてないとかあって色々面倒くさい
0299デフォルトの名無しさん2022/09/05(月) 20:01:50.03ID:iWQD5HeB
基本的にRustは知られていないんだよね。
日本以外では。
とっくにオワコンだから。
0300デフォルトの名無しさん2022/09/05(月) 20:04:19.99ID:g3RfqaIY
>>296
割とソフトな意見でオワコンとまでは言ってないような
そもそも言語におけるオワコンって何?
0301デフォルトの名無しさん2022/09/05(月) 20:10:04.95ID:iWQD5HeB
Rustなんか構ってる暇あったら、PHPやれよって話。
0302デフォルトの名無しさん2022/09/05(月) 20:13:42.10ID:9iTWKe04
>>301
他部署の人たちのPHPのバージョンアップ追従に毎回ドタバタしてるの見ると関わりたくないなぁと思う。
もちろんそれだけのお金と時間くれたらいいけど、PHPの単価ってそれほどでも無いよね?
0303デフォルトの名無しさん2022/09/05(月) 20:20:47.93ID:kVCZ1c6R
>>293
君は相変わらずデタラメばかり言ってるなあ
定数の索引で配列アクセスしているコードは出てきていない
その件で出ているRustの関数の引数は全てスライスであり配列ではない
つまり始点ポインタも長さも未知のものが引数としてやってくる
さらに定数の索引とはa[5]などの例を指しそんな例も出ていない

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

>>294
Cと同等の速さのRustより何倍も速いプログラミング言語は存在しない
0304デフォルトの名無しさん2022/09/05(月) 20:25:02.75ID:5VtMLQd9
>>300
最後まで読むと結局仕事では使ってるみたいだし
どちらかというと不満がある人でも使うくらいには広まってきている、というべきな気はする
オワコンっていうには他言語に移行したみたいな事例が必要なのでは
0305デフォルトの名無しさん2022/09/05(月) 20:36:11.44ID:e+uJj/tK
>>289
そもそもHaskellとRustに何の関係があると思った?
異なる言語って普通ならどうしようもなく分断されていて全く無関係な筈じゃないのかね

分断を回避する秘訣でもあるのか
0306デフォルトの名無しさん2022/09/05(月) 20:50:10.83ID:Xf3ARiO4
>>296
読んだけど少し偏った思想の人なだけだった
「いずれRustでガベージコレクターが人気になると予想する」とか今後も極一部の用途以外では使われないだろう
「XXXをRustで書き換えたら速くなったというのはRustのせいじゃない」は安全かつ速くなった利点を理解していない
「良いメンテされたコードを書いてるメンテナーは非同期を採用することに抵抗がある」は用途に応じて使い分ける人が正常なので抵抗なんてない
Rustを批判する人はちょっとおかしな人が多いと感じる
0309デフォルトの名無しさん2022/09/05(月) 21:39:30.67ID:wI2HBmBd
>>305
Haskellはガベージを撒き散らしながら計算を進めるからRustとはその点で真逆な存在かな
強いて言えばHaskellの型クラスとRustのtraitが基本思想の一部で似てる程度
そのRustとHaskellを叩いてる人はどうせ何も理解していないでしょう
0310デフォルトの名無しさん2022/09/05(月) 21:58:07.88ID:59/nx/yB
例えばRustでhttpクライアント使いたかったからhyperやらreqwestやらsurfやらサードパーティのライブラリを使うことになると思う
別にこれでもいいが他人のコードを読む上で共通のコードが出てくるってのはかなりアドバンテージがある

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

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

ということで標準ライブラリが強力ってのは実用的なソフトを複数人で作っていく上で非常に重要
0311デフォルトの名無しさん2022/09/05(月) 22:16:25.49ID:LJb2ynoL
>>310
hyperとreqwest/surfはレイヤーが異なり比較する対象でないからそこで例として持ち出すのは適切ではないね
あと標準ライブラリの範囲や意味するところは言語によって異なるのだからあまり意味のない議論だと思う
その思想だとあらゆるものが標準ライブラリにあり他のライブラリを一切使わない言語が最上となってしまう
それぞれにメリットとデメリットがあります
0312デフォルトの名無しさん2022/09/05(月) 22:16:42.44ID:e+uJj/tK
実用品かどうかの定義が難しいけど
ほぼ原価で買える物は実用品と認定されやすい
原価より高い物は実用的ではない無駄な要素が入っている疑惑や誤解を招きやすい
0313デフォルトの名無しさん2022/09/05(月) 22:20:06.23ID:5dvrlWbj
しかしRustへの注目度たかいなw
もう実質 Rust vs その他次世代言語って感じw
0314デフォルトの名無しさん2022/09/05(月) 22:33:58.90ID:g3RfqaIY
Rustがオワコン言うからGitHubのPullReqに占める言語毎の割合のデータ見てみたけどTypeScriptとGoが圧倒的ということが分かった
Nimは残念ながらランク外、他はだいたい横ばいみたい

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

GitHub全体のPullReq数も増加していると思われるので、個々の言語の利用者の増減を見るには不向きなデータかも
割合じゃなくて言語毎のPullReq数が分かるサイトがあったら教えて欲しい
0315デフォルトの名無しさん2022/09/05(月) 22:39:25.77ID:LWnBOcCn
利用される分野が違う言語を比較して、なんの参考にしたいんだろう
分野は気にならんの?
0318デフォルトの名無しさん2022/09/05(月) 22:49:48.10ID:TWq6epN6
GoとTypescript書ければ仕事には困らないな、うん

Rustは仕事の需要はないけど趣味やOSS活動でやる分にはいいかもしれない
0320デフォルトの名無しさん2022/09/05(月) 23:11:05.60ID:LWnBOcCn
このスレは言語機能そのものについて語るスレだと思ってた
人気について話したいひともたくさんいるんだろうけど
0322デフォルトの名無しさん2022/09/05(月) 23:26:43.28ID:iWQD5HeB
Rustはオワコンだから使たらアカンやで。
0323デフォルトの名無しさん2022/09/05(月) 23:27:36.08ID:9iTWKe04
>>311
全てを最初から用意するのは不可能だけど、標準ライブラリで事足りるってのは利用側としてはメリットでかいぞ。
もちろんrustがあえてコア重視してるのはわかるが、お陰で非同期とか今時普通なものも乱立してる。
0324デフォルトの名無しさん2022/09/05(月) 23:31:48.82ID:iWQD5HeB
Rsutと云う泥船に乗せて一緒に沈没させようとしている奴らが居る。
どこの教団や!?
0325デフォルトの名無しさん2022/09/05(月) 23:33:58.91ID:9iTWKe04
>>324
はいはい、おじいちゃんもう寝る時間よ。
0326デフォルトの名無しさん2022/09/05(月) 23:36:58.16ID:iWQD5HeB
Redditの今年最悪の言語に早くもリーチかけてるからな。
0328デフォルトの名無しさん2022/09/06(火) 00:00:31.26ID:bpHcrLU1
>>318
俺は趣味ならnimにちょっと興味ありな感じ。まだ全く手は出せてないけど。
0329デフォルトの名無しさん2022/09/06(火) 08:19:45.27ID:AHhd6ypa
>>321
コンパイラの内部構造とかは勉強になるな。メモリ管理は種類多すぎな気もするが。
0330デフォルトの名無しさん2022/09/06(火) 09:44:45.25ID:9WMtC8UL
>>322
Rubyのことなら同意
0331デフォルトの名無しさん2022/09/06(火) 09:47:23.91ID:eR9fijNj
Rust使えない癖に持ち上げまくってるキチガイとRustとRubyの区別のつかないやつが論争する地獄のようなスレ
0333デフォルトの名無しさん2022/09/06(火) 10:30:10.58ID:eR9fijNj
CのライブラリとJavaのライブラリと.NETが使えてWebAssemblyも記述できる言語ができれば最強
と思ったけどそれってC#やF#じゃん
0336デフォルトの名無しさん2022/09/06(火) 10:54:20.03ID:eR9fijNj
>>335
誤差
10の13乗ものループでそれだけのミリ秒数しか違いが出ないということは実際にその違いが問題になることはほとんどない
0337デフォルトの名無しさん2022/09/06(火) 10:55:43.20ID:eR9fijNj
要するにそのグラフの差は五十歩百歩でしかなくそれ以上の速度が必要ならスーパーコンピュータを視野に入れることになる
0338デフォルトの名無しさん2022/09/06(火) 11:22:14.85ID:7s2bxSL8
スーパーコンピュータなら速く動くとかいうことは全くないけどな
なんならオーバークロックしたゲーミングPCとかのほうが速い
スパコンはPCではそもそも実行不可能なレベルの超大規模な問題を解くためのもので
普通のプログラムが魔法のように速く動くという代物ではない
0341デフォルトの名無しさん2022/09/06(火) 12:01:26.94ID:6ZyYoNhQ
>>339
温すぎて笑う
ブルートフォースで解けるレベルじゃん
PaizaのAランクの話でもしてんの?
0342デフォルトの名無しさん2022/09/06(火) 12:04:20.22ID:6ZyYoNhQ
>>338
競プロの問題は並列化で速く解けることも多いからスパコンの得意とするところだぞ
0343デフォルトの名無しさん2022/09/06(火) 12:31:10.58ID:QxRWO4Sk
Ruby は遅いから、1秒で100万回ループ。
これがJIT で、1千万回になる

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

外部にアクセスせずに、延々と行列演算を繰り返すような、
CPU セントリックな処理では効果があるのかも
0344デフォルトの名無しさん2022/09/06(火) 12:45:16.87ID:9WMtC8UL
Nimは始まる前に終わりそう
がんがれ
0345デフォルトの名無しさん2022/09/06(火) 14:09:11.24ID:0lLJmQPI
>>342
実際のスパコン触ってみれば分かるんだけど、競プロの問題って小さすぎて並列性がなさすぎるんよ
1秒以内で終わっちゃうようだとMPIのコストどころかGPUにオフロードするコストすら回収できるか怪しい
0347デフォルトの名無しさん2022/09/06(火) 14:47:11.13ID:Uhu0FGeL
Amazonが>>9の記事で書いているように
C/C++/Rustで書けば2〜10倍は速くなり
それは電気代やCo2排出も同様になる
さらに省メモリになる点も考慮すると
サーバーやクラウド利用コストは確実に数倍差
言語の選択を変えるだけで支出も激減
0348デフォルトの名無しさん2022/09/06(火) 14:57:13.57ID:zHtqeu+H
ハードウェアアクセスの速度が変わらんのにベンチマークだけで胡散臭いこと言うなよ
0349デフォルトの名無しさん2022/09/06(火) 15:08:57.93ID:gWeaoLnz
>>346
並列性がないというか、並列化しても元々の実行時間が短いからオーバーヘッドが大きすぎて割に合わないという話では
スパコンのジョブって短くても実行時間数十分だったりするから競プロとは前提が違う
0350デフォルトの名無しさん2022/09/06(火) 15:28:54.40ID:VRQQIzRo
元々の問題設計がN^2で失格 NやNlogNオーダーで通るようなってるとしたら
N^2で並列化出来てもTLEだわ
0351デフォルトの名無しさん2022/09/06(火) 15:49:30.99ID:hbXRPtoA
誰でも思いつくのはGCの並列化だが
GCは何言語で書かれているのかを誰も知らない
0352デフォルトの名無しさん2022/09/06(火) 17:20:08.41ID:ri7pjbsX
コンパイル型の実行速度でスクリプトでも実行でき、コンパイルもできる言語が欲しい。反対を言えばbashのように
1行ずつ実行し、実行中で書き換えられることまでは必要ない。
単純なスカラーのループを書いたら、一台のCPUのレジスターだけをブン回す機械語のコードが生成されて欲しい。
A*Bと書くだけで千の計算を搭載されているメジャーなGPUで勝手に計算したり、あるいは千のマシンに分散して
実行して巨大な行列の積をポンと計算してもらいたい。
型だって必要ないなら指定したくない。もしポリモーフィックな関数が必要な時には、ジェネリックプログラミングを
使ってアルゴリズムを一度だけ書いて、あとは全ての型に使いたい。
ガーベージコレクション、あるいはメモリーマネージメントは循環参照や多重参照がなければRustのようにスコープを
抜けたら基本は消えるだけで十分でもあるが、循環参照をもったら自動でサイクリックGCも欲しい
並列化、あるいは非同期化に余計なコストを払いたくない、async/awaitなんてもってのほか論外、世紀の間違い。
ErlangやGoのようにspawnやGoで軽量プロセス起動は仕方ないにしても、これは必須ではなく、デコレーションで
あって並列ではなくとも動ける控えめなヒント情報であってほしい
ドライバ、あるいはOSやカーネルなどのハードウェアよりな開発にも利用できてほしいけど、例外あるいはpanicも欲しい
0353デフォルトの名無しさん2022/09/06(火) 18:45:34.78ID:txnX2wDb
Amazonの言うこと信じる人もいるんだ。
そりゃ霊感商法もなくならないわ。
0354デフォルトの名無しさん2022/09/06(火) 18:50:05.82ID:iU1ybZ8L
GCしないでプロセスごと捨てるのがスマートよ
0355デフォルトの名無しさん2022/09/06(火) 20:47:28.58ID:NO/n5LTM
>>321
https://nim-lang-081.osdn.jp/docs/tut1.html
> # 前方宣言:
> proc even(n: int): bool

前方宣言てw
これ書かされる言語まだあるんだ

> プロシージャで呼び出し元の引数を変更する必要があるならば、 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を書く
0356デフォルトの名無しさん2022/09/06(火) 21:02:15.19ID:+TeoQt4K
>>355
immutableかmutableかの区別宣言は絶対に必要だから
あとは各言語でそれをどのように表現するかだけでしょ
それをvar val let const など各言語で色んな表現の使い分けがあり更に引数でどうするかだけ
>>241のケースも考慮するとRustのmut付加方式がベストな解決かな
0358デフォルトの名無しさん2022/09/06(火) 21:17:25.60ID:MV3crhGe
ponylangだとbehaviorが終わるごとに該当アクターでGCを回すからプログラムとしては停止しないんだけども、これを並列GCですって言うのもなんだかなといった風情
0360デフォルトの名無しさん2022/09/06(火) 21:31:19.57ID:ItiT2cL1
MPIバリバリ使ってるけど競プロの問題を解くようなタスクでは使わないよ
課題設定があまりにも違い過ぎる
0361デフォルトの名無しさん2022/09/06(火) 21:37:52.05ID:6CvxnJgX
>>357
Rustはその2種類の区別もmutの位置で区別できてるね

①引数が値渡しで来て関数内で値を書き換える場合
例: fn func1(mut x: i32) { …
 →値渡しなので呼び出し元には影響なし

➁引数が参照渡しで来て関数内で参照元を書き換える場合
例: fn func2(x: &mut i32) { …
 →可変参照渡しなので呼び出し元の対象は書き換わりうる
0362デフォルトの名無しさん2022/09/06(火) 22:22:04.19ID:jOWG7AxE
あんた上手に振る舞えって言われてたやつだろ
Rustは出来るじゃねえよw 当たり前だ
お前が議論を理解出来てなかっただけだろ
そういうところが周りをイラつかせてるんだぜ
0363デフォルトの名無しさん2022/09/06(火) 22:30:02.86ID:NO/n5LTM
>>361
> Rustはその2種類の区別もmutの位置で区別できてるね

二種類の区別?

> 例: fn func1(mut x: i32) { …
> 例: fn func2(x: &mut i32) { …

これリファレンスかどうかってmutの位置関係ある?
Rustよくわからんけど & つけたらリファレンスになるだけじゃないの?
何の話を俺にしたいの?

>>359
Nimの参照渡しの表現に見覚えあるわってレスしただけなんよ俺はw
0364デフォルトの名無しさん2022/09/06(火) 22:34:57.09ID:2HxKYUoj
Rustだと両方ができて当たり前だが
プログラミング言語の中には
値を渡すか参照を渡すかをプログラマーが選べない言語も意外と多い
全てがどちらかに決められていたり
型によって各々どちらかに決められたり
メジャーな言語でも制限があったりする
0365デフォルトの名無しさん2022/09/06(火) 22:40:49.84ID:V53xvAGb
>>363
Rustは2種類の参照渡しがある
Tを参照元の型とすると
&T が(可変じゃない)参照
&mut T が可変参照
だから貴方が書いた>>355の話と同じじゃないかな
0367デフォルトの名無しさん2022/09/06(火) 22:44:16.65ID:NO/n5LTM
パスカル書いてた人なら
「パスカルなついw 引数んとこにvarって書いてたなw」
で終わる話
皆の衆なんか混乱させてすまんかったな(´・ω・`)
0369デフォルトの名無しさん2022/09/06(火) 22:53:11.35ID:tijl2CjL
複オジに相手にしてもイライラするだけやぞ
もう少しスルー力の鍛えようや
0370デフォルトの名無しさん2022/09/06(火) 22:53:17.60ID:2HxKYUoj
可変参照を渡すか可変じゃない参照を渡すかの区別がない言語もある
区別がある言語でもさらに2種類に分かれて
呼び出される関数でその参照が可変かどうか区別するだけの言語と
呼び出し側でも渡す参照が可変かどうか区別できる言語に分かれる
それら3種類のうち最後のタイプの言語が最も安全にプログラミングできる
0372デフォルトの名無しさん2022/09/06(火) 23:04:31.77ID:V53xvAGb
&Tを渡すか&mut Tを渡すかを渡す側で区別できない言語だと書き換えられちゃうのか分からない点で困るね
その場合でも呼び出す関数の引数宣言を見に行けばいいけど、そこにも可変かどうか宣言できない言語もあって絶望的なことも
0374デフォルトの名無しさん2022/09/06(火) 23:12:00.01ID:p3/oNdmv
その点もRustが一番考えられてる仕様のような
色んな言語の中で一番ちゃんときちんと区別してくれていてプログラミングする上で安心感もあるなあ
0376デフォルトの名無しさん2022/09/06(火) 23:23:59.02ID:MV3crhGe
ponyなら書き込みどころか読み込みまで制限できるぜ
参照の持ち方だけで6つもあるのやばいだろと思ったが減らせる見込みもないぜ
0378デフォルトの名無しさん2022/09/06(火) 23:29:15.38ID:ItiT2cL1
Nim好きなんだけど何で売れんかね
pythonからの乗り換えに最適なんだが
0379デフォルトの名無しさん2022/09/06(火) 23:30:19.86ID:ZgGRtw1t
よく考えたらこれも組織票野党が投票率下がった方が有利なように、スレ乗っ取りの下地作り?
>>369複?オジ?
0380デフォルトの名無しさん2022/09/06(火) 23:30:47.03ID:3jr2SH77
ponyとか真面目な話がしたいならワッチョイスレ行ったほうがいいよ
複おじをいじって遊びたいならここでいいけど
0381デフォルトの名無しさん2022/09/06(火) 23:34:47.24ID:V53xvAGb
昔は変数もmutableとimmutableの区別をしないのが多数派だった時代もあったそうだから
新しく作られた言語のほうが色々と新たな進化ができて有利なのかもね
0383デフォルトの名無しさん2022/09/06(火) 23:39:56.37ID:W/Xh3l1r
>>376
マジ?
ponyで読み込みを制限して書き込みのみにするのはどの修飾子を使えばいいの?
0385デフォルトの名無しさん2022/09/06(火) 23:50:57.29ID:ZgGRtw1t
>>381そうそう設計時点での思想って重要 増改築は面倒だから でも増改築できる柔軟性も必要

そろそろ落ちます tag付けhelp us pls
0386デフォルトの名無しさん2022/09/06(火) 23:55:28.57ID:k32oXi62
Ponyで参照はsingle writer xor multiple readersが課されているためwriterがいる時は読み込みができない
つまりRustと同じ
0387デフォルトの名無しさん2022/09/07(水) 00:17:09.26ID:ordz3g2+
>>383
食いつかれると思ってなかったから少し語弊がある書き込みだったかもしれない
ponyは変数ごとにReference Capabilityという修飾子を持ってて、それで読み書きと変数をコピーしたときの権限を管理してる
読みを制限しながら書き込めるのはisoとtrn

>>386
Rustって変数の参照を作らせないって設定はできるんだっけ?
あと読み書きしないけど値の存在だけは確認したいときってどうすんの?
0388デフォルトの名無しさん2022/09/07(水) 00:39:18.74ID:8j1OJp6D
ほとんどの言語はオブジェクトとかヒープで確保したものとか参照のみサポートが多いよね
参照を作らせなかったらどうやってアクセスするのだろう
移動しかないか
0390デフォルトの名無しさん2022/09/07(水) 02:20:15.23ID:NRm/XQ9U
Rustなら&selfメソッドを作らずにselfメソッドだけを用意すれば
その型は参照に対して全く働かずに移動に対してのみ使える型にすることはできるな
もちろんそのままだと移動で消費してしまい消えるのでそれを避けたい時Selfで再び自分を返すことになる
不便だが参照を全く使わずともその範囲で色々やれるようだ
0392デフォルトの名無しさん2022/09/07(水) 03:01:09.81ID:NRm/XQ9U
>>391
参照を使わないなら値そのものを移動するしかないだろ
他に何を期待してるんだ?
0394デフォルトの名無しさん2022/09/07(水) 03:08:26.53ID:FVgAnmdd
ははぁーん

聞かれたことに答えない
息をはくように話をそらす
それた話を修正しない
そもそも何を聞かれたかわかっていない

これって?

もしかして国語で苦労した?
tag付けて欲しい?
0396デフォルトの名無しさん2022/09/07(水) 03:25:07.36ID:Lg2r352+
それた話を修正しない

Goスレで論破されて敗走してきたんだ
でここに居つくために育成ゲームだとホザキ始めた
0397デフォルトの名無しさん2022/09/07(水) 04:13:08.28ID:2H+EvabS
なんのことやら
参照を全く使わないのは無理だけど
単独参照となり読み書き自由に専有できるのならあるよー
Ponyならiso
Rustなら&mut
0398デフォルトの名無しさん2022/09/07(水) 04:15:54.48ID:GNmKbNsR
そらした話は修正しない
そもそも何を聞かれたかわかっていないフリ

Flutterスレ盛り上げてこいよ
0399デフォルトの名無しさん2022/09/07(水) 05:49:18.66ID:a/SEXojX
誰にも参照されてないのにGCされない現象を実現したいわけではなさそう
ということは「参照を作らせない」とはいえ参照は作れるんだよね
0400デフォルトの名無しさん2022/09/07(水) 05:54:23.55ID:OvNIIrS4
そらした話は修正しない
すり替えた土俵ではRustと〜は同等
そもそも何を聞かれたかなんて知らない。無意味 気持ち悪い
参照とかGCの事は実はよく知らない。育成してくれ

Flutterスレ盛り上げてこいよ
0401デフォルトの名無しさん2022/09/07(水) 06:26:49.06ID:t2gi/CWf
>>378
Pythonで十分だからじゃね
情報の多さが違う
Pythonは遅いのが欠点だけど遅いのが問題になることってそんなにないんだよねえ
0402デフォルトの名無しさん2022/09/07(水) 06:52:15.00ID:ordz3g2+
>>390
Rustの構造体は中身が非公開だからメソッド制限でいけるのか
失念してたわ
あとはtrnあたりの挙動を再現できるかだな

>>397
&mutだと新しい読み取り専用の参照が出てくるの防げなくない?
0403デフォルトの名無しさん2022/09/07(水) 06:53:00.83ID:nA6d9voX
どうしても速さが必要なところだけRustにするとしても
それ以外はPythonで十分な気がする
0404デフォルトの名無しさん2022/09/07(水) 07:00:12.32ID:7SEt3XdA
>>403
実は速度の事、よく知らない
つい先日 自動ベクトル化とかSIMDとか育成された。育成を要求した俺すごい

Flutterスレ盛り上げてこいよ
0405デフォルトの名無しさん2022/09/07(水) 07:13:06.99ID:+WGAm7/P
>>386 >>397
GoスレでSIMDをふりかざしたのに論破された。更なる育成を要求する

Flutterスレ盛り上げてこいよ
0406デフォルトの名無しさん2022/09/07(水) 07:16:05.47ID:hRBB26Yn
>>402
弱くなる方向は何も問題無いでしょう
しかもRustは参照のライフタイムもコンパイラが管理把握できているため大丈夫でしょう
Ponyはその分をプログラマーが細かく指定して更にrecoverなど変化させていくことで補うわけです
0407デフォルトの名無しさん2022/09/07(水) 07:18:00.16ID:ordz3g2+
>>399
ponyだとどの変数も参照だから最初の参照は作れる
で、その参照から新しい参照を複製するときに複製さきの権限を制御する

Rustだと最初に作る変数は値のはずだから雑に変えてる
0408デフォルトの名無しさん2022/09/07(水) 07:21:36.81ID:6xyGFf7w
>>406
Rustはコンパイラが管理で安全 Pnoyはプログラマーの責任
Rustスレでビット幅なんて間違えていない。コンパイラが保証した

Flutterスレ盛り上げてこいよ
0409デフォルトの名無しさん2022/09/07(水) 07:23:19.72ID:8x7iT+wj
ponyは面倒すぎて萎える
こんな参照の管理くらいコンパイラが自動的にやるべきで人間に押し付けるのは悪手
0410デフォルトの名無しさん2022/09/07(水) 07:30:00.20ID:ANYrsupz
>>409
参照とか永遠に分からなくてもコンパイラが保証してくれるRustすごい、俺すごい。成長した

Flutterスレ盛り上げてこいよ
0411デフォルトの名無しさん2022/09/07(水) 07:42:15.35ID:ordz3g2+
>>406
確かにborrow checkerも働くみたいだし機能上の問題はないようだね
とはいえ、元の発言は単独参照で読みを占有できると言ってるからね
0412デフォルトの名無しさん2022/09/07(水) 07:45:25.38ID:+d3zlyKh
参照とかスタックとかヒープ、移動、元の発言なんて実はよく知らない。
所有権の複製こそ最善手
永遠に分からなくてもコンパイラが保証してくれるRustすごい、俺すごい。成長した
だがいつでも育成を要求する扉は開いている

Flutterスレ盛り上げてこいよ
0413デフォルトの名無しさん2022/09/07(水) 07:57:54.75ID:eUEKoWnI
>>412
すみません、所有権の複製ってなんですか...?
clone()とかでオブジェクトをコピーすると、複製後のオブジェクトに対して、別の新しい所有権がただ一つ代入先の変数に束縛されるという認識だったのですが...
0414デフォルトの名無しさん2022/09/07(水) 08:06:19.67ID:gZR3Yo8R
>>413
ゴネれば相手が勝手に折れる
ゴネ権の複製こそ最善手
いつでも妥協を要求するカードを複製している

Flutterスレ盛り上げてこいよ
0415デフォルトの名無しさん2022/09/07(水) 08:09:45.92ID:41cUJGIp
>>387
>読み書きしないけど値の存在だけは確認したいときってどうすんの?

Null安全な言語では値が存在しないことを表すNullなどを普通の型には代入できないことでNull安全性を実現している
そのためNullを代入できるNullableな型が用意されておりNullかどうかは値自体の読み書きとは別に可能な言語が多い

RustならばOption<T>がNullableな型でNullはNoneと表記する
Option<T>のメソッドis_some()かis_none()によって値自体の読み書きをせずに値の存在だけを確認できる
0416デフォルトの名無しさん2022/09/07(水) 08:19:14.45ID:C9aPpQqG
>>415
ボールは投げ返した
メモリレイアウトがどう変わるか、何も知らなくてもコンパイルが通る範囲でRustが保証する
どうだ怖いか

Flutterスレ盛り上げてこいよ
0417デフォルトの名無しさん2022/09/07(水) 08:23:50.75ID:E0QYSaMt
Rustは低レベルの対応も必要だから、mutable必要なんだろうけれど、理想はImmutableだけじゃないの?
0419デフォルトの名無しさん2022/09/07(水) 08:34:10.43ID:ASjGwh81
同じforループでも

for (i = 0; i < 10; i++)
これは見るからにmutableだけど

for i in 0..10
これは毎回別のimmutableがやってくる感じ
0420デフォルトの名無しさん2022/09/07(水) 08:39:03.96ID:SuR+St8r
いいかげん 俺ウザいだろ
tagが自然発生したぞ
どうだ怖いか

Flutterスレ盛り上げてこいよ
0421デフォルトの名無しさん2022/09/07(水) 09:44:51.32ID:XqqYtKGz
イミュータブルはzero overhead abstractionとは対極だからな
特にRustの場合は関数型みたいにオブジェクトの一部を書き換える度に新しいオブジェクト作るとかやってたら細切れに解放が必要になってコンパイルも実行もクソ効率悪そう
0422デフォルトの名無しさん2022/09/07(水) 10:24:02.90ID:aeiTHGZS
>>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; なんてほとんど使わないのではないか、なにより見た目が気持ち悪い。
これが最高だという人もいるけど、個人的にはなんかしっくりこないな
ほかの言語の多値戻り値のように()カッコさえなければ良いのに・・・・
0424デフォルトの名無しさん2022/09/07(水) 13:08:54.29ID:ossJLtb4
>>401
俺仕事でNLPやってるけどトークナイザの実装がクソ遅いんだよ
英語だとRustで実装されたfastバージョンがあるんだけど
日本語対応のやつはゼロ
作らしてくれーと言ってるけど許可降りない
0425デフォルトの名無しさん2022/09/07(水) 13:44:11.23ID:AY0Q59m9
>>424
日本語の字句解析なんてやったことあんの?
片手間でできるようなもんじゃないぞ
Cで書かれたありもの使えよ
0426デフォルトの名無しさん2022/09/07(水) 14:05:06.57ID:ossJLtb4
>>425
やったことあるから言ってるんだが?
それに今時の自然言語処理って転移学習は必須
そのためにはトークナイザとモデルを合わせなきゃいけなくてこれがめちゃくちゃ使いにくい
0427デフォルトの名無しさん2022/09/07(水) 14:09:08.42ID:AY0Q59m9
>>426
やったことあるならその時のが残ってるだろ
それをプレゼンしてだめなら自分の思ってるほどの性能は出てないてことじゃね
0428デフォルトの名無しさん2022/09/07(水) 18:37:19.13ID:eUEKoWnI
>>421
オブジェクト作るって、ヒープのアロケーションを想定してる?
0429デフォルトの名無しさん2022/09/07(水) 19:13:42.89ID:ge/fWvoV
いるよな、知りもしない癖に口出してくるやつ。
0432デフォルトの名無しさん2022/09/07(水) 20:06:49.94ID:/qhkAnst
今夜のAAPLの発表まで暇つぶし

早いもので2年か、改めて見る
Scalaが日本で衰退し始めている理由を説明します
https://www.yout
ube.com/watch?v=kFzLia7YZQU
0434デフォルトの名無しさん2022/09/07(水) 20:18:37.12ID:dqzrycJl
C++は3年ごとに改定されるので、歴史ある言語でありながら、次世代言語でもあるんだよね。
素晴らしいことだと思います。
0436デフォルトの名無しさん2022/09/07(水) 20:31:13.48ID:g9jqSBBW
SDGs的に完成は最悪手
発注側も分かってる

Scalaは完成しちゃったの?
0439デフォルトの名無しさん2022/09/07(水) 20:47:36.68ID:g+neltEd
>>422
プログラミングをしたことがないからそんな発想になる
関数からタプルなどが返ってきて別々に使うなど日常茶飯事

let (tx, mut rx) = mpsc::channel(10);
個別にmut指定する仕様は尊い
0443デフォルトの名無しさん2022/09/07(水) 21:14:05.84ID:g+neltEd
>>442
Rustは公開されている山のようにあるTODOリストが常に少しずつ進行中
大きなことから小さなことまで機能追加でどんどん便利になっている
0444デフォルトの名無しさん2022/09/07(水) 21:28:44.94ID:hfhFNamj
機能追加はcrate/macroで起こってる だがcoreは封鎖した
Go動向を追う最善手はGoスレ見に行くことである
知らんけど
0445デフォルトの名無しさん2022/09/07(水) 21:36:37.03ID:LgczABzT
そろそろ風呂に入ってくる
だが隙あらばスタックとヒープ mpscとスレッド安全の育成を要求する扉はまだ開いている 乗り遅れるな
0446デフォルトの名無しさん2022/09/07(水) 21:44:22.20ID:g+neltEd
>>444
外部crateの話は一切していなくて
Rust言語が日々進化しているとは
Rustコンパイラによる機能追加と改善
および標準ライブラリの機能追加を指す
もちろんcoreライブラリ部分にも追加やstable化などがある
0447デフォルトの名無しさん2022/09/07(水) 21:53:02.05ID:En8I5Kb5
>>428
その人じゃないけどRustでは特に指定しなければオブジェクトなどもスタック上に作られるよ
例えばCのコードと同じ動作をRustで書かれた>>181のイテレータメソッドチェーンのコード
各イテレータ毎にそのオブジェクトがスタック上に作られるね
結果としてC言語でforを回したり関数ローカルのmax変数を使うのと同じ
そのため全く見た目が異なるRustコードとCで同等の生成コードが出来上がってるわけ
0448デフォルトの名無しさん2022/09/07(水) 22:26:11.82ID:bnLUEQYt
>>447
>各イテレータ毎にそのオブジェクトがスタック上に作られる
スタックもヒープもasmもhardware levelは何も知らない。育成ry
0449デフォルトの名無しさん2022/09/07(水) 22:36:50.03ID:g+neltEd
ヒープ利用は確保と解放操作が必要だから必ず遅い
スタック利用はスタックポインタの増減を関数の最初と最後でまとめてするだけで速い
さらに最適化でレジスタ利用になりうるから超速い
0450デフォルトの名無しさん2022/09/07(水) 22:37:48.00ID:SiZHOEm5
>>447
職場でその言葉を知ったかしたら相手が勝手に納得しました。魔法のコトバ

育成無用 ヒント無用
0453デフォルトの名無しさん2022/09/07(水) 23:04:02.99ID:JYc4oRyX
>>452
重大なヒントleakかと思ったけど最低限で良かった
明日 職場で知ったかしてもらう予定
0454デフォルトの名無しさん2022/09/07(水) 23:18:52.05ID:MCKgMvZG
>>453
ボッチ自宅開発者だからオジが知ったかできる場所は5chだけ
リアルでやってたらここまで酷いことにはならない
0455デフォルトの名無しさん2022/09/07(水) 23:25:44.51ID:4U49yzDh
>>454またはPython職場でRust勉強会をしてて自分が一番詳しいと思われたい&
Rust使わせてくれない上司を見返したくて頑張ってるんだよ。
ウルウルくるぅ
0458デフォルトの名無しさん2022/09/07(水) 23:41:58.89ID:En8I5Kb5
>>452
その例は現実的ではないよね
実際の使われ方だと新規オブジェクト生成は通常は別関数だから
それをinline指定でもしない限りは別関数にあるmallocは消えないです
ヒープ確保は常に行われてしまいます

一方でRustでは新規オブジェクト生成が同様に別関数でinlineでなくても
オブジェクトを「値返し」するので大丈夫です
オブジェクト生成する別関数でも呼び出す側でもヒープの利用はありません
0460デフォルトの名無しさん2022/09/08(木) 00:52:54.26ID:8UoQH6yi
ヒープを使ってしまったら、>>452のような重箱の隅をつつくレアケースを除くと、最適化で消えないので不利
Rustのようにオブジェクトの生成すらスタック上で行なう方が有利

Rustはオブジェクトを値返しする点がそれを可能としている
オブジェクトをレジスタ群に格納して返せるときは最も速くなり、
その大きさを超えても、呼び出し元のスタック領域に確保された場所へ直接書き込んで渡すためこれも速い
0461デフォルトの名無しさん2022/09/08(木) 01:00:14.34ID:U6/gufpm
>>458
重箱の隅だけどinline指定しなくても関数のインライン化は行われるよ
同一翻訳単位の場合はもちろん、リンク時最適化でインライン化されることもある
0462デフォルトの名無しさん2022/09/08(木) 01:01:41.29ID:U6/gufpm
必ず○○とか必要以上に強い言葉を使うから重箱の隅をつつきたくなってしまうわけで、
ほとんどの場合○○とか適切な言葉遣いをしてくれれば良いのに
0463デフォルトの名無しさん2022/09/08(木) 01:21:29.31ID:bfKvyn62
>>461
inline化だけの話ならそうだね
でも今回はmalloc部分が消えるかどうかで単純なパターンだとinline化されて消えるときもある話じゃないかな
オブジェクト生成関数のmallocが常に消えたら大問題なのでそれは特殊なケースでしか起きないと思うよ
0466デフォルトの名無しさん2022/09/08(木) 01:50:13.51ID:bfKvyn62
>>464
RustではVec(オブジェクト)生成new()でヒープは使わないよ
サイズ1以上になって遅延して初めてヒープ確保

SmallVecを使えば指定サイズ以上になって遅延して初めてヒープ確保
それまではスタック上のみを使う

ArrayVecはヒープを一切使わない
スタック上の指定サイズの中でのみで使う

だから「上限サイズがなく、かつ、想定サイズを超えた」時でなければヒープを使わずに済むようになっているよ
0467デフォルトの名無しさん2022/09/08(木) 01:51:32.30ID:M4A7wjs7
TS以外だと実際どれやればいいん?
理由添えて教えてほしい
0468デフォルトの名無しさん2022/09/08(木) 02:21:09.08ID:KnWQjklo
>>467
TypeScriptやっている人ならRustかな
まずウェブブラウザのフロントエンドで少し処理することが出てくるとWebAssemblyを使うがそこでの使用言語シェア1位はRust
次にブラウザではなくデスクトップ上などで作るときもJS/TSとRustを使った安全に高速なフレームワークTauriがある
もちろんサーバーサイドでもRustを使って安全に高速な構築ができてサーバーやクラウドコストも他言語より有利になる
0469デフォルトの名無しさん2022/09/08(木) 02:43:12.05ID:M4A7wjs7
>>468
めっちゃ丁寧な解説ありがとう
汎用系のCOBOL3年から未経験でWEB系に最近転職したんだ
自主学習でReactやったんでとりあえずフロントエンドで採用されたけど
今後サーバーサイドやその他の技術を習得
しようとしたとき何をやろうか?と悩んでたんだ

参考にしてみます。本当にありがとう。
0474デフォルトの名無しさん2022/09/08(木) 08:22:43.32ID:zqAFLdB2
こんなに優秀なRustなのになんでFirefoxは遅いし、著名なあまりソフトウェアが出てこないの?
0475デフォルトの名無しさん2022/09/08(木) 08:26:35.79ID:BdGA/lpu
>>449 >>456は行儀よく振る舞う練習
>>473は自演否定を一旦諦め 蒸し返しの誘い球
温存している自宅回線IDで後ほど再び自演否定
こんな流れで戦ってる
0476デフォルトの名無しさん2022/09/08(木) 08:37:41.52ID:WNih/Uq3
>>466
Rustはスタック上だけでVec操作できるよう充実してるね
0477デフォルトの名無しさん2022/09/08(木) 08:51:41.58ID:+LoUe6Y0
>>474
安全とハイリスクハイリターンの対立と分断があるから
優秀の反対は別の優秀だから
0478デフォルトの名無しさん2022/09/08(木) 09:47:44.75ID:RfxdukXg
俺仕事でPython NLPやってるチームに配属された どうだ怖いか
周りのDr持ちが段違過ぎてRustで戦いを挑むカードを推進してる
Rustで作らしてくれーと言ってるけど許可降りない
無意味な上司のせいでRustはパーソナルプロジェクトだ

そのプロジェクトとは CLI Tools だ
JetBrainsのDeveloper Ecosystem Surveyでは
2021に待望のCLI Toolsカテゴリーが新設された。
突然Systems Programmingが激減したのは誤差だ
0479デフォルトの名無しさん2022/09/08(木) 09:51:36.54ID:JEMfdspa
Project Crasher
0480デフォルトの名無しさん2022/09/08(木) 09:56:34.95ID:Txzh6OM/
2020に新設された仕事での利用率は、2020→2021の伸びは0だが、
キャンペーンが実を結ぶのは今年2022だ
何しろ2022はtauriがv1に到達し Desktop/GUI Applications がエンタープライズで飛躍的に伸びる
WebAssemblyの使用言語シェア1位とかいう話もある
メモ帳レベル機能でもawesome扱いしてくれるのは今だけだ 車輪に乗り遅れるな
0483デフォルトの名無しさん2022/09/08(木) 11:06:23.80ID:KnWQjklo
>>480
いずれ多くの分野でRustを使って当たり前の時代が来るだろうけど
まだしばらくは限定される気がするね
0486デフォルトの名無しさん2022/09/08(木) 12:50:52.48ID:VIOSuMTh
>>480
今は、Rustで実装ってバリューあるけれど、もう何年もしたら、当たり前になって誰も気にしなくなるんだろうね。
0487デフォルトの名無しさん2022/09/08(木) 13:45:08.90ID:WNih/Uq3
スクリプト言語で十分な分野はそのままじゃないかな
それ以外の分野はRustを使うことが当たり前に
0488デフォルトの名無しさん2022/09/08(木) 14:10:48.26ID:+LoUe6Y0
言語仕様が優秀でも実装で失敗すれば終わり
標準ライブラリがーっていうのもどちらかといえば実装側の問題
0489デフォルトの名無しさん2022/09/08(木) 14:53:25.83ID:LIDvvnz0
ライブラリを選ぶコストや年単位で変更をウォッチしてアップデートの要否を判断して適用するコストって馬鹿にならんのよね
最近の言語なら言語そのものの生産性の差より言語の違いによるライブラリ周りの生産性の差の方が大きい
0490デフォルトの名無しさん2022/09/08(木) 19:00:05.87ID:aaaIAhtE
そう考えるとBoostのあるC++は素晴らしいよね。
0491デフォルトの名無しさん2022/09/09(金) 19:27:35.69ID:J0h2kR8b
https://www.jpcert.or.jp/sc-rules/00.introduction.html

CERT セキュアコーディングスタンダードは、C、C++、Javaを対象としたセキュアなコーディング標準を公開した。
RustとBashは安全なのでCERT/CCの対象外とした。
0494デフォルトの名無しさん2022/09/09(金) 20:16:31.91ID:J0h2kR8b
あ”あ”〜〜ワクワクが止まらねえ〜〜。
0495デフォルトの名無しさん2022/09/09(金) 22:47:37.83ID:B0h43lqZ
>>491
CもC++も対象バージョンが古すぎ。
0497デフォルトの名無しさん2022/09/10(土) 09:06:15.64ID:ZPKzDOJp
>>352
途中までJuliaのコピペ乙
0499デフォルトの名無しさん2022/09/10(土) 18:40:23.49ID:830ybrIN
CERT知らんのか。
0501デフォルトの名無しさん2022/09/10(土) 20:44:33.04ID:BhJh8aSd
C固有の話やメモリ安全性に関わるものはともかく、
シグナル安全性とかモダンな言語でも気にしないといけない部分はそれなりにあると思うので、
モダンな言語向けにまとめ直したものがあると嬉しいとは思う
0504デフォルトの名無しさん2022/09/10(土) 21:31:16.53ID:PkiDAnmE
小鳥んはいつまで次世代なんだよ
まだJavaから覇権を奪えないのか
0505デフォルトの名無しさん2022/09/10(土) 23:11:12.68ID:pCQRIeiF
Nimは本質的なメリットが何もないから
今後も企業が採用することがないと思うよ
0506デフォルトの名無しさん2022/09/10(土) 23:23:36.54ID:a77H3leG
Rustは本質的なメリットが何もないから
今後も企業が採用することがないと思うよ
0507デフォルトの名無しさん2022/09/10(土) 23:50:11.76ID:I8LDMMGc
>>502
Pythonはマルチスレッド禁止ではなく
グローバルインタプリタロックをしてるから真の並列処理ができないだけ
I/Oブロッキングされてる間に他が動けるなど完全に無意味というわけではない
これはRubyも同じで所詮はスクリプト言語だからしょうがない
0508デフォルトの名無しさん2022/09/10(土) 23:59:58.32ID:WfJh9xF9
Rustは企業による採用が多い
例えば>>9の記事、>>43の記事、154の記事など
各企業がRustのメリットを様々な観点から語っている
0509デフォルトの名無しさん2022/09/11(日) 00:34:56.10ID:Iy8wr1LO
>>508のような重箱の隅をつつくレアケースを除くと、Rustの現実>>496
0510デフォルトの名無しさん2022/09/11(日) 00:47:20.06ID:XM7RcVpf
理解のある有能な上司・経営者がいる企業はRustを適切に導入しつつあり
ダメな企業はそれらの記事にもある多大なメリットを理解できないまま差が広がるのだろう
0512デフォルトの名無しさん2022/09/11(日) 01:26:31.38ID:VONtFQ6w
>>510
統計とか言ってる時点でズレてるからな
俺はもう1番安全な言語しか使いたくないよ
0515デフォルトの名無しさん2022/09/11(日) 02:13:14.46ID:QQU6OFWg
>>509
トヨタやNTTも採用しているし
それらGAFAMによる採用も含めて
レアケースというよりも適切な判断ができる企業がRustを採用していってる感じ
0517デフォルトの名無しさん2022/09/11(日) 03:35:13.96ID:7JragUBO
昔から同じ傾向だけど
余裕のない会社(人)や無学習な会社(人)はそのまま古い言語、遅い言語、安全でない言語を使い続けるね
これは言語に限らずあらゆる対象について同じ
0518デフォルトの名無しさん2022/09/11(日) 06:11:01.67ID:B/NO1QVJ
本日の もはやRustはどうでも良くて
Rustで誘い球 ヒント乞い儀式の会場はこちらですか?

異次元超大手GAFAM御用達 老舗第三者機関jetbrainsによる
大規模統計調査結果 #Rustの不都合な真実 #責任転嫁論法

尾ひれはひれ抜きで

一言でまとめ

>Rustで作らしてくれーと言ってるけど許可降りない

詳しくは JetBrains ソースで👆
0519デフォルトの名無しさん2022/09/11(日) 07:38:24.36ID:+BbjejVS
調査結果を誤読している人がいるようだけど
昔から良いプログラミング言語が出てきたらまずは趣味や個人的な用途から使われ始めるのでこの第一条件をクリアしていることを意味している
仕事で強いられるのとは異なり自ら選べるところで進んで使われることはプログラマーにとっても良い言語であることを意味する

一方で多くの会社や客先などで使われる言語は良い悪いと関係なく惰性的にもしくは周りに流されて決まることも多い
よってその大衆的な調査よりも第二条件としては趣味範囲に留まらず実用的なプログラミング言語かどうかが重要となる
その点では>>9>>154の記事などで世界的な大手IT企業たちがRustの実用性を証明してくれている
0520デフォルトの名無しさん2022/09/11(日) 07:44:27.84ID:uuKi7qIG
RustスレやGoスレ、Pythonスレはレベルが低くて使えない
やっぱC/C++を煽らないと重箱の隅をつつく レアヒント情報は出てこない

4回線で戦ってるから、両側のサクラを演じてるが、本物がなかなか釣れない
0521デフォルトの名無しさん2022/09/11(日) 08:16:22.32ID:Iv+s/rR9
Rustが実用的に使えるようになったからC/C++は既存メンテを除いて不要じゃないか?
しばらくの時間が経った以後は重箱の隅をつつくレアケースでしかC/C++は使われなくなると思う
0522デフォルトの名無しさん2022/09/11(日) 08:26:29.84ID:dBVHZlNB
>>521
その条件だけじゃ不十分だよ
それに、Rustに慣れた技術者が不足なく増えること、の条件が加わればもうC/C++は使われなくなる
0524デフォルトの名無しさん2022/09/11(日) 08:56:08.15ID:SEdmppON
あるいは毎年、既存システム比、2割も新規があると考えるのは現実的ではない。
0526デフォルトの名無しさん2022/09/11(日) 09:15:04.75ID:LoCSxJxA
あるいは新規があればRustであると考えるのは現実的ではない。すべて架空の話。英語で言えば仮定法過去
0527デフォルトの名無しさん2022/09/11(日) 09:44:14.66ID:+PEbrMUs
C++は酷い言語だったが科学的な誤りはなかった
商業的に不要とか言われてもそれは倫理的に悪と言われる程度の説得力しかない
0528デフォルトの名無しさん2022/09/11(日) 09:50:44.97ID:WKW/SVys
あるいはRustでは保証するとか証明可能とか言う話は全て架空だ
数学的証明された事実は一つもない
0529デフォルトの名無しさん2022/09/11(日) 09:59:03.59ID:+PEbrMUs
まあ数学自体が架空だと思ってる奴もいるんだよな
複素数には不等号も最大も最小もないという事実は架空で
最大と最小しかない1bitも架空で
実数が現実だと思ってるようだ
0531デフォルトの名無しさん2022/09/11(日) 10:06:19.83ID:sTwbodpe
>Rustは数学自体が架空だと思ってる™
>Rustスレはレベルが低くて使えない
完全一致
0532デフォルトの名無しさん2022/09/11(日) 10:12:56.55ID:qCGvqebh
>Rustは数学自体が架空だと思ってる™ ←New
>Rustスレはレベルが低くて使えない
>Rustで作らしてくれーと言ってるけど許可降りない™
完全一致
0533デフォルトの名無しさん2022/09/11(日) 11:42:55.72ID:1/0HqANi
Scalaが実用的に使えるようになったからJavaは既存メンテを除いて不要じゃないか?
0534デフォルトの名無しさん2022/09/11(日) 12:14:21.26ID:P3VqydEe
GAFAMが揃って採用したら実用的&安泰
1社のみだと細々と消える可能性あり
0535デフォルトの名無しさん2022/09/11(日) 13:06:46.07ID:e58aNhcI
アリババに採用されないと無理だろ。
0537デフォルトの名無しさん2022/09/11(日) 13:26:02.18ID:HFx3mOt8
日本の場合、Rust実務3級みたいな怪しい資格が出てきたら、人の確保に困らないレベルだと考えられるのでは。
0538デフォルトの名無しさん2022/09/11(日) 13:33:45.44ID:e58aNhcI
実数が存在する可能性もゼロではない。
0541デフォルトの名無しさん2022/09/11(日) 15:00:31.37ID:e58aNhcI
アリババのメイン言語になってるならワンチャンあるかもしれないなあ。

でも、日本で使われてるならダメそうじゃないか?
日本人が良いというものは、だいたいダメだったぞ。
この30年間。
0542デフォルトの名無しさん2022/09/11(日) 15:06:26.74ID:e58aNhcI
ある意味、日本を釣るためにGAFAが手を組んだのかもしれないしな。
0544デフォルトの名無しさん2022/09/11(日) 15:24:35.80ID:e58aNhcI
>>543
中国とアメリカが手を組んだってことかな?

ますます嵌められる予感しかしない。
0546デフォルトの名無しさん2022/09/11(日) 16:37:16.95ID:vfKVIBQc
GAFAというが
アップルはRustに言及してないだろ
社内でどうしてるかは知らんが
0547デフォルトの名無しさん2022/09/11(日) 16:42:02.78ID:F99gXeAJ
そういや GAFA の F は Facebook の F だったので Meta に変わった今は GAMA になる筈だよね。
0548デフォルトの名無しさん2022/09/11(日) 16:43:11.94ID:XyeJ2q+G
>>546
Appleは2~3年前からクラウドサービスのバックエンドで使ってるって話だよ
公式発表とかしてるかは知らんけど中の人がしゃべってたし採用サイト見ればわかる
0549デフォルトの名無しさん2022/09/11(日) 16:47:35.25ID:PJg7Eu+i
ID:e58aNhcIは陰謀論とかにころっと騙されそう
日航機墜落はアメリカの陰謀だとか信じてそう
0550デフォルトの名無しさん2022/09/11(日) 16:48:54.21ID:y06ekIr1
>>541
CもJavaもPHPも日本じゃ昔から至るところで使われていたし、過去資産を一気に捨てるのでなけれこれからも世界中で使われるだろうけど?
0551デフォルトの名無しさん2022/09/11(日) 16:50:26.98ID:e58aNhcI
逆に、自民党は某宗教団体と無関係とか思ってる人のほうがオカシイのでは?
宗教と組んでるから安泰と党大会でも言ってるのに。
0552デフォルトの名無しさん2022/09/11(日) 17:02:25.87ID:p+Qu5PiK
陰謀論はたまに真実が混ざってるから厄介
9.11はサウジが糸を引いてたみたいなやつとかね
0553デフォルトの名無しさん2022/09/11(日) 17:06:29.54ID:vF4tz2Bt
>>547
GoogleはAlphabetになってるからAAMAかAAMAM

わざと没個性的にした企業名に追随する必要は全くないと思うが
0554デフォルトの名無しさん2022/09/11(日) 17:11:27.93ID:e58aNhcI
>>552
それ、最近話題の某宗教団体が主張してるけど。

陰謀論じゃなく真実。

陰謀論と言えばごまかせるという風潮がオカシイのでは?
0555デフォルトの名無しさん2022/09/11(日) 17:13:50.83ID:wKzSFZtE
☆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
0556デフォルトの名無しさん2022/09/11(日) 17:14:49.46ID:wKzSFZtE
☆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
}
0558デフォルトの名無しさん2022/09/11(日) 18:43:29.45ID:wKzSFZtE
☆js let
var a = []
for (let i = 0; i < 3; i++) {
a.push(() => console.log(i))
}
a.forEach(f => f()) // 0 1 2
0559デフォルトの名無しさん2022/09/11(日) 21:41:46.79ID:+PEbrMUs
登場人物等が実在しないと意味がないのが陰謀論
実在してもしなくても仮定するだけでいい感じになるのは防災とか護身術とかかな
0560デフォルトの名無しさん2022/09/11(日) 21:56:48.27ID:3JeGkSLy
☆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
}
0562デフォルトの名無しさん2022/09/11(日) 22:32:59.60ID:wKzSFZtE
☆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
0563デフォルトの名無しさん2022/09/11(日) 23:47:28.92ID:VMVpvyTB
>>560
ライフタイムを管理してるRustだけが
問題を回避してコンパイルエラーにすることができているね
0564デフォルトの名無しさん2022/09/12(月) 12:00:10.83ID:hkEaTFQf
それで最強?言語Rustで崇高なパーフェクト言語?Rustでいま何作ってるんですか?
ぜんぜんRust製の良いソフトウエアが出てこないですね
まさかウンコ臭い業務コードや、趣味のじこまんオナニーコード書いてるんですか?あ、ごめん業務ですら案件ほとんどないか!w
0565デフォルトの名無しさん2022/09/12(月) 12:19:44.25ID:5bihwCS7
ごめんrustって駄目なの?
goとかのがいいんか?
0566デフォルトの名無しさん2022/09/12(月) 12:20:19.70ID:pKAQjQJa
>>564
オモチャと馬鹿にするのは筋が良くないよ。
適用領域や生産性が十分であればオモチャがエンタープライズ(笑)を置き換える例は枚挙にいとまがない。

下げたいなら欠点や解決できていない課題を指摘するのがよいよ。
0568デフォルトの名無しさん2022/09/12(月) 12:30:55.10ID:8xQYKjTB
>>565
他人に書かせたコードを管理する立場なら現状ベター。
自分でコーティングするなら微妙。

ガチガチに固めたコーティング規約のついてくるc++くらいに考えればいいかと。
0571デフォルトの名無しさん2022/09/12(月) 13:42:12.36ID:vGI5q7L7
料理下手な奴って
調味料とかの用法用量をガチガチに守らない方が美味しくなる
って思い込みが強いんだよな
0572デフォルトの名無しさん2022/09/12(月) 13:53:17.15ID:QNBEnsOG
カレーの箱には材料全て炒めて煮込めって書いてあるけど実際には炒めるのは玉ねぎだけでいいし煮込むのはジャガイモだけでいいんだよね
あとはレンジで下処理できる
全部同じ処理方法だと玉ねぎは香りが飛ぶしジャガイモのデンプンが十分スープに出なかったりする
火を止めてから仕上げにインスタントコーヒーを少し加えると味音痴でもはっきりわかるくらいコクが変わるがそれは書いてない
なぜなら商業的にはコーヒーはルーに最初から入っているべきもので必要なスパイスや味付け等を一つのパッケージで提供することがルーの役割だから
ところがコーヒーは最後に入れるもので最初から入れるとただ苦味を加えただけになる
従ってレシピには載ってない

俺って料理音痴だなあ
0574デフォルトの名無しさん2022/09/12(月) 14:26:53.27ID:o/NFQNbK
>>570
OSSこそ他人のpull req受け入れたりするから規約は堅い方が良いのでは

書いてもらったコードを書き直すようお願いしたり、自分で書き直したりするのは二度手間だよね
0575デフォルトの名無しさん2022/09/12(月) 14:53:09.61ID:nQ3vrjGe
JetBrainsの方はテックメディアやblog等がこぞって取り上げてる印象がないけど日本だけ?
あと2~3週間で今年の結果が出る頃だけど、RustとGoをヘッドラインに入れ込んでViewが稼げそう
どっちがどう転んでもw
0576デフォルトの名無しさん2022/09/12(月) 15:23:46.11ID:/ImN/Q+4
どっち転んでるって分かってるくせに...

Goスレから出張ですか? このスレは>>518となりました
0578デフォルトの名無しさん2022/09/12(月) 15:45:21.43ID:U3gTQ3k2
>>577
この話をしたいのか?
>GAFAMが揃って採用したら実用的&安泰
>1社のみだと細々と消える可能性あり

飽きたわ
Scalaは細々でも生き残る実稼働分野を見出した
0579デフォルトの名無しさん2022/09/12(月) 15:52:19.48ID:D724xnZb
>>565
Rustは史上最強のプログラミング言語だ
コンピュータサイエンスとプログラミング言語理論の成果を全て取り入れた唯一の言語だろう
安全性とパフォーマンスを両立させた唯一の言語
まずRustを使うべき
しかしスクリプト言語使いの人などはハードルが高いのでGoやNimなんかを経由するのはあり
最終的にRustへ至る道への修行と考えれば全然あり
0580デフォルトの名無しさん2022/09/12(月) 15:55:18.32ID:xojxIqPL
キチガイがRustのアホな持ち上げ方するネガティブキャンペーンやめてくんないかな
いい加減流行ってくんないと不便なんだよいつまでも
0581デフォルトの名無しさん2022/09/12(月) 15:56:53.20ID:+dWR9IC9
Go  実稼働分野でバリバリ活躍中
Scala 実稼働分野でバリバリ活躍中
Rust 試食コーナーで食べてもらって狂喜乱舞
0582デフォルトの名無しさん2022/09/12(月) 15:58:05.79ID:D724xnZb
バリバリ使ってるレベルの高い人が周りにいないから知らないんだね
かわいそう
0583デフォルトの名無しさん2022/09/12(月) 16:00:17.03ID:xojxIqPL
>>582
Rustは足りない物だらけでバリバリ使えるレベルにないんですわ
ユーザー増える邪魔すんなよ
0584デフォルトの名無しさん2022/09/12(月) 16:04:01.87ID:mWclCycs
今すでにC/C++を使ってるようなプロジェクトでなければ、基本的にはRustなんて出番ないよ
Java、JavaScript、Python、Swift、Kotlinみたい言語が使われてる分野でRustが使われることはない。あっても非常にマレ
wasmでRustの需要があると騒ぐひともいるけどまだ新しすぎてなんともいえない
0585デフォルトの名無しさん2022/09/12(月) 16:06:50.08ID:D724xnZb
「自分のレベルが低い」ことを認識できないとレベルアップなんてできないぞ
Rust書ける?って言って勉強すれば書けます!とか言ってるやつが数ヶ月後も書けなくて
どういう反応するのか見たら「学習コストが高い」とかいうよくわからない言い訳をしたことがあった
Rustチームに入ってもらおうと思ったけどやめた
0586デフォルトの名無しさん2022/09/12(月) 16:10:13.94ID:D724xnZb
俺の経験上C/C++を書けないとRustは書けないと思う
だから急がば回れでC++の勉強をするのも良いと思う
Rustが持ってる機能の元ネタがそこらにあるから
やる価値はあると思う
なぜ継承がクソなのかコピーが悪なのか全て理解できると思う
この感覚を理解してないとRustの機能のありがたさはわからない
0587デフォルトの名無しさん2022/09/12(月) 16:14:15.82ID:D724xnZb
結論を言うとRustから逃げてるエンジニアは二流 ここで逃げるとあらゆることから逃げるだろう
0588デフォルトの名無しさん2022/09/12(月) 16:16:36.57ID:tOT7j8yQ
完成した

Go  実稼働分野でバリバリ活躍中
Scala 実稼働分野でバリバリ活躍中
Rust 試食コーナーで食べてもらって狂喜乱舞
   俺 >Rustで作らしてくれーと言ってるけど許可降りない
   有能社員 >Rustは学習コストが高い割に使えない
   有能社員 >C/C++を書けないとRustは書けない、Rustは意味なし
Nim 試食コーナーでスルーされて意気消沈
Pony 開店前
0589デフォルトの名無しさん2022/09/12(月) 16:19:39.20ID:ogCOvAZv
>>585
それが現実。

Rustを「とりあえず」使えるレベルになるだけでも深くプログラムに精通している必要があり、JavaとかPython開発で使えるレベルの人材では全く歯が立たない。
Rustコミニティは初心者にマウントする人間ばかりで教育手法は全然整備されていない。

こんなのでユーザーが増えるわけが無い。順当にHaskellと同じ道を歩んでいるわな。
0590デフォルトの名無しさん2022/09/12(月) 16:21:55.50ID:mWclCycs
当然だけど万能な言語なんてないから、ユースケースに選んで使えばいいだけ
プログラミング言語なんて5個や10個使えて当然
0592デフォルトの名無しさん2022/09/12(月) 16:29:46.69ID:pGdD9pkE
>>585
だからお前はレベルアップできないんだな
Rust使えるようになってからそういうことは言え
0594デフォルトの名無しさん2022/09/12(月) 16:45:35.34ID:D724xnZb
とはいえRustが普及しないのは俺も困る
レベルが低いものが結託してRust を潰そうとする動きは感じてる
なので何とか使えるように指導したいとは思ってる
0595デフォルトの名無しさん2022/09/12(月) 16:47:00.99ID:p/0uZlw7
>>584
それはちよっと無知すぎるんじゃないかね
そのJavaなどの言語が現実にRustへの移行対象となって進んでいる
単純にRustならば自動メモリ解放で高速化できるだけでなく
>>43の記事に具体的にあるように非同期な並行&並列プログラミングなどでの優位性も大きい
どんなに複雑化してもデータ競合がないことをRustコンパイラが保証する点は現在最も求められていることの最重要の一つ
0596デフォルトの名無しさん2022/09/12(月) 16:54:20.00ID:Sl+PHmf/
入れ食い状態

Go  実稼働分野でバリバリ活躍中
Scala 実稼働分野でバリバリ活躍中
   KENTA >日本では衰退しました ←New
Rust 試食コーナーで食べてもらって狂喜乱舞
   俺 >Rustで作らしてくれーと言ってるけど許可降りない
   レベルアップできない俺 >今はRustだけで良い。レベルアップはお断りだ ←New
   レベルアップできない俺 >試食コーナーで食べてもらって狂喜乱舞 ←New
   レベルアップできない俺 >数学出来ないけど有能社員を指導したいとは思ってる ←New
   有能社員 >Rustは学習コストが高い割に使えない
   有能社員 >C/C++を書けないとRustは書けない、Rustは意味なし
   有能社員 >Rustは言語オタク Haskellと同じ道 ←New
Nim 試食コーナーでスルーされて意気消沈
Pony 開店前
Haskell 衰退しました ←New
0598デフォルトの名無しさん2022/09/12(月) 17:02:59.62ID:D724xnZb
「できない人の気持ち」をずっと考えてたんだけど
スタックとかヒープとか所有権とかライフサイクルとか
そういう説明の仕方が悪いんじゃないかと
概念的な説明って意外と理解されないんだなと言うのが実感としてある
もう割り切って「この場合はこう書け」という説明の方が良いのではないかと思い始めた
0599デフォルトの名無しさん2022/09/12(月) 17:06:35.50ID:fbgm2yKh
入れ食い状態
ちょっと手加減してください

Rust 
   レベルアップできない俺 >スタックとかヒープとか、概念的 ←New
0600デフォルトの名無しさん2022/09/12(月) 17:09:10.23ID:UHoWNRxl
言語だけで低レベルな連中を排除できるから便利よ
前の会社でOCaml,Haskell,Scalaできる奴限定チーム作ったら
お守りの要る奴が居なくなって超快適だったw
まあ社内のできる奴が皆来たから他チームからの技術問い合わせ集中→丸投げが始まったからウンザリして転職したけどw
Rustも活かして行こw
0601デフォルトの名無しさん2022/09/12(月) 17:10:31.29ID:MdKMUdvB
>>598
あー
それわかる
C++とかも最初は割り切りパターンが大事だからね
例えばコンテナの要素にはunique_ptrを必ず使えとかかなり有用なパターンだと思うし
0602デフォルトの名無しさん2022/09/12(月) 17:15:38.21ID:D724xnZb
>>601
このような意見は有り難い
ちょっとその方針で社内ドキュメント書き直してみる
もしかしたらRust使い育成の成功体験が得られるかもしれん
0604デフォルトの名無しさん2022/09/12(月) 17:17:24.65ID:6spEgeO/
問題:ヒント乞い儀式は何処から始まって、何処まで続く?
   今、何人目?
0605デフォルトの名無しさん2022/09/12(月) 17:22:27.34ID:1EVPKhq8
こうしてRustはささやかに終わり、時代は変わっていくんですなぁ
0606デフォルトの名無しさん2022/09/12(月) 17:28:16.89ID:mWclCycs
Rustでやってる案件いくつか見たことあるけどどれも最初の開発者がめちゃくちゃ優秀だから、
変なことになってないし後から参加する人も自然とベストプラクティスを学びやすい感じになってる
まあどれもドメインを絞ってて規模が小さいから社内ドキュメントなんてあんまないけど…

>>602
社内ドキュメントで入門記事とか書こうとしてるの…??
0607デフォルトの名無しさん2022/09/12(月) 17:30:40.29ID:GOcHN1Zf
C/C++/低レイヤーの間違い指摘・揚げ足取りは思う壺です。
プロレスに終始してください。
0608デフォルトの名無しさん2022/09/12(月) 17:36:03.29ID:vGI5q7L7
static変数でいいと思った人の気持ちをOO棒でぶん殴ってた時代に戻ってやり直せばいいのでは
0609デフォルトの名無しさん2022/09/12(月) 17:44:05.96ID:AXUzp/Io
感想

Rustが高速で省メモリで安全という新分野を切り開いたのは確かなようで
クラウドコスト・使用電力量・Co2排出量でも有利なのは間違いなさそうだから
今後のシナリオは以下の2パターンかな~?

パターン1
慣れれば大半のプログラマーがRustを使いこなせるようになりRustはコモディティ化して人類の役に立つ

パターン2
Rustを使いこなせる層と使えない層に二極化する
企業などもRustを使いこなせる人材を集められる層と無理な層に二極化する
そのためサーバー&クラウドコスト支出・使用電力量・Co2排出量などあらゆる点で二極化してしまう
Rustを使えない側は様々な点で不利を背負ってしまう
0610デフォルトの名無しさん2022/09/12(月) 18:36:26.99ID:w++AQN2S
>>KENTA
Rustについてもいろんな過去動画で語ってるんだけど今一古い
古い動画では低レイヤー向けだから関係ないみたく言ってるけど最新版2022年下半期の意見が欲しい
KENTA周りでwasmってまだ見えてないんじゃないの?
過去の試食ニュースくらい?とか(tauriはKENTAに関係ないか)

だれか本人に伝えてきて下さいm(__)m
0611デフォルトの名無しさん2022/09/12(月) 18:42:10.96ID:1EVPKhq8
Rust使うとIDを簡単に変えることができる裏技みたいなのがあるの?
0612デフォルトの名無しさん2022/09/12(月) 18:58:12.12ID:cIAUh/V3
あえてKENTA周り煽るような否定形で聞いてるあたり
最新版では提灯コメントが出てくると思ってるんだろ

KENTAはScalaコミュニティ分析してるしガリ勉オジ嫌いって言ってたから
内心は言語オタクRust(コミュニティ)を良く思ってない

でも表面上では良い顔してくれると思うよ
0613デフォルトの名無しさん2022/09/12(月) 18:59:15.13ID:1QsSN3wZ
低レイヤー向きなのはガチ
Webやバッグエンドで扱うのはなかなかピーキーすぎるわ
0614デフォルトの名無しさん2022/09/12(月) 19:06:29.84ID:ctaSs0ih
低レイヤー向きなのはガチ(ただし既存システムは置き換えない)
Webやバッグエンド(その他もろもろ)はピーキー

こんなんじゃ提灯コメント出てこない
0615デフォルトの名無しさん2022/09/12(月) 19:07:05.31ID:hOTkFqgR
RustはHaskellと同じことを言ってる。
0616デフォルトの名無しさん2022/09/12(月) 19:08:23.81ID:M7cyS1TF
>>613
現実を見よう
バックエンド・クラウドサイドがRustで最も盛ん
フロントエンドもWasm記述言語トップがRust
0617デフォルトの名無しさん2022/09/12(月) 19:11:01.61ID:H3lrVzsc
Haskellが衰退したという結果は判るけど、何を言ってたかとか経緯はよく知らない
0618デフォルトの名無しさん2022/09/12(月) 19:14:40.26ID:k0iYs0el
こんな中、Clojureの勉強始めたわ。

Common Lispは、なかなか良い実装見つけられなくて挫折したけれど、ClojureはJVMの資産が使えるし、少し期待してる。
0619デフォルトの名無しさん2022/09/12(月) 19:14:42.35ID:iaJVMLEF
>フロントエンドもWasm記述言語トップ
どこぞのビルボード部門別1位みたいな言い方だな
0621デフォルトの名無しさん2022/09/12(月) 19:21:10.92ID:D0TZxDhn
WebAssemblyをGC言語で書くと実行速度もバイナリサイズも無駄すぎるため
現実的な記述言語がRustとC++しかないので当たり前
ただしこの対等勝負でC++にRustが勝っている点は注目に値するかもしれない
0622デフォルトの名無しさん2022/09/12(月) 19:26:50.51ID:R6La1yEF
>>621
所詮どこぞのビルボード部門別1位だからな

KENTA周りでwasmが見えてるのかどうか
重箱の隅をつつくレアケース、まだ試食タイムかとか
話はそれから
0623デフォルトの名無しさん2022/09/12(月) 19:28:16.63ID:6xErrG1k
WasmはJavaとか変わんないのになんでアセンブリ名乗ってんの
いくらなんでもリテラシーが低すぎないか
0624デフォルトの名無しさん2022/09/12(月) 19:58:51.59ID:M7cyS1TF
>>623
そこは起源がasm.jsから来てるのだろうけど
決定的な違いとしてJava仮想マシンはガベージコレクション前提
Wasmはガベージコレクション無しで始まった点からもWasmがアセンブリに近いかな
0626デフォルトの名無しさん2022/09/12(月) 20:55:33.71ID:o4fglLbA
なるほど確かにそう言ってました
型システムが重厚長大でトランスフォーマーだらけで
「正しいコード」をコンパイラ通しづらくなるのよ。
とうせるんだけどそのための変更の労力が馬鹿になんなくなる。
で、やーめた、となる。。
0627デフォルトの名無しさん2022/09/12(月) 21:06:58.74ID:UhYQaJnf
コンパイル通れば問題ない

コンパイル通れば コードが成長すると加速度的にコンパイル通し辛くなる
コンパイル通っても 「問題ない」なんて理想でした

Rustでもどっちも当てはまる
0628デフォルトの名無しさん2022/09/12(月) 21:13:22.93ID:o/NFQNbK
コードが成長すると全体把握が難しくなるというのは分かるがコンパイル通すのが難しくなるというのは分からんな
イディオムに従えばコンパイルは通せるでしょ普通に
0629デフォルトの名無しさん2022/09/12(月) 21:20:13.29ID:fZo/hnBr
C/C++/低レイヤー/wasm/GC/大規模コード/概念的理解の精密化の
ヒント・間違い指摘・揚げ足取りは思う壺です。

プロレスに終始
0630デフォルトの名無しさん2022/09/12(月) 21:41:14.55ID:M7cyS1TF
>>626
Rustはコンパイル通し辛いとかないよ
もちろんどの言語でも慣れるまでは大変だけど
Rustも他の言語と同様に慣れたら大丈夫
0631デフォルトの名無しさん2022/09/12(月) 21:44:33.36ID:7cpDGgxf
荒らし本人は4回線で、ID維持、単発ID織り交ぜてサクラ、ごく稀に便乗

プロレスに終始
0632デフォルトの名無しさん2022/09/12(月) 22:18:50.83ID:CmFXNZxi
Scalaレベルで着地できれば御の字、あるいは...
Haskellはアカデミック勢が根強い、果たしてRustは...
0633デフォルトの名無しさん2022/09/12(月) 22:27:46.58ID:68AKLxnx
>>609
シナリオどちらかになるんだろうけど
どちらになってもRustを使いこなせる人が勝ち組じゃん
0635デフォルトの名無しさん2022/09/12(月) 23:18:05.19ID:vGI5q7L7
スタックとかヒープとかはC++の方から来た性質だから
Haskellは本当の敵ではないね
0636デフォルトの名無しさん2022/09/12(月) 23:46:25.23ID:7g4swwEZ
>>589
そこに上がってるのもほとんどがフレームワーク使ってシステム作ってますな使い方しか日本じゃしてないから、そういうとこにRustが入り込むにはもっと周辺が充実してからじゃないと日本じゃ無理じゃね?
0637デフォルトの名無しさん2022/09/12(月) 23:47:46.93ID:7g4swwEZ
>>596
COBOLとFORTRAN忘れてるぞ。
0638デフォルトの名無しさん2022/09/13(火) 07:23:17.27ID:gWDv6hSm
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
こんなところ
0640デフォルトの名無しさん2022/09/13(火) 08:14:25.37ID:y6KzmKzo
>>636
Rustだと所有権とかsingle mutable xor immutable referenceとかのキツイ制約があるから、フレームワークを作るのも使うのも大変。
まぁ、Rustフレームワークが充実することなんて無いんじゃない?
0642デフォルトの名無しさん2022/09/13(火) 09:59:52.44ID:zBh9FomI
小学生は方程式を使ってはならない的なキツイ規制が無いからこそ
C++やRustがやりたい放題やってる
0644デフォルトの名無しさん2022/09/13(火) 10:43:48.12ID:eyEnRRRC
「なんで鶴亀算だけで全て解かなきゃなんねえんだよ」
「鶴亀算だけなら俺が安全性や正しさを確実に保証してやれるからだよ!!!」
0645デフォルトの名無しさん2022/09/13(火) 11:41:37.83ID:4BnmNWCa
お待たせしました(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
0646デフォルトの名無しさん2022/09/13(火) 11:43:15.62ID:t741VCGK
お待たせしました(2/2)
↓New
Haskell アカデミック勢が根強い
   それ以外は衰退しました
OCaml 関数型で速度を最優先するならこれ1択
   StackOverflow >愛され言語ではない
FORTRAN 科学技術方面で強い、しばしば1択
Julia 科学技術方面開拓中
   StackOverflow >愛され言語ランキング上位
COBOL 金融機関方面では既存システムで根強い
   それ以外は衰退しました
0648デフォルトの名無しさん2022/09/13(火) 12:01:05.28ID:tpYV5tct
>>641
もっとまともな反論したら?
せめて「actix-web最強」ぐらい言えよ。使ったこと無いから知らんけど。
0655デフォルトの名無しさん2022/09/13(火) 13:22:39.32ID:B87y3gGt
>>609
既にそのパターン2で進んでるように見える
状況を認識できている世界的IT大手はいずれもRustを採用して高速と安全の両立へ
そしてまともなところは今後追随していくのが確実だからダメなクズが取り残される
0657デフォルトの名無しさん2022/09/13(火) 13:41:48.64ID:zBh9FomI
弱肉強食がもう通用しない
早く生まれた年寄りが遅く生まれた子供の肉を食うから
0658デフォルトの名無しさん2022/09/13(火) 13:43:26.99ID:H2N4SaFr
C++だって誕生当初からこれまで、先行投資なんか必要なく、
陳腐コモディティでも二極化でもないんだから

Rustも先行投資なんて必要なくてGAFAMのトリクルダウンをどっしり待つくらいで十分
トリクルダウンなんて期待してないけど
0661デフォルトの名無しさん2022/09/13(火) 14:16:27.24ID:/5hyl5nT
Rustの動きが興味深いのは、
C++の分野だけでなく幅広い分野で用いられてる点だが、
C++と異なり現代的な様々なパラダイムを簡潔に扱えるようシンプルに統合されてることも大きいのではないか。

もちろん、常に安全に自動的にメモリが解放される手軽さを得つつ、
少し注視するだけでC並みの高速化を安全に得られることが決定打なのだろうが。
0662デフォルトの名無しさん2022/09/13(火) 14:30:44.11ID:37EvHtEx
>>661
そう、Rustには興味のアンテナ張るだけ
先行投資なんてしない トリクルダウンって何年後?
0663デフォルトの名無しさん2022/09/13(火) 15:06:51.76ID:xxUpITvK
全プログラミング学習者へ。ハーバード大の入門講座「CS50」が無償かつ日本語で学べるようになりました!
https://www.lifehacker.jp/article/2209_cs50_new/
>「CS50」ではコンピュータサイエンスとプログラミングに関する概念や考え方、C、Python、SQL、JavaScriptなど主要言語を学べる

Rustは対象外(笑)
0665デフォルトの名無しさん2022/09/13(火) 15:16:52.14ID:Eka/sYHG
>>609の二極化が進みそうだな
企業もプログラマーもRustを使いこなして高速と安全とリソースコスト削減をできるか否か
0667デフォルトの名無しさん2022/09/13(火) 15:28:18.43ID:hXvJppW6
>>664
おまえ頭悪そうだな
Rustがコモディティ化するのと二極化するのとどちらがGAFAMなどの寡占を維持できるか?
C言語と同等に高速で安全も満たす言語がRustの他にない
0670デフォルトの名無しさん2022/09/13(火) 15:38:06.45ID:urKAOro+
>>667 >>662

GAFAMがRustを寡占するんだったら尚のこと先行投資なんてしない

GAFAM >Rustエコシステムには投資しない トリクルダウン無し 寡占する
0674デフォルトの名無しさん2022/09/13(火) 16:26:40.14ID:NZjV2Lo6
Rustを使える企業とプログラマーが有利になるだけで
あとは置いてきぼりを喰らって不利になるだけだろう
0675デフォルトの名無しさん2022/09/13(火) 16:28:34.29ID:MR/SvflR
こんな風に攻撃的に擁護する人のいる言語は使ってはいけない
高確率で地雷
0676デフォルトの名無しさん2022/09/13(火) 16:33:18.32ID:tpYV5tct
>>664
教育コストが高すぎて、大学で教えられないということだろ。
情報工学でLispをやらなくなったのと一緒だよ。
0679デフォルトの名無しさん2022/09/13(火) 16:38:33.78ID:O8KoebnP
>>676
Lispがわかりにくいのは単なる構文の問題
やってることはJavaScriptと変わらんよ
なぜかそれを凄いことのようにブランディングした先人たちのマーケティング能力の方が驚きだよ
0681デフォルトの名無しさん2022/09/13(火) 17:04:48.92ID:zuI+ipCK
プログラミング言語で闘争を続けて、1つも新しいソフトウエアやサービスを生み出せない日本の縮図だな・・・
欧米企業なら、「最初のバージョンは常に捨てられる」の格言通り、いかにいち早く世に出すか注力する。
なんで書いてあるかは余り関係ない
日本にも有名なソフトウェアのコミッターは数多くいるけど、コンピューターサイエンスというほとんど役に立たない事が
ものすごいマウントポジションをとるだけに使われ、人より早く書くや、人より多く書く人はありがたがらない。
欧米だと「アイデアは価値がない、アイデアを誰より早く形にして価値がある」とまでされる
0683デフォルトの名無しさん2022/09/13(火) 17:15:56.27ID:Zt4ZmGLP
>>681
はい、言語選択が決定的要因だとは思いません。

相関はあると思うのであえて言語/frameworkで聞きますが
Ruby(Rails)は現在で良い選択だと思いますか?
スタートアップだとかのサイト作成の場合
0684デフォルトの名無しさん2022/09/13(火) 17:20:10.04ID:zBh9FomI
書くのが遅いというか
お金をいくらもらえるか決めるのが早過ぎるのでは
カンバン方式みたいな
0686デフォルトの名無しさん2022/09/13(火) 17:28:11.67ID:rqfJwBbj
システムプログラミング系の講義ならrust使うものとかあるんじゃないの
0690デフォルトの名無しさん2022/09/13(火) 17:49:57.23ID:5oUbDcyQ
サイバーエージェントの広告配信サーバーもRustだし
クックパッドもRustだし
日本でもどんどんRustへ置き換わっていってるな
0691デフォルトの名無しさん2022/09/13(火) 17:51:04.29ID:rqfJwBbj
rust system programming course university
でググったらUMDとかTUMとか出てくるわ
大学で教えられないほど教育コスト高いということはなさそう
0693デフォルトの名無しさん2022/09/13(火) 18:10:20.77ID:zBh9FomI
ソフトは無料でも教科書には課金した方が
教科書の劣化コピーがネット上で大量生産されやすい
0694デフォルトの名無しさん2022/09/13(火) 18:35:59.90ID:Ouug8JCC
>>692
Rustは勝者のためのプログラミング言語だから敗者には必要ない
敗者は遅い言語や危険な言語を使い続ければよい
0695デフォルトの名無しさん2022/09/13(火) 18:41:40.88ID:rqfJwBbj
>>692
大学で教えられているかどうかとTIOBEのランクに関係がある理屈がよくわからんのだけど
0698デフォルトの名無しさん2022/09/13(火) 19:44:23.64ID:9HVO2bc+
ClojureはあれでCircleCIとかいくつかの実用サービスに使われてるのがすごいよ。

lispは遊びでいくつか書いたけど、実用的なサービスをこれで書く気はなかなか起きないんだよなぁ。
0699デフォルトの名無しさん2022/09/13(火) 23:26:20.76ID:CJstPXh2
>>663
コンパイル方式がメインな言語はCしかないの?
0703デフォルトの名無しさん2022/09/14(水) 10:07:19.36ID:K2Ymv4YJ
上ので思い出したけど
先にtypescriptやったあとrust入ったせいでリテラル型がないの違和感なんだけどなんか理由あるん?
enumでいいじゃん的な理由?
0704デフォルトの名無しさん2022/09/14(水) 10:42:39.99ID:gVevfQX/
>>703
文字列との相互変換とかIDE補完とかtypoエラーチェックとかExhaustive matchingとか他
どっちがどうなのかまとめて
0705デフォルトの名無しさん2022/09/14(水) 11:18:49.59ID:qMxoDGM7
お待たせしました(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#(実例根拠が待たれる) ←🆕
0706デフォルトの名無しさん2022/09/14(水) 11:21:13.69ID:puz0kIZm
お待たせしました(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と変わらん ブランディングした先人たちのマーケティング能力が驚き ←🆕

※ジョーク集です。「未確認」表示の有無に関わらず真偽を保証するものではありません。
0707デフォルトの名無しさん2022/09/14(水) 14:26:54.73ID:zwrBt+Xf
wsl2のdebian入れたら何故かgrepコマンドがなくてrust製のripgrep(rg)をいれたわ
0709デフォルトの名無しさん2022/09/14(水) 15:08:53.33ID:Xp2DUV88
>>708
どっちの立ち位置のコメントかわからないけれどripgrepを知らない設定は不自然
ugrepとの比較のこと?
0710デフォルトの名無しさん2022/09/14(水) 17:43:41.36ID:glLuISAD
WSL2にdebianの方の話だろ?
0711デフォルトの名無しさん2022/09/14(水) 17:45:19.09ID:e1B1zDJm
>>703
パターンマッチ使えば同じことはできるよ
なんならマクロでもいい
ゼロコスト抽象化に反することはしないのがRust
0712デフォルトの名無しさん2022/09/14(水) 17:52:32.97ID:9tETuf2A
>>711
値が"foo"という文字列以外が渡されるとコンパイルエラーになる関数とか書けないでしょ
0713デフォルトの名無しさん2022/09/14(水) 18:00:21.72ID:jv9cR4Ls
ただ単にコンパイルがこれ以上遅くなる言語仕様を入れたくないだけ、何がゼロコスト抽象化だわwまったく見当違いも良いところ
0717デフォルトの名無しさん2022/09/14(水) 18:40:04.75ID:fEwp+zOJ
マクロでコンパイル時型エラーにできる?
実行時ならアサーション入れたりでマクロで何とかなりそうだけどコンパイル時に検出は無理くない?

個人的にはTypeScriptみたいな複雑さって本来過剰で、ブラウザ上のJSという特別な実行環境がゆえに必要になったもので、本来はenumとかで済までいいと思う。
0718デフォルトの名無しさん2022/09/14(水) 18:45:22.21ID:NFr/kVLx
>>698
lispは惑星探査機とか、特殊な用途で使われてるイメージ。
身近なところだと、ルンバがlispで動いてたはず。
0720デフォルトの名無しさん2022/09/14(水) 18:53:12.24ID:KdAr4qV+
>>717
マクロの引数をリテラル限定にしてその値をコンパイル時にチェックするくらいならできそうだけど
変数経由で渡されたときにその中身を確認するのは無理だろうな
Rustの依存型は提案されたけど入らなかったね(理由は忘れた)
0721デフォルトの名無しさん2022/09/14(水) 18:56:03.38ID:eqqO6UXU
自動車 船舶 航空宇宙のプログラムで求められる安全性ってRustは保証しないの?
0722デフォルトの名無しさん2022/09/14(水) 19:13:40.15ID:Jmciqxd+
>>714
>だからマクロでできるっての
>お前が何も知らないだけ


>>720
>できそうだけど

これってまさか同一人物の発言?
0723デフォルトの名無しさん2022/09/14(水) 19:22:13.99ID:KdAr4qV+
いや別人
自分はマクロを使っても完全なサポートは無理だと思ってるよ
マクロを使ってなんとか実現できそうなことを書いてみただけで
0724デフォルトの名無しさん2022/09/14(水) 19:35:40.12ID:ynFB7Nxb
現実派の>>723さん、>>721についてはどう思いますか?
突き詰めるとメモリ安全性って自動車 船舶 航空宇宙でも大きなウェイトを占めていてもおかしくない気がするのです。
Rust方面の意識として乗り物関連は避けたいとかあるんですか?

「Chrome」で対処されているバグの種類
https://asset.watch.impress.co.jp/img/wf/docs/1439/971/image3.png
0727デフォルトの名無しさん2022/09/14(水) 19:44:04.15ID:PyjIicam
>>724
トヨタが自動運転関係でRust使ってる話を見たことあるね
ChromeはRustで書き直せばバグを1/4に減らせると言われているね
0728デフォルトの名無しさん2022/09/14(水) 19:46:27.51ID:ynFB7Nxb
>>725
>安全を認定されたAdaツールチェーンの開発で培ってきた専門知識をRustコミュニティへ拡大する機会を提供する。
こういうのを待ってました!

>Ferrocene Rustコンパイラ
多分有償なんだろなorz
0729デフォルトの名無しさん2022/09/14(水) 19:50:08.79ID:BmzwXpH0
>>724
GC言語だと赤と青はまず発生しないからやっぱりRustは別にそれを置き換えることはないな
あくまでもCやC++を置き換える有力候補
0731デフォルトの名無しさん2022/09/14(水) 19:54:27.88ID:KdAr4qV+
>>728
FerroceneはRustコンパイラのISO26262認証取得を目指してるから
通れば自動車とかへの採用はあり得るよ
スポンサーもついているようだから少なくとも興味のある企業があるのは間違いない
Ferrocene自体はRustの特定バージョンの仕様を文書化して認証を取るという試みだから
コンパイラが別途有償になる予定はないはず
0732デフォルトの名無しさん2022/09/14(水) 19:55:03.16ID:AxsRNHLb
>>726
その記事を読むとChromeはC++のまま情けない解決策を取ろうとしてるなあ
特に参照カウンタ方式を強制するのは敗北に見える
メモリ使用量が増えると明記されているのはともかく
参照カウンタのデータ競合回避保護のためのオーバヘッドでパフォーマンスも大幅に悪化が予想されているのか
0733デフォルトの名無しさん2022/09/14(水) 19:58:45.25ID:ynFB7Nxb
>>727 >>729
>ChromeはRustで書き直せばバグを1/4に減らせると言われているね
>あくまでもCやC++を置き換える有力候補
この辺はタラレバくらいに思ってます、軍事関係みたく湯水の様にお金をつぎ込まない限り
0734デフォルトの名無しさん2022/09/14(水) 20:00:07.72ID:c3IeBynX
>>729
GC言語からRustへ置き換えるケースが多いのは別の理由でメリットが多いためだよ
・高速化
・省メモリ化
・データ競合の完全防止
0737デフォルトの名無しさん2022/09/14(水) 20:16:19.59ID:tyPb8uvV
Rustのデータ競合防止のやり方は効率性を犠牲にして安全側に倒してるだけでしょ
程度の違いこそあれ、純粋関数型で全部イミュータブルにすりゃデータ競合なんか起こらねえというのと同じようなもんだ
0739デフォルトの名無しさん2022/09/14(水) 20:27:11.32ID:KdAr4qV+
ゼロってことはないよ
標準ライブラリ内とか人間がデータ競合しないことを保証してるところはそれなりにあって、そこにバグが入ることはありうる
実際過去に発見されたことはあったはず
ただまぁ他言語はほとんどなにも保証してくれないから
それに比べれば十分メリットはあると思うけど
0740デフォルトの名無しさん2022/09/14(水) 20:33:35.83ID:KdAr4qV+
あと今人間が保証してるとこを機械的に証明しようという試みはあって
そういうのがうまくいけばゼロだと言える日がくるかもね
(そうはいっても証明手順に抜けがあるかもとかあるので真にゼロとはいえないかもだけど)
0741デフォルトの名無しさん2022/09/14(水) 20:34:31.90ID:SxGO9/pM
並行安全がーとかいうけど言語自体やライブラリを跨いで共通のお作法で並行並列処理を書けるGoと違って
Rustはあまりにもお粗末すぎるから結局無駄なことしてるだけとしか思わない
0742デフォルトの名無しさん2022/09/14(水) 20:42:58.80ID:9tETuf2A
>>737
効率が必要ならunsafe使うとか、適材適所で手段を選べるようにしてるから純粋関数型のたとえはちょっと違う気もする
0743デフォルトの名無しさん2022/09/14(水) 20:49:55.99ID:7hx6Nwjm
>>737
一般的にデータ競合安全性のためには
1. まず前提としてデータ競合の可能性がある場合にコンパイル時に自動的に必ず検知できること
2. プログラマーはデータ競合の可能性がある部分のうち下記3.以外の方法(アルゴリズムやデータ構造などの変更)が取れる場合は変更
3. データ競合の可能性があるとして残った部分はロックなどで競合回避

Rustが用意しているのは1.の実施と3.の機構の提供
効率性を高めるか犠牲にするかは2.の実施と3.の利用をどう行なうか次第でありプログラマーによる自由度がある
0744デフォルトの名無しさん2022/09/14(水) 20:58:16.45ID:tyPb8uvV
うん、だからそれデフォルトの挙動が安全側になってるという話だよね
そのレベルなら、デフォルトで全部immutableで必要に応じてmutableにできる言語なら十分に対策になってると言えるのでは
0745デフォルトの名無しさん2022/09/14(水) 20:59:30.08ID:1TdDwC+y
>>741
Goは並行しない場合もする場も様々な安全をプログラマーの自己責任で確保しなければいけないことが多すぎてそれ以前の問題があります
例えば非常に単純な>>556の例でもGoコンパイラはエラーとしてくれないためプログラマーが自己責任で防がなければなりません
一方で同じ問題例をRustならば>>560のようにコンパイルエラーとして検知できます
0746デフォルトの名無しさん2022/09/14(水) 21:07:13.43ID:PNfc8XBO
>>744
mutableを使った時点でデータ競合の可能性が発生するためコンパイラ等が検出する必要がある
一方で全てをimmutableにすると大量のガベージが発生して効率が悪い
効率と安全性を両立しているのはRust言語のみ
0747デフォルトの名無しさん2022/09/14(水) 21:15:24.31ID:c9vZvFEM
GCあり言語ならストップザワールドやGCスパイクとか体験できるじゃん。
でもRustだとそれができなくなる。
0749デフォルトの名無しさん2022/09/14(水) 21:23:32.90ID:9tETuf2A
>>744
mutableな共有領域に対するアクセスについてはコンパイラは特になにも保証しなくても良いということ?
そんな安全機構は邪魔なだけだから不要と
0750デフォルトの名無しさん2022/09/14(水) 21:58:51.43ID:VKXXNtX1
全部immutableと言うけど、スレッド間で通信するメッセージがimmutableなだけで
スレッド自体の状態は刻々と変化する

マルチスレッドが何の役に立つのかさっぱり分からない人にとっては
状態遷移をするにはスレッドを使うしかない言語の方が分かりやすい
0751デフォルトの名無しさん2022/09/14(水) 22:33:42.94ID:ynFB7Nxb
話が盛り上がっていたので見守ってました...
>>739 >>740
>機械的に証明
この辺もタラレバくらいに思ってます。「ゼロってことはないよ」の方が逆に説得力w

自分の現場は、石橋を叩いて渡る、です。(能力体力は十分)
RustはGAFAMなんかより自動車ISO認証級の実績積み上げがないと、下っ端が言い出すのも怖いくらいです。
Rust現実派の人が現れたので便乗してしまいました。ありがとうございました。
0752デフォルトの名無しさん2022/09/14(水) 23:00:59.98ID:wGnSnwqD
>>751
Rustは一貫して以下のルールでシンプルに安全性を保証している
「Rustコンパイラはunsafe部分を除いてプログラム全体の安全性を自動的に保証する」
「unsafe部分の保証と影響を外部に出さない保証のみプログラマーの責任となる」
つまりunsafeを用いたとしてもその局所的なコードのみ人間が注視するだけでプログラム全体が保証される仕組みをRustが提供している
従来の言語は安全でない部分がプログラム全体に散らばっている、かつ、言語が安全を保証する仕組みがない、という悲惨な状況であった
0753デフォルトの名無しさん2022/09/14(水) 23:22:08.01ID:c9vZvFEM
>>751
自動車業界はCやC++を使ってる。
0754デフォルトの名無しさん2022/09/14(水) 23:41:24.29ID:ynFB7Nxb
>>752
今後、オカタイところや人命に係る分野での採用記事事例など宣伝してもらえると嬉しいです。

>>753
自動車ISO認証取得+自動車への採用(どちらも今後の可能性)レベル、と書くべきでした。
「話はそれから」です。
0755デフォルトの名無しさん2022/09/14(水) 23:48:26.40ID:9tETuf2A
>>754
ちなみに今はどんな言語使ってるの?
枯れたツールチェインとなると結構古めのCとかかな
0757デフォルトの名無しさん2022/09/14(水) 23:56:26.57ID:ynFB7Nxb
普段は見てるだけなのですが、いいタイミングで便乗出来ました。
こういう現場もあるよという話が出来てよかったです。では。
0758デフォルトの名無しさん2022/09/15(木) 00:02:18.55ID:PSTi1Gas
GoogleとMicrosoftが共に各々で語っているようにC/C++で書かれた大規模ソフトのバグの7割はメモリ関係
例えば>>724のChromeでも7割がメモリ管理バグ
これがRustに移行すれば無くせるのだから新たなシステム作りでC/C++を採用するのはバカだけ
0759デフォルトの名無しさん2022/09/15(木) 00:05:23.23ID:nmd+p/jZ
>>746
それは、両立じゃなくて、選択肢があるってことだよね?
両立出来ていれば、わざわざ選択させる必要もないし。
0760デフォルトの名無しさん2022/09/15(木) 00:32:04.75ID:RdLyWE92
ファブルって最初は絵が受け付けなくて読んでなかったけど、いざ読んでみたら面白かった。
0761デフォルトの名無しさん2022/09/15(木) 00:34:56.77ID:YqiJR5lb
>>759
Rustの場合は常に安全が成立するから安全は選択肢ではない
アルゴリズムやデータ構造などを工夫することにより排他ロックなどを必要最小限にして効率化することはプログラマーの自由裁量
Rustにおいて安全と効率は両立できる
0762デフォルトの名無しさん2022/09/15(木) 02:14:17.68ID:/Qo8z/Hb
Rust「統一教会のほうから来ました」
0763デフォルトの名無しさん2022/09/15(木) 08:27:21.28ID:fhKzGp48
Rustは教官付き教習車だから、コンパイラの言うとおりに運転しないとブレーキ踏まれて前に進めない。

ソースコードのマネージャーにとっては福音だけどな。自分でコーティング規約を用意してコーダーに強制しなくても、コーダーが自分勝手にプログラムしてトラブルになる可能性が減る。
コーダーがコーティングしやすいかどうか、とかどうでもいい。

企業がRustを推奨し始めたのは、企業がマネージャーサイドでソースコードの管理コストを減らしたいから。コーダーは言うこと聞くやつを連れてくればいいという発想だよ。
0764デフォルトの名無しさん2022/09/15(木) 08:31:31.13ID:P/wAPOM3
>>762
統一教会は違くね?
0765デフォルトの名無しさん2022/09/15(木) 08:56:48.93ID:Z4cppPos
>>763
Rustはプログラマーに愛されている言語No.1しかも7年連続
快適なプログラミングのしやすさが特徴の一つ
0766デフォルトの名無しさん2022/09/15(木) 09:07:58.83ID:P/wAPOM3
>>707
grepに続いてtarも無い、と思ったらPATHから /bin が抜けてたわ。
/usr/bin にあるわけじゃないのか。
0767デフォルトの名無しさん2022/09/15(木) 10:01:50.79ID:rrfffa1i
お待たせしました(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は教官付き教習車だから、コンパイラの言うとおりに運転しないとブレーキ踏まれて前に進めない。 🆕
0768デフォルトの名無しさん2022/09/15(木) 10:04:34.27ID:HopAynZ9
お待たせしました(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 🆕

※ジョーク集です。「未確認」表示の有無に関わらず真偽を保証するものではありません。
0769デフォルトの名無しさん2022/09/15(木) 10:16:05.31ID:AewR1FC3
>>763
これってrustに限った話ではないのでは
例えば今話題のgoの未使用変数をエラーにするとかは同じ考え方だよね
0770デフォルトの名無しさん2022/09/15(木) 10:17:45.56ID:P/wAPOM3
>>768
C言語がないぞ
0771デフォルトの名無しさん2022/09/15(木) 10:18:10.05ID:P/wAPOM3
>>768
C言語がないぞ
0772デフォルトの名無しさん2022/09/15(木) 10:39:25.20ID:zVxtxmNw
>>769
Goは元々>>556の例を始めとして落とし穴があちこち多数仕掛けられている言語なので
まずは様々な落とし穴パターンをできるだけ多く習得して自分で責任を持って回避していかないとすぐに事故を起こしかねない言語でもある
だからそこで言う教官(コンパイラ)が指導ダメ出ししてくれないケースが多い中で未使用変数の件は親切に指導してくれる良い例
0773デフォルトの名無しさん2022/09/15(木) 10:59:43.56ID:OR8C0I/3
>>769
これ実質的に自己責任論だから
人間はみんな自己だよねと言っても無駄で、自己はこの世に一人しかいないという考え方なのさ
0776デフォルトの名無しさん2022/09/15(木) 12:24:52.85ID:Yrdeu38e
>>765 >>769
『Rustの作法に慣れたコーダーなら』コンパイラにブレーキを踏まれて止まることも少なくて快適だろうけど、慣れていない初級者・初学者のストレスは半端無い。

絶壁の学習曲線はRustの重大な問題で、これを何とかしない限りはHaskellくらいの普及率が関の山かと。
0777デフォルトの名無しさん2022/09/15(木) 12:49:54.52ID:6n/goZ6T
「教官、時速40キロで走っていると原付に追い抜かれて行きます。それに時間に遅れます!」
「奴は自己責任だ。お前は俺だけを見ろ」
「はい! あっ、事故っちゃいました、テヘ」
「ばっかも〜ん。しょうがないやつだな」

Rust、愛され言語No.1
0778デフォルトの名無しさん2022/09/15(木) 13:02:27.27ID:AewR1FC3
>>776
初学者が躓きがちなところって例えばどこなんだろう
学習曲線が急という話はあるが実際に初心者が苦しんでる箇所が知りたいなぁ

>>777
これって具体的に何のことを揶揄してるの?
安全性のために効率性が損なわれるという論はあるけどスレで出てきた事例が配列の境界チェックくらいでコンパイラ関係ないという
0779デフォルトの名無しさん2022/09/15(木) 13:21:46.17ID:N+NQH7M1
>>778
実効速度の事は揶揄してなくて、前半は>>681 >アイデアを誰より早く形にして価値がある
のことだと思うけど、
後半は手取り足取りでもChrome>>726でいう25%側で事故る(25%じゃ済まなくなる)、とか?

または愛されRust教官と生徒の...
大した意味はないと思う。
0780デフォルトの名無しさん2022/09/15(木) 14:34:36.53ID:7O/O6eid
まあ実際はrustで開発なんてほとんどしてないからな。
だから自信のない奴が無理矢理褒めてるんだよ。
0781デフォルトの名無しさん2022/09/15(木) 14:42:23.71ID:AewR1FC3
>>780
褒めてる側に怪しい人がいるのはそうだけど貶してる側も具体的な話に乏しくて印象だけで語っている人がいるような
0782デフォルトの名無しさん2022/09/15(木) 14:58:36.52ID:YdvnBlXp
Rustは荒れるので話題転換

Clojure Haskell Lisp辺りの過去に一世風靡?した言語が先端分野で地道に使われ続けてるのは
単純に個別要因(研究者の好みとか)なのだろうか。
Lispくらいの歴史があるのならともかくClojure Haskellである必要性必然性が理解できない。

リストにあるNimも何を目指してるのか、何が得意なのか見えない。
Pythonからの乗り換えに最適、って出てくるのはNumpyも使ってないPythonコードの高速化例が主で、
この程度で「研究者の好み」に響くのか疑問
0783デフォルトの名無しさん2022/09/15(木) 15:09:17.30ID:YdvnBlXp
率直に言うと、Nimには開発者、コミュニティの言語オタク感が、、(いい意味で)
0784デフォルトの名無しさん2022/09/15(木) 15:26:45.00ID:5tgK0LqN
>>763
ソースコードのマネージャーw
妄想が過ぎるやろww
お前やっぱり複オジと同じ種類の人間やな
0785デフォルトの名無しさん2022/09/15(木) 15:28:52.49ID:YnVRyWH8
>>782
エンジニアの単なる個人的な好みだよ
スタートアップの開発はだいたいエンジニア1人~せいぜい2,3人で始まり、作り方について外から誰も口出さないから、何でも好きなものを採用できる
とはいえあまり変なものは後からリプレースされることも多いが、あえて関数型使いたがるような奴は比較的優秀だから結果的に生き残りやすいんだろうね
0786デフォルトの名無しさん2022/09/15(木) 17:40:49.72ID:DPUhxpSw
>>776
どの言語もそうだけど慣れの問題だけだよ
慣れるまでは躓きやすいけど
慣れてしまえばそこに何か支障があるわけではなく快適

もちろん手続き型言語しか使ったことがなかった人が関数型言語を始めれば 最初だけカルチャーショック的なものもあるかもしれない

Rustは従来の手続き型言語のバリエーションの範囲内であり難しい点はなにもない
最近は増えてる関数型プログラミングを積極的にサポートしているだけの普通の手続き型言語である
0787デフォルトの名無しさん2022/09/15(木) 18:14:28.13ID:OR8C0I/3
ブレーキ云々は関数型ではなく静的型に責任がある
と理解するまでに10年単位の時間を消費してるのが現実
0788デフォルトの名無しさん2022/09/15(木) 18:19:41.49ID:uryhzbE3
lispはプロトタイプから本番に移行するに向いている的な事をどこかで見かけたんだけど、何か理由あるのかな?

本番であれば、今時は静的型付けの方が実行前にミスを減らせて良さそうって思うんだけど。
0790デフォルトの名無しさん2022/09/15(木) 18:42:43.79ID:/dOm+x1c
Concurrencyについては詳しくないんだけど
goはやっぱりつよいの?
erlangよりつよいの?
0791デフォルトの名無しさん2022/09/15(木) 18:55:22.88ID:fhKzGp48
>>786
マニュアル教習車の運転を「慣れの問題」と言っているようなもんだな。
最初はエンストしまくっていても、慣れればいつかは運転できるようになるわな。それがいつだか知らんけど。
0793デフォルトの名無しさん2022/09/15(木) 19:48:17.43ID:/Qo8z/Hb
統一教会「Rustをお持ちしました」
0794デフォルトの名無しさん2022/09/15(木) 20:20:12.75ID:+mjTxJT1
嫌いなものにはとりあえず統一教会と絡ませておけば批判したことにできる頭の具合が羨ましい
0795デフォルトの名無しさん2022/09/15(木) 21:03:43.45ID:/Qo8z/Hb
統一教会「晋三を捧げよ」
0796デフォルトの名無しさん2022/09/15(木) 21:29:46.27ID:/Qo8z/Hb
>>794
いやあ、それほどでも(照
0798デフォルトの名無しさん2022/09/15(木) 21:55:28.22ID:/Qo8z/Hb
マジか。
0799デフォルトの名無しさん2022/09/15(木) 22:18:19.78ID:rqzHv7Xe
>>788
common lisp とかだとあとから型書いてパフォーマンス上がる処理系とかあった気がするし、プロトタイプから色々柔軟に改修しやすいとかあったのかもね。
0801デフォルトの名無しさん2022/09/15(木) 23:18:38.32ID:M8k2LDUe
バージョンが 1.0 に達していない言語は混乱するだけだから入れなくていいよ
必要なら専用スレを立てた方がいい
0803デフォルトの名無しさん2022/09/16(金) 01:45:52.39ID:gYqpDin4
ちゃんと>>1に「スレタイ以外の言語もok」と書かれているように
それ以外の言語の話もこのスレでは歓迎です

スレタイは文字数制限があるため全ての言語を列挙することはできません
もし話題の多い言語が出てくれば話題の少ない言語と交代することになるでしょう
登場して20年以上経つ古い言語はもちろん対象外です
0804デフォルトの名無しさん2022/09/16(金) 06:52:08.13ID:fjE4y/uE
Rustを外せ(コッソリ
0807デフォルトの名無しさん2022/09/16(金) 07:52:17.18ID:ATWJ//93
>>796
彼女が企画もののAVに出てそう
0808デフォルトの名無しさん2022/09/16(金) 08:18:42.51ID:g+vpwU6C
>>790
goは聞きかじりだけどもシングルスレッドのコードを気楽に拡張して同時実行にできることが売りに見える
erlangは最初から並列であることを求めてるから方向性が違う
どっちも強いは成り立つんじゃないかな
0809デフォルトの名無しさん2022/09/16(金) 10:19:44.03ID:0Y0F2QEG
お待たせしました(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の重大な問題 🆕
0810デフォルトの名無しさん2022/09/16(金) 10:22:00.77ID:RyrM8365
お待たせしました(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  金融機関方面では既存システムで根強い それ以外は衰退しました
0811デフォルトの名無しさん2022/09/16(金) 10:24:50.31ID:bc2jlm7t
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 🆕

※ジョーク集です。「未確認」表示の有無に関わらず真偽を保証するものではありません。
0813デフォルトの名無しさん2022/09/16(金) 14:24:20.93ID:JbBUDOVI
>>jakt 追加は
Bounds checking, Sound null safety
try/catchは文
Dict Set TupleがPython並みに簡単 この辺はlife-time-analysysに頼らないでARCで実行時管理してるからかな
0814デフォルトの名無しさん2022/09/16(金) 15:16:00.68ID:5FcoWQIv
ARCメインの言語はいずれも遅いから興味ないな
とはいえZigの手動メモリ管理の面倒さと危険さは今の時代ニッチに終わるだろう
0816デフォルトの名無しさん2022/09/16(金) 15:55:51.13ID:lXNxdC5B
ワッチョイスレのリンク見たら
Written on May 19, 2022 時点で >It’s two weeks old.
っていくらなんでもホヤホヤ過ぎでしょw
0817デフォルトの名無しさん2022/09/16(金) 16:35:54.10ID:5ihvg/eP
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は都合の良い例だけ持ち出して「境界チェックは消える」とか言いがち
0818デフォルトの名無しさん2022/09/16(金) 16:47:16.92ID:74dom6Tp
スマポの時点で自動じゃないわなw
循環参照はWeak使ってなんとかしてくれっていうね
あとライフタイムにも参照の排他にも
全部頑張って気をつけないといけないのは書き手

メモリはGCに押しつけてしまうのがスッキリなのかもね
そっちはそっちで工夫してねっていう分離ができてる
nimなんかはそこを交換可能にしてて清々しいよね
0819デフォルトの名無しさん2022/09/16(金) 17:31:52.57ID:EVJZN8ya
メモリに気配りしたいからこそrustを使うのであってGCで良ければGC言語使えば良いよ
0820デフォルトの名無しさん2022/09/16(金) 17:39:38.21ID:hXa4CTix
>>819 == >>814 だろ

形勢が不利になって面倒くさくなった?

じゃなかったら「Zigの手動メモリ管理の面倒さ」-->「Rustは自動メモリ管理で簡単」
みたいな書き方を明示的に否定してくれ

そういうところがRustの胡散臭いところ
0822デフォルトの名無しさん2022/09/16(金) 17:51:15.64ID:rsr6X2sj
GC言語使いたいなら止めはしないけど
それならスクリプト言語使った方がマシだよ
0823デフォルトの名無しさん2022/09/16(金) 17:54:38.33ID:l9zi2+Dh
笑った >>819 == >>814 ==821==822 だろ 何回線目?
Zigの話じゃなくて、「Rustは嘘ついてました」って謝罪しろよ
0825デフォルトの名無しさん2022/09/16(金) 18:21:34.07ID:fQY5NM7R
>>818
嫁や彼女が援交やってそうだな。
0827デフォルトの名無しさん2022/09/16(金) 18:28:16.66ID:fQY5NM7R
GCはメモリ確保やコンパクションや解放をまとめてやりやすいからパフォーマンス出しやすい。
そのおかげでストップザワールドやGCスパイクも享受できる。
負荷を予測したい奴には向いてないかもな。
そういう意味ではGC言語はピーキーなんよ。
お前にはまだ早いかもしれん。
0828デフォルトの名無しさん2022/09/16(金) 18:32:35.16ID:fQY5NM7R
>>824
swiftは問答無用でretain,releaseもつくからじゃんよ
0829デフォルトの名無しさん2022/09/16(金) 18:38:52.62ID:9KGaiKu/
GCは〜って言って思考停止してるとRustでも使っているepochとか知らなそう
0830デフォルトの名無しさん2022/09/16(金) 18:46:51.84ID:RqiYn650
いずれGCがメモリレイアウトを動的に最適化したり必要に応じて確定的なメモリ解放を行うように動的にJITしたりするようになるから、究極的にはGCが勝利するだろうね
0831デフォルトの名無しさん2022/09/16(金) 18:48:15.45ID:j69kQS4p
Zigの良さがよくわからない
C言語より安全なのはわかるけどでもそれって結局Cでいいじゃんってなるよね
Rustみたいに静的メモリ安全は実現するのは端から諦めてC言語よりちょっと安全な言語を目指しているんだよね
本当にニッチって言葉が似合いすぎている
構文も無駄に複雑だし汚いし将来性ないと思う
0833デフォルトの名無しさん2022/09/16(金) 18:52:48.51ID:LN15iZX2
>>831 ZigはBinary生成が優秀だから、依存dll/soとかクロスコンパイルとか。Rustでも使っているよ
0837デフォルトの名無しさん2022/09/16(金) 19:04:06.82ID:LN15iZX2
Zigは作者が会社辞めて専念してるから、華々しくブレイクしなくてもずっと続けてくコミットがすごい
「安全性」は流行っているからリップサービス。マインドは常に実行速度。キレイなBinary。低レイヤー。
構文はちょこちょこ変わるイメージ。ときどき触るだけだけと直ぐに昔のがコンパイル通らなくなる。
0838デフォルトの名無しさん2022/09/16(金) 19:13:49.58ID:LN15iZX2
Faster than Cが自慢なのはぶっ飛んでるように聞こえるけど、一時期あったVは嘘だったけど、Zigはときどき本当。
LuaJitでもHaskellでもハマる処理では「簡単な記述で」Cより速いときがある。やってみないとわからない。
0839デフォルトの名無しさん2022/09/16(金) 19:19:50.21ID:LN15iZX2
構文なんて飾りですよ。狭い特定の処理がたまたま「簡単な記述で」書けるかどうかだけ。今はまだ時々実験するくらいで十分。深入りは先の話。
0847デフォルトの名無しさん2022/09/16(金) 20:08:18.02ID:0J+L4jjc
>>843 教えてください。検索すると30年位前の論文なんかも出てきて実現しているのかどうか、
それが>>830で言っているGCと一致しているのか、ちょっと理解が追いつきません....
0848デフォルトの名無しさん2022/09/16(金) 20:23:30.89ID:74dom6Tp
GCの研究が進んでよりよいものができるようになったとき
GC言語はそれをまんまと拝借できるから旨味あるよな
0849デフォルトの名無しさん2022/09/16(金) 20:34:49.53ID:0J+L4jjc
>>848 そうなんです。
ただ >>843の「incremental copy garbage collector」が30年以上まえから未だに研究されているのは検索すればすぐにわかるのですが、
nimで選べるくらいの実用段階なのか、更には>>830で言っている ものと一致しているのか、 重要ですよね。
30年以上の研究なんて逆に絵に描いた餅に思えたりするので。
0850デフォルトの名無しさん2022/09/16(金) 20:51:30.89ID:paysycNa
GC活用するだけじゃなくて、スタックフレームからエスケープしにくくする仕組みがあると面白いと思うけどね。

Rustほどガチガチだとだるいから、エスケープをコントロールするスマポみたいなクラスを用意するとか。
0852デフォルトの名無しさん2022/09/16(金) 21:21:31.00ID:74dom6Tp
GCもVMもどんどん改善してくれたまへ
JavaでHotSpotだのJITだの言い出したころワクワク感あったな
プログラマはプラットフォームに対してでなくて
これからはGCやVMに対してプログラミングをするだけでよくて
さらにGCやVMは誰かのおかげで勝手に改善されていくらしいという
0853デフォルトの名無しさん2022/09/16(金) 21:27:14.70ID:z5XcLMe6
http://www.kmonos.net/alang/d/garbage.html

ガベージコレクトされたプログラムの方が高速です。 これは直感に反するかもしれませんが、その理由は:

明示的なメモリ管理の際によく使われる手法は、参照カウントです。 代入があるたびにカウントを増やしたり減らしたリソースを挿入するのは、 速度低下の原因になっています。スマートポインタクラスでラップしても、 速度的な解決にはなりません。
(またいずれにせよ、 循環参照を削除できない参照カウント方式は、 一般的な解決策ではありません。)

オブジェクトによって獲得されたリソースの解放には、 デストラクタが使用されます。多くのクラスでは、このリソースとは 割り当てられたメモリのことです。
GCを使えば、 ほとんどのデストラクタが空になり、完全に削除してしまえます。

メモリ管理のためのデストラクタは、 オブジェクトがスタックに置かれたときに影響が顕著になります。
例外が発生したときに、全てのスタックフレームでデストラクタが呼び出され、 メモリを解放するような仕組みが必要となるのです。 もしデストラクタが関係しなければ、例外を処理する特別なスタックフレームを 設定する必要がなくなり、コードは高速に実行されます。

メモリ管理に必要なコードは全てを合わせるとちょっとした量になります。 大きなプログラムになるほど、キャッシュに入らない部分が増え、 ページングが多く発生し、 プログラムが遅くなります。

GCは、メモリが残り少なくなってきたときのみ実行されます。 メモリに余裕があれば、プログラムは全速力で実行され、 メモリ解放に一切時間を取られません。

モダンなGCは、過去の遅いものより遙かに発展しています。 世代型のコピーGCには、 昔のマーク&スイープアルゴリズムの非効率さはありません。

モダンなGCはヒープの詰め直しを行います。 これによってプログラムが活発に参照するページの数を減らし、 キャッシュヒット率を高め、 スワップ回数が減ります。

GCを使うプログラムは、メモリリークの積み重ねで次第にパフォーマンスが悪化、 という事態に縁がありません。
0854デフォルトの名無しさん2022/09/16(金) 21:34:12.96ID:W9x6+yw/
>>830
どちらもJVMで実現済みのことに思えるが…。

メモリレイアウトの最適化
→ 世代別GC(長寿命なオブジェクトは頻繁にGCしない領域に移動する)

確定的なメモリはJITで開放
→ エスケープ解析(短命でスタックに乗せても構わないオブジェクトはスタックに乗せる)
0856デフォルトの名無しさん2022/09/16(金) 21:39:12.85ID:paysycNa
>>853
近現代の言語だと例外は飛び抜けて重い機能だよな。c++使うときも自分から例外を使うこと無いし。
例外みたいなエラーフローあると便利なことあるんかね?
0857デフォルトの名無しさん2022/09/16(金) 21:39:55.16ID:W9x6+yw/
>>855
それも言語の良し悪しよりもbanがやるべきことをやってないだけだったり、nodeが本質的には不必要なことをやりすぎているだけっぽいと思うんだよな。
0859デフォルトの名無しさん2022/09/16(金) 21:45:22.11ID:lW11Z1GI
GC言語、メモリを山のように積んでるマシンだと走りきるまでGC走らなかったりするしな。
mallocしてfreeしないアプリみたいなもんで、ケースによってはそりゃ速い。
0861デフォルトの名無しさん2022/09/16(金) 22:04:21.30ID:N1Gu8JHK
>>857
要約すると、RustはZigに比べて本質的には不必要なことをやりすぎている、という事でOK
0864デフォルトの名無しさん2022/09/16(金) 22:19:05.45ID:EVJZN8ya
>>853
この文章10年以上前からあるけど今でも成り立つのだろうか

確かにメモリ解放を遅延させることによって実行命令数がGCの方が少なくなる場合はあると思う
一方でいくつかのmalloc実装がやっているような、直近にfreeされた領域を優先的に再割り当てするようなことは、GCが走らない限り、つまり、メモリを使い切るまではできない
freeされた領域はキャッシュに載っていて高速にアクセスできる可能性が高いので、直近にfreeされた領域を使い回すことはキャッシュヒット率を高める効果がある
GC言語は命令数は少なかったとしても、メモリのアクセスレイテンシの影響をより多く受け、トータルでは遅かったりしないだろうか

この文章の元ネタのベンチマークがあるなら現在のマシンで比較してみたら面白そう
0865デフォルトの名無しさん2022/09/16(金) 22:26:31.57ID:EVJZN8ya
>>861
アプリの実装の善し悪しの話と実装言語の善し悪しを意図的に混同させるのはよくないよ
0867デフォルトの名無しさん2022/09/16(金) 22:44:06.52ID:67q+IuG6
>>864
それソースある?
必ず再利用するにあたって領域を書き換えてんだから、直前にfreeしたかどうかに関わらず書き換え直後にキャッシュに乗るのは当たり前じゃないの?
チープな環境でスワップインを回避する効果はあるかもしれんが
0868デフォルトの名無しさん2022/09/16(金) 22:47:07.20ID:W9x6+yw/
>>858
曲解してるかなとは我ながら思った。
けど、GCが勝つというほどインパクトある伸び代が挙げられた項目にこれ以上あると感じないんだよね。
0870デフォルトの名無しさん2022/09/16(金) 22:54:48.64ID:aq1cgc5a
>>868
>GCが勝つという
そんな場合もある、程度では。

GraalVMでNativeにした場合で
Native Java(+GC) vs Native other(no GC)は気になる
0871デフォルトの名無しさん2022/09/16(金) 23:06:36.63ID:yQqW5GbJ
escapeするかしないか、静的と動的でそんなに違うもんかね。
むしろエラー以外はescapeする・しないは静的で相当範囲カバー出来てそう。データはないけど。
0872デフォルトの名無しさん2022/09/16(金) 23:12:50.46ID:lW11Z1GI
>>864
これはそう。ただ投機的実行(と昨今のその去勢)とかを考えると結構難しいかなとは。
0875デフォルトの名無しさん2022/09/16(金) 23:26:02.22ID:3cBZTpx6
>>872 vulnerability詳しくないけど、mitigationでfree->mallocがどの程度影響するのか気になるな。
0876デフォルトの名無しさん2022/09/16(金) 23:34:42.72ID:ATWJ//93
>>853
>GCを使うプログラムは、メモリリークの積み重ねで次第にパフォーマンスが悪化、 という事態に縁がありません。

嘘言うな
0877デフォルトの名無しさん2022/09/16(金) 23:42:23.80ID:n2V9aTfB
GCは解放の実タイミングは調整するけど「メモリリーク」とは見なしてないのでは。

むしろ Rust「メモリリークはメモリ安全性保障の範囲外」 の方なんとかして
0878デフォルトの名無しさん2022/09/16(金) 23:44:19.41ID:EVJZN8ya
>>867
GCはそもそもfreeから再利用まで間が開くのでその間にキャッシュから外れる可能性が高くなるし、
再利用に当たって領域を書き換えるなら、キャッシュに載ってない場合書き換え処理に時間がかかるのでは
スワップインはよくわからない
0879デフォルトの名無しさん2022/09/16(金) 23:45:28.20ID:EVJZN8ya
>>877
メモリリークを静的に検知するのはプログラムに対する制限が相当大きくなってしまうのでは
0880デフォルトの名無しさん2022/09/16(金) 23:53:17.42ID:MTo4LOAu
>>879 動的にでも検知する仕組み/試みがあったりするのかな。テスト、プロファイル、そりゃあるかな。
0882デフォルトの名無しさん2022/09/17(土) 00:05:17.29ID:guSBFHBz
GCはいわばメモリ管理の専門家に幅広い裁量を持たせて仕事させているわけで、
それに比べるとアプリケーションコード内でのメモリ管理はCenter of Excellence的な意味では原理的にどうしても不利よね
メモリ管理の専門家が十分な裁量を持って仕事できるのはせいぜいアロケータの実装くらいで、ほかは高水準のプログラミングモデルやプログラマの能力の制約を強く受けることになる
0883デフォルトの名無しさん2022/09/17(土) 00:13:57.81ID:WaM/gYIx
Javaは実行時最適化によりRustの3倍速い。
0885デフォルトの名無しさん2022/09/17(土) 00:44:08.92ID:wgXFenVD
スパイクの出ないGC出たら即乗り換える予定
0886デフォルトの名無しさん2022/09/17(土) 01:02:29.41ID:HP4MaZ5C
それ以来30年間GC技術が進んだ結果の現状が既出のこれ

>>200
>> https://pbs.twimg.com/media/EmYvG8aVkAMdfFG.jpg

全く対等に同条件で多くの人々が同じ問題に対して様々な言語で記述した結果の各実行時間
速く実行できた言語はRustとCとC++の3つでいずれもGCなし
GCする言語は軒並み遅い
一部をGC対象とならないよう回避の努力をしているGoがGC言語の中で最も速い
そうでない普通のGC言語は遅すぎる
0888デフォルトの名無しさん2022/09/17(土) 01:41:35.46ID:wgXFenVD
pythonさん
0889デフォルトの名無しさん2022/09/17(土) 01:47:29.96ID:5sn184WB
>>887
(1) GCが発生している場合
  → GC性能が改善された現在でもGC言語は遅い

(2) GCが発生していない場合
  → GC性能と関係なくGCが起きない段階でもGC言語は遅い

どちらのケースであってもGC言語はダメな存在になってしまいますね
0890デフォルトの名無しさん2022/09/17(土) 01:50:03.67ID:6EmGuQEd
あれ、D言語はかなり早いイメージだったけど、Goに負けることもあるのか
0891デフォルトの名無しさん2022/09/17(土) 01:52:02.97ID:WaM/gYIx
>>884
無いよ(笑
0893デフォルトの名無しさん2022/09/17(土) 01:57:29.45ID:5J0Fty65
Goは速いよ。

アンチGCはGC言語じゃなければ速い、と思い込みすぎでは?

ミッション車みたいなもんで、自分の設計力の無さがパフォーマンス劣化に直結するというか、いわゆるベンチのスペックは素直には出ないよ。
Rustアンチじゃないけど、これはRustの目的でもない(あくまで安全が目的)

GC言語みたいにだれでも80点が取れます、エンストしませんよ、みたいなもんじゃないんよ。

コンパイラが叱ってくれるからハイパフォーマンスとか、書いてて言ってんのかほんとに謎。
0895デフォルトの名無しさん2022/09/17(土) 01:59:07.17ID:WaM/gYIx
>>886
そいつの読み方は「C++とPyPy3圧倒的じゃないか」ですよ。
新参者から熟練者まで数と質すべてが圧倒的。
C++は熟練すると、黒魔術を含め、やりたいことが全てできる言語なので、突き詰めていく性質の企業におすすめ。
逆に、手数で勝負の乱打スタイル企業には、PythonやRoRがお勧め。
0896デフォルトの名無しさん2022/09/17(土) 02:01:08.18ID:WaM/gYIx
>>893
Javaも速いですよ。
Rustの3倍は冗談だけど。
欠点はメモリーを使いすぎること。
一般的なパソコンはメモリーが少し足りない。
だから、Javaは遅いと思われてる。
ミスマッチです。
0897デフォルトの名無しさん2022/09/17(土) 02:04:15.85ID:WaM/gYIx
ハードウェアを売りたい言語だから、ハードウェアに対する要求が少し厳しかったですね。
0898デフォルトの名無しさん2022/09/17(土) 02:25:11.61ID:YHpfxvp6
>>886
やはりGCの言語はいずれも遅いな
GCのせいで遅くなるのではなく
ヒープでメモリ確保するからGCの言語は遅くなる
0899デフォルトの名無しさん2022/09/17(土) 03:31:52.64ID:5J0Fty65
>>896
Java速いよね。あんまり適切なXmx知られてないだけだと思う。

>>898
少なくとも知ってる範囲だとGoもc#も取れるときはスタックを確保するぞ。
0900デフォルトの名無しさん2022/09/17(土) 03:42:09.24ID:o0T2dyfd
>>899
Javaは遅いです
どのベンチマークでもC/C++/Rustの2倍~数倍はJavaが遅いです
>>886の例でもJavaは数倍遅くなっています
0901デフォルトの名無しさん2022/09/17(土) 03:53:04.00ID:5J0Fty65
>>900
abc 182-eはakariって問題なんだけど、読んだ?
Javaで雑に書くとパフォーマンスでない類の問題だよ。

このグラフは言語オタ勢には有名かと思ってたけど、ベンチマークのグラフではなくて、あくまで競技者が書いた言語毎の統計のグラフなので、ポンコツが多ければそれが表現される。
言語人口が多いものの箱ひげが偉いことになってるでしょ。
0902デフォルトの名無しさん2022/09/17(土) 04:54:39.17ID:1eeK5YMC
>>901
なるほど
しかしJavaで書いて最も速くできた人でも遅くて
Rustで書いた平均的な人たちにすら負けているな>>886
どんなに優れた人であってもJavaを使った時点で遅いと確定してしまうのは辛いな
0903デフォルトの名無しさん2022/09/17(土) 07:28:28.63ID:8assD4qG
>>877
これ訳わからんよね。
そこまでして「GC不要でメモリ安全」を売りにしたかったのか、と思うわ。
c++とかだとメモリリークも普通にバグ扱いされるのに、それを「メモリ安全」と言い切るのは詐欺臭い。
0904デフォルトの名無しさん2022/09/17(土) 07:39:14.89ID:8assD4qG
>>902
そもそもRust使える人間は他の言語に詳しい人間しか居ないだろ。

他の言語に詳しく無い人間がRustの絶壁の学習曲線をクリアできるとは思えん。
「Rustしか使えません」なんて人間は存在するのかね?
0905デフォルトの名無しさん2022/09/17(土) 07:46:13.48ID:TM5e0HO7
>>903
それは常識
一般的に循環参照の安全な解放を静的に記述したり静的にチェックすることは不可能
デッドロックも同じで静的に発生をチェックして防止することは不可能
だからコンパイラ(=静的にチェックする存在)がそれらを防ぐことは対象外となる
0906デフォルトの名無しさん2022/09/17(土) 07:50:22.53ID:XDvVGFlj
>>904
バカは遅い言語や危険な言語を使い続ければよい
時代の要請は高速で安全でプログラミング効率の良い言語でありそれはRust
使えないバカがついていけずに切り捨てられていくことは業界にとっても朗報だ
0907デフォルトの名無しさん2022/09/17(土) 08:47:42.31ID:+hLuAY/P
早い言語は適当に書いても2秒の時間制限に間に合うけど
遅い言語は問題の想定解法じゃないと通らないから結果的に早い言語は上髭多くなるだけ
0908デフォルトの名無しさん2022/09/17(土) 09:18:54.40ID:vRd8nzJr
>>902
execution timeの単位はミリ秒だぞ
ベンチヲタは気にするが1000000回ループして1秒か2秒しか差がつかないのに現実的に問題になることってないぞw
現実のループは多くてもせいぜい1000回程度だろ
0909デフォルトの名無しさん2022/09/17(土) 09:57:15.90ID:BhE3E6/v
>>908
あんたには遅くてダメな言語で十分なのだから他を気にせず不満を持たずそのままでいいじゃないか
あんたには無縁だが世の中には速くて安全で保守性も良い言語が求められているだけの話だ
0910デフォルトの名無しさん2022/09/17(土) 10:21:27.92ID:ktSmkMDB
Rustの他の言語と比べた速度向上って、俺にじゃなく世のほとんどのプロジェクトにとって五十歩百歩の微々たるものなんですわw
0911デフォルトの名無しさん2022/09/17(土) 10:29:26.87ID:KEhwIc0k
前に、rustでtsc実装した人、さらにgoで作り直すって、理由がrustには向いてないからって。翻訳記事だからニュアンス違うのかもしれないけれど。
0912デフォルトの名無しさん2022/09/17(土) 10:29:40.60ID:8assD4qG
>>905
プログラマサイドにそんな「常識」は無い。プログラマ視点なら「メモリリークはバグ。メモリを圧迫してトラブルになる危険がある」の方が常識。Rust関係者はそういうことを説明の奥の方に隠して「メモリ安全」とか誇大広告するから詐欺だと指摘しているわけで。

常識とかけ離れた俺俺定義を使うならちゃんと注意書きしろよ。
「メモリ安全*」
*メモリリークを除きます。
みたいに。
0913デフォルトの名無しさん2022/09/17(土) 10:35:04.81ID:xfq0iQEs
Amazonの>>9の記事にもあるけど
Rustへ書き換えるだけだけでリソースコストや電気代それに伴うCo2排出量などが少なくとも50%は削減できる
さらにセキュリティの要請から安全性も求められている
土方でないまもともなプログラマーならばJavaでもRustでも他の言語でもプログラミングに支障なく書ける
それらの状況から選ぶべき言語がRust一択になっているだけでしょう
0914デフォルトの名無しさん2022/09/17(土) 10:39:04.61ID:ktSmkMDB
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
0916デフォルトの名無しさん2022/09/17(土) 10:55:22.36ID:8assD4qG
>>913
Rustを学習した人間の感想の多くが「Rustは難解」と言っているのに、「まともなプログラマなら支障なく書ける」とする根拠は?
根拠が個人の感想なら、「まともなドライバーならマニュアル車を支障なく運転できる」と言うくらい傲慢だと思うがね。
0917デフォルトの名無しさん2022/09/17(土) 10:55:41.70ID:gI44iNXP
>>912
それはちょっと知識不足じゃないかしら
もし循環参照を作っちゃった場合はそれを安全に解放する局所的な方法は理論的に存在しないんですよ
GCでも局所的に解決できる参照カウント方式では循環参照を解放できないため
GCの中でも全体のマークスイープ方式や全体の使用中分コピー方式でようやく解放されます
そららは非常にコストが重いだけでなく発動までに時差もあります

したがってプログラミング言語界ではそんなコストがかかるものに依存するのではなく
最初から循環参照を作らない方向で進んでいます
そのため最近は多くの言語で弱参照がサポートされており循環参照の発生を防ぐことができます

今回の話のJavaでももちろん弱参照が用意されていて最初から循環参照を作らないようにプログラミングします
そのほうが有利だからです
0919デフォルトの名無しさん2022/09/17(土) 11:12:08.51ID:/Lpl+zOG
>>917
Wikipediaですら「メモリ安全性」の解説でメモリリークをメモリエラーとしているのに、実装側の都合で一般に使われている用語の意味をひん曲げて「常識」とな?

そういうのが詐欺だと指摘しているだけだけどなぁ。

今度からちゃんと
「メモリ安全*」
*メモリリークを除きます。
と注釈付けろよ。
0920デフォルトの名無しさん2022/09/17(土) 11:17:11.83ID:gI44iNXP
>>918
それはC#でもJavaでもRustでも他の言語でも全て同じ方法です
どの言語も弱参照を併用して参照はツリー状のみにすることで循環参照の発生を防ぎます
もちろんそこには弱参照による弱い循環参照がありますが通常の参照はツリー状なので
おっしゃる通りに一瞬で解放することが可能です
0924デフォルトの名無しさん2022/09/17(土) 11:34:17.29ID:ktSmkMDB
今時循環参照くらいでメモリリークするような言語でよく安全を名乗れたもんだ
退化してるやん
0925デフォルトの名無しさん2022/09/17(土) 11:39:26.07ID:/MEkW9dR
昔は保守的GCというGCに人気があった
本当はゴミなのにゴミではないと判断することはバグではなく安全、という注釈つきのGCだった

この注釈は嘘だったという見方の方が今は優勢
0926デフォルトの名無しさん2022/09/17(土) 11:42:22.70ID:yVMylSLT
予想される次の手:
・循環参照の矮小化
 循環参照なんてめったに起こらないし
 普通に書いてたら発生しようがない
・問題の転嫁
 循環参照なんて書くほうが悪い
 循環参照によるメモリリークなんかを問題視するほうが悪い
・飛躍した結論
 とにかくRustは素晴らしい
0928デフォルトの名無しさん2022/09/17(土) 11:45:32.10ID:bMZyj00L
今は強い循環参照を作ってしまったら負けの世界
Pythonですら強い循環参照を避けるために弱参照が用意されていて回避できる
もちろんC#やJavaにKotlinやSwiftにも弱参照が当然あって回避できる
Rustなどのように強い循環参照が自然には発生しない言語仕様だと更に良い
0929デフォルトの名無しさん2022/09/17(土) 11:46:24.15ID:w5Ud45eS
メモリ安全とは何なのがまとまってるページとかは作れないんだろうか
0930デフォルトの名無しさん2022/09/17(土) 11:48:55.60ID:5J0Fty65
>>925
Bohemとかもそうだっけ?

循環参照に関しては、確かにメモリリークだけど、危険ではないんでは?
Dangling pointerにならんかったら良いんじゃ無いかなあ。

循環参照で放置されているものの解放に時間がかかっても、別に問題ないと思うんだけどな。メモリに極端な制約がある環境下でなければ。

最初から循環参照を作らないというのは一つなんだけど、そういうわけにもいかんのよ。
最近書いたけど、グラフなオブジェクトなんかは循環参照するじゃん。
0932デフォルトの名無しさん2022/09/17(土) 11:57:30.35ID:w5Ud45eS
ようやくわかってきたよ
C 言語 に大量にある 未定義な挙動が ないことをsafeって言ってんのか
ならメモリリークっていう現象事態はたしかにsafeだ
0933デフォルトの名無しさん2022/09/17(土) 12:01:39.81ID:Qv9rB708
>>923
単にメモリリークと言ったら含まれるけど、
メモリ安全性に関わるメモリリークの文脈では循環参照は言及されてなさそうなんだよね
メモリ安全性という言葉の定義だけの問題で、実用上問題になるという点ではよろしくないとは思うけど
0934デフォルトの名無しさん2022/09/17(土) 12:02:36.48ID:rp+oVngt
循環参照はコールバック等で普通に発生する
トレーシングGCでは全く何の問題にもならないから弱参照なんか使わんよ
0935デフォルトの名無しさん2022/09/17(土) 12:05:32.37ID:w5Ud45eS
ttps://doc.rust-jp.rs/book-ja/ch15-06-reference-cycles.html
循環参照は、メモリをリークすることもある

ここか
なるほど
0937デフォルトの名無しさん2022/09/17(土) 12:07:05.26ID:8assD4qG
>>931
今まである「メモリ安全性」の常識を無視して『メモリ安全性』という言葉を使わなきゃいいんだけどねぇ。
「プログラムの安全性にこだわった」くらいの宣伝ならまだわかる。

Rustはわざわざ「メモリ安全性」という言葉を使って宣伝しているんだからダメだろ。
0938デフォルトの名無しさん2022/09/17(土) 12:24:51.56ID:J+gZaL34
確定的なタイミングでトレーシングGCしてくれるようなスマートポインタって実現不可能なの?
0939デフォルトの名無しさん2022/09/17(土) 12:27:39.54ID:bwIIEGYu
勘違いしてる人がいるようなので正しい知識をまとめておきます

C++やRustのような非GC言語やリファレンスカウント方式のGC言語では(強い)循環参照の解放は原理的に不可能です
これらの言語ではデッドロック等と同様に(強い)循環参照は発生させてはいけない禁忌として扱われ発生自体を避けます
対処方法としては弱い参照を用いた弱い循環参照を用いるのが主流ですが
プログラムが自分で管理する範囲内で循環参照を作ってまとめて解放したり範囲内GCなどを用いる方式もあります

マーク&スイープ方式やコピー方式のGC言語ならば(強い)循環参照も解放することができます
ただしそれらの方式は全体空間を全てマークしたり辿ったりコピーしたりとコストが重いことの裏返しでもあります
さらにGCが起こるまで無駄にメモリを専有してしまう問題もあります
そのためこれらの方式のGC言語でも弱参照が用意されて(強い)循環参照を作らないようにすることが一般化しつつあります
0943デフォルトの名無しさん2022/09/17(土) 13:12:35.27ID:5J0Fty65
>>937
Rustのメモリ安全性、というのを先に定義しとるからなぁ。
そこはまぁ定義次第なのはその通りだと思う。
0944デフォルトの名無しさん2022/09/17(土) 13:18:40.25ID:Ct2ljdlf
>>938
無理だよ
だから各言語は現実的な対応をとってる
例えばC++のshared_ptrでも循環参照を起こしたらメモリ解放できない
回避策は強い循環参照を作らないようにweak_ptrを使う
Rustでは意図的に頑張らない限り循環参照が勝手に作られることはないけど
同様に参照をWeakにできるからメモリ解放可能な弱参照を用いた循環参照にして扱う
これはARC方式のSwiftでも同様で循環参照を起こしたらメモリ解放できない
Swiftでもweak宣言で弱参照にできるので解放できない循環参照を避けられる
いずれの言語もほぼ同じ仕組み
0945デフォルトの名無しさん2022/09/17(土) 13:55:15.51ID:Dua3tl/G
>>944 >Rustでは意図的に頑張らない限り循環参照が勝手に作られることはない
よくわからないので聞くけど、
Rustでは意図的に頑張れば、Weakにせずに循環参照データ構造を定義してzeroじゃない実データ構築をするコードがコンパイル通るの?
0946デフォルトの名無しさん2022/09/17(土) 13:59:18.77ID:8assD4qG
>>943
ならトップページに「Rustにおけるメモリ安全性」として「*メモリリークは除く」くらいはやらないと優良誤認だろ。
0949デフォルトの名無しさん2022/09/17(土) 14:26:47.74ID:Dua3tl/G
>>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
0950デフォルトの名無しさん2022/09/17(土) 14:30:22.04ID:Qv9rB708
>>937
循環参照によるリークを含むようにメモリ安全性を定義してる文献ってある?

Wikipediaの定義ではメモリリークという分類はあるけど、
"メモリ使用量が追跡されていない又は誤って追跡されている場合"
と説明されていて、前者は当てはまらないし、後者はダングリングポインタなどを意図しているようで、循環参照は含まないように読める

SwiftやChromeやAOSPやDのメモリ安全性に関するドキュメントでもメモリリークについては触れられていないようだった
0952デフォルトの名無しさん2022/09/17(土) 14:37:56.61ID:Dua3tl/G
>>951
>>944 >Rustでは意図的に頑張らない限り循環参照が勝手に作られることはない
warningがないし、当該データの使い方次第で実行時エラーにもならないので
意図しなくても、「偶発的に」循環参照が作られることはありそうだ。
0953デフォルトの名無しさん2022/09/17(土) 14:42:00.12ID:Dua3tl/G
潜伏した循環参照が後々深刻な事態になるかどうかは別の話だが
Rustだからと言って、コンパイル通ったからと言って、油断は禁物で
0955デフォルトの名無しさん2022/09/17(土) 14:44:11.19ID:EEEbWrXO
>>937
> 今まである「メモリ安全性」の常識
お前の脳内の話じゃないなら具体的にどういう事なのか示してみそ
0956デフォルトの名無しさん2022/09/17(土) 15:27:41.65ID:lGXhfZzC
すげーくだらないことで盛り上がってんなw
さすが次世代w言語wwスレwww
0957デフォルトの名無しさん2022/09/17(土) 15:28:08.55ID:5J0Fty65
メモリリークだけでは安全性には差し障らんでしょ。一般的に。
スタック、ヒープが枯渇することはメモリ安全性に差し障るけど。

リークしてるけど走りきった、とか、GCがまとめて解放した、はセーフだと思うよ。
0958デフォルトの名無しさん2022/09/17(土) 15:58:19.63ID:8assD4qG
>>950
そんなことよりもまず
「メモリ安全性は(プログラムによる)メモリエラーを許容するのか、しないのか」
はどちらだと思うのか考えてもらいたいね。Rustは「メモリエラーが発生するけどRustはメモリ安全」て言っている。
>>955も同じな。お前もRustみたいに断言するのかね。

まぁ、「c++よりもメモリ安全」というならまだ正確だが、それならそうと正直に言うべきだと思うがね。俺俺メモリ安全をwebページの奥の方に置かないで。
0960デフォルトの名無しさん2022/09/17(土) 16:11:02.02ID:Qv9rB708
>>958
「メモリ安全性」という用語の定義の話に変な造語持ち込んで話題そらすのやめてよ

Rustによるメモリ安全性の定義が俺俺というなら、ちゃんとした定義を示して欲しいな
「常識だから分かるでしょ?」というのは自分の思いの表明にしかならないよ
0961デフォルトの名無しさん2022/09/17(土) 16:15:15.87ID:EEEbWrXO
>>958
だからお前の思う「メモリー安全性」の定義を示せよ
まあ示せないからぐだぐだはぐらかすしか無いんだろうけどw
0962デフォルトの名無しさん2022/09/17(土) 16:22:09.35ID:8assD4qG
>>957
だとするとRustで常駐系のプログラムの開発をするのは安全では無いですな。
常駐系プログラムがメモリを食い潰すのは良くあるバグだけど、Rustだとそれは「仕様」で「メモリ安全の対象外」なんだから。
まぁ、Rcの循環参照だけの話だから、外部のコードを含めてRc使っていないor循環参照していないことを検証できれば安全なんだろうけど、Rustファンが言うような「Rustを使えば安全」というようなことは無い。

>>960
素直にWikipediaの「RAMアクセス時に発生するバグやセキュリティホールなどから保護されている状態のこと」でいいだろ。
Rust公式はなんて定義しているの?>>931は定義じゃないよな。
0963デフォルトの名無しさん2022/09/17(土) 17:12:30.63ID:Y2R7c2nA
「定義」や「常識」「一般的に」の話とは別だが、このスレ見てる個人的印象だと、
Rustで宣伝商売したい人たちは、Rustを知らない人(意思決定者)が「メモリ安全性」を「優良誤認」(自己責任)するのを密かに期待してそう
Rustプログラマーはそうじゃないと言い切れるのか
0964デフォルトの名無しさん2022/09/17(土) 17:14:19.56ID:d1cxOtJi
>>962
あんさんキチガイやな
それはRustの問題じゃない
>>939の説明が一番わかりやすいが言語全般における問題で原理的に解決できない問題やで
0966デフォルトの名無しさん2022/09/17(土) 17:33:54.35ID:F49YQPus
>>925
今はしらんがrubyのgcも保守的gcだったよ。
0967デフォルトの名無しさん2022/09/17(土) 17:35:17.75ID:F49YQPus
>>934
じゃあなんで弱参照が用意されてるんですかねぇ?
0968デフォルトの名無しさん2022/09/17(土) 17:40:51.90ID:nFfh6PUY
>>926の論法分析が的中してる

>>964
>言語全般における問題で原理的に解決できない問題やで

言語全般が「メモリ安全性」を宣伝してるって言ってる?

>原理的に解決できない問題

原理的もなにもRustプログラマーが常に:

>>919
>「メモリ安全*」
>*メモリリークを除きます。
>と注釈付

すれば良い
0969デフォルトの名無しさん2022/09/17(土) 17:42:57.37ID:Qv9rB708
>>962
メモリ安全性に循環参照によるメモリリークの抑止が含まれないことは認めてくれた感じかな?

Rustを使えば絶対安全とか言ってる人の言うことを信じるのは良くないよ
匿名掲示板の変な人の発言じゃなくてちやんとしたドキュメントを読んだ方が良い

Rustはメモリ安全性について独自の定義はしてなくて、Wikipediaに書かれているような意味でのメモリ安全性を保証するよ
0970デフォルトの名無しさん2022/09/17(土) 17:46:34.02ID:37/3YRxM
>>967
グローバルなキャッシュを実装するときなど、参照先のGCを妨げることなく長時間参照を持ち続ける必要がある場合に使用する
基本的にトレーシングGCで弱参照が必要になるのは極めてレアケース
0971デフォルトの名無しさん2022/09/17(土) 17:54:50.07ID:8assD4qG
>>964
新しい藁人形連れてくんなよ。
最初から
Rustの問題は>>903で、本来なら
「メモリ安全*」
*メモリリークを除きます。
とちゃんと注意書きすべき
という主張。原理的に解決できるかどうかとか主張していない。

>>964の言うとおり、原理的に解決できないのに>>963を狙って「メモリ安全」と宣伝しているなら邪悪すぎるな。>>964は「Rust公式は邪悪」と言いたいのかな?
09729702022/09/17(土) 17:57:12.28ID:37/3YRxM
なお、トレーシングGCにおいて循環強参照を避けることを目的に弱参照を使用することは全く何の意味もない
トレーシングGCのアルゴリズムを知っていれば循環強参照がGCのパフォーマンスやメモリ効率を悪化させることが無いのは明らかであるし、
弱参照の使用はレアケース故に概してあまり最適化されていないため、パフォーマンスは大抵の処理系においてむしろ悪化する
0973デフォルトの名無しさん2022/09/17(土) 18:01:07.97ID:F49YQPus
GCあるほうが楽だと思うんだけど、スパイクの無いGCって実現できないの?
0975デフォルトの名無しさん2022/09/17(土) 18:03:21.53ID:8assD4qG
>>969
いや?全然。
循環参照によるメモリリークはメモリエラーだろ。メモリ安全「RAMアクセス時に発生するバグやセキュリティホールなどから保護されている状態」じゃない。

それにRustファンの言うことを信じているとか、冗談を言うのはやめてくれよ。気持ち悪いから。
0976デフォルトの名無しさん2022/09/17(土) 18:04:26.55ID:RkjWnqae
>>972
え?
C#では循環参照を避けるためなどの目的で弱参照を使うけど
これは悪化させているとでも言いたいの?
0977デフォルトの名無しさん2022/09/17(土) 18:05:04.82ID:5J0Fty65
>>962
「どの言語でも基本的には、OOMキラーに殺される前にGCが走らせたり、手動でメモリーを解放できること」ができないと安全では無いんじゃないかな。なので環境依存よ。
そう、Rustを使えば安全では無い。
0979デフォルトの名無しさん2022/09/17(土) 18:17:28.35ID:DwuaYi+a
今回の件でGC言語がなぜ何倍も遅いのかよく分かった
世代別ガベージコレクションをするため頻繁にコピーGCを行なうことが遅くなる敗因の一つ
0983デフォルトの名無しさん2022/09/17(土) 18:37:21.32ID:5PJHomtk
四天王で最弱のGC。
0985デフォルトの名無しさん2022/09/17(土) 18:38:14.76ID:5PJHomtk
俺の考えたGCが最強だけど、サブマリン特許やる予定だから教えない。
0987デフォルトの名無しさん2022/09/17(土) 18:40:19.19ID:ykXCo787
GC言語を使うと大して楽になるわけではないのに劇的に遅くなるからな
無能にはGC言語が向いている
0989デフォルトの名無しさん2022/09/17(土) 18:42:13.95ID:5PJHomtk
Java製アプリはオメガテーつこてるけど、遅いとか重いとか一切ない。
サクサク快適。
だがしかし、キャレットの位置が異常なのでテキストの選択がやりにくい。
この動作はJava GUIの仕様だが、仕様が間違っていると思う。
Windowsと同じ動作にするべき。
0991デフォルトの名無しさん2022/09/17(土) 18:47:35.21ID:kG69OWVT
>>982
プログラマー指定せずとも自動的に参照カウントが使われる言語(PerlとかPythonとかSwiftなど)の場合はGCで合ってるよ
C++のshared_ptrやRustのRcのように特殊な用途のみにプログラマーが明示的に指定して使うものはGCとは呼ばれず単なるデータ管理構造
0992デフォルトの名無しさん2022/09/17(土) 18:48:56.73ID:KEhwIc0k
>>981
いつも出てくるこの自動解放されて楽って感覚がわからない。自動解放とか出来て当たり前じゃないの?

GCありと同等のルーズさが許されなら良いけれど、実際はメモリ管理を明確にさせられるよね。
0993デフォルトの名無しさん2022/09/17(土) 18:51:00.89ID:fAQVBQ3R
>>989
Javaは遅い
少なくともC/C++/Rustなどの2倍~数倍は遅い
Javaは仮想マシンだしGCあるし遅くなるのは仕方ない
0994デフォルトの名無しさん2022/09/17(土) 18:51:29.16ID:5PJHomtk
お子様 → Python
おんな → Ruby
真の男 → Rust

こう言いたいのでは?
岡くんは。
0995デフォルトの名無しさん2022/09/17(土) 18:52:46.32ID:5PJHomtk
>>993
ってことは、2~3倍遅くても何も問題ないってことだろ。
0996デフォルトの名無しさん2022/09/17(土) 18:55:08.60ID:5PJHomtk
パイソンとかジャッカルには厨二を惹きつける響きがある。
女がなぜRubyを使いたがるのかはよく知らん。
岡くんがRust推しなのは本読んでわかった気になったから。
0997デフォルトの名無しさん2022/09/17(土) 18:55:32.40ID:lBhMDjlR
>>992
C並に高速なプログラミング言語では自動メモリ解放は普通は行われない
これは例えば新世代言語であるZigなどでも同じで手動メモリ解放となる
唯一の例外が常に自動的にメモリ解放されるRust
10011001Over 1000Thread
このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 19日 7時間 35分 53秒
10021002Over 1000Thread
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。


───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────

会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。

▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/

▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
レス数が1000を超えています。これ以上書き込みはできません。

ニューススポーツなんでも実況