次世代言語23 Go Nim Rust Swift Kotlin TypeScript

**デフォルトの名無しさん** · 2021/11/28(日) 16:59:19.16

スレタイ以外の言語もok

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

**デフォルトの名無しさん** · 2021/11/28(日) 17:09:04.49

▼スレタイ言語ランキング
1位：Rust（22回 Part1〜）
2位：Go（16回 Part1〜）
3位：Kotolin（15回 Part4〜）
4位：TypeScript（15回 Part7〜）
5位：Swift（11回 Part7〜）
6位：Haskell（7回 Part7〜）
7位：Scale（5回 Part1〜）
8位：Elixir（4回 Part1〜）
9位：Dart（3回 Part9〜）
10位：Julia（3回 Part14〜）
11位：Nim（3回 Part21〜）
12位：Erlang（2回 Part1〜）
13位：Crystal（1回 Part14〜）
14位：Bosque（1回 Part17〜）
15位：V（1回 Part19〜）

**デフォルトの名無しさん** · 2021/11/28(日) 19:49:59.38

Zigて候補になる？

**デフォルトの名無しさん** · 2021/11/28(日) 20:15:17.89

>>3
泡沫言語だけどわりと海外のossで使われてるの見るよ
NimやVなんかより有望だと思う

**デフォルトの名無しさん** · 2021/11/28(日) 23:04:48.66

IT業界の状況

プログラミング言語「Rust」のための「Rust Foundation」設立 -- AWS(Amazon)、Microsoft、Google、Mozilla、Huaweiが創設
https://japan.zdnet.com/article/35166267/

Facebookが「Rust Foundation」に参加
https://japan.zdnet.com/article/35170192/

**デフォルトの名無しさん** · 2021/12/01(水) 20:52:58.23

最も勢いのあるプログラミング言語は？：全世界2万人弱の開発者を調査
https://atmarkit.itmedia.co.jp/ait/articles/2112/01/news135.html

**デフォルトの名無しさん** · 2021/12/01(水) 20:56:51.44

JavaScriptはブラウザが解する言語がそれしかないから人気と言うか使わざるを得ない

**デフォルトの名無しさん** · 2021/12/01(水) 21:06:10.70

rust単調減少やん

**デフォルトの名無しさん** · 2021/12/01(水) 21:10:31.52

単調非増加では？
というのはさておきDart人気なんだね

**デフォルトの名無しさん** · 2021/12/01(水) 21:50:01.36

rubyやobjective-cより下の13位から上がるどころか新規のdartに抜かれて14位に落ちてるんだがｗｗｗｗ

**デフォルトの名無しさん** · 2021/12/01(水) 22:54:31.76

>>6
TIOBEより納得できる結果だけどDartはなんで伸びたの

**デフォルトの名無しさん** · 2021/12/01(水) 23:04:28.42

DartにはFlutterっていうキラーアプリがあるからね
みんなFlutter使いたくてDartを使ってるだけっしょ

**デフォルトの名無しさん** · 2021/12/02(木) 00:48:53.78

>>6
> ・Rust
> 　過去2年間、他のどの言語よりも急速にユーザー数を伸ばしている。
> 　Rustを使う開発者は、2019年第3四半期には40万人だったが、2021年第3四半期には110万人に達し、ほぼ3倍に増えた。

すごい勢いで増えているね。

**デフォルトの名無しさん** · 2021/12/02(木) 01:20:43.38

rustは元がゴミすぎて3倍近く増えても順位は上げられずdartに瞬殺されて順位落としてるじゃんｗｗｗｗ

**デフォルトの名無しさん** · 2021/12/02(木) 01:37:10.86

visual development toolsって何？

**デフォルトの名無しさん** · 2021/12/02(木) 01:40:17.24

Flutterらへんのカテゴリは、システムプログラミングらへんとはユーザ数が桁違いだからな

**デフォルトの名無しさん** · 2021/12/02(木) 01:40:43.38

ユーザというか開発者数ね

**デフォルトの名無しさん** · 2021/12/02(木) 02:38:45.32

むしろdartが大復活したのすげえわ

**デフォルトの名無しさん** · 2021/12/02(木) 09:23:40.40

flutterなんて流行り始めてしばらく経つけどほとんど出てきてないし、どの言語もguiのbindingくらい持っているんだが
dartは昔から何かと出てきたけど、flutterで注目されて爆発したイメージ
何にせよrustは元々ゴミで注目された今もゴミということ

**デフォルトの名無しさん** · 2021/12/02(木) 09:28:58.92

Rubyがいよいよ本格的に死にそう

**デフォルトの名無しさん** · 2021/12/02(木) 10:03:46.89

>>13
やっぱRust凄いな
完全に次世代言語の本命確定か

**デフォルトの名無しさん** · 2021/12/02(木) 11:01:41.70

数だけで優劣が決まるならJSの圧勝だね
Rust理解できない子が、大歓喜するのも仕方がない

**デフォルトの名無しさん** · 2021/12/02(木) 12:01:49.37

でも >>6 のデータを見ると、SwiftやGoの半分ほどもRust開発者いるの？って思ってしまうなあ
自分の身近が偏ってるだけで、どこかにはRust開発者がたくさんいるんだろうか

**デフォルトの名無しさん** · 2021/12/02(木) 12:36:46.06

バックエンドだけでなくフロントエンドもRustで行こうという話も出てる

**デフォルトの名無しさん** · 2021/12/02(木) 12:52:13.85

rustで書かなきゃならんほどランタイム速度必要なとこなんてほぼないけどな。
組み込みにはメモリデカすぎだし、数値計算、アルゴリズム分野じゃ共有のめんどくささから使われんし、
本当にごくごく一部しか使い道がない。
ほとんどはファッションでrust理解してる俺すげーーしたいだけのカスユーザーだろ。

**デフォルトの名無しさん** · 2021/12/02(木) 13:02:43.82

現状C++じゃない領域にも適用しようといてるん？
個人的にはエンジニアの底上げになってうれしいけど

**デフォルトの名無しさん** · 2021/12/02(木) 13:10:28.97

discodeはバックもフロントもgoからrustに移行したな
遅延がサービス品質に直結してるようなアプリなら移行する価値があるんだろう

**デフォルトの名無しさん** · 2021/12/02(木) 13:12:35.29

逆にフロントエンドだけでなくバックエンドもDartで書こうという話も出てる
書けるようになったから書いてねという発表があった程度だけど

**デフォルトの名無しさん** · 2021/12/02(木) 13:27:17.82

Ruby on RailsのクックパッドもバックエンドをRustにしてたな

**デフォルトの名無しさん** · 2021/12/02(木) 13:48:49.03

>>25
それはアンチ的視点だからそんな偏った見方になってしまうのであって
現実にはどの分野でもRustに置き換えるとかなり高速化されるか
あるいは旧C/C++分野ではかなり安全化されるのでその両分野からじわじわと話が出てる

