次世代言語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/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/

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

全ての証言を信じれば矛盾する
なぜかといえば自白強要や誘導尋問から生み出される証言もあるから

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

>>985
>当然コストが高いわけでそれに見合うほどのパフォーマンスが必ずしも得られるわけではない
ここで言うコストとは何のこと？

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

全く同じアルゴリズムで比較するべきとか言い出すならそもそもこんな複雑なタスクでベンチマークするのがおかしい
もっと簡単なタスクをいろいろ用意してそれぞれでベンチマーク比較したほうがいい

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

どうすべきかなんて目的次第ですよ

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 45日 2時間 34分 22秒