次世代言語26 TypeScript Swift Go Kotlin Nim

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

スレタイ（順番はRedMonk準拠）以外の言語もok

※　Rustは現世代最強言語なので除外します

前スレ

次世代言語25 TypeScript Swift Go Kotlin Rust Nim
https://mevius.5ch.net/test/read.cgi/tech/1650185555/

**デフォルトの名無しさん** · 2022/08/01(月) 22:40:21.87

Rust と言うゲームがあるみたい。
それで、Rustは言語ランキングが1位になるのかも

並行プログラミングでは、Elixir。
100GB ぐらいのメモリで、5,000万個の小プロセスが稼働する

Ruby on Rails と似ている

**デフォルトの名無しさん** · 2022/08/01(月) 22:46:46.79

Elixirは大元のErlangの実行が中々愉快なことになってるんだけどもそれを継承してるんだっけ？

**デフォルトの名無しさん** · 2022/08/01(月) 23:02:32.84

>>896
それらのプログラミング言語で労力が10倍も変わるなんてありえない
変わるとしてもそのなぜか一緒にしているC/C++とC#の差が大きい程度
自動的にメモリ解放してくれないC/C++ではその分だけ労力がかかる
もちろんC#は多少労力が楽な分だけ遅くなるため優れていることを意味するわけではない

**デフォルトの名無しさん** · 2022/08/01(月) 23:10:21.89

>>897
320GBのメモリーがあれば、国民一人一人にプロセスを与えられるね。

**デフォルトの名無しさん** · 2022/08/01(月) 23:11:24.47

>>899
いや、Rustなら10倍かかってもおかしくないでしょう。

**デフォルトの名無しさん** · 2022/08/01(月) 23:14:57.62

安全にメモリ自動解放してくれて楽なのにC並に高速なRustがおすすめ

>>901
Rustなら楽に効率よくプログラミングができて高速な実行も得られます

**デフォルトの名無しさん** · 2022/08/01(月) 23:16:39.89

キミは何でIDが変わるの？

**デフォルトの名無しさん** · 2022/08/01(月) 23:25:18.49

労力って使える人材探し始めてから完成するまでの時間でしょ？
Rust使える人を見つける時間考えたら、他の言語選んだ方が圧倒的に早くて安いよ

**デフォルトの名無しさん** · 2022/08/01(月) 23:39:41.39

>>904
次世代言語スレでそれは意味のない話ですね
Rustも他の言語も使える普通の人にとって開発効率もその実行生産性も最も高い言語がRust
そしてRustコンパイラの親切さにより誰でもRustを使えるようになるところも大きなポイント
古き概念のみに固執して学習に失敗した人を除きみんなが学習に成功しています

**デフォルトの名無しさん** · 2022/08/01(月) 23:39:51.69

オリジナルよりパクリの方が時間は短い
時刻はオリジナルの方が早い

**デフォルトの名無しさん** · 2022/08/01(月) 23:43:41.81

>>905
> 開発効率もその実行生産性も最も高い言語がRust

ソースは？そんなに最強なのになんで流行っていのか説明できる？

**デフォルトの名無しさん** · 2022/08/01(月) 23:45:10.83

>>904
それで遅くメモリを喰うものが出来上がってもリソース運用コストが嵩むだけだ
さらにそういう連中は保守性の低いプログラムしか書けないだろうから今後のコストも膨らむ

**デフォルトの名無しさん** · 2022/08/02(火) 00:00:32.68

あとメモリ効率ってそんなに大事なことなの？
OSや組み込みなど低レイヤーならわかるけど

高いコストを払ってまで得られる価値はないことが多いのでは？今までGC言語が流行ってきたわけだが？
むしろIOやCPUがボトルネックになる方が大半でメモリ効率がいいことによって恩恵が得られるケースってほとんどないのでは？

**デフォルトの名無しさん** · 2022/08/02(火) 00:03:12.51

>>907
マジで知らんのか？
それはRustが新しい言語だから

Rustの大きな強みの並行プログラミングがまともに使えるようになったのが2019年から2020年にかけて
そしてその効率と実用性が幅広く確認されたためIT大手各社が共同でRust Foundationを設立したのが2021年
プログラム言語史上でも初めてIT大手各社が揃って共同で支持するほどの革命的な言語

**デフォルトの名無しさん** · 2022/08/02(火) 00:05:28.81

>>909
その高いコストもGCコストも両方を無くした画期的な言語がRust
これで誰もが楽に安全で速いプログラムを書けるようになった