**デフォルトの名無しさん** · 2021/12/02(木) 13:56:00.28

実際にはRustほどのパフォーマンスがいらなくても
型が強くてそこそこ速いって選択肢があまりないんだよな
Goくらいの速度でいいとしても、あの言語機能には
耐えられないって場合はRustになってしまう
ランタイムありで良ければJVM系とかC#もいいんだけど

**デフォルトの名無しさん** · 2021/12/02(木) 14:41:59.12

C++の巨大プロジェクトは絶対にメモリ関連のバグがたくさんあるからな・・・。

**デフォルトの名無しさん** · 2021/12/02(木) 14:54:42.94

C++とtypescriptやってる人は大抵rustもやってそう
>>25の意見は正しいと思う
rust推しだったけど意味不明な推しが多くて最近はもうgoでいいって思った

**デフォルトの名無しさん** · 2021/12/02(木) 15:11:50.02

>>31
それはある
強力な型の扱いや関数型言語に近い性質などが非常にプログラミングしやすくてRustは言語のセンスが良い
高速になるとか安全になるとかはオマケとして付いてきたｗ

**デフォルトの名無しさん** · 2021/12/02(木) 15:33:13.06

そこがおまけならnimとかでいいじゃん

**デフォルトの名無しさん** · 2021/12/02(木) 16:27:40.33

Rustはシャローコピーに関する地雷を極めて踏みづらいのはメリットかな

**デフォルトの名無しさん** · 2021/12/02(木) 16:28:07.24

NimはRustのような値付きenum及びそのパターンマッチングがないから使えん
Nimだとオブジェクトバリアントが限界で機能不足

**デフォルトの名無しさん** · 2021/12/02(木) 16:32:00.04

どちらもどうでもいいよそんなの趣味の範疇
オマケだというならgoの圧勝で終わり

**デフォルトの名無しさん** · 2021/12/02(木) 16:38:10.56

Goはそういう点ではNimよりも機能不足

**デフォルトの名無しさん** · 2021/12/02(木) 16:50:11.44

そんなの趣味嗜好の範疇なんだってｗ

**デフォルトの名無しさん** · 2021/12/02(木) 16:50:41.52

パフォーマンスどうでもよくて、そういう好みなら、ScalaとかHaskellが合うかもね

**デフォルトの名無しさん** · 2021/12/02(木) 17:02:19.38

ある意味
Haskellから美味しい部分をもらってきた手続き型言語がRust

**デフォルトの名無しさん** · 2021/12/02(木) 17:12:39.13

そうね、Rustはいろいろなシンタックスが用意されててすごいよ

パフォーマンスがどうでもいいなら、borrow checkerとかで安全にしてるRustより、
GCを使いつつ参照透過性を保つHaskellのほうがいろいろ整然とされてて見通しが良い気がする

まあいろいろ好みや、向き不向きとかあるだろうけど

**デフォルトの名無しさん** · 2021/12/02(木) 17:17:04.28

>>40
Goの機能不足は誰もが認める合意事項
だからこそGo2作っているわけで

**デフォルトの名無しさん** · 2021/12/02(木) 18:08:26.45

Nimも機能少ない方だから、Goでいいじゃんってなりがち
そういう意味ではGo/Rustの次世代って難しいな
GoとRustでシンプルと複雑の限界まで振ってあるから
その中間解を取ってしまうと中途半端になるという

**デフォルトの名無しさん** · 2021/12/02(木) 18:51:26.15

goはテンプレート有れば私的には文句ねぇが現今のinterfaceのアプローチと異なる且つ重複する部分が多くきな臭いよね
ただまぁあそこまで洗練されたcoroutine featureは他に見ないしgcの改良だけでもいいかなとも思う

**デフォルトの名無しさん** · 2021/12/02(木) 19:24:47.38

nimはオリジナリティがなく器用貧乏な感じ
golangだけでなくどの言語も独自の進化を続けているだけで機能不足なわけじゃない
rustは高速性と安全性を取ったら何も残らないゴミクズ

**デフォルトの名無しさん** · 2021/12/02(木) 19:39:44.60

元rust推し装うの笑う
もう流れはとめられんよ

**デフォルトの名無しさん** · 2021/12/02(木) 19:42:44.71

>>47
Go信者は根拠なくデタラメに他言語たちを罵倒するのはどうして？
理解できないから具体的に指摘できないため？

**デフォルトの名無しさん** · 2021/12/02(木) 19:57:21.48

あわしろ氏はRustを使うべきと言ってる。

**デフォルトの名無しさん** · 2021/12/02(木) 21:14:08.06

元々rust推しなのは事実だからなｗ
ただ俺が推してるのはごくごく一部の高スループットや巨大データを扱うサーバーやデータベースなどの分野であって
OSなどハード寄りや普通のアプリで向いているとは思っていない
rustの流れなんて誰も作ってないし意識もしてないと思う
自然に流れが出来るなら流れに任せるけど違和感しかなければ推せなくなる
根拠がないのは客観的な話ではなく、主観をそのまま言ってるからだよｗ
あと俺はgo推しじゃないし、汎用なやつだと消去法で総合的にgoのコスパが一番いいと思ってるだけ

**デフォルトの名無しさん** · 2021/12/02(木) 21:28:41.46

>>51
具体的にRustを使って何が問題なのかをどうぞ
コピペでは無理な具体的かつ詳細な説明をお願いします

**デフォルトの名無しさん** · 2021/12/02(木) 22:01:59.81

Nimは言語自体の機能は必要最低限にしてtemplateやmacroでユーザが自由に言語の機能を拡張できるようにしようという考えだから。

**デフォルトの名無しさん** · 2021/12/02(木) 22:14:35.17

分かるだろｗ議論しても荒れるだけだから無駄
大雑把に言って初心者に難しい理由の説明しづらいルールが多いから一般向けに流行らないということ
nimについてはそうだね

**デフォルトの名無しさん** · 2021/12/02(木) 23:08:40.70

ゴミクズとまで言い切った割には普通の話だな…
PythonやJSから入った初心者に勧めるならそりゃGoだろう

**デフォルトの名無しさん** · 2021/12/02(木) 23:59:00.94

そうだよ大雑把な話でないと定義や粒度が合わなくてそもそも話せないからな
あとrustから「高速性と安全性を取ったら」って前提を抜かないでゴミクズだけ引用しないでくれ

**デフォルトの名無しさん** · 2021/12/03(金) 00:16:18.89

こいつネット記事で聞き齧った程度の
浅いことしか言えてないし
実際はrustで hello world 書いたことすら無さそう

**デフォルトの名無しさん** · 2021/12/03(金) 00:17:26.23

遅くて安全じゃない言語は元がなんであれゴミクズなんでは...

**デフォルトの名無しさん** · 2021/12/03(金) 04:23:17.06

