次世代言語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/04(日) 19:29:23.15

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

**デフォルトの名無しさん** · 2022/09/04(日) 19:44:58.67

>>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をできる限り少なくするのがプログラミングのコツ

**デフォルトの名無しさん** · 2022/09/04(日) 20:00:50.97

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

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

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

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

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

**デフォルトの名無しさん** · 2022/09/04(日) 22:29:03.84

>>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は注視すべきポイントとなる

**デフォルトの名無しさん** · 2022/09/04(日) 23:03:51.17

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

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

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

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

**デフォルトの名無しさん** · 2022/09/04(日) 23:23:22.66

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

**デフォルトの名無しさん** · 2022/09/04(日) 23:56:45.66

>>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
}
もちろん最適化によりアクセス時のインデックス境界チェックは無くなります

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

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

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

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

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

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

アンダースタンド？ｗ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

**デフォルトの名無しさん** · 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
そもそも地獄レベルの問題を処理する競技が流行ってるので