次世代言語28 TypeScript Swift Go Kotlin Rust Nim
レス数が1000を超えています。これ以上書き込みはできません。
スレタイ以外の言語もok
前スレ
次世代言語27 TypeScript Swift Go Kotlin Rust Nim
https://mevius.5ch.net/test/read.cgi/tech/1659655598/ 文字列の変数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) KotlinやSwiftは型推論できるやろ
それにパースとキャストは違うぞ 全然書き込みが無いけど
ypeScript Swift Go Kotlin Rust Nimって、需要も人気も無いの? >>4
今どきのプログラミング言語はいずれも型推論が賢いね
昔は型推論が無いか弱くて
変数の型宣言が不要というだけで動的型付け言語のメリットされていた時代もあった 次世代言語と言われる
TypeScript も Swift も Go も Kotlin も Rust も Nim ←これらの言語を全然知らない、
昭和の時代から IT関連業で働き、稼いでいた者には、居場所が無いから別の職種に転業すべきかなぁ >>7
TS、Go、Kotlinはいたるところで使われてるから、すでに現行言語では? 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などをはじめとする
複数の言語のエネルギー効率を相対的に示した研究結果を紹介している。 >>8
そういった系統の言語は、
業務で使用した事が無いから知りませんね。 >>9
Lambdaといえば、Common Lisp だな。
LISP - Lambda Functions matzは構文に人間が寄り添うのではなく構文解析を言語が頑張るべき的なことを言ってたけど、現実は構文は厳格にしてformatterやlnterが曖昧さのないコードに導いてやるのが正解になってきたね。
人間なんてどこまでも適当な事をやらかせるんだから、それを実行時にうまく解釈してやるのは無理筋。 >>16
構文の厳格さもformatterもlinterも関係ないじゃんw
頭悪過ぎる Pythonは当初の頓珍漢な理想を捨ててpython2を見捨てなかったのがえらいんだよ Rustを自分には向いてないと言った(恐らく本人は批判したつもりはない)一生懸命にmatzを叩くRust新興カルトが気持ちわる杉る....
CやC++でバリバリ書いてる人に所有権チェックなんて邪魔すぎるし、配列境界チェックだって速度が出ない足を引っ張る機能にしか見えないだろ
今は固定範囲の配列アクセスのチェックなんかは省略してるかもしれんが、恐らくそんな事はない(全てに係るから安全だと大口する) matzは静的型付け言語は
変数に型定義を書きまくるのが面倒くさい
というようなとこを言ってて
型推論とか知ってるくせにそれは
無いんじゃねと思ったな CやC++で困ってない人に無理にrustを勧めてくる人は相手しなくて良いよ matzのおかげでプログラミング文化が進化したのはのは間違いない
RustもRuby文化のいい面をかなり受け継いでいる >>19
所有権チェックって何?
そんな用語も概念も存在しない
配列境界チェックは
例えばインデックス値をforでループに回したとしても
最適化によりforでのチェックだけになり
インデックスを使った配列やスライスへのアクセス時に再びチェックすることはない
つまりC言語と同じになる
>>21
困ってる困っていないの問題ではない
回避策が確立されたのに欠陥言語を使い続けるか否かの問題
人間は必ずミスを起こしうる、との結論が出ていて
大手IT企業も挙ってRustを採用している みんな所有権所有権言うけど、初学者がひっかかりがちなのって借用の方では
所有権というとRAIIの方を連想してしまうけど
C++でmove使いこなしてた人ならRustの所有権ではひっかからないだろうし、他の言語でもtry-with-resourcesとか類似の概念あるよね うちの会社にもPHPで困ってないからと言いながらゴミを作り続けるおっさんいるわ >>26
そういうおっさんが業務の阻害要因になってるならなんとかした方が良いけど
掲示板上でどういう問題抱えてるかすら分からない相手に闇雲に勧めるのとは全然違うよね >>26
PHPは>>9の記事の観点からはエネルギー効率の悪い劣った言語かもしれないが
C/C++が現実に大量のセキュリティの穴も含むメモリ管理バグを引き起こし続けている危険な欠陥言語である点とは大きな開きがある >>27
おっさん自身は問題を理解できてないってことを言ってるんだよ どんなに優れたプログラマーでもミスをするしバグも作るって考え方は大事だと思うけどな #define new old
で、全て解決では? でもウェブサイトの9割はPHPで出来てると言うからなあ。 PHPを馬鹿にするやつにその資格はない
PHPの作者を馬鹿にするやつにその資格はない
PHPよりも作者よりも糞なやつが鏡すら見ずに薄ら笑ってる >>26
ゴミって言ってもそれでお金稼いでいる訳じゃなくて? >>24
んなこと言ってねーだろ。
ミスリードすんな。 Haskellが見向きもされなくなったら、Rustの宣伝が増えたな。 >>36
宣伝?
例えば>>9の記事はクラウドのシェアトップであるAWSがそのサービス提供にRustを使って構築しているという現実の話
着実に様々なインフラがRustベースへと置き換わっていく現実の一つ 限られた情報から善と悪を判断できない人達が
まだ公開されていないクソどうでもいいデータを欲しがる 今日Helidonなるものを初めて知ったわ
オラクル足掻いてるよねー rustは死産だったんだよ
このスレで頑張ってるのは水子供養みたいなもん 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に移植することで劇的な性能向上を私たちは見てきました。 >>35
いやいやC++で書かれたプログラムは無条件にRustで置き換えられるって主張は銀の弾丸って言ってるのと同じでしょ 善行を勧めることと、善行が必勝法であると主張することを区別する必要がある >>23
「最適化によりforでのチェックだけになり・・・つまりC言語と同じになる」
はい、明確すぎる嘘、Cは普通処理系によりけりだが通常は配列境界のチェックなんてしません。あほかwなにが、つまりだw
必死すぎるのがほんと痛々しい 所有権を邪魔だと思ってる奴のC++コードは読みたくねえな
一緒に仕事したくねえ…… >>46
インデックス値でforループを回すとあるから
C言語でもループ1回に付き必ず1回のインデックス値の境界比較が必ず入るよ
境界チェック無しでforを回したら無限ループになる >>48
Cって、配列のインデックスアクセスに境界チェックとか無くて、プログラマに委ねられているのかと思ってた。Cも意外に安全性を気にしているんだね。 >>38
javaのフレームワークって何使ってるの? >>44
その通り
条件を絞って
予めRustに移植することを意識して描かれたC++のソースのみ自動変換出来る
なら正しいかも知れない >>44 追加
ちなみに漏れは
「Rustに移植することを意識して描かれたC++のソース」
ならC++のままでええやん?的な立場 >>49
たぶん間違って読解してる。
良くも悪くも日本語って主語省略しちゃうからね。 >>53
え?
>>48で合ってるだろ
インデックスforループは境界比較しないと止まらん >>55
配列のインデックスチェックってここではモダンな言語は配列外にアクセスすると実行時エラーになるということを言ってるんだよ
Cはエラーじゃなく未定義だから何が起こるかわからん いや動的配列ならやっぱ実行時か
どっちにしてもCみたいに変更しちゃいけないところを変更して暴走しないってこと >>56
元の話は>>23だからインデックス値のforループ
C言語でも他でもfor文で境界チェックが必ず入る
配列アクセス時はまた別の問題
Cならばチェックしないがfor文でチェック済なので安全上の問題なし
Rustならばチェックするがfor文でチェック済なので最適化によりここでのチェックは消えて問題なし
結果としてCでもRustでも同じ生成コードとなる >>59
動的配列のランダムアクセス時にC言語では入らない境界チェックが入るな >>59
日本語で説明するよりコードと生成されるアセンブリ見せた方がわかりやすいのでは forループの例では同じ生成コードとなるが
範囲内かどうか不明なインデックス値がやってきてそれで配列をアクセスする場合は違いが出る
C/C++
プログラマーの自己責任で境界チェックを手動でしなければならない
忘れたときは未定義動作となりうるため危険
Rust含むその他の言語
プログラマーは気にせずとも自動的に境界チェックされるため安全 >>59
>Cならばチェックしないがfor文でチェック済なので安全上の問題なし
doubt
マジで言ってるなら去ね >>66
forでインデックスの境界チェック済みとあるから
配列のアクセス時に再び境界チェックしなくても安全でしょ いや、for文でのループ条件とか書き間違えてバグる筆頭だろ。
人力チェックの限界が見える典型。 Rust方式が速さと安全の両立でベストだろう
基本的には配列(スライス)アクセス時にインデックス境界チェックが行われて必ず安全
その上でインデックスforなどでループ内のアクセスがコンパイラにより安全と保証できる場合は
最適化によりループ内の配列(スライス)アクセス時にインデックス境界チェックが無くなり速さと安全を両立 もしもポインタが組み込み型ではなく外部のライブラリだったら
ライブラリを変更するだけでCはそこそこ安全になれた
C++はスマートポインタを追加することはできても
元からあるポインタ型を改善することは全然できなかった >>69
slice::Iterは<[] as Index>::index使わないから最適化関係なく境界チェックは一度だけになるが >>59
痛いRustおじさんの代表例だね、境界チェックが必ず入る処理系があったとしてそれを、C言語は!なんて表現しないぞ?
「結果としてCでもRustでも同じ生成コードとなる 」絶対ならないからwつーかアセンブラして貼り付けろよ?
それで常に100%が誰がやってもどのバージョンでもどの環境でも同じならあんたが正しい
そもそも配列ループの遅さをカバーするためにRustは速度を稼ぐために一部分ループ展開を勝手にするはずなので、gccとかなら
O2ではダメでO3でfunroll-loopsでコンパイルしないとならないよ >>72
もちろんRustはイテレータが強力だから
インデックスで回すよりもイテレータ利用が断然に多く
スライス(配列)アクセスに境界チェックを毎回しないのはおっしゃる通りだが
様々な理由でイテレータではなくインデックスでforで回す場合もあり
その時ですらforの終端チェックのみで最適化によりスライス(配列)アクセス時の境界チェックは消えている
という話だから両立する話 >>73
配列ループで遅いなんて聞いたこともなく実際に遅くなっていない
何を根拠にそんなデタラメで叩いているのだろうか 他言語の範囲forとかイテレーターを無視して「Rustのforが一番」とかいうのは無知を通り越して無能。
「C++のforループは危険」というのはさすがに引っ込めたみたいだけど、cのforループと比較してRustを褒めるのは邪悪すぎるだろ。 >>76
みんなが話しているのは配列アクセスの安全と速さ
forはその時に出てくるだけであってfor自体の比較を誰もしていない
そこに優劣もない >>77
その割にはforの安全チェックとか持ち出しているやついるけど。
それに配列ならコンパイル時にサイズが決定する/しないで全然違うけど、そこをごっちゃにしているアホがいない? ほんとダメだねえ、どうやっても遅いんだが?顔真っ赤にして人を罵倒する前にさ
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の勝手にループ展開でも言えますが
いずれもループ終了チェックであり、そんなのは比較していませんし、またあとから出てきたイテレータの話は全く違う話ですね >>78
批判するにはちょっと知識不足すぎじゃない?
みんなが書いているRustのスライスはコンパイル時に長さが確定しないから、確定する配列だけでなく、どちらの場合でも大丈夫ってこと 前スレでも出てたけどrustがphpより遅いってマジっぽいね >>79
あまりにキチガイでワロタ
その約20倍差の数値で比較しちゃってるのかよ
本気で20倍速いと思い込んでる? >>74
レス番つけ忘れたけど、頑にCと(速度が)同じだ。遅くないというカルト信者みたいな態度はほんと反省してほしいわ・・・
根拠を示したのにキチガイと反論するばかりで、こんな簡単なプログラムにさえどこが悪いのか言えないし 誰も20倍速いなんて一言もいってませんが?timeごときでこの程度の差が出るのであれば、「同じ」なんて言えないと思いますが?
むしろ境界チェックが機能してる結果であり、一方でCはそのような境界チェックは通常の処理系ではありえない=チェックがないので
安全性はlintなどやプログラマーの能力に依存する
提言:”内容に反証を提示できず、人をキチガイ呼ばわりする人がキチガイ” > 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側のどうこうはさておき、要素アクセスのときにケアできてるかどうかの話じゃないの? ちなみにJavaのjava.util.Listは
https://docs.oracle.com/javase/jp/8/docs/api/java/util/List.html#get-int-
E get(int index)
例外: IndexOutOfBoundsException - インデックスが範囲外の場合(index < 0||index>= size())
となってる。 現代のCPUなら投機的実行で境界チェックみたいな処理は時間コストかからんけどなあ
それとRustのprintln!は非バッファでロックもするから配列性能計測に混ぜたらいかんでしょ
性能計測の初歩だと思うんだけど Rustのスライスsでfor i in 0..s.len()でループ回して見たら
生成コードはforの終端チェックだけになってs[i]の境界チェックは消えるんだな
確かに論理的に正しい最適化だが賢いな
結局Cでfor (i = 0; i < len; i++) とした時と同じ println!取り除いてもCより遅いけど?
勝手にコードを変更してs.lenとか悦にはいってるし、この人たちって絶対objdumpした結果を上げないね
同じ(=100%一致)なんて絶対あり得ない、gccじゃなくclang/llvmにしたら分らんけど、それでも
”C言語は”なんてあんたさえも知らない処理系があるのに恥ずかし気もなくビックマウス披露出来るわけない
投機実行の境界チェックのバイパスは有名なスペクターとして脆弱性だから機能してないんちゃうか?知らんけどさ >>80
固定長なら範囲チェック自体消えるだろ。
Rustの話をするなら、「ひとつの読み書き参照 xor 複数の読み取り参照のきっつい制約を課すことで範囲チェックの回数を減らしている」くらいの説明はできんのかね?オレも詳しくはないが。 引数で与えられた配列の中の最大要素をインデックスアクセスで探す関数を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 っつーか今さらcでの開発なんて小規模じゃないとやりたくないわ。 >>92
凄いな
CとRustは同じ生成コードになるんだな
どちらも64バイトでループ展開か >>94
生成コードが同じだからCとRustは速さも同等っぽい わざわざ境界値チェックが不要になるケースで比べたらそりゃそうだろって感じ
最初のサンプルコードが酷すぎた 結論が出たな
Rustを攻撃してた人が以下のようなウソをついてた
> 「結果としてCでもRustでも同じ生成コードとなる 」絶対ならないからw
> つーかアセンブラして貼り付けろよ?
> そもそも配列ループの遅さをカバーするために
> Rustは速度を稼ぐために一部分ループ展開を勝手にするはず
生成アセンブラコード>92を見ると
CでもRustでも同じ生成コード
CもRustもループ内のインデックス境界チェックは無く同じコードとなっている
そしてCもRustも一部分ループ展開を同様にしてる
当然どちらも同じ速度となる >>98
早くc言語で境界値チェックするコード出してよ。 全然読まない、勝手にコードを変更してs.lenとか悦にはいってる >>102
配列やベクタやスライスなどを一般的に
C言語で扱う関数ならば先頭ポインタと長さを受け取る
Rustならばその二つがペアとなったスライスsを受け取りその長さ部分がs.len()
だから常識的なプログラマーならば誰が書いても>>92のソースコードとなる
そして生成アセンブラコードがCとRustで同等と判明した おじさん普通にC勉強した方が良いよ
Rust書ける人でC書けない人なんていないからズレまくった指摘してるんだよ
Rustであえてパフォーマンス出ないようなコードを書いてるとしか思えない >>92のシンプルなコードをこれ以上に速くするのは無理じゃね
そしてRustもCも同等のアセンブリコードを吐いてるから実行速度も同じで勝負ついた感じだな バカ野郎!
Rustのおっちゃんは、日本を代表するトライアングル(楽器)奏者なんだぞ! 少なくとも配列範囲外アクセスするようなコードで比べなければ意味がない。
誰も勝負なんてしてないだろ
こんな事やってるからRustを嫌う人が割と増えていく、言い逃れそのものだろw
そもそもforの終了条件チェックと配列境界チェックの違いすら分かってないやつだ
カルトRust信者「C言語でもループ1回に付き必ず1回のインデックス値の境界比較が必ず入る」
固定長のループがclang/llvmで同じになったとして、壺カルトRust信者曰く、「C言語は」という
デカすぎる主語と、Rustでのすべての配列境界チェックが無くなるわけではなし何が勝ちなんだか... >>107
コードを読めない人なの?
固定長のループではなく長さは関数の引数として与えられている
したがってC言語でもループ1回に付き必ずインデックス値の境界比較(=インデックス値が長さを超えないこと)がfor文の条件部で行われている >>92
例えばinline化とかで二つの配列/スライスがエイリアスされていることがコンパイラー(とプログラマー)に見えている場合があると思うんだけれど
Rustの方は自動ベクトル化してくれないのね。Cの方は自動ベクトル化されている。
極端に書くとこんな感じ。
ttps://godbolt.org/z/sbenoGEEa
inline
ttps://godbolt.org/z/M6qz3s3f7
max_value_slice_vwをどう書いたら自動ベクトル化されるの? 何の争いかよくわからんけどつまりRustでサイズ10の配列を作ってその11番目の要素にアクセスしたらどうなるん?
Cだと境界チェックしないから未定義になるしセグフォ出たり他の変数を書き換えたり暴走したりすることもある 11というのをリテラルで与えるともしかしたらコンパイルエラーになるかもしれんけどたとえばそれを乱数で生成した場合はどうなんの? Cが境界チェックしないと言うのは境界チェックがプログラマの責任だということだよね
Rust以外のモダンな言語では大抵範囲外の要素にアクセスしようとすると実行時例外を吐く
Cはそれをせず黙って暴走したりこっそり他の変数の値を書き換えたりして気づきにくいバグになる
Rustはどっち? >>109
わざわざw = v; とか
架空コードすぎて気持ち悪い >>112
Rustは基本的には他の大多数の言語と同じで、アクセスする前に自動的にインデックスの境界チェックをする。
ただし、>>92などのように多くのプログラム利用例では、インデックスはforで指定範囲を動くため、アクセスする際のインデックス境界チェックは最適化により必要とせず行われなくなり、結果としてC言語と同じアセンブラコードが生成される。 つまり、Rustは安全性を常に保ちつつ、不要な境界チェックは最適化で無くすことで、安全かつ高速を実現。 CとRustは同じアセンブリコードを生成すると>>92で示されているから
あとは他の言語でもそうなるならそれを示せばよい どうでもいい内容で盛り上がってるな
for文の仕様がボトルネックになることなんかないんだからどうでもいい 例えばfor (i=0;i<len;i++) arr[i*2]=0;
Rustはこの時もCと同じコードになるんだよね? gccのコミッターのものだけどそんな単純な話じゃないよ
Rustのスティーブとはよく話をするけどね まあこんなマイクロコードの比較だのベンチだのに意味は無いわな
コンパイラも局所だけ見て処理するわけでもなし >>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言語と異なる) >>123
境界チェックがあるって言われてるのはその場合のことだよ
最適化で無くなる時の話をしてるのは君だけじゃないかな多分 rust書けるやつはたいていcも書ける。
cは書けるがrust書けないなつはいる(俺とか)。
両方書けるほうがいいに決まってる。 >>123
後者はC言語だと範囲外をアクセスしてしまい破綻だな
境界チェックをするRustが正しい >>124
正しい使用ならば最適化されて境界チェックが消える点も重要やで
それによりRustのコードがCとほぼ同じ速度で動いている
一方で間違った範囲外のアクセスが起きうる場合には境界チェックがなされる点も重要やで
それによりRustはCとは異なり安全となっている >>123,126
> あとRustではその処理関数は引数をスライスxで受けることになり
> lenはx.len()となる
配列の一部だけを処理したいとか普通にあるだろ >>128
配列の一部分はスライス (配列全体も可)
Vecの一部分もスライス (Vec全体も可)
スライスの一部分もスライス
なのでRustで関数を書くときはスライスを対象にして記述する
そしてスライスとして扱った時点で既に境界チェック済み(=元の範囲内)なので最適化が可能となる さすが複オジ隔離スレやで
今日もいい仕事しとるww Rustの実行速度がCと同等だと何か困ることでもあるの? >>129
関数内でlenが決まる場合でもいちいちスライス作るのか? C/C++ で BITMAPINFOHEADER なんか扱うときは
意図的に範囲オーバーさせて bmp データにアクセスするよねω株 PI.3.14 >>131
Rustアンチの人にとって「Rustは遅い!」が信仰の砦。
ところが世間で言われてる通り、RustはCとほぼ同じ速さだと>>92で分かり、大変なことになってしまって大騒ぎ。 困るとか困らないとかじゃなくCではやらない境界チェックがあるから現実に遅いよ Cと同じ速度で動くコード「も」あるというならその通り
他の言語でもある >>132
Rustのスライスは抽象化された概念で扱われるけど
実体は先頭ポインタと長さのペア
だからスライスを作るって大層なことではなくC言語で処理対象の先頭ポインタと長さを用意するのと同じ
あと、Rustではforインデックス使わずにイテレータチェーンにすることも多いけどその時もスライス起点が多い
そのイテレータチェーン利用時も>>92の下でforインデックス時と同等の生成コードになることが示されてる
つまり境界チェックは起きずC言語と同じ速さで動く
>>136
C言語より遅いコードがあると主張したいならば
具体的に>92のように生成コードの比較を出せばよい 境界チェックが消えたコードじゃなく消えてないコードで比べてみたらすぐわかるんじゃないですかね >>135
コンパイルオプションでチェック無効に出来ないの? >>137
> だからスライスを作るって大層なことではなくC言語で処理対象の先頭ポインタと長さを用意するのと同じ
いや、実装は想像できるからいちいち説明してもらわなくてもいいんだけどC言語だといちいちそんなもの作らないよ
先頭ポインタも長さ情報も既にあるのに同じ内容を持つスライスを作るのは(C言語脳としては)無駄に思える >>138
CよりRustが遅いコードを具体的に出してよ
array[i*2]の例は危険な範囲外アクセスとなるコードだから境界チェックをするRustに軍配が上がるね
だから安全な正しいコードなのにCよりRustが遅いコードを具体的に生成コードと共に出しましょう >>142
プログラマが完璧なら危険ではないので上司のしりぬぐいをしないというのがCのスタンス
Rustはチェックするので正しいが遅い
あのー、わざとやってるのかバカなのかどっちなの? >>141
Rustではもっと抽象的に捉えてプログラミングするからそこに無駄と考える発想は出てこないし
同じだから無駄だといっても生成コードは最適化で無駄は消えるからCと同じ速さが出るでしょう 実例と計測結果出さないと空論でしか無いわな
まあ速度差が無くて出せないんだろうけど チェックが入ると遅くなるから最適化でチェック省くことがあるんだろうに何で実測しなきゃわかんないんだよ
特定のスニペットじゃなく境界チェックが入る現実のコードの話をしてるのに実測なんてできるわけないだろ
境界チェックが原因で遅くなるコード作れと言うなら作るが、それ作ったら間違いを認めるんだろうな? >>144
ホントに常に消えるの?
ダメなケースは存在しないの? >>143
それは君が誤解してるようにみえるなあ
Rustでは安全に範囲内のアクセスとRustコンパイラが分析できれば境界チェックをしないためCと同じ速さが出る
そうでなく危険な範囲外のアクセスになりうるとRustコンパイラが判断すれば正しく境界チェックを行なう
C言語で書いても危険な範囲外のアクセスになりうる場合は手動で境界チェックをせざるを得ないから速さは同じ >>149
遅くなる具体例ありそう?それ知りたい
RustとCのアセンブリ生成コードが同等になり速さが同じとなるケースは>>92で示されてるから
同じようにして遅くなるケースを示せばよいと思う
もちろん範囲外アクセスとならない例でw いつもの嘘つき複オジに必死に突っかかるアホ
どっちもどっち >>148
> そうでなく危険な範囲外のアクセスになりうるとRustコンパイラが判断すれば正しく境界チェックを行なう
C言語では外部からもらったデータは仕様で配列範囲に入るのが確実だからチェックをしないとかあるんだけど、Rustコンパイラとやらは仕様書まで読み込んでくれるのかなw 境界チェックによるペナルティが気になる箇所なら境界チェックのないget_unchecked使えば良いのでは
デフォルトは安全側に倒されてるけどプログラマの裁量で速度を優先することもできるので、適材適所でどちらを使うか選べば良い
C++でも境界チェックありのat()があるから、デフォルトが逆なだけでできることは同じだよね 結局プログラマーの手に委ねていると必ずミスが起きうるから
境界チェック省略の件も含めて全てについて
コンパイラが分析して安全かどうか判定できた時にはチェックを省略し
そうでない場合は安全のために自動的にチェックをするのがベスト
という方向へ向かっているんじゃないかな
GoogleやMicrosoftがRust言語でOS開発
https://xtech.nikkei.com/atcl/nxt/column/18/00692/042700054/
【脆弱性の70%がメモリー管理バグに起因】
GoogleによればAndroidに存在した深刻なセキュリティー脆弱性の70%近くがメモリー安全に関するバグに起因するという。
同様にマMicrosoftも、同社製品に存在したセキュリティー脆弱性の70%がメモリー安全に関するバグに起因すると述べている。
C/C++を使う限りセキュリティー脆弱性を根絶するのは不可能と考えて、Rustを採用するに至ったというわけだ。 >>150
じゃあCよりRustが遅くなるコードを示せばごめんなさいすんのか?しないだろ?
ここまでの説明でわからないバカがいるはずないからレスバしたいだけだよな? この話題、ここ数年で最もレベル低いんじゃないか?大丈夫か? Rustは安心安全でC言語と同等の速度ってことでFAだな >>142
>array[i*2]の例は危険な範囲外アクセスとなるコードだから境界チェックをするRustに軍配が上がるね
array[i*2]の例は危険な範囲外アクセスとなるコードだから境界チェックをしないCに軍配が上がる
が正しい いやはや、時代についていけないCオジが暴れてるようだなw
Cオジもさぁ、自分の世界に引きこもってないでもっと外の世界見ないとねw Cこそ最強!
1個でもCより遅いケースあったらダメね! 次世代言語スレなんだから変数の境界越えたアクセスは落とす一択だろ。
もうちょっと別の話したいわ。 1個でもCより遅い場合あったら、他にメリットあっても意味ないから! 誰も>>91の突っ込み無いんかよ。
Rustが速いのは非常にキツイxor条件を満たす範囲だけで、そこを超えるのはとても面倒。そこを無視して「Rustは安全で高速」とか言うのは詐欺じゃね?
あと、次世代スレなのに何でRustとcだけの比較なんだよ。rangeの最適化なんてイマドキc++ですらやるんじゃないの? このスレは何もかもをRustと比較したがる信者とそれに反応してしまうバカに乗っ取られた隔離スレです
次世代言語スレではありません
次世代言語の話がしたいかたはこちらへ↓
次世代言語27 Nim Zig Pony Carbon Gleam
https://mevius.5ch.net/test/read.cgi/tech/1659660050/ ていうかこいつほんとにRust使ってプログラミングできるの?って思ったんだけど
あまりにも頭が残念すぎて論理的思考の必要なプログラミングができるとは思えない >>165
Cで書いた方が良い箇所はCで書けば良いのでは
アプリケーション全体を単一言語で書かなければならない理由もなかろう >>167
最終レスが8月18日とか終わってんじゃねえか TypeScriptは次世代なのか?
そろそろ枯れてきてるし何ならバニラが復権しかけてんだが >>169
そんなこと言ったらRsutを使う場面が無くなっちゃうだろ Rustはスライスに対して境界チェックをしないでアクセスする方法もunsafeで用意されている
つまり最適なプログラミング方法はC/C++を絶対に使わずに全てをRustで記述し
「コンパイラによる安全保証で最適化により安全に境界チェックを省略してくれる部分以外」かつ「人間による安全保証で境界チェックを不要としたい部分」のところのみunsafeで人間が安全保証し
その部分以外は全てコンパイラにより自動的にあらゆるメモリ安全保証させるのが最適な方法となる >>137
>>109は RustがC言語より圧倒的に遅いコードです
>>166 172
>Rustが速いのは非常にキツイxor条件を満たす範囲だけ
>「Rustは安全で高速」とか言うのは詐欺
>そんなこと言ったらRsutを使う場面が無くなっちゃうだろ
完全同意
Rustの最適化度合いは一貫性がなくて信頼できない
「Rustで高速化」が少しでも視野に入っている人は
Cコードも書いて常にasmとBenchmarkで比較確認するしかない
>173
109はRust版が10倍くらい遅いんだけどunsafe使ったら早くなるの? >>174
わざわざ w = v; してそんな無意味なプログラムを書く人いないよ
>>92のような実際に使われているパターンの意味のあるプログラム例が欲しいな >>109
これって偶然とか意図に関係なく引数が手に負えなくなると
Rustが全く最適化をしない、というPOCじゃね?
>>92
はhello worldレベル過ぎて逆に意味なくない? >>174
Cのコードを書く必要はない
Rustには一部エリアのみプログラマーに安全性の保証の義務を負わせるunsafeブロックがありCと同じことができる
ベンチも#[bench]等ですぐ比較できるから速さにシビアな場合は本件に限らずアルゴリズムの差異も含めてコストをかけるだろう
その点はどんな言語でも同じ >>178
>Cのコードを書く必要はない
>ベンチも#[bench]等ですぐ比較できる
いやいやCコードなしにhello sliceどうしでいくら比較しても意味ない。>>174は信頼性の話でしょ >>174
最適化度合いに一貫性のある言語って何?
Cだろうがasm確認しないといけないのは同じだと思うが >>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は同じ速さで動作する >>180
現行C/C++だけがダントツトップレベル
Rustは裏でLLVM使ってるのに何で >>177 で信頼性がないと証明されたんだ...
>>181
あちゃちゃhello sliceと違う書き方をしないといけないなんて、これも無信頼性のPOCだ 「最適化度合い」ってあれだな
「クイックソートは最悪のケースの計算量が多過ぎる」みたいな
ヒープソート最強伝説に似ている >>183
ほんとだね。アルゴリズム系は数学的に最悪ケースを予期回避できるのに、Rustの一貫性の無さは最悪
>>181で突然「このように書く」って言われてもPOCの積み増し >>181
RustはわかりやすくシンプルにプログラミングできてCと同じ速度なのが素晴らしいね Rustをむやみに褒めてるやつがアホすぎてRustのネガティブキャンペーンにしか見えない件 こういう争いは同じレベルのやつ同士でしか起きない
お互いに相手がアホだと思ってるけど両方同レベルのアホ 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言語バージョンと同じ動作をし
同等のアセンブリコードが生成されることも確認できる せめてID変えずにやってくれればいいのにな
何回NGさせるんだか >>189
確認乙
POC(>>177,182)積み増し乙 Cだと速いけどRustだと遅くなるケースって存在しないの?
誰かそういう例を作ってほしい
ここまでRustがCと同じ速さで書ける例ばかりだから >>192
はい。Rustは一貫性がない(>>177,>>182)ので個別にCコードと比べて
書き方を変えることにより同程度にもって行ける
ケースが稀にあることが証明されました
多大な努力の結果です。感謝 Rustはfor文自体がイテレータを使うから、
for i in 0..s.len() {
println!("{}", s[i]);
}
とインデックスを使う書き方をするのは非常に稀で、
これはインデックスを使わず、
for n in s {
println!("{}", n);
}
と書くのがRustでは普通だから、
インデックス議論自体があまり意味のないものに思える。
そしてどちらの書き方をしてもCコードと同速度。 Rustがそんなに速いならなんで競プロはC++一択なの >>196
それは単なる人口差・マニュアルやサンプル数差
C++に次いで多いのが言語としてはかなり遅いPythonなのを見ても分かる通り まあ、型を正確に宣言しても速くならないし遅くなるというのがもし本当なら
バニラJSが復権するのもPythonが支持されるのも当然といえば当然 例えば競プロAtCoderでABC182-E問題 i行目j列目のマス(i,j)を扱う問題
提出された各プログラミング言語別の実行時間分布
https://pbs.twimg.com/media/EmYvG8aVkAMdfFG.jpg Rustはコーディングに時間がかかるから競プロでは使えない。
競プロにC++とPythonは良い選択。 >>196
そもそもC++もちゃんと書けるとは言えないでしょ
mainとグローバル変数しか使わないし 他言語を貶しても、Rustが使える言語にはならない。 >>200
Pythonを選んだ時点でPyPy3にしたとしても負け戦が確定かよ
Rustは競プロでも強いのか >>200 懐かしいなあ
ttps://ビット.ly/3CS8AuV
トップのuzzyさん始めC++勢がじわじわ最適化を進めているのがカッコイイ
ちらほらいるRust勢は一発屋だけでインクリメンタルな最適化が出来ていないね。
Rustは一貫性がない(>>177,>>182)から下手に弄れなかったのかな? >>204
その定型文のどこが「使える」と思ったのかがさっぱり分からないよ >>207 Rustって一発作ったらそれ以上で弄れないって開発現場では使えない言語だね(>>206) >>206
インクリメンタルに最適化したと本気で思い込んでる?
uzzyの上位4つとも全てソース同じまま変化していない
つまり何度も同じのを提出してトライしただけ で、その競プロでのc言語での参加率はどれくらい?> cオジ 4回ともC++コード同じだな
ただしその一つ前だけコードが違っていて二次元配列を一次元へと書き換えて改善してる
一方でRustの人は最初から一次元にしてるからその改善が必要なかった
つまり>>208はRustを叩きたいだけの完全に的外れ たぶん必要なのは
葡萄を食べるべきでない理由ではなく
食べない自由なんだな >>200
プログラミング言語間の速度差が激しくて勝負にならないな
競プロで勝つためにはRustかC++を選ばざるを得ないのか >>213
いいや
Pythonは論外だけど他の言語で十分戦える >>200
Rust最速レベルやん
てかC++の分布笑えるな
ギリ合格からトップクラスまでみっちり 貶めれば誹謗中傷かも知れんけど、ほめれば気持ち悪いだけ
こんなの消去法でほめるに決まってんだろ 参加者自体はRustも多い。
C++と同じくらい居る。
時間内に提出できる人が少ないだけ。 つまりRustは生産性が低いor利用者の能力が低いってこと? 普通にガチ勢は昔からC++を使ってて今さら他の言語にしないというだけだろうな CオジはCとC++比べてもやっぱCの方が早いからC++はダメとか言うのかな? ダメな香具師が描いたダメなC++コードは本当に糞
Cのがマシ >>201
Pythonはよほどうまくチューニングしないとすぐ時間制限越えるんで競プロだと使い物にならないんですわ
>>200のグラフから実行時間でのランキングができそうだけどぶっちゃけ時間内に結果が出れば速かろうが遅かろうが大差無いのでPython以外なら何使ってもいい
言語よりプログラマーの能力が大事だし、それよりむしろ暇の方が大事
とにかく参加し続けてなるべく正解を出してれば上位に行ける pythonでアルゴリズム性能出ると思ってるのお前だけだよ。。 お前がアルゴリズムという言葉を知らないと言うことがわかった 行列の和と積を英単語ではなく記号で書けるだけでC++と互角みたいになったのがPython
argv + 1000000 がnullを返したり計算中に例外を投げる実装が可能なだけでRustと互角になれる >>223
うーん、いろんな言語で競プロやってる青色だからついコメントしたくなってしまう
CPythonは知らんけど、pypyは実行速度速いからマラソンでもなければ困ることないよ
再帰がしんどいと言われる問題も、コドフォではよく使われてるbootstrapデコレータを使えば簡単に解決する
Rustはusizeの扱いのために余分なコードが必要になることが多かったし、クロージャ使おうとすると引数の型とかめんどいしで、最近は専らPythonを使ってる
Pythonはクロージャを短めに書けることも競プロ的には気が楽だな Rustは競プロに向いて居ないからな。
避けるのが賢明。 複オジと
複オジにマジレスしちゃう人と
その両方を焚き付けて喜んでる人の三人でお送りしています 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);
文末セミコロンで複数行に分けても、理解しやすいという話はどこに行った?使いやすさを求めては
イケないんだろうけど、どうもね.... >>231
わざと面倒臭くさせてることに意味がある
その辺りの思想は今までの言語とは違うかもしれん >>231
>Cが普通はintインデクスなのに
そんなルール無いよね?
仕事で他社さん作ライブラリがuint使ってたことある。 普通にprintln!使うと遅いんだけど教プロ上位なんだな 競プロではRustは間違いなく最速レベルだし、proconioみたいなマクロを使えば入出力もめちゃくちゃ扱いやすい
でもまあそれ以外のとこでかなり慣れがいる >>231
インデックスやその長さはusize型で絶対に正しい
まずインデックスは負の数になってはいけないからunsigned型
サイズとしてはポインタなどと同じそのCPUで使われるサイズでなければならないからusizeとなる
そして実際のほとんどの様々なプログラミングにおいてインデックスはusize型で上手く動く
ところが例外が二つある
例外の一つは自分たちで決められない外部指定APIなど規定においてインデックスや長さがusize型でない場合でas usizeにより解決
例外のもう一つは一部の数値アルゴリズムでプログラミングする上で一時的もしくは最初あるいは終端で負の数になると便利なことがある
もちろんその一時的な負の数である時ははインデックスとして使われないようにプログラマーの責任でプログラミングしてインデックスとして使う時はas usize 浮動小数点数から符号無し整数へキャストする命令なくね?
最近の処理系は直接キャスト出来るようなったん? >>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をできる限り少なくするのがプログラミングのコツ >>231
Cも配列のインデックス関連は(s)size_tが基本では
strlenやmemcpyの引数や返値はsize_tだし
単にintから暗黙的にキャストできるというだけで
暗黙の数値キャストがないのは確かにめんどくさい
asでのキャストはリリースビルドだと範囲外の値になったときにエラーにならないし、
絶対成功するキャストと失敗する可能性のあるキャストが見た目からぱっと区別がつかないのもよろしくない
かといってn.try_into().unwrap()を書くのもだるい
せめてn.into()で済ませたいが16bitアーキもサポート対象だからusizeに From<u32> が実装されていない
ターゲットを32bit以上のアーキテクチャに限定するした場合はinto()使えるようにするとか、もう少し楽にできないだろうか >>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は注視すべきポイントとなる >>243の基本を踏まえた上で
例えば16bit環境でなければu32からusizeへのtry_into()は常に成功し安全にunwrap()できる
生成コードも以下のようにコストゼロ
https://godbolt.org/z/cEc5fKGjh
キャストasと同様にunwrapも注視ポイントとなるため
利便性も含めてinlineのto_usize()を用意してしまうのがよいかもしれない
bit環境依存性はそのメソッドに押し込めることで注視ポイントが散らばるのを防げる >>239
それ絶対に正しいとは言えてないよね
下のほうに書いてるんだろうけど、よくある別の言語仕様だと、a[-1]が末尾を表したりできるし、数多くの言語でインデックスループだと
これもよくある相対位置やインデックス演算でa[i-1]とか書くけど、usizeをキャストしてi32にしてもう一度、スライスにアクセスするために
as usizeとか2回キャストを行う。これがどれほど醜くなるし、めんどくさくて労力を要するか
当然、メモリアドレッシングが0x00〜上に伸びていくことなんて言わなくてもわかるが、それが合理的であり、かつスライスがusizeで
支持できる理由かといえばどうだろう?少なくとも私はメンドクサイ
またもちろん、(a, b) = t がタプルのアンパッキングなどに使えるのも知ってるけど、それとまとめて変数の宣言と初期化を少ないタイプ量で
出来る話とは別だろう、上からアドバイス頂いてるようでケチをつけて申し訳ないけど、もちろん不変性はマルチスレッドでも有利だしコードの
リファクタリングなどもし易い、ファンクションの変更が良くわかる(そのくせ同じ変数名で別型再定義できたり)とか色々利点があるのは
当然分かってるけど、これもまたmutを多数宣言しなきゃならない時とは全く別の話だよ >>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
}
もちろん最適化によりアクセス時のインデックス境界チェックは無くなります >>241
Rustはletとmut指定を分離することでそのようにできるから大成功だな
mut指定が分離していない言語ではそのようにすることができずいつも困っている
方法がないからimmutableで十分な変数も含めてまとめてmutableな変数宣言にせざるをえない
初めて知ったときRustはよく考えられているなあと感動した >>246
・Rustは、数値リテラルに多くの言語ある固定の型がなく、文脈によりu32とかi32とか変わる(型推測)
・下のほうで境界チェックがないのも1..a.len()としているから
当然ながら、これは胸を張って一貫性があるとは言えないがa[-1]は言語仕様ではコンパイルエラーになるが
for i in 0..a.len()とすれば境界チェックが入り実行時にpanicする
君が勘違いしてるのはa[i+b]とかはbを宣言した場合、as castが必要で、色々ごっちゃになってるYO
アンダースタンド?w C++は型の特性を調べて、ユーザーがconst性を利用したバージョンの実装を生み出すことができる。
しかも利用時には、型の特性によってコンパイラにどのバージョンを使うか選択させる事が出来る。 RustもIndex<u32>とか実装はできるよ
標準のsliceに実装されてないというだけで >>254
くちから たれている みつは 2きろ はなれていても はなが まがるほど もうれつに くさい。 >>211
一昨日は言葉が過ぎました。開発現場、携わっている人には心無い発言でした。反省してます。
強調したかったのは、最適化って難しいよ、速そうな言語を選んでコンパイラにお任せって言う易しい世界じゃないよ、という事です。
むしろ叩きたいのは、定期的に現れる無意味なRust上げ
スレッドの流れをフォローしている人間にはネガティブキャンペーンと受け取られているコメントです。
うすうす気づいているとは思いますが、これSEO対策なんですよ。
Rustをほとんど知らない人が検索をした時に、
チラッとその一部だけを見せてエコーチェンバーにはめ込むと言う仕掛けです
同様に時々現れる、会話の流れを修正したい時に持ち出す極論、逆説的にRustを卑下する冗談
これはわざとRsutとタイポしてチラ見に現れないようにしている。
複製おじとは別人だと思うのですがどんなんですかね。皆さんの意見を訊きたいな >>246はまともにプログラミングしたことないとまでは言えないが多くの勘違いをしてるのは確かだな
usizeを上に伸びていくと書いてあるから引き算出来ないとでも勝手に思い込んでa[i-1]ができないと勘違いしたのかもしれない
もう一件
> よくある別の言語仕様だと、a[-1]が末尾を表したりできるし
その件はa[-1]やマイナスのインデックスに意味を持たせたプログラミング言語の仕様ミス
もしくはお子様向け言語であるとの結論が大昔に出ている
プログラミングのミスでマイナスのインデックスとなり本来はエラーでミス発覚となるべきところか不可能となった
つまり言語仕様ミスなのかそんなこと気にしないお子様向け言語なのかどちらかということになる
ほとんどの言語はまともなのでa[-i]はエラーとなり正しくa[len-i]と書く >>257
複製おじ?usizeの議論は微笑ましいですね。盲目的ですが熱意にあふれてます。
速度、最適化に関する盲目的思い込みがなければ無害ですな
SEO対策(>>256)に加担していなければの話ですが >>259
同意ですな
一方で熱意にあふれ盲目的で従順に車輪の開発をしてくれるプログラマが
無料で使えるのであれば使わない手は無いとLinus辺りは策略してそう
SEO対策(>>256)もあながち...? 欠陥言語C++を使うメリットは何?
今はこれだけ多数の安全な言語があって色々選べるのに アセンブラを使う理由はレジスタにアクセスできるから。
これはとても危険。
C/C++を使う理由はメモリーにアクセスできるから。
これはとても危険。 大いなる力には責任が伴う。
2019 - アフレシアさん >>261 もしこの二日間程度のスレッドの流れをフォローしてもなお一つのメリットも見えないのであれば
あなたの長所は熱意だけです。周りを頼って上手に立ち振る舞ってください。
>>260 有料案件で活躍されているプログラマーを見下すものではありません
>>263 同意 正に実力の世界。去れよ無責任Kids C++にもメリットはありゼロじゃない
ただし世界的には>>154の結論が出ている
そして今回もC++で書かれたChromiumの穴のせいで、それを使うElectronを始め多數に影響が出て、それを使うVScodeにもセキュリティ脆弱性と連鎖
C++を使い続ける限りセキュリティの穴が量産されてしまう >>266
あなたの結論素晴らしいですね。
どうぞLinusあるいはMozillaの元へ
SEO対策(>>256)の一環ですか?
>C++を使い続ける限りセキュリティの穴が量産されてしまう
ほんと怖いです。一刻も早くRustに書き換えて欲しいですね。もう10年経ったっけ?
ところでFirefoxのthird_party directoryを除いたsource repoでのRustの使用割合ってご存知?宿題ですよ 何でもrustでやらんで、安全性第一のとことか機能が優れてるとこ(非同期やジェネリクス、健全なマクロ、パターンマッチ等)とかからでもrustを便利に使ってったらええ。
今のrustは少しずつ実用面で採用を広げて行ってる段階だろ。Linuxでの採用とかさ。
既存のcでやってることをイキなり全部rustで置き換えようとしてる人なんて居ない。
rustにその潜在能力があったもしてもマンパワーが足りない。だから大手は少しずつ小さな分野で使いだしてる、複数の大手でね。
ただrustはもっとc言語との連携が簡単だったらと思う。 >>268
>何でもrustでやらんで、安全性第一のとこ
完全同意 話が合いそう
安全性アピールがマーケティング上有利な暗号通貨系の動きが早かったです
>Linuxでの採用とかさ。
早いとこ第一歩を踏み出して欲しいです。偉大な一歩となることでしょう。
>既存のc...イキなり全部rust...
10年なんてあっという間ですね
>複数の大手でね。
大手って何やっても凄いです
ScalaでのNetflix分岐点 未満/以上の話を思い出した
>ただrustはもっとc言語との連携が簡単だったらと思う。
完全同意 話が合いそう
>>266 が宿題(>>267)をサボったら手伝ってあげてください >>268
どの言語からどの言語の場合でも既存システムをそのまま言語置き換えはコストだけかかり効率がよろしくない
そのためシステム改修や新規システムを中心にRust採用となっているようだ
現在ある選択肢では人間が引き起こしうるミスをコンパイラに防止させてセキュリティ含む穴を無くしていく言語候補がRustの他にない 簡単に言えば、Pythonの代わりにRustを使うことはあっても、C/C++の代わりになることはない。
レジスタやメモリーを扱うのは大変危険だから。 >>271
Rustはinlineアセンブラ記述をサポートしていてレジスタ操作もできることを知らないのかね
Rust叩きの人はなぜ学習せずに無知なままなのだろうか 以前の言語
・プログラムのメモリ安全性、null安全性、データ競合安全性をプログラマーの責任で保証する
Rust
・それらの安全性を全てコンパイラが保証
・プログラマーの責任でCと同じメモリ操作やインラインasmなどを記述できるunsafeブロックもサポート
Swift, Kotlinなど
・null安全性をコンパイラが保証 >>268
Rustを使うにはガッツリ勉強しないと無理だから……THE BOOK一通り勉強しないと無理だから…… >>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でほぼ同じになるのはなんでなんでしょうか? >>276
やっぱりおまえアホだな
16行だから速いと思っている??
行数で速さは決まらないが
その例なら16行のコードが無展開で一番遅くなる >>276
Cでは引数にlenを取り、Rustではlen()を使っていて、両者は全く異なるのに、なぜ、ほぼ同じ生成コードになるのかが分からないって!?
もう少しRustを勉強してからアンチ活動しましょ
Cは先頭ポインタと長さの二つの引数を別々に渡しているのに対して、
Rustはスライス1つのみ引数を渡しているけど、「スライス=ポインタと長さのセット」だから同じ情報を渡しています
そしてlen()はその長さ部分を示すだけだからCコード側のlenと同じ
そしてスライスとしてセットとなっているlen()だからこそデタラメな不正な値が来ることはなく、
コンパイラの管轄下で信頼できる正しい長さ数値情報として扱うことができて、
その長さ未満となるループ内でインデックス境界チェックも安全に省略できるのよ
そのためLLVMによりCのプログラムと同等の生成コードが出来上がります >>276
rustにもgccバックエンドあるからそれで試してみてくれ >>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で数を回せば観測される確かな差が生まれます。 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の方は判りません。どなたか解説お願いします Java C#などのJIT勢は決まってピーク性能(大きなデータセット,warmup付きのbenchmark)を
アピールしますがピーク性能だけを見ていて十分かどうかは別途判断が必要です。
競プロ目標であれば
>>228の様にいろんな楽しみ方がありますよ
>>226で懐かしいと言ったのは途中で行列の転置をかますことで
劇的に速くなった記憶があるからです。O(数式)ビッグオー レベルで
まだsubmit出来るようなのでお試しください ヒント:複オジはワッチョイスレに一回も来たことがない 複オジも昔はコテハン使ってイキってたんだが
恥ずかしいレスを叩かれて匿名複オジに
今でもそのコテハンで書き込んだりもしてる
迷惑だよな Haskellの時もそうだったけど、世界でアカン空気が流れ始めると、日本で流行らせようと宣伝し始めるのは何でだろな? RoRの時みたいに、世界で流行るときは、日本ではアカン言うてアンチが増えるんだよね。 >>290
この件と関係あるかは知らんけどその勢力がいることだけは確か このスレで紹介されるRustの良いところって、「定数の索引で配列アクセスする場合は、最適化されて境界チェックが消える、安心安全」だけでしょ?
定数の索引で配列アクセスなんて、一生に一度書くか書かないかくらいなんだから、そんな機能在っても嬉しくないわ。 その点Javaは、実行時最適化でRustの5倍速い。
知らんけど。 >>289
Rustだめな理由知りたいからあかんとされてるブログ記事なりニュースなりフォーラムなり教えて https://chrisdone.com/posts/rust/
こんなのはどう?
TwitterやRedditは辛辣な意見が多いよね。
クリップしてないけど。 非同期関連がごちゃごちゃしてて面倒くさいってのはあるよな
ゼロランタイムコストが売りだから仕方がないんだろうが
その点Goはランタイムに強力な並行並列処理が組み込まれてるから、基本的な文法から標準ライブラリ、サードパーティライブラリで全て共通のgoroutine、channel、selectを使えて非常に扱いやすい
DockerやKubernetesとかクラウド関連で流行ってるのはこの並行並列処理が言語、ランタイムレベルでサポートされてるのが最大の要因だな
Nodeも非同期処理を言語レベルでサポートしてるからこれだけWeb系で流行ってる
その点Rustは弱い
ライブラリによってAはサポートしてるけどBはしてないとかあって色々面倒くさい 基本的にRustは知られていないんだよね。
日本以外では。
とっくにオワコンだから。 >>296
割とソフトな意見でオワコンとまでは言ってないような
そもそも言語におけるオワコンって何? Rustなんか構ってる暇あったら、PHPやれよって話。 >>301
他部署の人たちのPHPのバージョンアップ追従に毎回ドタバタしてるの見ると関わりたくないなぁと思う。
もちろんそれだけのお金と時間くれたらいいけど、PHPの単価ってそれほどでも無いよね? >>293
君は相変わらずデタラメばかり言ってるなあ
定数の索引で配列アクセスしているコードは出てきていない
その件で出ているRustの関数の引数は全てスライスであり配列ではない
つまり始点ポインタも長さも未知のものが引数としてやってくる
さらに定数の索引とはa[5]などの例を指しそんな例も出ていない
正しくは
未知の始点ポインタと未知の長さが引数として与えられてその中を変数の索引が動くコード例であり
RustとCは同等の生成コードとなることが確認された
>>294
Cと同等の速さのRustより何倍も速いプログラミング言語は存在しない >>300
最後まで読むと結局仕事では使ってるみたいだし
どちらかというと不満がある人でも使うくらいには広まってきている、というべきな気はする
オワコンっていうには他言語に移行したみたいな事例が必要なのでは >>289
そもそもHaskellとRustに何の関係があると思った?
異なる言語って普通ならどうしようもなく分断されていて全く無関係な筈じゃないのかね
分断を回避する秘訣でもあるのか >>296
読んだけど少し偏った思想の人なだけだった
「いずれRustでガベージコレクターが人気になると予想する」とか今後も極一部の用途以外では使われないだろう
「XXXをRustで書き換えたら速くなったというのはRustのせいじゃない」は安全かつ速くなった利点を理解していない
「良いメンテされたコードを書いてるメンテナーは非同期を採用することに抵抗がある」は用途に応じて使い分ける人が正常なので抵抗なんてない
Rustを批判する人はちょっとおかしな人が多いと感じる >>293
さすがにそのツッコミはRustゴリ押しの自作自演級に低レベルだぞ >>305
Haskellはガベージを撒き散らしながら計算を進めるからRustとはその点で真逆な存在かな
強いて言えばHaskellの型クラスとRustのtraitが基本思想の一部で似てる程度
そのRustとHaskellを叩いてる人はどうせ何も理解していないでしょう 例えばRustでhttpクライアント使いたかったからhyperやらreqwestやらsurfやらサードパーティのライブラリを使うことになると思う
別にこれでもいいが他人のコードを読む上で共通のコードが出てくるってのはかなりアドバンテージがある
それに対してGoが標準ライブラリで用意されてるから通常サードパーティのライブラリは使わない
コネクションプーリングも勝手にやってくれる上にhttp2対応も完璧
テストもhttptestパッケージで簡単に作れる
サーバー作る時も標準ライブラリを学んでおけばサードパーティライブラリの習得は容易
RDB扱う時もGoは標準ライブラリレベルでインターフェースを共通化したりコネクションプーリングをサポートしてる
ということで標準ライブラリが強力ってのは実用的なソフトを複数人で作っていく上で非常に重要 >>310
hyperとreqwest/surfはレイヤーが異なり比較する対象でないからそこで例として持ち出すのは適切ではないね
あと標準ライブラリの範囲や意味するところは言語によって異なるのだからあまり意味のない議論だと思う
その思想だとあらゆるものが標準ライブラリにあり他のライブラリを一切使わない言語が最上となってしまう
それぞれにメリットとデメリットがあります 実用品かどうかの定義が難しいけど
ほぼ原価で買える物は実用品と認定されやすい
原価より高い物は実用的ではない無駄な要素が入っている疑惑や誤解を招きやすい しかしRustへの注目度たかいなw
もう実質 Rust vs その他次世代言語って感じw Rustがオワコン言うからGitHubのPullReqに占める言語毎の割合のデータ見てみたけどTypeScriptとGoが圧倒的ということが分かった
Nimは残念ながらランク外、他はだいたい横ばいみたい
https://madnight.github.io/githut/#/pull_requests/2022/1/TypeScript,Swift,Go,Kotlin,Rust,Nim
GitHub全体のPullReq数も増加していると思われるので、個々の言語の利用者の増減を見るには不向きなデータかも
割合じゃなくて言語毎のPullReq数が分かるサイトがあったら教えて欲しい 利用される分野が違う言語を比較して、なんの参考にしたいんだろう
分野は気にならんの? >>313
Rust以外は言語機能で本質的な改善になってないからね >>314
jsのマイナスはtsに乗り換えてるんだろけど
Rubyの落下率がひどいな… GoとTypescript書ければ仕事には困らないな、うん
Rustは仕事の需要はないけど趣味やOSS活動でやる分にはいいかもしれない >>315
それを言うとそもそもこのスレのスレタイがどうなのよという話になる このスレは言語機能そのものについて語るスレだと思ってた
人気について話したいひともたくさんいるんだろうけど Nim言語マニュアルの日本語訳がスゴい
Nim ドキュメンテーションの総覧
https://nim-lang-081.osdn.jp/docs/index.html
Arigatou >>311
全てを最初から用意するのは不可能だけど、標準ライブラリで事足りるってのは利用側としてはメリットでかいぞ。
もちろんrustがあえてコア重視してるのはわかるが、お陰で非同期とか今時普通なものも乱立してる。 Rsutと云う泥船に乗せて一緒に沈没させようとしている奴らが居る。
どこの教団や!? >>324
はいはい、おじいちゃんもう寝る時間よ。 Redditの今年最悪の言語に早くもリーチかけてるからな。 >>318
俺は趣味ならnimにちょっと興味ありな感じ。まだ全く手は出せてないけど。 >>321
コンパイラの内部構造とかは勉強になるな。メモリ管理は種類多すぎな気もするが。 Rust使えない癖に持ち上げまくってるキチガイとRustとRubyの区別のつかないやつが論争する地獄のようなスレ CのライブラリとJavaのライブラリと.NETが使えてWebAssemblyも記述できる言語ができれば最強
と思ったけどそれってC#やF#じゃん >>200のグラフを見ると
C#やNimは遅くて
C++やRustより2-3倍も遅い理由はなぜ? >>335
誤差
10の13乗ものループでそれだけのミリ秒数しか違いが出ないということは実際にその違いが問題になることはほとんどない 要するにそのグラフの差は五十歩百歩でしかなくそれ以上の速度が必要ならスーパーコンピュータを視野に入れることになる スーパーコンピュータなら速く動くとかいうことは全くないけどな
なんならオーバークロックしたゲーミングPCとかのほうが速い
スパコンはPCではそもそも実行不可能なレベルの超大規模な問題を解くためのもので
普通のプログラムが魔法のように速く動くという代物ではない >>331
そもそも地獄レベルの問題を処理する競技が流行ってるので >>339
温すぎて笑う
ブルートフォースで解けるレベルじゃん
PaizaのAランクの話でもしてんの? >>338
競プロの問題は並列化で速く解けることも多いからスパコンの得意とするところだぞ Ruby は遅いから、1秒で100万回ループ。
これがJIT で、1千万回になる
でも、Rails などでは、10万個をJITしても、そんなに速くならない。
I/O 中心の処理では効果がない
外部にアクセスせずに、延々と行列演算を繰り返すような、
CPU セントリックな処理では効果があるのかも >>342
実際のスパコン触ってみれば分かるんだけど、競プロの問題って小さすぎて並列性がなさすぎるんよ
1秒以内で終わっちゃうようだとMPIのコストどころかGPUにオフロードするコストすら回収できるか怪しい >>345
ダイクストラ法とか結構出番あるだろ
なんで並列化しねーの? Amazonが>>9の記事で書いているように
C/C++/Rustで書けば2〜10倍は速くなり
それは電気代やCo2排出も同様になる
さらに省メモリになる点も考慮すると
サーバーやクラウド利用コストは確実に数倍差
言語の選択を変えるだけで支出も激減 ハードウェアアクセスの速度が変わらんのにベンチマークだけで胡散臭いこと言うなよ >>346
並列性がないというか、並列化しても元々の実行時間が短いからオーバーヘッドが大きすぎて割に合わないという話では
スパコンのジョブって短くても実行時間数十分だったりするから競プロとは前提が違う 元々の問題設計がN^2で失格 NやNlogNオーダーで通るようなってるとしたら
N^2で並列化出来てもTLEだわ 誰でも思いつくのはGCの並列化だが
GCは何言語で書かれているのかを誰も知らない コンパイル型の実行速度でスクリプトでも実行でき、コンパイルもできる言語が欲しい。反対を言えばbashのように
1行ずつ実行し、実行中で書き換えられることまでは必要ない。
単純なスカラーのループを書いたら、一台のCPUのレジスターだけをブン回す機械語のコードが生成されて欲しい。
A*Bと書くだけで千の計算を搭載されているメジャーなGPUで勝手に計算したり、あるいは千のマシンに分散して
実行して巨大な行列の積をポンと計算してもらいたい。
型だって必要ないなら指定したくない。もしポリモーフィックな関数が必要な時には、ジェネリックプログラミングを
使ってアルゴリズムを一度だけ書いて、あとは全ての型に使いたい。
ガーベージコレクション、あるいはメモリーマネージメントは循環参照や多重参照がなければRustのようにスコープを
抜けたら基本は消えるだけで十分でもあるが、循環参照をもったら自動でサイクリックGCも欲しい
並列化、あるいは非同期化に余計なコストを払いたくない、async/awaitなんてもってのほか論外、世紀の間違い。
ErlangやGoのようにspawnやGoで軽量プロセス起動は仕方ないにしても、これは必須ではなく、デコレーションで
あって並列ではなくとも動ける控えめなヒント情報であってほしい
ドライバ、あるいはOSやカーネルなどのハードウェアよりな開発にも利用できてほしいけど、例外あるいはpanicも欲しい Amazonの言うこと信じる人もいるんだ。
そりゃ霊感商法もなくならないわ。 >>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を書く >>355
immutableかmutableかの区別宣言は絶対に必要だから
あとは各言語でそれをどのように表現するかだけでしょ
それをvar val let const など各言語で色んな表現の使い分けがあり更に引数でどうするかだけ
>>241のケースも考慮するとRustのmut付加方式がベストな解決かな ん?
パラメータのいわゆる参照渡しの話なんだけどな ponylangだとbehaviorが終わるごとに該当アクターでGCを回すからプログラムとしては停止しないんだけども、これを並列GCですって言うのもなんだかなといった風情 >>355
>>357
何が ? なのかも少し詳しく MPIバリバリ使ってるけど競プロの問題を解くようなタスクでは使わないよ
課題設定があまりにも違い過ぎる >>357
Rustはその2種類の区別もmutの位置で区別できてるね
①引数が値渡しで来て関数内で値を書き換える場合
例: fn func1(mut x: i32) { …
→値渡しなので呼び出し元には影響なし
➁引数が参照渡しで来て関数内で参照元を書き換える場合
例: fn func2(x: &mut i32) { …
→可変参照渡しなので呼び出し元の対象は書き換わりうる あんた上手に振る舞えって言われてたやつだろ
Rustは出来るじゃねえよw 当たり前だ
お前が議論を理解出来てなかっただけだろ
そういうところが周りをイラつかせてるんだぜ >>361
> Rustはその2種類の区別もmutの位置で区別できてるね
二種類の区別?
> 例: fn func1(mut x: i32) { …
> 例: fn func2(x: &mut i32) { …
これリファレンスかどうかってmutの位置関係ある?
Rustよくわからんけど & つけたらリファレンスになるだけじゃないの?
何の話を俺にしたいの?
>>359
Nimの参照渡しの表現に見覚えあるわってレスしただけなんよ俺はw Rustだと両方ができて当たり前だが
プログラミング言語の中には
値を渡すか参照を渡すかをプログラマーが選べない言語も意外と多い
全てがどちらかに決められていたり
型によって各々どちらかに決められたり
メジャーな言語でも制限があったりする >>363
Rustは2種類の参照渡しがある
Tを参照元の型とすると
&T が(可変じゃない)参照
&mut T が可変参照
だから貴方が書いた>>355の話と同じじゃないかな >>362 >>364 本当だ自分の勘違いを棚に上げている パスカル書いてた人なら
「パスカルなついw 引数んとこにvarって書いてたなw」
で終わる話
皆の衆なんか混乱させてすまんかったな(´・ω・`) 複オジに相手にしてもイライラするだけやぞ
もう少しスルー力の鍛えようや 可変参照を渡すか可変じゃない参照を渡すかの区別がない言語もある
区別がある言語でもさらに2種類に分かれて
呼び出される関数でその参照が可変かどうか区別するだけの言語と
呼び出し側でも渡す参照が可変かどうか区別できる言語に分かれる
それら3種類のうち最後のタイプの言語が最も安全にプログラミングできる 野放しは危険やで NGワードでtag付けする?
>>NNN複オジ &Tを渡すか&mut Tを渡すかを渡す側で区別できない言語だと書き換えられちゃうのか分からない点で困るね
その場合でも呼び出す関数の引数宣言を見に行けばいいけど、そこにも可変かどうか宣言できない言語もあって絶望的なことも その点もRustが一番考えられてる仕様のような
色んな言語の中で一番ちゃんときちんと区別してくれていてプログラミングする上で安心感もあるなあ ponyなら書き込みどころか読み込みまで制限できるぜ
参照の持ち方だけで6つもあるのやばいだろと思ったが減らせる見込みもないぜ Nim好きなんだけど何で売れんかね
pythonからの乗り換えに最適なんだが よく考えたらこれも組織票野党が投票率下がった方が有利なように、スレ乗っ取りの下地作り?
>>369複?オジ? ponyとか真面目な話がしたいならワッチョイスレ行ったほうがいいよ
複おじをいじって遊びたいならここでいいけど 昔は変数もmutableとimmutableの区別をしないのが多数派だった時代もあったそうだから
新しく作られた言語のほうが色々と新たな進化ができて有利なのかもね >>378いいね ちょっと動かせるデモサイトで乗り換え例のようなものはあるの? >>376
マジ?
ponyで読み込みを制限して書き込みのみにするのはどの修飾子を使えばいいの? >>380いや このスレが乗っ取られないことが重要 tag付けhelp me pls >>381そうそう設計時点での思想って重要 増改築は面倒だから でも増改築できる柔軟性も必要
そろそろ落ちます tag付けhelp us pls Ponyで参照はsingle writer xor multiple readersが課されているためwriterがいる時は読み込みができない
つまりRustと同じ >>383
食いつかれると思ってなかったから少し語弊がある書き込みだったかもしれない
ponyは変数ごとにReference Capabilityという修飾子を持ってて、それで読み書きと変数をコピーしたときの権限を管理してる
読みを制限しながら書き込めるのはisoとtrn
>>386
Rustって変数の参照を作らせないって設定はできるんだっけ?
あと読み書きしないけど値の存在だけは確認したいときってどうすんの? ほとんどの言語はオブジェクトとかヒープで確保したものとか参照のみサポートが多いよね
参照を作らせなかったらどうやってアクセスするのだろう
移動しかないか >>388
へーRustにできないことがあるんだね
スタックかヒープなんて聞いてないよ Rustなら&selfメソッドを作らずにselfメソッドだけを用意すれば
その型は参照に対して全く働かずに移動に対してのみ使える型にすることはできるな
もちろんそのままだと移動で消費してしまい消えるのでそれを避けたい時Selfで再び自分を返すことになる
不便だが参照を全く使わずともその範囲で色々やれるようだ >>391
参照を使わないなら値そのものを移動するしかないだろ
他に何を期待してるんだ? >>380
ここは複おじを育てるスレだからな
育成ゲームみたいなもん ははぁーん
聞かれたことに答えない
息をはくように話をそらす
それた話を修正しない
そもそも何を聞かれたかわかっていない
これって?
もしかして国語で苦労した?
tag付けて欲しい? Ponyでもconsumeにより参照を使わず移動になるよ それた話を修正しない
Goスレで論破されて敗走してきたんだ
でここに居つくために育成ゲームだとホザキ始めた なんのことやら
参照を全く使わないのは無理だけど
単独参照となり読み書き自由に専有できるのならあるよー
Ponyならiso
Rustなら&mut そらした話は修正しない
そもそも何を聞かれたかわかっていないフリ
Flutterスレ盛り上げてこいよ 誰にも参照されてないのにGCされない現象を実現したいわけではなさそう
ということは「参照を作らせない」とはいえ参照は作れるんだよね そらした話は修正しない
すり替えた土俵ではRustと〜は同等
そもそも何を聞かれたかなんて知らない。無意味 気持ち悪い
参照とかGCの事は実はよく知らない。育成してくれ
Flutterスレ盛り上げてこいよ >>378
Pythonで十分だからじゃね
情報の多さが違う
Pythonは遅いのが欠点だけど遅いのが問題になることってそんなにないんだよねえ >>390
Rustの構造体は中身が非公開だからメソッド制限でいけるのか
失念してたわ
あとはtrnあたりの挙動を再現できるかだな
>>397
&mutだと新しい読み取り専用の参照が出てくるの防げなくない? どうしても速さが必要なところだけRustにするとしても
それ以外はPythonで十分な気がする >>403
実は速度の事、よく知らない
つい先日 自動ベクトル化とかSIMDとか育成された。育成を要求した俺すごい
Flutterスレ盛り上げてこいよ >>386 >>397
GoスレでSIMDをふりかざしたのに論破された。更なる育成を要求する
Flutterスレ盛り上げてこいよ >>402
弱くなる方向は何も問題無いでしょう
しかもRustは参照のライフタイムもコンパイラが管理把握できているため大丈夫でしょう
Ponyはその分をプログラマーが細かく指定して更にrecoverなど変化させていくことで補うわけです >>399
ponyだとどの変数も参照だから最初の参照は作れる
で、その参照から新しい参照を複製するときに複製さきの権限を制御する
Rustだと最初に作る変数は値のはずだから雑に変えてる >>406
Rustはコンパイラが管理で安全 Pnoyはプログラマーの責任
Rustスレでビット幅なんて間違えていない。コンパイラが保証した
Flutterスレ盛り上げてこいよ ponyは面倒すぎて萎える
こんな参照の管理くらいコンパイラが自動的にやるべきで人間に押し付けるのは悪手 >>409
参照とか永遠に分からなくてもコンパイラが保証してくれるRustすごい、俺すごい。成長した
Flutterスレ盛り上げてこいよ >>406
確かにborrow checkerも働くみたいだし機能上の問題はないようだね
とはいえ、元の発言は単独参照で読みを占有できると言ってるからね 参照とかスタックとかヒープ、移動、元の発言なんて実はよく知らない。
所有権の複製こそ最善手
永遠に分からなくてもコンパイラが保証してくれるRustすごい、俺すごい。成長した
だがいつでも育成を要求する扉は開いている
Flutterスレ盛り上げてこいよ >>412
すみません、所有権の複製ってなんですか...?
clone()とかでオブジェクトをコピーすると、複製後のオブジェクトに対して、別の新しい所有権がただ一つ代入先の変数に束縛されるという認識だったのですが... >>413
ゴネれば相手が勝手に折れる
ゴネ権の複製こそ最善手
いつでも妥協を要求するカードを複製している
Flutterスレ盛り上げてこいよ >>387
>読み書きしないけど値の存在だけは確認したいときってどうすんの?
Null安全な言語では値が存在しないことを表すNullなどを普通の型には代入できないことでNull安全性を実現している
そのためNullを代入できるNullableな型が用意されておりNullかどうかは値自体の読み書きとは別に可能な言語が多い
RustならばOption<T>がNullableな型でNullはNoneと表記する
Option<T>のメソッドis_some()かis_none()によって値自体の読み書きをせずに値の存在だけを確認できる >>415
ボールは投げ返した
メモリレイアウトがどう変わるか、何も知らなくてもコンパイルが通る範囲でRustが保証する
どうだ怖いか
Flutterスレ盛り上げてこいよ Rustは低レベルの対応も必要だから、mutable必要なんだろうけれど、理想はImmutableだけじゃないの? >>417
イミュータブルを使わないと再帰が増えてハードル上がるから 同じforループでも
for (i = 0; i < 10; i++)
これは見るからにmutableだけど
for i in 0..10
これは毎回別のimmutableがやってくる感じ いいかげん 俺ウザいだろ
tagが自然発生したぞ
どうだ怖いか
Flutterスレ盛り上げてこいよ イミュータブルはzero overhead abstractionとは対極だからな
特にRustの場合は関数型みたいにオブジェクトの一部を書き換える度に新しいオブジェクト作るとかやってたら細切れに解放が必要になってコンパイルも実行もクソ効率悪そう >>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; なんてほとんど使わないのではないか、なにより見た目が気持ち悪い。
これが最高だという人もいるけど、個人的にはなんかしっくりこないな
ほかの言語の多値戻り値のように()カッコさえなければ良いのに・・・・ >>393
それめちゃくちゃしっくりくる
誰もあんな嫌なやつ育てたくないわな >>401
俺仕事でNLPやってるけどトークナイザの実装がクソ遅いんだよ
英語だとRustで実装されたfastバージョンがあるんだけど
日本語対応のやつはゼロ
作らしてくれーと言ってるけど許可降りない >>424
日本語の字句解析なんてやったことあんの?
片手間でできるようなもんじゃないぞ
Cで書かれたありもの使えよ >>425
やったことあるから言ってるんだが?
それに今時の自然言語処理って転移学習は必須
そのためにはトークナイザとモデルを合わせなきゃいけなくてこれがめちゃくちゃ使いにくい >>426
やったことあるならその時のが残ってるだろ
それをプレゼンしてだめなら自分の思ってるほどの性能は出てないてことじゃね >>421
オブジェクト作るって、ヒープのアロケーションを想定してる? 今夜のAAPLの発表まで暇つぶし
早いもので2年か、改めて見る
Scalaが日本で衰退し始めている理由を説明します
https://www.yout
ube.com/watch?v=kFzLia7YZQU C++は3年ごとに改定されるので、歴史ある言語でありながら、次世代言語でもあるんだよね。
素晴らしいことだと思います。 SDGs的に完成は最悪手
発注側も分かってる
Scalaは完成しちゃったの? Haskellも完成
Goはver2いつ出すんだレベル >>422
プログラミングをしたことがないからそんな発想になる
関数からタプルなどが返ってきて別々に使うなど日常茶飯事
例
let (tx, mut rx) = mpsc::channel(10);
個別にmut指定する仕様は尊い >>439
Goスレでpromise/channelの育成を要求して成長した >>440
Goにpromiseができたの?
Goスレ見に行くほど追ってないので知らんけど >>442
Rustは公開されている山のようにあるTODOリストが常に少しずつ進行中
大きなことから小さなことまで機能追加でどんどん便利になっている 機能追加はcrate/macroで起こってる だがcoreは封鎖した
Go動向を追う最善手はGoスレ見に行くことである
知らんけど そろそろ風呂に入ってくる
だが隙あらばスタックとヒープ mpscとスレッド安全の育成を要求する扉はまだ開いている 乗り遅れるな >>444
外部crateの話は一切していなくて
Rust言語が日々進化しているとは
Rustコンパイラによる機能追加と改善
および標準ライブラリの機能追加を指す
もちろんcoreライブラリ部分にも追加やstable化などがある >>428
その人じゃないけどRustでは特に指定しなければオブジェクトなどもスタック上に作られるよ
例えばCのコードと同じ動作をRustで書かれた>>181のイテレータメソッドチェーンのコード
各イテレータ毎にそのオブジェクトがスタック上に作られるね
結果としてC言語でforを回したり関数ローカルのmax変数を使うのと同じ
そのため全く見た目が異なるRustコードとCで同等の生成コードが出来上がってるわけ >>447
>各イテレータ毎にそのオブジェクトがスタック上に作られる
スタックもヒープもasmもhardware levelは何も知らない。育成ry ヒープ利用は確保と解放操作が必要だから必ず遅い
スタック利用はスタックポインタの増減を関数の最初と最後でまとめてするだけで速い
さらに最適化でレジスタ利用になりうるから超速い >>447
職場でその言葉を知ったかしたら相手が勝手に納得しました。魔法のコトバ
育成無用 ヒント無用 >>449
隙をみて恥をかき捨てた事でたった今 1mm成長した。俺すごい >>449
重箱の隅だけど malloc/freeは最適化で消えることがあるから "必ず遅い" は言い過ぎ
ヒープ利用でもレジスタが使われることもある
https://godbolt.org/z/crxTse4vG >>452
重大なヒントleakかと思ったけど最低限で良かった
明日 職場で知ったかしてもらう予定 >>453
ボッチ自宅開発者だからオジが知ったかできる場所は5chだけ
リアルでやってたらここまで酷いことにはならない >>454またはPython職場でRust勉強会をしてて自分が一番詳しいと思われたい&
Rust使わせてくれない上司を見返したくて頑張ってるんだよ。
ウルウルくるぅ >>452
ご指摘ありがとう
誤解させる書き方してしまいごめん >>452
その例は現実的ではないよね
実際の使われ方だと新規オブジェクト生成は通常は別関数だから
それをinline指定でもしない限りは別関数にあるmallocは消えないです
ヒープ確保は常に行われてしまいます
一方でRustでは新規オブジェクト生成が同様に別関数でinlineでなくても
オブジェクトを「値返し」するので大丈夫です
オブジェクト生成する別関数でも呼び出す側でもヒープの利用はありません ヒープを使ってしまったら、>>452のような重箱の隅をつつくレアケースを除くと、最適化で消えないので不利
Rustのようにオブジェクトの生成すらスタック上で行なう方が有利
Rustはオブジェクトを値返しする点がそれを可能としている
オブジェクトをレジスタ群に格納して返せるときは最も速くなり、
その大きさを超えても、呼び出し元のスタック領域に確保された場所へ直接書き込んで渡すためこれも速い >>458
重箱の隅だけどinline指定しなくても関数のインライン化は行われるよ
同一翻訳単位の場合はもちろん、リンク時最適化でインライン化されることもある 必ず○○とか必要以上に強い言葉を使うから重箱の隅をつつきたくなってしまうわけで、
ほとんどの場合○○とか適切な言葉遣いをしてくれれば良いのに >>461
inline化だけの話ならそうだね
でも今回はmalloc部分が消えるかどうかで単純なパターンだとinline化されて消えるときもある話じゃないかな
オブジェクト生成関数のmallocが常に消えたら大問題なのでそれは特殊なケースでしか起きないと思うよ >>464
RustではVec(オブジェクト)生成new()でヒープは使わないよ
サイズ1以上になって遅延して初めてヒープ確保
SmallVecを使えば指定サイズ以上になって遅延して初めてヒープ確保
それまではスタック上のみを使う
ArrayVecはヒープを一切使わない
スタック上の指定サイズの中でのみで使う
だから「上限サイズがなく、かつ、想定サイズを超えた」時でなければヒープを使わずに済むようになっているよ TS以外だと実際どれやればいいん?
理由添えて教えてほしい >>467
TypeScriptやっている人ならRustかな
まずウェブブラウザのフロントエンドで少し処理することが出てくるとWebAssemblyを使うがそこでの使用言語シェア1位はRust
次にブラウザではなくデスクトップ上などで作るときもJS/TSとRustを使った安全に高速なフレームワークTauriがある
もちろんサーバーサイドでもRustを使って安全に高速な構築ができてサーバーやクラウドコストも他言語より有利になる >>468
めっちゃ丁寧な解説ありがとう
汎用系のCOBOL3年から未経験でWEB系に最近転職したんだ
自主学習でReactやったんでとりあえずフロントエンドで採用されたけど
今後サーバーサイドやその他の技術を習得
しようとしたとき何をやろうか?と悩んでたんだ
参考にしてみます。本当にありがとう。 >>449
c++のvectorすら予約するからなぁ。
449はどれだけ時代遅れなんだろう。 こんなに優秀なRustなのになんでFirefoxは遅いし、著名なあまりソフトウェアが出てこないの? >>449 >>456は行儀よく振る舞う練習
>>473は自演否定を一旦諦め 蒸し返しの誘い球
温存している自宅回線IDで後ほど再び自演否定
こんな流れで戦ってる >>466
Rustはスタック上だけでVec操作できるよう充実してるね >>474
安全とハイリスクハイリターンの対立と分断があるから
優秀の反対は別の優秀だから 俺仕事でPython NLPやってるチームに配属された どうだ怖いか
周りのDr持ちが段違過ぎてRustで戦いを挑むカードを推進してる
Rustで作らしてくれーと言ってるけど許可降りない
無意味な上司のせいでRustはパーソナルプロジェクトだ
そのプロジェクトとは CLI Tools だ
JetBrainsのDeveloper Ecosystem Surveyでは
2021に待望のCLI Toolsカテゴリーが新設された。
突然Systems Programmingが激減したのは誤差だ 2020に新設された仕事での利用率は、2020→2021の伸びは0だが、
キャンペーンが実を結ぶのは今年2022だ
何しろ2022はtauriがv1に到達し Desktop/GUI Applications がエンタープライズで飛躍的に伸びる
WebAssemblyの使用言語シェア1位とかいう話もある
メモ帳レベル機能でもawesome扱いしてくれるのは今だけだ 車輪に乗り遅れるな どうしてID変えるんですか?やめてください迷惑です >>480
いずれ多くの分野でRustを使って当たり前の時代が来るだろうけど
まだしばらくは限定される気がするね >>480
今は、Rustで実装ってバリューあるけれど、もう何年もしたら、当たり前になって誰も気にしなくなるんだろうね。 スクリプト言語で十分な分野はそのままじゃないかな
それ以外の分野はRustを使うことが当たり前に 言語仕様が優秀でも実装で失敗すれば終わり
標準ライブラリがーっていうのもどちらかといえば実装側の問題 ライブラリを選ぶコストや年単位で変更をウォッチしてアップデートの要否を判断して適用するコストって馬鹿にならんのよね
最近の言語なら言語そのものの生産性の差より言語の違いによるライブラリ周りの生産性の差の方が大きい そう考えるとBoostのあるC++は素晴らしいよね。 https://www.jpcert.or.jp/sc-rules/00.introduction.html
CERT セキュアコーディングスタンダードは、C、C++、Javaを対象としたセキュアなコーディング標準を公開した。
RustとBashは安全なのでCERT/CCの対象外とした。 >>491
マイナー言語はふつうにスルーされてるだけ >>491
歴史を考えろよ
これはgoやrust登場前に作られた規約だぞ >>491
そんな古いのどこから見つけてきたんだ? C固有の話やメモリ安全性に関わるものはともかく、
シグナル安全性とかモダンな言語でも気にしないといけない部分はそれなりにあると思うので、
モダンな言語向けにまとめ直したものがあると嬉しいとは思う pythonみたくマルチスレッド禁止にすりゃええねん goとnimに興味あります
rustはある程度触ってみたけどもういいや 小鳥んはいつまで次世代なんだよ
まだJavaから覇権を奪えないのか Nimは本質的なメリットが何もないから
今後も企業が採用することがないと思うよ Rustは本質的なメリットが何もないから
今後も企業が採用することがないと思うよ >>502
Pythonはマルチスレッド禁止ではなく
グローバルインタプリタロックをしてるから真の並列処理ができないだけ
I/Oブロッキングされてる間に他が動けるなど完全に無意味というわけではない
これはRubyも同じで所詮はスクリプト言語だからしょうがない Rustは企業による採用が多い
例えば>>9の記事、>>43の記事、154の記事など
各企業がRustのメリットを様々な観点から語っている >>508のような重箱の隅をつつくレアケースを除くと、Rustの現実>>496 理解のある有能な上司・経営者がいる企業はRustを適切に導入しつつあり
ダメな企業はそれらの記事にもある多大なメリットを理解できないまま差が広がるのだろう >>510
統計とか言ってる時点でズレてるからな
俺はもう1番安全な言語しか使いたくないよ >>509
トヨタやNTTも採用しているし
それらGAFAMによる採用も含めて
レアケースというよりも適切な判断ができる企業がRustを採用していってる感じ 企業体力がある企業が採用していってる感じ!
って感じ? 昔から同じ傾向だけど
余裕のない会社(人)や無学習な会社(人)はそのまま古い言語、遅い言語、安全でない言語を使い続けるね
これは言語に限らずあらゆる対象について同じ 本日の もはやRustはどうでも良くて
Rustで誘い球 ヒント乞い儀式の会場はこちらですか?
異次元超大手GAFAM御用達 老舗第三者機関jetbrainsによる
大規模統計調査結果 #Rustの不都合な真実 #責任転嫁論法
尾ひれはひれ抜きで
一言でまとめ
>Rustで作らしてくれーと言ってるけど許可降りない
詳しくは JetBrains ソースで👆 調査結果を誤読している人がいるようだけど
昔から良いプログラミング言語が出てきたらまずは趣味や個人的な用途から使われ始めるのでこの第一条件をクリアしていることを意味している
仕事で強いられるのとは異なり自ら選べるところで進んで使われることはプログラマーにとっても良い言語であることを意味する
一方で多くの会社や客先などで使われる言語は良い悪いと関係なく惰性的にもしくは周りに流されて決まることも多い
よってその大衆的な調査よりも第二条件としては趣味範囲に留まらず実用的なプログラミング言語かどうかが重要となる
その点では>>9や>>154の記事などで世界的な大手IT企業たちがRustの実用性を証明してくれている RustスレやGoスレ、Pythonスレはレベルが低くて使えない
やっぱC/C++を煽らないと重箱の隅をつつく レアヒント情報は出てこない
4回線で戦ってるから、両側のサクラを演じてるが、本物がなかなか釣れない Rustが実用的に使えるようになったからC/C++は既存メンテを除いて不要じゃないか?
しばらくの時間が経った以後は重箱の隅をつつくレアケースでしかC/C++は使われなくなると思う >>521
その条件だけじゃ不十分だよ
それに、Rustに慣れた技術者が不足なく増えること、の条件が加わればもうC/C++は使われなくなる そもそも今その言語が使われてるのって8割方保守だろ あるいは毎年、既存システム比、2割も新規があると考えるのは現実的ではない。 RustがC/C++分野に食い込めても2割いくことはないということか あるいは新規があればRustであると考えるのは現実的ではない。すべて架空の話。英語で言えば仮定法過去 C++は酷い言語だったが科学的な誤りはなかった
商業的に不要とか言われてもそれは倫理的に悪と言われる程度の説得力しかない あるいはRustでは保証するとか証明可能とか言う話は全て架空だ
数学的証明された事実は一つもない まあ数学自体が架空だと思ってる奴もいるんだよな
複素数には不等号も最大も最小もないという事実は架空で
最大と最小しかない1bitも架空で
実数が現実だと思ってるようだ >Rustは数学自体が架空だと思ってる™
>Rustスレはレベルが低くて使えない
完全一致 >Rustは数学自体が架空だと思ってる™ ←New
>Rustスレはレベルが低くて使えない
>Rustで作らしてくれーと言ってるけど許可降りない™
完全一致 Scalaが実用的に使えるようになったからJavaは既存メンテを除いて不要じゃないか? GAFAMが揃って採用したら実用的&安泰
1社のみだと細々と消える可能性あり 日本の場合、Rust実務3級みたいな怪しい資格が出てきたら、人の確保に困らないレベルだと考えられるのでは。 >>535
アリババのレポジトリ見たらRustで書いてるプロジェクトが既にあるのな
あとアリババクラウド公式ブログでもRust推奨
Why Should You Learn Rust?
https://www.alibabacloud.com/blog/why-should-you-learn-rust_598680 アリババのメイン言語になってるならワンチャンあるかもしれないなあ。
でも、日本で使われてるならダメそうじゃないか?
日本人が良いというものは、だいたいダメだったぞ。
この30年間。 ある意味、日本を釣るためにGAFAが手を組んだのかもしれないしな。 >>542
GAFAだけならともかく
HuaweiもAlibabaもRust使ってる >>543
中国とアメリカが手を組んだってことかな?
ますます嵌められる予感しかしない。 GAFAというが
アップルはRustに言及してないだろ
社内でどうしてるかは知らんが そういや GAFA の F は Facebook の F だったので Meta に変わった今は GAMA になる筈だよね。 >>546
Appleは2~3年前からクラウドサービスのバックエンドで使ってるって話だよ
公式発表とかしてるかは知らんけど中の人がしゃべってたし採用サイト見ればわかる ID:e58aNhcIは陰謀論とかにころっと騙されそう
日航機墜落はアメリカの陰謀だとか信じてそう >>541
CもJavaもPHPも日本じゃ昔から至るところで使われていたし、過去資産を一気に捨てるのでなけれこれからも世界中で使われるだろうけど? 逆に、自民党は某宗教団体と無関係とか思ってる人のほうがオカシイのでは?
宗教と組んでるから安泰と党大会でも言ってるのに。 陰謀論はたまに真実が混ざってるから厄介
9.11はサウジが糸を引いてたみたいなやつとかね >>547
GoogleはAlphabetになってるからAAMAかAAMAM
わざと没個性的にした企業名に追随する必要は全くないと思うが >>552
それ、最近話題の某宗教団体が主張してるけど。
陰謀論じゃなく真実。
陰謀論と言えばごまかせるという風潮がオカシイのでは? ☆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 ☆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
} https://go.dev/doc/faq#closures_and_goroutines
> Even easier is just to create a new variable,
> using a declaration style that may seem odd but works fine in Go: ☆js let
var a = []
for (let i = 0; i < 3; i++) {
a.push(() => console.log(i))
}
a.forEach(f => f()) // 0 1 2 登場人物等が実在しないと意味がないのが陰謀論
実在してもしなくても仮定するだけでいい感じになるのは防災とか護身術とかかな ☆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
} ☆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 >>560
ライフタイムを管理してるRustだけが
問題を回避してコンパイルエラーにすることができているね それで最強?言語Rustで崇高なパーフェクト言語?Rustでいま何作ってるんですか?
ぜんぜんRust製の良いソフトウエアが出てこないですね
まさかウンコ臭い業務コードや、趣味のじこまんオナニーコード書いてるんですか?あ、ごめん業務ですら案件ほとんどないか!w ごめんrustって駄目なの?
goとかのがいいんか? >>564
オモチャと馬鹿にするのは筋が良くないよ。
適用領域や生産性が十分であればオモチャがエンタープライズ(笑)を置き換える例は枚挙にいとまがない。
下げたいなら欠点や解決できていない課題を指摘するのがよいよ。 >>565
いい言語だよ
ただちょーっとキチガイが贔屓の引き倒ししてるだけ >>565
他人に書かせたコードを管理する立場なら現状ベター。
自分でコーティングするなら微妙。
ガチガチに固めたコーティング規約のついてくるc++くらいに考えればいいかと。 >>565
Rustはプログラミングがめっちゃ快適なのでプログラマーたちに愛されている
「Stack Overflow」で7万人以上のITエンジニアの調査結果、最も愛されている言語は7年連続で「Rust」
https://survey.stackoverflow.co/2022/#most-loved-dreaded-and-wanted-language-love-dread >>568
つまりGoはOSS、エンタープライズ
Rustは言語オタク
に向いてるってこと? 料理下手な奴って
調味料とかの用法用量をガチガチに守らない方が美味しくなる
って思い込みが強いんだよな カレーの箱には材料全て炒めて煮込めって書いてあるけど実際には炒めるのは玉ねぎだけでいいし煮込むのはジャガイモだけでいいんだよね
あとはレンジで下処理できる
全部同じ処理方法だと玉ねぎは香りが飛ぶしジャガイモのデンプンが十分スープに出なかったりする
火を止めてから仕上げにインスタントコーヒーを少し加えると味音痴でもはっきりわかるくらいコクが変わるがそれは書いてない
なぜなら商業的にはコーヒーはルーに最初から入っているべきもので必要なスパイスや味付け等を一つのパッケージで提供することがルーの役割だから
ところがコーヒーは最後に入れるもので最初から入れるとただ苦味を加えただけになる
従ってレシピには載ってない
俺って料理音痴だなあ 自分で作る時の規約と同じ規約を他人にすすめるのは正しい >>570
OSSこそ他人のpull req受け入れたりするから規約は堅い方が良いのでは
書いてもらったコードを書き直すようお願いしたり、自分で書き直したりするのは二度手間だよね JetBrainsの方はテックメディアやblog等がこぞって取り上げてる印象がないけど日本だけ?
あと2~3週間で今年の結果が出る頃だけど、RustとGoをヘッドラインに入れ込んでViewが稼げそう
どっちがどう転んでもw どっち転んでるって分かってるくせに...
Goスレから出張ですか? このスレは>>518となりました >>577
この話をしたいのか?
>GAFAMが揃って採用したら実用的&安泰
>1社のみだと細々と消える可能性あり
飽きたわ
Scalaは細々でも生き残る実稼働分野を見出した >>565
Rustは史上最強のプログラミング言語だ
コンピュータサイエンスとプログラミング言語理論の成果を全て取り入れた唯一の言語だろう
安全性とパフォーマンスを両立させた唯一の言語
まずRustを使うべき
しかしスクリプト言語使いの人などはハードルが高いのでGoやNimなんかを経由するのはあり
最終的にRustへ至る道への修行と考えれば全然あり キチガイがRustのアホな持ち上げ方するネガティブキャンペーンやめてくんないかな
いい加減流行ってくんないと不便なんだよいつまでも Go 実稼働分野でバリバリ活躍中
Scala 実稼働分野でバリバリ活躍中
Rust 試食コーナーで食べてもらって狂喜乱舞 バリバリ使ってるレベルの高い人が周りにいないから知らないんだね
かわいそう >>582
Rustは足りない物だらけでバリバリ使えるレベルにないんですわ
ユーザー増える邪魔すんなよ 今すでにC/C++を使ってるようなプロジェクトでなければ、基本的にはRustなんて出番ないよ
Java、JavaScript、Python、Swift、Kotlinみたい言語が使われてる分野でRustが使われることはない。あっても非常にマレ
wasmでRustの需要があると騒ぐひともいるけどまだ新しすぎてなんともいえない 「自分のレベルが低い」ことを認識できないとレベルアップなんてできないぞ
Rust書ける?って言って勉強すれば書けます!とか言ってるやつが数ヶ月後も書けなくて
どういう反応するのか見たら「学習コストが高い」とかいうよくわからない言い訳をしたことがあった
Rustチームに入ってもらおうと思ったけどやめた 俺の経験上C/C++を書けないとRustは書けないと思う
だから急がば回れでC++の勉強をするのも良いと思う
Rustが持ってる機能の元ネタがそこらにあるから
やる価値はあると思う
なぜ継承がクソなのかコピーが悪なのか全て理解できると思う
この感覚を理解してないとRustの機能のありがたさはわからない 結論を言うとRustから逃げてるエンジニアは二流 ここで逃げるとあらゆることから逃げるだろう 完成した
Go 実稼働分野でバリバリ活躍中
Scala 実稼働分野でバリバリ活躍中
Rust 試食コーナーで食べてもらって狂喜乱舞
俺 >Rustで作らしてくれーと言ってるけど許可降りない
有能社員 >Rustは学習コストが高い割に使えない
有能社員 >C/C++を書けないとRustは書けない、Rustは意味なし
Nim 試食コーナーでスルーされて意気消沈
Pony 開店前 >>585
それが現実。
Rustを「とりあえず」使えるレベルになるだけでも深くプログラムに精通している必要があり、JavaとかPython開発で使えるレベルの人材では全く歯が立たない。
Rustコミニティは初心者にマウントする人間ばかりで教育手法は全然整備されていない。
こんなのでユーザーが増えるわけが無い。順当にHaskellと同じ道を歩んでいるわな。 当然だけど万能な言語なんてないから、ユースケースに選んで使えばいいだけ
プログラミング言語なんて5個や10個使えて当然 >>585 >>589
うむうむ。KentaのScalar動画で見た。
viewが30くらい伸びた しみじみくる >>585
だからお前はレベルアップできないんだな
Rust使えるようになってからそういうことは言え とはいえRustが普及しないのは俺も困る
レベルが低いものが結託してRust を潰そうとする動きは感じてる
なので何とか使えるように指導したいとは思ってる >>584
それはちよっと無知すぎるんじゃないかね
そのJavaなどの言語が現実にRustへの移行対象となって進んでいる
単純にRustならば自動メモリ解放で高速化できるだけでなく
>>43の記事に具体的にあるように非同期な並行&並列プログラミングなどでの優位性も大きい
どんなに複雑化してもデータ競合がないことをRustコンパイラが保証する点は現在最も求められていることの最重要の一つ 入れ食い状態
Go 実稼働分野でバリバリ活躍中
Scala 実稼働分野でバリバリ活躍中
KENTA >日本では衰退しました ←New
Rust 試食コーナーで食べてもらって狂喜乱舞
俺 >Rustで作らしてくれーと言ってるけど許可降りない
レベルアップできない俺 >今はRustだけで良い。レベルアップはお断りだ ←New
レベルアップできない俺 >試食コーナーで食べてもらって狂喜乱舞 ←New
レベルアップできない俺 >数学出来ないけど有能社員を指導したいとは思ってる ←New
有能社員 >Rustは学習コストが高い割に使えない
有能社員 >C/C++を書けないとRustは書けない、Rustは意味なし
有能社員 >Rustは言語オタク Haskellと同じ道 ←New
Nim 試食コーナーでスルーされて意気消沈
Pony 開店前
Haskell 衰退しました ←New >>595
それも知ってるから、非常にマレと書いた 「できない人の気持ち」をずっと考えてたんだけど
スタックとかヒープとか所有権とかライフサイクルとか
そういう説明の仕方が悪いんじゃないかと
概念的な説明って意外と理解されないんだなと言うのが実感としてある
もう割り切って「この場合はこう書け」という説明の方が良いのではないかと思い始めた 入れ食い状態
ちょっと手加減してください
Rust
レベルアップできない俺 >スタックとかヒープとか、概念的 ←New 言語だけで低レベルな連中を排除できるから便利よ
前の会社でOCaml,Haskell,Scalaできる奴限定チーム作ったら
お守りの要る奴が居なくなって超快適だったw
まあ社内のできる奴が皆来たから他チームからの技術問い合わせ集中→丸投げが始まったからウンザリして転職したけどw
Rustも活かして行こw >>598
あー
それわかる
C++とかも最初は割り切りパターンが大事だからね
例えばコンテナの要素にはunique_ptrを必ず使えとかかなり有用なパターンだと思うし >>601
このような意見は有り難い
ちょっとその方針で社内ドキュメント書き直してみる
もしかしたらRust使い育成の成功体験が得られるかもしれん 問題:ヒント乞い儀式は何処から始まって、何処まで続く?
今、何人目? こうしてRustはささやかに終わり、時代は変わっていくんですなぁ Rustでやってる案件いくつか見たことあるけどどれも最初の開発者がめちゃくちゃ優秀だから、
変なことになってないし後から参加する人も自然とベストプラクティスを学びやすい感じになってる
まあどれもドメインを絞ってて規模が小さいから社内ドキュメントなんてあんまないけど…
>>602
社内ドキュメントで入門記事とか書こうとしてるの…?? C/C++/低レイヤーの間違い指摘・揚げ足取りは思う壺です。
プロレスに終始してください。 static変数でいいと思った人の気持ちをOO棒でぶん殴ってた時代に戻ってやり直せばいいのでは 感想
Rustが高速で省メモリで安全という新分野を切り開いたのは確かなようで
クラウドコスト・使用電力量・Co2排出量でも有利なのは間違いなさそうだから
今後のシナリオは以下の2パターンかな~?
パターン1
慣れれば大半のプログラマーがRustを使いこなせるようになりRustはコモディティ化して人類の役に立つ
パターン2
Rustを使いこなせる層と使えない層に二極化する
企業などもRustを使いこなせる人材を集められる層と無理な層に二極化する
そのためサーバー&クラウドコスト支出・使用電力量・Co2排出量などあらゆる点で二極化してしまう
Rustを使えない側は様々な点で不利を背負ってしまう >>KENTA
Rustについてもいろんな過去動画で語ってるんだけど今一古い
古い動画では低レイヤー向けだから関係ないみたく言ってるけど最新版2022年下半期の意見が欲しい
KENTA周りでwasmってまだ見えてないんじゃないの?
過去の試食ニュースくらい?とか(tauriはKENTAに関係ないか)
だれか本人に伝えてきて下さいm(__)m Rust使うとIDを簡単に変えることができる裏技みたいなのがあるの? あえてKENTA周り煽るような否定形で聞いてるあたり
最新版では提灯コメントが出てくると思ってるんだろ
KENTAはScalaコミュニティ分析してるしガリ勉オジ嫌いって言ってたから
内心は言語オタクRust(コミュニティ)を良く思ってない
でも表面上では良い顔してくれると思うよ 低レイヤー向きなのはガチ
Webやバッグエンドで扱うのはなかなかピーキーすぎるわ 低レイヤー向きなのはガチ(ただし既存システムは置き換えない)
Webやバッグエンド(その他もろもろ)はピーキー
こんなんじゃ提灯コメント出てこない >>613
現実を見よう
バックエンド・クラウドサイドがRustで最も盛ん
フロントエンドもWasm記述言語トップがRust Haskellが衰退したという結果は判るけど、何を言ってたかとか経緯はよく知らない こんな中、Clojureの勉強始めたわ。
Common Lispは、なかなか良い実装見つけられなくて挫折したけれど、ClojureはJVMの資産が使えるし、少し期待してる。 >フロントエンドもWasm記述言語トップ
どこぞのビルボード部門別1位みたいな言い方だな >>618
Clojureも愛され言語ランキング上位だったな ガンガレ WebAssemblyをGC言語で書くと実行速度もバイナリサイズも無駄すぎるため
現実的な記述言語がRustとC++しかないので当たり前
ただしこの対等勝負でC++にRustが勝っている点は注目に値するかもしれない >>621
所詮どこぞのビルボード部門別1位だからな
KENTA周りでwasmが見えてるのかどうか
重箱の隅をつつくレアケース、まだ試食タイムかとか
話はそれから WasmはJavaとか変わんないのになんでアセンブリ名乗ってんの
いくらなんでもリテラシーが低すぎないか >>623
そこは起源がasm.jsから来てるのだろうけど
決定的な違いとしてJava仮想マシンはガベージコレクション前提
Wasmはガベージコレクション無しで始まった点からもWasmがアセンブリに近いかな なるほど確かにそう言ってました
型システムが重厚長大でトランスフォーマーだらけで
「正しいコード」をコンパイラ通しづらくなるのよ。
とうせるんだけどそのための変更の労力が馬鹿になんなくなる。
で、やーめた、となる。。 コンパイル通れば問題ない
コンパイル通れば コードが成長すると加速度的にコンパイル通し辛くなる
コンパイル通っても 「問題ない」なんて理想でした
Rustでもどっちも当てはまる コードが成長すると全体把握が難しくなるというのは分かるがコンパイル通すのが難しくなるというのは分からんな
イディオムに従えばコンパイルは通せるでしょ普通に C/C++/低レイヤー/wasm/GC/大規模コード/概念的理解の精密化の
ヒント・間違い指摘・揚げ足取りは思う壺です。
プロレスに終始 >>626
Rustはコンパイル通し辛いとかないよ
もちろんどの言語でも慣れるまでは大変だけど
Rustも他の言語と同様に慣れたら大丈夫 荒らし本人は4回線で、ID維持、単発ID織り交ぜてサクラ、ごく稀に便乗
プロレスに終始 Scalaレベルで着地できれば御の字、あるいは...
Haskellはアカデミック勢が根強い、果たしてRustは... >>609
シナリオどちらかになるんだろうけど
どちらになってもRustを使いこなせる人が勝ち組じゃん スタックとかヒープとかはC++の方から来た性質だから
Haskellは本当の敵ではないね >>589
そこに上がってるのもほとんどがフレームワーク使ってシステム作ってますな使い方しか日本じゃしてないから、そういうとこにRustが入り込むにはもっと周辺が充実してからじゃないと日本じゃ無理じゃね? >>596
COBOLとFORTRAN忘れてるぞ。 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
こんなところ >>636
Rustだと所有権とかsingle mutable xor immutable referenceとかのキツイ制約があるから、フレームワークを作るのも使うのも大変。
まぁ、Rustフレームワークが充実することなんて無いんじゃない? >>640 荒らし本人の主張
この後いつもの世迷言が始まる 小学生は方程式を使ってはならない的なキツイ規制が無いからこそ
C++やRustがやりたい放題やってる >>642
それを言うなら Rustはキツイ規制の鶴亀算 「なんで鶴亀算だけで全て解かなきゃなんねえんだよ」
「鶴亀算だけなら俺が安全性や正しさを確実に保証してやれるからだよ!!!」 お待たせしました(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 お待たせしました(2/2)
↓New
Haskell アカデミック勢が根強い
それ以外は衰退しました
OCaml 関数型で速度を最優先するならこれ1択
StackOverflow >愛され言語ではない
FORTRAN 科学技術方面で強い、しばしば1択
Julia 科学技術方面開拓中
StackOverflow >愛され言語ランキング上位
COBOL 金融機関方面では既存システムで根強い
それ以外は衰退しました 愛され言語で上位になったらかなり高確率で衰退言語になる。 >>641
もっとまともな反論したら?
せめて「actix-web最強」ぐらい言えよ。使ったこと無いから知らんけど。 かなり高確率で新しいおもちゃを見つけて衰退言語になる >>609
既にそのパターン2で進んでるように見える
状況を認識できている世界的IT大手はいずれもRustを採用して高速と安全の両立へ
そしてまともなところは今後追随していくのが確実だからダメなクズが取り残される >>609
バスに乗り遅れるな論法
日本人には通用しなくなった 弱肉強食がもう通用しない
早く生まれた年寄りが遅く生まれた子供の肉を食うから C++だって誕生当初からこれまで、先行投資なんか必要なく、
陳腐コモディティでも二極化でもないんだから
Rustも先行投資なんて必要なくてGAFAMのトリクルダウンをどっしり待つくらいで十分
トリクルダウンなんて期待してないけど Rustの動きが興味深いのは、
C++の分野だけでなく幅広い分野で用いられてる点だが、
C++と異なり現代的な様々なパラダイムを簡潔に扱えるようシンプルに統合されてることも大きいのではないか。
もちろん、常に安全に自動的にメモリが解放される手軽さを得つつ、
少し注視するだけでC並みの高速化を安全に得られることが決定打なのだろうが。 >>661
そう、Rustには興味のアンテナ張るだけ
先行投資なんてしない トリクルダウンって何年後? 全プログラミング学習者へ。ハーバード大の入門講座「CS50」が無償かつ日本語で学べるようになりました!
https://www.lifehacker.jp/article/2209_cs50_new/
>「CS50」ではコンピュータサイエンスとプログラミングに関する概念や考え方、C、Python、SQL、JavaScriptなど主要言語を学べる
Rustは対象外(笑) >>609の二極化が進みそうだな
企業もプログラマーもRustを使いこなして高速と安全とリソースコスト削減をできるか否か >>609 >>663
二極化だと思ってたらHaskell衰退の道を追う >>664
おまえ頭悪そうだな
Rustがコモディティ化するのと二極化するのとどちらがGAFAMなどの寡占を維持できるか?
C言語と同等に高速で安全も満たす言語がRustの他にない >>645
1行に収まらない文章は見た目悪いから短くして >>667 >>662
GAFAMがRustを寡占するんだったら尚のこと先行投資なんてしない
GAFAM >Rustエコシステムには投資しない トリクルダウン無し 寡占する >>667 >>662
GAFAM >だか今は試食タイムだ >>667 >>669
ショックを隠しきれない(笑)
>>663 Rustを使える企業とプログラマーが有利になるだけで
あとは置いてきぼりを喰らって不利になるだけだろう こんな風に攻撃的に擁護する人のいる言語は使ってはいけない
高確率で地雷 >>664
教育コストが高すぎて、大学で教えられないということだろ。
情報工学でLispをやらなくなったのと一緒だよ。 >>676
MITのことを言っているなら勘違いが過ぎる >>676
Lispがわかりにくいのは単なる構文の問題
やってることはJavaScriptと変わらんよ
なぜかそれを凄いことのようにブランディングした先人たちのマーケティング能力の方が驚きだよ >>679
Clojureの人たちは「本物のREPL」とか言ってるよね プログラミング言語で闘争を続けて、1つも新しいソフトウエアやサービスを生み出せない日本の縮図だな・・・
欧米企業なら、「最初のバージョンは常に捨てられる」の格言通り、いかにいち早く世に出すか注力する。
なんで書いてあるかは余り関係ない
日本にも有名なソフトウェアのコミッターは数多くいるけど、コンピューターサイエンスというほとんど役に立たない事が
ものすごいマウントポジションをとるだけに使われ、人より早く書くや、人より多く書く人はありがたがらない。
欧米だと「アイデアは価値がない、アイデアを誰より早く形にして価値がある」とまでされる >>681
はい、言語選択が決定的要因だとは思いません。
相関はあると思うのであえて言語/frameworkで聞きますが
Ruby(Rails)は現在で良い選択だと思いますか?
スタートアップだとかのサイト作成の場合 書くのが遅いというか
お金をいくらもらえるか決めるのが早過ぎるのでは
カンバン方式みたいな >>684
Rustは書くのが遅いという前提の話かな システムプログラミング系の講義ならrust使うものとかあるんじゃないの >>688
Rustでメンタルモデル(概念)だけを教えてC++で仕上げとは
上手く行くといいね サイバーエージェントの広告配信サーバーもRustだし
クックパッドもRustだし
日本でもどんどんRustへ置き換わっていってるな rust system programming course university
でググったらUMDとかTUMとか出てくるわ
大学で教えられないほど教育コスト高いということはなさそう >>690 >>691
じゃあなんでRustがTIOBEで20位に入れないのか
https://news.mynavi.jp/techplus/article/20220907-2448116/
>Rustのように20位以内の常任入りが予測されつつも長期にわたって実現していないプログラミング言語 ソフトは無料でも教科書には課金した方が
教科書の劣化コピーがネット上で大量生産されやすい >>692
Rustは勝者のためのプログラミング言語だから敗者には必要ない
敗者は遅い言語や危険な言語を使い続ければよい >>692
大学で教えられているかどうかとTIOBEのランクに関係がある理屈がよくわからんのだけど >>694
素晴らしい。
Haskell目指して頑張ろう。 ClojureはあれでCircleCIとかいくつかの実用サービスに使われてるのがすごいよ。
lispは遊びでいくつか書いたけど、実用的なサービスをこれで書く気はなかなか起きないんだよなぁ。 >>663
コンパイル方式がメインな言語はCしかないの? ClojureにはLogSeqでお世話になってる。Obsidianと併用 >>701
素晴らしい。
Haskell目指して頑張ろう。 上ので思い出したけど
先にtypescriptやったあとrust入ったせいでリテラル型がないの違和感なんだけどなんか理由あるん?
enumでいいじゃん的な理由? >>703
文字列との相互変換とかIDE補完とかtypoエラーチェックとかExhaustive matchingとか他
どっちがどうなのかまとめて お待たせしました(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#(実例根拠が待たれる) ←🆕 お待たせしました(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と変わらん ブランディングした先人たちのマーケティング能力が驚き ←🆕
※ジョーク集です。「未確認」表示の有無に関わらず真偽を保証するものではありません。 wsl2のdebian入れたら何故かgrepコマンドがなくてrust製のripgrep(rg)をいれたわ >>708
どっちの立ち位置のコメントかわからないけれどripgrepを知らない設定は不自然
ugrepとの比較のこと? >>703
パターンマッチ使えば同じことはできるよ
なんならマクロでもいい
ゼロコスト抽象化に反することはしないのがRust >>711
値が"foo"という文字列以外が渡されるとコンパイルエラーになる関数とか書けないでしょ ただ単にコンパイルがこれ以上遅くなる言語仕様を入れたくないだけ、何がゼロコスト抽象化だわwまったく見当違いも良いところ >>712
だからマクロでできるっての
お前が何も知らないだけ マクロでコンパイル時型エラーにできる?
実行時ならアサーション入れたりでマクロで何とかなりそうだけどコンパイル時に検出は無理くない?
個人的にはTypeScriptみたいな複雑さって本来過剰で、ブラウザ上のJSという特別な実行環境がゆえに必要になったもので、本来はenumとかで済までいいと思う。 >>698
lispは惑星探査機とか、特殊な用途で使われてるイメージ。
身近なところだと、ルンバがlispで動いてたはず。 >>718
>惑星探査機
何にも知らないけどAdaとかどうなんだろう >>717
マクロの引数をリテラル限定にしてその値をコンパイル時にチェックするくらいならできそうだけど
変数経由で渡されたときにその中身を確認するのは無理だろうな
Rustの依存型は提案されたけど入らなかったね(理由は忘れた) 自動車 船舶 航空宇宙のプログラムで求められる安全性ってRustは保証しないの? >>714
>だからマクロでできるっての
>お前が何も知らないだけ
↓
>>720
>できそうだけど
これってまさか同一人物の発言? いや別人
自分はマクロを使っても完全なサポートは無理だと思ってるよ
マクロを使ってなんとか実現できそうなことを書いてみただけで 現実派の>>723さん、>>721についてはどう思いますか?
突き詰めるとメモリ安全性って自動車 船舶 航空宇宙でも大きなウェイトを占めていてもおかしくない気がするのです。
Rust方面の意識として乗り物関連は避けたいとかあるんですか?
「Chrome」で対処されているバグの種類
https://asset.watch.impress.co.jp/img/wf/docs/1439/971/image3.png >>724画像の記事
「Chrome」は「MiraclePtr」でさらに安全に 〜Googleが「解放後メモリ利用」対策を開設 診断性が向上するという副次的効果も
https://forest.watch.impress.co.jp/docs/news/1439971.html >>724
トヨタが自動運転関係でRust使ってる話を見たことあるね
ChromeはRustで書き直せばバグを1/4に減らせると言われているね >>725
>安全を認定されたAdaツールチェーンの開発で培ってきた専門知識をRustコミュニティへ拡大する機会を提供する。
こういうのを待ってました!
>Ferrocene Rustコンパイラ
多分有償なんだろなorz >>724
GC言語だと赤と青はまず発生しないからやっぱりRustは別にそれを置き換えることはないな
あくまでもCやC++を置き換える有力候補 >>727
トヨタはRust資産をOSSしてくれるんだろうか... >>728
FerroceneはRustコンパイラのISO26262認証取得を目指してるから
通れば自動車とかへの採用はあり得るよ
スポンサーもついているようだから少なくとも興味のある企業があるのは間違いない
Ferrocene自体はRustの特定バージョンの仕様を文書化して認証を取るという試みだから
コンパイラが別途有償になる予定はないはず >>726
その記事を読むとChromeはC++のまま情けない解決策を取ろうとしてるなあ
特に参照カウンタ方式を強制するのは敗北に見える
メモリ使用量が増えると明記されているのはともかく
参照カウンタのデータ競合回避保護のためのオーバヘッドでパフォーマンスも大幅に悪化が予想されているのか >>727 >>729
>ChromeはRustで書き直せばバグを1/4に減らせると言われているね
>あくまでもCやC++を置き換える有力候補
この辺はタラレバくらいに思ってます、軍事関係みたく湯水の様にお金をつぎ込まない限り >>729
GC言語からRustへ置き換えるケースが多いのは別の理由でメリットが多いためだよ
・高速化
・省メモリ化
・データ競合の完全防止 >>731
続報待ちます
>>732,734
>データ競合回避保護 データ競合の完全防止
難しそう。自動化してほしい >>735
データ競合をコンパイル時点でゼロにすることに成功したのがRust Rustのデータ競合防止のやり方は効率性を犠牲にして安全側に倒してるだけでしょ
程度の違いこそあれ、純粋関数型で全部イミュータブルにすりゃデータ競合なんか起こらねえというのと同じようなもんだ 現実派の>>723さん、>>736についてはどう思いますか? ゼロってことはないよ
標準ライブラリ内とか人間がデータ競合しないことを保証してるところはそれなりにあって、そこにバグが入ることはありうる
実際過去に発見されたことはあったはず
ただまぁ他言語はほとんどなにも保証してくれないから
それに比べれば十分メリットはあると思うけど あと今人間が保証してるとこを機械的に証明しようという試みはあって
そういうのがうまくいけばゼロだと言える日がくるかもね
(そうはいっても証明手順に抜けがあるかもとかあるので真にゼロとはいえないかもだけど) 並行安全がーとかいうけど言語自体やライブラリを跨いで共通のお作法で並行並列処理を書けるGoと違って
Rustはあまりにもお粗末すぎるから結局無駄なことしてるだけとしか思わない >>737
効率が必要ならunsafe使うとか、適材適所で手段を選べるようにしてるから純粋関数型のたとえはちょっと違う気もする >>737
一般的にデータ競合安全性のためには
1. まず前提としてデータ競合の可能性がある場合にコンパイル時に自動的に必ず検知できること
2. プログラマーはデータ競合の可能性がある部分のうち下記3.以外の方法(アルゴリズムやデータ構造などの変更)が取れる場合は変更
3. データ競合の可能性があるとして残った部分はロックなどで競合回避
Rustが用意しているのは1.の実施と3.の機構の提供
効率性を高めるか犠牲にするかは2.の実施と3.の利用をどう行なうか次第でありプログラマーによる自由度がある うん、だからそれデフォルトの挙動が安全側になってるという話だよね
そのレベルなら、デフォルトで全部immutableで必要に応じてmutableにできる言語なら十分に対策になってると言えるのでは >>741
Goは並行しない場合もする場も様々な安全をプログラマーの自己責任で確保しなければいけないことが多すぎてそれ以前の問題があります
例えば非常に単純な>>556の例でもGoコンパイラはエラーとしてくれないためプログラマーが自己責任で防がなければなりません
一方で同じ問題例をRustならば>>560のようにコンパイルエラーとして検知できます >>744
mutableを使った時点でデータ競合の可能性が発生するためコンパイラ等が検出する必要がある
一方で全てをimmutableにすると大量のガベージが発生して効率が悪い
効率と安全性を両立しているのはRust言語のみ GCあり言語ならストップザワールドやGCスパイクとか体験できるじゃん。
でもRustだとそれができなくなる。 >>744
mutableな共有領域に対するアクセスについてはコンパイラは特になにも保証しなくても良いということ?
そんな安全機構は邪魔なだけだから不要と 全部immutableと言うけど、スレッド間で通信するメッセージがimmutableなだけで
スレッド自体の状態は刻々と変化する
マルチスレッドが何の役に立つのかさっぱり分からない人にとっては
状態遷移をするにはスレッドを使うしかない言語の方が分かりやすい 話が盛り上がっていたので見守ってました...
>>739 >>740
>機械的に証明
この辺もタラレバくらいに思ってます。「ゼロってことはないよ」の方が逆に説得力w
自分の現場は、石橋を叩いて渡る、です。(能力体力は十分)
RustはGAFAMなんかより自動車ISO認証級の実績積み上げがないと、下っ端が言い出すのも怖いくらいです。
Rust現実派の人が現れたので便乗してしまいました。ありがとうございました。 >>751
Rustは一貫して以下のルールでシンプルに安全性を保証している
「Rustコンパイラはunsafe部分を除いてプログラム全体の安全性を自動的に保証する」
「unsafe部分の保証と影響を外部に出さない保証のみプログラマーの責任となる」
つまりunsafeを用いたとしてもその局所的なコードのみ人間が注視するだけでプログラム全体が保証される仕組みをRustが提供している
従来の言語は安全でない部分がプログラム全体に散らばっている、かつ、言語が安全を保証する仕組みがない、という悲惨な状況であった >>752
今後、オカタイところや人命に係る分野での採用記事事例など宣伝してもらえると嬉しいです。
>>753
自動車ISO認証取得+自動車への採用(どちらも今後の可能性)レベル、と書くべきでした。
「話はそれから」です。 >>754
ちなみに今はどんな言語使ってるの?
枯れたツールチェインとなると結構古めのCとかかな >>755
>結構古めのCとかかな
様々な都合によりC、としか言えません 普段は見てるだけなのですが、いいタイミングで便乗出来ました。
こういう現場もあるよという話が出来てよかったです。では。 GoogleとMicrosoftが共に各々で語っているようにC/C++で書かれた大規模ソフトのバグの7割はメモリ関係
例えば>>724のChromeでも7割がメモリ管理バグ
これがRustに移行すれば無くせるのだから新たなシステム作りでC/C++を採用するのはバカだけ >>746
それは、両立じゃなくて、選択肢があるってことだよね?
両立出来ていれば、わざわざ選択させる必要もないし。 ファブルって最初は絵が受け付けなくて読んでなかったけど、いざ読んでみたら面白かった。 >>759
Rustの場合は常に安全が成立するから安全は選択肢ではない
アルゴリズムやデータ構造などを工夫することにより排他ロックなどを必要最小限にして効率化することはプログラマーの自由裁量
Rustにおいて安全と効率は両立できる Rustは教官付き教習車だから、コンパイラの言うとおりに運転しないとブレーキ踏まれて前に進めない。
ソースコードのマネージャーにとっては福音だけどな。自分でコーティング規約を用意してコーダーに強制しなくても、コーダーが自分勝手にプログラムしてトラブルになる可能性が減る。
コーダーがコーティングしやすいかどうか、とかどうでもいい。
企業がRustを推奨し始めたのは、企業がマネージャーサイドでソースコードの管理コストを減らしたいから。コーダーは言うこと聞くやつを連れてくればいいという発想だよ。 >>763
Rustはプログラマーに愛されている言語No.1しかも7年連続
快適なプログラミングのしやすさが特徴の一つ >>707
grepに続いてtarも無い、と思ったらPATHから /bin が抜けてたわ。
/usr/bin にあるわけじゃないのか。 お待たせしました(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は教官付き教習車だから、コンパイラの言うとおりに運転しないとブレーキ踏まれて前に進めない。 🆕 お待たせしました(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 🆕
※ジョーク集です。「未確認」表示の有無に関わらず真偽を保証するものではありません。 >>763
これってrustに限った話ではないのでは
例えば今話題のgoの未使用変数をエラーにするとかは同じ考え方だよね >>769
Goは元々>>556の例を始めとして落とし穴があちこち多数仕掛けられている言語なので
まずは様々な落とし穴パターンをできるだけ多く習得して自分で責任を持って回避していかないとすぐに事故を起こしかねない言語でもある
だからそこで言う教官(コンパイラ)が指導ダメ出ししてくれないケースが多い中で未使用変数の件は親切に指導してくれる良い例 >>769
これ実質的に自己責任論だから
人間はみんな自己だよねと言っても無駄で、自己はこの世に一人しかいないという考え方なのさ なんでRust信者ってID変えんの?
自信ないからかな? >>765 >>769
『Rustの作法に慣れたコーダーなら』コンパイラにブレーキを踏まれて止まることも少なくて快適だろうけど、慣れていない初級者・初学者のストレスは半端無い。
絶壁の学習曲線はRustの重大な問題で、これを何とかしない限りはHaskellくらいの普及率が関の山かと。 「教官、時速40キロで走っていると原付に追い抜かれて行きます。それに時間に遅れます!」
「奴は自己責任だ。お前は俺だけを見ろ」
「はい! あっ、事故っちゃいました、テヘ」
「ばっかも〜ん。しょうがないやつだな」
Rust、愛され言語No.1 >>776
初学者が躓きがちなところって例えばどこなんだろう
学習曲線が急という話はあるが実際に初心者が苦しんでる箇所が知りたいなぁ
>>777
これって具体的に何のことを揶揄してるの?
安全性のために効率性が損なわれるという論はあるけどスレで出てきた事例が配列の境界チェックくらいでコンパイラ関係ないという >>778
実効速度の事は揶揄してなくて、前半は>>681 >アイデアを誰より早く形にして価値がある
のことだと思うけど、
後半は手取り足取りでもChrome>>726でいう25%側で事故る(25%じゃ済まなくなる)、とか?
または愛されRust教官と生徒の...
大した意味はないと思う。 まあ実際はrustで開発なんてほとんどしてないからな。
だから自信のない奴が無理矢理褒めてるんだよ。 >>780
褒めてる側に怪しい人がいるのはそうだけど貶してる側も具体的な話に乏しくて印象だけで語っている人がいるような Rustは荒れるので話題転換
Clojure Haskell Lisp辺りの過去に一世風靡?した言語が先端分野で地道に使われ続けてるのは
単純に個別要因(研究者の好みとか)なのだろうか。
Lispくらいの歴史があるのならともかくClojure Haskellである必要性必然性が理解できない。
リストにあるNimも何を目指してるのか、何が得意なのか見えない。
Pythonからの乗り換えに最適、って出てくるのはNumpyも使ってないPythonコードの高速化例が主で、
この程度で「研究者の好み」に響くのか疑問 率直に言うと、Nimには開発者、コミュニティの言語オタク感が、、(いい意味で) >>763
ソースコードのマネージャーw
妄想が過ぎるやろww
お前やっぱり複オジと同じ種類の人間やな >>782
エンジニアの単なる個人的な好みだよ
スタートアップの開発はだいたいエンジニア1人~せいぜい2,3人で始まり、作り方について外から誰も口出さないから、何でも好きなものを採用できる
とはいえあまり変なものは後からリプレースされることも多いが、あえて関数型使いたがるような奴は比較的優秀だから結果的に生き残りやすいんだろうね >>776
どの言語もそうだけど慣れの問題だけだよ
慣れるまでは躓きやすいけど
慣れてしまえばそこに何か支障があるわけではなく快適
もちろん手続き型言語しか使ったことがなかった人が関数型言語を始めれば 最初だけカルチャーショック的なものもあるかもしれない
Rustは従来の手続き型言語のバリエーションの範囲内であり難しい点はなにもない
最近は増えてる関数型プログラミングを積極的にサポートしているだけの普通の手続き型言語である ブレーキ云々は関数型ではなく静的型に責任がある
と理解するまでに10年単位の時間を消費してるのが現実 lispはプロトタイプから本番に移行するに向いている的な事をどこかで見かけたんだけど、何か理由あるのかな?
本番であれば、今時は静的型付けの方が実行前にミスを減らせて良さそうって思うんだけど。 Concurrencyについては詳しくないんだけど
goはやっぱりつよいの?
erlangよりつよいの? >>786
マニュアル教習車の運転を「慣れの問題」と言っているようなもんだな。
最初はエンストしまくっていても、慣れればいつかは運転できるようになるわな。それがいつだか知らんけど。 >>777
そういえば前スレでrustは原付(php)に速度で負けてたよね 嫌いなものにはとりあえず統一教会と絡ませておけば批判したことにできる頭の具合が羨ましい >>788
common lisp とかだとあとから型書いてパフォーマンス上がる処理系とかあった気がするし、プロトタイプから色々柔軟に改修しやすいとかあったのかもね。 バージョンが 1.0 に達していない言語は混乱するだけだから入れなくていいよ
必要なら専用スレを立てた方がいい ちゃんと>>1に「スレタイ以外の言語もok」と書かれているように
それ以外の言語の話もこのスレでは歓迎です
スレタイは文字数制限があるため全ての言語を列挙することはできません
もし話題の多い言語が出てくれば話題の少ない言語と交代することになるでしょう
登場して20年以上経つ古い言語はもちろん対象外です >>790
goは聞きかじりだけどもシングルスレッドのコードを気楽に拡張して同時実行にできることが売りに見える
erlangは最初から並列であることを求めてるから方向性が違う
どっちも強いは成り立つんじゃないかな お待たせしました(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の重大な問題 🆕 お待たせしました(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 金融機関方面では既存システムで根強い それ以外は衰退しました 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 🆕
※ジョーク集です。「未確認」表示の有無に関わらず真偽を保証するものではありません。 >>jakt 追加は
Bounds checking, Sound null safety
try/catchは文
Dict Set TupleがPython並みに簡単 この辺はlife-time-analysysに頼らないでARCで実行時管理してるからかな ARCメインの言語はいずれも遅いから興味ないな
とはいえZigの手動メモリ管理の面倒さと危険さは今の時代ニッチに終わるだろう ワッチョイスレのリンク見たら
Written on May 19, 2022 時点で >It’s two weeks old.
っていくらなんでもホヤホヤ過ぎでしょw 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は都合の良い例だけ持ち出して「境界チェックは消える」とか言いがち スマポの時点で自動じゃないわなw
循環参照はWeak使ってなんとかしてくれっていうね
あとライフタイムにも参照の排他にも
全部頑張って気をつけないといけないのは書き手
メモリはGCに押しつけてしまうのがスッキリなのかもね
そっちはそっちで工夫してねっていう分離ができてる
nimなんかはそこを交換可能にしてて清々しいよね メモリに気配りしたいからこそrustを使うのであってGCで良ければGC言語使えば良いよ >>819 == >>814 だろ
形勢が不利になって面倒くさくなった?
じゃなかったら「Zigの手動メモリ管理の面倒さ」-->「Rustは自動メモリ管理で簡単」
みたいな書き方を明示的に否定してくれ
そういうところがRustの胡散臭いところ プログラマーに負担と責任を押し付けるZigは安全を軽視している GC言語使いたいなら止めはしないけど
それならスクリプト言語使った方がマシだよ 笑った >>819 == >>814 ==821==822 だろ 何回線目?
Zigの話じゃなくて、「Rustは嘘ついてました」って謝罪しろよ GCはメモリ確保やコンパクションや解放をまとめてやりやすいからパフォーマンス出しやすい。
そのおかげでストップザワールドやGCスパイクも享受できる。
負荷を予測したい奴には向いてないかもな。
そういう意味ではGC言語はピーキーなんよ。
お前にはまだ早いかもしれん。 >>824
swiftは問答無用でretain,releaseもつくからじゃんよ GCは〜って言って思考停止してるとRustでも使っているepochとか知らなそう いずれGCがメモリレイアウトを動的に最適化したり必要に応じて確定的なメモリ解放を行うように動的にJITしたりするようになるから、究極的にはGCが勝利するだろうね Zigの良さがよくわからない
C言語より安全なのはわかるけどでもそれって結局Cでいいじゃんってなるよね
Rustみたいに静的メモリ安全は実現するのは端から諦めてC言語よりちょっと安全な言語を目指しているんだよね
本当にニッチって言葉が似合いすぎている
構文も無駄に複雑だし汚いし将来性ないと思う >>830
それ結構難しい話に聞こえるけど、具体的な進展があるの? >>831 ZigはBinary生成が優秀だから、依存dll/soとかクロスコンパイルとか。Rustでも使っているよ >>820
変なこと言ってる人と同一視するのは勘弁してくれ >>820
そういう決めつけで妄想してると統合失調症になるよ Zigは作者が会社辞めて専念してるから、華々しくブレイクしなくてもずっと続けてくコミットがすごい
「安全性」は流行っているからリップサービス。マインドは常に実行速度。キレイなBinary。低レイヤー。
構文はちょこちょこ変わるイメージ。ときどき触るだけだけと直ぐに昔のがコンパイル通らなくなる。 Faster than Cが自慢なのはぶっ飛んでるように聞こえるけど、一時期あったVは嘘だったけど、Zigはときどき本当。
LuaJitでもHaskellでもハマる処理では「簡単な記述で」Cより速いときがある。やってみないとわからない。 構文なんて飾りですよ。狭い特定の処理がたまたま「簡単な記述で」書けるかどうかだけ。今はまだ時々実験するくらいで十分。深入りは先の話。 >>830
それインクリメンタルコピーCGのことでは? 今のところZig使うならCで良いかな
使う気にはなれないな すみませんZigはまだβ、Nimはver1.6という事で....
>>818
>nimなんかはそこを交換可能
NimのGC/ORC/ARCは興味深いですね
https://nim-lang.org/blog/2020/12/08/introducing-orc.html
もっと選べるようだけど、循環参照などデータ構造別に切り替えて混在出来るのかな?
https://nim-lang.github.io/Nim/mm.html
>>843 上記のリストに入ってますか? >>843 教えてください。検索すると30年位前の論文なんかも出てきて実現しているのかどうか、
それが>>830で言っているGCと一致しているのか、ちょっと理解が追いつきません.... GCの研究が進んでよりよいものができるようになったとき
GC言語はそれをまんまと拝借できるから旨味あるよな >>848 そうなんです。
ただ >>843の「incremental copy garbage collector」が30年以上まえから未だに研究されているのは検索すればすぐにわかるのですが、
nimで選べるくらいの実用段階なのか、更には>>830で言っている ものと一致しているのか、 重要ですよね。
30年以上の研究なんて逆に絵に描いた餅に思えたりするので。 GC活用するだけじゃなくて、スタックフレームからエスケープしにくくする仕組みがあると面白いと思うけどね。
Rustほどガチガチだとだるいから、エスケープをコントロールするスマポみたいなクラスを用意するとか。 GC以外だと、JVMや. NetなんかのVMも結構に改善してるんじゃない? GCもVMもどんどん改善してくれたまへ
JavaでHotSpotだのJITだの言い出したころワクワク感あったな
プログラマはプラットフォームに対してでなくて
これからはGCやVMに対してプログラミングをするだけでよくて
さらにGCやVMは誰かのおかげで勝手に改善されていくらしいという http://www.kmonos.net/alang/d/garbage.html
ガベージコレクトされたプログラムの方が高速です。 これは直感に反するかもしれませんが、その理由は:
明示的なメモリ管理の際によく使われる手法は、参照カウントです。 代入があるたびにカウントを増やしたり減らしたリソースを挿入するのは、 速度低下の原因になっています。スマートポインタクラスでラップしても、 速度的な解決にはなりません。
(またいずれにせよ、 循環参照を削除できない参照カウント方式は、 一般的な解決策ではありません。)
オブジェクトによって獲得されたリソースの解放には、 デストラクタが使用されます。多くのクラスでは、このリソースとは 割り当てられたメモリのことです。
GCを使えば、 ほとんどのデストラクタが空になり、完全に削除してしまえます。
メモリ管理のためのデストラクタは、 オブジェクトがスタックに置かれたときに影響が顕著になります。
例外が発生したときに、全てのスタックフレームでデストラクタが呼び出され、 メモリを解放するような仕組みが必要となるのです。 もしデストラクタが関係しなければ、例外を処理する特別なスタックフレームを 設定する必要がなくなり、コードは高速に実行されます。
メモリ管理に必要なコードは全てを合わせるとちょっとした量になります。 大きなプログラムになるほど、キャッシュに入らない部分が増え、 ページングが多く発生し、 プログラムが遅くなります。
GCは、メモリが残り少なくなってきたときのみ実行されます。 メモリに余裕があれば、プログラムは全速力で実行され、 メモリ解放に一切時間を取られません。
モダンなGCは、過去の遅いものより遙かに発展しています。 世代型のコピーGCには、 昔のマーク&スイープアルゴリズムの非効率さはありません。
モダンなGCはヒープの詰め直しを行います。 これによってプログラムが活発に参照するページの数を減らし、 キャッシュヒット率を高め、 スワップ回数が減ります。
GCを使うプログラムは、メモリリークの積み重ねで次第にパフォーマンスが悪化、 という事態に縁がありません。 >>830
どちらもJVMで実現済みのことに思えるが…。
メモリレイアウトの最適化
→ 世代別GC(長寿命なオブジェクトは頻繁にGCしない領域に移動する)
確定的なメモリはJITで開放
→ エスケープ解析(短命でスタックに乗せても構わないオブジェクトはスタックに乗せる) >>853
近現代の言語だと例外は飛び抜けて重い機能だよな。c++使うときも自分から例外を使うこと無いし。
例外みたいなエラーフローあると便利なことあるんかね? >>855
それも言語の良し悪しよりもbanがやるべきことをやってないだけだったり、nodeが本質的には不必要なことをやりすぎているだけっぽいと思うんだよな。 GC言語、メモリを山のように積んでるマシンだと走りきるまでGC走らなかったりするしな。
mallocしてfreeしないアプリみたいなもんで、ケースによってはそりゃ速い。 >>857
要約すると、RustはZigに比べて本質的には不必要なことをやりすぎている、という事でOK Rust「zero overhead abstraction」は嘘でした >>853
この文章10年以上前からあるけど今でも成り立つのだろうか
確かにメモリ解放を遅延させることによって実行命令数がGCの方が少なくなる場合はあると思う
一方でいくつかのmalloc実装がやっているような、直近にfreeされた領域を優先的に再割り当てするようなことは、GCが走らない限り、つまり、メモリを使い切るまではできない
freeされた領域はキャッシュに載っていて高速にアクセスできる可能性が高いので、直近にfreeされた領域を使い回すことはキャッシュヒット率を高める効果がある
GC言語は命令数は少なかったとしても、メモリのアクセスレイテンシの影響をより多く受け、トータルでは遅かったりしないだろうか
この文章の元ネタのベンチマークがあるなら現在のマシンで比較してみたら面白そう >>861
アプリの実装の善し悪しの話と実装言語の善し悪しを意図的に混同させるのはよくないよ >>865 Chrome by C++の場合について聞かせて >>864
それソースある?
必ず再利用するにあたって領域を書き換えてんだから、直前にfreeしたかどうかに関わらず書き換え直後にキャッシュに乗るのは当たり前じゃないの?
チープな環境でスワップインを回避する効果はあるかもしれんが >>858
曲解してるかなとは我ながら思った。
けど、GCが勝つというほどインパクトある伸び代が挙げられた項目にこれ以上あると感じないんだよね。 >>876 スワップインて。。>>864はまっとうな意見だと思うよ。 >>868
>GCが勝つという
そんな場合もある、程度では。
GraalVMでNativeにした場合で
Native Java(+GC) vs Native other(no GC)は気になる escapeするかしないか、静的と動的でそんなに違うもんかね。
むしろエラー以外はescapeする・しないは静的で相当範囲カバー出来てそう。データはないけど。 >>864
これはそう。ただ投機的実行(と昨今のその去勢)とかを考えると結構難しいかなとは。 GCを止めたら速いという話は藁人形論法なのでやめませんか? >>872 vulnerability詳しくないけど、mitigationでfree->mallocがどの程度影響するのか気になるな。 >>853
>GCを使うプログラムは、メモリリークの積み重ねで次第にパフォーマンスが悪化、 という事態に縁がありません。
嘘言うな GCは解放の実タイミングは調整するけど「メモリリーク」とは見なしてないのでは。
むしろ Rust「メモリリークはメモリ安全性保障の範囲外」 の方なんとかして >>867
GCはそもそもfreeから再利用まで間が開くのでその間にキャッシュから外れる可能性が高くなるし、
再利用に当たって領域を書き換えるなら、キャッシュに載ってない場合書き換え処理に時間がかかるのでは
スワップインはよくわからない >>877
メモリリークを静的に検知するのはプログラムに対する制限が相当大きくなってしまうのでは >>879 動的にでも検知する仕組み/試みがあったりするのかな。テスト、プロファイル、そりゃあるかな。 >>880
valgrindとかAddressSanitizerとかmallocをhookするやつとかいろいろあるよ GCはいわばメモリ管理の専門家に幅広い裁量を持たせて仕事させているわけで、
それに比べるとアプリケーションコード内でのメモリ管理はCenter of Excellence的な意味では原理的にどうしても不利よね
メモリ管理の専門家が十分な裁量を持って仕事できるのはせいぜいアロケータの実装くらいで、ほかは高水準のプログラミングモデルやプログラマの能力の制約を強く受けることになる それ以来30年間GC技術が進んだ結果の現状が既出のこれ
>>200
>> https://pbs.twimg.com/media/EmYvG8aVkAMdfFG.jpg
全く対等に同条件で多くの人々が同じ問題に対して様々な言語で記述した結果の各実行時間
速く実行できた言語はRustとCとC++の3つでいずれもGCなし
GCする言語は軒並み遅い
一部をGC対象とならないよう回避の努力をしているGoがGC言語の中で最も速い
そうでない普通のGC言語は遅すぎる >>886
これってGC性能が支配的になる問題なの? >>887
(1) GCが発生している場合
→ GC性能が改善された現在でもGC言語は遅い
(2) GCが発生していない場合
→ GC性能と関係なくGCが起きない段階でもGC言語は遅い
どちらのケースであってもGC言語はダメな存在になってしまいますね あれ、D言語はかなり早いイメージだったけど、Goに負けることもあるのか Goは速いよ。
アンチGCはGC言語じゃなければ速い、と思い込みすぎでは?
ミッション車みたいなもんで、自分の設計力の無さがパフォーマンス劣化に直結するというか、いわゆるベンチのスペックは素直には出ないよ。
Rustアンチじゃないけど、これはRustの目的でもない(あくまで安全が目的)
GC言語みたいにだれでも80点が取れます、エンストしませんよ、みたいなもんじゃないんよ。
コンパイラが叱ってくれるからハイパフォーマンスとか、書いてて言ってんのかほんとに謎。 >>886
そいつの読み方は「C++とPyPy3圧倒的じゃないか」ですよ。
新参者から熟練者まで数と質すべてが圧倒的。
C++は熟練すると、黒魔術を含め、やりたいことが全てできる言語なので、突き詰めていく性質の企業におすすめ。
逆に、手数で勝負の乱打スタイル企業には、PythonやRoRがお勧め。 >>893
Javaも速いですよ。
Rustの3倍は冗談だけど。
欠点はメモリーを使いすぎること。
一般的なパソコンはメモリーが少し足りない。
だから、Javaは遅いと思われてる。
ミスマッチです。 ハードウェアを売りたい言語だから、ハードウェアに対する要求が少し厳しかったですね。 >>886
やはりGCの言語はいずれも遅いな
GCのせいで遅くなるのではなく
ヒープでメモリ確保するからGCの言語は遅くなる >>896
Java速いよね。あんまり適切なXmx知られてないだけだと思う。
>>898
少なくとも知ってる範囲だとGoもc#も取れるときはスタックを確保するぞ。 >>899
Javaは遅いです
どのベンチマークでもC/C++/Rustの2倍~数倍はJavaが遅いです
>>886の例でもJavaは数倍遅くなっています >>900
abc 182-eはakariって問題なんだけど、読んだ?
Javaで雑に書くとパフォーマンスでない類の問題だよ。
このグラフは言語オタ勢には有名かと思ってたけど、ベンチマークのグラフではなくて、あくまで競技者が書いた言語毎の統計のグラフなので、ポンコツが多ければそれが表現される。
言語人口が多いものの箱ひげが偉いことになってるでしょ。 >>901
なるほど
しかしJavaで書いて最も速くできた人でも遅くて
Rustで書いた平均的な人たちにすら負けているな>>886
どんなに優れた人であってもJavaを使った時点で遅いと確定してしまうのは辛いな >>877
これ訳わからんよね。
そこまでして「GC不要でメモリ安全」を売りにしたかったのか、と思うわ。
c++とかだとメモリリークも普通にバグ扱いされるのに、それを「メモリ安全」と言い切るのは詐欺臭い。 >>902
そもそもRust使える人間は他の言語に詳しい人間しか居ないだろ。
他の言語に詳しく無い人間がRustの絶壁の学習曲線をクリアできるとは思えん。
「Rustしか使えません」なんて人間は存在するのかね? >>903
それは常識
一般的に循環参照の安全な解放を静的に記述したり静的にチェックすることは不可能
デッドロックも同じで静的に発生をチェックして防止することは不可能
だからコンパイラ(=静的にチェックする存在)がそれらを防ぐことは対象外となる >>904
バカは遅い言語や危険な言語を使い続ければよい
時代の要請は高速で安全でプログラミング効率の良い言語でありそれはRust
使えないバカがついていけずに切り捨てられていくことは業界にとっても朗報だ 早い言語は適当に書いても2秒の時間制限に間に合うけど
遅い言語は問題の想定解法じゃないと通らないから結果的に早い言語は上髭多くなるだけ >>902
execution timeの単位はミリ秒だぞ
ベンチヲタは気にするが1000000回ループして1秒か2秒しか差がつかないのに現実的に問題になることってないぞw
現実のループは多くてもせいぜい1000回程度だろ >>908
あんたには遅くてダメな言語で十分なのだから他を気にせず不満を持たずそのままでいいじゃないか
あんたには無縁だが世の中には速くて安全で保守性も良い言語が求められているだけの話だ Rustの他の言語と比べた速度向上って、俺にじゃなく世のほとんどのプロジェクトにとって五十歩百歩の微々たるものなんですわw 前に、rustでtsc実装した人、さらにgoで作り直すって、理由がrustには向いてないからって。翻訳記事だからニュアンス違うのかもしれないけれど。 >>905
プログラマサイドにそんな「常識」は無い。プログラマ視点なら「メモリリークはバグ。メモリを圧迫してトラブルになる危険がある」の方が常識。Rust関係者はそういうことを説明の奥の方に隠して「メモリ安全」とか誇大広告するから詐欺だと指摘しているわけで。
常識とかけ離れた俺俺定義を使うならちゃんと注意書きしろよ。
「メモリ安全*」
*メモリリークを除きます。
みたいに。 Amazonの>>9の記事にもあるけど
Rustへ書き換えるだけだけでリソースコストや電気代それに伴うCo2排出量などが少なくとも50%は削減できる
さらにセキュリティの要請から安全性も求められている
土方でないまもともなプログラマーならばJavaでもRustでも他の言語でもプログラミングに支障なく書ける
それらの状況から選ぶべき言語がRust一択になっているだけでしょう 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 RustでなくVBAを使うことでエネルギー削減になることもあるな >>913
Rustを学習した人間の感想の多くが「Rustは難解」と言っているのに、「まともなプログラマなら支障なく書ける」とする根拠は?
根拠が個人の感想なら、「まともなドライバーならマニュアル車を支障なく運転できる」と言うくらい傲慢だと思うがね。 >>912
それはちょっと知識不足じゃないかしら
もし循環参照を作っちゃった場合はそれを安全に解放する局所的な方法は理論的に存在しないんですよ
GCでも局所的に解決できる参照カウント方式では循環参照を解放できないため
GCの中でも全体のマークスイープ方式や全体の使用中分コピー方式でようやく解放されます
そららは非常にコストが重いだけでなく発動までに時差もあります
したがってプログラミング言語界ではそんなコストがかかるものに依存するのではなく
最初から循環参照を作らない方向で進んでいます
そのため最近は多くの言語で弱参照がサポートされており循環参照の発生を防ぐことができます
今回の話のJavaでももちろん弱参照が用意されていて最初から循環参照を作らないようにプログラミングします
そのほうが有利だからです >>917
C#では参照はツリーで管理されるから循環参照も問題なく一瞬で開放される >>917
Wikipediaですら「メモリ安全性」の解説でメモリリークをメモリエラーとしているのに、実装側の都合で一般に使われている用語の意味をひん曲げて「常識」とな?
そういうのが詐欺だと指摘しているだけだけどなぁ。
今度からちゃんと
「メモリ安全*」
*メモリリークを除きます。
と注釈付けろよ。 >>918
それはC#でもJavaでもRustでも他の言語でも全て同じ方法です
どの言語も弱参照を併用して参照はツリー状のみにすることで循環参照の発生を防ぎます
もちろんそこには弱参照による弱い循環参照がありますが通常の参照はツリー状なので
おっしゃる通りに一瞬で解放することが可能です >>921
リンク先にある「メモリリーク」の項ぐらい読めよ。 今時循環参照くらいでメモリリークするような言語でよく安全を名乗れたもんだ
退化してるやん 昔は保守的GCというGCに人気があった
本当はゴミなのにゴミではないと判断することはバグではなく安全、という注釈つきのGCだった
この注釈は嘘だったという見方の方が今は優勢 予想される次の手:
・循環参照の矮小化
循環参照なんてめったに起こらないし
普通に書いてたら発生しようがない
・問題の転嫁
循環参照なんて書くほうが悪い
循環参照によるメモリリークなんかを問題視するほうが悪い
・飛躍した結論
とにかくRustは素晴らしい >>902
「この設問は」ね。だから競プロは複数言語できると面白い。 今は強い循環参照を作ってしまったら負けの世界
Pythonですら強い循環参照を避けるために弱参照が用意されていて回避できる
もちろんC#やJavaにKotlinやSwiftにも弱参照が当然あって回避できる
Rustなどのように強い循環参照が自然には発生しない言語仕様だと更に良い メモリ安全とは何なのがまとまってるページとかは作れないんだろうか >>925
Bohemとかもそうだっけ?
循環参照に関しては、確かにメモリリークだけど、危険ではないんでは?
Dangling pointerにならんかったら良いんじゃ無いかなあ。
循環参照で放置されているものの解放に時間がかかっても、別に問題ないと思うんだけどな。メモリに極端な制約がある環境下でなければ。
最初から循環参照を作らないというのは一つなんだけど、そういうわけにもいかんのよ。
最近書いたけど、グラフなオブジェクトなんかは循環参照するじゃん。 ようやくわかってきたよ
C 言語 に大量にある 未定義な挙動が ないことをsafeって言ってんのか
ならメモリリークっていう現象事態はたしかにsafeだ >>923
単にメモリリークと言ったら含まれるけど、
メモリ安全性に関わるメモリリークの文脈では循環参照は言及されてなさそうなんだよね
メモリ安全性という言葉の定義だけの問題で、実用上問題になるという点ではよろしくないとは思うけど 循環参照はコールバック等で普通に発生する
トレーシングGCでは全く何の問題にもならないから弱参照なんか使わんよ ttps://doc.rust-jp.rs/book-ja/ch15-06-reference-cycles.html
循環参照は、メモリをリークすることもある
ここか
なるほど >>931
今まである「メモリ安全性」の常識を無視して『メモリ安全性』という言葉を使わなきゃいいんだけどねぇ。
「プログラムの安全性にこだわった」くらいの宣伝ならまだわかる。
Rustはわざわざ「メモリ安全性」という言葉を使って宣伝しているんだからダメだろ。 確定的なタイミングでトレーシングGCしてくれるようなスマートポインタって実現不可能なの? 勘違いしてる人がいるようなので正しい知識をまとめておきます
C++やRustのような非GC言語やリファレンスカウント方式のGC言語では(強い)循環参照の解放は原理的に不可能です
これらの言語ではデッドロック等と同様に(強い)循環参照は発生させてはいけない禁忌として扱われ発生自体を避けます
対処方法としては弱い参照を用いた弱い循環参照を用いるのが主流ですが
プログラムが自分で管理する範囲内で循環参照を作ってまとめて解放したり範囲内GCなどを用いる方式もあります
マーク&スイープ方式やコピー方式のGC言語ならば(強い)循環参照も解放することができます
ただしそれらの方式は全体空間を全てマークしたり辿ったりコピーしたりとコストが重いことの裏返しでもあります
さらにGCが起こるまで無駄にメモリを専有してしまう問題もあります
そのためこれらの方式のGC言語でも弱参照が用意されて(強い)循環参照を作らないようにすることが一般化しつつあります >>939
ちょっと本垢でQiitaにでも書いてくれマサカリ投げに行くから >>937
Rustのメモリ安全性、というのを先に定義しとるからなぁ。
そこはまぁ定義次第なのはその通りだと思う。 >>938
無理だよ
だから各言語は現実的な対応をとってる
例えばC++のshared_ptrでも循環参照を起こしたらメモリ解放できない
回避策は強い循環参照を作らないようにweak_ptrを使う
Rustでは意図的に頑張らない限り循環参照が勝手に作られることはないけど
同様に参照をWeakにできるからメモリ解放可能な弱参照を用いた循環参照にして扱う
これはARC方式のSwiftでも同様で循環参照を起こしたらメモリ解放できない
Swiftでもweak宣言で弱参照にできるので解放できない循環参照を避けられる
いずれの言語もほぼ同じ仕組み >>944 >Rustでは意図的に頑張らない限り循環参照が勝手に作られることはない
よくわからないので聞くけど、
Rustでは意図的に頑張れば、Weakにせずに循環参照データ構造を定義してzeroじゃない実データ構築をするコードがコンパイル通るの? >>943
ならトップページに「Rustにおけるメモリ安全性」として「*メモリリークは除く」くらいはやらないと優良誤認だろ。 >>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 >>937
循環参照によるリークを含むようにメモリ安全性を定義してる文献ってある?
Wikipediaの定義ではメモリリークという分類はあるけど、
"メモリ使用量が追跡されていない又は誤って追跡されている場合"
と説明されていて、前者は当てはまらないし、後者はダングリングポインタなどを意図しているようで、循環参照は含まないように読める
SwiftやChromeやAOSPやDのメモリ安全性に関するドキュメントでもメモリリークについては触れられていないようだった >>949
[BUILD]にしてみたが「循環しるよ」的なwarningはないのね >>951
>>944 >Rustでは意図的に頑張らない限り循環参照が勝手に作られることはない
warningがないし、当該データの使い方次第で実行時エラーにもならないので
意図しなくても、「偶発的に」循環参照が作られることはありそうだ。 潜伏した循環参照が後々深刻な事態になるかどうかは別の話だが
Rustだからと言って、コンパイル通ったからと言って、油断は禁物で >>937
> 今まである「メモリ安全性」の常識
お前の脳内の話じゃないなら具体的にどういう事なのか示してみそ すげーくだらないことで盛り上がってんなw
さすが次世代w言語wwスレwww メモリリークだけでは安全性には差し障らんでしょ。一般的に。
スタック、ヒープが枯渇することはメモリ安全性に差し障るけど。
リークしてるけど走りきった、とか、GCがまとめて解放した、はセーフだと思うよ。 >>950
そんなことよりもまず
「メモリ安全性は(プログラムによる)メモリエラーを許容するのか、しないのか」
はどちらだと思うのか考えてもらいたいね。Rustは「メモリエラーが発生するけどRustはメモリ安全」て言っている。
>>955も同じな。お前もRustみたいに断言するのかね。
まぁ、「c++よりもメモリ安全」というならまだ正確だが、それならそうと正直に言うべきだと思うがね。俺俺メモリ安全をwebページの奥の方に置かないで。 >>957
いやメモリリークはDoS攻撃に対する脆弱性になりうるから安全性に差し障るよ >>958
「メモリ安全性」という用語の定義の話に変な造語持ち込んで話題そらすのやめてよ
Rustによるメモリ安全性の定義が俺俺というなら、ちゃんとした定義を示して欲しいな
「常識だから分かるでしょ?」というのは自分の思いの表明にしかならないよ >>958
だからお前の思う「メモリー安全性」の定義を示せよ
まあ示せないからぐだぐだはぐらかすしか無いんだろうけどw >>957
だとするとRustで常駐系のプログラムの開発をするのは安全では無いですな。
常駐系プログラムがメモリを食い潰すのは良くあるバグだけど、Rustだとそれは「仕様」で「メモリ安全の対象外」なんだから。
まぁ、Rcの循環参照だけの話だから、外部のコードを含めてRc使っていないor循環参照していないことを検証できれば安全なんだろうけど、Rustファンが言うような「Rustを使えば安全」というようなことは無い。
>>960
素直にWikipediaの「RAMアクセス時に発生するバグやセキュリティホールなどから保護されている状態のこと」でいいだろ。
Rust公式はなんて定義しているの?>>931は定義じゃないよな。 「定義」や「常識」「一般的に」の話とは別だが、このスレ見てる個人的印象だと、
Rustで宣伝商売したい人たちは、Rustを知らない人(意思決定者)が「メモリ安全性」を「優良誤認」(自己責任)するのを密かに期待してそう
Rustプログラマーはそうじゃないと言い切れるのか >>962
あんさんキチガイやな
それはRustの問題じゃない
>>939の説明が一番わかりやすいが言語全般における問題で原理的に解決できない問題やで >>925
今はしらんがrubyのgcも保守的gcだったよ。 >>934
じゃあなんで弱参照が用意されてるんですかねぇ? >>926の論法分析が的中してる
>>964
>言語全般における問題で原理的に解決できない問題やで
言語全般が「メモリ安全性」を宣伝してるって言ってる?
>原理的に解決できない問題
原理的もなにもRustプログラマーが常に:
>>919
>「メモリ安全*」
>*メモリリークを除きます。
>と注釈付
すれば良い >>962
メモリ安全性に循環参照によるメモリリークの抑止が含まれないことは認めてくれた感じかな?
Rustを使えば絶対安全とか言ってる人の言うことを信じるのは良くないよ
匿名掲示板の変な人の発言じゃなくてちやんとしたドキュメントを読んだ方が良い
Rustはメモリ安全性について独自の定義はしてなくて、Wikipediaに書かれているような意味でのメモリ安全性を保証するよ >>967
グローバルなキャッシュを実装するときなど、参照先のGCを妨げることなく長時間参照を持ち続ける必要がある場合に使用する
基本的にトレーシングGCで弱参照が必要になるのは極めてレアケース >>964
新しい藁人形連れてくんなよ。
最初から
Rustの問題は>>903で、本来なら
「メモリ安全*」
*メモリリークを除きます。
とちゃんと注意書きすべき
という主張。原理的に解決できるかどうかとか主張していない。
>>964の言うとおり、原理的に解決できないのに>>963を狙って「メモリ安全」と宣伝しているなら邪悪すぎるな。>>964は「Rust公式は邪悪」と言いたいのかな? なお、トレーシングGCにおいて循環強参照を避けることを目的に弱参照を使用することは全く何の意味もない
トレーシングGCのアルゴリズムを知っていれば循環強参照がGCのパフォーマンスやメモリ効率を悪化させることが無いのは明らかであるし、
弱参照の使用はレアケース故に概してあまり最適化されていないため、パフォーマンスは大抵の処理系においてむしろ悪化する GCあるほうが楽だと思うんだけど、スパイクの無いGCって実現できないの? >965
>Rubyよりは使われてるみたいだな
逆逆 Stackoverflowは精度がイマイチ
jetbrains
Ruby https://i.imgur.com/zqmf96u.png お一人様 7% ほとんどの人が仕事で使っている
Rust https://i.imgur.com/olB9F6L.png お一人様 86% ほとんどの人が個人の趣味 >>969
いや?全然。
循環参照によるメモリリークはメモリエラーだろ。メモリ安全「RAMアクセス時に発生するバグやセキュリティホールなどから保護されている状態」じゃない。
それにRustファンの言うことを信じているとか、冗談を言うのはやめてくれよ。気持ち悪いから。 >>972
え?
C#では循環参照を避けるためなどの目的で弱参照を使うけど
これは悪化させているとでも言いたいの? >>962
「どの言語でも基本的には、OOMキラーに殺される前にGCが走らせたり、手動でメモリーを解放できること」ができないと安全では無いんじゃないかな。なので環境依存よ。
そう、Rustを使えば安全では無い。 >>976
そんな事実はない
嘘だと思うならC#スレで聞いてきなさい 今回の件でGC言語がなぜ何倍も遅いのかよく分かった
世代別ガベージコレクションをするため頻繁にコピーGCを行なうことが遅くなる敗因の一つ >>973
昔、ハードウェア側でGCするJVM(?)があったような…。 >>973
RustはGC無いけど即座に自動的にメモリ解放されて楽だよ 俺の考えたGCが最強だけど、サブマリン特許やる予定だから教えない。 GC言語を使うと大して楽になるわけではないのに劇的に遅くなるからな
無能にはGC言語が向いている >>979
世代間GCのアリナシもそうだし、
>>927と同じく、言語と解決したい課題によるよ。 Java製アプリはオメガテーつこてるけど、遅いとか重いとか一切ない。
サクサク快適。
だがしかし、キャレットの位置が異常なのでテキストの選択がやりにくい。
この動作はJava GUIの仕様だが、仕様が間違っていると思う。
Windowsと同じ動作にするべき。 >>980 次スレ気づいてない 誰か代理 俺は無理 >>982
プログラマー指定せずとも自動的に参照カウントが使われる言語(PerlとかPythonとかSwiftなど)の場合はGCで合ってるよ
C++のshared_ptrやRustのRcのように特殊な用途のみにプログラマーが明示的に指定して使うものはGCとは呼ばれず単なるデータ管理構造 >>981
いつも出てくるこの自動解放されて楽って感覚がわからない。自動解放とか出来て当たり前じゃないの?
GCありと同等のルーズさが許されなら良いけれど、実際はメモリ管理を明確にさせられるよね。 >>989
Javaは遅い
少なくともC/C++/Rustなどの2倍~数倍は遅い
Javaは仮想マシンだしGCあるし遅くなるのは仕方ない お子様 → Python
おんな → Ruby
真の男 → Rust
こう言いたいのでは?
岡くんは。 >>993
ってことは、2~3倍遅くても何も問題ないってことだろ。 パイソンとかジャッカルには厨二を惹きつける響きがある。
女がなぜRubyを使いたがるのかはよく知らん。
岡くんがRust推しなのは本読んでわかった気になったから。 >>992
C並に高速なプログラミング言語では自動メモリ解放は普通は行われない
これは例えば新世代言語であるZigなどでも同じで手動メモリ解放となる
唯一の例外が常に自動的にメモリ解放されるRust このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 19日 7時間 35分 53秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。