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

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

スレタイ以外の言語もok

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

**デフォルトの名無しさん** · 2022/09/25(日) 19:33:28.70

>>450
次世代言語は遅いくせにメモリー食いすぎだな。

**デフォルトの名無しさん** · 2022/09/25(日) 19:34:35.56

>>456
5chでRustやRubyが叩かれるのは理由があるからな。

**デフォルトの名無しさん** · 2022/09/25(日) 19:41:23.81

RubyはガイジのせいだけどRustにもガイジがいるの？

**デフォルトの名無しさん** · 2022/09/25(日) 19:45:35.90

>>459
熱心なアンチをここでよく見かけるｗ

**デフォルトの名無しさん** · 2022/09/25(日) 20:30:28.24

実装で特別なことはしてないが「競プロ的視点」という事で:

Language x10 x100 x200 x400 Memory Comment
--------------------------------------------------------------
Zig 0.118 1.073 2.113 4.203 3.2MB (std.HashMap + "caller hash" by Context(std.hash.Fnv1a_64.hash))
Zig 0.162 1.493 2.970 5.935 4.6MB (std.StringHashMap)

zig version 0.10.0-dev.4166+cae76d829
CPU Zen3@boost max~4.75GHz

Faster than C になってる(Cはまだまだ最適化の余地があると思うが)

**デフォルトの名無しさん** · 2022/09/25(日) 20:40:28.94

バカだな
言語間で異なるアルゴリズムを使っていたら
それは言語の比較ではなくアルゴリズムの比較だ

**デフォルトの名無しさん** · 2022/09/25(日) 20:45:11.70

実際に速くても、RustよりZigのほうが速い証明にならんのか？

**デフォルトの名無しさん** · 2022/09/25(日) 20:51:08.64

ZigもRustもコードを合わせればほぼ同じLLVMコードを吐いてほぼ同じ結果になるやろな
無論Clang使用したCも

**デフォルトの名無しさん** · 2022/09/25(日) 21:20:01.75

叩かれる側に原因があるっていうのはアフォーダンス
物を売りつければ、買う側に原因があるという
ちょうど猫が入りそうな箱に猫を入れたら、箱に原因があるという

**デフォルトの名無しさん** · 2022/09/25(日) 21:45:37.43

おーいつもやつ帰ってきたか
寂しかったぞ
三連休どこに消えてたんだ
家族サービスでもしてたか？
書き込み減って悲しかったぞ

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

C言語へのトランスレート自体は悪くない。
でもマイナー言語でリソース足りないのに色んな言語へのトランスレートをやろうとするのは無理すぎ。

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

>>467
> 色んな言語へのトランスレートをやろうとするのは無理すぎ。
そんな言語あるの？

**デフォルトの名無しさん** · 2022/09/26(月) 12:30:23.28

JVM 系言語が Kotlin Native, Scale.js, GraalVM あたりで JVM 以外に色気出すのは筋悪いと思うね。

そこに魅力を感じる層は結局自分が今習得しているツールに縛られた技術選定しかできない人々という意味でも、発展性がない。

**デフォルトの名無しさん** · 2022/09/26(月) 14:29:10.13

>>469
視野が狭い末端プログラマーらしい意見だね。

君は結局自分が今置かれた立場に縛られた物事の見方しかできない人という意味でも、発展性がない。

**デフォルトの名無しさん** · 2022/09/26(月) 14:40:41.23

>>453
nlvmというトランスレーターではないllvm IRを直接吐き出す実装があるんだわ。もちろん、公式じゃないし
こんな事する意味があまりないから全然流行ってないけど、上のほうで暴れてたLLVM=Rust信者だって
もともとはRustだってOCamlで書かれた最初のコンパイラを辞めて、LLVMのセルフホストになった。
そこにコンパイラ基盤がLLVMだから良いとか・優秀だという考えはない、単にコンパイルを速くしたかったか
開発リソースを集中させたかっただけ。現にgccrsはllvmだと宜しくない場合があるから作られてるわけで

