次世代言語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/23(土) 12:56:45.10

そもそもIPAが土方のやり方を推奨してるのが問題

**デフォルトの名無しさん** · 2022/07/23(土) 13:05:43.74

主観的にはRustはかなり開発効率高い
言語そのものもいいし周辺のエコシステムもいい
学習コストなんて二束三文だし

**デフォルトの名無しさん** · 2022/07/23(土) 13:09:35.85

ScalaやHaskellでも同じこと言ってた

**デフォルトの名無しさん** · 2022/07/23(土) 13:14:10.92

他の言語で、初期化と代入の違いを学習したコスト
初期化時には参照カウントが2以上にならないという事実を認識するコスト

こういうのはRustの学習コストにはあたらない

**デフォルトの名無しさん** · 2022/07/23(土) 14:13:31.48

今更な話じゃなく次世代言語の話してくれ。

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

現状Rustはライブラリの選択と学習と継続的な監査のコストが著しく高い
速度やリソース面でそれを補って余りあるメリットがあるようなシステムにしか採用されない

言語だけでみればライフタイム周りの煩雑さがある分だけC#よりもやや面倒という程度

**デフォルトの名無しさん** · 2022/07/23(土) 14:41:37.43

rustが向いてるのは明らかにミドルウェア層だわな。
アプリ層で使おうとするとかまともに仕事で使ったことない奴の戯言でしかないわ。

**デフォルトの名無しさん** · 2022/07/23(土) 14:51:11.37

>>246
> しかも両方とも主開発言語による有意な差はないという結論
どこをどう読んだらそんなアホな結論に達するんだ？
https://i.imgur.com/OQpwGw9.jpg

**デフォルトの名無しさん** · 2022/07/23(土) 15:00:55.50

むしろメモリ効率こそ現代の言語で重要なんだぞ？
CPUの性能は頭打ちというのを知らず？
機械学習みたいな行列演算するなら別だが普通のシステムプログラミングやWebアプリ、組み込みみたいな要件ではコアのパフォーマンスなど無意味

スクリプト言語みたいなGCコテコテの言語が速いことは絶対にない
現代のメモリアーキテクチャを知ってればあんなに参照を作りまくって
オブジェクトに触りまくって速いわけない
それはGoも同じ
現にGoは遅い
現代の言語での要件はスタックとヒープをプログラマが明確に意識でき
かつメモリ管理を安全にできる
これができているのは今のところRustのみ

**デフォルトの名無しさん** · 2022/07/23(土) 15:14:50.07

>>255
DockerとかKubernetesとかコンテナ技術を活用してマシンのリソースを有効活用するって流れになってるのはそうだけど
Rustで置き換えるってのは聞いたことがないな

> スクリプト言語みたいなGCコテコテの言語が速いことは絶対にない
それはIO待ちがほとんどないCPU処理が主体なプログラムでの話じゃない？
Goは適当に並行処理書いても極力処理がブロックしないように動作するけど
Rustは中断ポイントを自分で記述する必要があるから注意して書かないとGoより遅いなんてことはザラにある

このスレッドにあるベンチマークとか見ればいかにGoが優秀であるかがわかる
https://www.reddit.com/r/rust/comments/lg0a7b/benchmarking_tokio_tasks_and_goroutines/

IO待ち主体のプログラムはいかにブロックせずに処理するかが大事なのであってメモリ効率がボトルネックになることはないわ

**デフォルトの名無しさん** · 2022/07/23(土) 15:31:18.71

>>255
そういう特定のユースケースの話をしてるわけじゃないよ
そりゃベンチマークによって速かったり遅かったり
特定のエッジケースで速かったり遅かったりはあるでしょう

もっと数学的かつ抽象的に考えよう
ヒープにオブジェクトが1000個あります
しかしそのうち本当にヒープに乗せる必要があるオブジェクトが100個しかありませんでした
本来ヒープに100個しか必要のないオブジェクトなのに無駄な
ヒープアクセスが900個も起きてしまう
これをメモリ効率が悪いという
Goでもこれは起きうる
もちろんそれが*起きないように*書くこともできなくはないが
エスケープ解析などをしないとわからないし非常に難しいでしょう
しかしrustではこのようなことは起きない