**デフォルトの名無しさん** · 2022/08/02(火) 00:13:54.99

GC言語の方が生産性高いのでは？
GC言語より生産性が高い根拠は？
異常に速いとか言っておきながら単語カウントとかその辺にあるベンチマークでGoやNimに普通に負けることがあるのはなんで？

大手が採用しているのはあくまでもOS開発など低レイヤー用途でグーグルとかはサーバーサイドがGoで書かれているようだけどそれをRustにするという話はどこにも出ていないね

低レイヤー以外だとMetaとDiscordぐらいで日本でRust採用してる企業は特に存在しないね
グーグルトレンド見ればわかるようにRustは全然流行っていないな

**デフォルトの名無しさん** · 2022/08/02(火) 00:19:52.75

GoogleやMicrosoftはOSやカーネル開発でRustを採用することにしたらしいが
OSやカーネルやコンパイラだとかを開発しているエンジニアって全体の何%ぐらいだと思ってんの？

Rustは一部の数%程度の少数向けに向いているってのが事実だけど
ここにいるRust信者は他のあらゆるプログラミング用途でRustが最強で既存言語を置き換えていくとかほざいているわけだが
何の根拠もない妄想でしかないわ
適材適所って言葉を知らない無能

MetaとDiscord以外で採用している有名企業あげてみろや

**デフォルトの名無しさん** · 2022/08/02(火) 00:25:19.06

ネットに嘘が多いのは、検査が足りないからじゃないかな

Rustコンパイラはある種の嘘を検査している
それが非効率だと思うなら嘘に寛容な効率化をやってみせろ

**デフォルトの名無しさん** · 2022/08/02(火) 00:28:37.12

>>912
その嘘を繰り返すのはいい加減やめよう
バッファリングしない入出力を使わされたsimple版ですらRustはGoより速い>>603
そして両者の改善版でもRustはGoの1.5倍速い結果となった
この一瞬で実行が終わりGCも起きないほどの規模でもGC言語が大きく負けた

**デフォルトの名無しさん** · 2022/08/02(火) 00:28:42.85

RustはGCがないからあらゆる面で最強で他のあらゆる言語を置き換える←妄言

RustはGCや手厚いランタイム環境が使えない、もしくは適さないようなシビアな要件で安全なプログラムを作成できるためC++を置き換えることがある←正しい

正しい理解をした上でRustを広めような

**デフォルトの名無しさん** · 2022/08/02(火) 00:33:51.61

>>915
記事を見て言ってるわけだけど。記事の段階でGoに負けたのは事実でしょう
あとこれはベンチマークの一例ね。他にもネットで探せばRustが微妙な位置にいるのはよくあることだね。

そもそもハッシュが遅いだとかで最適化したバージョンが記事で使われてないのは何故だか考えてみようね

あとRustはNimにも負けているね。GC言語だけど。。

**デフォルトの名無しさん** · 2022/08/02(火) 00:38:10.10

CPU処理だけのプログラムでもGoに負けることがあるのだから
低レイヤー以外の用途でRustを採用する必要なんか皆無であることがよくわかるね

**デフォルトの名無しさん** · 2022/08/02(火) 00:40:03.84

ちなみに俺はRustアンチじゃないからね
何でもかんでもRustが最強！GC言語はゴミで駆逐されるとかほざいてて
Rust使ってる自分に酔ってて他人にマウント取るだけが生きがいのゴミが嫌いなだけだね

**デフォルトの名無しさん** · 2022/08/02(火) 00:40:19.24

全言語の中でCに次いでRustが最速となったプログラムのコード>>602を見てみよう
どの言語のプログラマーであってもすぐに理解できるほど抽象度が高く平易で分かりやすいコードとなっている
つまりRustを学習すれば誰もが分かりやすくてコード＆C並みに高速を両立するプログラムを書けるようになることを意味している

**デフォルトの名無しさん** · 2022/08/02(火) 01:56:40.26

このままRustでまるまる1スレッド潰すのか

**デフォルトの名無しさん** · 2022/08/02(火) 02:07:05.35

俺はRustでStringをcloneしまくるコード書いちゃうからなぁ
あんま速くないかも

**デフォルトの名無しさん** · 2022/08/02(火) 02:24:14.36

クソコードがそもそも詠唱できない時点で
クソコードのおもりをさせられるエンジニアがいなくなる

このことは重要

**デフォルトの名無しさん** · 2022/08/02(火) 05:52:39.70