言語へのトランスレートが無理なんじゃなく、作者は開発コスト問題から数多ある無数のCコンパイラへ対応は
辞めたがってるけど、それだってマイナーなTiny C/tccがC標準から少し逸脱してるから辞めたいだけ

**デフォルトの名無しさん** · 2022/09/26(月) 14:41:03.61

暇なんか

**デフォルトの名無しさん** · 2022/09/26(月) 14:46:16.26

暇なんや、ごめん。。。

**デフォルトの名無しさん** · 2022/09/26(月) 14:51:59.22

>>469
根拠を示していないから、ただの誹謗中傷にしかなっていない。
煽るにしても、もうちょっとそれらしい主張にしたら？
例えば「JVM系の言語はだらしなくヒープを使うからネイティブにしても速くならない。そんなのをやるんだったら、安全性と速さを両立したRustを勉強したほうがいい」とか。

**デフォルトの名無しさん** · 2022/09/26(月) 16:55:54.26

ruby は ruby で実装されています
遅くなる罠

**デフォルトの名無しさん** · 2022/09/26(月) 17:38:57.35

>>471
LLVMなんてどこでも使っているのに
LLVMというだけでRust信者と思い込むのは浅はか
なんでもかんでもRustにもって来たがるのはアンチの悪い癖

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

>>469
JVM言語の唯一のメリットであるポータブルな点は当時と比べて重要度を失っているんじゃないかな
もちろんポータブル自体は有利だけどJVMよりもっと様々な必要や要素を兼ね備えたWASMの出現が大きかったね
後発だから色んな改善がされているのは当たり前だけどWASM＞JVMであることは否定しようがないもんね

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

https://github.com/benhoyt/countwords

Language x10 x100 x200 x400 Memory Comment
--------------------------------------------------------------
Zig 0.118 1.073 2.113 4.203 3.2MB (std.HashMap + "caller hash" by Context(std.hash.Fnv1a_64.hash))
C(gcc) 0.136 1.146 2.271 4.531 2.0MB (optimized.c, binIO,jemalloc,O4,LTO) NEW
C(clang/LLVM) 0.137 1.147 2.280 4.544 2.0MB (optimized.c, binIO,jemalloc,O3,LTO) NEW
Go 0.177 1.412 2.733 5.446 3.8MB (caller hash)<--from過去スレ
Rust(LLVM) 0.154 1.425 2.838 5.674 2.6MB (optimized-customhashmap,O3,LTO,caller-hash) NEW

以下、caller-hashではない
Zig 0.162 1.493 2.970 5.935 4.6MB (std.StringHashMap)
Rust(LLVM) 0.214 1.725 3.396 6.715 3.5MB (optimized,fxhash,O3,LTO) NEW

zig version 0.10.0-dev.4166+cae76d829
gcc 12.2.0/clang 15.0.0
rustc 1.64.0 (a55dd71d5 2022-09-19)
CPU Zen3@boost max~4.75GHz

Go Ryzen9 5900X windows11 <-- Boost Clock. Up to 4.8GHz.?

Rust(optimized-customhashmap)はC(optimized.c)と「コードを合わせ」てあるはずだが、コンパイルオプション程度の「簡単」な工夫を試した限りではgcc/clangと「ほぼ同じ結果にはならなかった」

「コードを合わせたRust」がCと比べて「2~3割程度遅い」のは「そういう場合もあるよね」で驚きも失望もない

意外なのは過去スレGoがRustと同水準だ(起動時間0.03s程度以外むしろGoの方が速い)という事。(こちらで再現したわけではない)

**デフォルトの名無しさん** · 2022/09/26(月) 21:18:14.74

またキチガイが粘着にデマを蒸し返してるのか
RustがC/C++と同等の速さで動くことは世界中で様々なケースで確認済み
今は次の段階へ進んでいて新たなシステム構築からRustへ置き換わって行ってる

**デフォルトの名無しさん** · 2022/09/26(月) 21:28:58.87

Rustはコードがスパゲッティになっちゃうから
その分遅くなる可能性あるよね
スパゲッティにならなきゃＣと同等だよ

**デフォルトの名無しさん** · 2022/09/26(月) 21:31:40.65

