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

**デフォルトの名無しさん** · 2022/08/29(月) 11:22:16.48

スレタイ以外の言語もok

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

**デフォルトの名無しさん** · 2022/09/05(月) 03:10:33.61

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

**デフォルトの名無しさん** · 2022/09/05(月) 03:31:45.52

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

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

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

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

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

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

**デフォルトの名無しさん** · 2022/09/05(月) 03:36:29.05

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

**デフォルトの名無しさん** · 2022/09/05(月) 06:42:39.68

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

**デフォルトの名無しさん** · 2022/09/05(月) 07:16:47.41

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

**デフォルトの名無しさん** · 2022/09/05(月) 07:22:08.46

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

**デフォルトの名無しさん** · 2022/09/05(月) 07:51:21.51

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

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

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

**デフォルトの名無しさん** · 2022/09/05(月) 08:33:46.56

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

**デフォルトの名無しさん** · 2022/09/05(月) 09:45:50.25

>>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でほぼ同じになるのはなんでなんでしょうか？

**デフォルトの名無しさん** · 2022/09/05(月) 09:57:13.85

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

**デフォルトの名無しさん** · 2022/09/05(月) 10:24:45.85

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

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

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

**デフォルトの名無しさん** · 2022/09/05(月) 12:00:09.73

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

**デフォルトの名無しさん** · 2022/09/05(月) 13:38:45.87

>>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で数を回せば観測される確かな差が生まれます。

**デフォルトの名無しさん** · 2022/09/05(月) 13:42:00.23

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の方は判りません。どなたか解説お願いします

**デフォルトの名無しさん** · 2022/09/05(月) 14:12:00.36

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

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

**デフォルトの名無しさん** · 2022/09/05(月) 15:11:00.05

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

**デフォルトの名無しさん** · 2022/09/05(月) 15:42:20.01

気軽にNGされると困る

**デフォルトの名無しさん** · 2022/09/05(月) 15:43:39.27

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

**デフォルトの名無しさん** · 2022/09/05(月) 16:07:08.66

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

**デフォルトの名無しさん** · 2022/09/05(月) 16:32:50.42

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

迷惑だよな

**デフォルトの名無しさん** · 2022/09/05(月) 18:31:27.51

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

**デフォルトの名無しさん** · 2022/09/05(月) 19:04:14.83

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

**デフォルトの名無しさん** · 2022/09/05(月) 19:05:51.22

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

**デフォルトの名無しさん** · 2022/09/05(月) 19:06:21.16

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

**デフォルトの名無しさん** · 2022/09/05(月) 19:08:02.01

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

**デフォルトの名無しさん** · 2022/09/05(月) 19:11:19.28

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

**デフォルトの名無しさん** · 2022/09/05(月) 19:12:38.64

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

**デフォルトの名無しさん** · 2022/09/05(月) 19:23:11.04

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

**デフォルトの名無しさん** · 2022/09/05(月) 19:28:42.10

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

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

**デフォルトの名無しさん** · 2022/09/05(月) 19:51:44.37

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

**デフォルトの名無しさん** · 2022/09/05(月) 19:55:18.42

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

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

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

**デフォルトの名無しさん** · 2022/09/05(月) 20:01:50.03

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

**デフォルトの名無しさん** · 2022/09/05(月) 20:04:19.99

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

**デフォルトの名無しさん** · 2022/09/05(月) 20:10:04.95

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

**デフォルトの名無しさん** · 2022/09/05(月) 20:13:42.10

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

**デフォルトの名無しさん** · 2022/09/05(月) 20:20:47.93

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

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

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

**デフォルトの名無しさん** · 2022/09/05(月) 20:25:02.75

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

**デフォルトの名無しさん** · 2022/09/05(月) 20:36:11.44

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

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

**デフォルトの名無しさん** · 2022/09/05(月) 20:50:10.83

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

**デフォルトの名無しさん** · 2022/09/05(月) 21:07:54.27

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

**デフォルトの名無しさん** · 2022/09/05(月) 21:25:09.81

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

**デフォルトの名無しさん** · 2022/09/05(月) 21:39:30.67

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

**デフォルトの名無しさん** · 2022/09/05(月) 21:58:07.88

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

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

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

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

**デフォルトの名無しさん** · 2022/09/05(月) 22:16:25.49

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

**デフォルトの名無しさん** · 2022/09/05(月) 22:16:42.44

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

**デフォルトの名無しさん** · 2022/09/05(月) 22:20:06.23

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

**デフォルトの名無しさん** · 2022/09/05(月) 22:33:58.90

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

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

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

**デフォルトの名無しさん** · 2022/09/05(月) 22:39:25.77

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