**デフォルトの名無しさん** · 2022/07/23(土) 15:31:55.55

レス番間違えた

**デフォルトの名無しさん** · 2022/07/23(土) 15:40:38.68

自演失敗お

**デフォルトの名無しさん** · 2022/07/23(土) 16:04:31.85

>>257
> 無駄なヒープアクセスが900個も起きてしまう
> これをメモリ効率が悪いという
お前はまず用語をちゃんと使えるようになってから出直してこい

**デフォルトの名無しさん** · 2022/07/23(土) 16:08:37.49

>>260
よくわからない
何が間違ってるの？

**デフォルトの名無しさん** · 2022/07/23(土) 16:14:43.93

>>252
ライブラリの選択コストが低い言語ってのは標準ライブラリがでかい言語のこと？

**デフォルトの名無しさん** · 2022/07/23(土) 16:22:30.56

>>261
アクセス回数の話なら実行効率
メモリー効率は必要とされるメモリーの量

**デフォルトの名無しさん** · 2022/07/23(土) 16:33:12.53

自演rust狂信者の圧倒的な敗北.....
Rc<T>で無駄なメモリアクセスが起きてることを分かってない。参照カウントで、かなり無駄なカウントアップ・ダウンが現実に起きてるし非効率。
エスケープ解析なんぞでわかるのはほんの一部、goでメモリアクセスが遅めに見えるのは、goroutine間の変数への排他制御が無いからだしGCのせいでもない
古典的なメニーコアを素直に活用できない言語では起きない事を同じ土俵で無理に比べようとしている
確かにgoやrustがstructを使って、javaのようにobjectではないのはメモリー効率を考えているけど、ピープなんちゃらの説明はホントに
分かってないアホの説明。GCで掃除される対象の変数へのアクセスのことを言いたいのだと思うけど、そんなのアクセスするかはGCアルゴリズム次第だ
1回でいいから参照カウントの欠点を調べてこい

**デフォルトの名無しさん** · 2022/07/23(土) 16:47:16.76

AndroidアプリをKotlinベースで作っているんですが、
一定時間スマホ操作ができなくなるような機能を作りたいのですが、どうやればできますかね？
いわゆるデジタルデトックスアプリみたいに、一定時間画面を覆って操作できなくなるアプリ
（バックグラウンド写ったりしないやつ）を想定してます

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

>>263
無駄なヒープアロケーションが900あるって書いてあるやん
>>257の文章は気持ち悪いけど
そういうことは起きうるよねとは思うよ

**デフォルトの名無しさん** · 2022/07/23(土) 17:11:14.32

>>265
セキュリティ的に問題があるから無理
何もできないホームアプリを作って設定するくらいじゃないかな
それでも抜け道を完全に防ぐことはできないと思う
奥の手としては、バックグラウンドサービスでマルチスレッドで無駄な計算をぶん回して使用に耐えないくらい重くすればいい

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

>>266
> 無駄なヒープアロケーションが900あるって書いてあるやん
お前プログラマに向いてないだろ...
書いてあるのは
> 無駄なヒープアクセスが900個も起きてしまう
な

**デフォルトの名無しさん** · 2022/07/23(土) 18:08:33.07

>>264
プログラミング経験が少なく勘違いしてるのだと思うけど
C++のshared_ptrやRustのRc/Arcはほとんどのプログラムではその出現が0個～数えられる程度
別の者が同時に同じ物を指し誰が使い終わるかわからないという特殊な状況でしか使われないため出現がレア
実際にプログラミングをするとそのようなケースは多くを避けることができるため極一部でのみ使用となっている
ガベージコレクション言語が全てをガベージとして捨てて回収するコストと比較してC++とRustのこの極一部のみを参照カウントで管理する方式は圧倒的に速くて有利となっている

**デフォルトの名無しさん** · 2022/07/23(土) 18:17:12.38

> C++のshared_ptrやRustのRc/Arcはほとんどのプログラムではその出現が0個～数えられる程度

🤭

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

