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

■ このスレッドは過去ログ倉庫に格納されています
2021/11/28(日) 16:59:19.16ID:gZqbEyz/
スレタイ以外の言語もok

前スレ
次世代言語22 Go Nim Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1629590343/
2022/02/27(日) 21:16:17.18ID:TDmI4NY5
>>354
めちゃくちゃわかる
Pythonは便利さで考えると間違いなく個人的一位なんだけど、何らかの別の知識と組み合わせないと価値が生み出せない感じは確かにある。
C書いてる老人からしたら「インタープリターなんてけしからん」って感じで毛嫌いされるし...
純粋にプログラマとして名乗るなら一つはコンパイラ型言語を習得する必要がありそうだ。
359デフォルトの名無しさん
垢版 |
2022/02/27(日) 23:07:26.84ID:Kxq1o6ES
Pythonはパッケージ管理とか型付いてないライブラリがウザい
2022/02/27(日) 23:37:07.72ID:4VyCP23o
というかCargoはマジで優秀すぎて、他のあらゆる処理系に真似してほしい
2022/02/27(日) 23:42:37.49ID:OAiw6RqC
フロントエンドの人が最近Rust書いてるけど
JSしか書いたことない人が書ける言語じゃないと思うが
2022/02/27(日) 23:58:09.11ID:2GGoVw4G
JSでちゃんとしたものを書けるスキルがある人にとっては楽勝な気も。
363デフォルトの名無しさん
垢版 |
2022/02/27(日) 23:59:48.77ID:BlJE3fZv
プログラム言語に求められるニーズはホント、多様なんだな、と思った。
GoやPythonの様に仕様を簡単にして仕事をサクッと済ませたい人も居れば、「一般人では到達し得ない難易設定に取り組んで他者と差別化したい」という人も居る。
商品開発と同じで皆にドンピシャハマる言語は無いし、それを無理に作ろうとしたら、万人が物足りなさを感じる折衷案になってしまうのだろうな。

