次世代言語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/24(土) 15:22:13.06

最近はClangが賢いしLLVM方式は多言語をサポートできて有利だな
技術力のない次世代言語はLLVMコードを吐かずにCコードを吐いて最適化の機会を失っている

**デフォルトの名無しさん** · 2022/09/24(土) 15:50:34.59

勝利条件が間違っているのでチャンスを与えても無視されているケースもあるけど

**デフォルトの名無しさん** · 2022/09/24(土) 20:26:26.19

>>409
Nimですね

**デフォルトの名無しさん** · 2022/09/24(土) 22:56:21.99

Rust普通にfor文回すだけでもコンパイルエラーになって草
なんだこの言語は

**デフォルトの名無しさん** · 2022/09/24(土) 23:12:05.67

複数のCコンパイラ(gcc, g++, clang, vc, intel c++, tccなどなど)に対応するより、1つのほうが楽だからそうしてるだけで
技術力がない訳じゃないんだわ。アホ信者だろうからどうでもええけど

**デフォルトの名無しさん** · 2022/09/24(土) 23:20:12.97

>>409
そのLLVMはC++で作られてるわけで

**デフォルトの名無しさん** · 2022/09/24(土) 23:39:17.14

ある言語などの処理系がどの言語で書かれているかは全く無関係
例えばPythonで書かれていても動作が遅くなるだけで問題なく動く

そしてLLVMの出現時期がたまたま既にC++が標準化され普及した直後だったからC++で作られただけの話
もっと以前ならCで書かれただろうし現在開始のプロジェクトならRustで書かれただろう

**デフォルトの名無しさん** · 2022/09/24(土) 23:53:07.05

Rustブームの次はLLVMを教えてくれるのか
乗るしかない知の高速道路に

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

LLVM相当をRustで実装とかもう誰かやってそう

**デフォルトの名無しさん** · 2022/09/25(日) 01:46:08.85

>>413
様々なコンパイラに対応するという目標からして間違っているよ
本来の目標は様々なアーキテクチャに対応することだね
その目標を達成するための様々な方法の一つとしてCに変換する方法があるけど
LLVMに変換する方法と比べてCに変換する方法は様々な点で劣ってしまうね

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

gccとllvm、違いを述べてみよ

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

GNUとApple。

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

>>419
各プログラミング言語とも各アーキテクチャとも独立した中間コードにあたる命令セットと型システムを持つLLVMでは
各言語のコンパイラはその命令セットによるLLVM中間コードを吐くだけで
LLVMが一般的な最適化と各アーキテクチャに対する最適化を行なって最終コード生成をしてくれる
GCCは時代遅れのシステム設計なのでそのへんが上手く行っていない

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

何事にも優劣を付けたがる人

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

GCCのRTLも知らない知ったかなんて相手するなよ

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

まぁgccも3くらいの頃はRTLがあるとはいえ結構密結合していて改造するのも大変だった記憶
4以降くらいで中間表現がちゃんとなって今はLLVMと変わらないんじゃないかな
どちらかというとライセンスの問題のほうが違いとしては大きいかもね

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

RTLはあくまでもGCCによるGCCフロントのための内部の存在から脱しきれていない
LLVMのように外部の独立した主体が中間コードを生成しても使える状況には程遠い

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

パーツ化するのをrmsが反対してたのが
大きいんじゃないの？

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

>>425
もしかして GCC = GNU C Compiler って思ってるおじいちゃんなのかな？w

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

で、統一教会はなんて言ってるの？

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

linuxはいつまでgccを使い続けるつもりなのか

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

Cのheaderと型情報のないバイナリをパーツ化していたのに
一体化してどうすんの

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

GCCとLLVMって各種ベンチマーク見ると
ほぼサイズも実行速度も同程度っていうのが現実

だからどっちでもいっしょしょ

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

スレにサタンが紛れ込んでると思います。

**デフォルトの名無しさん** · 2022/09/25(日) 11:03:01.03

>>431
性能はほぼ一緒だね
しかしこのスレに一番関連ある関心事は新たな次世代言語が作られた時のコード生成のためにどちらが利用できるか利用しやすいかかな
現状だとほぼ間違いなくLLVMが選ばれると思う

**デフォルトの名無しさん** · 2022/09/25(日) 11:08:43.08

選ばれるとは何かが分からない
wasmを選んだ奴はllvmを却下したのか

**デフォルトの名無しさん** · 2022/09/25(日) 11:17:57.28

>>434
Wasmは多々あるアーキテクチャの一つ
LLVMコードからWasmコードが生成されるという関係
各言語コード→LLVMコード→Wasmコード(あるいはx64コードなど)

**デフォルトの名無しさん** · 2022/09/25(日) 11:26:05.63

>>433
後発なので色々改善されてるとは思うけどぶっちゃけ慣れのレベルじゃね？

**デフォルトの名無しさん** · 2022/09/25(日) 11:29:22.28

パーツ化を進めた結果が、llvmをwasmに変換する作業なのか

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

”様々なコンパイラに対応するという目標からして間違っているよ本来の目標は様々なアーキテクチャに対応すること”

また変な事言い出してきた。llvm13.0でllvm/ADT/Triple.hを確認すると59種のアーキテクチャが確認できて
手元のgccが79種、こいつは足し算もできないどころか、自分の文章に矛盾だらけなことに気づいていない.....
劣ってるのは、何でもかんでも引っ張り出してきて他言語を攻撃する品性のないあんたの頭であって、優れているのは
地道に言語実装を担当するコミッターであり、決してあんたではない。「〇〇を勉強してる俺スゲー！」ｗｗｗ

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

