次世代言語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(土) 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以外あるんかね？

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

研究でだったらhaskellでだってカーネル開発あるけどな

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

> スタックベースのRAII

ほかに何ベースのRAIIがあるの？

> 生存スコープの管理にスタックを使ってるだけ

変数のスコープを静的に解釈してデストラクタ呼び出しを追加してるだけでは？
スタックをいつどうやって使うの？

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

メジャーどころのOSのカーネルだとCかC++かアセンブリだよね
かろうじてLinuxにRustが取り込まれそうだけど当面はドライバのみで使途は限定的

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

>>349
LinuxだけでなくAndroidもRust導入した

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

>>343
見苦しい言い訳をするな
1000個アロケーションされてると書いてるんだから1000個アロケーションされてるんだよ
配列がどうとかの話は言ってない
お前が読み飛ばした部分だよ
適当にしか読んでないから飛んだんだろ
人の文章を読みない上に話を変えようとしてる
お前こそがプラグラマに向いてないぞ
残念ながらお前の負け

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

>>269
たしかにRustでRc/Arcが使われるのは限定されたケースのみではあるが、
例えばスレッド間での共有では使わざるを得なかった。
しかし来月リリースのRust 1.63では、スコープ付きスレッド生成(spawn)がstableとなるため更に使用頻度が減ることになる。
これにより参照カウントを使わずとも共有(借用)できるようになり、Rustの高速化と利便性が更に進む。

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

>>351
1000個アロケーションされることと1000回アロケーションされることの区別もつかない馬鹿は黙ってろw

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

論点がズレたからもう一度まとめておく
Goでは無意識的にヒープにアロケーションされてしまう可能性がある
それはエスケープ解析をしないとわからない
つまりメモリ使用量も実行効率も落ちる
これは一般論
恣意的な特定のベンチの数字を言ってるわけではない
rustは明示的にヒープに置くように書くのでそのようなことは起きない
つまり理論的にはrustが1番速いし最高の言語
もう一度言うが特定のベンチの話をしているのではない

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

>>353
だからお前はメモリ使用量の話をしてたからだろ
それに配列の話はしてない
何度も言わせるな
どこに配列と書いた？

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

もう一度まとめておく
おれに喧嘩を売ってきたやつはメモリ使用量と実行効率をわかってないと言ったが以下のように考えている
メモリ使用量については1000個ヒープにアロケーションされる可能性があるGoが不利
そして実行効率もヒープアロケーションによってGCが動くため悪い
シンプルすぎる当たり前のことを言ってるだけなのだから単に喧嘩を売りたいだけか？
まあ論破ごっこも自爆で負けとるが

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

しつこいと言われるかもしれんが特定のベンチマークの話をしているのではない
もっと普遍的で一般論の話をしている
なのでこのベンチの結果は～というのは受け付けない
同じように普遍的な理論で話してくれ
rustの普遍性は理想的な言語モデルなんだよ

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

メモリの安全性
メモリの自動解放
スタックヒープを意識したコードを書ける
実行効率
モダンな構文
これら全てを満たした奇跡のような言語
今のところ勝てる言語は存在しない

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

結局アンセーフを使ってしまうから無駄

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

唯一の欠点はC++とのInteropぐらいだ
なのでCarbonの存在意義は理解できるが
その代償としてメモリ安全性を失ってしまった
これでは元の木阿弥
まあInterop特化言語だろうからそれで良いのかもしれん
普通の人はrustで良いです

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

しつこく言ってるが特定のベンチマークの結果だけで鵜呑みにするのは間違っている
ソフトウェアに必要なのは普遍性なんだよ
そう言う観点で語ると一つ上の議論ができる

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

rustはゼロコスト抽象化とメモリ安全性という「普遍性」から生まれた
優れた開発者は必ずこの普遍性を設計に取り入れてる

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

言語と言語が対戦する異世界があればどちらか一方は必ずハッピーエンドだが
現実は違うんだよな
C++でできなかったことをRustにやらせても、できない理由の方が多い

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

>>352
Rustコンパイラの進化が素晴らしいね
それら安全であるとコンパイル時に静的に確定できることの範囲をどんどん広げていってる
これは他のプログラミング言語には無い思想でまさに次世代言語
そしてそれら安全となった操作がコスト最小で実行できるようになるのだからRustが安全最速を独走

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

>>355
メモリー使用量？
細かい実装上の差異を除けばヒープに取ろうがスタックに取ろうが同じだぞ
必死に連投する前にちょっとは勉強してこい

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

>>350
AndroidのカーネルってLinuxの取り組みとは別にRust導入してるの？
それともカーネル以外の低レイヤー領域の話？

>>359
まだunsafeを一カ所でも使ってしまうと台無しになる論唱えてるの？

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

プログラムが使用するメモリの総量の話をするなら
そもそもスタックにはたかだかプロセスのスタックサイズ分のデータしか載らないので
メモリ使用量の観点でスタックとヒープの差違を議論しても有用な比較にはならないのでは
メモリ使用量に占めるデータと管理領域の比率という意味ならスタックの方が良いだろうけど

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

IO待ちが主体のプログラムでそのメモリ効率とやらがボトルネックになることはないといってるのでは？

>>255
でメモリ効率がいいからパフォーマンスがいいとか言ってわけだけど、そんなことよりIOがボトルネックになるからいかにブロックしないように書く方が大事ってのはまさにそうだね