と言いつつ、皆にドンピシャハマる言語を模索している自分が居る。
「型設定、メンドクサイ〜」という人はC++で言うautoを使えばいいし、「自動化・縛り無しはバグの元！」という人はintやconstや所有権を追加すれば良い。どちらの書き方でも同じ言語上で動くし、お互いの書き方が気に入らなければ「付け足す・削る」だけで対応できるような、そんな、移植性の高い言語を作りたいものだ。
364デフォルトの名無しさん
垢版 |
2022/02/28(月) 00:28:38.71ID:mRBEkiDP
ステータスのためじゃなく楽だから使ってるだけ
2022/02/28(月) 00:30:29.35ID:fo+smr71
>>355
どの辺に難しさを感じたの？
コンパイル時のborrow checkerと同じことを実行時にチェックするだけだからRefCellが難しいと言うより借用周りの規則がややこしい？
2022/02/28(月) 00:32:24.14ID:fo+smr71
>>357
マクロはほとんど影響ないと思う
小規模のcrateをたくさん組み合わせることが多く、プロジェクトごとにそれぞれコンパイルする必要があるので
単純にコンパイル対象のコード量が多いというのはよく言われている
2022/02/28(月) 15:08:46.61ID:LoAqeLPd
cargoは独善的すぎて好きになれんわ。遅いし。
2022/02/28(月) 15:19:11.30ID:XoBakguu
その通り、cargoを持ち上げてる上げてる奴とは全く仲良くなれそうもない。
cargoが遅くてダメダメ、なんで遅いのかを調べるとRustのトレイトの仕組みに行き着くという罠...
2022/02/28(月) 15:37:37.25ID:Msb6WRSo
>>365
可変参照を実行時に得たいというrustの事情はわかるのだけど
そもそもコンパイル時に参照解決できないデータ構造はめちゃくちゃ多い
その辺りをもう少し書きやすくならないかなと思う
結局面倒だからunsafeに逃げてしまうのではないかと
まだうまく言語化できずモヤモヤしてるが
2022/02/28(月) 15:44:40.05ID:qfzw0yaJ
借用規則を考慮した設計が難しい、ってことかな
2022/02/28(月) 16:29:36.75ID:ZHtGEnZl
Rust以前のコードしか書いたことない人は
借用しっぱなしで平気だからいろいろ困ってしまう
Rc<RefCell<T>>で考えられるようになると
共有所有権をクローンして持っておいて
必要な瞬間のみ動的に借用するって方法を覚える
そうして、時間軸上のスコープとでもいうか借用の瞬間を小さく管理することを覚えるのである
そうして、今まで人類は所有権と借用についていかに無頓着にやり散らかしてきたのかを反省するのである
2022/02/28(月) 16:42:42.62ID:Msb6WRSo
>>371
それはわかるんだけど
その代償としてプログラマーが支払わなきゃならない代償がデカすぎると感じる
これはコンパイル時の様々なチェックとは本質的に違う努力で
rustを騙すためにやらなきゃならないバッドノウハウの類であると感じる
2022/02/28(月) 17:21:22.82ID:nTxgkwf4
>>371
GCで困らない、システムプログラミングしない人としては、
そんな面倒な事したくないなって、思ってしまう。
2022/02/28(月) 17:29:54.30ID:XoBakguu
せめてどうにか速くならないかとcargoをRAMDISKにしようとするとCARGO_TARGET_DIR=/tmp/.cargo/...と出来るのは
良いんだけど、コンパイルのためのworkじゃなく、targetディレクトリだから成果物がそこにできてしまうという（笑
速くなるんだけどね。。
2022/02/28(月) 18:10:55.65ID:OT3fp0Z5
>>369
はっきり言ってツリー構造とかはunsafeでいいと思うよ
2022/02/28(月) 18:11:17.29ID:fo+smr71
>>372-373
それはrustがnot for youという話なのでは
2022/02/28(月) 18:13:00.49ID:XSUMuMfa
Rust持ち上げてる内容を見ると他の言語でも普通にあるやつが多い
C++しか使ったことがないうぶな人なんじゃないかな
2022/02/28(月) 18:19:03.53ID:XSUMuMfa
頓珍漢で的外れ

型推論も賢い　←　むしろ型推論実装されてて賢くない奴ってどれなんだよ
アトリビュートが言語本体と独立していて　←　当たり前　他でも同じそれが属性

Cargoが良い　←　他より優れているとは思えない

強力な型推論およびトレイト静的実装型宣言により実際の型名を記述する必要がない　←　当たり前　もともとそういうもの
2022/02/28(月) 18:27:45.82ID:qfzw0yaJ
>>374
たしかに中間ファイルのビルドキャッシュはプロジェクト間で共有しつつ、最終生成物はプロジェクト内に出力するオプションがちょっと欲しいな
Goがそういう感じだったかな
2022/02/28(月) 18:31:01.98ID:fo+smr71
そもそもrust自体言語機能が優れていることは標榜してない
他のモダンな言語の "当たり前" をシステムプログラミング領域でも実現したというのがポイントでは
2022/02/28(月) 18:37:53.82ID:zoHJPzI7
エ、エラーメッセージが親切…
2022/02/28(月) 19:04:01.39ID:7SSxP2tw
>>380
GCなく高速で動く便利なプログラミング言語が登場したことが非常に大きい
そこへ加えて強力な静的型付けにトレイトの枠組みが加わりプログラミング開発の生産性が大きく上昇
2022/02/28(月) 19:09:23.31ID:qfzw0yaJ
せやなあ
あくまでRustの重要なところはオーバーヘッドが少なく比較的安全に、システムプログラミングやベアメタルプログラミングが行える処理系だというところだよね
この特徴だけでも他の言語と大きく差別化されるけど、モダンな型システムも便利だから低レベル以外のレイヤーでも使いたがる人がいる、って感じよね
2022/02/28(月) 19:14:51.86ID:EeqSDih1
>>380 みたいなのを見ると安心するけど、
>>381-383 みたいなのを見ると新興宗教団体のように見えるのがRust
2022/02/28(月) 19:23:32.63ID:fo+smr71
381はおちょくりだし383は380と同じことを言っているだけのような
382は自分の主張を繰り返すだけの人
2022/02/28(月) 19:38:39.03ID:EeqSDih1
>>380で終わっておけば「今週末ちょっとRustやってみようかなぁ」になるけど
>>381-383が続くことによりくどくなり、「うへぇ・・・Rust関わりたくねぇ」になりそうってこと