何をもって「安全」とするのやら
非同期回りも含めるとスクリプト系だいたい全部アウトになります？

**デフォルトの名無しさん** · 2021/12/03(金) 04:45:15.91

なんのことやらしらんけど、Rustや他の参照透明性のある言語のことを言いたいのかな

**デフォルトの名無しさん** · 2021/12/03(金) 04:47:18.61

安全な言語、について

**デフォルトの名無しさん** · 2021/12/03(金) 08:53:10.36

>>59
マルチスレッドでのデータ競合を入れるならコンパイル型もほぼアウト
実際静的にチェックできるのはRustくらいじゃない？
Goなんかはgoroutineで気軽にデータ競合しうるから、コンパイル時にチェックできるといいんだけどなぁ

**デフォルトの名無しさん** · 2021/12/03(金) 09:07:52.00

で、具体的にお前は何をrustで作ってんの？

**デフォルトの名無しさん** · 2021/12/03(金) 09:14:09.01

>>57
その人とは別人で悪いが、Rustでは最早ハロワを自分で書く必要がない

**デフォルトの名無しさん** · 2021/12/03(金) 09:15:22.04

またしょうもない定義の話になってるし・・・
分かれよｗ変なところに噛み付いてないで自分の意見をちゃんと言え

**デフォルトの名無しさん** · 2021/12/03(金) 12:02:53.40

rustは言語処理系書きやすい
安全性とか高速さは関係なくて代数的データ型が使いやすければ他の言語でも代替はできるとは思うが
rustが一番使い慣れてるのでrustで書いている

**デフォルトの名無しさん** · 2021/12/03(金) 15:17:45.07

データ競合については、Haskellとかも起きないよね

**デフォルトの名無しさん** · 2021/12/09(木) 00:24:44.17

rustは言語仕様以外の点がな..
https://sabotage-linux.github.io/blog/3/
https://blog.adelielinux.org/2017/11/18/our-official-stance-on-the-rust-programming-language/
https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedom_flaws

**デフォルトの名無しさん** · 2021/12/09(木) 01:13:30.58

このスレの言語で挙げられてる問題すべて解決してるものある？
NimはCにコンパイルされるからブートストラップの問題も対応アーキテクチャの問題もなくなるのかな？

**デフォルトの名無しさん** · 2021/12/09(木) 02:43:44.63

これRustなんだね
https://github.blog/2021-12-08-improving-github-code-search/

**デフォルトの名無しさん** · 2021/12/09(木) 12:38:32.33

むしろブートストラップの問題が表面化してる点はもうrustの圧勝って話に見える

**デフォルトの名無しさん** · 2021/12/10(金) 10:43:45.25

>>69
Nim言語のコンパイラはNim言語で書かれているんだけどCコンパイラさえあればビルドできるようになっている。
Nimコンパイラをソースコードからビルドするときは、Nimのコンパイラから出力されたC言語のNimのソースコードのリポジトリnim-lang/csources_v1をビルドしてから最新のNimコンパイラをビルドするようになっている。
https://github.com/nim-lang/Nim#compiling

**デフォルトの名無しさん** · 2022/01/26(水) 05:57:30.61

サーバーサイドは本当にGoが丁度いいな
typescriptと構文にてるし、node.jsから移行しやすいのが最高

**デフォルトの名無しさん** · 2022/01/26(水) 20:59:23.59

NimがGoとRustの間を縫って次世代トップに躍り出る予感
巨大IT企業のバックアップが付けば一気に跳ねると思う

**デフォルトの名無しさん** · 2022/01/26(水) 21:09:35.46

GoやRustと比べると言語としての魅力がよくわからないんだよな。
オフサイドルールスキー専用言語？

**デフォルトの名無しさん** · 2022/01/26(水) 21:25:25.23

Nimなんか別に誰も使ってないし特に期待もされてないでしょ
世の中に山ほどある俺言語の一つに過ぎないよ

**デフォルトの名無しさん** · 2022/01/26(水) 21:59:22.52

Nimはわざわざ選択する理由がないんだよな
楽に書くならGoだしちゃんと書くならRustなわけで
もうちょっと特徴が欲しい

**デフォルトの名無しさん** · 2022/01/26(水) 22:07:13.93

1. 実行速度、バイナリサイズ、メモリ使用量
→CトランスパイルなのでCに近い値

2. 安全性
→メモリ安全性高い

3. 生産性
→スクリプト言語並み

4. 機能性
→シンプルな機能と、強力なメタプログラミング

Nimは1・2と3の両立性が高く、比肩する言語が無い
3と4は常にトレードオフなので正解が無いが、Nimの割り切り方は良い

**デフォルトの名無しさん** · 2022/01/26(水) 22:16:29.06

GoもRustも実行速度とメモリ使用量が大きすぎるし、C/C++は生産性や安全性に問題が大きすぎる
その打開策としてNimを使う事ができる

複数言語を使い分けるよりも、1つの言語でまかなえるならば、学習コストや再利用性の面から越したことはないしね

**デフォルトの名無しさん** · 2022/01/26(水) 22:23:32.14

ただ他の言語と違ってコミュニティが貧弱すぎるのが欠点
言語性能自体とは直接の関係はないが、こればっかりは痛い
大手企業とか人気ソフトに使われる様なきっかけが無いと永遠に人気に火がつかないままだと思う

Go/Dart/KotlinはGoogle、Rust/JuliaはMozila、SwiftはAppleの後押しがあるけど、Nimは一切そういうの無くて、コアな人気だけが細々と支えてる状態

**デフォルトの名無しさん** · 2022/01/26(水) 22:32:35.02

>>79
NimってRustより速くてメモリ使用量少ないの？

**デフォルトの名無しさん** · 2022/01/27(木) 00:32:14.69

>>78
1と2ってGo/Rustくらいの世代だとほぼ標準装備なんだよね
そりゃ多少の優劣はあるだろうがアプリの特性差やプログラマのスキル差から考えると誤差
そうすると構文が一部の人にマッチするって部分しか残らない感じ

**デフォルトの名無しさん** · 2022/01/27(木) 09:11:54.39

Rustのメモリ使用量が大きいとかヤバイな

**デフォルトの名無しさん** · 2022/01/27(木) 09:32:04.47

nimはd言語の二の舞

**デフォルトの名無しさん** · 2022/01/28(金) 09:21:04.21

nimは、goと比べると今風の書き方が出来るのが良いかな。
でも、コミュニティが弱いのが辛い。

**デフォルトの名無しさん** · 2022/01/31(月) 06:52:54.15

https://kdy1.dev/posts/2022/1/tsc-go
tscの型チェック機能をgoで書き直すらしい、vercelが支援してるみたい
初めはテストとしてrustで書き直して型チェック速度が62倍になって
ただ、rustで書き直すのは適していないと考えてgoに移植することを選択したと

