次世代言語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(日) 14:06:22.51

令和にもなってC++マンセーする低能クソジャップさん…ｗ

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

Rust、C++、Goで比較すると、地域によって関心度がはっきりと色分けされる。
北米、中国、オーストラリアはGoの関心度が高い。
欧州、カナダ、ロシア、日本はC++の関心度が高い。
ただし、Rustの色はどこにもつかない。（百分の一のボリュームしかないから。）

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

YouTube で有名な雑食系エンジニア・KENTA は、
初心者のキャリアパスは、Ruby on Rails → Go だけと言ってる。
Laravel, Django を使わないように言ってる

Rust, Elixir は、普及のキャズムを越えなかった。
越えたのはGoだけ

でも、Stack Overflow では、Rust, Elixirの人気がトップ。
めちゃめちゃw
初心者をRust, Elixirの仕事で使うわけない

TIOBE は、Rubyは難しすぎて滅ぶから使ってはいけないと言ってる。
KENTA天敵・モローも、YouTubeで言ってた。
Rubyは滅ぶ。これからはJava・PHP の時代だと

それが今になって急に、Railsのキャリア相談までやり出したw
Java・PHPのSES・客先の仕事はどうなったの？w

YouTubeのモローの動画。
【2022年版】Ruby on Railsの将来性

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

>>792
静的解析ツールは役に立たないことも多いうえに面倒
レガシーなC++をさっさと捨てるのがベスト

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

Haskellいいよね

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

えっ

**デフォルトの名無しさん** · 2022/07/31(日) 16:00:43.28

>>799
それはそう言う処理系がまだ作られてないだけで技術的にできない理由はないと思うけど？

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

>>807
それゲームのほうのRustやで

**デフォルトの名無しさん** · 2022/07/31(日) 16:58:04.44

>>815
プログラミング言語のRustと指定できるのですよ。

**デフォルトの名無しさん** · 2022/07/31(日) 17:02:31.12

>>816
ゲームの方のRustで6月頃にYoutuber向けのイベント？か何かがあって急激に検索が増えている
逆に言語の方は特に増える要因はない
つまり「プログラミング言語のRust」という指定でも指定しきれていないということ

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

Google Trendsの詳細データがわからないしなんともいえんね
「日本の友達に聞いたらみんなRust好きって言ってたもん」程度の信頼性

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

まぁなんともいえんのはそう
とはいえGoogle検索に影響するほどバズったQiita記事やら5chスレなんていう
存在しないものを仮定するよりはゲームの影響を排除できてない
と見るほうが自然だろう

**デフォルトの名無しさん** · 2022/07/31(日) 17:27:41.53

キミらって井戸端会議みたいなん好きよね
どっちが人気あるとかどーのとか
技術的な話してるやつ少ないね

**デフォルトの名無しさん** · 2022/07/31(日) 17:35:17.35

>>817
トレンド見たならわかると思うけど、Rustなんて世界では全く注目されていなくて存在しないも同然。
しかし、5chではRust推しが異様に多くないか？
トレンドではGoが注目を浴びていて、Rustは存在しないも同然だぞ。
やはり、日本は特殊なのでは？

**デフォルトの名無しさん** · 2022/07/31(日) 17:40:54.26

そもそもRustは使いたいと思うような特徴が無いんだよな。
何か理由があってRust推ししてる人が、たかだか数人いる状況では？
例えばセミナー商法始めたとか。

**デフォルトの名無しさん** · 2022/07/31(日) 17:55:36.40

>>806
Javaは論外
C#は使っても良い
Pythonは適材適所
C++万歳

**デフォルトの名無しさん** · 2022/07/31(日) 17:55:42.92

Rust本の著者とかが怪しいな。

**デフォルトの名無しさん** · 2022/07/31(日) 17:57:48.82

>>821
5chはNim推し
昔はD推し

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

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