>>256
それは無意味な比較
いくつもリプライコメントが付いて指摘されているように
まずまもともな並行処理コードの比較となっていない
次にそのコードのことをしたいならば別の適用をすることでGoとRustでほぼ同じ時間となることもリプライで示されている
きちんと読まずにそんなことでRust叩きをするアンチは愚か

**デフォルトの名無しさん** · 2022/07/23(土) 18:28:20.30

>>264
何と何を比較していて何が優れていると言っているのかがまったくわからん...
主張を明らかにするかID変えないで発言追えるようにしてくれ

**デフォルトの名無しさん** · 2022/07/23(土) 18:43:45.96

>>271
リプライ読んだ上で言ってるけど？文盲か？
Goはランタイムが賢いから適当に書いても極力ブロックしない様に高速に動作する
Rustは中断ポイントを自分で指定する必要があるから無駄にブロックしないように注意しないといけないって書いたよね？

つまり適当に書いたGo>>>適当に書いたRust

となるわけ。

**デフォルトの名無しさん** · 2022/07/23(土) 18:45:49.99

>>269
Rcが極一部にしか出てこないのもそうだが
>>264はもっと大きな勘違いをしていて「Rc<T>で無駄なメモリアクセスが起きてる」と書いて参照カウントを批判している
実際にはRc<T>にアクセスしても付加コストはゼロでRcでないポインタとコストは同じ
つまり無駄なメモリアクセスは発生しない
参照カウントにアクセスされるのは生成clone時や解放drop時などのみ

**デフォルトの名無しさん** · 2022/07/23(土) 18:50:33.61

>>273
中断ポイントを自分で指定するとは意味がよくわからないので解説してほしい
もう一つ、適当に書いたコード同士の比較をしていることも現実離れしていて何をしたいのかわからない

**デフォルトの名無しさん** · 2022/07/23(土) 19:26:59.84

>>273
> つまり適当に書いたGo>>>適当に書いたRust
そういう主張ならGoのほうが楽に書けると言うべき

**デフォルトの名無しさん** · 2022/07/23(土) 20:04:44.48

>>276
ちよっと違う
その部分の話に限定すると
Goは他に選択肢なく書けてそこそこの性能が出る素人向け
C++/Rustはもっと多様な選択肢を取れてGoより高い性能を出せる玄人向け
そのことに加えてGoはランタイムコストが高くメモリについてもGCコストがかかる
あとGoは使用が適している分野が狭い

**デフォルトの名無しさん** · 2022/07/23(土) 20:24:12.66

つまりエンタープライズに適してるのはGoで
選ばれた人が作る出来のいいOSSに適してるのはRustだな

玄人によるRust>>>>>>素人によるGo>>>ここにいる自称玄人によるRust

ということだな

**デフォルトの名無しさん** · 2022/07/23(土) 20:37:54.47

>>278
使っているとGoは性能面だけでなく開発面での限界も感じてくる
Goはあくまでも簡素なスクリプト言語＋αの位置付け

**デフォルトの名無しさん** · 2022/07/23(土) 20:43:18.42

とか自称玄人がほざいておりますわw

**デフォルトの名無しさん** · 2022/07/23(土) 20:59:08.03

>>279
さすがにお前が言うと説得力ゼロ

**デフォルトの名無しさん** · 2022/07/23(土) 21:00:05.36

Goの出自からしてpythonの置き換えみたいなとこあるし。

**デフォルトの名無しさん** · 2022/07/23(土) 21:02:59.95

Goは言語仕様が弱すぎて開発に向かないが並行プログラミングが上手くできるスクリプト言語と捉えると優秀なスクリプト言語

**デフォルトの名無しさん** · 2022/07/23(土) 21:13:25.84

Googleはわざわざ開発に向かない言語を開発して社内で使ってるわけかw
Google社員ですらC++は扱えずに問題だらけだったからそれらを解決するためにGoを開発したわけだけどな

Rustは明らかにC++の代替だね。つまりOS開発やドライバ開発、OSS用途に向いてるだろうね
で、WebプログラミングをC++ってやりますかって話ですよ

ここにいる自称玄人の方々はOS開発とかドライバ開発とかしてないくせにRustという言語使ってることだけにアイデンティティを感じる可哀想なおっさんなんだよな結局
だから他言語を馬鹿にしてマウント取ることに生きがいを持った人生を送ってるわけだね

