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

**デフォルトの名無しさん** · 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では概念上や記述コード上は「値返し」でシンプルにわかりやすく
実行コードでは最適化されて「返り値の格納場所を参照渡し」になる
もちろん小さな型を返す場合は実行コードも効率よく「値返し」のままである