次世代言語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/30(土) 21:32:41.56

>>762
リアルな会話でで　はなはだ　や　こっけい　と言うワードを一切聞いたことがない
おじいちゃん世代かなあ？

**デフォルトの名無しさん** · 2022/07/30(土) 21:32:55.93

>>761

なんでHaskellやScalaはGoよりも前に出てるのにGoだけ流行るの？

シンプルな言語が求められてるからでは？

**デフォルトの名無しさん** · 2022/07/30(土) 21:54:11.36

>>717
OCIコンテナはRust実装あるよ

**デフォルトの名無しさん** · 2022/07/30(土) 22:09:21.95

言うほどGo流行ってないけどな

それに使われてる理由は言語がシンプルだからじゃないんだよな

**デフォルトの名無しさん** · 2022/07/30(土) 22:15:12.45

>>762
Rustを叩くならRustをもう少しちゃんと学ぼうよ
RustのNoneはOption<T>型
つまりT型の変数にNoneは絶対に代入できない
コンパイル時点で静的にNull安全が保証される
もちろん最近の言語は当然備えている必須の性質（退化しているGoを除く）

**デフォルトの名無しさん** · 2022/07/30(土) 23:25:28.07

> 本当のNull安全の意味は、それはNoneでもNilでもなく、関数型言語のように変数の宣言と初期化が同時一体になっている言語のことです。
とかアホなこと言ってる自称熟練プログラマの相手すんなよ...

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

>>767
Noneが代入できる・できないなんて話はしていない。Noneを正確に処理しているかという話をしている、「コンパイル時点で静的に」なんて話もしていない。
Nullを表すことが出来ないという話をしている

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

>>762
キミはNull安全に詳しいんだね
本当のNull安全とやらを見せてくれ

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

>>768
その難解？な文章が理解てきるなんておまえスゴイナー

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

>>769
普通の型(ポインタや数値や文字列など全て)がNullを表すことができないのがNull安全
Null安全な言語でNullを表すときは元の普通の型に対して特殊なNullableな型を用いる
そしてNullableな型はNullableを外して元の普通の型にしないとNullableなままでは元の型として使えない
つまり元の型とは別の型となっているためコンパイラが静的にエラーとすることができる

具体的にはRustならぱ元の普通の型Tに対してNullableな型はOption<T>となりNullはNoneと表記するNull安全な言語
このように表記は異なるがSwiftやKotlinなどもNull安全な言語

一方でGoはNullをnilと表記するがそのnilがそのままポインタなどに代入可能
つまり実行時にヌルポ参照のランタイムパニックが起きるNull安全でない言語

**デフォルトの名無しさん** · 2022/07/31(日) 04:44:43.27

C++20のコンセプトのほうが色々使えて良いのでは？

**デフォルトの名無しさん** · 2022/07/31(日) 05:29:20.33

>>772
>具体的にはRustならぱ元の普通の型Tに対してNullableな型はOption<T>となりNullはNoneと表記するNull安全な言語
なんだよこの説明ｗ
おっさんもNull安全の意味わかってねーじゃん
長文書く度に墓穴掘るな

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

>>774
KotlinやSwiftといったNull安全な言語は全て同じその方式だぜ
T型にNullは許容されず、Nullable<T>型にのみNullを許容
両者の型を厳格に区別することでNull安全を保証
Nullable<T>型は言語毎に記述が異なり「T?」型だったりOption<T>型だったり様々

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

その程度ならtype_traitsで十分では？

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

C++は何でもあるとともに、ほとんどの機能は皆に使われない、失敗した言語
言語の機能は有効に洗練して採り入れてこそ、初めて意味を持つことを示した反面教師
Null安全に関しては、言語としてNull許容を制限できなければ意味を持たず、C++はもちろんNull安全ではない

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

でも、C++そのものは、みんなに使われてるよね？
Rustが足元にすら近づけないほどに。

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

>>778
だからなに？
使われてて色々欠点も見えてきたから新しい言語が作られてるわけで

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

C++で使われない機能を主役にした言語を作っても使われないのでは？
実際、使われていないし。

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

なんだかんだ言ってC++は強力で便利なんだよな。
自分のやりたいことが実現できる。