RustはDropbox、Cloudflare、IBM、トヨタなども使っているね。
コストってなんのコストを指しているかわからないけど、個人的にはシステムの生涯でかかるコストは他言語より安く済むと思うよ。

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

基本的にRustは遅いよね。
実用的なソフトウェアを作るには10倍の労力がいるし。
ベンチマーク特化型言語なのに、ベンチマークも遅いし。

**デフォルトの名無しさん** · 2022/08/02(火) 08:10:44.50

>>915の認識は微妙に間違っていて、simpleは標準ライブラリにこだわって遅いhashmapを使ってて、バッファが噛んでないのはoptimizeの方。

**デフォルトの名無しさん** · 2022/08/02(火) 09:29:37.95

はいはいRust最強最強
とりあえず現時点で最強ってことらしいから、スレタイから外していいし、どっかいってくれ
次世代言語のスレだから既に最強のRustを語る必要はない

**デフォルトの名無しさん** · 2022/08/02(火) 10:16:23.49

>>926
コードを見てみたが>>430のベンチマークは恣意的過ぎて酷い比較になってたんだな
optimizeの方だけ取り上げてもCとC++では最適化した専用のカウント用テーブルを用いているのにRustだけ放置
結局Rustでも同様の実装をしたらC++よりもRustが速くなった>>602を見て唖然

**デフォルトの名無しさん** · 2022/08/02(火) 10:44:19.34

スピードなんかどうでもよくてメモリが安全なのがいいんだよ

**デフォルトの名無しさん** · 2022/08/02(火) 11:02:56.88

狭義のGC あり言語の欠点はGC走って処理が引っ掛かるところかと。

**デフォルトの名無しさん** · 2022/08/02(火) 11:04:01.76

>>929
Rustは確かに高速でも安全でもあるが
同じアルゴリズムとなった元記事のoptimuzed.cとoptimized.cppと>>602のRustコードを見比べると
Rustは抽象度が高く記述できていてコードが読みやすいな
それでいて高速および安全と三者が揃っているのは驚いた

**デフォルトの名無しさん** · 2022/08/02(火) 12:08:32.96

GC有りでPythonくらい所有権とか気にせず雑に扱えて、且つRustの効率性を実現できれば、次世代と呼べるのではないかな？

**デフォルトの名無しさん** · 2022/08/02(火) 12:21:54.19

Nimのoptimize版のコードかなり頑張ってるのにC/C++/Rustより倍くらい遅いのはGC言語の限界なのかな

**デフォルトの名無しさん** · 2022/08/02(火) 12:54:54.89

tauriってどうなの？価値ある？

**デフォルトの名無しさん** · 2022/08/02(火) 13:01:21.17

さあ、Electronで十分だと思うが

**デフォルトの名無しさん** · 2022/08/02(火) 14:25:29.92

スレタイにRustはないのにここで暴れる理由がわからん
Rustスレで啓蒙活動してればよろしい

**デフォルトの名無しさん** · 2022/08/02(火) 15:13:23.73

>>936
>>1によるとRustは現世代最強言語だから比較として出てくるのは当たり前だろ

**デフォルトの名無しさん** · 2022/08/02(火) 16:47:02.67

>>937
スレのルールに従えよ。

**デフォルトの名無しさん** · 2022/08/02(火) 17:38:35.92

> スレタイ（順番はRedMonk準拠）以外の言語もok
>
> ※　Rustは現世代最強言語なので除外します

※　Rustは現世代最強言語なので(話題にして良い言語から)除外します
※　Rustは現世代最強言語なので(スレタイから)除外します

どっち？

**デフォルトの名無しさん** · 2022/08/02(火) 18:09:03.75

NimはGC言語って言われるけど、スタック上にobject(C++のstruct/class相当)をおけるし、コンパイル時にサイズが決まれば配列もスタック上における。
objectの内容が配列や親objectのメモリ上に連続して配置することも可能。
C++言語のように自由にスタック上にデータを置くことが可能。
継承使いたいときとか一つのオブジェクトを複数のreferenceから参照したいときにref objectを使うんだけどこれはヒープに確保されGCで管理される。
Nimは複数のGCを選べるんだけど、--mm:arcオプションをつけるとRustのRcのような参照カウント方式でヒープが管理される。
--mm:orcオプションを使うと循環参照があってもメモリを解放できるようにした参照カウント方式が使われる。
詳しくは
https://nim-lang.org/docs/mm.html