Goで作られた素晴らしいソフトでDockerやKubernetesやGoogleサービスがあるわけだけど、重要なのは何を問題解決するであって特定の言語をこだわって作るわけじゃないよ、自称玄人さんw

**デフォルトの名無しさん** · 2022/07/23(土) 21:33:42.76

>>284
RustをC++の代替としてしかとらえることが出来ないのは理解不足だな
CやC++とは異なりRustは自動メモリ解放だからという理由だけではないが現実にJavaからRustへの移行も起きている
さらにスクリプト言語からの移行例もある
これらは高速さや省メモリの観点からだけではなく並行並列プログラミングにおけるデータ競合の問題までもRustは解決していることが大きい
Rustがデータ競合をコンパイル時にエラーとして見つけ出してくれることはバグの減少や実行時デバッグの激減ももたらしている

**デフォルトの名無しさん** · 2022/07/23(土) 21:34:22.09

webやってる人間ならむしろrustに好意的になるよ
子供にはわからんか

**デフォルトの名無しさん** · 2022/07/23(土) 21:36:09.58

docker,kubernetesを実装しても開発言語に向かないとか言われちゃうの意味わからんわ。

**デフォルトの名無しさん** · 2022/07/23(土) 21:44:18.63

>>285
日本企業の採用例は？どこに移行例があるの？
メルカリはGo使いまくってるみたいだけどそういう企業ってRustあるの？
GoogleやMicrosoftもOS開発で注目してるだけだよね？

データ競合なんて多数あるバグのほんの一部でしかないしそれだけ持ち出されても何も響かないね
競合状態は防げないわけだし、データ競合ならGoでもランタイムだか検知する機能はある、テストでも検知できる、それで十分としか思わないね。

**デフォルトの名無しさん** · 2022/07/23(土) 21:44:33.34

>>287
Goは言語仕様が弱いから開発には不向きだけど
高度な仕組みは不足していても地道に書いていけばもちろん何でも作れる
成果物があることと開発に向いていないことは矛盾しない

**デフォルトの名無しさん** · 2022/07/23(土) 21:53:20.94

>>289
〇〇の機能がある自慢ならHaskellやScalaもよくされていたけどこれらの言語って普及しましたかね？

継承を排除してるのがその代表例。
Goの割り切ったシンプルさはエンタープライズでの大規模スケールするソフトウエアの開発を促進させている

RustはOS開発やドライバ、組み込みには普及することはあるけどWebやバックエンドといった高レイヤーでは確実に普及しない。理由はScala、Haskellが普及しないのと同じ。
機能自慢だけで企業で使っていくための実用性がない。
Googleでさえ社員がC++など複雑な言語を使いこなせないからあえて機能を削ったGoを採用している。

**デフォルトの名無しさん** · 2022/07/23(土) 21:55:03.92

>>288
日本企業にこだわるところが理解できないが
例えばクックパッドがRubyで遅いのをRustへ移行した例などあるだろう

Goはランタイムがデータ競合を検知するとの主張は実行時の時点でGoの敗北を意味している
データ競合を静的に実行前に検知できるようにしたRustを使うほうがよい

**デフォルトの名無しさん** · 2022/07/23(土) 21:55:41.92

低レイヤー何も触ってないくせにマウント取るためにRust使って他言語貶めてるゴミクズが多すぎるわ

もはやマウント取ることが目的になってる

**デフォルトの名無しさん** · 2022/07/23(土) 21:55:49.25

>>288
並列絡むバグをテストで検知できれば十分というのは同意できないなぁ
Goがその辺頑張ってるのは知ってるけどそれでも

**デフォルトの名無しさん** · 2022/07/23(土) 22:00:23.38

>>291
開発コストはなんで度外視するの？

例えば単体テストはカバレッジ100%行かなくてもリリースするわけでしょ？それは開発コストとトレードオフをかけた結果80%とか基準を下げてるって面もあるわけ

データ競合は防げても競合状態はRustでも防げないわけで並行処理プログラミングが確実に安全に書けるって保証されてるわけでもないぞ
データ競合なんで数あるバグのうちの1つしかないわけで