壁からちょっと手を出すと子猫が飛びついてくるけど
全身見せて手を差し伸べようとすると逃げていくのと一緒
2022/02/28(月) 19:46:15.31ID:ZHtGEnZl
ムリに関わる必要はないし
誰もそれを強いてはいないぞｗ
あの言語はC++で苦しんだ連中が手を伸ばすもんだよきっと
2022/02/28(月) 19:52:14.78ID:pJo2hpV4
うちの場合だけどスクリプト言語からRustにして良かった点
・型を中心とする強力な言語機能による開発効率の大幅上昇
・メモリ省力化と高速化CPU負荷激減によりサーバー/クラウド等リソースとコスト大幅削減
・アプリやシステムなど反応速度も高速になり様々な利用者が快適となった
2022/02/28(月) 20:12:49.15ID:EeqSDih1
スクリプト言語から移行出来るような高機能なデファクトのフレームなんてRustにあったっけ・・・
2022/02/28(月) 20:26:42.23ID:EDlcC+qx
I/O待ちが大半なWebアプリじゃなくて
I/O処理やデータ加工が主体な処理なんじゃない？
そういうのでもスクリプト言語で書かれてるケース結構みるし
2022/02/28(月) 20:33:18.52ID:EeqSDih1
>>390
そんなしょうもないケースわざわざRustにしたらメンテする人いなくなるだけ
そもそも>>388以外が答えても意味ない
2022/02/28(月) 21:27:33.71ID:Msb6WRSo
「コンパイル時に参照が決まらないデータ構造に対して解決にはなってない」のがrustのいけてないところ
ここにたどり着いた俺を褒めてくれ
2022/02/28(月) 21:27:36.69ID:fChQ9CLi
過剰アンチも異常者に見えるからやめといたほうがいいぞ
2022/02/28(月) 22:17:24.10ID:3KbSSRJr
>>392
バグがあるとしたらそこが怪しいって絞り込めるだけで十分。
しかもそういう参照が決まらない場所なんて限定的だし
2022/02/28(月) 22:21:48.16ID:nNGdW6Mz
CPU セントリックな処理じゃないの？
少数の同じデータを繰り返し使うような、行列処理みたいな

Ruby on Rails みたいな、全ての関数が平均的に呼ばれるようなものは、
どうにもならないでしょ？

例えば、Ruby JIT で、1万個の関数を機械語にコンパイルしても、対して速くならない