>>479
さすがにそりゃ無理だろ。

**デフォルトの名無しさん** · 2022/09/26(月) 21:46:52.90

>>480
Rustで書くと素直な整理されたデータ構造に改善する方へ寄せられていくから
スパゲティにはならずむしろスパゲティ解消のメンテしやすい良いコードになってしまいますね

**デフォルトの名無しさん** · 2022/09/26(月) 21:52:22.11

保守性の悪いスパゲッティなコードを書く人がRustを嫌っているのはそこだな
Rustだといつもの汚い思い通りのコードが書けないからイライラするのだろう

**デフォルトの名無しさん** · 2022/09/26(月) 22:14:45.96

Rustスレで自己満クソコードをいっぱい貼った子がおってなｗ
あれたぶん自分ではきれいな非スパゲッティコードだと思ってるんやろな

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

>>484
最近Rustスレ見ているけどそんなの見たことないな
別の言語の話なのかな

**デフォルトの名無しさん** · 2022/09/26(月) 22:36:11.87

汚コーダーこと複オジ必死ww

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

Rustはある種のBDUFを強制するから良い場合もあれば良くない場合もある

**デフォルトの名無しさん** · 2022/09/26(月) 22:52:31.71

具体的にその汚いコードというのを見てみたい
もし本当にあるならば

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

自分ではキレイと思ってるから自分では自信があったのかなｗ
スレ住民にクソコード貼るなって言われても意固地になってたよｗ
その流れを再放送するなら無意味だよね
聞く耳持たないだけだから

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

仕様をよっぽど気に入らない限りコードなんて見なければいい
仕様が憎ければコードまで汚く見える

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

スパゲティコード見せて
Rustで見かけたことないので興味ある

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

>>489
「ママー、きょうこんなコードかいたんだよ、みてみてー」ってノリだったから汚いかどうかは眼中になかったんだろ

気持ち悪いおっさんが幼稚園児メンタルで汚コードを一日中貼り続けるからマジキモかったけどな

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

>>491
・>>1から過去スレをたどっていくことができない情弱
・酷評されたコードを汚くないと再反駁するためのネタ振り

どっち？

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

再放送になるだけだから相手しちゃダメよ

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

スパゲッティな汚いコードが貼られているスレどこよ？

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

昔はgotoだらけの制御が絡み合って個々に分解しにくいコードを指してスパゲティと呼んだものだが
今時そんなgotoだらけのコードはないだろうから、どんなコードを指してスパゲティと呼んだのか興味はある。

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

コードを示せない上にスレも示せないって、スパコードが実在しないんじゃね

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

きれい
a + (b + c) = (a + b) + c

汚い
(= (+ a (+ b c)) (+ (+ a b) c))

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

Rustでスパゲッテイなコードは起きないだろうから
>>484がRustを叩きたくて嘘をついていて引くに引けなくなっただけだと思うよ

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

最初から「Rustスレ」でって書いてあるじゃん
ディープコピーすら知らなかった複オジの黒歴史を見てこいよw

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

>>500
本人だから相手しちゃダメ
また汚コードペタペタされるぞ

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

Rustスレもいつも眺めているがスパゲティコードらしきものを見たことないな
そもそもRustでスパゲッティコードというものが想像つかん

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

急に必死じゃん
ウケる

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

結局Rustアンチの人による妄想なの？
次世代言語でのスパゲッティ見てみたかった

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

言語のアンチをしている時点で異常者だから

**デフォルトの名無しさん** · 2022/09/27(火) 07:43:25.27

>>482
「改善する方向に誘導」は嘘。
マズそうなデータ構造で助言してくれるわけじゃない。
実際は「煮詰まってきたときにコンパイルが拒否する」が正解。Rustはにっちもさっちもいかなくなってから「これはダメ」と放り投げる。

**デフォルトの名無しさん** · 2022/09/27(火) 09:16:32.53

テスト駆動によれば、テストが通らない状態から始めるように誘導しなければ
改善へ誘導したと言えなくなる

**デフォルトの名無しさん** · 2022/09/27(火) 09:41:06.42