GoとRustだと明らかに開発コストは桁違いであって特に新規にプロジェクトに参加したメンバーがいる場合に差が出てくるね

**デフォルトの名無しさん** · 2022/07/23(土) 22:02:31.75

>>291
てめーが移行例がたくさんあるとかほざいてるから聞いてんじゃん
日本人なんだからまず日本企業の採用例を聞いてるわけだが
海外企業でもいいよ

ごくごく一部しかないだろ
大半はOS開発用途。

**デフォルトの名無しさん** · 2022/07/23(土) 22:03:24.19

Discordしか知らないだろう自称玄人どもはw

**デフォルトの名無しさん** · 2022/07/23(土) 22:08:40.01

Web業界でC++よりRubyが流行ったのも開発コストの削減が目的なのであって
RustがRubyみたいにWeb業界で普及することはないだろうね。
自称玄人は実行コストのことしか考えないがそれならアセンブリが最強だろ。
結局開発コストと実行コストが優れてるGoが現時点での最適解となる。時点でNode(Deno)
RustがWeb企業で普及することはまずないね。OS開発の用途では普及していくだろう、

**デフォルトの名無しさん** · 2022/07/23(土) 22:12:19.51

>>290
勉強してからRustを批判した方がいいよ

継承を排除したことをGoの利点と言われてもRustも継承がなくGoと同じだよ
Rustは従来の言語にあった不要な部分や古い部分をばっさりと切り捨てて最新の高機能なパラダイムを組み合わせてシンプルに作った言語
だからRustもGoと同じくクラスも無いし例外(try-throw-catch)も無い

一方でRustは例えば代数的データ型のようなシンプルかつ有用なものを採用
代数的データ型を採用せずに次世代言語を名乗るのはおこがましいので例に出しました
Goとの比較で言えばGoは代数的データ型を欠いているためにエラー返り値の面倒な扱いを招いています
同じように例外を無くしてもGoは記述が面倒になりRustは便利になっていますね

**デフォルトの名無しさん** · 2022/07/23(土) 22:51:05.66

だからお前ら次世代言語の話しろよ。
それ以外は別スレ建ててやれや。

**デフォルトの名無しさん** · 2022/07/23(土) 22:53:24.42

Rust賛否議論に最適なスレッドがこちら！
https://mevius.5ch.net/test/read.cgi/tech/1657382429/

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

実際、次世代言語でやるべきメモリ管理や並行処理の課題はRustだけが取り組んでる感じがあって、それ以外の次世代言語はなんかパンチがないよな。
このスレで次世代言語として上がってるTypeScriptやSwiftやKotlinとかも、既存資産を使いつつモダン言語に緩やかに移行できます～がウリで、言語自体の挑戦があまり感じられないというか。

**デフォルトの名無しさん** · 2022/07/24(日) 00:59:14.24

Goのシングルバイナリは魅力的だけどRustはどうなの
簡単にexe作れる？

**デフォルトの名無しさん** · 2022/07/24(日) 01:00:34.35

>>302
簡単に作れるよ

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

素晴らしい
Rustやるわ

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

>>301
次スレからはtypescript, swift, go, kotlinはスレタイから外せよ。

**デフォルトの名無しさん** · 2022/07/24(日) 01:30:40.07

次世代言語ってどういう意味
そこに序列されるためには既存言語にない画期的な仕組みが必要なのか

**デフォルトの名無しさん** · 2022/07/24(日) 01:45:52.41

>>306
んなもんカッチリした定義なんてあるわけ無いだろ。アスペかよ。
少なくともtypescript, swift, go, kotlinは対象外だろうよ。

**デフォルトの名無しさん** · 2022/07/24(日) 02:35:17.60

>>306
画期的な仕組みでなくてもインパクトのあるものは多い
例えば>>298の代数的データ型なんて古くからある概念で特に関数型言語では昔から使われてきたものだけど
手続き型言語では導入されなかったり導入されていても有効活用できていなかったり
ようするに代数的データ型は無縁か役に立たないか相性が悪いものと思われていた