**デフォルトの名無しさん** · 2022/09/05(月) 22:43:52.15

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

**デフォルトの名無しさん** · 2022/09/05(月) 22:45:04.42

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

**デフォルトの名無しさん** · 2022/09/05(月) 22:49:48.10

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

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

**デフォルトの名無しさん** · 2022/09/05(月) 23:05:10.53

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

**デフォルトの名無しさん** · 2022/09/05(月) 23:11:05.60

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

**デフォルトの名無しさん** · 2022/09/05(月) 23:26:38.48

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

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

Arigatou

**デフォルトの名無しさん** · 2022/09/05(月) 23:26:43.28

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

**デフォルトの名無しさん** · 2022/09/05(月) 23:27:36.08

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

**デフォルトの名無しさん** · 2022/09/05(月) 23:31:48.82

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

**デフォルトの名無しさん** · 2022/09/05(月) 23:33:58.91

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

**デフォルトの名無しさん** · 2022/09/05(月) 23:36:58.16

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

**デフォルトの名無しさん** · 2022/09/05(月) 23:57:58.08

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

**デフォルトの名無しさん** · 2022/09/06(火) 00:00:31.26

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

**デフォルトの名無しさん** · 2022/09/06(火) 08:19:45.27

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

**デフォルトの名無しさん** · 2022/09/06(火) 09:44:45.25

>>322
Rubyのことなら同意

**デフォルトの名無しさん** · 2022/09/06(火) 09:47:23.91

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

**デフォルトの名無しさん** · 2022/09/06(火) 10:25:40.40

RustとRubyはほぼ同じや

**デフォルトの名無しさん** · 2022/09/06(火) 10:30:10.58

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

**デフォルトの名無しさん** · 2022/09/06(火) 10:33:00.76

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

**デフォルトの名無しさん** · 2022/09/06(火) 10:50:43.10

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

**デフォルトの名無しさん** · 2022/09/06(火) 10:54:20.03

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

**デフォルトの名無しさん** · 2022/09/06(火) 10:55:43.20

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

**デフォルトの名無しさん** · 2022/09/06(火) 11:22:14.85

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

**デフォルトの名無しさん** · 2022/09/06(火) 11:23:08.83

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

**デフォルトの名無しさん** · 2022/09/06(火) 11:38:16.60

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

**デフォルトの名無しさん** · 2022/09/06(火) 12:01:26.94

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

**デフォルトの名無しさん** · 2022/09/06(火) 12:04:20.22

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

**デフォルトの名無しさん** · 2022/09/06(火) 12:31:10.58

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

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

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

**デフォルトの名無しさん** · 2022/09/06(火) 12:45:16.87

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

**デフォルトの名無しさん** · 2022/09/06(火) 14:09:11.24

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

**デフォルトの名無しさん** · 2022/09/06(火) 14:13:42.45

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

**デフォルトの名無しさん** · 2022/09/06(火) 14:47:11.13

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

**デフォルトの名無しさん** · 2022/09/06(火) 14:57:13.57

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

**デフォルトの名無しさん** · 2022/09/06(火) 15:08:57.93

>>346
並列性がないというか、並列化しても元々の実行時間が短いからオーバーヘッドが大きすぎて割に合わないという話では
スパコンのジョブって短くても実行時間数十分だったりするから競プロとは前提が違う

**デフォルトの名無しさん** · 2022/09/06(火) 15:28:54.40

元々の問題設計がN^2で失格 NやNlogNオーダーで通るようなってるとしたら
N^2で並列化出来てもTLEだわ

**デフォルトの名無しさん** · 2022/09/06(火) 15:49:30.99

誰でも思いつくのはGCの並列化だが
GCは何言語で書かれているのかを誰も知らない

**デフォルトの名無しさん** · 2022/09/06(火) 17:20:08.41

コンパイル型の実行速度でスクリプトでも実行でき、コンパイルもできる言語が欲しい。反対を言えばbashのように
１行ずつ実行し、実行中で書き換えられることまでは必要ない。
単純なスカラーのループを書いたら、一台のCPUのレジスターだけをブン回す機械語のコードが生成されて欲しい。
A*Bと書くだけで千の計算を搭載されているメジャーなGPUで勝手に計算したり、あるいは千のマシンに分散して
実行して巨大な行列の積をポンと計算してもらいたい。
型だって必要ないなら指定したくない。もしポリモーフィックな関数が必要な時には、ジェネリックプログラミングを
使ってアルゴリズムを一度だけ書いて、あとは全ての型に使いたい。
ガーベージコレクション、あるいはメモリーマネージメントは循環参照や多重参照がなければRustのようにスコープを
抜けたら基本は消えるだけで十分でもあるが、循環参照をもったら自動でサイクリックGCも欲しい
並列化、あるいは非同期化に余計なコストを払いたくない、async/awaitなんてもってのほか論外、世紀の間違い。
ErlangやGoのようにspawnやGoで軽量プロセス起動は仕方ないにしても、これは必須ではなく、デコレーションで
あって並列ではなくとも動ける控えめなヒント情報であってほしい
ドライバ、あるいはOSやカーネルなどのハードウェアよりな開発にも利用できてほしいけど、例外あるいはpanicも欲しい