手続き中心処理はダメ。
データ駆動型じゃないと、速くならない
2022/02/28(月) 22:49:27.28ID:EeqSDih1
>>395
そういうのにスクリプト言語を選択してるのがおかしいだけで、Rustでなくても何でも普通に書けばそれなりに速い。
また繰り返しになるがRoRを置き換えられるようなRustのフレームなんてあったっけ？
そもそも>>388以外が答えても意味ない
2022/02/28(月) 23:22:44.01ID:7SSxP2tw
>>389
各自の分野と対象レイヤーがバラバラだろうから一般的な話になるが
開発のできる普通のプログラマーにとってはほとんどの分野でRustが実用的に使えるようになってるな
しかし切り貼りや書き換えや各種設定などだけでやりくりする似非プログラマーにとってはまだ厳しい
2022/02/28(月) 23:29:23.70ID:7SSxP2tw
>>392
それはRustが最高速を出すために
ジェネリクスを具体的な型に対してコンパイル時に静的にモノモーフィングするからであって利点の一つ
もちろん稀なケースでは動的にディスパッチしたほうが有利なこともあるのでRustは静的と動的のどちらも選べる
2022/02/28(月) 23:58:18.16ID:pJo2hpV4
>>396
うちではRoRは使っていません
その階層での汎用的なフレームワーク全体を作るのは大変でしょうが
必要な機能のみを必要な用途に特化して用いていますのでそのようなものを必要としていません
2022/03/01(火) 00:00:29.40ID:MT73K7Vw
>>399
はい、嘘乙ｗ
2022/03/01(火) 00:02:10.33ID:MT73K7Vw
>>397
エコシステム完成を宣言！？なんでもござれ？？？？
なわけないだろｗ 嘘乙ｗ
2022/03/01(火) 00:35:18.37ID:I7tVqKwp
>>398
その利点は理解してるよ
ポインタをつなぎかえるようなプログラム以外ではそこまで面倒だとは思わないし
ほとんどのプログラムは静的に決まるように書けるしね
403デフォルトの名無しさん
垢版 |
2022/03/01(火) 06:36:40.86ID:kkFVnbRG
ポインタ繋ぎ変えるのはRustでは面倒です←まあわかる

