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

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

スレタイ以外の言語もok

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

**デフォルトの名無しさん** · 2022/04/09(土) 14:01:07.29

スレタイの言語間で争える話題ないか考えてみたけど
それぞれ狙うところがバラバラで共通項がないな

**デフォルトの名無しさん** · 2022/04/09(土) 14:06:05.68

rustスレでやれば
もうJavaレベルには普及しないって結論じゃん

**デフォルトの名無しさん** · 2022/04/09(土) 14:11:30.90

次のスレからRustの話題は荒れるから禁止にしてスレタイからも削ろうｗ

**デフォルトの名無しさん** · 2022/04/09(土) 14:14:38.49

このスレで荒れてくれる分には構わんわ。C++スレとかRustスレとかを荒らさないで。

**デフォルトの名無しさん** · 2022/04/09(土) 14:19:25.04

便利さを理解するために不便さを体験するべきか否か論な訳だけど、個人的にはそれをするにしては遠回りが過ぎるのがC++という長大な壁だと思っているので経由する必要はないかなと思ってる
代わりの話としてZigとかどうよ
依存型的なコンパイル時計算と実行時計算をフラットに書ける感じ
結構賛否両論来そうな話題だと思う

**デフォルトの名無しさん** · 2022/04/09(土) 14:22:44.53

あれるのは上等なのか

関数オーバーロードがない言語は軒並み糞

**デフォルトの名無しさん** · 2022/04/09(土) 14:27:38.36

オーバーロードあると高階関数に渡すときに一手間かかるのがヤダ

**デフォルトの名無しさん** · 2022/04/09(土) 14:30:13.22

標準ライブラリの標準関数のシグネチャー変える言語は糞

**デフォルトの名無しさん** · 2022/04/09(土) 14:31:10.30

教育には自分を撃てる言語を使った方が良いのでは？

**デフォルトの名無しさん** · 2022/04/09(土) 14:31:48.55

コンパイルするときにファイルのフォルダ階層に依存する言語は糞

**デフォルトの名無しさん** · 2022/04/09(土) 14:33:14.01

pythonガチアンチ勢がいるらしいな

**デフォルトの名無しさん** · 2022/04/09(土) 14:38:25.49

mainのあるファイルから連鎖的に参照されないと同じフォルダにあってもソースがコンパイルされない言語は糞

**デフォルトの名無しさん** · 2022/04/09(土) 14:40:09.03

言語じゃなかったな
コンパイラ環境か？コンパイラドライバか？

**デフォルトの名無しさん** · 2022/04/09(土) 15:06:56.55

言語依存の特性というよりはコンパイラがインクリメンタルかリカーシブルかなんて、言語にほとんど関係ない・・・

**デフォルトの名無しさん** · 2022/04/09(土) 15:33:43.71

じゃあ
ファイル名がクラス名やモジュール名と一致してないとダメな言語は糞

**デフォルトの名無しさん** · 2022/04/09(土) 17:12:33.80

自分じゃ話題も振らないのに他のスレでやれとかいう輩って・・・

**デフォルトの名無しさん** · 2022/04/09(土) 17:40:19.06

>>741
> 便利さを理解するために不便さを体験するべきか否か論
そう捉える奴も多いのだろうが、それだと完全に精神論になってしまうだろ。

コメントで要求されてる「Howは要らない。Whyを書け」と捉えるべき。(C++はRust仕様のコメント)
つまり、C++でどういう手法が試され、結果としてRustが何を採用してるかを紐解けば、
Rustが何故こうなっているのかが分かる、というわけ。

