次世代言語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/07/31(日) 17:58:52.41

最近はAIだの大規模分散処理だのk8sだの、小手先のプログラミング技術よりもずっと上位のレイヤばかりが注目される風潮があったから、
久々にプログラミング言語だけでマウント取れるチャンスが来て嬉しいんだろう
小手先のコードで難しい風のことをやるのが好きな割にそんなに頭良くないからHaskellとか本質的な概念の難しさでマウント取れるほどでもない、Scalaとかあのへんの人達

**デフォルトの名無しさん** · 2022/07/31(日) 18:01:52.52

もしかして統一教会がRustの取り扱い始めたのか？
日本だけなんだかおかしいぞ？

**デフォルトの名無しさん** · 2022/07/31(日) 18:13:00.39

コンパイル通れば全部オッケー、ランタイム速度最高！みたいなのが子供ウケいいんだよ。

**デフォルトの名無しさん** · 2022/07/31(日) 18:14:29.51

PHPより遅いのにか。

**デフォルトの名無しさん** · 2022/07/31(日) 19:08:26.53

>>829
PHPより遅かったのはC++だぞ
>>430の表を見ろ
simple版がRust＞PHP＞C#＞C++

そして>>602でoptimized版もRust＞C++となったようだからC++は厳しい

**デフォルトの名無しさん** · 2022/07/31(日) 20:26:31.89

>>826
ダウンロードできる成果物 (コンパイラ等) が最上位のレイヤーだと思うよ

マウントしても物は増えないのに何が嬉しいんだろうか
物欲がない人なのか
あるいは物欲を捨てなければならないと信じているのか

**デフォルトの名無しさん** · 2022/07/31(日) 20:45:35.96

>>831
最上位のレイヤは成果物の運用でしょ
仮にハリボテシステムで人間が裏で手動で操作してたとしても、
それでビジネス目標が達成できていてシステム作るより早く安上がりに構築運用できるならそのほうが良い

**デフォルトの名無しさん** · 2022/07/31(日) 21:15:03.74

>>825
D言語、悪くないと思うんだがなぁ、、、
10年前にスポンサーがついてればと思ったりする。

**デフォルトの名無しさん** · 2022/07/31(日) 22:01:58.99

>>832
他人の目標を変更させるのは困難だから人間は少ない方がいい

**デフォルトの名無しさん** · 2022/07/31(日) 22:53:26.31

もともとRubyで作られていたプロダクトで実行速度の改善が必要となった場合
代替言語としてGoではなくCrystalが採用される流れになってほしい

**デフォルトの名無しさん** · 2022/07/31(日) 23:54:15.32

>>821
Stackoverflowは存在しなかったか

**デフォルトの名無しさん** · 2022/08/01(月) 00:18:15.12

>>835
CookpadがRubyで遅くて深刻な部分をRustにしたのは似てるからだよね
クロージャの記法とか積極的なメソッドチェーンとか

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

Rubyを選んでRustってセンスがなさすぎるわ。

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

Rubyの代替ならNimだと思うわ。
RustはRubyのコンセプト (手軽なオブジェクト指向プログラミング)から遠すぎるわな。

**デフォルトの名無しさん** · 2022/08/01(月) 09:26:24.18

Rubyの代替というか高速化のため従来Cで書いていた部分の置き換えなのでは

**デフォルトの名無しさん** · 2022/08/01(月) 09:31:38.40

Rubyの代替でgoとか言ってるの見たことあるな
個人的には疑問だったが

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

web関連として使うなら普通にts使えと思うわ

**デフォルトの名無しさん** · 2022/08/01(月) 09:59:40.05

Ruby屋にtsはないだろう
・優れた開発者体験で静的型陣営を勝利に導いた
・ランタイムのパフォーマンスは動的型でありながらRubyを圧倒
・Railsの公式言語でありRubyの思想を色濃く受け継いでいたCoffeeScriptを駆逐
・SPAの隆盛を支えRailsをオワコン化させた
Rubyの敗北の象徴みたいな言語なんだから

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

tsはそろそろ不要だな

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

GoはランタイムにM:N threadingが統合されててシームレスに使えるってとこだけがとても良い
JavaScriptとかRubyはその辺ウンコすぎ

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

>>845
Rustも同様にM:N threadingがシームレスに簡単に使えるようになったのでRustがおすすめ

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

>>846
あらゆるライブラリ通して共通のやり方で並行プログラミングできんの？

**デフォルトの名無しさん** · 2022/08/01(月) 12:18:20.24