ポインタ繋ぎ変えるのはバッドプラクティスなのでアリーナ使って富豪みたいなメモリの使い方しましょう← ？？？？？w？？！？？？？？？？？？？？？？？？？？？？w
2022/03/01(火) 18:23:47.64ID:I7tVqKwp
>>403
いや何でもかんでもArena使えってことではないよ
Arenaは処理の間、メモリの解放が起こらずに解放する時はまとめて解放するようなデータ構造で使うものだよ
rustのソース読んでたらAST作る部分で使ってた
ASTはまさにそのような部品
rustのソースは学びが多すぎる
2022/03/01(火) 18:27:16.34ID:wlQMHsd9
arenaって富豪的なの？
最近のmalloc実装はarena使ってるからそれも富豪的ってこと？
2022/03/01(火) 18:36:51.05ID:I7tVqKwp
>>405
arenaは解放処理が行われるときは必ず全てのオブジェクトが解放される
mallocはslab allocatorが上手いことやらないと解放されない
2022/03/01(火) 19:11:45.23ID:wlQMHsd9
>>406
なんでslab allocatorが関係してるの？
408デフォルトの名無しさん
垢版 |
2022/03/01(火) 19:31:58.30ID:kkFVnbRG
>>404
ASTみたいな構造+途中で解放する必要があるって時の解がRustにないので、オレオレ実装をプロジェクトごとに入れるか、アリーナを何度も作っては捨ててを繰り返しながら世代型GCもどきを作るかするしかなくない？
これは事実上なんでもアリーナでやるってことになると思うけど
2022/03/01(火) 20:13:49.20ID:lFABJG9J
強力な静的型付けと言うのは普通のプログラム言語は当たり前でスクリプト崩れがそうでないだけだと思うけどなあ…
2022/03/01(火) 20:26:25.79ID:wYBPD4DC
>>408
そういうのはまさにRefCellを使うしかない
arenaはあくまで処理の間は絶対に解放されないデータ構造をまとめて確保するために使う
例えばASTだったりネットワークグラフだったりね
こういうメモリの使い方のセンスってGC言語が当たり前になったせいで完全に失われた技術って感じがする
2022/03/01(火) 20:34:17.98ID:KSXXo2gm
>>409
静的型付き言語の中でも代数的データ型や型制約のような型の表現力の違いというのはあると思うよ
2022/03/01(火) 20:36:04.73ID:wYBPD4DC
>>408
ちなみにarenaみたいな仕組みを実はV8は実装している
HandleScopeという仕組み
これはHandleScopeが生きている間はメモリが解放されないが
HandleScopeが死ぬタイミングで全てのローカル変数のメモリが解放される
2022/03/01(火) 20:42:46.97ID:wlQMHsd9
>>409
CやGoはどこに分類されるの？
スクリプト崩れ？
2022/03/01(火) 20:53:08.57ID:VJyX+NRp
ObjCのautoreleaseみたいなのが最初からあると楽でたすかる
415デフォルトの名無しさん
垢版 |
2022/03/01(火) 22:06:55.93ID:kkFVnbRG
>>410
なるほど……
416デフォルトの名無しさん
垢版 |
2022/03/01(火) 22:31:05.05ID:kkFVnbRG
いやRefCellはしんどいって
やっぱgcpointer復活して欲しい
2022/03/01(火) 23:43:07.40ID:cUOzOJ3p
RefCellなんてたまにしか使わないものだし使うときも困るようなものじゃないぜ
おそらくRustのアンチが不利っぽく見えるところを取り上げようとしてるんだろうけとさ
2022/03/01(火) 23:52:21.58ID:X64WHIwe
そりゃテキトーなスクリプトで済むようなコードばっかなら使わんだろうね
2022/03/01(火) 23:55:04.65ID:pLY9i2hK
分野にも依るんだろうけどWeb関係やってるとRefCellの出現は超レア
ライブラリの方のソースも全て見たけど
RustのHTTPデファクトスタンダードのhyperで1ヶ所だけ出現
その上のレイヤーのライブラリ群ではゼロ、HTTPS扱うhyper-tlsでもゼロ
2022/03/02(水) 00:44:16.33ID:2MKUvw25
Webだとメモリ上に状態を永続的に保つ必要はないからrust向きだよね
所有権を渡していくことで自然と安全なプログラムが書ける
永続情報はデータベースかmemcacheみたいなkvstoreに入れるし
2022/03/02(水) 01:01:39.91ID:uPKvDIET
>>416
gcpointerって@のこと？
あれはgcと言いつつただのRcだしinternal mutabilityとは関係ないよ
2022/03/02(水) 01:27:42.89ID:vZCB5GJW
>>420
ほとんどの動的アロケーションはリクエストスコープだからという理屈？
だったら所有権というより自動変数で十分でしょ
423デフォルトの名無しさん
垢版 |
2022/03/02(水) 02:27:42.01ID:/7glPJ4X
循環参照が必要な時にやれることが「プログラマが注意して管理しましょう」しかないのキツくない？
2022/03/02(水) 03:42:27.38ID:S8+3WyDZ
>>423
現実に色んな分野でプログラミングするとわかるが循環参照なんてほとんどの分野で出てこないか回避できる
なぜなら現実の様々なシステムからアプリまで全てにおいて出てくるデータ構造は何らかの視点で見ると木構造になっているからである
だから非現実的な机上の空論で悩む必要はない
2022/03/02(水) 03:44:23.51ID:re9dUtRi
グラフとか木構造になるの？
426デフォルトの名無しさん
垢版 |
2022/03/02(水) 03:47:03.10ID:/7glPJ4X
世界が狭い人に非現実って言われちゃった
427デフォルトの名無しさん
垢版 |
2022/03/02(水) 03:52:48.36ID:/7glPJ4X
> なぜなら現実の様々なシステムからアプリまで全てにおいて出てくるデータ構造は何らかの視点で見ると木構造になっているからである

これが真ならベルマンフォードとか使うケースはどうなるんだ
まあ無理筋に頑張って木と同一視するのかもしらんが
2022/03/02(水) 03:58:19.90ID:S8+3WyDZ
>>425 >>426
抽象的な話しか出来ないなら相手にしないが
具体的に木構造の視点を持たないグラフを扱うシステムやアプリがあるなら挙げてごらん
そしてそのデータをどのように永続化しているのかも語って欲しい
あったとしても非常に特殊なレアケースだろう
2022/03/02(水) 04:07:57.82ID:S8+3WyDZ
>>427
ベルマンフォード法で扱うデータをポインタ(参照)で指し合うなんて非効率なことはしないので不成立
普通に配列に格納する
2022/03/02(水) 04:21:43.92ID:3w84ACsj
よくわかっていないけど
鉄道の路線図とか簡単にループするけど
どうするの?
2022/03/02(水) 04:23:18.48ID:re9dUtRi
>>428
質問してるのはこっちなんだがｗｗｗｗ
2022/03/02(水) 04:38:01.52ID:S8+3WyDZ
>>430
プログラミングでそういうのを扱うときに
駅の個数だけ駅ノードオブジェクトをメモリ確保して路線毎に隣接駅をポインタ(参照)で指し合う、なんてことはしない
それだと何かするたびにポインタを何度も辿りまくって遅いし
そのポインタで指し合う構造をデータベースに格納するのも大変