何でもできるのは良くないことだから機能を制限するのは理論的に正しいのかもしれない。
しかしそれが使われるようになるのは難しいと思う。

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

>>781
C++が失敗したから山のように様々な言語が出来てきた
C++は何でも出来るのではなく整理されていない後付け機能が多数あるだけ
ようやくC++と同じ速度で動く諸言語が出揃ったので過去からの蓄積維持を除いて今後はC++を使うメリットは全く無い

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

C++はあからさまに成功した言語だと思いますが。

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

++してないC言語は今でも組込みやらカーネル界隈では現役バリバリだけど
C++として使ってるものに関しては必ずしもC++でやらなきゃいけないわけじゃないんだよな

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

みんなの共通認識
C言語は1階平屋の素朴だけど長く住めるしっかりした家
C++はそこへ2階3階とどんどん縦へ建て増し横にも増築と違法建築状態のダメな家
部屋は大量に増えたけど住みにくいので使われていない部屋が多数

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

>>780
> C++で使われない機能を主役にした
なんの事を言ってるの？
それあなたが（批判するために）勝手に主役だと思ってるだけじゃないの？

**デフォルトの名無しさん** · 2022/07/31(日) 10:36:19.32

>>775
おっさんほんとに不勉強だな
そんなんじゃ新人にもバカにされるぞ

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

C++20のコンセプトのほうが良いのでは？

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

C++にborrow checkerがあればC++でもいいかもな

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

静的解析ツール使えば良いだけでは？

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

Null安全は次世代言語に必須だな
これを省くメリットはない

>>790
ツール不要
Null安全な言語ならコンパイラがエラーとて指摘する

**デフォルトの名無しさん** · 2022/07/31(日) 12:24:56.81

静的解析ツールなら、コンパイラとは次元の違うレポートを得られる。

**デフォルトの名無しさん** · 2022/07/31(日) 12:28:11.09

静的解析ツールタダじゃないじゃん。やたら時間もかかるし。

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

>>792
C++でCoverity使ってたけどそれでもメモリー安全とかヌル安全は完璧には捉えられなかったけどね
完璧に捉えられるツールがあるなら教えてくれ

>>793
Coverityは差分解析とかもできるからそんなに時間がかかるって感じはしなかったけど

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

なんで仕事でもないのにC++使うんだろ
何にも意味がないのに

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

高抽象度なものはC++向けのインターフェースしか提供されてなくて、自前でCからのFFIラッパー書かなきゃないけないけど書きたくないからかな……

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

既存のOSSがC++が多いからな
みんなRustに移植されてればいいのに

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

>>795
何でもできるからでは？

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

極端な話、高位合成によってC/C++をハードウェア記述に使うことが当たり前に行われているけども、Rustでは無理でしょう。

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

でもRustはメモリが安全だよ

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

2021年秋にRustへの移行を発表して以来、Metaの時価総額はどんどん下がってますしね。
市場の評価は正直だと思いますよ。

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

>>797
いうほどC++のOSSって多くないような…

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

Rustへ移行する。
↓
お花畑系か？
↓
企業価値が下がる。

当然の成り行き。

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

メタクエスト2とか1.5倍以上に値上げするのを発表したばかり
売り上げが下がってもおかしくない

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

https://trends.google.co.jp/trends/explore?q=%2Fm%2F0dsbpg6,%2Fm%2F0jgqg
どうやらRustは日本でだけ突出して関心を集めてるようだけど。

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

メモリリークするかもしれないC++を使う理由は本当にあるのか？
pythonやjavaやC#
それか次世代言語使えばいいじゃないか？

C++使う意味は本当に薄れてる

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

誰か仕掛け人がいるんだろうな。
地域を日本に限定すると、6月初めに急激に検索ボリュームが増えて、その後低下し始める。
この時、何かがあったのであろう。
本の宣伝のためにQiitaで記事を書くとか、5chでスレ立てとか。

他の国では一貫してGoのようなライバルより検索ボリュームが低い。
10倍とかではなく、たとえばGoと比較すると、Rustは100倍ほど検索ボリュームが低い。

ところが日本では6月に一時的とはいえ、RustがGoを超える。
100倍の差を乗り越えて。
韓国面に落ちてそう。

**デフォルトの名無しさん** · 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スケジューラーの実装標準搭載要望が多いのか？