ところがRustがその代数的データ型をタグ付きunionとなる形の値付きenumとして採り入れて
さらにこれも関数型ではお馴染みのOptionやEither (RustではResult)を
そのenumで表現してRust標準ライブラリの中枢に据えることで
非常に便利で言語の中心として機能する重要なインフラとして一気に昇華させてしまった

つまり古くからある概念や仕組みであっても
有用な形で言語に採り入れることでインパクトのあるものになりうる
次世代言語と称せられる言語はそういうインパクトのある何かが多数あるのだろう

**デフォルトの名無しさん** · 2022/07/24(日) 02:40:05.18

もうﾜｯﾁｮｲつけろ

**デフォルトの名無しさん** · 2022/07/24(日) 03:54:31.36

swiftでアプリ作るか〜って弄ってるので次世代実用言語なら外してもらっちゃ困るし
次世代にはなんとかなるんじゃないかな〜って寝言言語のスレなら外してもらっていいよー

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

>>298
RustにはWebプログラミングには不要な要素が多いって言ってんだろ
文盲乙

OS開発しないのに細かいメモリ管理をプログラマにまかすのは完全に不要な負担である
これはまつもとひろゆきもいってる

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

とにかくWebやバックエンドといった高レイヤー層でRustが流行ることはないのは事実である
論破してみろよ自称玄人は
具体的に移行している企業もDiscordしか知らないみたいだし、Discordでも一部の部分しか採用してない

〇〇の機能があるから優れてる自慢はHaskellやScalaでも起こってた、でも流行らなかった

流行るのはGoやPythonのように機能を削った言語

RustにはOS開発など低レイヤーには必要な要素が詰まっているが高レイヤーでは不要なものだらけである、だから普及しないんだよ自称玄人さん

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

確かにWebでどうなるかはよくわからないな
ひょっとしたらJavaみたいにエンタープライズが使い出すのかもしれん
Webとの関連でいうと個人的にTauriには大いに期待している

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

自称玄人はOS開発やドライバ開発など低レイヤーの経験など一度もないのに、畑違いであるRustを使ってるだけにアイデンティティを感じている孤独なおっさん
だから高レイヤー層では流行らない言われても論理的に反論できず、他言語を貶めて他人にマウントを取ることしかが脳がない
Rustを使っていることが唯一のアイデンティティの哀れなおっさん

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

俺もWeb周りで使われるのはかなり限定的になるんじゃないかと思うな。良い言語だけど採用しただけの価値が出る領域はかなり狭いよ。

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

Web と一括りにしてる時点で議論の対象にならんクズレスでしかない

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

valeのGenerational Referencesって面白くない？
https://verdagon.dev/blog/generational-references
所有者は一つだけだけど非所有者の参照はいくつも持てる。
各ヒープメモリに世代カウントを付けて、参照はポインタ+世代カウント+オフセット値のようなデータになる。
参照先にアクセスするときはヒープの世代カウントと参照の世代カウントを比較して不一致だったら解放されたメモリにアクセスしたと見なせる。
参照をコピーするときは参照カウンタのようなカウントを増減する必要は無い。参照をそのままコピーするだけ。

**デフォルトの名無しさん** · 2022/07/24(日) 08:20:10.22

ときどき現れる、自分んとこにRustがやってくるのが怖くて吠えまくるおじさん
Rustが使えるだけでマウントなんてとるわけないのに、劣等感で震えすぎ

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

>>317
これほんとか？
This is cheaper because programs dereference less than they alias and dealias

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

>>318
やってこないから（笑）

**デフォルトの名無しさん** · 2022/07/24(日) 09:01:53.33

>>319
それは確かに怪しいっぽい

**デフォルトの名無しさん** · 2022/07/24(日) 09:25:03.61

前はRustなんてどの領域でも採用されないと主張していた
その後は大手は採用しないとか、言語オタクしか使わないとか言い出して、今はwebに来ませんようにとお祈りしてる

**デフォルトの名無しさん** · 2022/07/24(日) 09:26:39.85

いや、使われていないだろう。

**デフォルトの名無しさん** · 2022/07/24(日) 09:35:45.64