>>847
できないよ
ランタイムに何を使うべきかの選択をしたくないならgoを使った方が良い

**デフォルトの名無しさん** · 2022/08/01(月) 12:32:25.99

>>847
何を意味してその質問しているのかな
一般的に基盤として共通の枠組みと共通のインタフェースになるのは当たり前だし
その中でちゃんと目的毎に適した多様なパーツを提供しているのも当たり前だし
Goで出来てることは全て出来るし
Goより粒度の細かいこともできるのでRustがおすすめ

**デフォルトの名無しさん** · 2022/08/01(月) 12:37:14.24

>>848
それはもっと狭くGoのランタイムを選択してることになるから同じことであり説得力がない

**デフォルトの名無しさん** · 2022/08/01(月) 12:42:24.49

>>846
「簡単」とか大嘘つくなよ。
所有権を意識しないで使えるようになってから言えや。

**デフォルトの名無しさん** · 2022/08/01(月) 12:52:39.69

>>851
Goの並行プログラミングではチャネルによるデータの所有権の受け渡しが基本なことすら知らないのか？
所有権を意識しないバカは口を挟まない方がいいぞ

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

>>851
C++などでメモリ共有方式でやるときも所有権の共有は意識せざるを得ない
並行並列プログラミングで所有権を意識するなと言われても無理な話

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

>>846
大嘘くそ太郎

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

その分野ならRustが一番いいかな
所有権の取り扱いにミスがあればコンパイラが詳しく指摘してくれる
データ競合してるところがあればコンパイラが詳しく指摘してくれる
実行時エラー発生まで待たずに済み開発効率も高い

**デフォルトの名無しさん** · 2022/08/01(月) 13:19:04.33

>>854
RustでもシームレスなM:Nスレッドが簡単に使えるよ

**デフォルトの名無しさん** · 2022/08/01(月) 13:24:02.26

>>852
”チャネルによるデータの所有権の受け渡し”GoにもRustにもそんな概念はありませんが？おまえが考えたの？

**デフォルトの名無しさん** · 2022/08/01(月) 13:41:40.37

>>856
Rustの標準ライブラリは、1:1スレッドの実装のみを提供しています。
さらに外部ライブラリでも、有名なものはかなり煩雑に書いてI/Oバウンドのものしか作れません、Rustの（多くのライブラリの）ポリシーとして勝手にタイマーなど時系列で特定の処理を実行しているCPUコアが切り替わったりしません。
これは大きいランタイムを嫌うからですが、kernelなどやハードウェアに近いものを書く分には良いですが、I/Oが詰まったら、他は実行できないでプログラム全体がフリーズします
これを”M:Nが簡単”というにはあまりに、お粗末であり、記述の煩雑さを見ても、”簡単に使える〇〇カラおすすめ”なんて人を騙すための背信行為です。
言語をススメたい、シェアを伸ばしたいと思うなら真摯で誠実になりなさい。
あんたに言ってもしょうがないけど、あと開発効率は全然高くない、コンパイル遅い、mut mutめんどくさい、いい加減改良しろや！ボケカスMozila！

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

>>857
並列プログラミングでは常識
データの所有権を共有するか、共有を避けて所有権の受け渡しのみにするかなど、意識せざるを得ない
そのうちGoではデータの所有権を受け渡しをするチャネルの利用を推奨していて公式にも明記

Go公式ページ
https://github.com/golang/go/wiki/MutexOrChannel
Channel = passing ownership of data

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

>>857
言い方はオカシイ奴だけど、明確に所有権の概念のある言語から見たらそう見えるということは正しいだろう？
859の上に書いてある、channelがある言語によく聞くスレッドにまつわる話に
"Share memory by communicating, don't communicate by sharing memory."
「通信によってメモリを共有し、メモリを共有（して通信）しないで」というのが、golang的には正しいかもしれんが
golangだって実通信しているわけじゃなく、スレッド間のブロッキングの入るFIFOバッファへのデータのコピーに過ぎない

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

>>858
本質を捉えらてないからそんな無駄な間違えた話になる
言語に関係なくGoでもRustでも、M:NのM部分つまりカーネルスレッドの標準起動数はCPUコアスレッド数と同じ最適化
これら全てを計算のみ実行し続けて強制奪取なくば塞ぐ使い方をM:Nですることは実際になく、仮にあったとしても容易に定期自主返納も可能だからフリーズを現実に起こすことはない
現実に影響する大きな違いは、Goroutineが個別にスタックを必要としてスタック切り替えコストもメモリコストもかかるのに対して、Rustタスクはスタックレスだから切り替えコストやメモリコストが生じない点
Rustではシンプルな状態マシンとしてそれを実現していて上手く機能している

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