そのメモリ効率云々ってのが重視されるのって組み込みとかでWebサーバーなどでそんなのどうでもいいに決まって

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

>>366
Androidは新しいBluetoothスタックとかDNSリゾルバなんかがRustになってるよ

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

まるでRustのネガティブキャンペーンやってるようだな

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

IOバウンドなプログラムでRustを積極的に採用するメリットなんかほとんどない
Goが現在ではベストな選択、次点でNodeなわけだけどなんでかっていうと
GoはC言語+GC+並行処理ってなぐらいでものすごいシンプルだから。
普通の手続き言語触ったことがあるなら、並行処理以外は全く覚えることはないから1週間あればすぐにチーム開発に参加できるぐらいの容易さがあるわけ。
エンタープライズではまずこの容易さがないと流行らない。

それに比べRustはまず並行処理がランタイムに組み込まれておらず、tokioとかいうライブラリを使うわけだけど
そもそも並行処理以外の言語部分での学習コストが高すぎるから、C++での豊富な経験でもない限りチーム開発の戦力になることは難しい。
tokioもGoみたいに抽象化されていて簡単に扱えるわけじゃないからこれも非常に学習コストが高い。

そもそもそんなパフォーマンスが重要ならC++で非同期プログラミングでもやればいいわけだけど、こんなのやってソフトウェア作ってる企業なんてほとんど存在しない。
つまりバカでも扱えるような言語ではないと企業で流行ることはない。(OS開発などは別)
DenoはRustで作られてるけどバカではRustは使いこなせないからわざわざ労力をかけてDenoを作ってるんだよ
Rustが優れてるからDenoがいらないとはならない。

Rustはあくまでも選ばれし人間にのみ使われる言語。自称玄人が背伸びして使う言語ではない。

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

>>371
おまえはGoとNode以外に何が使えるの？
比較対象をきちんと列挙せずに自分だけで完結してベストとか言われても困る

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

RustはJavaの遺伝子を受け継ぐから組み込みやウェブでも流行するだろ。
Androidアプリの開発言語に採用されるかもしれん。
Javaではありませんよ言語とか苦しい言い訳しないで済むし。

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

picojavaのようにpicorustプロセッサが出来るかもしれませんよ。
と思ったらすでに在った。

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

5chで次世代言語と言えば、織田信長しかないんだけど。
忘れてやしませんか？
それとも意図的に無視してんの？

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

>>371
その用途ならばRustがオススメです
Goとの比較で言えばRustの方が高速かつ省メモリにすることができるだけでなく
Goの貧弱な言語仕様とは異なりRustは開発効率も高いです

NodeとDinoはJavaScriptなのでそれらよりも遅くメモリも多く必要とするだけでなく
Worker以外はシングルスレッドの中でしか展開できない限界もあります

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

Denoは言語じゃないだろ
なんでRustと比較できるの？

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

マジでヤベェやつしかいないww
次世代老人スレ

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

パラダイムシフトです。

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

次世代老人とは、今は老人ではない、つまり若者のことである。

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

>>377
それはRust批判をしている>>371さんがRustを叩くための棍棒として持ってきているだけだからでしょう

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

>>381
アンカーつければ良かったな
>>377はもちろん>>371に言ってるよ

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

>>375
おれも大学でGHC/KL1やったことあって、5ch関係なくその辺なんとなく好きだからせめてリンクを貼ってやろう
https://www.fun.ac.jp/~hirata/Papers/spa99-on-slides.pdf

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

>>340
shared_ptrとarc/rcが参照カウンタを増減するのは参照をコピーするときとそれがスコープ抜けるときだけどその前後に参照先にアクセスするとは限らないので参照カウンタにアクセスするときにキャッシュミスが発生するかもしれない。
generational referencesではdereferenceするときだけ参照先の世代カウンタを読むので、世代カウンタにアクセスしたときは必ず参照先にアクセスする。キャッシュミスが起きても世代カウンタと参照先が同じキャッシュラインに存在する可能性が高いのであまり問題にならない。
generational referencesは参照カウンタと違ってヒープを確保するとき以外はメモリに書き込みを行わない。
なので単純に遅いとは言い切れないと思う。

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

>>384
実際のプログラミングを考えれば分かるように、その利用のほとんどが参照先にアクセスすること。
つまり解放の頻度が非相対的に常に低いのが特徴。
なぜなら、解放の頻度が高くてすぐに解放されるような用途ならばヒープは使われないか、ヒープわ使ってもunique_ptrやBox等で多くは済む。
つまりshared_ptrやRc/Arcが使われるのは比較的に長期に保持されて解放の頻度は相対的にも低い。
いずにしても、「解放の頻度」よりも「参照先へのアクセス」がプログラムで起きる頻度の多い主流な出来事。

「参照先へのアクセス」のコスト
【shared_ptrとRc/Arc】コストゼロ (参照カウントは全く使用されない)
【valeのGenerational References】コストが高い (ヒープの世代カウントと参照の世代カウントを比較が必要)
したがってC++/Rustの方法が有利。

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

いえいえ、C++はそんな魔法のようなことはできませんよ。
物理法則を超越するのはRustだけです。

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

>>386
Rustでは出来ている

**デフォルトの名無しさん** · 2022/07/25(月) 00:06:36.72

RustのRc<T>のソースコードを見てみた
参照先へのアクセス時つまりTへのアクセス時には参照カウントは全くノータッチ
つまり>>385で正しいようだ
参照カウントは解放のためだけに使うものだから普段は使わないのは当たり前か