**デフォルトの名無しさん** · 2022/09/06(火) 18:45:34.78

Amazonの言うこと信じる人もいるんだ。
そりゃ霊感商法もなくならないわ。

**デフォルトの名無しさん** · 2022/09/06(火) 18:50:05.82

GCしないでプロセスごと捨てるのがスマートよ

**デフォルトの名無しさん** · 2022/09/06(火) 20:47:28.58

>>321
https://nim-lang-081.osdn.jp/docs/tut1.html
> # 前方宣言:
> proc even(n: int): bool

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

> プロシージャで呼び出し元の引数を変更する必要があるならば、 var パラメータを使います。
> proc divmod(a, b: int; res, remainder: var int) =

パスカルのVariable parameterっぽいなこれ
ちなパスカルだと

https://wiki.freepascal.org/Variable_parameter
> procedure xorSwap(var left, right: integer);

こっち側にvarを書く

**デフォルトの名無しさん** · 2022/09/06(火) 21:02:15.19

>>355
immutableかmutableかの区別宣言は絶対に必要だから
あとは各言語でそれをどのように表現するかだけでしょ
それをvar val let const など各言語で色んな表現の使い分けがあり更に引数でどうするかだけ
>>241のケースも考慮するとRustのmut付加方式がベストな解決かな

**デフォルトの名無しさん** · 2022/09/06(火) 21:05:47.04

ん？
パラメータのいわゆる参照渡しの話なんだけどな

**デフォルトの名無しさん** · 2022/09/06(火) 21:17:25.60

ponylangだとbehaviorが終わるごとに該当アクターでGCを回すからプログラムとしては停止しないんだけども、これを並列GCですって言うのもなんだかなといった風情

**デフォルトの名無しさん** · 2022/09/06(火) 21:21:35.81

>>355
>>357

何が ? なのかも少し詳しく

**デフォルトの名無しさん** · 2022/09/06(火) 21:31:19.57

MPIバリバリ使ってるけど競プロの問題を解くようなタスクでは使わないよ
課題設定があまりにも違い過ぎる

**デフォルトの名無しさん** · 2022/09/06(火) 21:37:52.05

>>357
Rustはその2種類の区別もmutの位置で区別できてるね

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

➁引数が参照渡しで来て関数内で参照元を書き換える場合
例: fn func2(x: &mut i32) { …
　→可変参照渡しなので呼び出し元の対象は書き換わりうる

**デフォルトの名無しさん** · 2022/09/06(火) 22:22:04.19

あんた上手に振る舞えって言われてたやつだろ
Rustは出来るじゃねえよw 当たり前だ
お前が議論を理解出来てなかっただけだろ
そういうところが周りをイラつかせてるんだぜ

**デフォルトの名無しさん** · 2022/09/06(火) 22:30:02.86

>>361
> Rustはその2種類の区別もmutの位置で区別できてるね

二種類の区別？

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

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

>>359
Nimの参照渡しの表現に見覚えあるわってレスしただけなんよ俺はｗ

**デフォルトの名無しさん** · 2022/09/06(火) 22:34:57.09

Rustだと両方ができて当たり前だが
プログラミング言語の中には
値を渡すか参照を渡すかをプログラマーが選べない言語も意外と多い
全てがどちらかに決められていたり
型によって各々どちらかに決められたり
メジャーな言語でも制限があったりする

**デフォルトの名無しさん** · 2022/09/06(火) 22:40:49.84

>>363
Rustは2種類の参照渡しがある
Tを参照元の型とすると
&T が(可変じゃない)参照
&mut T が可変参照
だから貴方が書いた>>355の話と同じじゃないかな

**デフォルトの名無しさん** · 2022/09/06(火) 22:43:24.65

>>362 >>364 本当だ自分の勘違いを棚に上げている

**デフォルトの名無しさん** · 2022/09/06(火) 22:44:16.65

パスカル書いてた人なら
「パスカルなついｗ　引数んとこにvarって書いてたなｗ」
で終わる話
皆の衆なんか混乱させてすまんかったな(´・ω・｀)

**デフォルトの名無しさん** · 2022/09/06(火) 22:47:53.44

上手いね見習いたまえ