フォーラム https://news.ycombinator.com/item?id=30074414

**デフォルトの名無しさん** · 2022/01/31(月) 07:42:59.19

>>86
要約

一部Rustで書き直してテストしたら62倍速となり当然速かったけど
tscのコード全体がGCに依存しまくっているため移植ではなく全面書き直しとなってしまう
そこで妥協案としてGCで動作するGoへ移植することにした

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

こんなもん本家の開発についていけなくなって早晩放棄されるのが目に見えてるだろ
まだRustだったらMSが支援してくれる可能性もあったかもしれないけどね
完全に手段が目的化している不毛なプロジェクトの典型だな

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

SASS なんて、元々のRuby から、
多言語でも使えるように、C++ のnode-sass（LibSass）へ移植したけど、
開発が難しすぎるから、頓挫した

今は、Dart Sass

Dartもマイナーな言語だし、
TypeScript か何かで作らないと、また開発に行き詰るかも

C/C++, Rust など実行速度が速い言語は、開発が難しすぎる。
可読性が悪く修正できないので、開発費・開発期間が増える

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

>>89
C/C++の可読性の悪さは
Rustで改善されていてとても使いやすくなっている
GC依存で設計された既存システムをそのまま移植するのは無謀だが
最初からGCに依存せずに設計が可能でありRustなら可読性が問題になることはない

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

自分はRustのCargoとその気になればunsafeで自由に書けるのが気に入ってる
Rustはとにかく美しいと思うな

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

たしかに、Cargoらへんのエコシステムに関してはC++とは勝負にすらならないな
npmを反面教師にしたのかな、よくできてるよね

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

Rustが美しいと思うのはどういう点なのか、具体的に聞きたくなる。これはC/C++と比べてる話じゃなく現代的な言語の話で
無駄にタイプ量が多くマクロと言語が一貫してなく、アトリビュートも独立しおり言語との一貫性が全くない

**デフォルトの名無しさん** · 2022/02/01(火) 14:17:41.49

例えば const fnやコンパイル時定数などはコンパイル時にコードを動かして計算したりするが、一方でアトリビュートで
#[cfg(unix)]とかやったりして思想がバラバラ、まあ破綻はしてないしC/C++のマクロなんかと比べれば100倍ましだけど

**デフォルトの名無しさん** · 2022/02/01(火) 14:19:22.77

>>93
型推論も賢く強力な静的型付け言語なのにタイプ量は少ない
アトリビュートが言語本体と独立していて区別しやすくプログラミングする上で見やすい

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

>>93
マクロと言語が一貫してる言語ってどういうイメージなんだろう
Lispしか思い浮かばなかったけどさすがに違うよね

**デフォルトの名無しさん** · 2022/02/01(火) 19:27:41.48

>>92
Cargoが良すぎて今まではちょっとしたスクリプトをPythonで書いてたのだけど
そういうのも全部Rustで書くようになってしまった

>>93
むしろこのアトリビュートが好きで
同一ファイルにtestをちゃちゃっと書けるのだったり
あーこれこれ、こういうのが欲しいんだよってのがほぼ全て揃っている

大小様々なソフトウェアを書くためにやっと人類が手に入れた言語かなって
だがなんかマンセーしすぎてスマソ

**デフォルトの名無しさん** · 2022/02/02(水) 09:03:27.50

Rustの長い長い型名
https://qiita.com/mp2147483647/items/4cc56b0cc80369828a88

**デフォルトの名無しさん** · 2022/02/02(水) 20:32:31.23

>>93
マクロはRustの言語ルールを満たしていなくてよいところが要点
その定義文法も変換が主たるものだから別記法が理に適っている

>>98
Rustは強力な静的型付けにより安全と効率を両立させている
結果としての型名が長くなることがあっても
強力な型推論およびトレイト静的実装型宣言により実際の型名を記述する必要がない
その例は極端な特殊な例にも関わらず同様にして最終型名を記述せずに済んでいる

**デフォルトの名無しさん** · 2022/02/03(木) 02:33:37.86

もしかしてrustってめちゃくちゃ完成度高くね？
バックエンドだけじゃなくて
wasmでブラウザのフロントエンドにも進出してくるっぽいし
typescriptのシェアも奪いそう

**デフォルトの名無しさん** · 2022/02/03(木) 11:10:49.98

Go人気らしいけど嫌い
やっぱりC++使いはRustに行くべきなんかな

**デフォルトの名無しさん** · 2022/02/03(木) 11:48:25.31

Rust、アルゴリズム書くのに超絶向いてないよ。

**デフォルトの名無しさん** · 2022/02/03(木) 13:51:46.29

アルゴリズム書くのは普通疑似言語でやるわな

**デフォルトの名無しさん** · 2022/02/03(木) 17:00:23.94

>アルゴリズム書くのは普通疑似言語でやるわな
何言ってんの？

**デフォルトの名無しさん** · 2022/02/03(木) 18:00:00.71

アルゴリズム自体の記述には自然言語か疑似言語かpythonみたいなスクリプト言語使うのが多いのでは

｢アルゴリズムを書く｣ってアルゴリズムを使ったプログラムを書くという意味？
そうだとしたら対象が広すぎるのでもうちょっと具体化して欲しい

**デフォルトの名無しさん** · 2022/02/03(木) 18:01:17.86

そんなしょーもない誤魔化しはしなくていいよ。

**デフォルトの名無しさん** · 2022/02/03(木) 18:07:41.52

アルゴリズムと一概に言ったってソートみたいなのは別にrustでも普通に書けるでしょ
どういうアルゴリズムを実装しようとして困ったのか教えて欲しい

**デフォルトの名無しさん** · 2022/02/03(木) 18:24:36.45

じゃあB-tree、赤黒木、ダイクストラ、フィボナッチtree、なんでもいいから書いてみりゃいいよ。

**デフォルトの名無しさん** · 2022/02/03(木) 18:28:40.55

木構造やグラフ構造が書きづらいって話かな

**デフォルトの名無しさん** · 2022/02/03(木) 18:59:23.99

変な日本語だな
アルゴリズムの勉強には向いてない、ということを言いたいんだろうけど

**デフォルトの名無しさん** · 2022/02/03(木) 19:05:25.62

どうでもいいイチャモンづけにこだわるやつだな。。
だから実際組んで見ろって。。何もしないくせに。

**デフォルトの名無しさん** · 2022/02/03(木) 19:12:44.13

新しいrustの弱点の話聞けるかと思ったら結局いつものグラフ構造の話だったので興味を失ってしまっただけです

**デフォルトの名無しさん** · 2022/02/03(木) 19:23:59.05

>>112
Rustでキューとかスタックとかって便利に使えるの？

所有権の関係で、要素をいじるときはpopしてから操作するのかしらん？

**デフォルトの名無しさん** · 2022/02/03(木) 19:34:47.62