俺スゲーっていうか
自分の力量も相手の力量も両方見えてないのが初心者の特徴
フワフワした断片的な知識で夢心地になれるのも初心者の特徴

**デフォルトの名無しさん** · 2022/09/25(日) 11:43:12.78

Cコードを生成してるNimはマイナー言語のまま終わりそうよ

**デフォルトの名無しさん** · 2022/09/25(日) 11:52:46.22

>>437
後から慌ててパーツ化を進めたのはGCC

**デフォルトの名無しさん** · 2022/09/25(日) 12:22:24.14

このスレに出てくる言語だと
SwiftやRustやZigやKotlin(ネイティブ生成時)などみんな各コンパイラがバックエンドとしてLLVMを使っている
もちろんC系各言語はClangがLLVMバックエンド

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

GCでも似たような話を聞いた
多々ある言語がみんなGCを使っているのに何故ARCなのかって
おそらく、多々あるアーキテクチャの一つにならない方が得をする可能性もあるからじゃないか

**デフォルトの名無しさん** · 2022/09/25(日) 14:58:40.12

gccのほうが変則的ながらサポートするアーキテクチャが多いのは歴史が長いからだろうけど、gcc rustとか
linusが言ってるように存在する（だがいまいち）んだから、攻撃性だけ高いバカは相手にしちゃいかんのな？
公式じゃないとしても様々なコンパイラに対応はrustですら行っていて自分に返ってきた諸刃の剣になっとるわ
何が言いたいのか1つも分らんし、結局はマイナーだの、みんながLLVMだの。マジ気持ち悪い

**デフォルトの名無しさん** · 2022/09/25(日) 15:24:54.20

nimはコンパイラを作らない方針よ
Cへのコンバータを代わりに用意していましゅ

**デフォルトの名無しさん** · 2022/09/25(日) 17:11:04.17

>>439
日本の技術は世界一。

**デフォルトの名無しさん** · 2022/09/25(日) 17:28:42.91

次スレタイから
Nim out
Zig in
で

**デフォルトの名無しさん** · 2022/09/25(日) 18:03:28.36

Carbonも入れよう
Go、Rust、Swift、Zig、Carbonはまつもとゆきひろ公認の次世代言語だからね
https://logmi.jp/tech/articles/327259

**デフォルトの名無しさん** · 2022/09/25(日) 18:11:13.74

D言語も入れるべきでは？

**デフォルトの名無しさん** · 2022/09/25(日) 18:43:21.75

当時Zigに注目してなかったが、過去スレのこれ↓今度は「競プロ的視点」でZigのところ再現してくれ

ちなみに某一名が >それは専用プログラムでない限りプログラミングでやってはいけない行為 >"caller hash"
と批判しているが、"Rust@github rust/optimized-customhashmap"でも行われている。

https://github.com/benhoyt/countwords

https://mevius.5ch.net/test/read.cgi/tech/1655771266/
976デフォルトの名無しさん2022/08/05(金) 07:34:10.27ID:BZGh0CoX
Time in seconds for each data size: kjvbible.txt
x10 x100 x200 x400 Mem Comment

0.018 0.052 0.089 0.174 ***MB baseline/cat
0.036 0.089 0.147 0.260 ***MB baseline/rg foobar (ripgrep, no match)
0.032 0.091 0.159 0.290 ***MB baseline/ugrep foobar (no match)
0.058 0.457 0.889 1.789 1.1MB baseline/grep foobar (no match)
0.219 2.108 4.127 8.263 0.9MB baseline/wc -w (word count, total only)

0.154 1.271 2.551 5.079 2.0MB C (caller hash,stdin=binary-mode)
0.177 1.412 2.733 5.446 3.8MB Go (caller hash)
0.161 1.458 2.903 5.671 1.4MB C++ (caller hash,cin=binary-mode)
0.175 1.513 2.953 5.863 4.6MB Zig @github fixed
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0.176 1.572 3.124 6.045 2.6MB Rust@github rust/optimized-customhashmap <------実は"caller hash"
0.180 1.597 3.219 6.267 3.1MB Rust@5ch res >>602
Ryzen9 5900X windows11

**デフォルトの名無しさん** · 2022/09/25(日) 18:57:56.78

そんなことより条件揃えないベンチは何も価値がない
どうでもいい話を今ごろ蒸し返すのは病気

**デフォルトの名無しさん** · 2022/09/25(日) 18:59:20.58

Nim下げしたいがためだけにgccよりllvmとか言ってたのか
くだらな

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

Cコードを生成するNim
LLVMコードを生成するZig
どちらがまともか一目瞭然

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

唯一確かなのは言語のスレで実装でマウント取ろうとする奴がまともでないことだな

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

ある言語で誰かにより書かれた特定のアプリやシステムやプログラムコードをもってその言語自体を叩く人がいつもいるね
区別がつかないのかも

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

そもそも言語を叩くって意味が分からんわ
いや、意味は分かるんだけど動機が分からんわ

プログラミング言語に好きも嫌いもなくて必要なもんを使うだけ←わかる
嫌いな言語なんてない←わかる
嫌いな言語がある←わかる
嫌いな（？）言語を叩く←？？？

**デフォルトの名無しさん** · 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のような真のマクロを備える
それともどこかにある最適な実装を、シコシコとオレ様実装してしまう泥臭く真の漢のシステムプログラマーばかりなのか