Rustが叩かれてるというよりは単に複オジが叩かれてるだけなんだがｗ
このへんの区別がつかない人と話になる？ｗ

**デフォルトの名無しさん** · 2022/09/27(火) 11:19:43.94

このスレはなぜJuliaの話題が無いのか
単純な計算やループだとRustのようにCと同等のネイティブコードで実行でき簡単に並列化・分散化してスケールする。
行列を標準で扱え、コンパイルも出来てスクリプト言語のように手軽にcliで実行できる。面倒な型は普通に型推論だが
逆行する推論を備え、それによってコンパイル言語でありえない動的さと、Lispのような真のマクロを備える
それともどこかにある最適な実装を、シコシコとオレ様実装してしまう泥臭く真の漢のシステムプログラマーばかりなのか

**デフォルトの名無しさん** · 2022/09/27(火) 11:26:01.22

>>509
汎用言語じゃないから

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

>>509
その単純な計算やループはたまにしか使わない
JuliaはGC言語なのにヒープメモリをできる限り少なくするプログラミングをプログラマーがしなければいけない
そのへんに気を使わずプログラムを作ると速さに大きな差が出る
つまりメモリ管理は気にせず言語に任せておけばいいという言語じゃない
なのにガベージコレクションが発生する

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

>>509
今時数値計算をCPUでやるおじさんは老害

**デフォルトの名無しさん** · 2022/09/27(火) 12:51:08.64

Juliaは多重ディスパッチでデータ型とアルゴリズム実装を自由に組み合わせられるみたいなのが売りの一つだと思うけど
ちゃんとテストされてない組み合わせだと簡単に計算結果を間違うという指摘が結構あって
数値計算向けの言語としては致命的なんではないかなぁと思っている

**デフォルトの名無しさん** · 2022/09/27(火) 13:19:39.57

カリー化の要領で単一ディスパッチに帰着するパターンの正式名称が致命的だった

**デフォルトの名無しさん** · 2022/09/27(火) 15:29:16.37

>>511
本当に触ったことありますか？どんな言語だとしても、ループ内でのヒープメモリ割り当てなんて気を付けて書く。
それはRustだって同じ事、GCというかスコープを外れたらOSが回収するが、決してメモリーを気にしないような
プログラミングなんてしない、これはGoでもJavaでも同じ。これを気にしない人はカッコ付けて再帰呼び出しを
してみたりスタックさえ気にしない人が稀にいる
本当に言いたいことを最後に書く日本人の典型だと思うが、そりゃGCはGC系なので発生するでしょうね

>>512
いまどきならCUDA.jlやAMDGPU.jlというものがある。だがRustだとかGoだとかもGPUを普通は使ったりしない。
前者は標準の高階関数で悦に入ってるのがその証拠であり、後者は多数のgoroutineで疑似パラレル処理を
するわけだが稀にGPUを使うとしても特殊例に過ぎない

>>513
そりゃテストされてない組み合わせなんてまともに動くほうが稀だとおもうけど。Rustでいえば少し昔のactixを
async-stdで動かすようなもんだろう、動的呼び出しのコストを気にして、動的性がほとんどないRustやGoと
比べるのが違うんだろうと思うが、letだのvarだの書かないのは、型推測の究極系からいうとありだと思う。
パターンマッチングもあるし、ライバルはRustとかじゃなく、PythonのDeepleaning系やＲなんだろうと思うが

**デフォルトの名無しさん** · 2022/09/27(火) 15:42:59.62

めっちゃw早口で言ってそうw

**デフォルトの名無しさん** · 2022/09/27(火) 16:39:12.74

>>515
> どんな言語だとしても、ループ内でのヒープメモリ割り当てなんて気を付けて書く。

多くのGC言語では、そんなことを気にせずGC任せのプログラマーが多数派だと思います

> GCというかスコープを外れたらOSが回収するが、

ありえません

**デフォルトの名無しさん** · 2022/09/27(火) 18:30:42.66

Rustみたいなバリバリの実用土方向け言語と比べるのは間違い。