>>861
>これら全てを計算のみ実行し続けて強制奪取なくば塞ぐ使い方をM:Nですることは実際になく
普通に？数千数万の要求に、並列・時分割でプログラムをCPUのコア数以上に動作させる要件は世界中にたくさんあるが？
多くの言語でOSスレッドがフリーズしたら、容易でもないし、定期自主返納なんてあり得ない。容易に自主返納するおまえの
コードの実力を見せてもらおうか？
ランタイムありのグリーンスレッドを提供している一部の言語の場合、スレッドの停止は致命ではないがRustは全くそうではない。

＞Rustタスクはスタックレスだから切り替えコストやメモリコストが生じない点
OSスレッドにスタックが存在しない現代のOSはほぼ無い。
問題になるのはメモリやスタックにあるデータをスレッド間で共有したりメッセージパッシングしたりするときに、OSスレッドをまたいで
データやりとりしたり、排他ロックはコストが掛かるという話だけ。
そもそもグリーンスレッドはOSコンテキストスイッチを嫌ってそもそもスレッドを跨がない場合が多い。だからGoのメニーコア用の
M:Nランタイムは、他の糞のようなI/Oバウンドしか出来ない言語のライブラリより、遥かに軽量
切り替えコストやメモリコストが生じないのではなく、機能としてグリーンスレッドような存在がなく、軽量に切り替えるような事が
出来ないだけの出来ない尽くし、これはまったく誇れることではなくむしろ汚点

>Rustではシンプルな状態マシンとしてそれを実現していて上手く機能している
では、なぜシンプル・上手く機能なはずのRustにM:Nスケジューラーの実装標準搭載要望が多いのか？

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

なんか盛り上がってるな
おれはアクターモデルを安全に使いやすい言語が登場してほしい

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

ステートマシンの生成をゼロオーバーヘッドと言い張るのは流石に無理筋じゃないかね
ステートマシン手書きと同じというだけの言葉遊びやね

**デフォルトの名無しさん** · 2022/08/01(月) 17:04:06.77

>>864
rustが標榜してるのはzero cost abstractionで言わんとしてるのはまさにそういうことだよ
抽象化されたコード書いても手書きでステートマシン書くのと同じ性能特性になる
他の典型的な言語だとオーバーヘッドあるよね？という主張

長文レスは目が滑るから読んでないから的外れだったらスマン

**デフォルトの名無しさん** · 2022/08/01(月) 17:15:17.99

グリーンスレッドは初期rubyのウリだったよね
マッツも誇らしげやったで
ワイもユーザとして誇らしかったのを覚えてる

**デフォルトの名無しさん** · 2022/08/01(月) 17:21:31.08

ここまでにponyおじさんが現れないことがそこはかとなく悲しい

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

オブジェクト一つにつきスレッド一つ作れるようになったら
オブジェクト指向はただのマルチスレッド手続き型になってしまう

**デフォルトの名無しさん** · 2022/08/01(月) 18:38:15.71

Rustで実用的なソフトウェアを書くには、Java、C#、C/C++の５～８倍ほどの労力が必要と言われてる。

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

>>866
Linuxにスレッドがなかったからでは？

**デフォルトの名無しさん** · 2022/08/01(月) 18:42:48.07

ものりしっくですね

**デフォルトの名無しさん** · 2022/08/01(月) 18:44:36.03

グーグルトレンドによると、世界では存在感ゼロのRustが、日本では6月初めの一時期、Goを抜いたからね。
世界ではGoのほうが100倍ほど検索ボリュームがあるので、逆転はあり得ない。
なんか工作くせえ。

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

スレッドがなかったころ、Linuxユーザーはスレッドの邪悪さを主張してて、Windowsはスレッドがあるからダメなんだとか言ってたのにな。

**デフォルトの名無しさん** · 2022/08/01(月) 19:15:06.90

こいつKENTAおじさんと同じ病気だな

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

ぶっちゃけ、C++が常に次世代言語では？
3年に一度改定され続けるんだし。
C++20は、C++11以来のメジャーバージョンアップと言えるのでは？

**デフォルトの名無しさん** · 2022/08/01(月) 20:06:43.75