黒魔術を禁止したいRust。
それはものすごく正しい。
Javaと同じ理念なので、Javaと同じように成功するだろう。
しかし、黒魔術使いがRustを使いたいと思うこともないだろう。

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

魔導士がRustを作ったが、魔導士はRustを使わない。

**デフォルトの名無しさん** · 2022/07/24(日) 09:51:49.50

>>322
WebAssemblyが普通になってきたらRustが来るかもね

**デフォルトの名無しさん** · 2022/07/24(日) 10:05:58.70

>>324
黒魔術が具体的に何を指してるか分からんがunsafeではだめか？

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

webassemblyは
高レイヤーのC++を変えなくても低レイヤーの機械語を変えれば安全になるという
C++を高レイヤーと見抜けない人には難しい技術

**デフォルトの名無しさん** · 2022/07/24(日) 10:14:42.11

>>310
swiftは個別スレあるだろう

**デフォルトの名無しさん** · 2022/07/24(日) 10:17:08.35

>>317
こういうレスを待ってた

**デフォルトの名無しさん** · 2022/07/24(日) 10:20:14.22

>>311
Matzなのか
ひろゆきなのかw

**デフォルトの名無しさん** · 2022/07/24(日) 10:33:10.43

ここは次世代か現世代に限らず言語マウンティングしたいやつらの巣窟

**デフォルトの名無しさん** · 2022/07/24(日) 10:40:42.93

メモリ管理アルゴリズムを変えるたんびに言語を変えるのをやめよう
ライブラリを変えればいいだけ

**デフォルトの名無しさん** · 2022/07/24(日) 11:15:14.23

>>267
難しいのですかね？
下みたいなアプリがあったのでできるのかと思ったのですが、、
なにか特殊な方法が必要なんでしょうか
https://play.google.com/store/apps/details?id=forinnovation.phoneaddiction&hl=ja

**デフォルトの名無しさん** · 2022/07/24(日) 11:55:06.92

不正確：ここは次世代か現世代に限らず言語マウンティングしたいやつらの巣窟
ここはRust言語マウンティングしたいやつら（ただしコーディング能力はゼロに近い低め）の巣窟、まともに話し合うことすら不可能

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

>>307
Kotlinは次世代から卒業したと思ったらオワコン化しちゃったか。
Javaは緩やかに衰退しているし、頼みのAndroidもFlutterに持っていかれそう。

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

RustはOSの開発でもあんま使われてないよね
でも将来JavaみたいなIT土方専用言語になりそうな気がする

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

>>333
メモリ管理周りは標準ライブラリのインターフェースにも影響するけど
標準ライブラリすげ替えたらそれはもう別言語では

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

土方うんぬんはマウンティングではなく職業差別だよな
差別された業種はプロよりアマの方が強くなる
これ資本主義への挑戦だろ

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

>>317
> valeのGenerational References
> 参照先にアクセスするときはヒープの世代カウントと参照の世代カウントを比較して不一致だったら解放されたメモリにアクセスしたと見なせる。

それは重すぎる設計で実用的ではないですね
C++のshared_ptrもRustのRc/Arcも
参照先にアクセスするときは参照カウントへのアクセスがなくコストゼロです
RAIIによる自動解放時にようやく参照カウントを見てヒープも解放するか判断します
やはりC++のshared_ptrとRustのRc/Arcの方式が最も優れた方式と言えるでしょう

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

>>268
理解目来てないのはお前
「1000個ヒープにある」んだよ
まず文章を読め

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

>>300のスレにコピペしといたで続きはそっちでお願いな

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

>>341
まじでプログラマに向いてないんだなw
ヒープアロケーションが1,000回かどうかなんて書いてないだろ
配列で一気にアロケーションしてるかも知れんしな

**デフォルトの名無しさん** · 2022/07/24(日) 17:11:06.10

そもそもRustというかスタックベースのRAIIって結構ヒープアロケーションしてるからな
生存スコープの管理にスタックを使ってるだけ

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

>>336
google的にもflutterをメインにしたいんじゃないかと邪推してる。

**デフォルトの名無しさん** · 2022/07/24(日) 17:20:42.68

>>337
今それを言ったらOSのカーネル開発で使われてる言語なんてC以外あるんかね？