**デフォルトの名無しさん** · 2022/09/27(火) 18:38:52.09

>>515
必死で笑った

**デフォルトの名無しさん** · 2022/09/27(火) 18:56:17.56

>>515
本当まで読んだ

**デフォルトの名無しさん** · 2022/09/27(火) 19:10:24.11

>>518
え？ほとんど誰も使ってないんだけど

**デフォルトの名無しさん** · 2022/09/27(火) 19:50:43.74

>>518
Rustは管理部門がコーダーに押し付けたい言語。
社員監視用にマナー講師を雇うようなもんだ。

**デフォルトの名無しさん** · 2022/09/27(火) 20:02:47.05

>>522
このまえはRustを趣味で使われる割合が多いと叩いていたのに叩く方針変更かね
Rustはプログラマーに愛されているプログラミング言語7年連続1位と記事が出ているけどどうするのかね

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

>>515
各組み合わせごとに厳密にテストしないと組み合わせられないなら
「多重ディスパッチで簡単に組み合わせられます」とか言うなよってこと
そもそも静的型ならコンパイルエラーになるしPythonとかなら巨大なライブラリにみんなで乗っかる方式だから、組み合わせの問題が発生しやすいのはJulia固有の話

**デフォルトの名無しさん** · 2022/09/27(火) 20:13:06.18

>>523
今までも同じ主張しかしとらんよ。
これからは他人のために使うRustユーザーが増えていくから、愛され言語１位を維持するのは無理だろ。
PythonとかJavaの規模のなっても維持できているなら本物だな。

**デフォルトの名無しさん** · 2022/09/27(火) 20:18:14.18

Rustは他の言語よりコーティングしやすいしプログラマーにとっては嬉しい言語っす

**デフォルトの名無しさん** · 2022/09/27(火) 20:49:24.20

1から自分で好きなように書くならRustは気持ち良い言語なのは同意するけどね
Rustは個人の好みや癖が出やすい言語だから、他人のオナニーの後片付けは辛いぞ
Rubyしかり、創意工夫()の余地が大きくて楽しい()言語はレガシー化すると激しくプログラマに嫌われる傾向がある

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

>>527
プログラミングしたことのない人には
RubyとRustは創意工夫の余地があって辛くて
他の言語には創意工夫の余地がないように見えているのか
そんなデタラメ書き散らす前にプログラミング経験積んで出直してこい

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

Go追加>>478(>>450,461)
Language x10 x100 x200 x400 Memory Comment
--------------------------------------------------------------
Zig 0.118 1.073 2.113 4.203 3.2MB (std.HashMap, caller hash by Context(Fnv1a_64))
C(gcc) 0.136 1.146 2.271 4.531 2.0MB (optimized.c, binIO,jemalloc,O4,LTO)
C(clang/LLVM) 0.137 1.147 2.280 4.544 2.0MB (optimized.c, binIO,jemalloc,O3,LTO)
Go 0.152 1.233 2.428 4.832 3.9MB (caller hash,better loop) New
Go 0.164 1.346 2.654 5.279 3.8MB (caller hash)手元再現 New
Go 0.177 1.412 2.733 5.446 3.8MB (caller hash)<--参考値from過去スレ
Rust(LLVM) 0.154 1.425 2.838 5.674 2.6MB (optimized-customhashmap,O3,LTO,caller-hash)

以下、caller-hashではない
Go 0.085 0.366 0.693 1.319 61.9MB (parallel.go,reserve 65536/2)<--マルチスレッド New
Zig 0.162 1.493 2.970 5.935 4.6MB (std.StringHashMap)
Go 0.182 1.563 3.063 6.097 3.8MB (customhash.go,reserve 65536) New
Rust(LLVM) 0.214 1.725 3.396 6.715 3.5MB (optimized,fxhash,O3,LTO)

zig version 0.10.0-dev.4166+cae76d829
gcc 12.2.0/clang 15.0.0
go version go1.19.1
rustc 1.64.0 (a55dd71d5 2022-09-19)
CPU Zen3@boost max~4.75GHz

https://github.com/benhoyt/countwords

