22/04/08 14:05:58.17 xmDi13Bx.net
Rustのプログラミングの快適さは
様々なプログラミングパラダイムを巧みに洗練して採り入れているところにあると思う
一つ一つは既存の言語にあるものが多いけど総合的に組み合わされたのはRust特有でそれが�
657:Rーディングのしやすさに繋がっている
658:デフォルトの名無しさん
22/04/08 14:45:33.12 wv8X5M3X.net
昼間から長文とかおじちゃんたち仕事は？？
659:デフォルトの名無しさん
22/04/08 14:49:38.98 J+DLQw6K.net
「Javaスクールの危険」みたいな話になってきてるな
URLﾘﾝｸ(web.archive.org)URLﾘﾝｸ(local.joelonsoftware.com)
660:デフォルトの名無しさん
22/04/08 14:54:51.52 zi4mesOO.net
一方でRustは色んなことが身につくからその問題点もないよな
661:デフォルトの名無しさん
22/04/08 14:56:47.94 CQiu8f2R.net
>>650
再起とポインタなんて知らなくてもWebプログラマーはつとまるんだよ
ましてや精神的態度なんて根性論いいだしたら人材不足の今、人なんて集められないよ
662:デフォルトの名無しさん
22/04/08 14:58:59.00 CQiu8f2R.net
>>650は下の（２）の人のことをいってるんであってこのスレにいる大多数の（１）の人たちには関係がないこと。
ーーーーーーー
プログラマーには２種類の人がいる。
自動車産業に例えたら、（１）地方の工場勤務の期間工と（２）研究開発センターのエンジニア
（１）はRustは使用しなくていい。というか理解できなくて使えない。Pythonとかで頭を使わないコード書くだけだから。例えるなら、ラインで組み立て作業を１日延々しているだけのルーチンワーク要員。
（２）はRustなどを使用してシステムプロラミングWebassemblyなどでローレイヤーや基盤を作っていく。例えるなら自動車のエンジンやデザインの設計者。
663:デフォルトの名無しさん
22/04/08 15:07:49.60 Js+ybEIJ.net
自分はCS出てフルスタックやってるから他の立場のことはわからないが
色々やってきた言語の中でRustが最も開発効率良いと断言できる
664:デフォルトの名無しさん
22/04/08 15:13:55.24 FJuOSvU4.net
rustとgoが合体したらいいのになあ
665:デフォルトの名無しさん
22/04/08 15:30:55.82 fiUiUlD4.net
なんか一部のrust推しがすごいっすね
666:デフォルトの名無しさん
22/04/08 16:23:35.95 UBiXicJa.net
>>655
V言語
667:デフォルトの名無しさん
22/04/08 16:57:15.66 PcnkB3on.net
>>656
rust推しだけど変な人が無理筋の推し方してて困ってる
668:デフォルトの名無しさん
22/04/08 17:09:14.19 a6HBTm5x.net
頭の悪い子に限って延々演説するよなｗ
お前らそれを完全スルーしてて賢いわｗ
669:デフォルトの名無しさん
22/04/08 17:14:34.86 BG4ZrdKI.net
>>657
Vは確かに最初の宣伝はそんな感じだっけど、現状はRustとGoを足して10で割ったくらいの状態だからなぁ
670:デフォルトの名無しさん
22/04/08 17:54:29.26 0JDStoXf.net
V言語はマクロがないとかクロージャがないとか
あと安定しないままだよね
671:デフォルトの名無しさん
22/04/08 18:14:16.72 CQiu8f2R.net
>>659
スルーというかNGWordに正規表現で
.{50}
としてるからまったく気づかない
672:デフォルトの名無しさん
22/04/08 18:59:02.09 wv8X5M3X.net
>>652
そうして集めたPHPerたちが作ったWebシステムはどうなりましたか
673:デフォルトの名無しさん
22/04/08 19:35:51.32 gFm4wviN.net
>>663
facebookって言って超メジャーなサービスになってるよ。
674:デフォルトの名無しさん
22/04/08 19:40:32.31 wv8X5M3X.net
>>664
facebookのPHPエンジニアが優秀＝PHPエンジニアが優秀
という短絡思考には感服致します
障害者学級PHPoorたちの心のより所なんですね
675:デフォルトの名無しさん
22/04/08 19:54:22.21 haRe9nr5.net
このスレだけ見てるとPHPerよりRusterのほうが危険で頭がおかしいと思ってしまう…
実際はそんな�
676:ｱとはないかもしれないが
677:デフォルトの名無しさん
22/04/08 19:58:36.19 gFm4wviN.net
>>664
え、どうなったか聞かれたから答えたらなぜかPHPともどもボロクソ言われるの、
意味がわからんのだが。
678:デフォルトの名無しさん
22/04/08 20:05:37.41 g/vqQJB9.net
>>654
「unsafeに触らない限りは」だろ。
実際にはフレームワークとかライブラリとかが充実している言語のほうが開発効率は高い。
(すでに開発済みだからという理由だけど)
679:デフォルトの名無しさん
22/04/08 20:09:42.84 nC7N6zb/.net
Rustは欲しいcrateほど放置されてるcrateやwipの空crateが一定数あるのが実用を考えた時に厳しい
RustのWinUI3対応早く来ないかなー
後別に何でもかんでも関数型になって欲しい訳でもないんだけど、スクリプト的な簡単に書きたいモチベーションのある言語に、関数のデフォルトのカリー化と、引数を渡すのと同じ記法での部分適用が導入されて欲しい
個人的に見た目がスッキリするし書くのが楽に感じるので
Fsharp使えというのはそうかもしれない
680:デフォルトの名無しさん
22/04/08 20:31:38.25 wv8X5M3X.net
>>667
元レス読めよ文盲
これだからPHPoorは
さっさと氏ねゴミカス
681:デフォルトの名無しさん
22/04/08 20:39:12.10 IqLRftxA.net
>>668
それはプログラミング言語の問題ではないな
純粋にプログラミング言語の比較でRustより上のものを挙げないと
682:デフォルトの名無しさん
22/04/08 20:39:56.09 haRe9nr5.net
webの世界を支えてるのはPHP
683:デフォルトの名無しさん
22/04/08 20:42:20.02 haRe9nr5.net
>>671
使いやすさから言えばjavaやc#のほうが上だと思う
Rustは使いどころがまだ確立されていない
684:デフォルトの名無しさん
22/04/08 20:48:04.21 4vP7lCV8.net
>>671
なら「標準ライブラリが充実している」でいいよ。
標準ライブラリが言語に含まれないとは言わんよな？
685:デフォルトの名無しさん
22/04/08 20:50:18.47 MnFLToWU.net
>>669
ところでカリー化はラムダではあかんの？
686:デフォルトの名無しさん
22/04/08 20:53:57.99 nx5fqsfT.net
>>673
そこはさすがに誰が見ても
Rust＞Javaはあらゆる面から全員一致として
Rust＞C#もほとんどの人が同意でしょ
687:デフォルトの名無しさん
22/04/08 21:15:04.96 hRiSi6np.net
>>676
それは過大評価し過ぎでは…
688:デフォルトの名無しさん
22/04/08 21:31:56.88 Br+emjPa.net
言語自体の比較だと現状ではRustが一番かもしれん
新言語が現れなければじわじわと利用環境や利用者を拡大していくのだろう
689:デフォルトの名無しさん
22/04/08 21:33:57.02 a6HBTm5x.net
>>669
> 後別に何でもかんでも関数型になって欲しい訳でもないんだけど
リストのリテラルが無いあたりで割り切りを感じるよな
あくまで軸足は関数型言語にはないという
リストの結合とかカリー化や関数結合もデフォで組み込まれてたら
もっと違う感じだったやろねえ
690:デフォルトの名無しさん
22/04/08 22:02:06.45 GQWBx4Yt.net
ガベージ出まくるからゼロコスト抽象にならない問題点などあるよな
見かけはマクロでわかりやすくする程度が現実解
まあ普通のGC言語でもサポートしてないのが多い中
そこまで必要とされていない機能なのかもしれん
691:デフォルトの名無しさん
22/04/08 22:13:42.74 haRe9nr5.net
なんでIDコロコロ支店の？
692:デフォルトの名無しさん
22/04/08 22:23:42.64 wv8X5M3X.net
いきなりコロしとか言い出すとかマジやべえな
693:デフォルトの名無しさん
22/04/08 23:37:25.21 nC7N6zb/.net
>>675
処理として等価なものが書けるという意味では問題ないよ
それよりもっと簡単に書けるようになるので、あると嬉しいなって
694:デフォルトの名無しさん
22/04/08 23:52:45.49 fiUiUlD4.net
rust推しに狂気を感じるスレ
695:デフォルトの名無しさん
22/04/09 00:07:03.26 il24SwZF.net
それしか言えんのか
696:デフォルトの名無しさん
22/04/09 00:20:56.02 qlihBLS+.net
>>650
似てはいる。
「JavaではCS学生には過�
697:ﾛ護すぎ」が趣旨だと思うが、 同様にRustを考えるなら ・修得概念は多いがこれは暗記の類であり、チャレンジではない ・コンパイラ頼みで考える事を放棄してるから、成長しない で、アカデミックには不適だ。 大学なんて就職予備校だと割り切るならありだが。 Goなら、 ・修得概念は少なく抑えられている ・構成自体は何でも出来る（はず、多分） ・やたらコピペさせられる点が糞 であって、教育/アカデミックには向いてる。(少なくともRustよりはいい) 「データ競合」「デッドロック」等のバグをコンパイラに頼って回避してる限り、 コンパイラがサポートしてくれない状況では確実にやらかす。 コンパイラのサポート無しでも回避出来る腕だが、さらにコンパイラでダブルチェックする、が正しい。 フレームワークなんて暗記の類で、ちゃんとプログラミングが出来る奴なら、使えば使えるようになってる。 フレームワークは生産性を上げる為の手段であり、 プロダクトを目指さなくてもいい学生の時点で型に嵌めてしまうのは成長を阻害する気がする。Rustがこれ。 （他言語でもフレームワークを使って課題製作して出来たつもりになってるのなら同様ではあるが、 既に書いたようにRustの場合は言語自体がフレームワーク化してるので、これを回避出来ないのが難点）
698:デフォルトの名無しさん
22/04/09 01:45:47.90 H+Mv/KjD.net
コンパイラのチェックが厳しい→コンパイラに頼る→学習にならない
もう言語の利点を語るんじゃなくて、学習に向いてるかどうかってことに話を絞ることでRust批判につなげることにしたのね
699:デフォルトの名無しさん
22/04/09 01:58:00.79 il24SwZF.net
暗記ごときでボローチェッカーに対処できるなら自他ともに認めるRustの学習曲線の問題は発生しないんだよなあ
700:デフォルトの名無しさん
22/04/09 02:01:36.12 il24SwZF.net
あとデッドロックは別にRustで静的に防止できる類のバグではないぞ
メモリリークと同様だね
701:デフォルトの名無しさん
22/04/09 02:15:58.74 eXc0QQCs.net
言語として魅力を感じるのはGoよりRustだが、将来的にGoよりシェアを拡げるかと言われたら疑問
702:デフォルトの名無しさん
22/04/09 02:26:41.71 730EZC4A.net
Rustはシステムプログラミングの分野でだけちゃんと生き残れば大成功だよ
あとは特にハイパフォーマンスや低コストが要求されるとこくらいか
ほとんどのアプリケーションでは、JavaやらPythonやらなりの高水準言語にて、より適す言語が見つかるやろ
703:デフォルトの名無しさん
22/04/09 03:28:08.67 iJevktt3.net
>>691
Javaの諸々の弱点を克服したものがRustであるため
従来Javaで書かれていた分野にRustが食い込んで行きつつあります
704:デフォルトの名無しさん
22/04/09 03:34:37.18 ntDYOunj.net
ツルツル無毛の奇麗な一本筋なんだろうね
705:デフォルトの名無しさん
22/04/09 04:14:38.03 0HVqg1ER.net
FacebookがバックエンドをJavaからRustにした記事でJavaの問題点が多数挙げられていたな
706:デフォルトの名無しさん
22/04/09 05:55:15.91 GQoYu9QH.net
他部分の結論がまだ早いが、環境的な点から考えて、
GoはJavaとPythonと比べて、教育言語として価値が高いことは今のところない
・良くも悪くもOOPではない。抽象化のレクチャの定番が崩れている
・コンベンション重視のせいで、文化風土が専制的
（たとえばインデントは実質タブしか。手法にフレームワークを当てはめがち。考える余地を与えない）
・C言語の代わりにはならず、高級言語として教えるにもポインタの概念が余計
・例外処理/リソース管理/並行処理あたりの重要ポイントの対応方法が独創的で潰しが効かない
以上、拡大解釈せずにあくまで業界最適化言語と
707:考えるのが無難という意見だ
708:デフォルトの名無しさん
22/04/09 06:21:18.57 Qew3WBrk.net
>>695
そのGo批判は間違っている
OOPはclassが無いだけだろ
例外処理もtry-catchが無いだけだろ
GoもRustもどちらもclassやtry-catchは無いが異なる方法を取っているだけにすぎない
言語毎に様々な形態がある部分を取り上げて批判するあなたの視野が狭く偏見を持っているだけにみえる
709:デフォルトの名無しさん
22/04/09 07:21:22.99 qlihBLS+.net
>>695-696
それは教育目的を明確にしておかないと空回りする。単純には以下となる。
・実務： 大学は就職予備校である
・養成： 大学は人材養成所である
・アカデミック： その分野の発展を目指す
695は実務寄りの意見だ。
ただ、実務なら議論するまでもなく現在のシェア、または求人のシェア通りにやるべきであって、
それ以外を選ぶのは教授の趣味でありエゴでしかない。
今ならPython/Java/JavaScript/C#/C++/C/PHP/Rubyの順かと。
650記事と696（と686内俺のGoへの意見）は養成寄りで、人材の底上げを目指したものだ。
> ポインタを使うプログラミングは今日書かれるコードの90%には必要とならず、製品コードにおいてははなはだ危険なものであるということは素直に認める。
> その通りだ。そして関数プログラミングは実務ではほとんど使われていない。それも認める。
> しかしそれでも、最もエキサイティングなプログラミング仕事ではこれらは重要なものなのだ。
> たとえばポインタなしにLinuxカーネルで作業することはできない。
> Linuxのコードを1行も理解することはできず、実際ポインタの理解なしにはどんなオペレーティングシステムのコードも理解できない。
つまりはプログラミングドリルに何を用いるかで、プロダクトを目指したものではない。
だから界隈の文化なんて全部無視でよく、単に、学生の頭の体操/訓練に何が適しているかだ。
この場合、スタート時から色々概念が必要なRustは最悪で、仕様は軽ければ軽い程良く、
早い段階で「仕様とか概念に苦労せず」学生が自在に「こねくり回せる」必要がある。
こねくり回す時の苦労が養成になるので、そこは頑張って苦労しろ、というわけだ。
この用途なら、Goも悪い選択ではない。
が、まあ、素直にCを選択する方が妥当ではあるが。
710:デフォルトの名無しさん
22/04/09 08:15:54.24 yjPUnyR6.net
最初はC → Rustが王道だろうな
さすがにCのままだけでは効率悪すぎる
711:デフォルトの名無しさん
22/04/09 08:16:17.09 cvyLC6WE.net
GoもRustもclassはない
でも実質似たようなことはできる
でも実質は実質であり素直にOOPできるかと言えばそうでもなく変な制約がある
ファイル分割とかしたいとか思わないならその限りではない
712:デフォルトの名無しさん
22/04/09 08:17:47.26 ehpYMGIZ.net
goはある意味goroutineとchannelを使うための言語だしな。そこに価値を見出す人が使えばいいこと。
ただまぁ、独創的だから潰しがきかないとか批判しだしたらpythonも癖が強すぎてたいがいだがな。
結局普及したもの勝ち。
713:デフォルトの名無しさん
22/04/09 08:24:05.70 cvyLC6WE.net
>>698
目的に応じて言語を選んだほうがいい
C→Rustは狭すぎるし心に余裕がなくなるし楽しくない
標準的なGUIもないから入門には不向き
個人的には間にGC言語やPython挟んだほうがいいと思うよ
714:デフォルトの名無しさん
22/04/09 08:54:42.92 0xXBKlCN.net
>>701
PythonよりはRustの方がええやろ
Pythonは偏り過ぎ
715:デフォルトの名無しさん
22/04/09 08:56:00.27 LAfniSDw.net
バランスいい言語ないの(´・ω・｀)
716:デフォルトの名無しさん
22/04/09 09:09:13.58 ehpYMGIZ.net
個人的にはswiftがそこそこモダンな機能を一通り備えていながら癖の強くない文法でバランスがいい言語だと思うけど、
Apple依存というところが最大のネック。
717:デフォルトの名無しさん
22/04/09 09:09:29.66 H+Mv/KjD.net
ないです
RustのGUIクレートってどれがいいんだろ
718:デフォルトの名無しさん
22/04/09 09:33:25.59 cvyLC6WE.net
コンパイラチェックが厳しいで思い出した
全然関係ないけど自分は麻雀が打てない
ゲームではできる
自分では上がりだと思ってても実際は上がれなかったりする
結局ゲームで判定してもらってる
どこが悪いのかは自分で分かっていない
コンパイラのチェックでは原因が出るのでどこが間違ってるのかはわかる
719:デフォルトの名無しさん
22/04/09 09:43:27.34 7NJqkFJL.net
Rustのコンパイラはどの部分とどの部分がどういう問題となっていて今回のエラーとなっているのかを
複雑なケースでも丁寧に教えてくれて学習効果も高いですね
720:デフォルトの名無しさん
22/04/09 10:38:03.26 ALVqghU/.net
結局 c -> c++ -> rust って感じに進まないと理解できないと思うがな。
いきなり c -> rust で何をやってるか理解できるとはとても思えん。
この種のことをrust信者はすぐ誤魔化す。
721:デフォルトの名無しさん
22/04/09 10:45:26.66 n9UcTFQC.net
>>708
どのあたりが理解できないと思う？
722:デフォルトの名無しさん
22/04/09 10:47:43.60 3YobdmGS.net
>>708
そこは完全に逆
C++は学ぶ必要なし
今となっては何の価値もない言語
C++を学んでも回り道をしている無駄なunique_ptrくらいしかRustのために役に立つ知識がない
723:デフォルトの名無しさん
22/04/09 10:53:42.52 EFTB/rfv.net
>>708
自分はそのルートだったけどC++を経由する必要はどうかなぁ
現代のC++をマスターするのはRust以上に難しいし、初心者が自分でどこまで学べばいいかを判断するのも難しそう
まぁ結局我々は初心者ではないので推測で言ってもあまり意味はないけど
724:デフォルトの名無しさん
22/04/09 11:02:06.42 SpxMIjuY.net
要するにマロックだろ？
725:デフォルトの名無しさん
22/04/09 11:11:18.68 UvtYS0nS.net
単刀直入に言うと
実はC++とRustには共通点が非常に少ない
特にC言語との共通点を除くとほとんど残らない
だから学ぶべきはC→Rustが正解
726:デフォルトの名無しさん
22/04/09 11:38:59.26 P+77Yson.net
>713
>実はC++とRustには共通点が非常に少ない
そういう嘘をつくからRust信者はクソ言われるんだよ。
Rustの根幹をなすメモリ安全性はC++のRAII/unique_ptrから着想を得た所有権／ムーブセマンティクスの運用を徹底することによって実現しているし、
Rc/ArcもC++のshared_ptrの機能を強化しているだけ。
引数渡しをムーブセマンティクスデフォルトにするという致命的ミスをしているからC++と別物のように見えるけど、
C++ユーザーからすればC++を少し洗練させたぐらいにしか見えない。
その実体を知りながら「共通点が非常に少ない 」とか言うのは詐欺師ぐらいなものだ。
727:デフォルトの名無しさん
22/04/09 11:49:01.58 0K2sKttC.net
C++に着想を得ているのはそうだと思うけど、歴史通りの順番で学ぶ必要ある？
（その理屈だと最初はパンチカードからかな…）
C++の後付したわかりにくいmoveを学ぶより、最初から洗練された方を学んだほうがいいと思うけど
728:デフォルトの名無しさん
22/04/09 11:53:43.59 EFTB/rfv.net
C++の歴史を追っていくみたいなのは、言語設計的にはすごく学びがあって、好きな人にはおすすめなんだけど
ただプログラミングがしたい人におすすめできるかというと…
729:デフォルトの名無しさん
22/04/09 11:55:25.64 cvyLC6WE.net
現実的にはPythton or Java or C# → C → Rustかな
730:デフォルトの名無しさん
22/04/09 12:00:59.18 LZU2nudI.net
最近のC++はなんとRustの後追いをしている状況
例えばRustの中核となっている enum OptionとResult そして Iterator
Optionは C++では std::optionalで これはC++17でようやく導入された
Resultは C++では std::expectedで これは現在導入に向けて審議中
Iteratorは C++では std::rangesで これはC++20でようやく導入された
このようにRustでの成功を見てC++が後から導入となっている
最近導入されたばかりなのでC++入門書や解説サイトにはもちろん出てこない
【結論】C++は学ぶ必要なし
731:デフォルトの名無しさん
22/04/09 12:05:05.94 cvyLC6WE.net
C++は無駄に増改築を繰り返された老舗旅館
通路の途中で無駄に段があったり渡り廊下があったり
HPに書いてある現代風の部屋に泊まれる場合もあるけど古い部屋に泊まることもある
732:デフォルトの名無しさん
22/04/09 12:09:41.54 EFTB/rfv.net
C++98ならそんな増築感はなかったけど、そこまで戻るとRustとの共通点もほとんどなくなっちゃうしなぁ
733:デフォルトの名無しさん
22/04/09 12:15:44.17 ehpYMGIZ.net
RAIIとテンプレートメタプログラミングが発見されてから独特の進化を始めたな。
734:デフォルトの名無しさん
22/04/09 12:16:15.06 cvyLC6WE.net
>>718
>>720
新しい部分を指してC++を学ぶべきと言ってるのではないと思うよ
それまでのC++からC++11 以降の新しい流れをみるんだろ
C++で何が都合が悪かったか判る
735:デフォルトの名無しさん
22/04/09 12:19:37.41 EFTB/rfv.net
>>722
それって歴史を知っている我々には分かるけど初心者に分かる？
736:デフォルトの名無しさん
22/04/09 12:24:26.93 cvyLC6WE.net
>>723
自分はC++を学ぶべきとは思ってないけど何が都合が悪いのか体験したらいいということだろうと推測
初心者にわかるかどうかは知らない
初心者にはjava C# Pythonを勧める
737:デフォルトの名無しさん
22/04/09 12:26:21.53 2dOqhr+x.net
C++の増改築を学ぶのはムダな枝も多くて学ばないほうがいい
RustはC++含めた様々な言語から色々採り入れているけど
洗練して整合性あるようコンパクトに採り入れてるからシンプル
738:デフォルトの名無しさん
22/04/09 12:36:22.62 HmFS1ypI.net
>>694
URLキボン
739:デフォルトの名無しさん
22/04/09 12:42:40.46 cvyLC6WE.net
フレンド関数とか学んでも使いどころなどない
740:デフォルトの名無しさん
22/04/09 12:44:13.05 qlihBLS+.net
>>706
> どこが悪いのかは自分で分かっていない
Rustで作ったゲームなら、フリテンですor役がありません、と親切に教えてくれるよ
と信者の代わりに突っ込んでみる
741:デフォルトの名無しさん
22/04/09 12:51:14.42 byaB+Tw8.net
Rustのコンパイラは賢い先生みたいなもので不十分なところを的確に適切に指導してくれる
昔Rustは学習難易度高いと言われていたためコンパイルエラーに最も力を入れたプログラミング言語へと成長した
742:デフォルトの名無しさん
22/04/09 12:52:42.79 lI/OjvKQ.net
レス番がとびとびなんだがそんなに長文書き込んでるやついるの？w
743:デフォルトの名無しさん
22/04/09 13:05:08.55 P+77Yson.net
>715
何をトンチンカンな指摘をしているんだよ。
>713 >実はC++とRustには共通点が非常に少ない
に対する反論なのに、
>715 歴史通りの順番で学ぶ必要ある？
とか共通点の話と何の関係も無いだろ。
Rust信者はこういう詭弁を弄するクソしかいないのかね。
あと、言語の話をしているのに
> （その理屈だと最初はパンチカードからかな…）
とか言語じゃないものを引っ張り出すようなアホな反論するなよ。
744:デフォルトの名無しさん
22/04/09 13:10:56.96 Wb48yUxI.net
>>718
C++から見てRustのそのシンプルで分かりやすい記述と概念は羨ましい
だからRustから輸入する形で取り入れることになった
745:デフォルトの名無しさん
22/04/09 13:23:59.57 P+77Yson.net
>718
>最近のC++はなんとRustの後追いをしている状況
Rust信者は我田引水が酷いな。
C++の標準化が遅いのはC++が巨大だからであって、しがらみのないRustの方が採用早くなるのは当然だろ。
> Optionは C++では std::optionalで これはC++17でようやく導入された
初出はboost::optionalで2003年8月
> Resultは C++では std::expectedで これは現在導入に向けて審議中
これはboost::outcomeが初出かな？ 2014年
> Iteratorは C++では std::rangesで これはC++20でようやく導入された
そこそこ違いがあるけど、boost::rangeは2003年。
どれもRustリリース前のものばかりだろ。
RustがC++のアイディアをパクって先行実装しただけじゃね？
746:デフォルトの名無しさん
22/04/09 13:25:35.27 OTzifHJR.net
C++の貧相なラムダ式見て涙出てくるわ
おばちゃんの必死の若作りみたいで痛々しい
>>730
相変わらず読む価値無しの駄文オナは続いてるようだよｗ
747:デフォルトの名無しさん
22/04/09 13:29:34.12 il24SwZF.net
ｽﾚﾘﾝｸ(tech板)
そろそろこっちでやってくれませんか？
748:デフォルトの名無しさん
22/04/09 13:41:58.59 xJyQ5Sl3.net
>>733
C++にはRustのenum(＝型収容付きenum＝タグ付きunion)が無いため
それらC++のバージョンはRustのものより劣っている
それではRustに勝てない
749:デフォルトの名無しさん
22/04/09 14:01:07.29 n9UcTFQC.net
スレタイの言語間で争える話題ないか考えてみたけど
それぞれ狙うところがバラバラで共通項がないな
750:デフォルトの名無しさん
22/04/09 14:06:05.68 J0gE1zR3.net
rustスレでやれば
もうJavaレベルには普及しないって結論じゃん
751:デフォルトの名無しさん
22/04/09 14:11:30.90 cvyLC6WE.net
次のスレからRustの話題は荒れるから禁止にしてスレタイからも削ろうｗ
752:デフォルトの名無しさん
22/04/09 14:14:38.49 ehpYMGIZ.net
このスレで荒れてくれる分には構わんわ。C++スレとかRustスレとかを荒らさないで。
753:デフォルトの名無しさん
22/04/09 14:19:25.04 mmQa05p2.net
便利さを理解するために不便さを体験するべきか否か論な訳だけど、個人的にはそれをするにしては遠回りが過ぎるのがC++という長大な壁だと思っているので経由する必要はないかなと思ってる
代わりの話としてZigとかどうよ
依存型的なコンパイル時計算と実行時計算をフラットに書ける感じ
結構賛否両論来そうな話題だと思う
754:デフォルトの名無しさん
22/04/09 14:22:44.53 cvyLC6WE.net
あれるのは上等なのか
関数オーバーロードがない言語は軒並み糞
755:デフォルトの名無しさん
22/04/09 14:27:38.36 OWfDePLk.net
オーバーロードあると高階関数に渡すときに一手間かかるのがヤダ
756:デフォルトの名無しさん
22/04/09 14:30:13.22 cvyLC6WE.net
標準ライブラリの標準関数のシグネチャー変える言語は糞
757:デフォルトの名無しさん
22/04/09 14:31:10.30 DIYn4SHb.net
教育には自分を撃てる言語を使った方が良いのでは？
758:デフォルトの名無しさん
22/04/09 14:31:48.55 cvyLC6WE.net
コンパイルするときにファイルのフォルダ階層に依存する言語は糞
759:デフォルトの名無しさん
22/04/09 14:33:14.01 gSPSOhuN.net
pythonガチアンチ勢がいるらしいな
760:デフォルトの名無しさん
22/04/09 14:38:25.49 cvyLC6WE.net
mainのあるファイルから連鎖的に参照されないと同じフォルダにあってもソースがコンパイルされない言語は糞
761:デフォルトの名無しさん
22/04/09 14:40:09.03 cvyLC6WE.net
言語じゃなかったな
コンパイラ環境か？コンパイラドライバか？
762:デフォルトの名無しさん
22/04/09 15:06:56.55 BphNan8J.net
言語依存の特性というよりはコンパイラがインクリメンタルかリカーシブルかなんて、言語にほとんど関係ない・・・
763:デフォルトの名無しさん
22/04/09 15:33:43.71 cvyLC6WE.net
じゃあ
ファイル名がクラス名やモジュール名と一致してないとダメな言語は糞
764:デフォルトの名無しさん
22/04/09 17:12:33.80 +P+cdtWg.net
自分じゃ話題も振らないのに他のスレでやれとかいう輩って・・・
765:デフォルトの名無しさん
22/04/09 17:40:19.06 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:デフォルトの名無しさん
22/04/09 18:34:35.92 JZiB2qZH.net
色んな言語やってきたが総合的にみてRustが現在のプログラミング言語の中の最強言語で間違いない
理論的に任意の言語が動き実際にも多数の言語が動かされているWebAssemblyにおいてもRustが利用トップである客観的事実もある
768:デフォルトの名無しさん
22/04/09 18:36:58.31 il24SwZF.net
話題は>>577で振ったけどスルーされました(^p^)
実際どうなんすかこれ、Yewとかその辺の利用者の使用感知りたいんだけど
769:デフォルトの名無しさん
22/04/09 18:48:35.17 SpxMIjuY.net
C++理解した程度でプログラミング理解したと思ってるのが痛々しい
770:デフォルトの名無しさん
22/04/09 20:19:57.41 cvyLC6WE.net
Rustはボロー周りとEnumだけがよくできていて他はそうでもない
長期で運用しにくいしょうもない弱点だらけ
771:デフォルトの名無しさん
22/04/09 20:26:08.31 n9UcTFQC.net
>>757
例えば？
772:デフォルトの名無しさん
22/04/09 20:26:09.05 TpQINAdx.net
そうだぞこんなの使ったら駄目だぞ
俺は使うがな
773:デフォルトの名無しさん
22/04/09 20:31:58.00 cvyLC6WE.net
レスをたどる能力もないのかRustの機能や制約を知らないのか自分で何かを調べる能力がないのか
どれなんだろう？
774:デフォルトの名無しさん
22/04/09 20:34:48.49 TpQINAdx.net
まとめるの面倒だからしないけど弱点だらけだぞ
それでも俺は使うがな
775:デフォルトの名無しさん
22/04/09 20:38:12.58 cvyLC6WE.net
言語面は置いといてrustはまずcargoを何とかしろ
モジュールパッケージの参照の仕組みを改善しろ
776:デフォルトの名無しさん
22/04/09 21:14:44.30 HNoOQ+Ya.net
次世代次世代つって結局Rustしか話題に上がってないやんｗ
777:デフォルトの名無しさん
22/04/09 21:34:11.92 lI/OjvKQ.net
>>763
つまり次世代はRust覇権が確定。Rust一択ってこと。
VScodeが覇権したようにプログラミング言語もそろそろRust一択にしようよ
778:デフォルトの名無しさん
22/04/09 23:10:39.42 SpxMIjuY.net
GoやクソバカPHPoorが滅びるべきというのには同意
779:デフォルトの名無しさん
22/04/09 23:31:48.47 qlihBLS+.net
それがRustが現在も今後とも流行らない理由だろうね
780:デフォルトの名無しさん
22/04/10 00:20:38.04 xqQhhwbp.net
他の言語でもRustのように広い意味でのデータ競合を実行前にチェックしてくれたらいいのに
そうすればその分の実行時デバッグを無くすことができるのに
781:デフォルトの名無しさん
22/04/10 00:52:23.84 fmRbxCQk.net
>>767
それ、馬鹿の一つ覚えだろうけど、割とマジに、データ競合で困る事なんて無いぞ。
もしみんなが本当にデータ競合に困りまくってたら、あらゆるアプリがRustでキラーアプリ化してるはずだろ。
実際は誰も困ってないし、さらにホームドアを付けたところで元々バグもないから差別化出来ず、キラーアプリ化もしてない。
面倒なのでスルーしたが、256で突っ込まれてるように、
実行時デバッグをそれほど必要としてる時点でプログラマとしてはポンコツ。
初心者なのを自覚して、まずはコードを頭の中で動かせるようになる事を目指すべきだよ。
782:デフォルトの名無しさん
22/04/10 00:52:41.03 dmNwgspZ.net
とかく計算系のライブラリの高速実装がGPGPU関係なくRustよりC++が優先されているのが悲しいが個人でなんとかできる規模でもなく
783:デフォルトの名無しさん
22/04/10 01:03:58.92 fmRbxCQk.net
>>769
やれば分かるが演算系はリソースの確保/開放ははっきり言ってほぼ必要ないので、
C++どころかCでも全く苦労しない。
しかもRustだと使い回すには一々所有権を気にしないといけないだけ面倒。
他言語なら見えれば何度でも問題なく使えるのに。
だからその辺がRustメインになる事はあり得ないと思うけど。実用重視なら尚更。
境界チェックが一々入る分だけ無駄に遅くなるのも致命的ではあるし。
俺は演算部分だけCのdllにして、GC言語からそれを呼び出すのが最強だと思うけど。
つまりNumPyでいい。(なお俺は使った事無いが）
784:デフォルトの名無しさん
22/04/10 01:07:40.61 clYg/AzK.net
>>768
超巨大なコードベースの前で人は簡単にポンコツになるよ
Sanitizerやclang-tidyへのgoogleの投資を見れば分かる
ただこの手のツールが必要になる言語やアプリは限られているから
あらゆる領域でデータ競合抑止が役に立つというのは偽だとは思うが
785:デフォルトの名無しさん
22/04/10 01:22:47.07 fmRbxCQk.net
>>771
それはコードベースが巨大すぎて見落とす確率が高くなるだけだろ。
ただし事実としてこれはあるのは認める。
これについては、Web系見てて思ったんだが、
Java(OOP)： どんな巨大なコードでも、20年前のコードでも、メンテナンスしてみせる！！！
Web系(Restful)： そもそも巨大にならないように分割。
一人で管理出来るサイズ(1,000-10,000程度)なら管理も簡単だし、コードも最悪書き捨てでもいい。
で、俺はWeb系の方が正解じゃないかと思いだしている。
だから、Javaを殺すのはWeb系だろうなとも思っている。
786:デフォルトの名無しさん
22/04/10 01:24:17.90 7I8wnXlj.net
Rustのプログラミング開発効率の良さには感動した
めっちゃ便利やな
787:デフォルトの名無しさん
22/04/10 01:24:40.32 fmRbxCQk.net
あ、すまん、分かると思うが、772訂正。
× 1,000-10,000程度
○ 1,000-10,000行程度
788:デフォルトの名無しさん
22/04/10 01:35:56.55 o4uZiwRi.net
>>772
用語の使い方からも
間違った対比からも
知的レベルの低さが露呈している
そこは単純にモノリスvs.マイクロだけであってOOPやRESTは関係ない
789:デフォルトの名無しさん
22/04/10 01:51:37.37 lgnAhvFe.net
>>772
web系というかブラウザやらOSやらの低レイヤーで考えるべきかと
OSもマイクロカーネルにしたらバグ少なくなるのかね
790:デフォルトの名無しさん
22/04/10 01:55:17.11 G67EgXPk.net
Nimの話題ロクに出てこないね
自分は使ったことないけど、使ったことある人はどう？
他の言語との違いや特色教えてくれると嬉しい
791:デフォルトの名無しさん
22/04/10 01:55:40.00 fmRbxCQk.net
>>775
まあ揚げ足取りはどうぞご自由にだが、話は通じてるようだ。
それで、反論は出来ないのか？
だとすると、やはりRust信者は低脳だとしか思えない。
（議論する気があるのなら、そのレスでは駄目だし）
・巨大化したコードベースではどうしても見落としが発生する
792:から、全部所有権を強制化してコンパイラでチェックする という直接的な解決策をRustは採用しているが、 ・そもそも巨大化しないようにひたすら分割し、見落としが発生しにくい規模に抑える という、上位アーキテクチャでの解決策もあるのだよ。 これは「データ競合」の時も言ったろ。 そこに問題があれば、解決策もそれなりに用意されてる。（格好いいかはまた別だが） それでは解決出来てない！不十分だ！と言うのなら、 どうにも取りきれなかったバグがRustによって取りきれ、結果的にキラーアプリ化するはずなのだが、 実際これがないだろ。 なら、これまでの地味な方法でも何とかなってたって事なんだよ。
793:デフォルトの名無しさん
22/04/10 02:03:42.86 fmRbxCQk.net
>>776
> OSもマイクロカーネルにしたらバグ少なくなるのかね
通説としてはそういう事になっている。（まあ知ってると思うが）
Linusはモノリシックカーネルの利点を言ってるけど、あれは俺は後付だと思うよ。
とはいえ速度重視ならモノリシックの方が上だし、
堅牢性重視ならマイクロカーネルってのは、技術的にも正しいと思う。
俺が言ってるのはもっと単純な話で、
機能が少なければ、実装に必要なコードも少なく済み、見落としも減る、という、至極当たり前の話。
だから「仕様を必要最低限に絞る事こそ最強」という話だね。
これもよく言われているとも思うけど。
だから、マイクロカーネルの方が仕様が小さいから実装コードも減り、結果的に「見落とし」のバグは減ると思うよ。
794:デフォルトの名無しさん
22/04/10 02:03:43.80 Yq6q8jid.net
Nim、vlang、Zig、Zenらへんはマイナーすぎてなんとも
D言語が使われなかったのと似たような理由で使われなさそう
795:デフォルトの名無しさん
22/04/10 02:04:15.32 UjiUu+PI.net
結論は変えるつもりがなくそこに至るまでの論理だけを手を代え品を代えひねり出し続ける
信者もそれに対する批判も不毛なんだ
796:デフォルトの名無しさん
22/04/10 02:06:36.51 NYexxOz5.net
>>778
アーキテクチャとアプリと言語は全て別問題なのに区別がつかずにごっちゃに話しているキチガイに見えます
797:デフォルトの名無しさん
22/04/10 02:21:42.17 UjiUu+PI.net
そんなことより次々世代言語にどういう特徴を持った言語が来るか予想しようぜ
798:デフォルトの名無しさん
22/04/10 02:34:28.97 NYexxOz5.net
>>780
IT大手各社が珍しく揃って支援＆採用しているRustだけが最近のプログラミング言語の中で長期に残りそう
>>783
Rustを置き換えるような次々世代言語は
Rustが備えるC言語並の速さ省メモリと安全性を押さえた上で異なるアプローチとなるだろうけど
Rust関係の論文が多い状況からすると理論的な裏付けが先行研究としてあるものの中から出てくるのかな
799:デフォルトの名無しさん
22/04/10 08:39:07.48 K0blu0OJ.net
C2とATS2のことも忘れないであげてください！
800:デフォルトの名無しさん
22/04/10 09:17:53.01 fmRbxCQk.net
>>782
それはRust信者はプログラマではないからだな。
プログラマは全レイヤで最適化を模索する事が出来る。（本来は）
例えばだいぶ前にスマホ見てて踏切の内側と外側を間違えて死んで話題になってたが、これについて
・現場(踏切の改善)：踏切内の障害物検知器の精度を上げ、人が間違って立ち止まってる場合も検出し、電車を緊急停止させる(Rust）
もありだが、
・運用（経路選択）：そもそも踏切を通らない経路を選択する。歩道橋があればそれを使う。
・運用（マナー）：歩きスマホ禁止。イヤホンも爆音にはせず、周りの人の声も聞こえる程度にしておけば気づけたかも？
・運用(ポリシー）：外でボーっとしない。事故に巻き込まれる確率は0ではないのだから、
801:常にある程度は周りに気を付ける ・アーキテクチャ：高架化して踏み切り自体を無くす(C#) アーキテクチャ面での対策が根本対策になるが、現実的には運用での回避になってる。 大人の場合はマナー/ポリシーで回避し、 これを期待出来ない小学生には、通学路なら歩道橋を設置して、経路選択での対策が為されてる。 「データ競合」も同様に、 ・現場(チェッカ)：所有権を厳密に管理し、コンパイラでチェック(Rust) もありだが、 ・運用：難しい事はしない。競合する可能性のある場所は限定的にして、見ればバグに気づける程度にする ・アーキテクチャ：スレッド構成上、そもそも競合が発生し得ない(C#) で、アーキテクチャでの対策が根本対策だが話が大がかりになり面倒になるので、 大体は運用で対策され、でも何とかなってるというのが実態だ。 通常は言語選択はアーキテクチャよりさらに上のレイヤか、そもそも独立した軸なので、 言語比較で一番下のレイヤ（現場）での改善のみに限定するのが間違ってる。 そして重要なのは、既存の言語でも根本対策はやる気になればすぐに出来るんだよ。多少面倒なだけで。 だから信者の言う「Rustでなければ無理だった」というアプリが存在せず、キラーアプリも出てこないわけ。 Rustは「一方ロシアは鉛筆を使った」の米国側を突き進もうとしてる。これもありだが、ロシア側もありなだけの話。
802:デフォルトの名無しさん
22/04/10 09:21:12.35 n6k1Ijhp.net
この人は無駄で無意味な間違った例え話を延々と繰り返し妄想の世界に住んでいる
803:デフォルトの名無しさん
22/04/10 09:21:25.28 sR7YmRYu.net
Scalaの方がKotlinより機能豊富だけどWeb系では落ち目になったね
Scalaの方が好きだが
804:デフォルトの名無しさん
22/04/10 09:26:20.41 BLmvSJJ5.net
>>788
Scalaは結構好きで長く使っていたけど
使っているとどうしてもJVMが見えてしまう部分があって
Rustに乗り換えちゃったな
805:デフォルトの名無しさん
22/04/10 09:29:58.47 93k1uAXl.net
rustaceanはある時期を境に爆発的に表に出てきてプログラミング界隈を圧倒する未来が見える
806:デフォルトの名無しさん
22/04/10 09:41:23.13 BLmvSJJ5.net
表に出るかなぁ？
OSやコンパイラ、ミドルウェアあたりに侵食して、気付かないうちに全員が依存してる、みたいな状況なら有り得そう
807:デフォルトの名無しさん
22/04/10 10:05:57.88 W8i2G4wq.net
scalaはコンパイルが困憊るほど遅すぎた
808:デフォルトの名無しさん
22/04/10 10:55:59.09 vR2aNwQM.net
>>779
>Linusはモノリシックカーネルの利点を言ってるけど、あれは俺は後付だと思うよ。
後付けというか経験知からの意見だろ。
Linusはそもそもが理論家なわけでもないし。
仕様を最初から小さく絞れるとか考えてる奴は全く的外れとしか言いようがない。
809:デフォルトの名無しさん
22/04/10 11:21:10.49 7HDkHX8h.net
Linux作り始めたときからタネンバウムと論争しているのに理論家じゃないとか後付けとか
810:デフォルトの名無しさん
22/04/10 11:26:19.70 nRSUY8iy.net
一部だけ小さくしてバグ減っても意味ないよ。
部分的な最適化はシステム全体の最適化の視点では上手く機能するわけではないからね。
一つ前のFreeBSDで話題になって詳しい人が説明してくれてた。
ｽﾚﾘﾝｸ(unix板:794番)
811:デフォルトの名無しさん
22/04/10 11:41:39.32 vR2aNwQM.net
>>794
だからLinusはタネンバウムみたいな理論家を嫌ってんだろ。議論の中身理解してないのか？
812:デフォルトの名無しさん
22/04/10 12:14:41.45 N1Kz0CTA.net
>>783
C言語より10倍速い言語が現われて界隈歓喜
813:デフォルトの名無しさん
22/04/10 12:18:37.19 W8i2G4wq.net
>>783
Googleに頼めば全て完成する
814:デフォルトの名無しさん
22/04/10 12:31:07.74 2AahvlRa.net
次世代はシンプルな言語仕様+強力な静的チェックだと思う
Rustみたいに事前の宣言でガチガチに縛るんじゃなく、型推論やフロー解析を積極的に利用して利用のされ方に基づいた型チェックや生存期間のチェックを行う
まあこのままいくとJavaScript+VSCodeがそれになるかもしれないが
815:デフォルトの名無しさん
22/04/10 12:46:03.55 fBzqkVFD.net
>>799
ことweb界隈で使われる言語に関しては前半同意
サービス独自の機能をスピーディーに開発することが求められるweb界隈において、プログラマ自身が考えないといけないことが多くなるrustはまず普及しない
816:デフォルトの名無しさん
22/04/10 12:55:32.64 fmRbxCQk.net
>>793
運用していくうちに追加追加で仕様が段々膨らんでいくのはある程度仕方ないとして、
それでも更新タイミングで不要な仕様を出来るだけ削除して仕様を絞るのは基本中の基本だろ。
マイクロカーネルもある意味これで、「カーネルがやるしかない事しかやらない」という、最小仕様を目指したものだ。
プログラミングに於いて小さい仕様を目指すのは大正義だし、みんなそうしてる。
（出来てるかはまた別。特にJava分野。
対してWebの場合はこの辺切り捨てるしサービス終了もありありなので、
反発はあるかもしれないが、仕様が雪だるま式に膨らんでる事はない。
俺はこの辺、Java流の「どんなに大きくなっても何とかしてみせる」ではなく、
Web流の「定期的に棚卸しで削除」の方が長期的には正しいのではないかと思いつつある、という事)
>>794
Linusは当初から分かっててモノリシックを選択したのはいい。
当時の速度的にそれが妥当だったのも分かる。
ただ、今となってはマイクロカーネルにすべきだし、徐々にでも変更していくべきだと思うよ。
今でもモノリシックの利点を説いているのは、後付のように思える。
817:デフォルトの名無しさん
22/04/10 13:03:29.70 WQm20ac3.net
>>794
「俺は後付だと思う」って予防線貼ってるし、そこまで知らなかったんだよ、きっと
許してあげて
818:デフォルトの名無しさん
22/04/10 13:10:21.13 BLmvSJJ5.net
>>799
Rustのように型が強力でコンパイル時チェックの細かいGC言語ってのが現状ないから
そこは新言語の余地がある気がしている
JSだとどうしても型はガバガバにならざるを得ないからなぁ
819:デフォルトの名無しさん
22/04/10 13:17:50.89 blp15KeH.net
言語には向き不向きがあるわけで
それを無視してRustがすべての言語を置き換えるみたいな話をしているのがおかしい
C/C++の置き換えは進むかもしれないけどwebやスマホやPCアプリとかでは採用されないでしょ
普通はどの言語が最適かをいろいろ検討して決めます
なんか通販の広告みたいなんだよね
良いことしか言わないし
大手IT企業が採用ってのは通販広告の有名人も愛用！みたいな感じ
コンピュータ関係の新技術の売り文句は100%そうだった試しはないので話半分で聞いていた方がよいと思う
820:デフォルトの名無しさん
22/04/10 13:30:51.71 fBzqkVFD.net
>>804
ほんまこれ
このスレの一部のRust信者がRustこそ至高みたいなノリだけど、このノリについていけないRust推し結構いると思う
821:デフォルトの名無しさん
22/04/10 13:55:42.06 UjiUu+PI.net
いつでも最初から型が要るのは足枷というのは確かに思うわ
そうなると漸進的型付けってやつかねえ
TS以外のaltJSは死んだとかだれかが言っていたが、Haxeの再興もあるか？
822:デフォルトの名無しさん
22/04/10 14:04:03.83 WXrh5iWM.net
>>805
というよりRustは好きだけど別に推してはないという
誰も使わなくていいよ
俺と一部のお前らが使うだけでいい
みんなに使ってもらう必要なんて一切ない
823:デフォルトの名無しさん
22/04/10 14:14:16.90 li
824:fo30Qd.net
825:デフォルトの名無しさん
22/04/10 14:16:40.89 WXrh5iWM.net
アンタにレスしてないから気にしないでね
人を小馬鹿になんかしてないし
Rust以外の言語も好きだし
そもそもどの言語も馬鹿にしたりしない
826:デフォルトの名無しさん
22/04/10 14:23:28.49 sejldIDY.net
こういう屈折した性格の勘違い野郎ばっかで本当に近づきたくない。扱いにくいのに能力なんてないし言語触ってれば最先端だと勘違いしてる、とんでもねえバカ
827:デフォルトの名無しさん
22/04/10 14:40:08.25 9taU8UGO.net
RustはMozillaのステマでfirefoxのRust導入は
不可能と叩きが暴れてた頃が懐かしいなあ～
828:デフォルトの名無しさん
22/04/10 14:57:34.06 fmRbxCQk.net
>>810
まあ勘違い馬鹿は必ず存在するのである程度致し方ない。
連中は基本的に「難しい言語使ってる僕すごい」であり、
プログラミング言語の優劣を自己で判断する能力はないので、
何か新しく「凄いけど難しい！！！」とされる言語が出てきたら勝手に移住する。
だから、対策としては、何でもいいから新しい言語を作って適当に吹聴する事だね。
そうすればRust界隈も浄化される。
なお一時期はC++の連中の選民思想が超絶にウザかったが、これが今はRustになってるだけ。
ならC++スレはどうなったかと思って見てみたら、完全にお馬鹿の溜まり場になってたわ…。
まあ○○言語を使ってれば賢いって事にはならないので、当然でもあるのだが。
829:デフォルトの名無しさん
22/04/10 15:13:47.07 nUqmGYW5.net
ちんちんシュッ！シュッ！シュッ！
830:デフォルトの名無しさん
22/04/10 15:18:10.17 LCNa54V5.net
完結に喋れない病気直ってないの？
831:デフォルトの名無しさん
22/04/10 15:22:51.62 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:デフォルトの名無しさん
22/04/10 15:22:54.24 WXrh5iWM.net
>>811
なんか最初の頃はMozillaの印象強かったよねえ
833:デフォルトの名無しさん
22/04/10 15:24:50.68 x8
834:oklrTT.net
835:デフォルトの名無しさん
22/04/10 15:33:46.76 lgnAhvFe.net
>>815
ruby3はruby2の3倍高速化というお題目でそれなりの成果を出した訳だけどそれでもまだまだ足りないと言うのね
スクリプト言語で高速化するためにはボトルネック箇所をCなりで置き換えるのが普通
JSはブラウザで動かさなければならないという制約上言語自体を高速化する必要があり
ブラウザベンダー大資本がつぎ込まれた結果高速化した
前提がかなり異なるから同じことがruby/pythonに起こることはないのではないか
836:デフォルトの名無しさん
22/04/10 15:56:47.79 fmRbxCQk.net
>>818
> ruby3はruby2の3倍高速化というお題目でそれなりの成果を出した訳だけど
それよく勘違いされてるが、
3倍になった『部分がある』だけで、全体が3倍になったわけではないよ。
(これは公式でもこう『追加』アナウンスされてたはず）
俺が思う割と正当な比較はこれだが、
> URLﾘﾝｸ(1.bp.blogspot.com)
> URLﾘﾝｸ(okuranagaimo.blogspot.com)
「Pythonは100倍以上遅いぞ」なんて言われる事も多く、
C比だとJSで5-6、Python/Rubyは80-100程度だと思ってる。
だからまずはJS並にするだけで16倍程度は高速化するわけであり、CやCythonは嫌だ…な連中には十分だと思うんだよ。
Rubyも16倍のクライアントを捌けるようになれば鯖代も半分以下に出来るだろうし。
(そもそもコードが汚れるのは無理に速度チューニングしたコードにするからであり、
馬鹿みたいなコードでも速く動くのならコードも綺麗に保てるし）
> 前提がかなり異なるから同じことがruby/pythonに起こることはないのではないか
逆に言えば、金さえつぎ込めば改善出来るわけで、
改善項目とそれに要する金額をずらっと羅列して、クラファンで資金が付いたところから実行、
十分な結果で採り入れられたらそいつがその資金を給料として獲得、とかいう方式にすれば、
割とすぐにでも行けるんじゃないかと思うんだけどな。
837:デフォルトの名無しさん
22/04/10 15:58:01.34 UjiUu+PI.net
>>815
> JSにおいて速度の枷は動的型であり、だからこそTSでアノテートだが
違うよ
ブラウザがTSをそのまま食えるようにするというのは開発者側でトランスパイルする必要性を無くすだけで実行速度の改善を目的としたものではないよ
ていうかその方向性はasm.jsとかPNaClみたいな先駆者がいて彼らの現状の到達点がWASMという経緯があるよ
838:デフォルトの名無しさん
22/04/10 16:21:05.00 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:デフォルトの名無しさん
22/04/10 16:49:31.19 UjiUu+PI.net
知らなかったくせに
841:デフォルトの名無しさん
22/04/10 16:53:31.25 QEMS6G9N.net
毎日Rust攻撃してる人、暇なんかな。
別の事に時間使えはいいのに、と他人事ながら思うよ。
842:デフォルトの名無しさん
22/04/10 16:57:09.68 7HDkHX8h.net
AssemblyScript や Static TypeScript の話をどこかで聞きかじったのが混ざってるんだと思う
843:デフォルトの名無しさん
22/04/10 17:16:31.79 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:デフォルトの名無しさん
22/04/10 17:19:51.97 kr0xp78k.net
>>794
ライナスは理論家じゃなくて実務家
ライナスはUNIXクローンが動かないと意味がないからとりあえずソースを書いて動かそう派で
タネンバウムは理論上マイクロカーネルが有利だからマイクロにしろと言って噛みついて来た理論家
845:デフォルトの名無しさん
22/04/10 17:37:12.48 ZtzjE5Lq.net
Blitz.js は、React 版・Ruby on Rails。
Cake PHP みたいなものか？
Type Script なら、Rubyよりも型安全だけど、
モデルが、RailsのActive Record よりも弱いらしい
846:デフォルトの名無しさん
22/04/10 17:53:45.64 lgnAhvFe.net
>>819
"それなりの成果" ってわざわざ書いた意図をくみ取って欲しかったな
クラファンとかアイディア出すのは良いんだけど
具体的にどういう課題があって改善したがってるのかが分かんないんだよね
Cで書いたモジュールと置き換えるのじゃだめなの？
847:デフォルトの名無しさん
22/04/10 18:07:58.32 b41tYEVR.net
定期的にKENTAさんを引用している人、もしリスナーさんだったらやめたほうが良いですよ？
分析は正しいかもしれないが、イメージを悪くして迷惑をかける可能性だってあるし、
本人が見ていないところに、荒らしにも見える行為はマナー上良くないですからね？
848:デフォルトの名無しさん
22/04/10 18:20:31.55 aoUYGCMa.net
Youtubeで有名な、とかいう主観に満ちた枕詞をつけてるあたり権威付けして威を借りようとでも思ってるんでしょ
たかがYouTuberに言語の勢いを減らせるほどの影響力ないでしょ
849:デフォルトの名無しさん
22/04/10 18:27:03.03 Yq6q8jid.net
YouTuberの名前を出されても中学生が書いてるのかなとしか思わんしマジでそんなやつどうでもいい
偉そうに技術を語るなら、超有名OSSプロダクトをいくつも作ってるとか、GAFAでアーキテクトをやってるとかぐらいの実績がほしい
850:825
22/04/10 18:58:00.76 ZtzjE5Lq.net
KENTA の有料のRuby on Rails サロンは、
851:日本6位の3千人。 日本1位は、キングコング西野の数万人 vue.js 日本ユーザーグループが、3千人 単独のフレームワークの有料サロンで3千人は、あり得ない！ 世界的にも断トツじゃないか？ 実際に、外人から驚嘆されている。 転職で未経験者が、こんなすごいポートフォリオを持ってくるのは、あり得ないって これが日本人が発明した塾・予備校。虎の穴 でも、これほどすごくても、日本人の年収が先進国の1/3 なのも、あり得ないけどw 失われた30年。 財務省のせいで、世界中で唯一、GDP が伸びなかった国
852:デフォルトの名無しさん
22/04/10 19:10:26.93 TRRwI9qz.net
KENTAガイジNGしてないひとまだいたんだ
853:デフォルトの名無しさん
22/04/10 19:35:37.31 N5dTO4j8.net
>>821
GC対応は悲観的
様々な言語で効率化が異なる手法のGCのためにWebAssemblyに共通仕様のGCを作るのは不可能という結論になった
だから当面はWebAssemblyにGCは載らずいずれGC対応しても各GC言語はそのまま動かず特別仕様に制限される
854:デフォルトの名無しさん
22/04/10 19:50:06.06 lgnAhvFe.net
>>834
JVM on WASMみたいなアプローチならどうじゃろ？
855:デフォルトの名無しさん
22/04/10 20:10:14.95 vR2aNwQM.net
>ただ、今となってはマイクロカーネルにすべきだし、徐々にでも変更していくべきだと思うよ。
>今でもモノリシックの利点を説いているのは、後付のように思える。
そう思ってるなら思ってる奴がフォークするなりしてやればいいんじゃね？
そのためのフリーソフトなんだから。でも結局やらんだろうがな。
856:デフォルトの名無しさん
22/04/10 20:30:35.41 aoUYGCMa.net
オンラインサロンの会員数を出したり、外人から驚嘆されてるとかいう眉唾情報を出したり、教祖が教祖なら信者も信者だな
857:デフォルトの名無しさん
22/04/10 20:49:57.25 fmRbxCQk.net
>>828
> 具体的にどういう課題があって改善したがってるのかが分かんないんだよね
> Cで書いたモジュールと置き換えるのじゃだめなの？
この主語がRubyではなく、Rubyランタイムだと仮定すると、以下。
Rubyについて文句言われてるのは速度だけだろ。
エコシステムはPythonには劣るが、基本的には「それ、Rubyでも出来るよ」程度にはなってるんだろ。
なら後は人数だけで、新規を呼び込むにはPythonよりも圧倒的に速い速度だよ。
手法は速くなるのなら何でもいい。
改善箇所は、まずはプロファイラ付きのランタイムを配ってデータを集めて、
使用頻度の高さ＊コード見ての改善見積もり＝高速化効果見積もりと、その費用の一覧を作って、
ついでにそのプロファイラー付きランタイムでの使用実績も掛けて各社向けに
「御社のRubyプログラムは○○円で△%高速化」の一覧に差し替えて、クレクレ君するしかないね。
長期的に見れば自前でゴリゴリチューニングするよりランタイムが速くなってくれた方が楽だから、
10社くらい束ねればわりと行けるのではないかと。
あくまで、各社が「ここを速くしてくれ」として費用を出してきた場所を改善だ。
ユーザー無視して高速化しても外れるだろうし。
858:デフォルトの名無しさん
22/04/10 20:50:32.86 fmRbxCQk.net
>>828
> 具体的にどういう課題があって改善したがってるのかが分かんないんだよね
> Cで書いたモジュールと置き換えるのじゃだめなの？
主語がRubyだと仮定して、
Rubyのどこが不味いのか、速度が欲しければCでdllを用意しろ、という意味なら、死ねと言われるだろうよ。
Rubyは根本の戦略が間違ってる。
Pythonとダダ被りなので、このままだと、シェア的に見て死ぬのはRubyだと確定してる。
なら、Pythonと正面からやり合うのではなく、違う道を模索しないといけない。
具体的には互換性無視での先行だね。そして「学生が学ぶならRuby」という地位を確立してしまう事だ。
2012位にRubyカンファレンスでMatzが「互換性を重視しました！」
と言って沸いたという記事があったはずだが、あれが完全なる間違い。
互換性重視と言うと聞こえはいいが、これは「新規のコードよりも既存のコードを優遇する」という事であり、
859:これからコードを書く/学ぶ連中にとっては全く意味無い。それよりは、最新の書き方を試せる方がいい。 どの言語も段々と互換性を重視するしかなくなるので、仕様改訂出来ず、段々と古くさくなっていく。 Pythonなんて既にそうなってるだろ。 なら、「常に最新の書き方が出来ます！」をキープして、新規学習者の登竜門的な地位を確立するしかない。 これには、 ・バージョン管理で仕様を年に一度は大幅改訂。新しい記法を貪欲に採り入れ、古い記法はばっさり捨てる。 ・古いバーションの記述でも動きはするように、関数単位でのパースバージョン指定が出来るようにする。 ・学生にとって入社～3年目程度に必要な概念は全て学習出来るよう、 他言語でのプロポーザルの有力案は全て採り入れる。（高速である必要はなく、動けばいい） とかで、とにかく「プログラミングの学習にはRuby!」という地位を確立しないと、 Pythonに食われて死ぬ未来しかないだろ。 で、RoRは仕様を改訂/捨てまくりだと聞いてるけど、 あれが正しいよ。というか、何かしらPython(や他言語)と差別化しないと死ぬだけ。
860:デフォルトの名無しさん
22/04/10 20:57:15.28 aoUYGCMa.net
学生にRuby…？
専門学校ならそれでいいかもしれんけど
861:デフォルトの名無しさん
22/04/10 20:58:47.74 fmRbxCQk.net
>>834
> 様々な言語で効率化が異なる手法のGCのためにWebAssemblyに共通仕様のGCを作るのは不可能という結論になった
そりゃそうかもしれんが、これはWebAssemblyの連中が真面目すぎるだけ。
Python/Ruby/JS/TSを使ってる連中が、GC方式なんて気にしてるわけねえだろ。
GC出来てれば何でもいいんだよ。（循環参照でもGC出来るのは必須で）
やりたくないから理由を適当にでっち上げたようにしか見えないね。
（オープンソースならそんなもんだが）
862:デフォルトの名無しさん
22/04/10 21:10:10.44 fmRbxCQk.net
>>836
wikiによるとArchとDebianでやってみた奴はいるらしい。
> 2012年現在、Machベースの GNU Hurd も機能しており、それを採用した Arch Linux と Debian のテスト版も進行中である。
> URLﾘﾝｸ(ja.wikipedia.org)
ただまあ、マイクロカーネルにしても、
ドライバ周りのコードを（カーネル開発人員が）自前で書かないといけないので、
最終的に書かなければならない合計コードサイズ自体は大して変わらず、
カーネルで落ちるかユーザーモードでバグるかの違いで、大して意味はないのかも？
ならわざわざやろうと思わないのも道理だ。
863:デフォルトの名無しさん
22/04/10 21:15:37.68 QEMS6G9N.net
GNU Hurd ダメなやつだから。
864:デフォルトの名無しさん
22/04/10 21:24:19.23 9taU8UGO.net
この聞きかじりで広く明後日の知識を披露してる人は
前暴れてた人と同じなのか違うのか
865:デフォルトの名無しさん
22/04/10 21:28:26.61 ZtzjE5Lq.net
循環参照とか参照カウント・世代別GC とか、
動的言語で、そんな事を知っている香具師はいない
唯一、Ruby には「Rubyのしくみ」と言う、
Ruby1.9の仮想マシンの本があるから、
Cookpad の笹田耕一が、どういうようにRuby VM を作ったかと言うのは、
日本人だけは知っている
866:デフォルトの名無しさん
22/04/10 21:44:41.86 +3UgN2G1.net
香具師→やつ
訂正しとくわ
867:デフォルトの名無しさん
22/04/10 21:54:26.09 W8i2G4wq.net
>>832
すまん、コレ見るとやっぱジャップランド土人ってガイジの集団じゃないか？
中国に併合してもらって考えを悔い改めた方がいいのでは？
868:デフォルトの名無しさん
22/04/10 21:55:02.28 QUw9uGH2.net
V8高速化するのは兆円越えるような凄まじい金銭が投入されてるが、pythonの組織など億から10億程度、rubyはその1/5行くかどうかなんだから�
869:｣り合える訳がない。
870:デフォルトの名無しさん
22/04/10 22:10:35.68 tGlbubKc.net
他言語のエンジンをrustで作り出したら本格的
今のところjs/tsのエンジンであるdenoのみか
871:デフォルトの名無しさん
22/04/10 22:50:17.14 D/xoL3wp.net
GOとか早くも終わりそうな感じだけど実際どうなの？
API作るには良いかと思った事もあったけどわざわざ採用する程でもないんだよねぇ
872:デフォルトの名無しさん
22/04/10 22:54:33.39 EeuOQJAe.net
>>849
RustによるPython実装のver0.1が公開
ｽﾚﾘﾝｸ(river板)
Rython（ライソン）は、Rust言語によりPythonを実装することを目的として開発されたプログラミング言語である。
873:デフォルトの名無しさん
22/04/10 22:54:54.30 vR2aNwQM.net
サーバー用途以外だったらワークフローエンジンとかCIツール周りなんかは向いてそうな気はする。
874:デフォルトの名無しさん
22/04/10 22:55:50.40 Yq6q8jid.net
>>848
いくらなんでもそんなに金かけてるわけないだろ
V8の開発をする専門エンジニアをフルタイム数万人規模で働かせるっていうの？
ちなみに任天堂やソフトバンクの時価総額が7兆円ぐらいな
875:デフォルトの名無しさん
22/04/10 23:46:53.01 OCBvsT75.net
>>850
Goはある範囲内なら簡潔に分かりやすく書けていいよ
今はRustでもGoと同様のプログラミング方法で簡潔に分かりやすく書けるようになったため私はRustへ移った
理由はRustの方が速くて他にも広く適用できるため
876:デフォルトの名無しさん
22/04/10 23:58:13.16 pEZ46Oyr.net
>>835
もちろんそれでも他でも動く
C#によるBlazorも重くて遅くてデカいけど動いている
焦点は効率の問題
877:デフォルトの名無しさん
22/04/11 00:50:05.90 E3KBZvfK.net
>>838
いや、だから一般論じゃなくてあなたは何に困ってるのかを聞いてるの
ただ漠然と速度が遅いと言われるだけでは分からんのよ
878:デフォルトの名無しさん
22/04/11 01:12:00.13 umXHqcZk.net
使ってないので何も困ってませんというオチ
879:デフォルトの名無しさん
22/04/11 07:03:18.35 j88vhZuT.net
抽象論で済ませたいという輩はそもそもプログラム向いてないよ。
880:デフォルトの名無しさん
22/04/11 07:06:48.33 3x0R8xqL.net
だってプログラム書けないだもん
881:デフォルトの名無しさん
22/04/12 13:44:31.10 A7zu82Eq.net
速度に不満があるならJulia使おうぜ
ちなみに俺はプロット表示出来なくて、すぐ必要なわけでもないし面倒になって環境構築の段階で挫折した
882:デフォルトの名無しさん
22/04/12 20:19:42.59 vS+B3//0.net
所詮道具は道具だ
個人的に深掘りしたいライブラリ整備したい言語と
働くために使う言語は別だと割り切ればだいたい幸せだよ
まあそれで何個も使ってるとしんどいんだけどな
883:デフォルトの名無しさん
22/04/12 20:24:08.33 Th8uJDWe.net
>851 さすがに むせた
884:デフォルトの名無しさん
22/04/13 02:09:35.75 dECpaYfo.net
流れに身を任せれば良い。幸福感が得られる。
重要な決定に関与しないので、責任感に追われることは無い。
それも生き方。何の間違いもない。
885:デフォルトの名無しさん
22/04/13 09:38:49.99 McIysJ0Q.net
このようにして奴隷は誕生するのである。
886:デフォルトの名無しさん
22/04/13 14:31:42.18 7VeATDTg.net
プログラミング言語の人気ランキング、順位変動は縮小傾向にある―RedMonkが調査
URLﾘﾝｸ(atmarkit.itmedia.co.jp)
887:デフォルトの名無しさん
22/04/13 16:28:48.93 WrxbMLiQ.net
Nimだけトップ20圏外か
888:デフォルトの名無しさん
2022/04/1
889:3(水) 17:49:20 ID:QcgahTwn.net
890:デフォルトの名無しさん
22/04/13 19:36:47.36 uZMWha80.net
考えてみたらnimなんてQitaか5chでしか聞かなかったもんな。
声の大きい人のおかげでGoやRustと同格っぽく錯覚してたけど、実際は>>865のように
Crystalあたりが比較対象になるマイナー言語だったんだよな。
891:デフォルトの名無しさん
22/04/13 19:42:01.28 tSwum0gN.net
メジャーかどうかがキミらの関心事なん？
892:デフォルトの名無しさん
22/04/13 19:49:54.89 P5Yf9dEj.net
>>865
16.Go
17.Powershell
と並べられるとGoが急にしょぼく見えてきた
893:デフォルトの名無しさん
22/04/13 20:39:44.52 je5sMJxi.net
Zigがグラフに入ってない気がするけどなんでだろ？
Vでも入ってるのに
894:デフォルトの名無しさん
22/04/13 20:55:30.92 TtGTyBSH.net
Zは今は駄目だ
895:デフォルトの名無しさん
22/04/13 20:59:16.38 kkNkKFp+.net
型無し糞言語を勧めてくる屑どもは市中引き回しの上打ち首に処せ
896:デフォルトの名無しさん
22/04/13 21:55:10 VZeyJm3t.net
>>865(整理)
1 JavaScript
2 Python
3 Java
4 PHP
5 CSS
5 C#
7 C++
8 TypeScript
9 Ruby
10 C
11 Swift
12 R
13 Objective-C
14 Shell
14 Scala
16 Go
17 PowerShell
18 Kotlin
19 Rust
19 Dart
897:デフォルトの名無しさん
22/04/13 21:56:44 WrxbMLiQ.net
Rが意外と高ランクなのはなぜだろう
Stack Overflowの質問数が多いから学生が課題で使うなどしてるのかな
898:デフォルトの名無しさん
22/04/13 22:04:41 lf84vSB/.net
>>874
このスレにとっての整理というのはこういうことだろ
8 TypeScript
11 Swift
16 Go
18 Kotlin
19 Rust
899:デフォルトの名無しさん
22/04/13 22:07:12 CqWBmt+n.net
>>865
この相関表だとJuliaがここにスレタイに入ってないのはおかしい、Nimも外してJVMで動いてる競合が全くしないKotlinも外せよ。
入れるならコンパイルできるHaskell、Erlang、Dあたりだろう。TypeScriptは残しても良いけど、ここの人たちがGCだのなんだの
ムーブセマンティックがどうの言うてる次世代言語のような先進性なんてほとんど無いぜ？
このスレにNimがあるのはえらい迷惑、RustやC++をまじめにやってる人も迷惑だと思うけど、あんたら好きそうだから隔離としては
ええんちゃうか？
900:デフォルトの名無しさん
22/04/13 22:10:18 SVdVjY9z.net
こないだここで話題に出てたFlixはいいセンいってると思うんだけどな
901:デフォルトの名無しさん
22/04/13 22:11:15 CqWBmt+n.net
そもそもHaskellが入ってないのがおかしい
902:デフォルトの名無しさん
22/04/13 22:20:19.72 tuyUM4Xb.net
「次世代言語」ってどういう意味よ
ちなみにHaskellはJavaやPythonなんかよりも古い言語だ
903:デフォルトの名無しさん
22/04/13 22:35:07.15 WrxbMLiQ.net
現世代じゃなくて次世代ってことは流行ってる言語はだめか
Nim以外スレタイから消した方が良い？
904:デフォルトの名無しさん
22/04/13 22:48:55.23 IduSatGp.net
実用プロダクトがバンバン出て
求人も当たり前に見つかるのは
次世代感はあまり無いかも
905:デフォルトの名無しさん
22/04/13 23:05:23.43 ay76B0Js.net
>>880
Haskellは98とか2010とかいろいろ修正機能追加してるので、C11とかC++20とかそういう立場でしょ。次世代ってことは現世代で
問題があるか書き難いか、表現しずらい、誤解を生むような記述が解消されてたり、コンピューターサイエンス屋が無理やり入れたに
機能なんかを削除したり。あとは実行上のメモリー管理や分散処理が簡単になると
906:か
907:デフォルトの名無しさん
22/04/13 23:07:38.62 n/eoHDdL.net
それはNimが現世代言語になれなかっただけでは？
908:デフォルトの名無しさん
22/04/13 23:26:59 lUUAz3L8.net
>>880
無駄が少なく記述できる（冗長・簡潔）とか、新しい概念が追加されている（Structured programming→OOPS)なんかもそう。
今まではアセンブラや行番号記述の言語（例えばN88BASIC）などから構造化プログラミングが可能になり、C++やJavaでOOPSが唱えられていたけどRustで言えば多態はクレートになるが、クレートより先の進化が無いとは限らない。
またErlangやHaskellにあるガード構文もパラダイムを変えるようなものではなく、あくまでも制限なので構文上で次世代というには、多くの言語が似たような構文を導入し始めてる。
例えばasync/awaitなど非同期構文などはまさにそれ
909:デフォルトの名無しさん
22/04/13 23:42:53.90 5KgZTTtC.net
>>883
メモリー管理というか、どんどん複雑大規模化するソフトに対するメモリーに起因するバグが統計的に少なく記述できる「次世代言語」
910:デフォルトの名無しさん
22/04/14 11:35:33.89 lzoOecS7.net
Haskelｌはメインの言語としては狭すぎる
特殊な分野向け
というがCSSがランキングにあがってるんだよね
911:デフォルトの名無しさん
22/04/14 12:22:45.14 Z089SWEo.net
ScalaがGoやKotlin,Rustより上なのか
Scala3になっていろいろ改善されてるみたいだし、まだ復活の目ある？
912:デフォルトの名無しさん
22/04/14 12:46:43 NlVTXqiH.net
ない
Scalaはビッグデータ分野のOSSでの採用が多かったから既存コードベースだけは無駄にデカい
そんな状況で非互換メジャーアップデートしたらどうなるかわかるだろ？
913:デフォルトの名無しさん
22/04/14 17:49:33 kkKc/VMN.net
なるほどPython3
914:デフォルトの名無しさん
22/04/14 18:41:17 lzoOecS7.net
本当の意味での次世代って存在するのかな？
ロシアが威嚇のために日本海に向けてミサイル撃ってるけど
他の国にも威嚇してエスカレートして核戦争始まって文明が滅ぶかもしれないｗ
915:デフォルトの名無しさん
22/04/14 20:30:53.20 06ANIdH6.net
人類がそこまでの存在だったってだけの話よ
916:デフォルトの名無しさん
22/04/14 21:31:28.88 dmYzyL87.net
次世代言語って、今流行してる言語を置き換えうる別の言語ってことじゃないの？
新しい概念やらが採用されてるかどうかは関係なく、政治的な理由で決まることもある気がする
まあそういうのよりは、新しい概念が採り入れられてる言語について語ったほうが楽しいだろうけど
917:デフォルトの名無しさん
22/04/14 21:39:45.95 IQzKdxCE.net
Rustは次世代を担う方の素養はないと思う。C->C++->Rustと進んでこないとRustの目指している世界観が理解できないと思うのに、コードは命名規則に_を使うのか思えば大文字小文字でFn/fnで意味付けをしてたり、’staticみたいなコメント？と思える雑な定義が多い。理解してない子が勢いで作ったの？って感じがするので広める前に整理が必要だよね。ISOをとったらどうかな？
918:デフォルトの名無しさん
22/04/14 21:50:00.79 Hy4f2CwM.net
rust嫌いなのはよくわかったけど理由付けがしょーもなさすぎる
919:デフォルトの名無しさん
22/04/14 21:52:41.11 9EW5Ge1x.net
>>894
JavaScript→TypeScript→Rust と普通にステップアップしたよ
とても使いやすいよ
920:デフォルトの名無しさん
22/04/14 23:13:24.53 BxOaTkYv.net
Cすっ飛ばしてRust来たけど気に入ってるよ
921:デフォルトの名無しさん
22/04/14 23:45:37.43 fXS8nb7A.net
Rustは十分に抽象化されているため
Cの生ポインタの知識なく効率�
922:謔ｭ使える むしろ生ポインタは安全でないため足を引っ張る知識
923:デフォルトの名無しさん
22/04/15 00:26:17 /A+hDicd.net
なにいってんだこいつ
924:デフォルトの名無しさん
22/04/15 01:12:09.01 eIDEFdSW.net
バカが安易に生ポインタ書き込みしないようにunsafeしないと使えないようになってるので大丈夫
99%以上の用途ではそんな低レベルなものは必要とせずとも大丈夫なようにRustはできている
ほとんどの人は実験目的以外で用いることがないだろう
925:デフォルトの名無しさん
22/04/15 05:59:27.92 cD2+6A2l.net
unsafeがあるから安心安全
926:デフォルトの名無しさん
22/04/15 07:12:23.73 +y13V7Hk.net
生ポインタが分からぬのに使えてるとか笑
927:デフォルトの名無しさん
22/04/15 08:32:18.47 nO4hXcis.net
CもC++もRustも使えるが
確かにRustでは他の多くの言語と同じく生ポインタを使って読み書きすることはないしその概念も不要だな
普通の言語ならばそのような抽象度の低いものを持ち出さずともプログラミングできるべきなのだろう
928:デフォルトの名無しさん
22/04/15 08:48:44.24 JbDqxHHs.net
生ポインタとかエッチ
929:デフォルトの名無しさん
22/04/15 09:01:04.46 /A+hDicd.net
参照の同一性比較するためにas *const _したことないんか？
930:デフォルトの名無しさん
22/04/15 09:08:45.73 OmyTBDUu.net
人間関係というか変な人を排除するのにRustっていい例があります。
うちの会社です。
C++使える人は仕事はできる（昔からやってるだけですが）んですが、人格に問題があり、とにかく後輩にはほとんど教えず
なにか聞かれると自分で調べろとか、そういうなにかと偉そうな人たちが多いです。
そんな中Rustのプロジェクトが立ち上がるとそれまでC++使ってた偉そうな人たちが見事にいないプロジェクトになり、非常に風通しがよいプロジェクトになっております。
お互いつらい目にあってきたからその反動ですごくお互いに親切に教え合う雰囲気。
逆にC++のプロジェクトは偉そうな人たちと社内で最も使えない人たちだけが残りまして廃墟になっておりますｗ
931:デフォルトの名無しさん
22/04/15 10:13:34.70 y5QQqJ15.net
理系の比較的頭の良い人が多い割に非生産的な仕事の多い分野は、非協力的で常にイライラしてる人が多い印象
オンプレのインフラとかC++なんかはまさにそうだね
932:デフォルトの名無しさん
22/04/15 12:27:18.13 4kmZAVVg.net
なんでも敵視するRust新兵隔離所、Rustの話しかしてないからRustに誘導されたら、真のRust使いが怒り出した
933:デフォルトの名無しさん
22/04/15 12:30:40.34 NclNSxVV.net
>>908
そして別言語の話しだすと「優れてるマン」が噛みついてくるｗ
934:デフォルトの名無しさん
22/04/15 12:44:28.39 k/yGxJzN.net
>>905
as * const は safe では
デリファレンスが unsafe なだけでポインタの比較はsafe
935:デフォルトの名無しさん
22/04/15 13:05:03.59 /A+hDicd.net
>>910
そうだよ
でも生ポインタというかアドレスが何か分かっていないとこのキャストが意味するところは理解できないでしょうし
それゆえ「生ポインタの知識は不要だし有害」は過言という主張です
936:デフォルトの名無しさん
22/04/15 13:17:15 k/yGxJzN.net
>>911
そりゃそうだね
937:デフォルトの名無しさん
22/04/15 16:25:15.14 ozQCMa2m.net
メロスは激怒した
必ず、かの 邪智暴虐 （ じゃちぼうぎゃく ） のRUSTを除かなければならぬと決意した。
メロスには生ポイントがわからぬ
938:デフォルトの名無しさん
22/04/15 16:35:16.39 UYa93qbN.net
生ポインタの知識は無くてもプログラムは書けるし、動くし、困るまでは、知らなくても良いんじゃないの？
939:デフォルトの名無しさん
22/04/15 17:23:21 k/yGxJzN.net
一皮むけば生ポインタ出てくるのはどの言語でもそうだしことさらrustだけ取り上げる理由もないとは
940:思うけど ポインタの知識が有害というのは言い過ぎ
941:デフォルトの名無しさん
22/04/15 18:39:04.53 ozQCMa2m.net
でもおまえdouble freeじゃん
942:デフォルトの名無しさん
22/04/15 23:07:48 w/iGrZ8Q.net
Rustの話は専用スレ立ててそっちでやれよ
943:デフォルトの名無しさん
22/04/15 23:46:20.49 qbrugoRS.net
>>917
Rustの話ではないぞ
double freeはRustでは起きない
Rustは全自動解放だからプログラマーが気にすることはない
944:デフォルトの名無しさん
22/04/16 02:03:12 d9aHN/wl.net
いまさらdouble freeが問題になる言語ある？
945:デフォルトの名無しさん
22/04/16 02:10:47 IW60Azsc.net
c++はstd::unique_ptrで使い回すようにしたららだいぶスッキリしたよ。
継ぎはぎ故の古い環境やオレオレツールが動くのも良い。
でもどっかでカバっと大規模に整理して欲しいと思ったりもする。
946:デフォルトの名無しさん
22/04/16 06:37:22.84 Ynxy6YP5.net
pythonってそんなに世の中で使われているかな？
単にエンジニアが好きと思ってるだけのような気がしなくもないのだが・・・
俺は嫌いだけどｗ
947:デフォルトの名無しさん
22/04/16 08:14:27 EdW3+kRq.net
寧ろエンジニア以外に受けているのでは？
948:デフォルトの名無しさん
22/04/16 08:17:27 1ORd5NzP.net
そのうち小学生の必須科目になりそう
949:デフォルトの名無しさん
22/04/16 09:04:49.24 teyv0kaV.net
「 全自動解放だからプログラマーが気にすることはない 」そんな訳ない、Rustでも自分でカスタムアロケータ書けば気にする
950:デフォルトの名無しさん
22/04/16 12:15:02.24 cvz/IVkr.net
Pythonの何でもかんでもベクトル演算縛り他の言語始めるとき悪影響だよな
951:デフォルトの名無しさん
22/04/16 16:00:51.37 HzTWzZVk.net
pascal じゃなく python ？
pascal は言語理論上の基礎の上に載ったしっかりした文法だが python のような出鱈目文法が今はウけるのか？
世も末としかいいようがない…
952:デフォルトの名無しさん
22/04/16 16:23:00 7TENBOhS.net
LL(1)がそんなすごい話だっけ？
953:デフォルトの名無しさん
22/04/16 17:15:40.83 Tmn9GDW2.net
>>923
ベーシックよりはマシかと。
954:デフォルトの名無しさん
22/04/16 18:18:48 HzTWzZVk.net
>>927
そのような基盤にすら載らない言語が跋扈するなんて世も末かと
955:デフォルトの名無しさん
22/04/16 18:23:19 rBRO4aI9.net
>>929
意味解析しないと構文解析できないCとかいう言語が跋扈してる時点ですでに世界は終わっているよ
956:デフォルトの名無しさん
22/04/16 18:58:19 d9aHN/wl.net
クククLispが世界を支配する日は近いぞ
957:デフォルトの名無しさん
22/04/16 19:01:07 Ynxy6YP5.net
>>931
残念ながら・・・
そろそろC++++とか出ないのか？ｗ
あ、C#かｗ
958:デフォルトの名無しさん
22/04/16 19:42:31.25 6xv6jabx.net
>>924
嘘つき
アロケータを自作しようが標準のを使おうが
そのことには全く影響されずに自動で解放されるぞ
959:デフォルトの名無しさん
22/04/16 20:32:01.07 G/CUq+lM.net
じゃあなんでRustは学習コストと難易度が高いのですか？
960:デフォルトの名無しさん
22/04/16 20:51:06.94 D0HU54VV.net
Rustに手を出してみたが特に難しいことは無かったな
むしろ洗練されたわかりやすい言語だと感じた
その上で必要ならば細かいことにも手が行き届く感じ
961:デフォルトの名無しさん
22/04/16 22:40:46 hJU9sS6g.net
洗練と言うのは一人だけだからわかりやすい
962:デフォルトの名無しさん
22/04/16 23:21:57 3G5k9Hnh.net
>>933
嘘つき、deallocで実際に解放しなければ解放されるわけないだろ、死ね詭弁論者
963:デフォルトの名無しさん
22/04/16 23:59:23.94 rBRO4aI9.net
>>937
それ、「freeを呼べばメモリが解放される」って主張にたいして
「メモリ解放しない独自実装のfreeならメモリリークする」って反論するようなもので
論理
964:的には正しいけど意味のない主張だよね
965:デフォルトの名無しさん
22/04/16 23:59:50.03 G/CUq+lM.net
でも君たちRust書いたとてIT土方のままだよね
966:デフォルトの名無しさん
22/04/17 00:34:36.53 iAVEey/W.net
>>937
それは君が理解できていないからそんな主張になる
メモリの解放は3階層ある(GCでない場合)
(1) デストラクタによる解放 ←プログラミング言語の仕様で関係するのはここまで
(2) メモリアロケーターでの解放 ←例えばmallocに対するfreeの内部はここ
(3) OSへのメモリ解放 ←システムコールsbrkはここ
C言語は(1)がないため(2)のfreeをプログラマーが忘れず呼び出す必要がある
C++は(1)のデストラクタの記述と呼び出しにプログラマーの手動が一部残りうる
Rustはプログラマーが何もしなくてよい
967:デフォルトの名無しさん
22/04/17 00:45:36 xE2XgYmS.net
で？年収は？
968:デフォルトの名無しさん
22/04/17 00:46:21.20 xE2XgYmS.net
>>940
それ実質GCじゃん
969:デフォルトの名無しさん
22/04/17 00:54:39.19 10LdHAnc.net
>>942
Rustでプログラマーがメモリ解放しなくてよい点はGC言語に似ているけど
GC言語はガベージ(＝ごみ)が溜まっていって後でガベージコレクションを行なう必要があるのに対して
Rustでは即座に自動的にメモリ解放されるためC言語と同様に省メモリかつ高速というメリットがある
970:デフォルトの名無しさん
22/04/17 01:09:59.47 xE2XgYmS.net
>>943
細かく解放のオバヘッド乗るとか最悪じゃん
971:デフォルトの名無しさん
22/04/17 01:16:07.56 3NrKz2t8.net
>>944
CとC++とRust がその同じ方法だけど
いずれも超高速だよ
つまりGCするよりも即座に解放するのが正解と結論が昔から出ているよ
972:デフォルトの名無しさん
22/04/17 07:19:14 98II7f1E.net
>>944
普通はシステムコールする専用のスレッドを作ってそこで全部やるからオーバーヘッド無いよ
973:デフォルトの名無しさん
22/04/17 08:46:12.09 xE2XgYmS.net
嘘乙
システムコールだろうがGCallだろうが、CPUとメモリ使うから一緒だぞ
これだから物理を知らないソフト屋は
974:デフォルトの名無しさん
22/04/17 09:02:05.09 98II7f1E.net
バックグラウンドのシステムコールが問題になるような環境だと、それこそガベコレ動かしてる余裕など無いのでは？
975:デフォルトの名無しさん
22/04/17 09:50:03.49 MVCPXkPs.net
>>943
>>549
976:デフォルトの名無しさん
22/04/17 10:25:23.27 fCmr+50W.net
freeでsbrk走るとか本気で言ってるのか
977:デフォルトの名無しさん
22/04/17 10:28:31.82 sABjwZnn.net
>>944
どういう状況を想定するかにもよるけど、解放可能なオブジェクトを解放せずどこかに貯めておいて、
後からまとめて解放するような実装もできるよ
明示的に書かないといけないからちょっとめんどくさいが
978:デフォルトの名無しさん
22/04/17 10:33:33.77 fCmr+50W.net
解放可能なオブジェクトを解放せず後からまとめて解放するような実装を明示的に書く
それはもうGCなのでは？
979:デフォルトの名無しさん
22/04/17 10:44:39.16 JSPiPQVg.net
自分でやるかシステムに任せるかで違うと思うよ
自分でやるとバグが発生する可能性がある
980:デフォルトの名無しさん
22/04/17 11:09:06.02 wPmjz1Mj.net
現実にGC言語方式よりもC/C++/Rust 方式の方が圧倒的に速くて省メモリであると判明している
ただしCでは手動でメモリ解放しなければならないデメリットがありミスも多かった
そこでC++ではメモリ解放を一部自動化した
さらにRustではメモリ解放を完全自動化してミスもゼロとなった
981:デフォルトの名無しさん
22/04/17 11:10:30.80 aLAyt8HE.net
まるでメモリ解放以外のプログラムのミスは無いみたいな感じだよな
982:デフォルトの名無しさん
22/04/17 11:11:47.17 fCmr+50W.net
Rustコンパイラはメモリリークが発生しないことは保証しません
983:デフォルトの名無しさん
22/04/17 11:16:42.17 kfDvzEft.net
セキュリティで問題となる多くはメモリ関連が起因している
984:デフォルトの名無しさん
22/04/17 11:17:28.40 zOCvtZTK.net
>>956
そんなの当たり前じゃん
一般的にコンパイル時点でメモリリークを検出することは論理的に不可能
だからRustコンパイラはメモリリークが発生しないことを保証できない
これはRustの問題ではない
985:デフォルトの名無しさん
22/04/17 11:19:15.00 98II7f1E.net
わざとメモリリークさせているのか事故ってるだけなのかコンパイラは区別できないからな
986:デフォルトの名無しさん
22/04/17 11:29:57.34 MOkVW5s5.net
Rustでは循環参照以外ではメモリリークを起こさないことをコンパイラが保証できる
さらにRustでは循環参照をプログラマーが意図的に起こさない限り勝手に作られることはない
そのためプログラマーの意図せぬ循環参照は起きずメモリリークも起きない
現実問題としては長らくRustプログラミングしてきて実験テスト目的以外で循環参照を扱ったことは一度もない