現実にはどう扱われているかというと
データの配列として持ってそのインデックス等で他を指す
つまりポインタ(参照)は出てこない
配列とインデックスの方が扱いやすいし、メモリアクセスも速いし、ファイルやデータベースに格納するのも容易

>>431
現実に必要となることが無いか、代替手段があるか、となり、
残る超レアケースがあるなら出してごらん
2022/03/02(水) 04:43:14.42ID:re9dUtRi
>>432
お前が>>424で
> なぜなら現実の様々なシステムからアプリまで全てにおいて出てくるデータ構造は何らかの視点で見ると木構造になっている
と宣うから、俺が
> グラフとか木構造になるの？
って聞いてるんだがｗｗｗｗ
2022/03/02(水) 04:55:17.69ID:S8+3WyDZ
>>433
現実の様々なシステムからアプリまで全てにおいて出てくるデータ構造ならば
何らかの視点で見ると木構造になっている
もちろんその一番簡素なパターンである配列構造を含めてね
今のところ誰も反例を出せていない
もしあるとしても超レアケースなのだろう
2022/03/02(水) 04:57:49.96ID:re9dUtRi
>>434
グラフとか木構造になるの？
2022/03/02(水) 05:01:58.37ID:S8+3WyDZ
>>435
現実の様々なシステムからアプリまで全てにおいて出てくるデータ構造の何のグラフですか？
ベルマンフォード法ならば>>429に書いたように配列で扱われます
鉄道の路線図についても>>432に書いたように配列で扱われます
2022/03/02(水) 05:06:59.01ID:re9dUtRi
>>436
> グラフとか木構造になるの？
こう聞かれて特定のグラフだと思う方がおかしくね？
答えられないなら何レスも使わずに分からないと言って欲しい
2022/03/02(水) 05:18:20.52ID:S8+3WyDZ
>>437
そこまでキチガイならば相手をしない
こちらは最初から一貫してこの話しかしていない

>>424　引用
|　現実に色んな分野でプログラミングするとわかるが循環参照なんてほとんどの分野で出てこないか回避できる
|　なぜなら現実の様々なシステムからアプリまで全てにおいて出てくるデータ構造は何らかの視点で見ると木構造になっているからである
|　だから非現実的な机上の空論で悩む必要はない

そしてそちらが挙げた具体例に対して
それらは現実に配列として扱われていることも述べた
2022/03/02(水) 05:23:23.57ID:re9dUtRi
>>438
>>437
2022/03/02(水) 05:32:08.74ID:2MKUvw25
言ってることは分かるよ
俺はrust書き始めてポインタを使わないプログラミングをするようになった
C/C++に毒れてたことに気がついた
例えば木構造も配列とインデックスで同じことをやるように書き直した
昔のAhoやUllmanのアルゴリズムの本はポインタを前提にしてないから
配列とインデックスを使ってアルゴリズムを書いてる
その本を引っ張り出してきて読み直したりした
まさか現代において70年代に書かれた本を参考にするとは思わなかった
2022/03/02(水) 05:45:14.10ID:re9dUtRi
>>438は「分からない」ようだから話を進めると、グラフ構造は木構造にはならない
なぜなら、木構造はグラフ構造の一種だからｗ