>>113
普通は get_mut に類するメソッドが用意されててコレクションから取り出さなくても編集できるはず
同じコレクション内の他の要素への参照を持たせようとすると難しいかもね

**デフォルトの名無しさん** · 2022/02/03(木) 19:51:02.49

>>114
サンクス。
さすがにスタック・キュー(所有者)に要素の操作を移譲するようなことはしないか。実用上は妥当なところか。

**デフォルトの名無しさん** · 2022/02/03(木) 19:57:30.61

>>113
言語と切り離して論理的に考えた時に
安全な構成と操作ならばRustでも簡単
危険な構成や操作ならばRustでは出来ない(unsafe使えばCと同じ操作が可能)

さらに加えて
危険な構成や操作に成り得るが
限られた一貫した用い方をしている限り安全な場合
新たな型を作って危険な操作を内部に閉じ込めてしまい
安全な操作のみ外部に提供することで利用者はunsafeを用いずに済むことができる
Rustの標準ライブラリもそのようにして作られている

**デフォルトの名無しさん** · 2022/02/03(木) 23:53:53.52

>>112
毎回そうやって曖昧にして逃げてるんだね。進歩ないね。

**デフォルトの名無しさん** · 2022/02/04(金) 00:36:32.80

>>117
そこはグラフも表現できないクソ雑魚言語乙ってあおるべきなのになんで下手くそな人格攻撃してしまうのか

**デフォルトの名無しさん** · 2022/02/04(金) 12:24:28.50

具体的にするならミュータブルなグラフ構造をスレッドセーフに扱うのは人類が思っている以上に難しいことで、それを言語側の制約で扱うならこうならざるを得ないくらい難しい問題だ、ということではないの？

**デフォルトの名無しさん** · 2022/02/04(金) 13:24:42.43

例えば何かノードをたどっている最中にいつの間にか戻り先が変わってるとかいちいちケアしてコード書けないから、結局排他処理やスナップショットすりなんらかの工夫が必要
データ構造の操作だけ完璧に仕上げても応用きかないからそこまで深く考える必要ない

**デフォルトの名無しさん** · 2022/02/04(金) 15:25:21.40

そうね
スレッドセーフを諦めれば他の言語に近いくらいに簡単にできるのではないか

**デフォルトの名無しさん** · 2022/02/04(金) 15:44:53.55

C言語→Rustするトランスパイラーですべて解決じゃね？
Rustだからメモリも安心安全だぞ

**デフォルトの名無しさん** · 2022/02/04(金) 17:43:24.41

>>95-99
今どきのコンパイル型言語で型推論が強力でない言語なんてありますか？#[attribute(key = "value", value2)]とか書いててタイプ量は少ない？
最近は自作のアトリビュートが書けるようになりましたが、普通は言語サブセットは小さくして、そのサブセット言語でアトリビュートを実現してれば
このように無理やりカスタムアトリビュートを出す必要はなかった。
一番の最低なところはCargoだと思う、これのせいでコンパイルが異常に遅い。Pythonでもpipやデコレーターはありますがホントにマンセーですね
マクロの定義文法も変換が主たるものだから別記法が理にかなっているとの事ですが、設計段階では、そんな事は一言もホアレは
言ってません。0.2でクラスが導入され、0.3でインターフェースが導入され、0.4でトレイトが出来てクラスが削除された。1.0以降も酷い互換性の
破壊が続いて、安定しだしたのは1.20以降です。
個人的に気に入らないのはfunctionはfnとするのにmutableはmutと使用頻度が高いものがfnよりタイプ量が多い事。「::」も無意味に
2回打たせる意味が分からない。アトリビュートも#[...]とか異常に無駄。ほかの言語のようにパターン束縛表現があるので@は使えませんが
「#」だけで良いでしょう・・・
確かにマクロ呼び出しは「!」とわざと区別するように思想が影響していますが、マクロ中の$はマクロ展開ではコンパイラを単純化させて
コンパイルを速くするためだけにプログラマへ負担を押し付けているだけです。ただ「!」もNeverと別の意味があり、暗黙の型強制なんて
わざと敷居を高くすることに言語設計者は考えているとしか思えない
Occamで最初のバージョンが作られたけど、インデントスタイルのオフサイドじゃなくC/C++風にしたのは、好みで｛｝スタイルを好む人が
多いから（タイプ量は増えますが）許容範囲でしょうが・・・

**デフォルトの名無しさん** · 2022/02/04(金) 17:50:56.66

趣味・好みじゃなくて問題があるという話なら
なぜ本家じゃなくここに書くw

**デフォルトの名無しさん** · 2022/02/04(金) 18:12:52.54

0.2からおっかけてたのならattributeの文法議論の時にそれ主張しとけば良かったのに

あとcargoのせいでコンパイルが遅くなるというのはどういうこと？
パッケージマネージャーがあるせいでcrateが細分化されてリンク時間が延びることを言いたい？

**デフォルトの名無しさん** · 2022/02/04(金) 19:21:26.70

>>123
Rust 1.0がリリースされた2015年よりも昔の0.x時代の話で叩いても無意味ですぜ
あとは1文字タイプ量が多いとかどうでもよい話ばかり
言語機能については批判がないということはRustの優秀性を認めてるわけか

**デフォルトの名無しさん** · 2022/02/04(金) 23:40:44.00

Rust並に実行速くて
Rustよりもプログラミングしやすい言語がない
結果として現時点でのベストな選択肢はRust

**デフォルトの名無しさん** · 2022/02/05(土) 00:06:09.72

c言語の型宣言も後置にしてくれねーかな。

**デフォルトの名無しさん** · 2022/02/05(土) 08:13:51.74

Rustの唯一の欠点は、メモリ管理をしないといけないところだな。
ここも選択肢を用意してくれれば良いのに。

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

手動でメモリ管理したい人向けの言語に何言ってんだ

**デフォルトの名無しさん** · 2022/02/05(土) 12:03:26.16

そうは言っても、メモリ管理したい人って需要少なくない？
今のままでは、C.C++代替以上にはなれない気がする。

**デフォルトの名無しさん** · 2022/02/05(土) 12:54:51.75

それ以上に何を求めるってんだ

**デフォルトの名無しさん** · 2022/02/05(土) 13:14:08.46

言うほどメモリ管理してるか？RAIIとスマポに頼りっきりのくせに
参照カウンタとかもはや実質的に確定的ですらないやん

**デフォルトの名無しさん** · 2022/02/05(土) 14:54:37.48

>>133
そこはC++も同じだけど
C++よりも更にメモリ管理の記述が少なく済むのがRust
それでいてコンパイルが通った時点でメモリやデータ競合などの安全性が保証されるのがRust

**デフォルトの名無しさん** · 2022/02/05(土) 15:02:39.39