予想以上にGoが速かったが、最近の成果かもしれない。
https://go.dev/blog/go1.19 (2 August 2022)
>Go 1.19 includes a wide variety of performance and implementation improvements

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

アルゴリズムの比較と言語の比較の区別がつかない人が未だに無意味なことを続けてるな～

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

>>522
なるほど

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

社畜タイムだな

**デフォルトの名無しさん** · 2022/09/27(火) 23:25:50.78

>>522
そんなホワイト企業があるなら名前教えてくれよ

**デフォルトの名無しさん** · 2022/09/28(水) 11:39:35.28

くせぇ、くせぇ、泥だらけ漢だらけで土方臭え！forループじゃなくmap使えとか親方ァは細かすぎる・・・
何がワシだって「下積みの頃はC未定義動作で行間を読んだもんだ！」だ！未定義動作書くなよ！？基本だろうが！＃
何が「ここは大手の偉い人が書いたから変えらなかったんだよ！」だ！
Displayトレイトが滅多に表示しない方に使ってて頻繁に表示する方はいちいちdisp_xxxなんて呼ばないといけないんだ！
設計根本から間違ってるだろうが！
「Rustは気持ち良い言語、Rustは気持ちよく書ける」なんて2020年代前半に言われてたらしいが、もう憎しみしかない
お百度参りしても、この恨み晴れるとは思えない
オレこのデスマが終わったら、高給取りのAIのPython業界に転職するんだ・・・

**デフォルトの名無しさん** · 2022/09/28(水) 12:04:48.31

>>534
ことごとく勘違いしてるでしょ？

mapは単なる写像にすぎなくてループと対応するものではなくループの中の写像の文 let y = f(x); に対応するものです

未定義動作はunsafeを使わない限り発生しません

disp_xxxといったものは標準ライブラリにありません

以上から貴方はRustではなく異なる別のものを使っている可能性が高いです

**デフォルトの名無しさん** · 2022/09/28(水) 13:39:09.80

顔真っ赤で一行開け必死で笑ったｗｗｗキモッｗ

**デフォルトの名無しさん** · 2022/09/28(水) 18:08:24.66

rustは、haskellみたいにはならないと思う。
ロマンが足りない。オナニーしても気持ち良くない的な。
その点、juliaの方がロマン感じる。

**デフォルトの名無しさん** · 2022/09/28(水) 18:19:46.86

rustは十分ロマンがあるよ

**デフォルトの名無しさん** · 2022/09/28(水) 19:06:02.54

嫌いなのはわかるけど消去法でもRust一択だよ
まずスクリプト言語は速度と安全性がゴミなので論外
(書き捨てのスクリプトにのみ使うならアリ)

C/C++は論外
世界中のバグはこの言語から生まれている

JavaやC#もぬるぽ排除失敗
副作用まみれを助長する言語仕様
クソ重GCとJVM運用でオワコン

Goも結局ジェネリクス導入の失敗で標準ライブラリがジェネリクスなしの涙目に
安全性とは程遠い
言語仕様も一部よくわからない謎
さらにゴルーチンの書きにくさで並行処理の言語としても微妙

その他のモダン言語は結局本質的解決にはなってないから論外

よってRust一択

**デフォルトの名無しさん** · 2022/09/28(水) 19:10:09.32

>>539
Goはnil安全性すらないから前世紀の言語っぽい

**デフォルトの名無しさん** · 2022/09/28(水) 19:15:39.85

Goは色んな機能を削りすぎていて苦痛
ジェネリック導入で明るい未来を期待していたけどあんな使えない仕様になるとは

**デフォルトの名無しさん** · 2022/09/28(水) 19:17:23.82

>>540
あーそれもあるか
err != nilには笑ったわ
なんかエディタのスニペットに登録してるから問題ないらしい

**デフォルトの名無しさん** · 2022/09/28(水) 19:20:37.46

正直NULL安全みたいな機能いるか？
Kotlinとかにもあるけど、結局NULL許容型も書けるし中途半端過ぎる

**デフォルトの名無しさん** · 2022/09/28(水) 19:21:11.66