**デフォルトの名無しさん** · 2022/08/02(火) 18:25:25.25

>>940
スタックに置けるのは当たり前だからそこはおいといて
[1] 継承を使うだけでヒープになるのは厳しい
[2] ヒープになるだけでGCとなるのは厳しい
[3] C++とRustで参照カウンタが使われる状況になるのはもっとレアケースのみ
中途半端な立ち位置だからNimは厳しい

**デフォルトの名無しさん** · 2022/08/02(火) 18:41:12.53

>>939
Rustは現世代言語なので、(話題にして良い)次世代言語から除外します。
だろ。

**デフォルトの名無しさん** · 2022/08/02(火) 18:42:42.88

Rustで実用的なソフトウェアを書くのは大変骨が折れる。

**デフォルトの名無しさん** · 2022/08/02(火) 18:45:25.03

厨がウザいからRustは除外します（本音）。

**デフォルトの名無しさん** · 2022/08/02(火) 19:45:31.74

valgrindもまともに使ったことなさげなバカが偉そうにしてるの見ると腹が立つってのはあるわな。

**デフォルトの名無しさん** · 2022/08/02(火) 19:49:07.82

C/C++で書かれたOSの上で動作してるのに、大言壮語も甚だしいという意見もある。

**デフォルトの名無しさん** · 2022/08/02(火) 19:56:24.89

システムプログラミング(笑)に特化してるってんならとっととRust製のOS作れよな

**デフォルトの名無しさん** · 2022/08/02(火) 20:22:23.89

RustでOSか。
一応 Linux は Rust で書いたソースも受け付けるようになったらしいな。ベースがCなのは変えないそうだが。

**デフォルトの名無しさん** · 2022/08/02(火) 20:56:39.03

>>945
今となってはコンパイル時に静的解決できることがほとんどだから需要ないな
実行時にMemcheckなんかやってる時点で時代遅れの敗者

**デフォルトの名無しさん** · 2022/08/02(火) 21:03:37.39

>>941
ヒープ使わずに継承を使うことはできるけどOOPするときは派生オブジェクトを基底オブジェクトのポインタ経由で使うことが多いでしょ。
QtのサンプルコードでGUI関係のクラスはnewしてヒープに確保している。
https://doc.qt.io/qt-6/qtwidgets-widgets-calculator-example.html

https://nim-lang.org/docs/mm.html
に書いてあるけど参照カウントが不要な場合はコンパイラが自動的に最適化してくれる。
そのおかげでunique_ptrとshared_ptrを使いわけるようなことは考えずに済む。

参照カウンタがどれだけ必要になるかは場合によりけり。
C++やRustでRcが不要なコードならたぶんNimでもref objectを使わずにコードを書けるよ。

**デフォルトの名無しさん** · 2022/08/02(火) 21:35:54.41

NimはObjectとref Objectを区別して扱わなきゃいけない時点で既に不便。

例えばRustでもそんな区別はなく、
スタック上のデータのみで完結しているオブジェクトなのか、
ヒープ上のデータを付随するオブジェクトなのか、
プログラマーはどちらなのか意識せず区別せずとも自動的に安全にメモリ解放される。

**デフォルトの名無しさん** · 2022/08/02(火) 22:18:46.88

CRTPでおｋ。

**デフォルトの名無しさん** · 2022/08/02(火) 22:24:30.00

次スレのスレタイはNim Zig Pony Carbon Gleamあたりでいいっすか？

**デフォルトの名無しさん** · 2022/08/02(火) 22:40:59.73

>>945
それ本気で言ってたら笑われる
Valgrind使って実行時にエラー検出と
Rustでコンパイル時にエラー検出の
現在どちらをとるべきか100%答えは出ている

RustでValgrindを使うことも稀にあるが
大半がC/C++とのFFIがらみでありC/C++が足を引っ張っている

**デフォルトの名無しさん** · 2022/08/02(火) 23:38:50.10

>>953
ウィ

**デフォルトの名無しさん** · 2022/08/02(火) 23:51:57.52

>>948
だってRustってめっちゃ遅いから

**デフォルトの名無しさん** · 2022/08/02(火) 23:58:05.26

RustならCとほとんど変わらない最高速
開発効率も上がる

**デフォルトの名無しさん** · 2022/08/03(水) 07:24:58.64

んなわけない。

**デフォルトの名無しさん** · 2022/08/04(木) 06:52:08.63

Rust保守できなくて他の言語に書き直す案件多すぎじゃね？