その上でRustは現代的なプログラミングパラダイムが洗練されて採り入れられているため書きやすい
つまりちょっとしたメモリ管理を意識してプログラミングするだけで他より数倍～十倍速くなることもあるのだから
例えばサーバー経費を何分の1に激減させつつレスポンスも良いという実利的なメリットにも効いてくる

**デフォルトの名無しさん** · 2022/02/05(土) 17:29:39.72

>>133
> 参照カウンタとかもはや実質的に確定的ですらないやん

原理的には確定的やん
GC有り言語でガベコレタイミングに苦しんだことあるやつなら
ハッキリとRAIIとGCの間に線が引ける

**デフォルトの名無しさん** · 2022/02/05(土) 17:48:34.36

>>136
不要となったら直ちにデストラクタが呼ばれる点で優れてるよな
GC言語ではそれが出来ないので後始末の記述を毎回書くことで一部補うかその機能がないか

**デフォルトの名無しさん** · 2022/02/05(土) 18:36:32.12

RAIIとGCは対立する概念じゃないがな。C++/CLIで共存できてる。

**デフォルトの名無しさん** · 2022/02/05(土) 20:00:06.29

RAII言語は必要があれば言語の枠外でGCライブラリなどを用いてGC利用も可能
その逆にGC言語はRAII利用が不可能

**デフォルトの名無しさん** · 2022/02/05(土) 20:40:28.08

それはRAIIの機能がない言語ではRAIIが使えないと言っているに等しい。

**デフォルトの名無しさん** · 2022/02/05(土) 21:10:31.12

循環参照もプログラマが自分でWeak<T>使ってなんとかするっていう言語だ
面構えが違う

**デフォルトの名無しさん** · 2022/02/07(月) 00:03:08.00

>>126
で、Rustって駄目ブラウザ以外に何作れんの？お前何作ってんの？内容ゼロで優秀性なんて言い出すウンコのコード見せろよ

**デフォルトの名無しさん** · 2022/02/07(月) 00:13:06.30

>>142
Deno

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

数年前ならいざ知らず未だにRustに実用プロダクトあるのという
煽りは痛い人になっちゃったな

**デフォルトの名無しさん** · 2022/02/07(月) 03:24:58.20

なんかRuby界隈みたいに知識のアップデート止まってる人たち多いね
もうRustなんてそこら中で使われまくってんのに

**デフォルトの名無しさん** · 2022/02/07(月) 09:18:42.53

Rustは低レイヤやライブラリから徐々に侵食していく感じだからなかなか気付かれにくいかもね
Cのライブラリと思ってたら実装はRustに置き換わってた、とかよくある

**デフォルトの名無しさん** · 2022/02/07(月) 12:33:27.96

「よくある」んなら具体例をどうぞ

**デフォルトの名無しさん** · 2022/02/07(月) 12:54:30.50

自分はGNOMEとFirefoxしか知らんな
既存の実装がrustに置き換わるというよりrustで書き直された代替実装が登場してる印象

**デフォルトの名無しさん** · 2022/02/07(月) 12:56:04.35

VSCodeの検索にripgrepが使われるようになったのも広義の置き換えとは言えるか？

**デフォルトの名無しさん** · 2022/02/07(月) 13:02:36.93

この手の手合はそんなものは下らない一般的じゃないと
言い続けるだけだからなあ

**デフォルトの名無しさん** · 2022/02/07(月) 13:48:06.41

curlとかpycaもかな
この手のは最初に入るときはレガシープラットフォーム対応の問題とかで話題になるけど
一度入ってしまうと採用が広がっても特に取り上げられることはないからなぁ

**デフォルトの名無しさん** · 2022/02/07(月) 14:27:21.78

pythonのファンシーコンソール風ゲームライブラリであるpyxelの実装がrustで書かれてて、お？ってなったわ

**デフォルトの名無しさん** · 2022/02/07(月) 15:19:33.56

その言語で書き直された〜みたいなことが話題になるうちはほぼ広がってないと考えて良いわ。

**デフォルトの名無しさん** · 2022/02/07(月) 15:43:24.90

>>153
こうなったらOKというお前の合格ラインは？

**デフォルトの名無しさん** · 2022/02/07(月) 17:52:12.40

>>150
「よくある」とやらの根拠に興味あるだけだから心配すんな
絶対批判したり非難したりしないからリラックスして述べてみ

**デフォルトの名無しさん** · 2022/02/07(月) 18:19:47.49

>>155
最近じゃITニュースサイトでも
Rustで書き直しましたという記事がちょくちょく出てることに
興味もないレベルだと次世代言語スレは難しくない？

**デフォルトの名無しさん** · 2022/02/07(月) 22:00:41.23

>>153
スクリプト言語のボトルネック部分をCで書き直さしたなんてよく話題になるからCもマイナー言語ということで良いか？

**デフォルトの名無しさん** · 2022/02/07(月) 22:12:11.68

Rustは現代的なマルチパラダイムが洗練されて採り入れられているためプログラミングがしやすい
それなのにCやC++のように最高速で動いてくれて快適かつリソースや経費の節減となってくれる
さらにオマケとしてメモリ安全やデータ競合安全などの保証まで付いてくる

**デフォルトの名無しさん** · 2022/02/07(月) 22:14:03.66

まあまあ他人に期待するのではなく自分で何か書けばいいだけでしょ
今なら車輪の再発明と叩かれることもないだろう

**デフォルトの名無しさん** · 2022/02/07(月) 22:42:44.19

「よくある」はずなのダンマリｗ

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

いうほどランタイム速度を必要とするようなアプリ、どいつもこいつも書いてないってのが現実。
はったりかましたバカはよくいるけど。

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

だいたいのアプリはAPI呼び出しの塊だからアプリ自体が実行時間のボトルネックになることはレアかもね

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

Nimを使って作られたゲームを紹介しよう。
https://goodboygalaxy.com/
ゲームボーイアドバンス向けに作られた2Dアクションゲーム。
https://store.steampowered.com/app/1444480/Turing_Complete/
論理回路を組み立てて自作CPUを作るゲーム。Godotっていうゲームエンジンが使われている。

**デフォルトの名無しさん** · 2022/02/09(水) 13:13:49.61

>>157
そんなこといちいちドやって報告しないって意味だよ。どこぞの言語と違ってな。

**デフォルトの名無しさん** · 2022/02/09(水) 13:57:31.22

>>164
へー、リリースノートとかにも載せずにしれっと更新するのが世の中では当たり前なのね

**デフォルトの名無しさん** · 2022/02/09(水) 13:58:40.10

>>164 CからRustに書き直されることはあっても逆は無いから当然だろ

**デフォルトの名無しさん** · 2022/02/09(水) 21:57:32.65

まっ、Cはこれだけ広範囲に使われているからね。基礎教養みたいなもの。
知っていて、使えて当たり前。