グラフ構造を単純に実装すると、親ノードが子ノードを参照する形になり、簡単に循環参照を発生する
そういうこともあり、古来通常の実装はノードから直接参照するのではなく、エッジというものを用意し
各コンテナに保存した上で参照先をコンテナのキーにすることで表現する

つまり循環参照は簡単に発生し、それを回避する努力を惜しまない必要がある
>>423の言う通り、まさに
> 循環参照が必要な時にやれることが「プログラマが注意して管理しましょう」
であることが明確に分かる

これをろくに議論もできない頭で否定するものではないｗ
2022/03/02(水) 05:48:19.98ID:ZvwBufG6
配列とインデックスを使うとして、ある要素のインデックスを取った後にその要素が削除されるとそのインデックスが想定していない要素を指すことになるじゃん。そういうのはみんなどうやって防いでいるの?

あと、双方向リンクドリストって普通に実装すると循環参照になるけどこれも配列とインデックスでやるの?
2022/03/02(水) 05:52:14.90ID:re9dUtRi
原理的には整合が取れない状態にならないように操作がatomicになるように実装する
もちろん実装方法なので、構造を変えたり、方法は具体的にはいろいろあるよ
2022/03/02(水) 06:14:19.31ID:S8+3WyDZ
>>441
そこまでアホとは思わなかったw
一般的なグラフが木構造にならないのは当たり前だろ
まさかそんなことを言いたいがためにこちらの質問に回答できなかったのかw
呆れた

現実に色んな分野でプログラミングするとわかるが循環参照なんてほとんどの分野で出てこないか回避できて残りはレアケース
なぜなら現実の様々なシステムからアプリまで全てにおいて出てくるデータ構造は何らかの視点で見ると木構造になっているからである
さらに既に例で示したようにベルマンフォード法などのグラフにおけるアルゴリズムを扱う場合も現実のプログラミングでは配列として扱われている
だからそんな非現実的な机上の空論で悩む必要はない

>>442
そういうレアケースのために
Rustでは双方向リンクドリストも含めて標準ライブラリに用意されている
その上で注意書きとしてほとんどのケースではリンクドリストを使うよりも配列やリングバッファ(RustではVecDeque)を使った方が有利と明記している
これは言語に関係なく成り立つ話
2022/03/02(水) 06:20:20.10ID:re9dUtRi
>>444
そんな単純なことが返事できなかったのはお前だろｗｗｗｗ
そんな頭で「非現実的な机上の空論」とか言ってる場合じゃない
循環参照問題はレアケースではなく明確で常に回避を必要とし、各分野で日々回避方法が研鑽されている
Rustも例外ではない
2022/03/02(水) 06:39:13.56ID:S8+3WyDZ
>>445
そんな当たり前のことをわざわざ尋ねてくるほど君が低レベルとはその時は想定していなかった
結局のところ君は具体的な反例を出せずに非現実的な机上の空論を続けるだけなのかね

現実の様々なシステムからアプリまで様々なものにおいて出てくるデータ構造は何らかの視点で見ると木構造になっているものがほとんどであり循環参照で悩む必要はない
一般的なグラフ上の各種アルゴリズムについても配列上のデータとして扱われるのが通常
ポインタで指し合うデータ構造をとってもポインタを何度もたどるのはメモリアクセスで不利でキャッシュ的にも不利であり、もちろん永続化として格納する時も同じく
2022/03/02(水) 06:42:03.58ID:re9dUtRi
俺が言ってるのは循環参照問題は重大な問題であるということｗ
反論出来てないのはお前ｗ
Rustの標準ライブラリはunsafeのオンパレードだなｗ
2022/03/02(水) 07:11:01.35ID:jfLsV1Py
>>447
その最後の行「Rustの標準ライブラリはunsafeのオンパレードだなｗ」によって
あなたがプログラミングについて無知だと判明しました

