- 1 名前：デフォルトの名無しさん [2022/03/22(火) 03:23:41.60 ID:ZDHdo9X7.net]
- スレタイ以外の言語もok
前スレ
次世代言語23 Go Nim Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1638086359/
- 763 名前：デフォルトの名無しさん mailto:sage [2022/04/09(土) 15:33:43.71 ID:cvyLC6WE.net]
- じゃあ
ファイル名がクラス名やモジュール名と一致してないとダメな言語は糞
- 764 名前：デフォルトの名無しさん mailto:sage [2022/04/09(土) 17:12:33.80 ID:+P+cdtWg.net]
- 自分じゃ話題も振らないのに他のスレでやれとかいう輩って・・・
- 765 名前：デフォルトの名無しさん mailto:sage [2022/04/09(土) 17:40:19.06 ID:qlihBLS+.net]
- >>741
> 便利さを理解するために不便さを体験するべきか否か論
そう捉える奴も多いのだろうが、それだと完全に精神論になってしまうだろ。
コメントで要求されてる「Howは要らない。Whyを書け」と捉える
- 766 名前：べき。(C++はRust仕様のコメント)
つまり、C++でどういう手法が試され、結果としてRustが何を採用してるかを紐解けば、
Rustが何故こうなっているのかが分かる、というわけ。
信者がひたすら「Rustは正しい」と信じることしかできないのは、Whyを知らず、妥当性の判断能力がないから。
ただしHowはRustの場合は文法にしてしまっているので、
Whyを知らなくても、知ってる奴と同等のコードは生成出来てしまう。
だからプロダクト目的のRustドカタには必要がないのも事実。
(これはフレームワークに於いて、何故こんな構造を採用したのか？とか考える必要がなく、
ただ従って正しく使えば生産性が上がるのと同様）
逆にアカデミックとか、Rustの次の言語を考えたい奴がWhyを抑えないのは問題。
信者ではなく、自分で判断してRustを選択したと言いたいのなら、Whyを知らないといけない。
（知ってないと判断出来ないはずなので、論理的に矛盾する。
これはC++の全てを知っておけという意味ではなく、
Rustで採用された「データ競合」「寿命管理」「例外処理」等の対処方法については、
当然だが他のやり方も存在しており、それぞれ一長一短有るから統一されてない。
それらを知らずに、Rustのやり方しか知らず、ひたすらRustマンセーなら、それはただの信者と言える） [] - [ここ壊れてます]
- 767 名前：デフォルトの名無しさん mailto:sage [2022/04/09(土) 18:34:35.92 ID:JZiB2qZH.net]
- 色んな言語やってきたが総合的にみてRustが現在のプログラミング言語の中の最強言語で間違いない
理論的に任意の言語が動き実際にも多数の言語が動かされているWebAssemblyにおいてもRustが利用トップである客観的事実もある
- 768 名前：デフォルトの名無しさん mailto:sage [2022/04/09(土) 18:36:58.31 ID:il24SwZF.net]
- 話題は>>577で振ったけどスルーされました(^p^)
実際どうなんすかこれ、Yewとかその辺の利用者の使用感知りたいんだけど
- 769 名前：デフォルトの名無しさん mailto:sage [2022/04/09(土) 18:48:35.17 ID:SpxMIjuY.net]
- C++理解した程度でプログラミング理解したと思ってるのが痛々しい
- 770 名前：デフォルトの名無しさん mailto:sage [2022/04/09(土) 20:19:57.41 ID:cvyLC6WE.net]
- Rustはボロー周りとEnumだけがよくできていて他はそうでもない
長期で運用しにくいしょうもない弱点だらけ
- 771 名前：デフォルトの名無しさん mailto:sage [2022/04/09(土) 20:26:08.31 ID:n9UcTFQC.net]
- >>757
例えば？
- 772 名前：デフォルトの名無しさん mailto:sage [2022/04/09(土) 20:26:09.05 ID:TpQINAdx.net]
- そうだぞこんなの使ったら駄目だぞ
俺は使うがな
- 773 名前：デフォルトの名無しさん mailto:sage [2022/04/09(土) 20:31:58.00 ID:cvyLC6WE.net]
- レスをたどる能力もないのかRustの機能や制約を知らないのか自分で何かを調べる能力がないのか
どれなんだろう？
- 774 名前：デフォルトの名無しさん mailto:sage [2022/04/09(土) 20:34:48.49 ID:TpQINAdx.net]
- まとめるの面倒だからしないけど弱点だらけだぞ
それでも俺は使うがな
- 775 名前：デフォルトの名無しさん mailto:sage [2022/04/09(土) 20:38:12.58 ID:cvyLC6WE.net]
- 言語面は置いといてrustはまずcargoを何とかしろ
モジュールパッケージの参照の仕組みを改善しろ
- 776 名前：デフォルトの名無しさん mailto:sage [2022/04/09(土) 21:14:44.30 ID:HNoOQ+Ya.net]
- 次世代次世代つって結局Rustしか話題に上がってないやんｗ
- 777 名前：デフォルトの名無しさん mailto:sage [2022/04/09(土) 21:34:11.92 ID:lI/OjvKQ.net]
- >>763
つまり次世代はRust覇権が確定。Rust一択ってこと。
VScodeが覇権したようにプログラミング言語もそろそろRust一択にしようよ
- 778 名前：デフォルトの名無しさん mailto:sage [2022/04/09(土) 23:10:39.42 ID:SpxMIjuY.net]
- GoやクソバカPHPoorが滅びるべきというのには同意
- 779 名前：デフォルトの名無しさん mailto:sage [2022/04/09(土) 23:31:48.47 ID:qlihBLS+.net]
- それがRustが現在も今後とも流行らない理由だろうね
- 780 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 00:20:38.04 ID:xqQhhwbp.net]
- 他の言語でもRustのように広い意味でのデータ競合を実行前にチェックしてくれたらいいのに
そうすればその分の実行時デバッグを無くすことができるのに
- 781 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 00:52:23.84 ID:fmRbxCQk.net]
- >>767
それ、馬鹿の一つ覚えだろうけど、割とマジに、データ競合で困る事なんて無いぞ。
もしみんなが本当にデータ競合に困りまくってたら、あらゆるアプリがRustでキラーアプリ化してるはずだろ。
実際は誰も困ってないし、さらにホームドアを付けたところで元々バグもないから差別化出来ず、キラーアプリ化もしてない。
面倒なのでスルーしたが、256で突っ込まれてるように、
実行時デバッグをそれほど必要としてる時点でプログラマとしてはポンコツ。
初心者なのを自覚して、まずはコードを頭の中で動かせるようになる事を目指すべきだよ。
- 782 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 00:52:41.03 ID:dmNwgspZ.net]
- とかく計算系のライブラリの高速実装がGPGPU関係なくRustよりC++が優先されているのが悲しいが個人でなんとかできる規模でもなく
- 783 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 01:03:58.92 ID:fmRbxCQk.net]
- >>769
やれば分かるが演算系はリソースの確保/開放ははっきり言ってほぼ必要ないので、
C++どころかCでも全く苦労しない。
しかもRustだと使い回すには一々所有権を気にしないといけないだけ面倒。
他言語なら見えれば何度でも問題なく使えるのに。
だからその辺がRustメインになる事はあり得ないと思うけど。実用重視なら尚更。
境界チェックが一々入る分だけ無駄に遅くなるのも致命的ではあるし。
俺は演算部分だけCのdllにして、GC言語からそれを呼び出すのが最強だと思うけど。
つまりNumPyでいい。(なお俺は使った事無いが）
- 784 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 01:07:40.61 ID:clYg/AzK.net]
- >>768
超巨大なコードベースの前で人は簡単にポンコツになるよ
Sanitizerやclang-tidyへのgoogleの投資を見れば分かる
ただこの手のツールが必要になる言語やアプリは限られているから
あらゆる領域でデータ競合抑止が役に立つというのは偽だとは思うが
- 785 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 01:22:47.07 ID:fmRbxCQk.net]
- >>771
それはコードベースが巨大すぎて見落とす確率が高くなるだけだろ。
ただし事実としてこれはあるのは認める。
これについては、Web系見てて思ったんだが、
Java(OOP)： どんな巨大なコードでも、20年前のコードでも、メンテナンスしてみせる！！！
Web系(Restful)： そもそも巨大にならないように分割。
一人で管理出来るサイズ(1,000-10,000程度)なら管理も簡単だし、コードも最悪書き捨てでもいい。
で、俺はWeb系の方が正解じゃないかと思いだしている。
だから、Javaを殺すのはWeb系だろうなとも思っている。
- 786 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 01:24:17.90 ID:7I8wnXlj.net]
- Rustのプログラミング開発効率の良さには感動した
めっちゃ便利やな
- 787 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 01:24:40.32 ID:fmRbxCQk.net]
- あ、すまん、分かると思うが、772訂正。
× 1,000-10,000程度
○ 1,000-10,000行程度
- 788 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 01:35:56.55 ID:o4uZiwRi.net]
- >>772
用語の使い方からも
間違った対比からも
知的レベルの低さが露呈している
そこは単純にモノリスvs.マイクロだけであってOOPやRESTは関係ない
- 789 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 01:51:37.37 ID:lgnAhvFe.net]
- >>772
web系というかブラウザやらOSやらの低レイヤーで考えるべきかと
OSもマイクロカーネルにしたらバグ少なくなるのかね
- 790 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 01:55:17.11 ID:G67EgXPk.net]
- Nimの話題ロクに出てこないね
自分は使ったことないけど、使ったことある人はどう？
他の言語との違いや特色教えてくれると嬉しい
- 791 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 01:55:40.00 ID:fmRbxCQk.net]
- >>775
まあ揚げ足取りはどうぞご自由にだが、話は通じてるようだ。
それで、反論は出来ないのか？
だとすると、やはりRust信者は低脳だとしか思えない。
（議論する気があるのなら、そのレスでは駄目だし）
・巨大化したコードベースではどうしても見落としが発生する
- 792 名前：から、全部所有権を強制化してコンパイラでチェックする
という直接的な解決策をRustは採用しているが、
・そもそも巨大化しないようにひたすら分割し、見落としが発生しにくい規模に抑える
という、上位アーキテクチャでの解決策もあるのだよ。
これは「データ競合」の時も言ったろ。
そこに問題があれば、解決策もそれなりに用意されてる。（格好いいかはまた別だが）
それでは解決出来てない！不十分だ！と言うのなら、
どうにも取りきれなかったバグがRustによって取りきれ、結果的にキラーアプリ化するはずなのだが、
実際これがないだろ。
なら、これまでの地味な方法でも何とかなってたって事なんだよ。 [] - [ここ壊れてます]
- 793 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 02:03:42.86 ID:fmRbxCQk.net]
- >>776
> OSもマイクロカーネルにしたらバグ少なくなるのかね
通説としてはそういう事になっている。（まあ知ってると思うが）
Linusはモノリシックカーネルの利点を言ってるけど、あれは俺は後付だと思うよ。
とはいえ速度重視ならモノリシックの方が上だし、
堅牢性重視ならマイクロカーネルってのは、技術的にも正しいと思う。
俺が言ってるのはもっと単純な話で、
機能が少なければ、実装に必要なコードも少なく済み、見落としも減る、という、至極当たり前の話。
だから「仕様を必要最低限に絞る事こそ最強」という話だね。
これもよく言われているとも思うけど。
だから、マイクロカーネルの方が仕様が小さいから実装コードも減り、結果的に「見落とし」のバグは減ると思うよ。
- 794 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 02:03:43.80 ID:Yq6q8jid.net]
- Nim、vlang、Zig、Zenらへんはマイナーすぎてなんとも
D言語が使われなかったのと似たような理由で使われなさそう
- 795 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 02:04:15.32 ID:UjiUu+PI.net]
- 結論は変えるつもりがなくそこに至るまでの論理だけを手を代え品を代えひねり出し続ける
信者もそれに対する批判も不毛なんだ
- 796 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 02:06:36.51 ID:NYexxOz5.net]
- >>778
アーキテクチャとアプリと言語は全て別問題なのに区別がつかずにごっちゃに話しているキチガイに見えます
- 797 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 02:21:42.17 ID:UjiUu+PI.net]
- そんなことより次々世代言語にどういう特徴を持った言語が来るか予想しようぜ
- 798 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 02:34:28.97 ID:NYexxOz5.net]
- >>780
IT大手各社が珍しく揃って支援＆採用しているRustだけが最近のプログラミング言語の中で長期に残りそう
>>783
Rustを置き換えるような次々世代言語は
Rustが備えるC言語並の速さ省メモリと安全性を押さえた上で異なるアプローチとなるだろうけど
Rust関係の論文が多い状況からすると理論的な裏付けが先行研究としてあるものの中から出てくるのかな
- 799 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 08:39:07.48 ID:K0blu0OJ.net]
- C2とATS2のことも忘れないであげてください！
- 800 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 09:17:53.01 ID:fmRbxCQk.net]
- >>782
それはRust信者はプログラマではないからだな。
プログラマは全レイヤで最適化を模索する事が出来る。（本来は）
例えばだいぶ前にスマホ見てて踏切の内側と外側を間違えて死んで話題になってたが、これについて
・現場(踏切の改善)：踏切内の障害物検知器の精度を上げ、人が間違って立ち止まってる場合も検出し、電車を緊急停止させる(Rust）
もありだが、
・運用（経路選択）：そもそも踏切を通らない経路を選択する。歩道橋があればそれを使う。
・運用（マナー）：歩きスマホ禁止。イヤホンも爆音にはせず、周りの人の声も聞こえる程度にしておけば気づけたかも？
・運用(ポリシー）：外でボーっとしない。事故に巻き込まれる確率は0ではないのだから、
- 801 名前：常にある程度は周りに気を付ける
・アーキテクチャ：高架化して踏み切り自体を無くす(C#)
アーキテクチャ面での対策が根本対策になるが、現実的には運用での回避になってる。
大人の場合はマナー/ポリシーで回避し、
これを期待出来ない小学生には、通学路なら歩道橋を設置して、経路選択での対策が為されてる。
「データ競合」も同様に、
・現場(チェッカ)：所有権を厳密に管理し、コンパイラでチェック(Rust)
もありだが、
・運用：難しい事はしない。競合する可能性のある場所は限定的にして、見ればバグに気づける程度にする
・アーキテクチャ：スレッド構成上、そもそも競合が発生し得ない(C#)
で、アーキテクチャでの対策が根本対策だが話が大がかりになり面倒になるので、
大体は運用で対策され、でも何とかなってるというのが実態だ。
通常は言語選択はアーキテクチャよりさらに上のレイヤか、そもそも独立した軸なので、
言語比較で一番下のレイヤ（現場）での改善のみに限定するのが間違ってる。
そして重要なのは、既存の言語でも根本対策はやる気になればすぐに出来るんだよ。多少面倒なだけで。
だから信者の言う「Rustでなければ無理だった」というアプリが存在せず、キラーアプリも出てこないわけ。
Rustは「一方ロシアは鉛筆を使った」の米国側を突き進もうとしてる。これもありだが、ロシア側もありなだけの話。 [] - [ここ壊れてます]
- 802 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 09:21:12.35 ID:n6k1Ijhp.net]
- この人は無駄で無意味な間違った例え話を延々と繰り返し妄想の世界に住んでいる
- 803 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 09:21:25.28 ID:sR7YmRYu.net]
- Scalaの方がKotlinより機能豊富だけどWeb系では落ち目になったね
Scalaの方が好きだが
- 804 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 09:26:20.41 ID:BLmvSJJ5.net]
- >>788
Scalaは結構好きで長く使っていたけど
使っているとどうしてもJVMが見えてしまう部分があって
Rustに乗り換えちゃったな
- 805 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 09:29:58.47 ID:93k1uAXl.net]
- rustaceanはある時期を境に爆発的に表に出てきてプログラミング界隈を圧倒する未来が見える
- 806 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 09:41:23.13 ID:BLmvSJJ5.net]
- 表に出るかなぁ？
OSやコンパイラ、ミドルウェアあたりに侵食して、気付かないうちに全員が依存してる、みたいな状況なら有り得そう
- 807 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 10:05:57.88 ID:W8i2G4wq.net]
- scalaはコンパイルが困憊るほど遅すぎた
- 808 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 10:55:59.09 ID:vR2aNwQM.net]
- >>779
>Linusはモノリシックカーネルの利点を言ってるけど、あれは俺は後付だと思うよ。
後付けというか経験知からの意見だろ。
Linusはそもそもが理論家なわけでもないし。
仕様を最初から小さく絞れるとか考えてる奴は全く的外れとしか言いようがない。
- 809 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 11:21:10.49 ID:7HDkHX8h.net]
- Linux作り始めたときからタネンバウムと論争しているのに理論家じゃないとか後付けとか
- 810 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 11:26:19.70 ID:nRSUY8iy.net]
- 一部だけ小さくしてバグ減っても意味ないよ。
部分的な最適化はシステム全体の最適化の視点では上手く機能するわけではないからね。
一つ前のFreeBSDで話題になって詳しい人が説明してくれてた。
https://mevius.5ch.net/test/read.cgi/unix/1630061644/794
- 811 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 11:41:39.32 ID:vR2aNwQM.net]
- >>794
だからLinusはタネンバウムみたいな理論家を嫌ってんだろ。議論の中身理解してないのか？
- 812 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 12:14:41.45 ID:N1Kz0CTA.net]
- >>783
C言語より10倍速い言語が現われて界隈歓喜
- 813 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 12:18:37.19 ID:W8i2G4wq.net]
- >>783
Googleに頼めば全て完成する
- 814 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 12:31:07.74 ID:2AahvlRa.net]
- 次世代はシンプルな言語仕様+強力な静的チェックだと思う
Rustみたいに事前の宣言でガチガチに縛るんじゃなく、型推論やフロー解析を積極的に利用して利用のされ方に基づいた型チェックや生存期間のチェックを行う
まあこのままいくとJavaScript+VSCodeがそれになるかもしれないが
- 815 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 12:46:03.55 ID:fBzqkVFD.net]
- >>799
ことweb界隈で使われる言語に関しては前半同意
サービス独自の機能をスピーディーに開発することが求められるweb界隈において、プログラマ自身が考えないといけないことが多くなるrustはまず普及しない
- 816 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 12:55:32.64 ID:fmRbxCQk.net]
- >>793
運用していくうちに追加追加で仕様が段々膨らんでいくのはある程度仕方ないとして、
それでも更新タイミングで不要な仕様を出来るだけ削除して仕様を絞るのは基本中の基本だろ。
マイクロカーネルもある意味これで、「カーネルがやるしかない事しかやらない」という、最小仕様を目指したものだ。
プログラミングに於いて小さい仕様を目指すのは大正義だし、みんなそうしてる。
（出来てるかはまた別。特にJava分野。
対してWebの場合はこの辺切り捨てるしサービス終了もありありなので、
反発はあるかもしれないが、仕様が雪だるま式に膨らんでる事はない。
俺はこの辺、Java流の「どんなに大きくなっても何とかしてみせる」ではなく、
Web流の「定期的に棚卸しで削除」の方が長期的には正しいのではないかと思いつつある、という事)
>>794
Linusは当初から分かっててモノリシックを選択したのはいい。
当時の速度的にそれが妥当だったのも分かる。
ただ、今となってはマイクロカーネルにすべきだし、徐々にでも変更していくべきだと思うよ。
今でもモノリシックの利点を説いているのは、後付のように思える。
- 817 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 13:03:29.70 ID:WQm20ac3.net]
- >>794
「俺は後付だと思う」って予防線貼ってるし、そこまで知らなかったんだよ、きっと
許してあげて
- 818 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 13:10:21.13 ID:BLmvSJJ5.net]
- >>799
Rustのように型が強力でコンパイル時チェックの細かいGC言語ってのが現状ないから
そこは新言語の余地がある気がしている
JSだとどうしても型はガバガバにならざるを得ないからなぁ
- 819 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 13:17:50.89 ID:blp15KeH.net]
- 言語には向き不向きがあるわけで
それを無視してRustがすべての言語を置き換えるみたいな話をしているのがおかしい
C/C++の置き換えは進むかもしれないけどwebやスマホやPCアプリとかでは採用されないでしょ
普通はどの言語が最適かをいろいろ検討して決めます
なんか通販の広告みたいなんだよね
良いことしか言わないし
大手IT企業が採用ってのは通販広告の有名人も愛用！みたいな感じ
コンピュータ関係の新技術の売り文句は100%そうだった試しはないので話半分で聞いていた方がよいと思う
- 820 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 13:30:51.71 ID:fBzqkVFD.net]
- >>804
ほんまこれ
このスレの一部のRust信者がRustこそ至高みたいなノリだけど、このノリについていけないRust推し結構いると思う
- 821 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 13:55:42.06 ID:UjiUu+PI.net]
- いつでも最初から型が要るのは足枷というのは確かに思うわ
そうなると漸進的型付けってやつかねえ
TS以外のaltJSは死んだとかだれかが言っていたが、Haxeの再興もあるか？
- 822 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 14:04:03.83 ID:WXrh5iWM.net]
- >>805
というよりRustは好きだけど別に推してはないという
誰も使わなくていいよ
俺と一部のお前らが使うだけでいい
みんなに使ってもらう必要なんて一切ない
- 823 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 14:14:16.90 ID:li
]
- [ここ壊れてます]
- 824 名前：fo30Qd.net mailto: >>807
そう思ってるなら言わなきゃ良いんじゃないですか？そういう他の言語を使ってる人を小馬鹿にした態度がRust推しそのものでしょ、しかも良い印象は全く受けない [] - [ここ壊れてます]
- 825 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 14:16:40.89 ID:WXrh5iWM.net]
- アンタにレスしてないから気にしないでね
人を小馬鹿になんかしてないし
Rust以外の言語も好きだし
そもそもどの言語も馬鹿にしたりしない
- 826 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 14:23:28.49 ID:sejldIDY.net]
- こういう屈折した性格の勘違い野郎ばっかで本当に近づきたくない。扱いにくいのに能力なんてないし言語触ってれば最先端だと勘違いしてる、とんでもねえバカ
- 827 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 14:40:08.25 ID:9taU8UGO.net]
- RustはMozillaのステマでfirefoxのRust導入は
不可能と叩きが暴れてた頃が懐かしいなあ～
- 828 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 14:57:34.06 ID:fmRbxCQk.net]
- >>810
まあ勘違い馬鹿は必ず存在するのである程度致し方ない。
連中は基本的に「難しい言語使ってる僕すごい」であり、
プログラミング言語の優劣を自己で判断する能力はないので、
何か新しく「凄いけど難しい！！！」とされる言語が出てきたら勝手に移住する。
だから、対策としては、何でもいいから新しい言語を作って適当に吹聴する事だね。
そうすればRust界隈も浄化される。
なお一時期はC++の連中の選民思想が超絶にウザかったが、これが今はRustになってるだけ。
ならC++スレはどうなったかと思って見てみたら、完全にお馬鹿の溜まり場になってたわ…。
まあ○○言語を使ってれば賢いって事にはならないので、当然でもあるのだが。
- 829 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 15:13:47.07 ID:nUqmGYW5.net]
- ちんちんシュッ！シュッ！シュッ！
- 830 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 15:18:10.17 ID:LCNa54V5.net]
- 完結に喋れない病気直ってないの？
- 831 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 15:22:51.62 ID:fmRbxCQk.net]
- >>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の高速化でしょうが、と。
- 832 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 15:22:54.24 ID:WXrh5iWM.net]
- >>811
なんか最初の頃はMozillaの印象強かったよねえ
- 833 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 15:24:50.68 ID:x8
]
- [ここ壊れてます]
- 834 名前：oklrTT.net mailto: >>805
そもそも5ch以外で信者っぽい人見たことないけどな
リアルでもTwitterあたりでもみんな複数言語使ってる中の一つにRustもあるってだけ [] - [ここ壊れてます]
- 835 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 15:33:46.76 ID:lgnAhvFe.net]
- >>815
ruby3はruby2の3倍高速化というお題目でそれなりの成果を出した訳だけどそれでもまだまだ足りないと言うのね
スクリプト言語で高速化するためにはボトルネック箇所をCなりで置き換えるのが普通
JSはブラウザで動かさなければならないという制約上言語自体を高速化する必要があり
ブラウザベンダー大資本がつぎ込まれた結果高速化した
前提がかなり異なるから同じことがruby/pythonに起こることはないのではないか
- 836 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 15:56:47.79 ID:fmRbxCQk.net]
- >>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に起こることはないのではないか
逆に言えば、金さえつぎ込めば改善出来るわけで、
改善項目とそれに要する金額をずらっと羅列して、クラファンで資金が付いたところから実行、
十分な結果で採り入れられたらそいつがその資金を給料として獲得、とかいう方式にすれば、
割とすぐにでも行けるんじゃないかと思うんだけどな。
- 837 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 15:58:01.34 ID:UjiUu+PI.net]
- >>815
> JSにおいて速度の枷は動的型であり、だからこそTSでアノテートだが
違うよ
ブラウザがTSをそのまま食えるようにするというのは開発者側でトランスパイルする必要性を無くすだけで実行速度の改善を目的としたものではないよ
ていうかその方向性はasm.jsとかPNaClみたいな先駆者がいて彼らの現状の到達点がWASMという経緯があるよ
- 838 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 16:21:05.00 ID:fmRbxCQk.net]
- >>820
> 実行速度の改善を目的としたものではないよ
それは知ってるが、JSの速度改善には型の固定（静的型)が必要だから、「『Any無しの』TSを食わせる」必要があるんだよ。
その前段階として「TSを食わせる」が必要なわけ。
（実際やろうとしてるかは知らん)
asm.jsはお世辞にもいいものとは思えない。
あれもJSエンジン内で型を固定出来てるわけではないし。（ただJITだとあれでも行けるのかな？)
PNaClは知らない。けど削除されちゃったよね。
ただwiki見る限りWebAssemblyでいいから削除、みたいな感じのようだが。
「Any無しのTSを食わせる」位ならBlazorでWebAssemblyしろってのはその通りだが。
だからWASIも方向性としては有ってて、最高に上手く行け�
- 839 名前：ﾎJVMを置き換える事になるかもしれんけど。
(Java言語そのものは死なず、JavaからWebAssemblyを吐くようになるだけだが） [] - [ここ壊れてます]
- 840 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 16:49:31.19 ID:UjiUu+PI.net]
- 知らなかったくせに
- 841 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 16:53:31.25 ID:QEMS6G9N.net]
- 毎日Rust攻撃してる人、暇なんかな。
別の事に時間使えはいいのに、と他人事ながら思うよ。
- 842 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 16:57:09.68 ID:7HDkHX8h.net]
- AssemblyScript や Static TypeScript の話をどこかで聞きかじったのが混ざってるんだと思う
- 843 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 17:16:31.79 ID:ZtzjE5Lq.net]
- 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 だけと宣言した
- 844 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 17:19:51.97 ID:kr0xp78k.net]
- >>794
ライナスは理論家じゃなくて実務家
ライナスはUNIXクローンが動かないと意味がないからとりあえずソースを書いて動かそう派で
タネンバウムは理論上マイクロカーネルが有利だからマイクロにしろと言って噛みついて来た理論家
- 845 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 17:37:12.48 ID:ZtzjE5Lq.net]
- Blitz.js は、React 版・Ruby on Rails。
Cake PHP みたいなものか？
Type Script なら、Rubyよりも型安全だけど、
モデルが、RailsのActive Record よりも弱いらしい
- 846 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 17:53:45.64 ID:lgnAhvFe.net]
- >>819
"それなりの成果" ってわざわざ書いた意図をくみ取って欲しかったな
クラファンとかアイディア出すのは良いんだけど
具体的にどういう課題があって改善したがってるのかが分かんないんだよね
Cで書いたモジュールと置き換えるのじゃだめなの？
- 847 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 18:07:58.32 ID:b41tYEVR.net]
- 定期的にKENTAさんを引用している人、もしリスナーさんだったらやめたほうが良いですよ？
分析は正しいかもしれないが、イメージを悪くして迷惑をかける可能性だってあるし、
本人が見ていないところに、荒らしにも見える行為はマナー上良くないですからね？
- 848 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 18:20:31.55 ID:aoUYGCMa.net]
- Youtubeで有名な、とかいう主観に満ちた枕詞をつけてるあたり権威付けして威を借りようとでも思ってるんでしょ
たかがYouTuberに言語の勢いを減らせるほどの影響力ないでしょ
- 849 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 18:27:03.03 ID:Yq6q8jid.net]
- YouTuberの名前を出されても中学生が書いてるのかなとしか思わんしマジでそんなやつどうでもいい
偉そうに技術を語るなら、超有名OSSプロダクトをいくつも作ってるとか、GAFAでアーキテクトをやってるとかぐらいの実績がほしい
- 850 名前：825 mailto:sage [2022/04/10(日) 18:58:00.76 ID:ZtzjE5Lq.net]
- KENTA の有料のRuby on Rails サロンは、
- 851 名前：日本6位の3千人。
日本1位は、キングコング西野の数万人
vue.js 日本ユーザーグループが、3千人
単独のフレームワークの有料サロンで3千人は、あり得ない！
世界的にも断トツじゃないか？
実際に、外人から驚嘆されている。
転職で未経験者が、こんなすごいポートフォリオを持ってくるのは、あり得ないって
これが日本人が発明した塾・予備校。虎の穴
でも、これほどすごくても、日本人の年収が先進国の1/3 なのも、あり得ないけどw
失われた30年。
財務省のせいで、世界中で唯一、GDP が伸びなかった国 [] - [ここ壊れてます]
- 852 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 19:10:26.93 ID:TRRwI9qz.net]
- KENTAガイジNGしてないひとまだいたんだ
- 853 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 19:35:37.31 ID:N5dTO4j8.net]
- >>821
GC対応は悲観的
様々な言語で効率化が異なる手法のGCのためにWebAssemblyに共通仕様のGCを作るのは不可能という結論になった
だから当面はWebAssemblyにGCは載らずいずれGC対応しても各GC言語はそのまま動かず特別仕様に制限される
- 854 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 19:50:06.06 ID:lgnAhvFe.net]
- >>834
JVM on WASMみたいなアプローチならどうじゃろ？
- 855 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 20:10:14.95 ID:vR2aNwQM.net]
- >ただ、今となってはマイクロカーネルにすべきだし、徐々にでも変更していくべきだと思うよ。
>今でもモノリシックの利点を説いているのは、後付のように思える。
そう思ってるなら思ってる奴がフォークするなりしてやればいいんじゃね？
そのためのフリーソフトなんだから。でも結局やらんだろうがな。
- 856 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 20:30:35.41 ID:aoUYGCMa.net]
- オンラインサロンの会員数を出したり、外人から驚嘆されてるとかいう眉唾情報を出したり、教祖が教祖なら信者も信者だな
- 857 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 20:49:57.25 ID:fmRbxCQk.net]
- >>828
> 具体的にどういう課題があって改善したがってるのかが分かんないんだよね
> Cで書いたモジュールと置き換えるのじゃだめなの？
この主語がRubyではなく、Rubyランタイムだと仮定すると、以下。
Rubyについて文句言われてるのは速度だけだろ。
エコシステムはPythonには劣るが、基本的には「それ、Rubyでも出来るよ」程度にはなってるんだろ。
なら後は人数だけで、新規を呼び込むにはPythonよりも圧倒的に速い速度だよ。
手法は速くなるのなら何でもいい。
改善箇所は、まずはプロファイラ付きのランタイムを配ってデータを集めて、
使用頻度の高さ＊コード見ての改善見積もり＝高速化効果見積もりと、その費用の一覧を作って、
ついでにそのプロファイラー付きランタイムでの使用実績も掛けて各社向けに
「御社のRubyプログラムは○○円で△%高速化」の一覧に差し替えて、クレクレ君するしかないね。
長期的に見れば自前でゴリゴリチューニングするよりランタイムが速くなってくれた方が楽だから、
10社くらい束ねればわりと行けるのではないかと。
あくまで、各社が「ここを速くしてくれ」として費用を出してきた場所を改善だ。
ユーザー無視して高速化しても外れるだろうし。
- 858 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 20:50:32.86 ID:fmRbxCQk.net]
- >>828
> 具体的にどういう課題があって改善したがってるのかが分かんないんだよね
> Cで書いたモジュールと置き換えるのじゃだめなの？
主語がRubyだと仮定して、
Rubyのどこが不味いのか、速度が欲しければCでdllを用意しろ、という意味なら、死ねと言われるだろうよ。
Rubyは根本の戦略が間違ってる。
Pythonとダダ被りなので、このままだと、シェア的に見て死ぬのはRubyだと確定してる。
なら、Pythonと正面からやり合うのではなく、違う道を模索しないといけない。
具体的には互換性無視での先行だね。そして「学生が学ぶならRuby」という地位を確立してしまう事だ。
2012位にRubyカンファレンスでMatzが「互換性を重視しました！」
と言って沸いたという記事があったはずだが、あれが完全なる間違い。
互換性重視と言うと聞こえはいいが、これは「新規のコードよりも既存のコードを優遇する」という事であり、
- 859 名前：これからコードを書く/学ぶ連中にとっては全く意味無い。それよりは、最新の書き方を試せる方がいい。
どの言語も段々と互換性を重視するしかなくなるので、仕様改訂出来ず、段々と古くさくなっていく。
Pythonなんて既にそうなってるだろ。
なら、「常に最新の書き方が出来ます！」をキープして、新規学習者の登竜門的な地位を確立するしかない。
これには、
・バージョン管理で仕様を年に一度は大幅改訂。新しい記法を貪欲に採り入れ、古い記法はばっさり捨てる。
・古いバーションの記述でも動きはするように、関数単位でのパースバージョン指定が出来るようにする。
・学生にとって入社～3年目程度に必要な概念は全て学習出来るよう、
他言語でのプロポーザルの有力案は全て採り入れる。（高速である必要はなく、動けばいい）
とかで、とにかく「プログラミングの学習にはRuby!」という地位を確立しないと、
Pythonに食われて死ぬ未来しかないだろ。
で、RoRは仕様を改訂/捨てまくりだと聞いてるけど、
あれが正しいよ。というか、何かしらPython(や他言語)と差別化しないと死ぬだけ。 [] - [ここ壊れてます]
- 860 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 20:57:15.28 ID:aoUYGCMa.net]
- 学生にRuby…？
専門学校ならそれでいいかもしれんけど
- 861 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 20:58:47.74 ID:fmRbxCQk.net]
- >>834
> 様々な言語で効率化が異なる手法のGCのためにWebAssemblyに共通仕様のGCを作るのは不可能という結論になった
そりゃそうかもしれんが、これはWebAssemblyの連中が真面目すぎるだけ。
Python/Ruby/JS/TSを使ってる連中が、GC方式なんて気にしてるわけねえだろ。
GC出来てれば何でもいいんだよ。（循環参照でもGC出来るのは必須で）
やりたくないから理由を適当にでっち上げたようにしか見えないね。
（オープンソースならそんなもんだが）
- 862 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 21:10:10.44 ID:fmRbxCQk.net]
- >>836
wikiによるとArchとDebianでやってみた奴はいるらしい。
> 2012年現在、Machベースの GNU Hurd も機能しており、それを採用した Arch Linux と Debian のテスト版も進行中である。
> https://ja.wikipedia.org/wiki/%E3%83%9E%E3%82%A4%E3%82%AF%E3%83%AD%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB
ただまあ、マイクロカーネルにしても、
ドライバ周りのコードを（カーネル開発人員が）自前で書かないといけないので、
最終的に書かなければならない合計コードサイズ自体は大して変わらず、
カーネルで落ちるかユーザーモードでバグるかの違いで、大して意味はないのかも？
ならわざわざやろうと思わないのも道理だ。
- 863 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 21:15:37.68 ID:QEMS6G9N.net]
- GNU Hurd ダメなやつだから。
|
 |