Rustでなにか画期的に高速化されるわけでもないし、コーディングの量が圧倒的に減るわけでもない。Pythonのように特定分野で格段の強みがあるわけでもなし。
メモリ安全性といっても、それが課題になってくるほど大きなプロジェクトに関わってるわけでもないしなぁ・・・

組み込み的にはオブジェクト志向な方がハードウェアと馴染みがいいって感じもあるかな。

**デフォルトの名無しさん** · 2022/02/09(水) 23:51:15.16

>>167
＞メモリ安全性といっても、それが課題になってくるほど大きなプロジェクトに関わってるわけでもないしなぁ・・・

俺のやってるプロジェクトは小さい自慢かよ

**デフォルトの名無しさん** · 2022/02/10(木) 02:47:32.09

>>167
オブジェクト指向の方がハードウェアとなじみが良いというのはどういうこと？
カプセル化とか継承とか、もしかしたらメッセージパッシングとかがハードウェアの抽象化に適しているということ？

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

>>169
相手にしちゃだめ

**デフォルトの名無しさん** · 2022/02/10(木) 12:40:20.38

デバイスドライバーみたいなソフトウェアだと、linuxのVFSみたいなインターフェイスを意識するのが普通だから
オブジェクト指向や関数ポインタ渡しが普通。
動的に操作方法を変える必要性が大きいものはこういう仕組みは必要になる。

**デフォルトの名無しさん** · 2022/02/10(木) 12:43:32.46

そういやRustって、コールスタック重視なのになんで所有権移動をデフォルトにしたのかね？

スタックにデータがあるなら、戻ってくるのを想定して借用をデフォルトにした方が効率良い気がするけど。

**デフォルトの名無しさん** · 2022/02/10(木) 13:01:13.03

値渡し警察「参照渡しは存在しない。あるのは借用<T>の値渡しだけだ」

**デフォルトの名無しさん** · 2022/02/10(木) 19:06:35.96

>>172
そこはRustでは最適化される
例えば大きな構造体 struct Foo { 略 } があったとして
fn main() {
let foo = sub1();
}
fn sub1() -> Foo {
let foo1 = sub2();
return foo1;
}
fn sub2() -> Foo {
let foo2 = Foo { 略 }; // 上述の大きな構造体
return foo2;
}
と多段の関数の深いところから大きな構造体を返すとする
(注: 他言語の人にもわかりやすく敢えて「return」を明記してます)

Rustではこれは最適化されて
深いsub2()の変数foo2の格納場所はmain()のスタックの位置となる
特に今回の場合だと次々に渡していくだけなので
変数foo2のアドレスとfoo1のアドレスとfooのアドレスは一致する
(もちろんこのコードでヒープは一切利用されない)

つまり返り値(の格納場所)をポインタ渡ししているのと同じことになる
C言語ではそれを自分でコードとして記述しなければならないが
Rustでは概念上や記述コード上は「値返し」でシンプルにわかりやすく
実行コードでは最適化されて「返り値の格納場所を参照渡し」になる
もちろん小さな型を返す場合は実行コードも効率よく「値返し」のままである

**デフォルトの名無しさん** · 2022/02/10(木) 19:53:19.62

>174
いや、RVOの話じゃなくて、
スタックにあるオブジェクトの所有権を関数呼び出し先に移動するのを
デフォルトにした設計的な意図は何なんだろう
という話。

継続を第一級オブジェクトとしてサポートするのでもなければ
サブルーチンはいずれリターンしてくるんだから、スタックに積んだ
オブジェクトも呼び出し先に所有権を移動しないで持ち続けるのが
自然な感じがするんだよね。
それをわざわざ移動してスタックの奥で破棄する（＝スタックに残骸が残る）
ようにしたのはなんでかね、と。

**デフォルトの名無しさん** · 2022/02/10(木) 20:19:32.65

>>175
ヒープにあるオブジェクトだと deep copy にコストかかるから shallow copy (move) をデフォルトにして
コストかかる処理はソースコード上明確になるようにしたかったからだと思う

**デフォルトの名無しさん** · 2022/02/10(木) 20:31:58.46

>176
Rustもなんだかんだ言ってヒープ使用を想定している、ということかね。
それなら所有権移動をデフォルトにした理由は判る。

**デフォルトの名無しさん** · 2022/02/10(木) 20:36:51.31

https://www.reddit.com/r/rust/comments/fa9pkp/what_is_the_motivation_behind_default_move/
このスレで作者が答えているけど、すでに参照を示す&が広く使われてるのにデフォルトを借用にすると、moveを示すために「非参照演算子」みたいなものが必要になって整合性が取れないから、とのこと
あとはスタックにどう置いてどうアクセスするかはコンパイラの最適化の問題であって
言語のセマンティクスとは別、みたいな話も

**デフォルトの名無しさん** · 2022/02/10(木) 20:48:03.49

>>175
Rustではそんな無駄なことはしていないので大丈夫
まずメソッド定義は以下の3つの方法がある
(1) fn method1(self: Self, 引数)
(2) fn method1(self: &Self, 引数)
(3) fn method1(self: &mut Self, 引数)
Selfは自分の型を示す特別な型であり省略して以下のように略記も可能
(1) fn method1(self, 引数)
(2) fn method1(&self, 引数)
(3) fn method1(&mut self, 引数)
ここで>>175が最初に言っている方法は(1)のケース
参照しか利用しないメソッドなれば(2)のように定義して所有権は移動しない
参照を利用して書き換えるならば(3)のように定義して所有権は移動しない
そして所有権を移動させたいメソッドのみ(1)の定義を用いる
この3つの区別があるためRustでは無駄なことは起きない

**デフォルトの名無しさん** · 2022/02/10(木) 21:34:34.23

>>174
Rustは所有権がはっきりしてるためコンパイラが安全に最適化をガンガン出来る点が良いな
しかもプログラマーはそれを意識せずにRustのセマンティクスだけ把握して書けば後はコンパイラが勝手に最適化してくれる
これがC/C++だと自分で戻り値の場所を確保して自分でポインタを渡していき競合安全性も含めて自分でメモリ管理しなければならない
CG言語だとスタック上はあきらめてヒープで確保して返して後始末はGC任せ
Rustが有利

**デフォルトの名無しさん** · 2022/02/10(木) 21:40:15.72

>>178
どちらかに指定が必ず必要なのだから
ライフタイムを管理する必要のある参照の方に＆指定する現方法が大正解だな
参照にはsingle writer XOR multi readersのルール義務もあるしな

**デフォルトの名無しさん** · 2022/02/10(木) 21:50:15.02

ある程度は既存のメジャー言語と作法を揃えないと、タダでさえヤバい学習曲線がさらにとんでもないことになるしねえ

**デフォルトの名無しさん** · 2022/02/10(木) 22:07:58.55