**デフォルトの名無しさん** · 2022/08/04(木) 07:38:09.36

>>959
具体的には？
多すぎと言うならサクッと10件くらい上げてくれるかな

**デフォルトの名無しさん** · 2022/08/04(木) 08:27:29.63

貶めたいだけだから、あげられないと思う

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

>>959
言語に対してアンチ活動をしているだけでも異常だが
嘘まで突き出すのは精神異常を疑う

**デフォルトの名無しさん** · 2022/08/04(木) 09:35:45.18

>>960
すみません、嘘いいいました

**デフォルトの名無しさん** · 2022/08/04(木) 09:44:49.51

https://twitter.com/search?q=Rust%20%E7%A7%BB%E6%A4%8D&src=typed_query
https://twitter.com/5chan_nel (5ch newer account)

**デフォルトの名無しさん** · 2022/08/04(木) 09:53:00.83

>>964
どう見てもrustからの移植よりrustへの移植の話の方が多くないか？

**デフォルトの名無しさん** · 2022/08/04(木) 10:33:52.33

今まで長年色々と携わってきた一般的な話として
移植するほど価値のあるものは滅多にないのと
同じ物を長く使い続けるよりある段階で設計から作り直した方が効率が良いのと
その時は古い言語を引きずらずにRustやKotlinやSwiftなど改善された良い言語を採用した方が効率良い

**デフォルトの名無しさん** · 2022/08/04(木) 10:54:52.94

でもRustを使えばメモリは安心安全だよ

**デフォルトの名無しさん** · 2022/08/04(木) 11:32:27.68

移植と逆移植の需要が噛み合って無限の雇用を創出するわけだ

**デフォルトの名無しさん** · 2022/08/04(木) 12:34:53.02

>>965
既存コードの数が違うんだから当然だろ。

**デフォルトの名無しさん** · 2022/08/04(木) 13:00:46.06

保守できなくて書き直しで言うと JS/TypeScript 界隈が深刻なんじゃねえの？
未成熟なモジュールシステム、幅広い要件、多彩すぎる処理系、本来の目的と違う使い方をされるView層(DOM)、流行りの影響を受けやすいドメイン。初学者に人気がある。

まぁ、言語側で頑張れることも限界があるけど…。

**デフォルトの名無しさん** · 2022/08/04(木) 13:17:32.31

>>969
それはそうだが
> Rust保守できなくて他の言語に書き直す案件多すぎじゃね？
って吠えてた人がいるからもっとあるのかと思ったら意外にショボくてワロタ
よくこんなものをドヤ顔で出せるもんだなw

**デフォルトの名無しさん** · 2022/08/04(木) 20:50:36.26

でもPHPの方が速いよね

**デフォルトの名無しさん** · 2022/08/04(木) 20:54:22.20

npmは反面教師としてめちゃくちゃ活躍した
後発のパッケージツールはみんな参考にしてる

**デフォルトの名無しさん** · 2022/08/04(木) 22:46:04.19

プロジェクト毎に切り替えてインストールする、

Ruby のBundler を真似て、npm/yarn が出来た

**デフォルトの名無しさん** · 2022/08/04(木) 23:00:37.24

何さらっと嘘言っているんだよｗ
パッケージ管理ツールなんて昔からあるのに

**デフォルトの名無しさん** · 2022/08/05(金) 07:34:10.27

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
0.180 1.597 3.219 6.267 3.1MB Rust@5ch res >>602
Ryzen9 5900X windows11

**976** · 2022/08/05(金) 07:37:51.09

データサイズを大きくしたら結構景色が変わったよ
もともとのサイズは左端のx10ね

**976** · 2022/08/05(金) 07:44:17.90

caller hashはoptimized.cと同じようにメインループでhash計算を済ませておいてhashテーブル関数に渡す用にしたもの
これ結構効果的だった

**デフォルトの名無しさん** · 2022/08/05(金) 07:49:10.83

こちらでもGoがC++やRustよりも遅い結果しか出ないのだが
GoがC++やRustよりも速い結果になる人は何が違うのだろう？バージョン？CPU？計測方法？
GoがC++やRustより速くなるのは他でも見かけないから何らか別の理由があるはず

**976** · 2022/08/05(金) 07:50:28.70

rustはよくわからないので、caller hash版は大先生にお願いしたいです

Mem:
メモリ使用量はタスクマネージャーでの表示です。cat/rg/ugrepは早すぎて見えませんでした
x10~x400で違いはなかったです

