次世代言語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/22(木) 21:08:11.72

>>367
おそらくフロントエンドは全部Rustになります
CDNエッジサーバーで「フロントエンドの処理を全部動かす」のが確定的になったから
そこではRustが暴れまくる
コンパイラとシステムプログラミング、OSだけでなく
Webの世界もRustが支配しそうだ

**デフォルトの名無しさん** · 2022/09/22(木) 21:43:59.14

>>389
Cからの動作合成が使い物になると思ってる時点で実際FPGAやったことないのバレバレなんだよな
ちゃんとパフォーマンス出そうと思ったらVerilogで書くのは当然として配置やクロック系までちゃんと調整しないといけないわけで

**デフォルトの名無しさん** · 2022/09/22(木) 21:52:22.05

フロントエンドでもバチクソに速さを求められて要件もシンプルな場所にはそれなりに Rust が使われると思うけど、業務アプリとかみたいに要件にも揺れがある領域では GC が基本の言語がまだまだ(もしかしたらずっと)強いだろ。

**デフォルトの名無しさん** · 2022/09/22(木) 21:54:38.94

＞腐った設定を楽しむポエスレ
これでしばらく俯瞰してる

https://mevius.5ch.net/test/read.cgi/tech/1663409149/366 (一部設定加筆修正)
デフォルトの名無しさん 2022/09/22(木) 15:45:41.23 ID:llfSUMQF
なるほど、腐ったスレ -> 腐った設定を楽しむポエスレ

追加設定(仮):
Rust,Go,C#,C,組込み,低レイヤー,それぞれ担当分野の強みを集めて日本製VRヘッドセットなどのウェアラブルデバイスのキット、ソフトウェアソリューション事業(仮)を近々発表する設定

ソフトウェアスタックの一部がRust製、Rustの優良誤認(*)を巧に利用した宣伝
(* https://mevius.5ch.net/test/read.cgi/tech/1661739736/946,963)

Rust,Goの「全訳」(公式以外)を出してコンサル、受託開発もすると宣伝

近々リリース予定のLinux6.1(Rust製ドライバ実働ready)を宣伝材料に使う

Rustの真実(**)は宣伝に都合が悪いから5chで火消し作業w
(** https://mevius.5ch.net/test/read.cgi/tech/1663409149/338)

尋常ならざるネット行動で「ヘイト」を集めた「仮想集団Rustese」(4~5名)(仮定)の社長(仮)が複オジしゃちょー
(https://mevius.5ch.net/test/read.cgi/tech/1663409149/256,368)

着々と「ヘイト」を収集中

ネットメディアに取り上げられて「顔出し」インタビュー記事が出るw
＞後日「答え合わせ」しようや
(>>https://mevius.5ch.net/test/read.cgi/tech/1663409149/202,255)

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

>>354
Nginxは静的webサーバーとしてはApacheより速いけど、HTTP(S) ProxyやリバースProxyでそんなに速くないし
ロードバランシングもあるけど、モニタリングとか簡素だもん。Cloudflareがいままで余りにもお粗末だっただけで
HAProxyやEnvoy(いずれもC系)でHTTPSでは99%タイルで3倍以上、Traefikの最新版だって2倍スループットの
差が出る。まあ上の記事にも書いてあるけどね
ちょっと古いけど、ベンチマーク（もちろんCPUやメモリ消費量の話じゃないけど、それはパフォーマンスに直結する）
https://www.loggly.com/blog/benchmarking-5-popular-load-balancers-nginx-haproxy-envoy-traefik-and-alb/

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

嫌儲板にRustのスレが立つ日が来るとはｗｗｗｗ

Linux、開発言語としてRustの導入がほぼ確定！まだ覇権プログラミング言語Rustを学んでない奴おりゅ？ [543236886]
https://greta.5ch.net/test/read.cgi/poverty/1663742232/

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

それとHTTP(S) ProxyなんてHTTPリクエストの入り口だけど、それを「フロントエンド」なんて言わないよね。
大体はミドルウェア扱いで、コンペティションならサーバーサイドの処理結果や連続する同一リクエストなどを
Proxyキャッシュから返すとか小細工するけどさ
ほとんどの実際のサーバーサイドの入り口のプログラミングだって普通にファイヤーウォールの中にあるので
そんな外で一体になるようなプログラミングは許されることは多くない
エッジサーバー言い換えるとエッジコンピューティングは、CDNやIoTのような特殊な業務には求められるけど
データーベースにつながってるようなシステムだと（工夫して非同期を使っても）結局データを取りに行って
戻ってこなくちゃならないし

**デフォルトの名無しさん** · 2022/09/22(木) 23:24:58.92

レールは続く】 Ruby on Rails Part21 【これからも
https://medaka.5ch.net/test/read.cgi/php/1545146635/103-104

Rails で世界最速！
表示速度が“異常な”Webサイト「dev.to」

これ、米国？なのに瞬時に表示される！
不思議

**デフォルトの名無しさん** · 2022/09/22(木) 23:25:28.59

Rustおじさん狂っちゃった？

**デフォルトの名無しさん** · 2022/09/22(木) 23:53:56.73

ファイル配信がFPGAに置き換わってることを知らなかったのでは？

**デフォルトの名無しさん** · 2022/09/23(金) 01:00:35.17

異世界おじさん

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

>>399
ファイル配信がどのレイヤーのこと言ってるのか知らんけどフルFPGAの配信サーバーなんて見たことないけど？

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

データでわかるRustの開発者達〜Rust Survey 2021の深堀
https://gihyo.jp/article/2022/09/rust-monthly-topics-01

**デフォルトの名無しさん** · 2022/09/23(金) 22:37:31.64

ホントにRust利用分野のトップがサーバーサイド／バックエンドなんだな

**デフォルトの名無しさん** · 2022/09/24(土) 10:27:32.12

C 言語の代替を標榜して作られたんだから
そりゃそうなるわな

**デフォルトの名無しさん** · 2022/09/24(土) 10:44:41.46

お前らは、標榜したことを実現するためにあらゆる手段を使うべきだと刷り込まれている
だがそれは数学ではないし道徳的にも正しくない

**デフォルトの名無しさん** · 2022/09/24(土) 13:05:16.42

おまえら次のスレでは別の言語が覇権！ってしてるんだもんなあ
なんていうか世の中からズレまくってるよ

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

次世代言語の話というより、格付けをしたいだけのキッズが混ざってるからな

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

トーバルズ氏、Rust導入やM2搭載「MacBook Air」について語る
https://japan.zdnet.com/article/35193521/2/

Rustがまだカーネルに導入されていない理由の1つは、一部の開発者が、Linuxで動かすには非標準のRustの拡張がたくさん必要になることを懸念していることだ。
例えば、Rustで書かれたLinuxの新しいNVMeドライバーを動かすには、70以上の拡張が必要になる。

しかしTorvalds氏は、自分たちはすでに何十年も、標準のC言語にはないものを使い続けてきたと指摘した。
「私は以前から、この分野の標準はゴミだと大声で主張してきた。標準が間違っているので、私たちは標準を無視している。Rustについても同じことが言えるだろう」と同氏は言う。

少なくともTorvalds氏は、重要なのはむしろRustのコンパイラーの信頼性と安全性だと考えている。
今ある問題の1つは、「GCC Rust」の信頼性と安定性が低いことだ。このため現実的には、今のところ、LinuxでRustを使用するには「Clang」を使うしかない。
しかしTorvalds氏は、「Clangは十分使える。Rustをマージすればおそらく有益だろうし、カーネルに害を与えることもないだろう」と語った。

**デフォルトの名無しさん** · 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

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