可変参照と可変じゃない参照の区別が安全性保証の要になっているため
参照の方に記号を付けるのは理に適っている
いずれにしてもC/C++で安全に書く時はそれら含めて意識せざるをえない
それがRustでは様々な点でかなり楽になっているのだからC/C++より学習が大変ということはない

**デフォルトの名無しさん** · 2022/02/11(金) 12:06:27.49

>>178
なるほどねぇ。
個人的にはconst refを標準にして非参照演算子を用意するのも有りだと思うけど
（変数そのものの状態変更を呼び出し元で明記するという意味で）
そのあたりは作者の設計思想だからなぁ。

ただ、コンパイラの最適化と言語のセマンティクスを切り離すのは単純すぎる気が。
>>180みたいな話もあるんだし。

**デフォルトの名無しさん** · 2022/02/11(金) 12:49:33.03

>>184
参照を返す関数を書いてみればわかる
参照の方が特殊な存在であり記号は何でもよいが記号を付けるべき存在だとわかる
そして適切な記号としては微妙に概念が一部重なるC言語の＆を選んだのも適切

**デフォルトの名無しさん** · 2022/02/11(金) 13:38:34.47

>>185
もともとコールスタック（>>172）の話をしているのに、ヒープデータ前提の参照戻し関数の話をされてもねぇ。
Rustが「効率的にするという約束はしているが、コールスタックとかヒープとかは関係ない」というスタンスなら別だけど。

**デフォルトの名無しさん** · 2022/02/11(金) 13:47:41.99

>>186
ほら理解できていない
まずは実際にプログラミングしてみなさい
ヒープなんか一切用いなくてスタック上しか使わなくても参照返しは必ず起きるしライフタイムの管理が必須となる

**デフォルトの名無しさん** · 2022/02/11(金) 14:39:24.16

>>187
そこまで言うんだったら具体的なコードを例示してくれない？
「参照返しは必ず起きる」と理解できるような普遍的なコードで頼むよ。

**デフォルトの名無しさん** · 2022/02/11(金) 15:19:57.69

>>187
>ヒープなんか一切用いなくてスタック上しか使わなくても参照返しは必ず起きるしライフタイムの管理が必須となる
これは嘘だろ。実際fortranはヒープ使わないし、変数の寿命なんて問題は考えなくて済む。
そういう意味じゃめっちゃ安全。

**デフォルトの名無しさん** · 2022/02/11(金) 16:01:25.44

>>188
数値配列の処理や文字列の処理でよく起きますね
例えばイメージしやすい例だと入力文字列から前置文字列と後置文字列に挟まれた文字列を返す関数
// 【input_str】 = 【prefix_str】 + 【output_str】 + 【postfix_str】
fn get_str_between<'a>(input_str: &'a str, prefix_str: &str, postfix_str: &str) -> Option<&'a str> {
let start_index = input_str.find(prefix_str)? + prefix_str.len();
let end_index = input_str[start_index..].find(postfix_str)? + start_index;
Some(&input_str[start_index..end_index])
}
このように引数に複数の参照が来る時に参照を返す場合はライフタイムの明記をします
この例だと関数が返す参照は引数のinput_strのライフタイムと同じですよと伝えることで
この返り値がさらにどこか別の関数で使われたりあるいは構造体に格納されたりしても出自がわかり安全なわけです

ちなみに文字列処理はヒープエリアを一切使わなくても
スタック上の配列(ex. ArrayString)やstaticエリアだけでも完結できますからその突っ込みは無しでよろしくw

**デフォルトの名無しさん** · 2022/02/11(金) 17:17:31.83

ああ、データ自体を外部から参照する関数なら参照返しも普通か。>>186自体は間違いだな。

ただ、>>184（参照・実体の表記法／関数呼び出し規則）とはあんまり関係していない気が……やっぱり、Rustの設計思想が>>178だからというのが結論に思えるなぁ。
まあ、このあたりをいじくると、所有権を持つ変数が必ずひとつ存在するRustの設計思想からいじくらなきゃいかんような気がするから、Rustじゃ無理か。

**デフォルトの名無しさん** · 2022/02/11(金) 18:27:07.40

>>191
そこはRust限定の話ではなく一般的な話だと思う
参照というのはあくまでも実体があってこそ生きていられる存在
だから実体を保有する変数がどこかに必ず存在していて
その実体が参照よりも長生きしていないとダングリングポインタになってしまう

(ここからはRustの話)
したがって実体の方を本体として無記号にし
それに依存している存在にすぎない参照の方を＆記号で示している

**デフォルトの名無しさん** · 2022/02/11(金) 23:20:00.56

>>189
すべての関数呼び出しが末尾再帰であれば、呼び出しにあたって現在のスタックフレームを保存する必要はないから、中途半端な
手続き言語で分かった風に語りだす人は、どこかおかしい。コンピューターサイエンスとか齧ったことは無さそう。Rustをやってる人の
こういう語りは言語の発展の邪魔でしかないね

**デフォルトの名無しさん** · 2022/02/11(金) 23:30:45.78

>>193
どうみてもその>>189はRustをわかっていない人がむしろ(デタラメにRustを)批判してるような

**デフォルトの名無しさん** · 2022/02/12(土) 01:31:10.49

Go言語の作者Rob Pike氏が2015年に発表した「Go言語が成功した理由は何なのか？」で
> mapやfilterのような機能は言語の表現力を高めるものであり、書いていて楽しい言語に繋がるわけだが、
> これはそのトレードオフとなるメンテナンス性が高く扱いやすい言語という点をを犠牲にするだけでなく、
> （極めて素晴らしい方法で実装しない限り）コンピューターリソースを非常に消費するものだ。
と述べていて当時はその通りに思われてGoでは毎回for文で書くことがシンプルで良いとされてきた
しかしその後Rustのイテレータ実装ではfor文とほぼ同様に速く動かせるようになり
for文で毎回ごちゃごちゃ書くよりメンテナンス性もよく扱いやすいとわかった

**デフォルトの名無しさん** · 2022/02/12(土) 02:24:04.92

Rust創造イテレータおじさん。。。

**デフォルトの名無しさん** · 2022/02/12(土) 02:36:04.74

どうみても言語の否定じゃなく、どうでも良いようなことを延々と語りだすそいつの思考の人格・性格的否定だろうに。
こんな読解力も何もない奴ばっかか・・・

**デフォルトの名無しさん** · 2022/02/12(土) 14:28:17.06

>>195
Rust開発者は天才だから仕方ない

**デフォルトの名無しさん** · 2022/02/12(土) 16:13:21.86

所有権という概念を生み出したrustの人（名前わすれた）は天才だよ
効率性と安全性を同時に実現してる
これを関数型言語の人が生み出せなかったのは謎すぎる

**デフォルトの名無しさん** · 2022/02/12(土) 16:49:53.94

Ruby にはLazy があるから、無限配列でも、iterate できる

実行順序を変える。
書いた通りに前から実行しない