>>539
Rustは絶壁の学習曲線で多数の初学者が挫折し、エンスー以外使えないエンドコンテンツで終わるだろう。

せめてライブラリとかフレームワークを初心者向けに作り込むことができればまだ可能性はあるが、所有権とライフタイムがラフな使い方を拒否するからそういうことも困難。

まぁ、「３番目に学習する言語」くらいの位置になれれば万々歳だな。

**デフォルトの名無しさん** · 2022/09/28(水) 19:25:13.91

>>543
関数型界隈以外ではその重要性に気がついてなかった
いわゆるシステムプログラミング言語でRustが唯一まともにNULL安全性を持って生まれた言語

**デフォルトの名無しさん** · 2022/09/28(水) 19:30:16.66

>>544
初心者が挫折しがちというのは理解できるのだが
(俺自身C/C++のヘビーユーザーだったが最初はコンパイルを通すのに苦労した)
しかし一旦理解するとコンパイルエラーはほぼ起きないし
Rustの気持ちになって考えることができるようになる
本当にコンパイラの気持ちがわかる

**デフォルトの名無しさん** · 2022/09/28(水) 19:40:17.57

>>543
Javaのヌルポは散々馬鹿にされていたからなぁ。
実際には、正常値としてのNullならnull objectの方が素性が良い。optionalみたいなNullが良いのは、異質なケースとして明示的に処理したい場合のみ。

**デフォルトの名無しさん** · 2022/09/28(水) 19:43:30.85

>>546
その「一旦理解する」というのが絶壁だっつうの。

**デフォルトの名無しさん** · 2022/09/28(水) 19:43:33.10

データ構造含めてスパゲッティでも動いてくれるGC言語と
データ構造が整理されていないとコンパイラが通ってくれないRust
保守性の良いコードを強制してくるRustはウザいよな

**デフォルトの名無しさん** · 2022/09/28(水) 19:51:26.79

>>547
ポインタであろうとデータであろうと
nullやnilなどはその型と全く別の型であるべきであり
型が異なればコンパイルエラーとすることができるため
nullやnilをうっかり使ってしまう悲劇を確実に回避できる
この仕組みを備えることをnull安全性と言う

**デフォルトの名無しさん** · 2022/09/28(水) 20:06:25.79

>>543
kotlinは割りとバランスいいと思う。
Option<T> みたいな冗長な型にならず T? で済ませてるから。
Rust はそこはちょっとダルい。

**デフォルトの名無しさん** · 2022/09/28(水) 20:27:35.31

はぁ？w

**デフォルトの名無しさん** · 2022/09/28(水) 20:37:57.86

>>539
そんな優等生な実用性は求めてないんだよ。

次世代なら、超すごいGCとかなんでも推論してハマればすごいけれど外れるとクソみたいなのをやってくれよ。

**デフォルトの名無しさん** · 2022/09/28(水) 21:50:06.42

>>553
その辺はcopilotなど最新のAIの分野だと思われる
モダン言語としてはまず言語仕様をしっかり安全性の高いものにするのが大事
それに俺はヤンキーを否定してるわけではない
pythonとかライブラリの充実度は世界一だろうし
雑なツールを作るには一番早くできるだろう
TypeScriptもスクリプト言語の型システムとしてはよくできている
しかしその手の言語を最初に使っても結局そのスクリプトを人がどんどん改造してスパゲッティになる様子を見てきた
スクリプト言語である程度実装可能なことがわかったら
すぐにRustに切り替えるべき

**デフォルトの名無しさん** · 2022/09/28(水) 22:09:10.05

>>548
C/C++を理解していないと難しいとは思う
所有権の移動はあらゆる変数参照で起きうるから
ひとまず借用しまくること
Rustの借用はコンパイルが通る限り安全なのだ
所有権を移動しない
これで既存の言語のように書けるのではないかな

**デフォルトの名無しさん** · 2022/09/28(水) 22:56:28.26

>>555
move不要説って、RefCellで複雑なことやろうとするでしょ

Cellでreplaceしまくったほうが簡単だよ