完全なコピーができるデータには
参照も参照カウントもGCも所有権もロックもスレッドも必要ない
プロセス間通信だけでいい

コピーを回避することが邪悪かどうかは知らんけど全ての元凶ではある

**デフォルトの名無しさん** · 2022/08/01(月) 20:18:48.94

ちょうどLinuxでスレッドが使えるようになったころ、世の中はC10K問題全盛期に入った。
しかし、Linuxユーザーはスレッドマンセーに宗旨替えしてしまい、C10Kには目もくれなくなってしまった。
そのころC++では、boostと黒魔術が広まりつつあり、5chではWTLなんかが流行ってた。
当然ながらC++では非同期が一つのキーワードであり、IOCPが関心を集めていた。
それがBoost.Asioへと繋がっていく。

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

>>876
ヒープレスプログラミングとか考えて提唱してみれば？
21世紀を代表するアーキテクトとして歴史の本に載るかもよ？

**デフォルトの名無しさん** · 2022/08/01(月) 20:27:15.17

Tauriでデスクトップアプリ作りたくてRust始めようと思ったけど
なんかPythonやらNimやらもサポートされるらしい
じゃあRustやらなくていっか

**デフォルトの名無しさん** · 2022/08/01(月) 20:32:21.83

>>878
それ何てFORTH？

**デフォルトの名無しさん** · 2022/08/01(月) 20:36:12.25

C++11以前から見たら、C++20はやりたかったことが全てできるフルセットの言語になった。
もう使うしかないでしょコレ。

**デフォルトの名無しさん** · 2022/08/01(月) 20:36:36.15

>>880
普通のFORTHです。

**デフォルトの名無しさん** · 2022/08/01(月) 20:38:40.87

>>864
Rustプログラマーは抽象的に開発効率よく非同期プログラミングをすることができる
そこからステートマシンの生成は静的にコンパイラが自動的に行なう
手書きでステートマシンを最速化のために書いたのと同じ結果を得られる
プログラマーはそのステートマシンの存在を知る必要がない
実行時の付加コストもない

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

その手のメタプログラミングするなら・・・
C++しかないでしょう！

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

状態機械を作るときには、状態の圧縮が肝要なので、結局、外部のプログラムが必要になります。
必要にならないというのなら、せいぜい手書きと同レベルのものなんですよ。

**デフォルトの名無しさん** · 2022/08/01(月) 20:54:41.00

>>869
Rustでは抽象的に効率よくプログラミングしてもほぼ最速の結果を得られるようになり
コンパイル時の様々な静的なエラー化により実行時デバッグも激減して開発効率が上昇したよ

**デフォルトの名無しさん** · 2022/08/01(月) 20:56:30.57

>>886
よくわかんないので英語でお願いします。

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

>>884
C++はメモリ解放の自動化ができていないから
プログラミングでもデバッグでも無駄に労力を要して馬鹿らしいよ

**デフォルトの名無しさん** · 2022/08/01(月) 21:06:27.96

std::unique_ptr<>使えば良いのでは？

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

>>863
ス、ス、スウィ？

**デフォルトの名無しさん** · 2022/08/01(月) 21:48:32.95

>>889
C++がダメな点はそれ
1. その面倒な指定が必要
2. それを使い忘れると実行時にアウト
3. 使い間違えると実行時にアウト
4. ムーブの指定なども記述が煩雑
5. それら全て正しく頑張っても所有権の問題を解決してるだけで参照の問題は解決できていない
C++は安全なメモリ自動解放がなされない欠陥言語

**デフォルトの名無しさん** · 2022/08/01(月) 21:49:39.23

>>869
C#の2～3倍
Javaの1～2倍
Cの0.5～0.3倍
C++は幅が広すぎて一般解じゃ意味がない

**デフォルトの名無しさん** · 2022/08/01(月) 21:50:26.57

>>874
やっと気づいたの？

**デフォルトの名無しさん** · 2022/08/01(月) 21:53:44.40

>>891
ダメなら自分で差し替えれば良いのでは？
C++は、それこそメモリー管理をGCに変えることだってできるのだから。

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

>>894
そこで欠陥言語C++を使う意味が全く無い

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

>>892

> ただし、このプログラム言語によって実用的なプログラムを作成するためには、
> C/C++/C#と比較して5〜10倍、Javaと比較して2〜3倍の労力を要する事は事実である。

と説明書に書いてあるよ？

**デフォルトの名無しさん** · 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倍の労力がいるし。
ベンチマーク特化型言語なのに、ベンチマークも遅いし。