**デフォルトの名無しさん** · 2022/08/05(金) 07:54:28.24

>>978
それは専用プログラムでない限りプログラミングでやってはいけない行為
単語を渡すだけのインタフェースになっているべきであり、その利用側はハッシュ関数が何かを知ってはいけない
さらに、そのような逸脱した最適化アルゴリズムを特定の言語にだけ適用しても、言語間の比較とならない

**デフォルトの名無しさん** · 2022/08/05(金) 07:58:44.14

次世代言語27 Nim Zig Rust Carbon

**デフォルトの名無しさん** · 2022/08/05(金) 08:03:18.30

要はアルゴリズムが大事で言語の差異はスクリプト言語でもない限りどうでもいいってことだろ
もうこの話は終わりでいいよ

**デフォルトの名無しさん** · 2022/08/05(金) 08:06:44.88

アルゴリズムが同じならばGoが常に遅い
なので今回GoはイカサマをしたらC++/Rustより速くなったという話

**デフォルトの名無しさん** · 2022/08/05(金) 08:12:34.92

Goはパラレル版もリポジトリに置いてあるけど当然そっちの方がRustより早いぞ
Rustも並列処理すれば速いんだろうけど

ということで大事なのはアルゴリズムで言語差はわりとどうでもいいね
Rustがアピールするべきなのはパフォーマンスというよりは低ランタイムコストでメモリ安全ってとこじゃないの
当然コストが高いわけでそれに見合うほどのパフォーマンスが必ずしも得られるわけではない

パフォーマンスを改善するには言語を変えて作り直すより、アルゴリズムを改善したり、並行並列処理に切り替えたりする方が効果的

**デフォルトの名無しさん** · 2022/08/05(金) 08:15:37.58

その0.1秒で終わる処理ですら同じ条件ならばGoが遅いけど　
現実にはサーバーからアプリまでそれよりはるかに長い時間使われる
そしてGCが何度も起こりGoの遅さが致命的になる

**デフォルトの名無しさん** · 2022/08/05(金) 08:17:56.43

>>986
それはあなたの感想では？
GOがエスケープ解析しない根拠は？
＞そしてGCが何度も起こり

**デフォルトの名無しさん** · 2022/08/05(金) 08:18:55.11

次スレはワッチョイありで立ててくれ
Rust盲信者がIDころころ変えるので

**デフォルトの名無しさん** · 2022/08/05(金) 08:25:55.99

>>984
どこがイカサマ？Cと比較するために最適化しただけなのでは？
それがイカサマなら標準のハッシュが遅いからライブラリ使ってんのもイカサマだよね？

**デフォルトの名無しさん** · 2022/08/05(金) 08:29:18.89

元のGoブログの人を含めて全員おかしい
アルゴリズムを揃えないベンチマークは何も意味を持たない

**デフォルトの名無しさん** · 2022/08/05(金) 08:56:59.64

>>982
rustはもう外せよ

**デフォルトの名無しさん** · 2022/08/05(金) 09:25:07.37

そんなにRustがあらゆるプログラムでパフォーマンス、生産性が優れているなら
なんで頭のいいエンジニア達はわざわざRustを使ってDenoっていうランタイム作ってんの？？？

GCがあるとRust狂信者によるとWebサーバーでもクリティカルに影響が出てしまうらしいけど

なんでGCのないRustで狂信者曰くあらゆる面でゴミなGCありのDeno作ってんのよ

**デフォルトの名無しさん** · 2022/08/05(金) 09:40:18.52

>>978
その通りだがその時点でこのベンチマークが現実離れした意味のないものであることを意味している
以前から指摘が出ているように、このベンチマークの実行時間のほとんどは単語カウントに費やされていて、だからこそそのハッシュ計算のオプティマイズで大きく改善される
この筋の悪いベンチマークをどうしても行なうならば、最低限アルゴリズムとテーブルサイズなど条件を揃えるべき
現状では意味のない比較となっている

**デフォルトの名無しさん** · 2022/08/05(金) 09:43:12.76

次スレ

次世代言語27 Nim Zig Pony Carbon Gleam
https://mevius.5ch.net/test/read.cgi/tech/1659660050/

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

>>992
CやC++を使ってなぜ様々な遅い言語のコンパイラやインタプリタを作っているのか？と同じ話ではないか
それに気付かない君の頭の悪さを嘆こう

**デフォルトの名無しさん** · 2022/08/05(金) 09:48:57.07

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

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