信者がひたすら「Rustは正しい」と信じることしかできないのは、Whyを知らず、妥当性の判断能力がないから。
ただしHowはRustの場合は文法にしてしまっているので、
Whyを知らなくても、知ってる奴と同等のコードは生成出来てしまう。
だからプロダクト目的のRustドカタには必要がないのも事実。
(これはフレームワークに於いて、何故こんな構造を採用したのか？とか考える必要がなく、
ただ従って正しく使えば生産性が上がるのと同様）

逆にアカデミックとか、Rustの次の言語を考えたい奴がWhyを抑えないのは問題。
信者ではなく、自分で判断してRustを選択したと言いたいのなら、Whyを知らないといけない。

（知ってないと判断出来ないはずなので、論理的に矛盾する。
これはC++の全てを知っておけという意味ではなく、
Rustで採用された「データ競合」「寿命管理」「例外処理」等の対処方法については、
当然だが他のやり方も存在しており、それぞれ一長一短有るから統一されてない。
それらを知らずに、Rustのやり方しか知らず、ひたすらRustマンセーなら、それはただの信者と言える）

**デフォルトの名無しさん** · 2022/04/09(土) 18:34:35.92

色んな言語やってきたが総合的にみてRustが現在のプログラミング言語の中の最強言語で間違いない
理論的に任意の言語が動き実際にも多数の言語が動かされているWebAssemblyにおいてもRustが利用トップである客観的事実もある

**デフォルトの名無しさん** · 2022/04/09(土) 18:36:58.31

話題は>>577で振ったけどスルーされました(^p^)
実際どうなんすかこれ、Yewとかその辺の利用者の使用感知りたいんだけど

**デフォルトの名無しさん** · 2022/04/09(土) 18:48:35.17

C++理解した程度でプログラミング理解したと思ってるのが痛々しい

**デフォルトの名無しさん** · 2022/04/09(土) 20:19:57.41

Rustはボロー周りとEnumだけがよくできていて他はそうでもない
長期で運用しにくいしょうもない弱点だらけ

**デフォルトの名無しさん** · 2022/04/09(土) 20:26:08.31

>>757
例えば？

**デフォルトの名無しさん** · 2022/04/09(土) 20:26:09.05

そうだぞこんなの使ったら駄目だぞ

俺は使うがな

**デフォルトの名無しさん** · 2022/04/09(土) 20:31:58.00

レスをたどる能力もないのかRustの機能や制約を知らないのか自分で何かを調べる能力がないのか
どれなんだろう？

**デフォルトの名無しさん** · 2022/04/09(土) 20:34:48.49

まとめるの面倒だからしないけど弱点だらけだぞ

それでも俺は使うがな

**デフォルトの名無しさん** · 2022/04/09(土) 20:38:12.58

言語面は置いといてrustはまずcargoを何とかしろ
モジュールパッケージの参照の仕組みを改善しろ

**デフォルトの名無しさん** · 2022/04/09(土) 21:14:44.30

次世代次世代つって結局Rustしか話題に上がってないやんｗ

**デフォルトの名無しさん** · 2022/04/09(土) 21:34:11.92

>>763
つまり次世代はRust覇権が確定。Rust一択ってこと。
VScodeが覇権したようにプログラミング言語もそろそろRust一択にしようよ

**デフォルトの名無しさん** · 2022/04/09(土) 23:10:39.42

GoやクソバカPHPoorが滅びるべきというのには同意

**デフォルトの名無しさん** · 2022/04/09(土) 23:31:48.47

それがRustが現在も今後とも流行らない理由だろうね

**デフォルトの名無しさん** · 2022/04/10(日) 00:20:38.04

他の言語でもRustのように広い意味でのデータ競合を実行前にチェックしてくれたらいいのに
そうすればその分の実行時デバッグを無くすことができるのに

**デフォルトの名無しさん** · 2022/04/10(日) 00:52:23.84

>>767
それ、馬鹿の一つ覚えだろうけど、割とマジに、データ競合で困る事なんて無いぞ。
もしみんなが本当にデータ競合に困りまくってたら、あらゆるアプリがRustでキラーアプリ化してるはずだろ。

実際は誰も困ってないし、さらにホームドアを付けたところで元々バグもないから差別化出来ず、キラーアプリ化もしてない。

面倒なのでスルーしたが、256で突っ込まれてるように、
実行時デバッグをそれほど必要としてる時点でプログラマとしてはポンコツ。
初心者なのを自覚して、まずはコードを頭の中で動かせるようになる事を目指すべきだよ。

**デフォルトの名無しさん** · 2022/04/10(日) 00:52:41.03

とかく計算系のライブラリの高速実装がGPGPU関係なくRustよりC++が優先されているのが悲しいが個人でなんとかできる規模でもなく

**デフォルトの名無しさん** · 2022/04/10(日) 01:03:58.92

>>769
やれば分かるが演算系はリソースの確保/開放ははっきり言ってほぼ必要ないので、
C++どころかCでも全く苦労しない。
しかもRustだと使い回すには一々所有権を気にしないといけないだけ面倒。
他言語なら見えれば何度でも問題なく使えるのに。

だからその辺がRustメインになる事はあり得ないと思うけど。実用重視なら尚更。
境界チェックが一々入る分だけ無駄に遅くなるのも致命的ではあるし。

俺は演算部分だけCのdllにして、GC言語からそれを呼び出すのが最強だと思うけど。
つまりNumPyでいい。(なお俺は使った事無いが）

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

>>768
超巨大なコードベースの前で人は簡単にポンコツになるよ
Sanitizerやclang-tidyへのgoogleの投資を見れば分かる

ただこの手のツールが必要になる言語やアプリは限られているから
あらゆる領域でデータ競合抑止が役に立つというのは偽だとは思うが

**デフォルトの名無しさん** · 2022/04/10(日) 01:22:47.07

>>771
それはコードベースが巨大すぎて見落とす確率が高くなるだけだろ。
ただし事実としてこれはあるのは認める。

これについては、Web系見てて思ったんだが、

Java(OOP)：どんな巨大なコードでも、20年前のコードでも、メンテナンスしてみせる！！！
Web系(Restful)：そもそも巨大にならないように分割。
　一人で管理出来るサイズ(1,000-10,000程度)なら管理も簡単だし、コードも最悪書き捨てでもいい。

で、俺はWeb系の方が正解じゃないかと思いだしている。
だから、Javaを殺すのはWeb系だろうなとも思っている。

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

Rustのプログラミング開発効率の良さには感動した
めっちゃ便利やな

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

あ、すまん、分かると思うが、772訂正。

× 1,000-10,000程度
○ 1,000-10,000行程度

**デフォルトの名無しさん** · 2022/04/10(日) 01:35:56.55

>>772
用語の使い方からも
間違った対比からも
知的レベルの低さが露呈している
そこは単純にモノリスvs.マイクロだけであってOOPやRESTは関係ない

**デフォルトの名無しさん** · 2022/04/10(日) 01:51:37.37

>>772
web系というかブラウザやらOSやらの低レイヤーで考えるべきかと
OSもマイクロカーネルにしたらバグ少なくなるのかね

**デフォルトの名無しさん** · 2022/04/10(日) 01:55:17.11

Nimの話題ロクに出てこないね
自分は使ったことないけど、使ったことある人はどう？
他の言語との違いや特色教えてくれると嬉しい

**デフォルトの名無しさん** · 2022/04/10(日) 01:55:40.00

>>775
まあ揚げ足取りはどうぞご自由にだが、話は通じてるようだ。
それで、反論は出来ないのか？
だとすると、やはりRust信者は低脳だとしか思えない。
（議論する気があるのなら、そのレスでは駄目だし）

・巨大化したコードベースではどうしても見落としが発生するから、全部所有権を強制化してコンパイラでチェックする
という直接的な解決策をRustは採用しているが、
・そもそも巨大化しないようにひたすら分割し、見落としが発生しにくい規模に抑える
という、上位アーキテクチャでの解決策もあるのだよ。
これは「データ競合」の時も言ったろ。
そこに問題があれば、解決策もそれなりに用意されてる。（格好いいかはまた別だが）
それでは解決出来てない！不十分だ！と言うのなら、
どうにも取りきれなかったバグがRustによって取りきれ、結果的にキラーアプリ化するはずなのだが、
実際これがないだろ。
なら、これまでの地味な方法でも何とかなってたって事なんだよ。

**デフォルトの名無しさん** · 2022/04/10(日) 02:03:42.86

>>776
> OSもマイクロカーネルにしたらバグ少なくなるのかね
通説としてはそういう事になっている。（まあ知ってると思うが）

Linusはモノリシックカーネルの利点を言ってるけど、あれは俺は後付だと思うよ。
とはいえ速度重視ならモノリシックの方が上だし、
堅牢性重視ならマイクロカーネルってのは、技術的にも正しいと思う。

俺が言ってるのはもっと単純な話で、
機能が少なければ、実装に必要なコードも少なく済み、見落としも減る、という、至極当たり前の話。
だから「仕様を必要最低限に絞る事こそ最強」という話だね。
これもよく言われているとも思うけど。
だから、マイクロカーネルの方が仕様が小さいから実装コードも減り、結果的に「見落とし」のバグは減ると思うよ。

**デフォルトの名無しさん** · 2022/04/10(日) 02:03:43.80

Nim、vlang、Zig、Zenらへんはマイナーすぎてなんとも
D言語が使われなかったのと似たような理由で使われなさそう

**デフォルトの名無しさん** · 2022/04/10(日) 02:04:15.32

結論は変えるつもりがなくそこに至るまでの論理だけを手を代え品を代えひねり出し続ける
信者もそれに対する批判も不毛なんだ

**デフォルトの名無しさん** · 2022/04/10(日) 02:06:36.51

>>778
アーキテクチャとアプリと言語は全て別問題なのに区別がつかずにごっちゃに話しているキチガイに見えます

**デフォルトの名無しさん** · 2022/04/10(日) 02:21:42.17

そんなことより次々世代言語にどういう特徴を持った言語が来るか予想しようぜ

**デフォルトの名無しさん** · 2022/04/10(日) 02:34:28.97

>>780
IT大手各社が珍しく揃って支援＆採用しているRustだけが最近のプログラミング言語の中で長期に残りそう

>>783
Rustを置き換えるような次々世代言語は
Rustが備えるC言語並の速さ省メモリと安全性を押さえた上で異なるアプローチとなるだろうけど
Rust関係の論文が多い状況からすると理論的な裏付けが先行研究としてあるものの中から出てくるのかな

**デフォルトの名無しさん** · 2022/04/10(日) 08:39:07.48

C2とATS2のことも忘れないであげてください！

**デフォルトの名無しさん** · 2022/04/10(日) 09:17:53.01

>>782
それはRust信者はプログラマではないからだな。

プログラマは全レイヤで最適化を模索する事が出来る。（本来は）
例えばだいぶ前にスマホ見てて踏切の内側と外側を間違えて死んで話題になってたが、これについて

・現場(踏切の改善)：踏切内の障害物検知器の精度を上げ、人が間違って立ち止まってる場合も検出し、電車を緊急停止させる(Rust）
もありだが、
・運用（経路選択）：そもそも踏切を通らない経路を選択する。歩道橋があればそれを使う。
・運用（マナー）：歩きスマホ禁止。イヤホンも爆音にはせず、周りの人の声も聞こえる程度にしておけば気づけたかも？
・運用(ポリシー）：外でボーっとしない。事故に巻き込まれる確率は0ではないのだから、常にある程度は周りに気を付ける
・アーキテクチャ：高架化して踏み切り自体を無くす(C#)

アーキテクチャ面での対策が根本対策になるが、現実的には運用での回避になってる。
大人の場合はマナー/ポリシーで回避し、
これを期待出来ない小学生には、通学路なら歩道橋を設置して、経路選択での対策が為されてる。

「データ競合」も同様に、

・現場(チェッカ)：所有権を厳密に管理し、コンパイラでチェック(Rust)
もありだが、
・運用：難しい事はしない。競合する可能性のある場所は限定的にして、見ればバグに気づける程度にする
・アーキテクチャ：スレッド構成上、そもそも競合が発生し得ない(C#)

で、アーキテクチャでの対策が根本対策だが話が大がかりになり面倒になるので、
大体は運用で対策され、でも何とかなってるというのが実態だ。
通常は言語選択はアーキテクチャよりさらに上のレイヤか、そもそも独立した軸なので、
言語比較で一番下のレイヤ（現場）での改善のみに限定するのが間違ってる。
そして重要なのは、既存の言語でも根本対策はやる気になればすぐに出来るんだよ。多少面倒なだけで。
だから信者の言う「Rustでなければ無理だった」というアプリが存在せず、キラーアプリも出てこないわけ。

Rustは「一方ロシアは鉛筆を使った」の米国側を突き進もうとしてる。これもありだが、ロシア側もありなだけの話。

**デフォルトの名無しさん** · 2022/04/10(日) 09:21:12.35

この人は無駄で無意味な間違った例え話を延々と繰り返し妄想の世界に住んでいる

**デフォルトの名無しさん** · 2022/04/10(日) 09:21:25.28

Scalaの方がKotlinより機能豊富だけどWeb系では落ち目になったね
Scalaの方が好きだが

**デフォルトの名無しさん** · 2022/04/10(日) 09:26:20.41

>>788
Scalaは結構好きで長く使っていたけど
使っているとどうしてもJVMが見えてしまう部分があって
Rustに乗り換えちゃったな

**デフォルトの名無しさん** · 2022/04/10(日) 09:29:58.47

rustaceanはある時期を境に爆発的に表に出てきてプログラミング界隈を圧倒する未来が見える

**デフォルトの名無しさん** · 2022/04/10(日) 09:41:23.13

表に出るかなぁ？
OSやコンパイラ、ミドルウェアあたりに侵食して、気付かないうちに全員が依存してる、みたいな状況なら有り得そう

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

scalaはコンパイルが困憊るほど遅すぎた

**デフォルトの名無しさん** · 2022/04/10(日) 10:55:59.09

>>779
>Linusはモノリシックカーネルの利点を言ってるけど、あれは俺は後付だと思うよ。
後付けというか経験知からの意見だろ。
Linusはそもそもが理論家なわけでもないし。
仕様を最初から小さく絞れるとか考えてる奴は全く的外れとしか言いようがない。

**デフォルトの名無しさん** · 2022/04/10(日) 11:21:10.49

Linux作り始めたときからタネンバウムと論争しているのに理論家じゃないとか後付けとか

**デフォルトの名無しさん** · 2022/04/10(日) 11:26:19.70

一部だけ小さくしてバグ減っても意味ないよ。
部分的な最適化はシステム全体の最適化の視点では上手く機能するわけではないからね。
一つ前のFreeBSDで話題になって詳しい人が説明してくれてた。
https://mevius.5ch.net/test/read.cgi/unix/1630061644/794

**デフォルトの名無しさん** · 2022/04/10(日) 11:41:39.32

>>794
だからLinusはタネンバウムみたいな理論家を嫌ってんだろ。議論の中身理解してないのか？

**デフォルトの名無しさん** · 2022/04/10(日) 12:14:41.45

>>783
C言語より10倍速い言語が現われて界隈歓喜

**デフォルトの名無しさん** · 2022/04/10(日) 12:18:37.19

>>783
Googleに頼めば全て完成する

**デフォルトの名無しさん** · 2022/04/10(日) 12:31:07.74

次世代はシンプルな言語仕様+強力な静的チェックだと思う
Rustみたいに事前の宣言でガチガチに縛るんじゃなく、型推論やフロー解析を積極的に利用して利用のされ方に基づいた型チェックや生存期間のチェックを行う
まあこのままいくとJavaScript+VSCodeがそれになるかもしれないが

**デフォルトの名無しさん** · 2022/04/10(日) 12:46:03.55

>>799
ことweb界隈で使われる言語に関しては前半同意

サービス独自の機能をスピーディーに開発することが求められるweb界隈において、プログラマ自身が考えないといけないことが多くなるrustはまず普及しない

**デフォルトの名無しさん** · 2022/04/10(日) 12:55:32.64

>>793
運用していくうちに追加追加で仕様が段々膨らんでいくのはある程度仕方ないとして、
それでも更新タイミングで不要な仕様を出来るだけ削除して仕様を絞るのは基本中の基本だろ。
マイクロカーネルもある意味これで、「カーネルがやるしかない事しかやらない」という、最小仕様を目指したものだ。

プログラミングに於いて小さい仕様を目指すのは大正義だし、みんなそうしてる。
（出来てるかはまた別。特にJava分野。
対してWebの場合はこの辺切り捨てるしサービス終了もありありなので、
反発はあるかもしれないが、仕様が雪だるま式に膨らんでる事はない。
俺はこの辺、Java流の「どんなに大きくなっても何とかしてみせる」ではなく、
Web流の「定期的に棚卸しで削除」の方が長期的には正しいのではないかと思いつつある、という事)

>>794
Linusは当初から分かっててモノリシックを選択したのはいい。
当時の速度的にそれが妥当だったのも分かる。

ただ、今となってはマイクロカーネルにすべきだし、徐々にでも変更していくべきだと思うよ。
今でもモノリシックの利点を説いているのは、後付のように思える。

**デフォルトの名無しさん** · 2022/04/10(日) 13:03:29.70

>>794
「俺は後付だと思う」って予防線貼ってるし、そこまで知らなかったんだよ、きっと
許してあげて

**デフォルトの名無しさん** · 2022/04/10(日) 13:10:21.13

>>799
Rustのように型が強力でコンパイル時チェックの細かいGC言語ってのが現状ないから
そこは新言語の余地がある気がしている
JSだとどうしても型はガバガバにならざるを得ないからなぁ

**デフォルトの名無しさん** · 2022/04/10(日) 13:17:50.89

言語には向き不向きがあるわけで
それを無視してRustがすべての言語を置き換えるみたいな話をしているのがおかしい
C/C++の置き換えは進むかもしれないけどwebやスマホやPCアプリとかでは採用されないでしょ
普通はどの言語が最適かをいろいろ検討して決めます

なんか通販の広告みたいなんだよね
良いことしか言わないし
大手IT企業が採用ってのは通販広告の有名人も愛用！みたいな感じ
コンピュータ関係の新技術の売り文句は100%そうだった試しはないので話半分で聞いていた方がよいと思う

**デフォルトの名無しさん** · 2022/04/10(日) 13:30:51.71

>>804
ほんまこれ
このスレの一部のRust信者がRustこそ至高みたいなノリだけど、このノリについていけないRust推し結構いると思う

**デフォルトの名無しさん** · 2022/04/10(日) 13:55:42.06

いつでも最初から型が要るのは足枷というのは確かに思うわ
そうなると漸進的型付けってやつかねえ
TS以外のaltJSは死んだとかだれかが言っていたが、Haxeの再興もあるか？

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

>>805
というよりRustは好きだけど別に推してはないという
誰も使わなくていいよ
俺と一部のお前らが使うだけでいい
みんなに使ってもらう必要なんて一切ない

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

>>807
そう思ってるなら言わなきゃ良いんじゃないですか？そういう他の言語を使ってる人を小馬鹿にした態度がRust推しそのものでしょ、しかも良い印象は全く受けない

**デフォルトの名無しさん** · 2022/04/10(日) 14:16:40.89

アンタにレスしてないから気にしないでね
人を小馬鹿になんかしてないし
Rust以外の言語も好きだし
そもそもどの言語も馬鹿にしたりしない

**デフォルトの名無しさん** · 2022/04/10(日) 14:23:28.49

こういう屈折した性格の勘違い野郎ばっかで本当に近づきたくない。扱いにくいのに能力なんてないし言語触ってれば最先端だと勘違いしてる、とんでもねえバカ

**デフォルトの名無しさん** · 2022/04/10(日) 14:40:08.25

RustはMozillaのステマでfirefoxのRust導入は
不可能と叩きが暴れてた頃が懐かしいなあ～

**デフォルトの名無しさん** · 2022/04/10(日) 14:57:34.06

>>810
まあ勘違い馬鹿は必ず存在するのである程度致し方ない。
連中は基本的に「難しい言語使ってる僕すごい」であり、
プログラミング言語の優劣を自己で判断する能力はないので、
何か新しく「凄いけど難しい！！！」とされる言語が出てきたら勝手に移住する。
だから、対策としては、何でもいいから新しい言語を作って適当に吹聴する事だね。
そうすればRust界隈も浄化される。

なお一時期はC++の連中の選民思想が超絶にウザかったが、これが今はRustになってるだけ。
ならC++スレはどうなったかと思って見てみたら、完全にお馬鹿の溜まり場になってたわ…。
まあ○○言語を使ってれば賢いって事にはならないので、当然でもあるのだが。

**デフォルトの名無しさん** · 2022/04/10(日) 15:13:47.07

ちんちんシュッ！シュッ！シュッ！

**デフォルトの名無しさん** · 2022/04/10(日) 15:18:10.17

完結に喋れない病気直ってないの？

**デフォルトの名無しさん** · 2022/04/10(日) 15:22:51.62

>>783
はっきり言えば、誰も「新言語」なんて必要としてないだろ。
欲しがってるのは、各自が気に入った言語での、
・バグを自動的に検出してくれるゴリゴリのリンター
・Cと同速で動く爆速環境
であって。

はっきり言ってRust信者の「Rustは書きやすい！！！」すら方便で、連中は
・リントが強く、データ競合が起きない
・寿命管理ががっちりしてるので、GCなくてもメモリリークが発生しにくい
事がRustの買いだと言ってるわけだが、
Rust信者すら、信者になる前に使ってた言語でこれらを満たす状況になってたら、そのままその言語を使い続けてるだろ。

寿命管理はGCが爆速なら（リアルタイム系以外は）誰も文句言わないのでこれで決まり。
データ競合バグは言う程問題でもないが、
これをどうしても避けたいのなら、JSのように基本シングルスレッドにしてしまえば根本解決する。
だからこの2点が必要とされてるのなら、JSの爆速環境があれば済む話。

JSにおいて速度の枷は動的型であり、だからこそTSでアノテートだが、JSに変換して実行してる現在では速度メリットはない。
だからV8(JSエンジン）がTSをそのまま食うようになれば、解決する。期待値としては多分現行の倍速程度にはなる。
あるいはBlazor(WebAsembly)がこれに近い状況。

ただし世界が望んでるのは、Python/RubyがとりあえずJS並に高速化する事だね。
ただ俺はPython/Ruby連中が高速化についてあまり真剣に取り組んでない（ように見える）のは意味が分からないのだが。
Matzも新言語作るんだーとか言ってたと思ったが、あんたがやるべきなのはRubyの高速化でしょうが、と。

**デフォルトの名無しさん** · 2022/04/10(日) 15:22:54.24

>>811
なんか最初の頃はMozillaの印象強かったよねえ

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

>>805
そもそも5ch以外で信者っぽい人見たことないけどな
リアルでもTwitterあたりでもみんな複数言語使ってる中の一つにRustもあるってだけ

**デフォルトの名無しさん** · 2022/04/10(日) 15:33:46.76

>>815
ruby3はruby2の3倍高速化というお題目でそれなりの成果を出した訳だけどそれでもまだまだ足りないと言うのね

スクリプト言語で高速化するためにはボトルネック箇所をCなりで置き換えるのが普通
JSはブラウザで動かさなければならないという制約上言語自体を高速化する必要があり
ブラウザベンダー大資本がつぎ込まれた結果高速化した
前提がかなり異なるから同じことがruby/pythonに起こることはないのではないか

**デフォルトの名無しさん** · 2022/04/10(日) 15:56:47.79

>>818
> ruby3はruby2の3倍高速化というお題目でそれなりの成果を出した訳だけど
それよく勘違いされてるが、
3倍になった『部分がある』だけで、全体が3倍になったわけではないよ。
(これは公式でもこう『追加』アナウンスされてたはず）

俺が思う割と正当な比較はこれだが、
> https://1.bp.blogspot.com/-rfuoTnmJM5Q/X41w-eFt9QI/AAAAAAAAJcc/nFNdlKqfs6sRKna-85JxpmzrAe1bw0tGQCLcBGAsYHQ/s0/3730357d-results-energy-time-and-memory-usage-screenshot-from-research-paper.png
> https://okuranagaimo.blogspot.com/2020/10/blog-post_19.html
「Pythonは100倍以上遅いぞ」なんて言われる事も多く、
C比だとJSで5-6、Python/Rubyは80-100程度だと思ってる。
だからまずはJS並にするだけで16倍程度は高速化するわけであり、CやCythonは嫌だ…な連中には十分だと思うんだよ。
Rubyも16倍のクライアントを捌けるようになれば鯖代も半分以下に出来るだろうし。
(そもそもコードが汚れるのは無理に速度チューニングしたコードにするからであり、
馬鹿みたいなコードでも速く動くのならコードも綺麗に保てるし）

> 前提がかなり異なるから同じことがruby/pythonに起こることはないのではないか
逆に言えば、金さえつぎ込めば改善出来るわけで、
改善項目とそれに要する金額をずらっと羅列して、クラファンで資金が付いたところから実行、
十分な結果で採り入れられたらそいつがその資金を給料として獲得、とかいう方式にすれば、
割とすぐにでも行けるんじゃないかと思うんだけどな。

**デフォルトの名無しさん** · 2022/04/10(日) 15:58:01.34

>>815
> JSにおいて速度の枷は動的型であり、だからこそTSでアノテートだが

違うよ
ブラウザがTSをそのまま食えるようにするというのは開発者側でトランスパイルする必要性を無くすだけで実行速度の改善を目的としたものではないよ
ていうかその方向性はasm.jsとかPNaClみたいな先駆者がいて彼らの現状の到達点がWASMという経緯があるよ

**デフォルトの名無しさん** · 2022/04/10(日) 16:21:05.00

>>820
> 実行速度の改善を目的としたものではないよ
それは知ってるが、JSの速度改善には型の固定（静的型)が必要だから、「『Any無しの』TSを食わせる」必要があるんだよ。
その前段階として「TSを食わせる」が必要なわけ。
（実際やろうとしてるかは知らん)

asm.jsはお世辞にもいいものとは思えない。
あれもJSエンジン内で型を固定出来てるわけではないし。（ただJITだとあれでも行けるのかな？)

PNaClは知らない。けど削除されちゃったよね。
ただwiki見る限りWebAssemblyでいいから削除、みたいな感じのようだが。

「Any無しのTSを食わせる」位ならBlazorでWebAssemblyしろってのはその通りだが。
だからWASIも方向性としては有ってて、最高に上手く行けばJVMを置き換える事になるかもしれんけど。
(Java言語そのものは死なず、JavaからWebAssemblyを吐くようになるだけだが）

**デフォルトの名無しさん** · 2022/04/10(日) 16:49:31.19

知らなかったくせに

**デフォルトの名無しさん** · 2022/04/10(日) 16:53:31.25

毎日Rust攻撃してる人、暇なんかな。
別の事に時間使えはいいのに、と他人事ながら思うよ。

**デフォルトの名無しさん** · 2022/04/10(日) 16:57:09.68

AssemblyScript や Static TypeScript の話をどこかで聞きかじったのが混ざってるんだと思う

**デフォルトの名無しさん** · 2022/04/10(日) 17:16:31.79

Ruby はJIT で、C コードをコンパイルするけど、
1万ぐらいコンパイルしても、Rails みたいにすべての関数が平均的に呼ばれるアプリでは、
1割ぐらいしか速くならない

行列・ベクトル演算みたいに、CPU セントリックな処理では速くなるから、
Python, Julia では、JITの効果は大きいかも

I/O を使わずに、少ない数値を何回も使って、組合せ演算するようなたぐい

YouTube で有名な、雑食系エンジニア・KENTA が言ってたけど、

Scala が滅んだのは、
食えないから、コミュニティーに居座る無職のベテが、新規を叩きまくるから。
食えない所には、変な香具師しか残らない

Scala, PHP は、KENTAがオワコン認定したから、一気に滅んだ

結局、Laravel, Django, Node.js などは、競争でRails に勝てなかったから。
だから、未経験者のキャリアパスは、Rails → Go だけと宣言した

**デフォルトの名無しさん** · 2022/04/10(日) 17:19:51.97

>>794
ライナスは理論家じゃなくて実務家

ライナスはUNIXクローンが動かないと意味がないからとりあえずソースを書いて動かそう派で
タネンバウムは理論上マイクロカーネルが有利だからマイクロにしろと言って噛みついて来た理論家

**デフォルトの名無しさん** · 2022/04/10(日) 17:37:12.48

Blitz.js は、React 版・Ruby on Rails。
Cake PHP みたいなものか？

Type Script なら、Rubyよりも型安全だけど、
モデルが、RailsのActive Record よりも弱いらしい

**デフォルトの名無しさん** · 2022/04/10(日) 17:53:45.64

>>819
"それなりの成果" ってわざわざ書いた意図をくみ取って欲しかったな

クラファンとかアイディア出すのは良いんだけど
具体的にどういう課題があって改善したがってるのかが分かんないんだよね
Cで書いたモジュールと置き換えるのじゃだめなの？

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

定期的にKENTAさんを引用している人、もしリスナーさんだったらやめたほうが良いですよ？

分析は正しいかもしれないが、イメージを悪くして迷惑をかける可能性だってあるし、
本人が見ていないところに、荒らしにも見える行為はマナー上良くないですからね？

**デフォルトの名無しさん** · 2022/04/10(日) 18:20:31.55

Youtubeで有名な、とかいう主観に満ちた枕詞をつけてるあたり権威付けして威を借りようとでも思ってるんでしょ

たかがYouTuberに言語の勢いを減らせるほどの影響力ないでしょ

**デフォルトの名無しさん** · 2022/04/10(日) 18:27:03.03

YouTuberの名前を出されても中学生が書いてるのかなとしか思わんしマジでそんなやつどうでもいい
偉そうに技術を語るなら、超有名OSSプロダクトをいくつも作ってるとか、GAFAでアーキテクトをやってるとかぐらいの実績がほしい

**825** · 2022/04/10(日) 18:58:00.76

KENTA の有料のRuby on Rails サロンは、日本6位の3千人。
日本1位は、キングコング西野の数万人

vue.js 日本ユーザーグループが、3千人

単独のフレームワークの有料サロンで3千人は、あり得ない！
世界的にも断トツじゃないか？

実際に、外人から驚嘆されている。
転職で未経験者が、こんなすごいポートフォリオを持ってくるのは、あり得ないって

これが日本人が発明した塾・予備校。虎の穴

でも、これほどすごくても、日本人の年収が先進国の1/3 なのも、あり得ないけどw
失われた30年。
財務省のせいで、世界中で唯一、GDP が伸びなかった国

**デフォルトの名無しさん** · 2022/04/10(日) 19:10:26.93

KENTAガイジNGしてないひとまだいたんだ

**デフォルトの名無しさん** · 2022/04/10(日) 19:35:37.31

>>821
GC対応は悲観的
様々な言語で効率化が異なる手法のGCのためにWebAssemblyに共通仕様のGCを作るのは不可能という結論になった
だから当面はWebAssemblyにGCは載らずいずれGC対応しても各GC言語はそのまま動かず特別仕様に制限される

**デフォルトの名無しさん** · 2022/04/10(日) 19:50:06.06

>>834
JVM on WASMみたいなアプローチならどうじゃろ？

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

>ただ、今となってはマイクロカーネルにすべきだし、徐々にでも変更していくべきだと思うよ。
>今でもモノリシックの利点を説いているのは、後付のように思える。
そう思ってるなら思ってる奴がフォークするなりしてやればいいんじゃね？
そのためのフリーソフトなんだから。でも結局やらんだろうがな。