言語関係なく一般的にその「unsafeな操作」無しではプログラミングは成立しません
そのため各プログラミング言語はその「unsafeな操作」を様々な方法で閉じ込めようとしたり
あるいはC/C++のように全開放して全てをプログラマーの自己責任としたりしています
いずれにしても各言語の内部では「unsafeな操作」が当然ながら頻出となります

一方でRustでは従来にない以下の方針を取ることにしました
・GCを言語としては採用しない
・それにも関わらずプログラム全体のメモリ安全性をコンパイラが保証できるようにする
・必ず残る必須な「unsafeな操作」は型やモジュールの外に影響が出ないよう内部に閉じ込める
・その型やモジュールが外に提供するインタフェースは(unsafe宣言されているものを除いて)安全に提供する
つまりプログラミングをする上で避けることができない「unsafeな操作」を
C/C++のように(結果的に)プログラム全体に散りばめてしまうのではなく
ライブラリなどの内部に完全に閉じ込めて外に影響が出ない安全なインタフェースのみ提供することにしたのです

Rustはこの方針によってプログラミングに不可欠な必須の「unsafeな操作」なだけでなく
実行効率の良さのための「unsafeな操作」も型やモジュールの内部に閉じこめることが可能となりました
そして安全なだけでなく速さも両立することに成功しました
2022/03/02(水) 07:19:39.02ID:re9dUtRi
いやいや、普通unsafeなコードというのは外部とのやり取りの薄皮一枚だけで収まるはずなんだがｗ
Rustだと都合により内側でも使います！
みたいな使い方で、標準ライブラリの中ではやりたい放題されてるように見えるってことｗ
ベアメタルとかになると標準ライブラリも使えないわけで、薄皮一枚だけunsafeにしても足りず泣く泣くunsafeを使う羽目になり、、、
安全とは一体・・・になりそうってことなんだわｗ
2022/03/02(水) 07:27:54.59ID:jfLsV1Py
>>449
そんなに無知を曝け出さないほうがいいと思いますよ
「unsafeな操作」とは何か、そしてその避けられない操作に対してRustがどのように
並行並列環境に至るまでメモリ安全性の保証を実現させたのか勉強するのをお勧めします
2022/03/02(水) 07:30:04.06ID:re9dUtRi
所有権と速度の問題を回避するためにunsafeに走ってませんか？？？？ｗ
2022/03/02(水) 09:17:36.83ID:uPKvDIET
>>449
ベアメタルでliballocは使えるからデータ構造を再実装しないといけないケースはあまりないのでは？
453デフォルトの名無しさん
垢版 |
2022/03/02(水) 09:26:05.15ID:bQ8fspy2
>>440
温故知新ですな
454デフォルトの名無しさん
垢版 |
2022/03/02(水) 09:36:25.73ID:bQ8fspy2
>>449
unsafeは無くすことできないから閉じ込めるってことなんだが。
unsafeあったらダメ原理主義者ですか？
455デフォルトの名無しさん
垢版 |
2022/03/02(水) 10:24:25.41ID:/7glPJ4X
>>432
結局データの配列として持つことになるのはわかるけど、それって指す先が存在するか分からないから実質ポインタとやってること同じだし、途中で要素削除があるとインデックスの整合性保つのに一苦労するじゃん

まあ君にとっては「レアケース」であり「現実に必要となることが存在しない」のかもしれんが、実際に存在するとだけは言っておくわ

あと、配列とインデックスの方がメモリアクセスも速いってのはわからんかった。配列とインデックスの方がポインタより速いってなんでだろ
456デフォルトの名無しさん
垢版 |
2022/03/02(水) 10:28:21.60ID:/7glPJ4X
まあベルマンフォードする前に配列とインデックスの形式に変換するくらいのことは出来るけど、結局その前段階のミュータブルなグラフを配列とインデックスで管理するのはキツい
アリーナでオレオレ世代型GCモドキを作った方がまだマシ
457デフォルトの名無しさん
垢版 |
2022/03/02(水) 10:32:20.03ID:/7glPJ4X
あとは配列とインデックスの代わりにHashMapとkeyにするとかかな？
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。