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

[0001 デフォルトの名無しさん 2022/08/05(金) 08:26:38.87 ID:TpiqaUBm]

スレタイ以外の言語もok

前スレ
https://mevius.5ch.net/test/read.cgi/tech/1655771266/

[0002 デフォルトの名無しさん 2022/08/05(金) 08:37:03.30 ID:KgIsFrhc]

ワッチョイないから立て直し？

[0003 デフォルトの名無しさん 2022/08/05(金) 09:05:00.04 ID:b6gTveVP]

ここは歴代ずっとワッチョイ無しの自由な雑談ができる次世代言語スレ
あと特定の言語を排除しようとするおかしな人は無視していい

[0004 デフォルトの名無しさん 2022/08/05(金) 09:42:49.97 ID:/hLfNpmA]

ﾜｯﾁｮｲありスレはこちら

次世代言語27 Nim Zig Pony Carbon Gleam
https://mevius.5ch.net/test/read.cgi/tech/1659660050/

[0005 デフォルトの名無しさん 2022/08/05(金) 13:52:56.66 ID:U29UchoE]

新世代プログラミング言語 【日経Tech】
https://xtech.nikkei.com/atcl/nxt/mag/nc/18/042800230/042800001/
https://cdn-xtech.nikkei.com/atcl/nxt/mag/nc/18/042800230/042800001/01.jpg

21世紀に生まれた新しいプログラミング言語を採用する企業が日本でも少しずつだが増えている。
手軽にアプリケーションを開発する用途には不向きだが、システムプログラミングにおいては抜群の適性を発揮する。
新世代プログラミング言語の使いどころを、先進企業の実例を通してみていこう。

新世代言語が得意とするのは、大量のトラフィックを多数のプロセッサコアを活用して並行処理したり、
高速な処理を実現しつつメモリーを安全に管理したりするプログラムの開発だ。

米グーグルは2021年4月、AndroidOSの開発言語にRustを追加したと発表した。
これまでは主にC／C++を使っていた。Rustであればバッファーオーバーランなど
メモリー管理に起因するセキュリティー脆弱性が生まれにくくなる点を考慮して採用したという。
グーグルはLinuxカーネルの開発にRustを適用しようともしている。
米マイクロソフトも2019年、RustをWindows OSの開発に使用する研究を始めたことを明らかにしている。

Goはグーグルが開発を始めたプログラミング言語で、動画配信サービスのYouTubeや
コンテナ管理ツールであるKubernetesの開発に使っている。

[0006 デフォルトの名無しさん 2022/08/05(金) 19:29:36.02 ID:BU8XQp8V]

ここが新しいRustのスレでつか？

[0007 デフォルトの名無しさん 2022/08/05(金) 19:37:35.48 ID:+d0T8I82]

>>5
図がわかりやすくていいね

[0008 デフォルトの名無しさん 2022/08/05(金) 20:37:12.78 ID:/2EXcwTq]

>>6
さがっていろケンシロウ
みることもまた戦いだ

わたしの拳わたしの戦い方は
いずれ必ず
おまえの役に立つ時がくるだろう

[0009 デフォルトの名無しさん 2022/08/05(金) 20:40:03.72 ID:Z7rCc0jt]

>>5
設計図共有サイト、謎の半導体メーカー・エヌビディア！ｗｗｗ

[0010 デフォルトの名無しさん 2022/08/05(金) 22:17:43.36 ID:BMQn4j6g]

今からtsは要らないよな

[0011 デフォルトの名無しさん 2022/08/05(金) 23:40:01.91 ID:neUxGv7V]

>>10
そのこころは？
WASMが勢いつけてるから？

[0012 デフォルトの名無しさん 2022/08/06(土) 00:27:04.14 ID:VEv62Z69]

>>5
こんな記事に真面目にケチ付けても仕方ないけど、この面子ならC#は右上のグループだろう
最近のC#は非同期処理のパフォーマンスが極度に最適化されていて、Goに引けを取らない

[0013 デフォルトの名無しさん 2022/08/06(土) 03:44:12.91 ID:XeXelAmy]

>>10
WebブラウザでJavaScriptかWasmが必須だからTSは欠点あれど重要な位置を保つでしょう
Wasm by Rustだけでも行けるけど両者の異なる利点を両取りするハイブリッドが主流になると予想

[0014 デフォルトの名無しさん 2022/08/06(土) 05:46:10.00 ID:LQR5jobs]

>>13
もう「次世代」じゃないだろ。

[0015 デフォルトの名無しさん 2022/08/06(土) 05:59:09.03 ID:0/UjvMUm]

マルチスレッドで使えないからウェブアセンブリ意味ないじゃんっていわれてたけど解決したんかい？

[0016 デフォルトの名無しさん 2022/08/06(土) 10:17:41.69 ID:LLV93bqs]

>>5
Java C# より微妙に右に行ってるのは理由があってのことなのかね？

[0017 デフォルトの名無しさん 2022/08/06(土) 10:35:52.17 ID:WeMd0Hwa]

Rustがパフォーマンスも生産性も最強ならISUCONで全然使われてないってのは何でなの？

[0018 デフォルトの名無しさん 2022/08/06(土) 11:25:45.97 ID:aWQzwcS0]

生産性も指す範囲が認識違ってるからじゃない。
動くものを短い時間で作れるかじゃなくて、継続開発におけるメンテコストが小さくなるのが特徴なんでは。

[0019 デフォルトの名無しさん 2022/08/06(土) 11:37:56.35 ID:Zy70ULhC]

難解でスパゲティ化しやすいからメンテコストは上がると思う。

[0020 デフォルトの名無しさん 2022/08/06(土) 11:55:38.60 ID:rrIoMakq]

>>19
なぜ真逆のことを言うのかしら
例えばもしスパゲティしてるとRustコンパイラによってスパゲティを無くす方向に誘導されたり見通しの良いコードになりますよね
メンテコストが低く済むのも特徴

[0021 デフォルトの名無しさん 2022/08/06(土) 11:58:56.35 ID:Zy70ULhC]

>>20
従来のプログラミング言語より開発期間が延びることは、開発者も認めてる。

[0022 デフォルトの名無しさん 2022/08/06(土) 12:10:11.68 ID:JDezbopU]

GoがISUCONでは圧倒的みたいだけど、Goは素早くパフォーマンスが出るプログラムを作れるってことが証明されてるな
またGoは継続的メンテの生産性も非常に高い
グーグルのような大企業やKubernetesなどクラウド関連のツールで使われていることから証明されてる

継続メンテの生産性を上げるためにはコードの可読性が重要なわけだけどGoほど他人の書いたコードが読みやすい言語を俺は知らない
機能を削りまくってオーバーエンジニアリングを不可能にさせてるってのがかなり可読性に寄与してると思う
あと標準ライブラリが充実してるのも可読性あげてる
つまり生産性で最強なのはGo。

[0023 デフォルトの名無しさん 2022/08/06(土) 12:16:05.20 ID:XcW48Anf]

>>16
nikkeiにそういうの求めちゃダメだから

[0024 デフォルトの名無しさん 2022/08/06(土) 12:33:16.19 ID:Zy70ULhC]

Rustを流行らせようと頑張ってるのは、セミナー商法の人たちだろ。
成果なんか出ないから、長期にわたって相談があり、報酬が得られる。

[0025 デフォルトの名無しさん 2022/08/06(土) 12:39:09.16 ID:/NAfx8SK]

>>21
Rustは抽象的に開発効率よくプログラミングしやすいため開発期間は短くなってるな

[0026 デフォルトの名無しさん 2022/08/06(土) 13:27:01.16 ID:SGd1AFHA]

>>25
なんかデータあるんですか？

[0027 デフォルトの名無しさん 2022/08/06(土) 13:35:05.96 ID:hNQC/RRg]

逆効果になってる事をいまだに分からないバカ専用言語

[0028 デフォルトの名無しさん 2022/08/06(土) 13:51:00.45 ID:fIYdbcv5]

基本的にはプログラムは書いた通りに動く
想定を超えた効果が生じるという主張自体が、基本からかなり乖離している

[0029 デフォルトの名無しさん 2022/08/06(土) 14:04:55.90 ID:Zy70ULhC]

【世界】
https://trends.google.co.jp/trends/explore?q=%2Fm%2F0dsbpg6,%2Fm%2F09gbxjr,%2Fm%2F0jgqg

【日本】
https://trends.google.co.jp/trends/explore?geo=JP&q=%2Fm%2F0dsbpg6,%2Fm%2F09gbxjr,%2Fm%2F0jgqg

明らかに異常。

[0030 デフォルトの名無しさん 2022/08/06(土) 14:08:52.98 ID:TnfZT8O1]

>>29
"ストリーマー rust"
のトレンドと比較して相関を見ればハッキリとわかるけど、ゲームのRustに見事に引きづられてるだけだぞ

[0031 デフォルトの名無しさん 2022/08/06(土) 14:09:49.54 ID:Zy70ULhC]

統一教会が動員されてるのでは？

[0032 デフォルトの名無しさん 2022/08/06(土) 14:11:24.34 ID:Zy70ULhC]

>>30
プログラミング言語のRustと指定されてる。
絶対何か工作してる。
韓国面に落ちてる=＝統一教会の影。

[0033 デフォルトの名無しさん 2022/08/06(土) 14:12:15.10 ID:Zy70ULhC]

統一教会がセミナー商法で儲けようとして自民党の先生方とタッグを組んだってことでは？

[0034 デフォルトの名無しさん 2022/08/06(土) 14:17:36.29 ID:fIYdbcv5]

行き過ぎた金儲けは経済の失敗でしょ
エンジニアリングの失敗みたいに言うなよ

[0035 デフォルトの名無しさん 2022/08/06(土) 14:19:54.18 ID:Zy70ULhC]

Rustは世界で全く注目されない失敗言語。
日本でのみ注目されてるのは、何らかの工作がある。
統一教会の信者になっても、幸福にはならない。

[0036 デフォルトの名無しさん 2022/08/06(土) 14:22:09.40 ID:Zy70ULhC]

RustはC++のサブセットだから、普通は「C++でおｋ」ってなる。
それが世界標準。
日本だけ異常値を示すのは、何らかの事情がある。
統一教会とか統一教会とか統一教会とか。

[0037 デフォルトの名無しさん 2022/08/06(土) 14:28:25.57 ID:Zy70ULhC]

統一教会のマネー部門が「プログラミング教育必修化に伴う新規事業の立ち上げ」と関連して「Rustの国家言語化」を推進してるんだろ。

[0038 デフォルトの名無しさん 2022/08/06(土) 14:30:13.11 ID:Zy70ULhC]

「ファミリー」「世界」「みんなの」ってつく教材が出てきたら、統一を疑え。
全国の小中学生が統一の教科書で学ぶ異常事態。

[0039 デフォルトの名無しさん 2022/08/06(土) 14:36:06.27 ID:fIYdbcv5]

hello worldをhello 世界って書いたらアウトってことか

[0040 デフォルトの名無しさん 2022/08/06(土) 14:38:56.74 ID:k4A078eF]

安全性と可読性がトレードオフになるケースについてrust厨は全く考慮してないんだよな。

[0041 デフォルトの名無しさん 2022/08/06(土) 14:41:47.93 ID:Zy70ULhC]

それ以前に、メモリーでバグるのは初心者だけなので、戦力化した後は必要とされなくなる機能。
そこに全振りした言語が受け入れられるわけはなく、実際、世界では受け入れられていない。

[0042 デフォルトの名無しさん 2022/08/06(土) 14:45:08.37 ID:Zy70ULhC]

ちなみにわたくしはC++で書く時も、newとかdeleteとか、もはや書いていませんから。

[0043 デフォルトの名無しさん 2022/08/06(土) 15:03:35.78 ID:95xiI4eN]

>>40
可読性はRustが優れていると感じた
例えば前スレのこのRustのコードも他の言語のコードより読みやすい
https://gist.github.com/rust-play/f03d2e73ee4e76acf69c98b7a8b8d322

[0044 デフォルトの名無しさん 2022/08/06(土) 15:19:50.06 ID:LK6Z1Hbl]

>>43
全く同じことをしているのにoptimized.cやoptimuzed.cppの可読性が低いのはC/C++が原始的というか抽象度が低いためだろう

[0045 デフォルトの名無しさん 2022/08/06(土) 16:23:13.29 ID:OUo1sMqN]

Rust＝スパゲティ
でもメモリは安心

[0046 デフォルトの名無しさん 2022/08/06(土) 16:55:09.41 ID:SdbuTVvd]

こっちが本スレか

[0047 デフォルトの名無しさん 2022/08/06(土) 17:07:52.91 ID:n2+0u9Mg]

何故か、ここのスレでは銀の弾丸みたいに叫んでる人が目立っているのが、気になる。

[0048 デフォルトの名無しさん 2022/08/06(土) 18:11:23.30 ID:Zy70ULhC]

統一教会の信者さんが叫んでるだけでは。

[0049 デフォルトの名無しさん 2022/08/06(土) 18:32:09.80 ID:Zy70ULhC]

>>39
教科書にそんなもんぶっこんで来るのは統一教会くらいしかないからな。
サタンがどうとかメシアがどうとか、必修プログラミング教育にぶっこんできたら、99％統一教会と思え。

[0050 デフォルトの名無しさん 2022/08/06(土) 19:40:54.78 ID:dh8YGzDk]

なんか山上みたいなやつだな

[0051 デフォルトの名無しさん 2022/08/06(土) 20:38:42.34 ID:Snr/GczG]

なんか単なる手続き型から外れれば外れるほど流行らなくなるのを見てると初心者を取り込むことがいかに大事かということを考えさせられる

[0052 デフォルトの名無しさん 2022/08/06(土) 21:01:46.81 ID:fIYdbcv5]

銀の弾丸って単語だけ流行らせて
「人数を2倍にしても時間は半分にならない」って事実を教えなかったことを反省しろよ

逆に時間を何倍かにすれば猿が人に進化するのでは？

[0053 デフォルトの名無しさん 2022/08/06(土) 21:34:34.98 ID:95xiI4eN]

>>51
手続き型の方が分かりやすいと勘違いしてしまうのは手続き型で学習を始めた場合の初心者のうちだけで
次のステップでだらだらと手続き型で書くのは分かりにくく保守性も悪いと気付く
そして手続き型な部分を完全に排除してしまうと効率悪いことも理解できると最善に組み合わせたハイブリッドへ進む

[0054 デフォルトの名無しさん 2022/08/06(土) 22:22:50.50 ID:fIYdbcv5]

昔話では、正直者を完全に（排除ではなく）コピーするのが非効率と思い込んで
ハイブリッドへ進んでしまう物語が多い

[0055 デフォルトの名無しさん 2022/08/06(土) 22:26:51.83 ID:Zy70ULhC]

もう全部入りのC++でいいじゃん。

[0056 デフォルトの名無しさん 2022/08/06(土) 23:19:33.24 ID:Snr/GczG]

>>53
そうは言うけどもパラダイムを変えたりちょっとしたルールをつけ足したりすると途端にユーザーが減ってるように思うんだよな
プログラミングが暗にCを前提にしているというか

[0057 デフォルトの名無しさん 2022/08/06(土) 23:28:47.16 ID:LK6Z1Hbl]

>>55
C++は安全でないコードをコンパイラが通してしまい実行時に苦しむ古い言語
基礎がしっかりしていないのに増築を重ねて洗練されていない悪い言語

[0058 デフォルトの名無しさん 2022/08/06(土) 23:38:04.36 ID:95xiI4eN]

>>56
末端のユーザーなんてどうでもよい
自分たちがいかに全体(デバッグ時、メンテ時、実行時リソースなど含む)を効率よく出来るかが重要
様々な点で効率の悪い言語が簡単だからという理由で世間で普及していてもどうでもよい話

[0059 デフォルトの名無しさん 2022/08/07(日) 00:04:55.22 ID:ql1TgpH2]

>>58
その全体の環境を良くしていくのはその言語のユーザーたちで、結局頭数の多い言語が優位になると思うんだが
いやこの辺りは卵が先か鶏が先かみたいな所もあるけれども

[0060 デフォルトの名無しさん 2022/08/07(日) 00:15:54.62 ID:nCVSRdWl]

>>59
C++のように筋が悪いと
頭数の多さで色んな仕様拡張をしても
使われないものを増やすばかりで
環境も良くなっていないし優位にもなっていない

[0061 デフォルトの名無しさん 2022/08/07(日) 11:08:52.89 ID:wbukB5Xn]

次世代とスレタイあるのに何故今の言語を必死にアピールしてるのかね。
せめてその言語の将来のバージョンでの新機能とか廃止される機能について書けないのかね。

[0062 デフォルトの名無しさん 2022/08/07(日) 11:14:42.58 ID:xKkoyfCO]

次世代wと書くだけでおバカさんが爆釣だからに決まっとるやん

[0063 デフォルトの名無しさん 2022/08/07(日) 11:48:34.37 ID:kBhOCwz1]

隔離スレあるからRustアンチ装ってネガキャンしていいよね

[0064 デフォルトの名無しさん 2022/08/07(日) 11:49:29.82 ID:yn0NLwDm]

ジェネリクスを採用するか落とすか
実数クラスは複素数クラスを継承するか
この辺りで時間が止まってるのが現実

[0065 デフォルトの名無しさん 2022/08/07(日) 12:02:03.02 ID:r7YsBDkd]

C++はメタ言語でもあるので、言語設計者が使い方を決めるのではなく、ユーザーが使い方を決めるのですよ。

[0066 デフォルトの名無しさん 2022/08/07(日) 13:50:25.50 ID:6loH3/Cb]

今さらC++なんて古い言語を使うメリットが無い

[0067 デフォルトの名無しさん 2022/08/07(日) 14:19:10.56 ID:r7YsBDkd]

メタ言語なので、頭の良い人が使えば次世代を今使えるし、頭の悪い人が使えば昔のパラダイムで使うことになるのでは？

[0068 デフォルトの名無しさん 2022/08/07(日) 14:22:24.87 ID:r7YsBDkd]

そもそもRustはC++のサブセットなので、最終的にはC++を使いこなせるようになることを目指すのでは？

[0069 デフォルトの名無しさん 2022/08/07(日) 14:31:11.81 ID:IfZGncFx]

せやな頑張って極めてくれ

[0070 デフォルトの名無しさん 2022/08/07(日) 15:20:51.91 ID:r7YsBDkd]

おまえがな〜♪

[0071 デフォルトの名無しさん 2022/08/08(月) 02:39:57.76 ID:qWA0y/14]

>>68
サブセット？
C++コンパイラはメモリ解放とデータ競合の安全性を保証できるのてすか？

[0072 デフォルトの名無しさん 2022/08/08(月) 09:56:34.48 ID:O/c+BDEK]

>>16
Rustはまだ分かるがGolangがさらに右に行くのはおかしいな。

[0073 デフォルトの名無しさん 2022/08/08(月) 10:06:06.54 ID:oHs/K700]

最近のC#は値型のサポートが強化されていて、GCを避けたRust的なタスクもある程度カバーできるようになっている
少なくともGoよりは右だな

[0074 デフォルトの名無しさん 2022/08/08(月) 10:10:15.41 ID:jJMmsTXK]

あたりまえだけどGCはあった方がいいに決まってる
そんなにGCがないことが重要ならISUCONはみんなRustを使ってる

Webやサーバーサイドのプログラムは他にボトルネックがあるからGCの有無なんてどうでもいいんだよ
そんなの気にせず適当にかけたほうがよい
Rustは適当に書くことはできない
だから適していない

[0075 デフォルトの名無しさん 2022/08/08(月) 10:24:49.37 ID:oHs/K700]

GCが走ることで一時的にレイテンシが増大することがあるから、
安定したレイテンシでレスポンスを返すことが重要ならGCを避けることも検討する必要があるかもしれない
まあWeb程度ならプロファイル取ってGCに大きな負荷をかけている「極一部の」コードについて実装を修正するだけの話なので、
Rustに書き換えようぜとか言い出す極論馬鹿は無視してよい

[0076 デフォルトの名無しさん 2022/08/08(月) 10:30:03.58 ID:5wQFqA4Q]

適当に書けるか否かはGCの有無関係ある？

[0077 デフォルトの名無しさん 2022/08/08(月) 10:30:20.15 ID:5wQFqA4Q]

適当に書けるか否かはGCの有無関係ある？

[0078 デフォルトの名無しさん 2022/08/08(月) 10:30:32.39 ID:oZ9hPUlf]

>>75
現実にRustへ書き換えるケースが多い理由は
サーバコスト・クラウドコストの激減など様々な理由があります
特にRust利用によるコスト激減は大きいです

[0079 デフォルトの名無しさん 2022/08/08(月) 10:31:14.85 ID:5wQFqA4Q]

適当に書けるか否かはGCの有無関係ある？

[0080 デフォルトの名無しさん 2022/08/08(月) 10:37:54.22 ID:oZ9hPUlf]

>>74
GCがあったほうがよいとの主張を初めて見ました
GCは無い方が当然有利です

ただしRust登場以前はGC無しだとC/C++となりメモリ解放がプログラマーの責任となり複雑な場合は穴が発生しがちでした
今は自動メモリ解放されるRustがありますからGC無しでもそのような問題を避けられます

[0081 デフォルトの名無しさん 2022/08/08(月) 10:41:10.14 ID:/aBGPumi]

>>80
生産性のことを言ってるけど
C++やCをあらゆるプログラムで使う人ってなかなかいないよね？
RubyやPythonが流行ってたのはGC言語だからでは？

Rustはその流れに逆行してるのでC++やCを置き換えてもRuby Python. Node Goを置き換えることはないね

[0082 デフォルトの名無しさん 2022/08/08(月) 10:52:59.61 ID:/aBGPumi]

あとRust信者はGCを毛嫌いしているが最近はどんどん進化してる
コンピュータ側の進化に期待しないのはなぜ？

それに対してユーザーに責任を丸投げしてるのがRust
OSやドライバ開発者には良いが大半の開発者にとってそれは無駄な負担となる

[0083 デフォルトの名無しさん 2022/08/08(月) 11:14:27.79 ID:6lpblQL4]

>>82
ウソはよくないな
Rustの世界的な利用調査結果を見てもOSやドライバなんかではなく
圧倒的なRust利用トップがサーバーサイド／バックエンド分野

軽くて速くてプログラミングしやすいRustが使われる
そしてリソースコスト激減から反応性の良さまで恩恵を得られるのがRust

[0084 デフォルトの名無しさん 2022/08/08(月) 11:21:23.06 ID:lzv6yAzd]

スパゲッティRustは適当に書けないよな

[0085 デフォルトの名無しさん 2022/08/08(月) 11:30:43.29 ID:/aLuVjy4]

Rustで書くとスパゲティ化を防いで読み書きメンテしやすい良いコードになる利点もありますね

[0086 デフォルトの名無しさん 2022/08/08(月) 11:41:49.41 ID:Chuc2bn/]

>>78
クラウド利用料なんて大抵はDBが大半を占めるし、人件費に比べたら安いもんだよ
仮にAWS費用が月100万円として、そのうち20%がアプリのコンピューティング費用だとしよう
もしRustへの書き換えでコンピューティング費用が50%になれば月10万円の節約だ
単価200万の凄腕Rustプログラマが一ヶ月で作業したらペイするまでに20ヶ月かかる
そして以後もRustを使える高単価の人間を飼う必要があるわけだ
Rust信者としても、GC言語しか使えないプログラマよりも自分達の単価が大幅に高いことは否定したくないだろう？

[0087 デフォルトの名無しさん 2022/08/08(月) 12:02:17.62 ID:Og0DlKRv]

なんでもかんでもRustが良い、っていってるのはどうみても仕事経験の薄いキッズだろ
納得なんか不可能だから構うなよ

[0088 デフォルトの名無しさん 2022/08/08(月) 12:06:40.32 ID:6lpblQL4]

>>86
クラウドでDBのコストが高いのはRDB利用時だけだぞ
RDBはコストが高いだけでなくパフォーマンス面でも不利だから利用を最小限にする
そしてクラウド提供の安く高パフォーマンスの非RDBなDBを用いたり自前の非RDBなDBサーバをクラウドに構築
いずれにしてもRustが活躍する領域

[0089 デフォルトの名無しさん 2022/08/08(月) 12:07:15.97 ID:xzpYaZGN]

正直Rustの仕事なんて一度も見た事が無い
業務に使われている事が本当にあるのか？
少なくとも日本で採用するような会社殆ど無い気がする

[0090 デフォルトの名無しさん 2022/08/08(月) 12:11:11.88 ID:Chuc2bn/]

>>88
まさに仕事経験の薄いキッズだねえ

[0091 デフォルトの名無しさん 2022/08/08(月) 12:20:00.34 ID:TAwO3GZO]

>>81
RubyやPython以前にもGCあり言語はいっぱいあった。
ってかGCの有無で言えばGCあり言語のほうが数だけは多そう。
でもそれら全てが流行ったかというとそうでは無い。

[0092 デフォルトの名無しさん 2022/08/08(月) 12:28:08.43 ID:/aLuVjy4]

>>86
それDBサーバー費用が高くなっているは何でもかんでもSQLに押し付けているパターンの時ですよ
技術力のないところはそれで仕方ないでしょうけどそれは無駄で非効率ですから普通は可能な限りNoSQLにして費用を下げるとともに効率を上げます
SQLを使わない代わりにその様々な処理のコードを書くことになりますが最適化が出来るため高速化と費用激減の両方を得られます
そこで使われている言語はGC言語よりもRustが好ましいことは言うまでもないでしょう

[0093 デフォルトの名無しさん 2022/08/08(月) 12:34:17.42 ID:QO/dWc4g]

RustだけでなくNoSQLに幻想を抱くキッズ

[0094 デフォルトの名無しさん 2022/08/08(月) 12:35:55.92 ID:/aBGPumi]

じゃあISUCONでRust出て予選通過してみたらどうなの
100万円もらえるし学生でも優勝してたりするぞ

Rustキッズ頑張れよ笑

[0095 デフォルトの名無しさん 2022/08/08(月) 12:39:46.19 ID:/aBGPumi]

そんなにコストコスト気になるのに人件費を気にしないのはなぜ？
個人開発ならともかくRustキッズ曰くエンタープライズでバックエンドサーバーサイド分野で広まりまくってるらしいじゃん

[0096 デフォルトの名無しさん 2022/08/08(月) 12:40:30.24 ID:LL3uQ1oy]

Rustでエスケープ解析に触れない奴は勉強不足だから無視していいよ。

[0097 デフォルトの名無しさん 2022/08/08(月) 12:53:17.40 ID:Chuc2bn/]

十分な実務経験があってRust推す人はどちらかというとRDB好きな人が多い印象だな
RDBは固定長レコード時代の設計思想を色濃く受け継いでいて、
変なORMを噛まさずに正しく使えばクライアント側のメモリ管理が極めて効率的だからRustとは思想的な相性が良いと思うよ

[0098 デフォルトの名無しさん 2022/08/08(月) 13:01:54.54 ID:YWEH8Nnf]

Rustキッズも草だがISUCONキッズも草
二人ともまともな仕事探しなよ

[0099 デフォルトの名無しさん 2022/08/08(月) 13:04:26.73 ID:6lpblQL4]

>>97
大手ITの様々なサービスがなぜ非RDB利用なのか
クラウドでなぜ非RDBが提供されているのか
クラウドが提供するRDBの高コストなど現実を理解していれば
RDBの利用を必要最小限にした方が有利なことが理解できるだろう

[0100 デフォルトの名無しさん 2022/08/08(月) 13:10:53.01 ID:PVcyS4q4]

>>99
コストの問題じゃねーよw

[0101 デフォルトの名無しさん 2022/08/08(月) 13:11:12.07 ID:HxYRacQm]

好き嫌いで決めるもんじゃないでしょ

[0102 デフォルトの名無しさん 2022/08/08(月) 13:29:22.09 ID:GCEjPBap]

>>94
Rustで予選突破しましたという記事がすぐみつかるんたが…

[0103 デフォルトの名無しさん 2022/08/08(月) 13:31:44.99 ID:QO/dWc4g]

>>102
で、GCを使ってる言語の通過数と比較するとどう？
https://isucon.net/archives/56838122.html

[0104 デフォルトの名無しさん 2022/08/08(月) 13:51:44.39 ID:CLPoy81X]

Perlが1/5に対してRustは1/19

つまりPerlエンジニアの方がRustより強い

[0105 デフォルトの名無しさん 2022/08/08(月) 13:53:43.99 ID:/aBGPumi]

Goの半分ぐらい通過するようになってから普及してると言ってくれ

[0106 デフォルトの名無しさん 2022/08/08(月) 14:02:38.72 ID:/aLuVjy4]

競技プログラミングもISUCONも実際にある仕事と離れすぎていてゲームの範疇といった感じ
もちろんアルゴリズムを考え付き実装する能力やシステムの問題点を見つけ出し改善する能力は非常に重要だけど時間で競うものではないね
ましてやそこでの使用言語の状況に意味はないでしょう

[0107 デフォルトの名無しさん 2022/08/08(月) 14:08:02.05 ID:WrKjimA+]

何かと優劣付けたがる生き物っているけど
割と煙たがられてたイメージだわ

[0108 デフォルトの名無しさん 2022/08/08(月) 14:10:56.01 ID:MJuU9BY+]

>>103
煽ったつもりが単なる無知だったという話だから
そのあたりどうでもいいよな

[0109 デフォルトの名無しさん 2022/08/08(月) 14:16:32.02 ID:QO/dWc4g]

2019年のRust参加者は0組だったことを踏まえると、ISUCONでのRust利用者は異常にめちゃくちゃ増えてるから、これからどうなるかはわからんけどね
2019年はRustの参加者0組だった

[0110 デフォルトの名無しさん 2022/08/08(月) 14:17:03.91 ID:QO/dWc4g]

推敲するつもりが間違って送信してしまった・・・
https://isucon.net/archives/53789935.html

[0111 デフォルトの名無しさん 2022/08/08(月) 14:30:44.53 ID:z8XdWceR]

>>103
むしろそこにCもC++も無いのになぜ非GC言語からRustだけが参戦できているのか？が重要なところだ
Rustという言語がカバーできる領域の広さ強さを示している
過去にはC++での参戦もあったがC++は消滅したのもそれを裏付ける

あとISUCONではこの前までRustには参考実装すら用意されなかった
今はGoの参考実装から移植してくれる人のおかげで用意されるようになったようだ
とはいえど初期状態ではGoが起動といったように扱いに差がある
そのほか様々なハンデがありつつもRustはむしろ健闘しているといえる

[0112 デフォルトの名無しさん 2022/08/08(月) 14:34:47.89 ID:QO/dWc4g]

Goの利用者なんてもはやペチパーみたいなもんだし、本当にRustが強いというなら他言語利用者よりもダントツな通過率を見せてほしいものだ

[0113 デフォルトの名無しさん 2022/08/08(月) 15:28:50.47 ID:nLF3s4L3]

ISUCONよく知らんけど
言語の速度が直接影響を与えるような課題はまずないでしょ
しかしなぜそこまでGoが多いのか理解不能ではある

[0114 デフォルトの名無しさん 2022/08/08(月) 18:33:28.61 ID:sf8DoyKQ]

>>113
グーグルトレンド見ればわかる。
Rustユーザーは殆ど存在しない。
一方、Goはすでにメジャー言語のひとつになってる。

[0115 デフォルトの名無しさん 2022/08/08(月) 18:44:43.21 ID:YeAhfKJe]

>>114
なぜ>>103のISUCONで使用された言語一覧に
SwiftもKotlinもC#もC++もCも出てこないのに
なぜかGoやRustやPHPやPerlがあるの？？

[0116 デフォルトの名無しさん 2022/08/08(月) 18:48:36.68 ID:sf8DoyKQ]

>>115
ISUCONが何か知らないけど、キミの情報だけ見ると、アプリ用言語とウェブ用言語で使われる使われないが分かれてるように見えるよ。

[0117 デフォルトの名無しさん 2022/08/08(月) 18:51:02.17 ID:Ztz4OmA/]

勉強会と称して会社でセミナー開いて社員から参加料徴収してそう

[0118 デフォルトの名無しさん 2022/08/08(月) 18:57:37.93 ID:YeAhfKJe]

>>116
その分類だとGoやRustはどっちなの？
ウェブ用言語？

[0119 デフォルトの名無しさん 2022/08/08(月) 18:59:58.38 ID:sf8DoyKQ]

>>118
HTMLの次に手を出すのがJavascriptやRustじゃないかな？

[0120 デフォルトの名無しさん 2022/08/08(月) 19:06:15.39 ID:xzpYaZGN]

Goももう終わりそうな感じがするのだが
webでもAPI用途で使う分にはアリかも知れないがそこまで高速化がアプリで必要無いんだよね
ボトルネックは大体RDBとかだしPHPで十分なんだよね

[0121 デフォルトの名無しさん 2022/08/08(月) 19:06:45.72 ID:GdyVfCQX]

>>115
運営が実装を提供してる言語に限定されるからだよ

[0122 デフォルトの名無しさん 2022/08/08(月) 19:14:13.82 ID:sf8DoyKQ]

ウェブの人たちって信仰に篤いでしょ。
このスレのRust民の書き込み見る感じ、ウェブの人たちじゃないかなあと思うよ。

[0123 デフォルトの名無しさん 2022/08/08(月) 19:25:42.83 ID:U++CWrZh]

>>121
ISUCONでの使用言語は自由で制限なし
運営が需要から判断していくつかの言語で参考実装を提供するけど
それは無視して自分で自由にコードを書いてもよい
例えば以前はRustの参考実装は提供されなかったけどその時からRust利用での参加者はいた
ISUCONで使用する言語は任意であり各参加者が自由に選べる

[0124 デフォルトの名無しさん 2022/08/08(月) 19:29:52.39 ID:vqcSUYjk]

>>120
PHPはないわ
Typescriptならともかく

今時型推論のある静的言語以外ありえないわけだよ
PHPなんてゴミは早く撲滅しないといけない

[0125 デフォルトの名無しさん 2022/08/08(月) 19:35:28.21 ID:sf8DoyKQ]

でも、ウェブで一番使われてるのがPHPでは？

[0126 デフォルトの名無しさん 2022/08/08(月) 19:38:38.94 ID:Ztz4OmA/]

ワープレな？

[0127 デフォルトの名無しさん 2022/08/08(月) 19:42:30.46 ID:xzpYaZGN]

>>124みたいな型を連呼する奴ってロクにプログラム組めないんだろうなぁ
現実的な話サーバーサイドにjsも無いけどTSとか余計に無いｗ
こんなトランスパイル前提の言語なんて確実に消えるから
PHPすら扱えないならこの板来るなよｗ

[0128 デフォルトの名無しさん 2022/08/08(月) 19:47:48.61 ID:vqcSUYjk]

>>127
C10k問題知ってる？Nodeが流行った理由が非同期プログラミングに強いことだけど
何でトランスパイラ前提だと消えるんだ？

そんなことより動的型でPHPだとまともに保守ができないゴミプログラムが生産されるだけ
まさにゴミそのもの

[0129 デフォルトの名無しさん 2022/08/08(月) 19:54:31.05 ID:vqcSUYjk]

そもそもRubyやPHPみたいな動的型付け言語が流行った理由ってのは
C++やJavaだと変数の宣言ですら型定義が必要で面倒臭いところ
それに対して最近では静的型付けも進化して型推論装備が当たり前となった
これに伴い簡単に扱えるため動的言語をあえて使うメリットも無くなった
Pythonとか型ヒント機能を追加して静的型付けの特徴も取り入れてることから
今時動的型付けなんて時代遅れだということがわかる

型ヒント追加したなんちゃってPHPよりTypescriptやGoやRustの方が生産性は高い
新規プロジェクトでPHPなんてどこも採用してないわ

[0130 デフォルトの名無しさん 2022/08/08(月) 20:20:36.46 ID:xzpYaZGN]

うわコイツ絶対仕事してないわｗ
普通にサーバーサイドはPHPが一番多いし
お前どこの世界にいるの？ｗ
型連呼する奴は仕事していない事が良く分かるｗ

[0131 デフォルトの名無しさん 2022/08/08(月) 20:38:48.95 ID:vqcSUYjk]

時代の流れについていけないPHPおじさんw

[0132 デフォルトの名無しさん 2022/08/08(月) 20:46:44.42 ID:xj88ZuYt]

昔ながらのLAMP環境ならそりゃPHPしかないよね

[0133 デフォルトの名無しさん 2022/08/08(月) 21:28:14.57 ID:DIxb8BnQ]

>>94
isuconみたいに瞬発力重視のコンテストでRustで参戦するとか狂気な気はするんだよな。
納期の縛りなくベストを尽くすならいい言語だよ。

[0134 デフォルトの名無しさん 2022/08/08(月) 23:43:42.79 ID:bVB3HabO]

自社サービスなら比較的コードと密になるNoSQLの判断も可能やけど
SI案件だと無責任すぎてキャッシュ以外には導入躊躇するよ

[0135 デフォルトの名無しさん 2022/08/09(火) 00:24:19.37 ID:Plwa9BCw]

当然だけどRDBMSの上位互換なNoSQLなんて存在しないしケースバイケースだよ
用途にジャストフィットするなら採用を検討すればいいけど、
ノウハウがないなら耐久試験や障害復旧のシナリオテストなんかもしたいし、かなり時間がかかるね

そもそもRDBでは実現困難なものがあるからそういうのでは使うべき
Redisにあるデータ構造が必要ならRedisを使うし、全文検索が必要なら検索エンジンを使う
RDBで十分なのに無理やりNoSQLをなんでもかんでも使おうとすると、正規化やトランザクション処理が得意なRDBと違って、データが冗長になったりロック処理でわけわからんくなる
あとコストについても、速度がウリなmemcachedやRedisなんかは全部メモリに載せないといけないから大量データを処理するとメモリバカ食いになってメモリたくさん積んだマシンが必要になる
そこも結局はトレードオフだ

[0136 デフォルトの名無しさん 2022/08/09(火) 01:32:01.59 ID:gtiGofbP]

>>89
トヨタとかいう地方にある会社で募集してたらしいぞ

[0137 デフォルトの名無しさん 2022/08/09(火) 07:45:51.86 ID:rWBkFnPj]

既存システムは過去資産からPHPが多いね。
でもまぁ過去に安易に書いちゃってたから、うちの他部署もバージョンアップするのに苦労してるわ。動的言語はダメだなと思った。

[0138 デフォルトの名無しさん 2022/08/09(火) 09:09:16.70 ID:xpcAQEM+]

アップデートってバージョン0からバージョン100に飛んだ方が安上がりだよな
1ずつ増やしてたらコスト100倍

[0139 デフォルトの名無しさん 2022/08/09(火) 11:13:57.93 ID:IRkfDrb4]

rust案件、なくはないがこれ明らかに前任者が逃げ出したなって案件ばっか。

[0140 デフォルトの名無しさん 2022/08/09(火) 11:16:03.77 ID:HlyJMO/P]

新規はいいが保守案件なんて誰がやりたがるんだろう
お前らやりたいか？

[0141 デフォルトの名無しさん 2022/08/09(火) 11:33:50.25 ID:MRbKMm0e]

>>139
そんな嘘を付いてまで逆恨みしている理由を知りたい

[0142 デフォルトの名無しさん 2022/08/09(火) 11:39:41.66 ID:IRkfDrb4]

>>141
現実を見ましょう。
ttps://jp.indeed.com/Rust%E8%A8%80%E8%AA%9E%E9%96%A2%E9%80%A3%E3%81%AE%E6%B1%82%E4%BA%BA?vjk=31e817738ecb93b4

[0143 デフォルトの名無しさん 2022/08/09(火) 11:48:22.42 ID:oe9CXP3N]

Rustの引継案件はやりたくないな
今では誰も使ってない変なライブラリだらけになってそう
Goなんかはその点では古くなりにくいよね

[0144 デフォルトの名無しさん 2022/08/09(火) 11:50:05.69 ID:8voMgtSF]

>>142
Rustの求人多いんだな
高給でいいな

[0145 デフォルトの名無しさん 2022/08/09(火) 11:52:09.51 ID:tyWaLZiX]

型付けって、静的動的よりも強いか弱いの方が重要じゃないの？

[0146 デフォルトの名無しさん 2022/08/09(火) 11:54:00.44 ID:tyWaLZiX]

>>144
かなり高待遇だけど、こんな高待遇じゃないと、人来ないって事？

[0147 デフォルトの名無しさん 2022/08/09(火) 12:08:34.66 ID:oe9CXP3N]

業務委託だからこんなもんでしょ

[0148 デフォルトの名無しさん 2022/08/09(火) 12:09:53.05 ID:yNLec7bJ]

>>146
Rustは高速かつ安全で保守性もよいためその認識と需要が広まりつつある
リソースコスト削減となる点と需給バランスにより今後も高給の傾向が続くだろう

[0149 デフォルトの名無しさん 2022/08/09(火) 12:13:30.83 ID:OiwkcGrC]

フリーランスで業務委託って責任負わせるって事か？ｗ
準委任しかやってられんよｗ

[0150 デフォルトの名無しさん 2022/08/09(火) 13:28:04.16 ID:SUUVydRq]

PHP使ってもいいけど型明示しとけ。

[0151 デフォルトの名無しさん 2022/08/09(火) 13:54:44.47 ID:xpcAQEM+]

整数は整数と明示したいが32ビットとか64ビットとか明示したくない
そこで型名をTとする

[0152 デフォルトの名無しさん 2022/08/09(火) 14:00:22.05 ID:/NVuMDrB]

>>149
おまえ業務委託も知らんのかw
そんくらいは勉強しとけ

[0153 デフォルトの名無しさん 2022/08/09(火) 14:24:45.63 ID:tyWaLZiX]

>>147
こんなフワッとした内容で業務委託とか、振る方も受ける方も怖くない？

>>148
大手以外、メリット出すの難しそうだね。スタートアップとか大手とか、開発得意にいているところ向けなんかね？

[0154 デフォルトの名無しさん 2022/08/09(火) 14:29:29.55 ID:rviNpZ1q]

>>153
小規模なところはcrypt関係みたいに速度が最重要でもなければ技術力があってもメリットでにくい

今なら技術力アピールになるというメリットはある

[0155 デフォルトの名無しさん 2022/08/09(火) 18:40:37.50 ID:oM0lzHLp]

それ以前に、Rustの案件ではない。

[0156 デフォルトの名無しさん 2022/08/09(火) 19:34:23.64 ID:lYYrXFKS]

>>120
単語カウントのベンチで実はPHPがめちゃくちゃ速いことがわかったけどWeb系の人はそこには何も言わないのな
あれはマジで予想外だった
スクリプト言語最速と言われるV8と五分だった

[0157 デフォルトの名無しさん 2022/08/09(火) 19:38:57.62 ID:oM0lzHLp]

Rustより速かった。

[0158 デフォルトの名無しさん 2022/08/09(火) 21:03:55.36 ID:xpcAQEM+]

シェルスクリプトでは、Cと同じ速さのコマンドがあるのは常識で分かる
だがそれを他のスクリプト言語で真似したら多くの人が認知的不協和に陥る

[0159 デフォルトの名無しさん 2022/08/09(火) 21:05:46.33 ID:tnSRgX+g]

>>156
速くても生産性の観点で論外
静的型付け以外うんこ

[0160 デフォルトの名無しさん 2022/08/09(火) 21:06:10.39 ID:tnSRgX+g]

あと非同期プログラミングがまともにできないのでゴミ

[0161 デフォルトの名無しさん 2022/08/09(火) 21:10:47.11 ID:EZ4MxSsh]

大手で素のPHPが選ばれないのはメンテナンス性が低いから
PHPが7以降速いのはある程度やってる人なら知ってるよ

[0162 デフォルトの名無しさん 2022/08/09(火) 21:21:08.54 ID:qPgdF1zn]

>>159
じゃあお前はシェルスクリプトも使わないのかよ

[0163 デフォルトの名無しさん 2022/08/09(火) 22:06:42.97 ID:tnSRgX+g]

>>162
使うわゴミ
ただしシェルスクリプトはちょっとしたものしか使わない

PHPはちょっとしたものも大規模なソフトウェアでもどちらでも話にならない

[0164 デフォルトの名無しさん 2022/08/09(火) 22:59:20.68 ID:H83BYiRN]

正直、Cに型は無いようなもんだしな。

PHP良いぞ。単ファイル単機能で作ったら保守性もそこまで下がらん。
あれはHTML返すから地獄になる。

そもそも本当にPHPやってる会社は静的解析ぐらい内製してるでしょ。

[0165 デフォルトの名無しさん 2022/08/09(火) 23:16:15.02 ID:oM0lzHLp]

これからはキャストの時代ですしね。

[0166 デフォルトの名無しさん 2022/08/10(水) 01:05:45.94 ID:EEq1efXU]

>>164
metaくらいしかPHPやってないってこと？

[0167 デフォルトの名無しさん 2022/08/10(水) 01:38:00.37 ID:BY9mJTpO]

facebookは型付きの独自PHPを実装してそれ使ってるらしいからね
過去の資産が多すぎてそうするしかなかったのだろうけど

[0168 デフォルトの名無しさん 2022/08/10(水) 01:48:08.23 ID:uIeHvMMb]

PHPを開発に使ってる会社って事業初期に大量のPHP資産が作られてメンテせざるを得ない会社、っていうイメージしかない

[0169 デフォルトの名無しさん 2022/08/10(水) 02:23:41.34 ID:nT9pe/lB]

ウェブって、当たるも八卦当たらぬも八卦だから。
PHPで始めるのは合理的。
PHPは速いので、当たった場合もリファインまでの時間を稼いでくれるし。

[0170 デフォルトの名無しさん 2022/08/10(水) 03:05:15.44 ID:3IeIylSZ]

YouTube で有名な雑食系エンジニア・KENTA が、PHP, Scala をオワコン認定した。
これにより、優秀なプロが使わなくなるので、
ZOZO はLaravel だけど今後、良い開発者を集められなくなる

TIOBE の5つの絶滅する言語が、Ruby, Haskell, Objective-C, R, Perl

PHP, Scalaは、これに入っていなかったのに、KENTAに認定された

KENTAの天敵・SES のモローも、Rubyはオワコン、
これからは、Java, PHPの時代と言っていたが、
下の動画では、Railsのキャリア相談まで始めたw

【2022年版】Ruby on Railsの将来性
www.youtube.com/watch?v=YWKxh3KoNsY

日本では益々、Rails 1強へ進んだ。
でも外人でも、試作品をJavaScript で8週間掛かったのが、
Railsで2週間で作れたという香具師もいる。
サーバーをJSで作るのは馬鹿らしい

上場して時価総額1兆円のGitlab も、Railsを使い続ける宣言をしている

[0171 デフォルトの名無しさん 2022/08/10(水) 03:08:04.53 ID:nT9pe/lB]

HaskellはRustと同じコンセプトだから廃れないだろ。

[0172 デフォルトの名無しさん 2022/08/10(水) 03:43:44.42 ID:nT9pe/lB]

HaskellとRustは紙一重。

[0173 デフォルトの名無しさん 2022/08/10(水) 05:49:31.44 ID:i8JPdX8W]

>>161
>>169
PHPは遅いだろ
この前の単語カウントのベンチでもC++より5倍以上も遅かった

> 0.27 C++
> 1.40 PHP

[0174 デフォルトの名無しさん 2022/08/10(水) 07:15:25.76 ID:nT9pe/lB]

商用はZend Server使うので、滅茶苦茶速いっすよ。

[0175 デフォルトの名無しさん 2022/08/10(水) 07:54:12.37 ID:i8JPdX8W]

>>174
ベンチでも使われた普及しているphpはZend Serverと同じZend Engineが使われている

[0176 デフォルトの名無しさん 2022/08/10(水) 08:22:36.36 ID:rcQfSgy+]

待望の新言語

オブジェクト崇拝は罪！ 古ヘブライ文字で記述する創世的プログラミング言語が降臨
そこはかとなく神聖な感じのするソースコードがやんごとない
https://forest.watch.impress.co.jp/docs/serial/yajiuma/1431426.html

[0177 デフォルトの名無しさん 2022/08/10(水) 08:26:31.40 ID:LYpt5XQN]

>>176
オブジェクト指向ではない理由が
「偶像崇拝は禁止されている」
ってのがいいね、徹底してるわw

[0178 デフォルトの名無しさん 2022/08/10(水) 09:35:03.01 ID:bxuLoLIR]

>>168
そういうのはわりと仕様がシンプルだから全リニューアル難しくないし
余りに酷い作りだったら全リニューアルすればいいんじゃないかと思う

[0179 デフォルトの名無しさん 2022/08/10(水) 10:02:39.54 ID:bLf0UnoD]

確かに、ペチパーって難しいシステム構成をやりたがらないから、意外とPHP資産って扱いやすいんだよね
過去にSIerが入って無茶苦茶になったシステムに比べたら遥かにマシ

[0180 デフォルトの名無しさん 2022/08/10(水) 10:10:18.14 ID:bxuLoLIR]

その点で言うとJavaとかRubyで組まれたものがわりと厄介

[0181 デフォルトの名無しさん 2022/08/10(水) 10:21:20.47 ID:bLf0UnoD]

そうそう、それなりに頭使って真面目に作られた、しかし複雑さを制御できるだけのスキルが開発者にないシステムが一番厄介なんだよねえ
難しいものを難しいまま実装して変なデータ連携が大量に生じ、そのくせ目的は正しいことが多いから業務と切り離せなくなる

[0182 デフォルトの名無しさん 2022/08/10(水) 10:40:05.09 ID:bxuLoLIR]

Javaの場合標準ライブラリの設計が汚いからそれに習って作られてるシステム自体も設計が汚くてどうしようもないんだよなあ
オブジェクト指向が主流じゃない時代にようわからんヤツが指揮を執って無理やりクラス書いてたってのもあるだろうけど

[0183 デフォルトの名無しさん 2022/08/10(水) 12:42:08.99 ID:wdsDlMgu]

Rustをやり始めてわかったんだけど
一般的に設計が下手だとデータの依存関係がぐちゃぐちゃになりGC言語はそれでも通っちゃうのに対して
Rustで通すにはデータの依存関係を整理するのが一番の近道となるため良い設計にさせられしまう
結果的にRustで書いたコードはメンテナンス性も良くなるという良い副作用が

[0184 デフォルトの名無しさん 2022/08/10(水) 12:52:13.96 ID:ibGL2wT8]

それのどこがいい設計というの？

[0185 デフォルトの名無しさん 2022/08/10(水) 12:57:14.26 ID:h5nM35rr]

文盲か？
データの依存関係が整理されてるなら、そうでないやつよりいい設計と言えるだろ。
俺はRust使ったことないけどね。

[0186 デフォルトの名無しさん 2022/08/10(水) 13:01:14.16 ID:OAjuzVE6]

COBOLおすすめ

[0187 デフォルトの名無しさん 2022/08/10(水) 13:24:29.70 ID:v2DFTKIi]

依存関係がぐちゃぐちゃだとRustでは通らないというのはAがBに依存していてBがAに依存しているというような循環参照があるとRustでは通らないってこと?
循環がある複雑な設計ができないというのはメリットかもしれないけど、どうしても循環が必要な場合はRustは使えないってこと?

[0188 デフォルトの名無しさん 2022/08/10(水) 13:29:04.51 ID:bxuLoLIR]

>>187
共通部分Cを別に括りだしてAとB両方がCを参照するようにすれば大半の場合循環参照は回避できるはずだけど

[0189 デフォルトの名無しさん 2022/08/10(水) 13:46:25.86 ID:sNqQ8ycT]

GCは関係なさそう
無理矢理こじつけるならvirtualデストラクタに関係あるが
重要なのはvirtualの方だ

[0190 デフォルトの名無しさん 2022/08/10(水) 13:47:44.80 ID:cEafvHu4]

相当本人の設計レベルが低いんじゃ。。

[0191 デフォルトの名無しさん 2022/08/10(水) 13:51:24.78 ID:w+A7Q7I0]

>>187
Rustでもそういう互いに依存しあう形も可能だがその分だけ少しだけ複雑な型となる
つまりRustではそんな形を取るよりもスッキリと依存関係が整理された良いデータ設計をした方が書きやすい
そのためRustで書くと自然に良い設計のプログラムになるよう誘導される

[0192 デフォルトの名無しさん 2022/08/10(水) 13:56:50.60 ID:eN3aIK3B]

つまり、rustはenterprises向けではない

[0193 デフォルトの名無しさん 2022/08/10(水) 13:58:59.52 ID:uIeHvMMb]

RefCellとか使うと、実行時に借用チェックしてパニックが起きうるんでしょ？
そうするとRust使う意味がなくなっちゃうしな

[0194 デフォルトの名無しさん 2022/08/10(水) 14:00:14.32 ID:bxuLoLIR]

>>192
いうてもGoogleやMSやFBなんかは積極的にRust導入していくって言ってるしな

[0195 デフォルトの名無しさん 2022/08/10(水) 14:02:45.42 ID:sNqQ8ycT]

gotoはスパゲッティだがcomefromは良い設計という説がある
これを拡大解釈すると
traitとかinterfaceとかの実装側だけが依存関係を宣言するのはスパゲッティである

逆にエンドユーザー側から依存関係を列挙したい

つまり、追放されていたCの共用体の汚名返上をした方がいいのでは

[0196 デフォルトの名無しさん 2022/08/10(水) 14:06:25.83 ID:bxuLoLIR]

>>195
共用体はC++じゃなくCじゃなきゃダメな組込みやカーネルなんかの分野だといつでも現役だけどね

[0197 デフォルトの名無しさん 2022/08/10(水) 15:00:30.99 ID:B0kpAn2f]

>>195
Cの共用体は時代遅れの遺物。
例えばRustでは、排他データ共用であるタグ付き共用体＝ボディ付きenumと、同一データ共用であるtransmuteの、
役割の異なる二つの機能に分化され利便性も安全性も向上している。

[0198 デフォルトの名無しさん 2022/08/10(水) 16:04:48.53 ID:AhsVHkEa]

>>187
Weakとか使えば良いがこれまでみたいな雑な処理はまず無理
全てのデータの参照を完全に頭の中で再現できる設計にしなきゃダメ

[0199 デフォルトの名無しさん 2022/08/10(水) 16:38:38.42 ID:v2DFTKIi]

Rust使うかどうかに関係なく互いに依存しあうコードとかぐちゃぐちゃな設計は書かないでってみんなに呼びかければいいじゃん。

[0200 デフォルトの名無しさん 2022/08/10(水) 17:06:24.53 ID:ZFTliHm/]

プロトタイピングレベルだと設計なんて気にしてられない。
Rustはそういうのには使えんな。

[0201 デフォルトの名無しさん 2022/08/10(水) 17:57:07.65 ID:h5nM35rr]

いやいや設計のためにプロトタイピングするんだろ。
本来プロトタイプは捨てるのが前提だから。
捨てる前提だからRust使うまでもないのは同意で、それこそ動的型言語でさくっと作るのでもよい。

[0202 デフォルトの名無しさん 2022/08/10(水) 18:30:28.73 ID:F9/ptNap]

Rustで実用的なソフトウェアを作るにはC/C++の10倍の労力と注意深さが必要。

[0203 デフォルトの名無しさん 2022/08/10(水) 18:35:36.42 ID:JllE9vuQ]

>>201
違うよ。設計のためじゃなくて問題領域の情報収集のためにやるんだよ。
プロトタイピングの段階で設計を考えるのは「早すぎる最適化」の典型。

[0204 デフォルトの名無しさん 2022/08/10(水) 18:42:49.97 ID:tg6K1NO5]

>>202
むしろ静的型付け言語の中でRustはそのあたりについてかなり楽な言語やろ
注意深さなんて無くてもコンパイラが教えてくれる
コンパイル時点で問題を取り除いてくれるから労力も少なくて済む

[0205 デフォルトの名無しさん 2022/08/10(水) 18:45:06.71 ID:F9/ptNap]

実用的でメジャーなソフトウェアが皆無。

[0206 デフォルトの名無しさん 2022/08/10(水) 19:12:56.65 ID:jrkTB4/i]

linux

[0207 デフォルトの名無しさん 2022/08/10(水) 19:41:01.41 ID:sk3AyQrK]

>>204
「プロトタイピング」て知ってる？
「問題領域」て分かる？

[0208 デフォルトの名無しさん 2022/08/10(水) 19:54:14.10 ID:bxuLoLIR]

>>205
Firefoxめっちゃ使ってるんだけど
HTML、JSのデバッガとしてはChromeよりも遥かに優秀なんだがな

[0209 デフォルトの名無しさん 2022/08/10(水) 20:20:53.11 ID:ELagABQ4]

皆一体何と戦っているんだ

[0210 デフォルトの名無しさん 2022/08/10(水) 20:36:32.94 ID:1/irOBHJ]

>>205
Rustは実用的になったのがようやくここ数年だからまだ少ないと思うけど
逆にここ数年に出てきたものの中だとDenoとかTauriとかRust製が目立ってるかな

[0211 デフォルトの名無しさん 2022/08/10(水) 21:12:32.20 ID:NmnQYtNj]

Firefoxって、そんなにRustで置き換えられてる？
元が大きいのもあって、大して置き換わってなかったような。

[0212 デフォルトの名無しさん 2022/08/10(水) 21:15:46.69 ID:Kdr/lhnJ]

How much Rust in Firefox?
https://4e6.github.io/firefox-lang-stats/

[0213 デフォルトの名無しさん 2022/08/10(水) 21:47:08.63 ID:sNqQ8ycT]

>>209
むしろ個人と個人の戦いを回避したいから集団を作らせようとしている印象だが

[0214 デフォルトの名無しさん 2022/08/10(水) 21:56:02.90 ID:y2CjdAWq]

>>203
お前の言う設計は範囲が狭いな。逆に俺の言う設計は広くておおざっぱ過ぎるか？

[0215 デフォルトの名無しさん 2022/08/10(水) 23:16:30.22 ID:OAjuzVE6]

>>212
なんで安全のために全部Rsutに置き換えないの？

[0216 デフォルトの名無しさん 2022/08/10(水) 23:36:42.52 ID:sNqQ8ycT]

>>215
目的のためなら何でもするとは言ってないから
何でもするとかいう方針自体が全然安全じゃないから

[0217 デフォルトの名無しさん 2022/08/11(木) 00:11:49.77 ID:ZCQSRwpp]

Rustで書くと危険な部分もあるんですねえ。

[0218 デフォルトの名無しさん 2022/08/11(木) 00:25:31.63 ID:8gPi/LG+]

>>214
設計の範囲も狭いが
プロトタイピングという言葉の範囲がめちゃ狭いから噛み合わんのやろ

[0219 デフォルトの名無しさん 2022/08/11(木) 00:37:42.94 ID:5NB7ephI]

目的を固定すると危険しかない

[0220 デフォルトの名無しさん 2022/08/11(木) 00:55:10.26 ID:ScqLZwtD]

>>215
100と0しかない世界線の住人か？

[0221 デフォルトの名無しさん 2022/08/11(木) 02:27:09.28 ID:THycMkTK]

Cloudflare WorkersがC, C++, Rustに加えて
Python, Scala, Kotlin, Reason, Dartに対応したけど
Reasonなんて使ってる奴おるんか？
https://blog.cloudflare.com/cloudflare-workers-announces-broad-language-support/

[0222 デフォルトの名無しさん 2022/08/11(木) 02:53:54.65 ID:ZCQSRwpp]

>>220
Rustでは無理な部分もあるんですよ。
HTMLの仕様を読めばわかるけど。

[0223 デフォルトの名無しさん 2022/08/11(木) 03:13:46.61 ID:Sybzs6gH]

>>222
プログラミング言語によってHTMLを扱えたり扱えなかったりすることはありません

[0224 デフォルトの名無しさん 2022/08/11(木) 03:33:33.51 ID:ZCQSRwpp]

>>223
仕様書を読めばわかるんですけど、HTMLは相互参照の山なんですよ。
ですからRustには荷が重いというか、HTMLはRust殺しなんですよね。
これ、Rustが悪いのかHTMLが悪いのかというと、自分はHTMLの設計が古臭いと思いますね。
理論的にはRustの方が正しいと思います。

[0225 デフォルトの名無しさん 2022/08/11(木) 03:40:04.40 ID:ZCQSRwpp]

そもそも現在のHTML仕様はJSとC++を前提に書かれていて、その他の言語で取り扱うには、特有の事情を考慮しないといけないんですよね。
C#で取り扱おうとか、Javaで取り扱おうとか、そういうのはあまり問題ないんですよ。
C++同様、フルコースの言語なんで。
ところが、Cで取り扱おうとか、Rustで取り扱おうということになると、いろいろ考える必要がある。
これはいずれHTML仕様のほうを修正していくべきなんでしょうね。

[0226 デフォルトの名無しさん 2022/08/11(木) 03:48:44.40 ID:D5CYg6Pn]

それはHTMLというかDOMでは？

[0227 デフォルトの名無しさん 2022/08/11(木) 06:57:33.65 ID:/IbLiGYi]

>>225
初期のwebサーバーはCで組んでたけど、特に支障はなかったよ
何か勘違いしてないかい？

[0228 デフォルトの名無しさん 2022/08/11(木) 07:15:59.88 ID:CtVRnCBa]

Rustでちょっと複雑なことさせると
すぐスパゲティになっちゃうんだろうな

[0229 デフォルトの名無しさん 2022/08/11(木) 07:24:38.68 ID:pHX8OKOv]

>>225
C++が一番向いていない
C++でDOMを扱おうとすると参照カウント必須
そうじゃないと使われなくなった断片を回収できない

[0230 デフォルトの名無しさん 2022/08/11(木) 08:05:18.95 ID:4s9DVfCr]

>>229
参照カウントを使えばC++でも実現できるのだから全く問題ない
誰から参照されているのか一覧リストを管理するよりも参照カウントが一番軽い
カウントがゼロになったらメモリを解放できる

[0231 デフォルトの名無しさん 2022/08/11(木) 08:23:24.72 ID:BGDDy7T+]

こんな感じだと、Rust好き的には、まず現実世界をRustで扱いやすいように修正するところからだね～

[0232 デフォルトの名無しさん 2022/08/11(木) 08:34:02.44 ID:7v/bWlgJ]

>>227
彼はプログラミング経験があまりないいつもの妄想バカ
だからC++では扱えるけどCやRustや他の言語では扱えない！とかバカなことを主張している

[0233 デフォルトの名無しさん 2022/08/11(木) 08:52:59.49 ID:swhQx1y1]

>>230
それならC++以外の言語でも実装できてしまう
C++でしか扱えないって嘘じゃん

[0234 デフォルトの名無しさん 2022/08/11(木) 11:12:00.07 ID:AMWlPSdy]

>HTMLは相互参照の山なんですよ。
複オジなみのアホ迷言だなww

[0235 デフォルトの名無しさん 2022/08/11(木) 11:23:16.28 ID:9TqIqLGI]

C/C++のプログラム用のライブラリをRsutで書こうとするとグルーコードまみれになって危険と言いたいのか？

[0236 デフォルトの名無しさん 2022/08/11(木) 11:28:04.54 ID:vbpLy+Rh]

このスレに場違いなC++君がいつも頓珍漢なことを言ってるのは
叩き道具としてC++を持ち出しているだけであってC++でプログラミングしているわけではなく無知なため

[0237 デフォルトの名無しさん 2022/08/11(木) 11:29:28.19 ID:ScqLZwtD]

>>222
無理なところまでRust使う必要ないだろ？
なんで全部Rustでないとだめなのよ？
100と0しかない世界線の住人か？

[0238 デフォルトの名無しさん 2022/08/11(木) 11:34:46.22 ID:5NB7ephI]

効率的市場ってやつ？
0秒で100年先を織り込むという

[0239 デフォルトの名無しさん 2022/08/11(木) 11:35:01.03 ID:CYbTzNpy]

>>222 >>237
Rustで無理な部分なんて無いです
全部Rustで行けます

[0240 デフォルトの名無しさん 2022/08/11(木) 12:06:59.79 ID:iYrezZwU]

C++で枯れてるモジュールをRustなどで書き直す必要はないわな

[0241 デフォルトの名無しさん 2022/08/11(木) 12:16:07.83 ID:CYbTzNpy]

そういうこと
Rustに全て書き換えることは可能だけど
既にそういう状況にあるものを書き換える労力に意味はない
だからどこの企業やプロジェクトでも同じで新たなシステム改変部分からRust使用となっている

[0242 デフォルトの名無しさん 2022/08/11(木) 12:16:35.32 ID:7cUH/Z7I]

>>234
まあ、<a href="...">...</a> のことを言ってるならあながち間違いじゃないけど、プログラムから扱う話しとはあまり関係ないよね

[0243 デフォルトの名無しさん 2022/08/11(木) 12:31:23.76 ID:dNzT5Twj]

>>224
違いますRustの方が間違いです
doubly linked list作れない時点でまともな言語ではありません

[0244 デフォルトの名無しさん 2022/08/11(木) 13:03:40.31 ID:q4niyik3]

HTMLってw
またおじさんが知ったかで暴れてるのか
何回論破されて負けてもこの調子だし話にならんな
本物はさっさと消えてくれ

[0245 デフォルトの名無しさん 2022/08/11(木) 13:11:32.71 ID:3OHaebLi]

AWSがプログラミング言語「Rust」を使っている理由
https://japan.zdnet.com/article/35183866/

Amazon Web Services（AWS）は、同社のエンジニアたちがプログラミング言語「Rust」を
使っている大きな理由として、エネルギー効率の高さを挙げる。
AWSは早くからRustを採用し、Rust Foundationの創設にも携わった。
現在もRustの普及に熱心に取り組んでいる。

AWSのソフトウェアエンジニアで、Rustの普及に取り組む
Shane Miller氏と主任エンジニアのCarl Lerche氏の投稿によれば、
Rustはメモリー安全性を高め、セキュリティ関連の不具合を減らす役に立つだけでなく、
PythonやJavaよりもはるかに「エネルギー効率に優れている」という。
Amazonは、2025年までにデータセンターの100％を再生エネルギーでまかなうという目標を掲げ、
データセンターの環境負荷の軽減に取り組んでいる。
Rustの採用はその一翼を担うという。

Rustで構築されたAWSサービスの例としては、
コンテナーアプリ用のサーバーレスプラットフォーム「Lamba」を支える「Firecracker」、
「Amazon Simple Storage Service（S3）」「Amazon Elastic Compute Cloud（EC2）」、
コンテンツ配信ネットワーク「Amazon CloudFront」、
LinuxベースのコンテナーOS「Bottlerocket」がある。

「CやRustが他の言語よりもエネルギー効率に優れていることに驚きはない。
衝撃的なのは、その違いの大きさだ。CとRustを広範に採用すれば、
控えめに見積もってもコンピュートに使用されるエネルギーの量を50％削減できる可能性がある」と
Miller氏は述べ、その根拠として、C、GoogleのGo、Lua、Python、Ruby、Fortranなどをはじめとする
複数の言語のエネルギー効率を相対的に示した研究結果を紹介している。

[0246 デフォルトの名無しさん 2022/08/11(木) 13:57:53.80 ID:5NB7ephI]

弱参照の目的が「強参照のバグを回避するため」と誤解されてるんだな
生ポインタを安全にすることが目的だと思った方が現実に近い
unsafe生ポインタでできることは安全な弱参照でもできる

[0247 デフォルトの名無しさん 2022/08/11(木) 14:40:08.04 ID:9t95Zhl+]

>>194
ここで言うエンタープライズは、月数十万のバカにいつまでも確定しない要件を曖昧に実装させるような泥団子システムを作る業界のことだと思う。

Rustだとコンパイルが通らないからゴミを検収に出して時間稼ぐみたいなテクニックが使えない。

[0248 デフォルトの名無しさん 2022/08/11(木) 15:07:05.88 ID:6Sj50xSo]

>>245
そうか？いうほどFirefoxはエネルギー効率良くないです。なんやかんやいうても一番はOS標準搭載のブラウザーでmacOSならSafariでWindowsならEdgeです
いうほどFirefox常用してるけど早くもないし、終了時が重いのはやめてほしい

[0249 デフォルトの名無しさん 2022/08/11(木) 15:15:41.02 ID:1vyjl3kW]

Web開発でのデバッグ用途ならFirefoxの方が使い勝手がいい

[0250 デフォルトの名無しさん 2022/08/11(木) 15:18:20.72 ID:ZCQSRwpp]

>>229
その通りですが、仕様がC++向けに書かれているので、問題ないんですよ。
ご存じの通り、現在のHTML仕様は実装をそのまま仕様にするようなものなので。

[0251 デフォルトの名無しさん 2022/08/11(木) 15:19:27.76 ID:ZCQSRwpp]

ちなみに相互参照が多用されているので、参照カウントでは解決できないですよ。
そこがHTML仕様の厄介なところです。

[0252 デフォルトの名無しさん 2022/08/11(木) 15:30:14.14 ID:8SRrL23l]

>仕様がC++向けに書かれているので

この妄想の元ネタってなんなんだろうか。ちょっと気になる。

[0253 デフォルトの名無しさん 2022/08/11(木) 15:41:42.85 ID:7cUH/Z7I]

俺はちっとも気にならないのでよそでやって欲しい

[0254 デフォルトの名無しさん 2022/08/11(木) 15:56:07.13 ID:5NB7ephI]

任意の妄想を書き込み可能な脆弱性
に反応して脆弱性を突くだけの機械的なムーブなのでは

[0255 デフォルトの名無しさん 2022/08/11(木) 17:05:52.29 ID:Kd3rFp17]

>>245
AmazonもRust派なのかよ
AWSの各サービスが次々とRustで書かれているのか

[0256 デフォルトの名無しさん 2022/08/11(木) 17:25:03.43 ID:NtDJBq0Q]

GAFAMの中だとAmazonが一番Rust推しだと思う
MozillaのリストラのときもRust開発者大量に採用してたし

[0257 デフォルトの名無しさん 2022/08/11(木) 19:00:28.74 ID:X+IfO94A]

おちめのあまぞん

[0258 デフォルトの名無しさん 2022/08/11(木) 19:06:10.54 ID:cYo9lEj1]

>>245
エネルギー効率が高いって、もっとソフトウエア的にわかりやすくいうと何を表してるの？
同じことをやろうとしたときのCPUの演算回数とか？

[0259 デフォルトの名無しさん 2022/08/11(木) 19:29:30.88 ID:ZCQSRwpp]

Rust草創期、財団設立に関わったことで、引くに引けなくなってるのでは？
損切りできない体質は悲劇を招きますよ。
もっとも、一部門の話に過ぎないとは思いますが。

[0260 デフォルトの名無しさん 2022/08/11(木) 19:30:12.29 ID:K1VoPj4Z]

>>258
Rustは実行が速く省メモリで効率がいい
使用リソースが少なく済み
エネルギーも少なく済み
料金コストも少なく済む

[0261 デフォルトの名無しさん 2022/08/11(木) 19:33:35.06 ID:ZCQSRwpp]

>>258
アマゾンは一人一人に対して個別のHTMLを返すんですよ。
もちろん、JSで読み込むような部分もあるんですが、そういうのは広告のようなもので、価格の提示など本質的な部分はサーバ側でHTMLに組み込みます。
したがって電気代が大変でしょうね。
従来の産業では、製鉄所が自前あるいは共同の発電所を持つことが当たり前ですが、アマゾンも発電所をお持ちかもしれませんね。

[0262 デフォルトの名無しさん 2022/08/11(木) 19:36:26.39 ID:ZCQSRwpp]

>>260
Rustで実用的なソフトウェアを書くことは難しく、Rustの開発主体であるMozillaでさえ自身のブラウザの二割しかRustを適用できていません。
いまとなっては、失敗だったと認めざるを得ないでしょう。

[0263 デフォルトの名無しさん 2022/08/11(木) 19:40:30.56 ID:9TqIqLGI]

久しぶりにこのスレでNG使ったわ

[0264 デフォルトの名無しさん 2022/08/11(木) 19:41:50.30 ID:ZCQSRwpp]

https://trends.google.co.jp/trends/explore?q=%2Fm%2F0dsbpg6,%2Fm%2F05z1_,%2Fm%2F07sbkfb

世界でRustはすでにオワコン言語の地位を獲得しています。
オワコンの地位を獲得したころ、なぜか日本で書籍やセミナーが増えました。

[0265 デフォルトの名無しさん 2022/08/11(木) 19:43:48.57 ID:CtVRnCBa]

>>262
みんなそこまで言わないように気を使ってるのに…

[0266 デフォルトの名無しさん 2022/08/11(木) 19:45:33.11 ID:ZCQSRwpp]

はっきり言わないと、統一教会みたいに詐欺師がのさばりますよ。

[0267 デフォルトの名無しさん 2022/08/11(木) 19:47:57.82 ID:ZjpQa1eK]

>>259
Rust FoundationをGoogle・Microsoft・Amazonなどが共同で設立したのは昨年2021年2月ですが
あなたの言うRust草創期にAmazonがRustの財団の設立に関わったとはこのことを意味していますか？

[0268 デフォルトの名無しさん 2022/08/11(木) 19:50:22.88 ID:ZCQSRwpp]

>>267
ドッグイヤーと言われるIT業界ですからね。

[0269 デフォルトの名無しさん 2022/08/11(木) 19:53:31.47 ID:xU6QWn2b]

>>261
無知すぎて笑った
それはアマゾンの通販ページの話
アマゾンといっても>>245の記事に明記されているようにAWS (Amazon Web Services)つまり世界最大のクラウドサービスの話を他の皆がしている
AWSすら知らないで連投していて爆笑

[0270 デフォルトの名無しさん 2022/08/11(木) 20:01:54.70 ID:7cUH/Z7I]

>>258
まあざっくりその認識でいいと思う

[0271 デフォルトの名無しさん 2022/08/11(木) 20:15:26.31 ID:WVfR2Wgm]

まぁ日本ではPHPばかり使われるのがこのスレの流れでもわかるわ。
次のスレタイからは 次世代 の冠は外せよ。

[0272 デフォルトの名無しさん 2022/08/11(木) 20:24:34.40 ID:TxCQzsqx]

Rust叩きしてる人がいつもおかしなことばかり書き込むので素性を怪しんでいたけど、
クラウドのトップシェアのAWSを知らないとは驚いた。
そういう常識のない人がRust叩きしていたと分かり納得できた。

[0273 デフォルトの名無しさん 2022/08/11(木) 21:02:00.22 ID:PxUPmcND]

Rustは一部の天才向けの言語
AWSの開発者なんて一部の天才しかいない
大半の開発者はAWSを開発する側ではなく利用して問題解決をする側

後者の人間がRustを使いこなしてサービスを作れるわけがない

[0274 デフォルトの名無しさん 2022/08/11(木) 21:21:47.16 ID:5NB7ephI]

Webサービス音痴になっても言語まで音痴になるな！

[0275 デフォルトの名無しさん 2022/08/11(木) 21:58:11.55 ID:oTvjhPzi]

>>273
次世代言語の本命3つが公式サポートされたよ

AWSがついにRust、Kotlin、Swiftの公式SDKを導入
https://www.infoq.com/jp/news/2022/01/aws-rust-kotlin-swift-sdks/

Rust、Kotlin、Swift向けの新たなAWS SDKでは、AWS APIの固有のラッパーが提供される。
これにより、開発者がより使い慣れた一貫した方法でAWSサービスを操作できるようになる。

Amazonによると、各SDKは、各言語に共通のベストプラクティスを取り入れ、高度な言語構文を活用している。
たとえば、Rust SDKでは、非同期/待機、ノンブロッキングIO、ビルダーなどの最近の機能が使用される。
同じように、Swift SDKではSwift 5.5の同時実行機能が使用され、マルチプラットフォームがサポートされる。
さらに、Rust SDKは高速シリアライザーとデシリアライザーによって、
不要なコピーと割り当てを最小限に抑え、CPUとメモリの使用率を削減する。

[0276 デフォルトの名無しさん 2022/08/11(木) 22:20:00.16 ID:C2sFOKfB]

Rust叩きの人はRustは知らないを通り越して
なんにも知らない人が多いな

[0277 デフォルトの名無しさん 2022/08/11(木) 22:48:43.13 ID:ZCQSRwpp]

Haskellと同じ道を歩いてる。

[0278 デフォルトの名無しさん 2022/08/11(木) 22:57:05.95 ID:bLBgCb4P]

AWS Lambda がデフォルトで採用している言語は、
Java, Go
Node.js, Python, Ruby
C#, PowerShell

YouTube で有名な雑食系エンジニア・KENTA がオワコン認定した、
PHP, Scala は元から採用されていない

Laravel を使っているZOZO とか、Scala を使っているTwitter などは、
良い開発者が集まらないから、ヤバイ

AWS Solution Architect の米国年収が、
Ruby on Rails の1,300万円を超えて、1,400万円になった。
今は円安で、1,800万円まで高騰している

一方、Node.js は言語の平均の900万円。
Rails なら2週間で作れる試作品が、JavaScript で8週間掛かる

バグが多い・長時間掛かるなど、効率が悪いと年収が下がる

[0279 デフォルトの名無しさん 2022/08/11(木) 23:09:50.33 ID:ScqLZwtD]

>>277
AWSでHaskellサポートされたことあったっけ？

[0280 デフォルトの名無しさん 2022/08/11(木) 23:34:23.21 ID:5NB7ephI]

AIが過去に何度か失敗していて今回も失敗するという主張と同じ道

[0281 デフォルトの名無しさん 2022/08/11(木) 23:37:34.61 ID:ZCQSRwpp]

アメリカでオワコンになると日本でごり押しが始まるけど、どういう仕組みなんだ？

[0282 デフォルトの名無しさん 2022/08/11(木) 23:55:00.67 ID:oGx+Hztf]

>>278
それらの支援が必要な言語と異なり
C++とRustは自力でCustum Runtimeを実装できるし
AWSによっても提供されており問題なく使える

AWS Lambda C++ Runtime
https://github.com/awslabs/aws-lambda-cpp

Rust Runtime for AWS Lambda
https://github.com/awslabs/aws-lambda-rust-runtime

[0283 デフォルトの名無しさん 2022/08/12(金) 00:31:07.27 ID:KPbB5azj]

>>281
まず日本の原発が爆発する
次にアメリカはゴリ押しやめる
日本はゴリ押しを続ける

[0284 デフォルトの名無しさん 2022/08/12(金) 01:02:30.18 ID:J29cS/Aj]

ウェブサービスを作るのに、
C++ みたいなポインターとか、デバイスは関係ない

AWS とかウェブサービスなどは、
デバイスを抽象化して貸し出している層の話

[0285 デフォルトの名無しさん 2022/08/12(金) 01:12:39.99 ID:ijOecH2p]

アプリで通用しないからウェブへ逃げた言語のひとつでは？

[0286 デフォルトの名無しさん 2022/08/12(金) 02:03:25.74 ID:Pwp1hh6y]

>>284
AWS Lambdaにしても課金単位が使用メモリ✕時間なので
高速で省メモリなC++とRustが圧倒的に有利

>>285
そのアプリのサーバーサイドAPIがクラウド上などにありRustが有利
あるいはデスクトップ上での完結アプリだとTauriのようにメイン部分がRust

[0287 デフォルトの名無しさん 2022/08/12(金) 02:15:46.05 ID:NovzwVFL]

こんなことずっと言ってるのにまだコンテナエンジンさえまともに作れてないっていうね。。

[0288 デフォルトの名無しさん 2022/08/12(金) 02:33:18.95 ID:bDQmrk+5]

少なくとも次世代言語は動的型付言語じゃなく型推論のある静的型付言語だろうな。

[0289 デフォルトの名無しさん 2022/08/12(金) 02:49:37.47 ID:ijOecH2p]

Rustで出来てる有名なソフトって何？

[0290 デフォルトの名無しさん 2022/08/12(金) 03:29:00.86 ID:ES0c90Y+]

Node.jsより速くて色々と便利なDenoとか
Electronより速くてバイナリ生成も小さいTauriとか

[0291 デフォルトの名無しさん 2022/08/12(金) 03:34:06.83 ID:ijOecH2p]

Tauriって本体はWebkitかChromiumだろ。
Firefoxならまだしも。

[0292 デフォルトの名無しさん 2022/08/12(金) 05:24:48.42 ID:ijOecH2p]

人造人間11号用のアプリ作れる？

[0293 デフォルトの名無しさん 2022/08/12(金) 06:16:48.79 ID:KPbB5azj]

別に新興宗教を作らなくても伝統的なやつをコピーするだけでいいんだよ

[0294 デフォルトの名無しさん 2022/08/12(金) 07:17:38.32 ID:8aFEsxK9]

>>289
Unixコマンド

[0295 デフォルトの名無しさん 2022/08/12(金) 09:56:58.91 ID:XPcdhorI]

>>289
Linux

[0296 デフォルトの名無しさん 2022/08/12(金) 10:02:43.86 ID:4Mgm88NN]

LinuxのカーネルはCでしょｗ
肝心なところにRustなんて使われない

[0297 デフォルトの名無しさん 2022/08/12(金) 10:08:16.88 ID:25v3e0MP]

Rustは所有権システムのせいで他システムから移行するのがなかなか難しい
新規に作るならいいが既存システムをそのまま変えるのは厳しく構造を変えていかないといけない

[0298 デフォルトの名無しさん 2022/08/12(金) 11:32:56.40 ID:KPbB5azj]

人間同士の会話で詭弁と嘘をじゃんじゃん使う汚い手口を知ってるなら
Rustでもルールの抜け道を使って
PHP並みに汚い今まで通りの書き方ができるんだよ

[0299 デフォルトの名無しさん 2022/08/12(金) 12:29:18.76 ID:Oy5swSwT]

>>297
どんな言語でも既存システムそのまま別の言語へ変える労力はムダであり馬鹿げたプロジェクトとなる
一方でシステムを改変する機会に別の言語へ変えるのは問題ない

[0300 デフォルトの名無しさん 2022/08/12(金) 12:48:08.34 ID:c/mjoCjH]

>>299
おまえその手の仕事したことないだろw

[0301 デフォルトの名無しさん 2022/08/12(金) 12:58:53.09 ID:eVusMPKY]

>>247
検収する側としては、ソースにunsafeが入っていないかgrepして入ってたら検収しないとか、アホな事言うのも出てくるかもね。

最近も暴れてた人はRust擁護しているのかと思ったら、叩いてる方だったのか…

[0302 デフォルトの名無しさん 2022/08/12(金) 13:04:31.64 ID:/hoT7fNk]

既に動いてる一体的システムを改変なしに他の言語へ移すのは移行用の後継言語へ移す以外だとコスパ悪いからあまり行われないね

もちろんAPIで分離されている別システムなら話は別で高速化のためにC++やRustなど含めて自由に他の言語へ可能

[0303 デフォルトの名無しさん 2022/08/12(金) 13:13:52.69 ID:KPbB5azj]

参照カウントしないポインタが欲しいだけならunsafeではなくWeakを使う

[0304 デフォルトの名無しさん 2022/08/12(金) 13:19:20.77 ID:0xlDyyuc]

>>301
コーダーにunsafe使われたらRust採用する利点無いだろ。

そのあたりは優秀なライブラリ開発者に限定して実装させるんじゃないの？

[0305 デフォルトの名無しさん 2022/08/12(金) 13:37:01.57 ID:KPbB5azj]

自分が使いたい時に使うでしょ
自分が何をやりたいのかを他人に判断させるな

[0306 デフォルトの名無しさん 2022/08/12(金) 13:53:28.10 ID:0xlDyyuc]

>>305
ならRustは要らないなぁ。
Rustは他人に「自分が使いたい時に使うでしょ」なんて言わせないための言語だよ。
自分でコーティングするならc/c++で十分だわ。

[0307 デフォルトの名無しさん 2022/08/12(金) 14:04:45.01 ID:s5ItonLD]

何の話かよくわからないけど
不便な旧言語のままでいい人はそれで構わないんじゃないの？
もちろんC++は不便だからCarbonなどが出てきている
そしてCarbonの公式FAQにもあるようにあくまでも既存C++コードのためのものであってRustが使えるならRustの方が好ましいと明記されている

[0308 デフォルトの名無しさん 2022/08/12(金) 14:41:41.60 ID:KPbB5azj]

Javaの文化が歪んでいるのをRustに投影しているように見える

static変数が利用可能なのはstatic変数を使わせないためである
JNIが利用可能なのはJNIを使わせないためである

[0309 デフォルトの名無しさん 2022/08/12(金) 15:19:13.21 ID:UMYGy7UQ]

いい感じに隔離スレとして機能してるねココ

[0310 デフォルトの名無しさん 2022/08/12(金) 17:33:04.35 ID:ijOecH2p]

unsafeが利用可能なのはunsafeを使わせないためである

[0311 デフォルトの名無しさん 2022/08/12(金) 17:39:56.81 ID:KPbB5azj]

目的は何々であるという説には陰謀論レベルの信憑性しかない

[0312 デフォルトの名無しさん 2022/08/12(金) 17:58:30.16 ID:B8WuAqqn]

ScalaとかHaskell好きだけどねえ
初心者が使いこなすのは大変だから流行らないよね

[0313 デフォルトの名無しさん 2022/08/12(金) 18:40:09.03 ID:pHCKIPO9]

一定数に名前が知られている時点で流行ってると言って良いと思うよ

[0314 デフォルトの名無しさん 2022/08/12(金) 19:35:03.04 ID:8aFEsxK9]

Scala　vs Haske vs Rustみたいなスレを作った方がいいかもね

[0315 デフォルトの名無しさん 2022/08/12(金) 19:41:01.12 ID:mai+3JG0]

C vs C++ vs Rust だけでいいだろ
大方の興味はこの１点につきる

[0316 デフォルトの名無しさん 2022/08/12(金) 19:43:26.46 ID:ijOecH2p]

>>315
RustはC++のサブセットだから意味ないと思う。

[0317 デフォルトの名無しさん 2022/08/12(金) 19:50:24.38 ID:ijOecH2p]

>>312
初心者が何言っとる。

[0318 デフォルトの名無しさん 2022/08/12(金) 23:23:35.24 ID:3qV0/cHh]

Zig が存在するのに、なぜ他の言語でプロジェクトを開始するのでしょうか?

[0319 デフォルトの名無しさん 2022/08/12(金) 23:58:58.03 ID:P0zPe4di]

>>316
C++はデータ競合すらコンパイラが指摘できない

>>318
Zigは手動メモリ管理だから論外

[0320 デフォルトの名無しさん 2022/08/13(土) 00:30:17.86 ID:xQE0tEua]

そのとおりです。 Rust では、プログラムは常に malloc と free を呼び出します。 Zig では、メモリを最初に 1 回割り当てることができます。

[0321 デフォルトの名無しさん 2022/08/13(土) 00:46:50.18 ID:9pjJ9/xa]

Rust叩きしてる人はなぜいつも無知なのだろうか

[0322 デフォルトの名無しさん 2022/08/13(土) 01:03:17.60 ID:xQE0tEua]

Rust ユーザーが jemalloc を使用する必要があるのはなぜですか

[0323 デフォルトの名無しさん 2022/08/13(土) 01:57:28.21 ID:N+gF026L]

>>321
多数決主義じゃないかなあ
マイノリティの知識を利用できない

[0324 デフォルトの名無しさん 2022/08/13(土) 02:07:32.42 ID:yjuU6Mz4]

アホジャップが生産性低いのは
メタプログラミングできないとの
JIS配列でアホみたいな足枷はめられてるから
USキーボードでDvorak配列は当たり前

俺たちタイプライターの時代じゃなくて
コンピューターの時代に生きてるんだよな
アップデートして時代に追いつこう

[0325 デフォルトの名無しさん 2022/08/13(土) 02:34:08.59 ID:xrD8032t]

>>322
一般論として全ての用途に有利なメモリアロケータはもちろん存在しない
またアプリケーションプログラムの方もその用途によっては標準とは別のメモリアロケータ利用が最適化に効くものも当然ある
したがってもし必要と判断した時に利用するメモリアロケータを変えられることが好ましい

調べてみると
Rustもそのようなメモリアロケータを変更可能な言語
jemallocはある種の用途で有利になりうるメモリアロケータ
そして両者を組み合わせて用いることに支障はないようだが何を問題にしているのか？

[0326 デフォルトの名無しさん 2022/08/13(土) 03:03:54.43 ID:9Y2sM84k]

Haskellのときも、世界が見限ったころに5chで流行り始めた。

[0327 デフォルトの名無しさん 2022/08/13(土) 03:04:25.86 ID:9Y2sM84k]

実用性のない言語は使われない。

[0328 デフォルトの名無しさん 2022/08/13(土) 03:41:52.55 ID:fGEsvyaQ]

Haskellは大量のgarbageを撒き散らすうえにGCが遅いため実行時間が遅いのが致命的な古い言語
しかし代数的データ型やパターンマッチに型クラスなど有用なものが多く後の言語に影響を与えた
30年前の言語をわざわざ次世代言語スレに持ち出してきて叩く人はおかしい

[0329 デフォルトの名無しさん 2022/08/13(土) 03:47:09.96 ID:9Y2sM84k]

Rustも世界が見限ったので5chで流行り始めてる。

[0330 デフォルトの名無しさん 2022/08/13(土) 03:59:57.56 ID:9Y2sM84k]

いつものやつ。
https://trends.google.co.jp/trends/explore?q=%2Fm%2F0dsbpg6,%2Fm%2F02p97,PHP

[0331 デフォルトの名無しさん 2022/08/13(土) 04:10:31.61 ID:xQE0tEua]

>>330
修繕
https://trends.google.co.jp/trends/explore?q=%2Fm%2F0dsbpg6,%2Fm%2F02p97,%2Fm%2F060kv

[0332 デフォルトの名無しさん 2022/08/13(土) 04:21:51.20 ID:6QfP9d8W]

937 デフォルトの名無しさん 2022/08/02(火) 15:13:23.73 ID:EoK+AbMq
>>936
>>1によるとRustは現世代最強言語だから比較として出てくるのは当たり前だろ

比較として過去世代言語を持ち出すのはレギュレーション違反ではありません
よろしくお願いします

[0333 デフォルトの名無しさん 2022/08/13(土) 04:22:46.97 ID:3CEN1DwX]

>>329
昨年Rust FoubdationをGoogleやMicrosoftやAmazonなど
世界の大手IT各社が共同で設立したばかりですが
どこの世界がRustを見限ったの？

[0334 デフォルトの名無しさん 2022/08/13(土) 04:49:06.79 ID:9Y2sM84k]

FacebookがRustを採用。
↓
Facebookの失墜。
↓
世界がRustを見限る。

Facebookが戦犯。

[0335 デフォルトの名無しさん 2022/08/13(土) 05:17:02.03 ID:qcqt1f6R]

>>245の記事によると
世界でトップシェアのクラウドAWSがその提供サービス実装にRustを使っているようだぜ

[0336 デフォルトの名無しさん 2022/08/13(土) 05:34:22.29 ID:9Y2sM84k]

>>335
終わりの始まり。

[0337 デフォルトの名無しさん 2022/08/13(土) 06:07:19.25 ID:9Y2sM84k]

Rustで出来てる有名なソフトって何かあるの？

[0338 デフォルトの名無しさん 2022/08/13(土) 06:28:22.11 ID:lzc5RUpA]

AWSだけでなくLinux OSもAndroid OSもRustを採用したから終わりの始まり

[0339 デフォルトの名無しさん 2022/08/13(土) 07:38:54.55 ID:njvmvUJk]

あくまでも適してるのは低レイヤー

[0340 デフォルトの名無しさん 2022/08/13(土) 08:13:13.08 ID:9Y2sM84k]

Linux OSもAndroid OSもCで書かれてる。

[0341 デフォルトの名無しさん 2022/08/13(土) 08:17:14.35 ID:9Y2sM84k]

Rustで書かれてるメジャーなOSって何かあるの？

[0342 デフォルトの名無しさん 2022/08/13(土) 09:28:15.05 ID:KZ/RfVV4]

あったら何なの？無かったら何なの？
関係ないんだよお前には

[0343 デフォルトの名無しさん 2022/08/13(土) 09:42:57.35 ID:2Qk1ejrP]

なんかGoもRustも違うんだよな～
求めてる言語じゃないっていうか
Cをベースにして欲しいんだよ俺は
C++は論外

[0344 デフォルトの名無しさん 2022/08/13(土) 09:49:20.23 ID:9Y2sM84k]

Rubyはどうだい？

[0345 デフォルトの名無しさん 2022/08/13(土) 09:55:35.86 ID:Dkd+eytH]

>>325
メモリ安全を売りにしているRustだから、メモリアロケータもRust製に拘った方が良いとかは無い？

[0346 デフォルトの名無しさん 2022/08/13(土) 09:58:00.87 ID:JIF8rHbt]

>>343
C#をネイティブコンパイルで

[0347 デフォルトの名無しさん 2022/08/13(土) 10:00:10.89 ID:ogpUFXWj]

■Rust使用実績
<OS>
- Linux
- Android

<基盤、ミドルウェア>
- AWS

<アプリケーション>
- Firefox

<Webアプリ>
- Cookpad
- Dwango

[0348 デフォルトの名無しさん 2022/08/13(土) 10:16:01.13 ID:UHqBjcNr]

WebアプリでRust使ってるやつはバカそのもの

[0349 デフォルトの名無しさん 2022/08/13(土) 10:45:37.81 ID:TjiWtf4M]

■Goの使用実績

https://github.com/golang/go/wiki/GoUsers

[0350 デフォルトの名無しさん 2022/08/13(土) 11:10:16.71 ID:N+gF026L]

GCがメモリ解放を「遅延」する特性を
プログラミング全般に応用した遅延評価は
GCの失墜を象徴する芸術作品なんだよ

[0351 デフォルトの名無しさん 2022/08/13(土) 11:30:18.26 ID:nBIkkk5z]

>>350
メモリ解放の遅延と評価の遅延は対象も効果も目的も違うだろ。

同一視するのはさすがに無知過ぎない？

[0352 デフォルトの名無しさん 2022/08/13(土) 11:41:11.76 ID:njvmvUJk]

GCが適さない環境でメモリ管理するいいやり方が所有権システムってだけなのでは？

GCが特に問題ならない環境でその所有権システムをわざわざ利用するメリットは？

[0353 デフォルトの名無しさん 2022/08/13(土) 11:45:26.29 ID:N+gF026L]

Haskellの場合は構文木のグラフ簡約がなければGCのグラフ探索もほとんど不要だよね

[0354 デフォルトの名無しさん 2022/08/13(土) 11:56:00.20 ID:BhfPzEVU]

>>352
静的型付けとか所有権とかは
難しいものでもなく慣れだけで簡単で
実際に使っていると大した手間も無く
メリットばかりが得られるんだよ

コンパイル時点で静的に全て決まるから
実行時にその分の無駄なデバッグなども不要
どの分野とか全ての分野で同じ

更にオマケとして
高速と省メモリが付いてくる
もちろん安全性も付いてくる

[0355 デフォルトの名無しさん 2022/08/13(土) 12:17:05.15 ID:if0JSPrf]

>>352
エコ

[0356 デフォルトの名無しさん 2022/08/13(土) 12:27:39.76 ID:njvmvUJk]

信者曰くデメリットなくてコストもかからずメリットしかないらしいけど
競プロでもISUCONでも全然人気ないし、エンタープライズでもほとんど見ないね

[0357 デフォルトの名無しさん 2022/08/13(土) 12:38:30.52 ID:Dkd+eytH]

UnityがC#からRustに乗り換えでもしたら、
私でもRustを扱える難易度かもしれない。

[0358 デフォルトの名無しさん 2022/08/13(土) 12:44:13.20 ID:7TnExSFS]

そもそもGCがボトルネックになるケースって相当なレアだと思うんだけど
GCをなくしたいモチベーションがよくわからない

[0359 デフォルトの名無しさん 2022/08/13(土) 12:53:11.09 ID:l2wlkFvH]

GCかどうかはどうでもいい話

高速＆省メモリ
　だと
エコ＆利用者も快適＆リソース料金コストも安い

つまり良いこと尽くしなので高速＆省メモリを選ぶ
結果として非効率なGCは論外

[0360 デフォルトの名無しさん 2022/08/13(土) 12:57:18.86 ID:njvmvUJk]

エンタープライズでは開発コスト重視するからRustはコストの観点では論外だね
開発メンバが抜けた時に継続してメンテできるか？新たな人材の確保は容易化？を最優先に考えるから

コストで有利に働くのはあくまでも個人開発の場合だね

[0361 デフォルトの名無しさん 2022/08/13(土) 12:58:30.25 ID:njvmvUJk]

NoSQL最強でRDBは不要おじさんw
無知そのものw

[0362 デフォルトの名無しさん 2022/08/13(土) 13:02:33.78 ID:cJQbCMHe]

なにがし言語が使える人材、なんて人材の探し方してるの？
それでエンタープライズは笑う

[0363 デフォルトの名無しさん 2022/08/13(土) 13:04:50.07 ID:HNkVMULx]

>>352
メモリ以外のリソース、コネクションやファイルハンドラやらも所有権の枠組みで管理できるので並列処理でリソース管理周りのバグを出したくなければRustが理に適ってるシーンもある。

GC付きの言語でメモリ以外のリソースをGC的に管理しようとする取り組みとか無いのかね。
tryで囲んだりdefer書くとかで責務をいつまでも書き手に委ね続けるのは言語設計者の怠慢だわ。

[0364 デフォルトの名無しさん 2022/08/13(土) 13:07:30.57 ID:njvmvUJk]

イキってRustなんて使ったところで技術的負債になるだけ

あくまでもC++を置き換えるだけだからイキって採用しないようにしろよ

[0365 デフォルトの名無しさん 2022/08/13(土) 13:07:51.86 ID:ppHUbuJC]

エスケープ解析に触れないでGCと所有権を比較するのはさすがに無能すぎる。

あと、所有権に言及して設計の制約を無視する奴は詐欺師。
Rustはまず効率化のために制約の下でできる範囲で設計して、無理なら設計を破棄してやり直す(か、そもそもコーダーにやらせない)思想だろ。

[0366 デフォルトの名無しさん 2022/08/13(土) 13:19:05.90 ID:uzvb9KsU]

>>360
現実世界だと大手IT各社がRustを採用しているのはどうしてなの？

[0367 デフォルトの名無しさん 2022/08/13(土) 13:23:30.97 ID:N+gF026L]

>>363
デストラクタ内でポインタをいじる処理を許せばGCの性能が死ぬ

[0368 デフォルトの名無しさん 2022/08/13(土) 13:35:35.80 ID:6QfP9d8W]

>>363
C#のusingじゃだめですか

[0369 デフォルトの名無しさん 2022/08/13(土) 13:36:08.73 ID:HNkVMULx]

>>367
メモリ以外のリソースを持つオブジェクトを型付けしてやって効率的にするとかできないもんかね。

何にせよRustの適用領域が狭いのは確かだけどハマる領域だとこれ一択レベルだろうな。

[0370 デフォルトの名無しさん 2022/08/13(土) 13:40:47.26 ID:r/AYssCA]

>>369
Rustはほとんどの領域に向いている汎用的な言語
そもそも特定向け専用言語なんて非常に珍しい存在

[0371 デフォルトの名無しさん 2022/08/13(土) 13:40:59.10 ID:njvmvUJk]

>>366
ヒント　低レイヤー　C++

[0372 デフォルトの名無しさん 2022/08/13(土) 13:45:03.23 ID:HNkVMULx]

>>368
C#のusingやkotlinのuseが正解っぽい感じはするんだけど、GCみたいにそもそも普段は意識しなくて済む感じになってほしい。

[0373 デフォルトの名無しさん 2022/08/13(土) 13:54:48.24 ID:njvmvUJk]

>>370
向いていると専用の違いがわからない馬鹿

[0374 デフォルトの名無しさん 2022/08/13(土) 14:02:11.57 ID:35Vbbs0e]

ここにあるファイルを末尾に日付を入れてネットワーク上のNASにコピーした後、削除し空ファイルを作ってください。
これをRustでやる奴はウンコ、普通にbashで書く

[0375 デフォルトの名無しさん 2022/08/13(土) 14:06:21.25 ID:N+gF026L]

Pythonの__del__の仕様を確認したらむちゃくちゃ大雑把だった
こんなのスクリプト以外で許されるわけねえだろ

[0376 デフォルトの名無しさん 2022/08/13(土) 14:10:23.92 ID:6QfP9d8W]

>>374
エラー処理の要件次第ではbashだと辛くなりそうな予感がするんですが

[0377 デフォルトの名無しさん 2022/08/13(土) 14:19:49.12 ID:w1Rw8Hpr]

>>372
普通にストリームとかを使いっぱにしとけばいいんじゃね？
まともな実装ならその変数がGCで回収される時にクローズされるだろ

[0378 デフォルトの名無しさん 2022/08/13(土) 14:49:04.30 ID:98LBn3Jf]

>>326
日本が伊達にIT後進国じゃないってことだよな

[0379 デフォルトの名無しさん 2022/08/13(土) 14:51:34.28 ID:98LBn3Jf]

>>343
zig

[0380 デフォルトの名無しさん 2022/08/13(土) 15:27:52.15 ID:1A00TS1y]

>>374
それだとファイルの末尾だと誤読しうる
おそらくファイル名の末尾の意味だろう

そういう処理は用途によってはbashスクリプトも当然使っている
ただし色んなエラー処理をしだすとシェルスクリプトでは面倒なこともある

そのためプログラミング言語を使う場合もある
Rustを使っているものもある

[0381 デフォルトの名無しさん 2022/08/13(土) 15:36:28.85 ID:1A00TS1y]

>>377
GCはいつ起こるかわからない
そしてその使い方ではGCが起きるまでクローズが遅延される

すると色んな問題が起こる
OSリソースがその間占有され続ける
占有オープンなら他者が利用できないなど

GC言語を使うなら面倒でもdeferやusingなどで明示的に後処理するしかないだろう
もちろんC++やRustならばRAIIにより即座に解放されクローズ処理もされるため面倒な記述は不要である

[0382 デフォルトの名無しさん 2022/08/13(土) 15:40:18.08 ID:w1Rw8Hpr]

>>381
> GCはいつ起こるかわからない
> そしてその使い方ではGCが起きるまでクローズが遅延される
そんなことは分かってるよw
話の流れくらい読めよ

[0383 デフォルトの名無しさん 2022/08/13(土) 15:56:23.29 ID:1A00TS1y]

>>382
RAII言語の方が優秀だと認識できているならばよろしい

[0384 デフォルトの名無しさん 2022/08/13(土) 16:14:32.90 ID:w1Rw8Hpr]

>>383
アホなの？
C# の using も知らん無能はいちいち絡んでくるなよ

[0385 デフォルトの名無しさん 2022/08/13(土) 17:08:08.82 ID:1A00TS1y]

>>384
君は>>381を最後まで読まずに
途中で反射的に書き込んでいると分かったのでもういい
反省しなさい

[0386 デフォルトの名無しさん 2022/08/13(土) 17:28:21.83 ID:njvmvUJk]

NoSQL最強おじさん笑
RAII最強おじさん笑

[0387 デフォルトの名無しさん 2022/08/13(土) 17:30:58.15 ID:w1Rw8Hpr]

>>385
お前は>>372に既に書いてあることをアホみたいに再度書いてるから揶揄されてることも分からん知能しかないことがよくわかったよw

[0388 デフォルトの名無しさん 2022/08/13(土) 17:33:59.86 ID:Dkd+eytH]

>>375
そんな雑なものがたくさんあるのに、Rustにすべきなんて言う人とはいつ迄も平行線な気がするよね。

[0389 デフォルトの名無しさん 2022/08/13(土) 17:41:30.08 ID:WN46//k4]

>>363
それが怠慢とかｗ
どこでメモリ（リソース）を確保してどこで解放するかをプログラマが選択出来なきゃ
それこそ自由度が無く使いにくい言語になる
GCがあるから解放しなくてもいつかやってくれるから明示的に書かないという思想が
正しいと思っているならおかしい

[0390 デフォルトの名無しさん 2022/08/13(土) 17:50:27.94 ID:N+gF026L]

>>388
Rustやれぇとか命令されても
命令を無視する自由度のある人間はいちいち気にしない
命令無視しようが平行線だろうが何も問題ない

[0391 デフォルトの名無しさん 2022/08/13(土) 18:03:09.67 ID:ctGwDZYY]

useとかusingとかdeferとか
書き忘れていたら実行前にエラーとなってくれればいいんだけどね
忘れずに書いていることに依存させる言語仕様はよくないね

[0392 デフォルトの名無しさん 2022/08/13(土) 18:12:50.43 ID:46rvE8i+]

GCは結局メモリとGCの二つを管理しなきゃいけなくなって非効率なんじゃないか？

[0393 デフォルトの名無しさん 2022/08/13(土) 18:14:07.67 ID:9Y2sM84k]

量子プロセッサ時代のプログラミング言語とか、意義のある会議は出来ないものか。

[0394 デフォルトの名無しさん 2022/08/13(土) 18:42:16.49 ID:MTqiLV7H]

ここ隔離スレなので特定のトピックに興味あるなら専用スレ立てた方が良いよ

[0395 デフォルトの名無しさん 2022/08/13(土) 21:59:10.85 ID:8G4SUPRt]

ファイルの自動クローズがRAIIで無条件かGCなので何らか明示指定かの話を見ていて思ったんだけど、
メモリの自動解放はこれまでGC言語だけの特権でGCにはデメリットもあれどメモリの自動解放という何もかもを上回るメリットが前面にあったのよね。
ところがGCがないのにメモリを自動解放するプログラミング言語が登場しちゃって危機感を覚える人も登場しちゃって、

[0396 デフォルトの名無しさん 2022/08/13(土) 22:51:24.09 ID:6wAoLN5t]

GCがない(?)のにメモリを自動解放するプログラミング言語は昔からありますが……C++と言いましてね。

C++で（Rustみたいに）スタックフレームに何でも押し込むスタイルにするとどうなるのかねぇ。

[0397 デフォルトの名無しさん 2022/08/13(土) 23:40:22.03 ID:9Y2sM84k]

重要なものがキャッシュに乗りにくくなるのでは？

[0398 デフォルトの名無しさん 2022/08/13(土) 23:54:24.87 ID:601ao6Ev]

そもそもRustもC++も含め、RAIIは何でもスタックに積んでいるわけではない
スタック上の値のように振る舞うように作られているだけで、内部的にヒープにメモリを確保しポインタを保持しているケースが多い

[0399 デフォルトの名無しさん 2022/08/14(日) 00:25:46.03 ID:b9F5IowR]

Rustは自動メモリー管理が売りなんだから、C++のように自由に何でも出来たらダメでは？

[0400 デフォルトの名無しさん 2022/08/14(日) 00:49:36.36 ID:b9F5IowR]

JavaとHaskellの良いとこ取りのように宣伝されてたけど、悪いところを併せ持ってしまったのでは？

[0401 デフォルトの名無しさん 2022/08/14(日) 07:17:26.98 ID:tJlVM+m7]

>>396
C++はメモリを自動解放しない。
unique_ptrやshared_ptrを忘れずに利用し間違えずに使用した場合のみ自動解放されるが、
それはその正しく作られたプログラムがメモリを自動解放しているのであり、
C++という言語自体がメモリを自動解放することはない。
一方でGC言語やRust言語などはプログラムの記述と関係なくメモリが自動解放される。

[0402 デフォルトの名無しさん 2022/08/14(日) 07:54:47.25 ID:osAuRY7C]

事実上今時のプログラムで生ポインタなんて使わないしアスペの>>401は知らんけど普通のプログラマにとってメモリー解放はC++程度で充分

[0403 デフォルトの名無しさん 2022/08/14(日) 08:05:26.58 ID:tJlVM+m7]

>>402
それはプログラマーの問題。
プログラマーの作ったプログラムにより自動解放している。
C++という言語はメモリを自動解放しない。

[0404 デフォルトの名無しさん 2022/08/14(日) 08:19:24.23 ID:J5VfX3cG]

>>401
一般ユーザーがめったに使わないnewで言いがかりつけるなよ。Rustのunsafeみたいなものだろ。

[0405 デフォルトの名無しさん 2022/08/14(日) 08:30:27.75 ID:osAuRY7C]

はいはい、アスペは何を指摘されているかも理解できないからどうでもいいわ

[0406 デフォルトの名無しさん 2022/08/14(日) 08:44:12.34 ID:FX5vs6id]

ムッシュムラムラ

[0407 デフォルトの名無しさん 2022/08/14(日) 09:20:45.22 ID:lDco67Nc]

RAIIみたいなありふれたものじゃなくてxor mutabilityをアピールした方が良いのでは

[0408 デフォルトの名無しさん 2022/08/14(日) 09:37:16.54 ID:TQqmfXCA]

>>407
これ

[0409 デフォルトの名無しさん 2022/08/14(日) 09:38:28.08 ID:gLXUvNT9]

>>407
実運用としては難しすぎて逆効果だとわかっているから言わないんだよ。
あるいはそもそも理解していないか。

[0410 デフォルトの名無しさん 2022/08/14(日) 10:03:55.97 ID:TQqmfXCA]

>>409
難しすぎて逆効果ってどういうこと？
ワイRust大好きマンだけど、趣味ってだけで業務ではRust使ってないからよくわからない....

[0411 デフォルトの名無しさん 2022/08/14(日) 10:19:19.22 ID:q44Oj4I2]

>>410
もちろん難しいことはなくとてもシンプルな原理
そして実運用で非常に大きなメリットをもたらしている
Rustが大手IT各社に支持されている理由の一つ

[0412 デフォルトの名無しさん 2022/08/14(日) 10:29:55.69 ID:oyMyAes/]

あくまでもOS開発の用途で採用されてるだけ

[0413 デフォルトの名無しさん 2022/08/14(日) 10:38:15.56 ID:q44Oj4I2]

>>412
Rustの世界的大規模な調査結果により
Rustの利用対象はサーバーサイド/バックエンドが最多で
以下クラウド、分散システム、WebAssembly/Webフロント、組み込みといった状況になっている

[0414 デフォルトの名無しさん 2022/08/14(日) 10:43:52.82 ID:oyMyAes/]

>>413
ソースは？
大手企業は？

[0415 デフォルトの名無しさん 2022/08/14(日) 10:48:15.10 ID:q44Oj4I2]

>>414
>>413のソースは毎年調査が行われているRust Annual Survey Report

[0416 デフォルトの名無しさん 2022/08/14(日) 10:58:46.14 ID:J5MpSH/Q]

>>407
XORじゃないけどな

[0417 デフォルトの名無しさん 2022/08/14(日) 11:16:29.29 ID:UOAed9Kc]

before == afterのことをimmutableというなら
==の定義とかあるんですか？
まさか、大手企業を観測すれば==の定義が分かると思ってるマッドサイエンティストはいないよね

[0418 デフォルトの名無しさん 2022/08/14(日) 11:19:12.35 ID:q44Oj4I2]

>>416
一般的にデータ競合を起こさないための条件は
multiple readers XOR single writer
そしてRustも同じくこのシンプルな原則に従っている

[0419 デフォルトの名無しさん 2022/08/14(日) 11:47:03.37 ID:E6D9Byfe]

現実には複数の状態のストアに跨がる論理的な競合の方がずっと問題で、単一データの読み書きの競合なんてアトミック変数くらいで十分

[0420 デフォルトの名無しさん 2022/08/14(日) 11:59:58.73 ID:N9EVRHSm]

実行時に同時に読み書きしうるかどうかをコンパイラが厳密に検知することは不可能
Rustがやってるのは大幅に安全側に倒すアプローチで、それでいいんだったら関数型みたいにそもそもミュータブルなデータを共有しない、でも立派に対策になってるよね
実際それで十分なケースが殆どでしょ

[0421 デフォルトの名無しさん 2022/08/14(日) 12:04:57.82 ID:npbVW+VU]

Rustはdata raceはふせげてもrace conditionは防げない
銀の弾丸でも何でもない

[0422 デフォルトの名無しさん 2022/08/14(日) 12:09:32.20 ID:q44Oj4I2]

>>419
アトミック変数を忘れたら競合する
さらにアトミック変数を使ってもそのコストがかかる

Rustでは静的にコンパイル時にデータ競合を必ず排除する
アトミック操作を必要とするならば指摘してくれる
multiple readers XOR single writerを守っていれば当然(コストの高い)アトミック操作を必要とせずにコンパイルが通る

したがってRustは他の言語よりもコストを低くデータ競合の安全性を常に満たせる

[0423 デフォルトの名無しさん 2022/08/14(日) 12:11:52.89 ID:npbVW+VU]

並行処理をしてないのにいちいちいらない制約かけられる方がコスト高いわ

[0424 デフォルトの名無しさん 2022/08/14(日) 12:12:26.58 ID:N9EVRHSm]

>>422
いつものキッズかな
単一変数のデータ競合が生じなくても多くのロジックは競合するんだよ

[0425 デフォルトの名無しさん 2022/08/14(日) 12:17:06.31 ID:qTNce3WZ]

並行処理を安全に実装するのが難しいから、需要があってGoとかRustみたいな言語が登場してるのであって、直列なコードしか書かないなら昔の言語でもよくね

[0426 デフォルトの名無しさん 2022/08/14(日) 12:18:16.18 ID:N9EVRHSm]

>>425
そうじゃなくて、並行処理をしている場合、現実には競合するタイミングが生じないと分かっていても制約がかかることになるんだよ
コンパイラは静的なスコープを検査することしかできないからな

[0427 デフォルトの名無しさん 2022/08/14(日) 12:35:39.15 ID:q44Oj4I2]

>>424
そんな当たり前のことで問題のすり替えをするのは行儀がよろしくない
>422では明確にデータ競合の話をしている

どの話であってもまずはデータ競合を起こさないことが必須
しかしこれまでの言語はプログラマー任せであり言語として実行前に静的にデータ競合を防ぐ機能を持たなかった
Rustはそれを実現するとともにコストの高いアトミック操作無しでもデータ競合を避ける形もサポートした

[0428 デフォルトの名無しさん 2022/08/14(日) 12:48:55.73 ID:E6D9Byfe]

>>427
多くの場合はより高水準の制御や抽象化を必要とするため、君が思っているほどデータ競合可能性の回避は重要じゃないってことだよ
制約に対して得るものが小さい

[0429 デフォルトの名無しさん 2022/08/14(日) 13:14:59.37 ID:q44Oj4I2]

>>428
実際にそれらのプログラミングをしていればわかる
データ競合の回避は重要どころか必須

[0430 デフォルトの名無しさん 2022/08/14(日) 13:29:25.97 ID:UOAed9Kc]

やっぱRAIIを意識しないと会話が成立しないぞ

読みたい情報が消されたり書き換えられているバグよりも危険なのは
情報を記憶する領域自体が消滅しているバグだから
書き換えを制限する効果よりもmoveやdropを制限する効果を見なければ本質が見えない

[0431 デフォルトの名無しさん 2022/08/14(日) 13:35:19.72 ID:cZJLOqDl]

>>428
データ競合可能性の回避は重要か重要じゃないかではない
データ競合可能性の回避は必ずすべきこと
Rustを叩きたいからといってこれを重要じゃないと主張するのは頭が狂っている

[0432 デフォルトの名無しさん 2022/08/14(日) 13:53:29.77 ID:ghgoUiTh]

データ競合可能性の回避をしてないシステムやアプリって存在するの？

[0433 デフォルトの名無しさん 2022/08/14(日) 14:01:21.37 ID:lDco67Nc]

並列処理しなくてもmutable aliasingにまつわるバグは起こりうるよね
典型的にはコレクションのイテレート中の要素追加とか

これを防ぐ仕組みを整えたらうまいこと並列処理にも応用できたという話であってデータ競合を防ぐことが本質ではない

[0434 デフォルトの名無しさん 2022/08/14(日) 14:09:17.85 ID:osAuRY7C]

>>432
回避し切れてないシステムやアプリはそこそこ存在するけどw

[0435 デフォルトの名無しさん 2022/08/14(日) 14:32:21.17 ID:Zv4+MM+J]

mutable aliasingはGC言語でも防げないからなぁ
これが一度Rustに慣れてしまうと他に戻れなくなる原因の一つかも
他言語も積極的に取り入れてほしいところ

[0436 デフォルトの名無しさん 2022/08/14(日) 15:49:07.29 ID:UOAed9Kc]

コレクションが変更されたら
影響のあるすべてのイテレータに何か通知するべき

ここで、すべてのイテレータのリストを強参照してるとメモリが解放されないバグを作れる
GC言語でも弱参照大事

[0437 デフォルトの名無しさん 2022/08/14(日) 15:56:50.41 ID:b9F5IowR]

Rustはオワコンだろ。

[0438 デフォルトの名無しさん 2022/08/14(日) 16:16:26.65 ID:lDco67Nc]

>>436
GC言語ってそこまでケアしてくれるのが普通なの？

[0439 デフォルトの名無しさん 2022/08/14(日) 16:30:43.31 ID:b9F5IowR]

そういうレベルで設計する人たちだと、RustやReactなんかが良いのかもしれないな。
「レベルが高い」と思ってそうなのがアホだけど。
「弊社はアホが多いから、これで行くしかない」というのが正しい態度では？

[0440 デフォルトの名無しさん 2022/08/14(日) 16:41:26.12 ID:psUND9lq]

すばらしい洞察

[0441 デフォルトの名無しさん 2022/08/14(日) 16:46:59.70 ID:Zv4+MM+J]

実際「自分はアホなのでバグのないC++は書けない」と思ってRust書いてるよ
年とともに集中力も維持し続けられなくなるし、コンパイラに助けてもらわないとどうしようもない

[0442 デフォルトの名無しさん 2022/08/14(日) 17:03:40.00 ID:lDco67Nc]

昔の静的型付けvs動的型付け論争思い出すね
開発者は十分賢いと仮定しレビューやテストでバグを見つけられれば十分とする立場と、
実行前に機械的に抽出できるバグは潰しておきたい立場の違い

[0443 デフォルトの名無しさん 2022/08/14(日) 17:06:11.09 ID:2tPpitqi]

Rustで「簡単」になるのははチームやコードを管理するリーダーやマネージャーで、実装するコーダーにとっては「簡単」じゃないのにな。

[0444 デフォルトの名無しさん 2022/08/14(日) 17:08:43.26 ID:b9F5IowR]

そういうレベルだと、なに使っても同じでは？

[0445 デフォルトの名無しさん 2022/08/14(日) 17:10:46.46 ID:lDco67Nc]

レビューやテストでなんとかできるなら現世代言語で十分だよね
次世代言語という観点では、実行前により多くの問題点を検出することや、検出できる問題の量を保ったままコード記述の自由度を高めることが期待されてることのひとつだと思う

[0446 デフォルトの名無しさん 2022/08/14(日) 17:10:54.70 ID:BkdSXVLW]

IT大手企業が揃って同じ主張
人手に頼るC++等ではバグを無くせない
良い人材を揃えているところでもミスをゼロには出来ないから言語による支援がある方が良い
メモリ管理でもデータ競合でも同じ

ソース
https://xtech.nikkei.com/atcl/nxt/column/18/00692/042700054/

Rustは、プログラムに必要なメモリーの確保や解放に関連するバグが生じない「メモリー安全」が保証されたプログラミング言語である。
それに対してこれまでのOS開発に使われてきたC/C++は「大規模な開発においてメモリー安全なコードを記述することがほぼ不可能」
（Microsoftのブログ「We need a safer systems programming language」より）なのだという。

GoogleによればAndroidに存在した深刻なセキュリティー脆弱性の70％近くがメモリー安全に関するバグに起因するという。
同様にMicrosoftも、同社製品に存在したセキュリティー脆弱性の70％がメモリー安全に関するバグに起因すると述べている。
C/C++を使う限りセキュリティー脆弱性を根絶するのは不可能と考えて、Rustを採用するに至ったというわけだ。

[0447 デフォルトの名無しさん 2022/08/14(日) 17:12:42.24 ID:lpUzUHFf]

イテレータなんてないし、for rangeで回ってくるのは常にコピーだよ。

[0448 デフォルトの名無しさん 2022/08/14(日) 18:49:23.51 ID:2zwTzsHO]

Rustはモダンとか言っておきながら今時セミコロン入力を強要するゴミ言語
セミコロン省略するとreturnを省略できる？何のメリットがあんのそれ
可読性が悪くなるだけだよね

JSみたいにフォーマッタで自動入力もできないしゴミ

[0449 デフォルトの名無しさん 2022/08/14(日) 19:57:13.45 ID:TQqmfXCA]

>>448
Rustを書いたことないか、チュートリアルレベルでしか触ってなさそう

[0450 デフォルトの名無しさん 2022/08/14(日) 21:15:44.48 ID:B+F1bo8h]

文法や記述は様々な言語をやっていれば誤差と慣れだけの問題となる
それに文句をつけるのは初心者と異常者のみ

そのRustに関して言えばセミコロンや中括弧(波括弧)は機能面で必要だからある
逆に例えば「 if (条件) 」の丸括弧は不要だから「 if 条件 」

[0451 デフォルトの名無しさん 2022/08/14(日) 22:57:09.94 ID:549c+n4K]

関数型のElixir は、データを書き換えられない。immutable。
新規作成しかできない

だから、並行処理に強い

[0452 デフォルトの名無しさん 2022/08/14(日) 23:52:55.91 ID:lDco67Nc]

>>448
こういう議論も地味に重要だと思う
セミコロンなしでreturn必須な言語の方が可読性高いのかな？
returnを書くことで読み手にとって何が明確になるんだろうか

フォーマッタでの自動入力って何？

[0453 デフォルトの名無しさん 2022/08/14(日) 23:58:23.93 ID:QUSc/NM6]

>>451
すなわち値を書き換えるたびにガベージを撒き散らしGC
さらにElixirにはGCされず溜まる一方のAtomがあり枯渇すると死ぬ

[0454 デフォルトの名無しさん 2022/08/15(月) 00:30:10.08 ID:yUQkYoQs]

文法はフォーマッタやコード生成、静的解析などのツールの作りやすさ影響してくるからあまり馬鹿にしない方が良い

[0455 デフォルトの名無しさん 2022/08/15(月) 01:04:12.66 ID:p/fNcd9R]

日本人は一部はセンスあるが
RustやElixer等メタプログラミング言語が理解できないやつが多すぎる

[0456 デフォルトの名無しさん 2022/08/15(月) 01:17:24.43 ID:DNbe8aKk]

外国人でも抽象的な概念についての難易度は同じだゾ・・・

[0457 デフォルトの名無しさん 2022/08/15(月) 09:39:59.10 ID:r7x/NN7r]

セミコロンを省略するとreturnになるわけではないぞ
・Rustでは式にセミコロンをつけると文になる
・ブロック({stmts}のこと)の最後の式が、そのブロックを評価したときの式となる
この二つのルールが原則で、関数のブロックの最後のセミコロンを省略すると、関数を評価した値になるってだけ

let a = {
let mut b = Builder::new();
b.add(foo);
b.add(bar);
b.build()
};
このルールのおかげでこのようなコードが書けるようになる(return文は関数から抜けるためにしか使えないので、ブロックの評価には使えない)
一時変数のスコープを最小限に抑えることができるし、mutableで宣言した変数を、スコープを抜けたらimmutableに戻すこともできる
慣れれば見やすいし、意味的なメリットも多い

[0458 デフォルトの名無しさん 2022/08/15(月) 10:33:46.88 ID:p/fNcd9R]

>>456
ウィキペディアの英語版と日本語版比べてみて、
メタプログラミングについて書かれている事が全然違うから。

日本は本当に遅れてる

[0459 デフォルトの名無しさん 2022/08/15(月) 10:41:42.04 ID:8YjBNSEW]

>>457
その意味不明な記法が可読性が悪くてゴミなんだが？
信者以外からはメリットを対して感じないよね。

この恩恵を受けるためだけにセミコロン全てにつけないといけないのめんどいんだけど。

[0460 デフォルトの名無しさん 2022/08/15(月) 11:14:59.57 ID:0McKJS85]

バカはバカを呼び寄せる

[0461 デフォルトの名無しさん 2022/08/15(月) 11:41:54.68 ID:i3sQrZ2z]

>>459がどの言語の文法を理想と考えているのかが気になる
golang?

[0462 デフォルトの名無しさん 2022/08/15(月) 12:05:46.45 ID:r7x/NN7r]

なぜRustに対する批判が具体的なものじゃなくて、「意味不明」とか「不要」とか主観的で何を指しているのかわからないような言葉ばかりなんだろう

[0463 デフォルトの名無しさん 2022/08/15(月) 12:17:22.73 ID:A27GovSV]

文末のセミコロンが必須な主なプログラミング言語
C　C++　Java　Perl　PHP　など

この状況でRustのセミコロンを叩いているのはこれらの言語を知らない初心者？
しかもRustは文と値の区別のためセミコロンの有無を活用して意味付けしている

[0464 デフォルトの名無しさん 2022/08/15(月) 12:21:25.57 ID:8YjBNSEW]

>>463
最近の言語が一切なくて草
モダン言語はない方が普通でそれと逆行してるから批判してるんだが

[0465 デフォルトの名無しさん 2022/08/15(月) 12:39:14.98 ID:vxI8O7UY]

Python Ruby JavaScript Scala Kotlin あとなにがあったっけなぁ

[0466 デフォルトの名無しさん 2022/08/15(月) 12:42:41.40 ID:8YjBNSEW]

>>457
逆にセミコロンなしをデフォルトにしてセミコロンとかつけると式になるとかでもいいのでは？

その書き方ができると便利なのは否定しないけど、その恩恵を得るためだけに全てにセミコロン付けるのを押し付けるのは余計なコストだっていいたいわ

[0467 デフォルトの名無しさん 2022/08/15(月) 12:52:23.38 ID:A27GovSV]

セミコロンを省略可能にしたプログラミング言語は色々と苦しんでいる
昔からJavaScriptのセミコロン省略により起こる問題は有名だが
Goなどもセミコロンを省略可能な言語なので問題がよく起きている

例えばGoでは
foo := 111111111 + 222222222 + 333333333
が何らか長い行として長いので改行して書こうとして
foo := 111111111
　　+ 222222222
　　+ 333333333
と書いてしまうとこれは以下のセミコロンの省略と解釈されてしまう
foo := 111111111;
　　+ 222222222;
　　+ 333333333;
つまりエラーとなる

他にもGoでは
bar := []int { 111111111, 222222222, 333333333 }
が何らか長い行として長いので改行して書こうとして
bar := []int {
　　111111111,
222222222,
333333333
}
と書いてしまうとこれは以下のセミコロンの省略と解釈されてしまう
bar := []int {
　　111111111,
222222222,
333333333;
}
これもエラーとなる

[0468 デフォルトの名無しさん 2022/08/15(月) 12:53:34.04 ID:A27GovSV]

>>467のようにGoは「セミコロンが必須だけど、省略可で、自動セミコロン挿入される言語」であるため
うっかり改行すると自動セミコロン挿入により文法エラーとなってしまう

[0469 デフォルトの名無しさん 2022/08/15(月) 12:53:34.61 ID:lLs0VW2c]

Rustで文と式が混在するのは最適化のため？文でエラーが発生したときはどうなるんかね？

resultとかの戻り値用変数があると自然だけど、末尾呼び出し最適化が面倒になるので痛し痒し。

[0470 デフォルトの名無しさん 2022/08/15(月) 13:06:38.69 ID:8YjBNSEW]

>>467
それの何が問題なの？
文法エラーになるなら何の問題ではない、エラーにならずにコンパイルされて変な挙動をするとかだったら問題だけど

[0471 デフォルトの名無しさん 2022/08/15(月) 13:10:39.72 ID:r7x/NN7r]

>>466
文にセミコロンをつけると式になるって文法を整合性を保ったまま定義できるとは思えない....
1とかtrueみたいな一つの値は式として扱う
ifやmatchはデフォルトで文として扱い、セミコロンをつけると式になるって文法にすると
let x = f(if cond { ... } else { ... };)
みたいな文で、どこが文でどこが式なのか曖昧さを持ってしまう気がする

[0472 デフォルトの名無しさん 2022/08/15(月) 13:14:43.30 ID:r7x/NN7r]

構文解析の簡単さってかなり大事なことだと思う
language serverも軽くなるしコンパイルも早くなる
適当に書いてフォーマッタで整形するって書き方もできるようになる
セミコロンをつけるのが面倒なのは分かるけど、それ以上の恩恵があるのは事実

[0473 デフォルトの名無しさん 2022/08/15(月) 13:15:05.13 ID:JDmNxXPp]

文法エラーになってからわざわざ直すのは面倒くさくないの？
JS/TSでもASIの罠にはまらないように考えるほうが面倒だから基本セミコロン付けているな

[0474 デフォルトの名無しさん 2022/08/15(月) 13:19:28.24 ID:zxOEKBbO]

>>466
言語設計した事ある？
a = b の b は式だからお前の仕様だと ; が必要になるんだけどw

[0475 デフォルトの名無しさん 2022/08/15(月) 13:22:56.61 ID:r7x/NN7r]

>>469
Rustでは文は
Item(関数の定義や構造体の定義など)
LetStatement(let文)
ExpressionStatement(式にセミコロンつけたやつ)
MacroInvocation(hoge!();みたいにマクロの使用にセミコロンつけたやつ)
しかないから、そもそも文はエラーを生成しない
文の中の式がエラーを生成することはあるけど、文法上はハンドリングも式の中で行われる
https://doc.rust-lang.org/stable/reference/statements.html

[0476 デフォルトの名無しさん 2022/08/15(月) 13:23:00.24 ID:8YjBNSEW]

>>474
したことねえけど、式として表現できるようにしたいからセミコロンを全てに強要するとかうんこだなって言いたいだけ

利用者にとっては面倒なだけ

[0477 デフォルトの名無しさん 2022/08/15(月) 13:32:10.82 ID:r7x/NN7r]

>>476
式の全てにセミコロンが強要されているわけではないぞ
Block(ifとかmatchとかの{}を使うやつ)を含む式であるExpressionWithBlockではセミコロンの省略が可能とされている
だから、式を文として扱うべき場所で必要最低限のセミコロンが強制されている
https://doc.rust-lang.org/stable/reference/statements.html#expression-statements

[0478 デフォルトの名無しさん 2022/08/15(月) 13:36:40.79 ID:zxOEKBbO]

>>476
だからお前の方法だと余計面倒になるだろw
問題提起はまあいいとして解決策がアホすぎる

[0479 デフォルトの名無しさん 2022/08/15(月) 14:50:27.64 ID:iWGF+SuJ]

セミコロンは面倒だし書かなくていいならそれに越した事ないけど
JSみたいに罠に嵌るくらいなら明示的に書くのでも別にいい
Rustはじめた当初はセミコロンの有無で戻り値が変わるのはめちゃイライラしたけど2週間もすれば慣れる

セミコロン不要言語ではRubyやSwiftは縛りが少なくて扱いやすい
Pythonは改行できるケースがかなり限定されてるから扱いにくい(そのくせ1行80文字にしろとかアタオカ)

[0480 デフォルトの名無しさん 2022/08/15(月) 15:00:02.78 ID:i3sQrZ2z]

話題か全然次世代言語っぽくないな
次世代言語は人間の考えを忖度して良い感じにコードを解釈して欲しい
セミコロンとか些細な文法レベルじゃなくて、自動的に最適なアルゴリズム選んでくれるとか

[0481 デフォルトの名無しさん 2022/08/15(月) 15:18:34.31 ID:n9YpVahh]

どういうトレードオフの上に成り立ってるかを理解しようとしない人とは技術的な議論はない立たないわな

[0482 デフォルトの名無しさん 2022/08/15(月) 16:06:15.48 ID:fboUSwN3]

長い行を途中で改行したくなったらどうなるか？

・JavaScriptだと正しく333333333と出力
let foo = 111111111
+ 222222222
console.log(foo)

・Goだとエラー([phone]が使われていない)となる
foo := 111111111
+ 222222222
fmt.Println(foo)

・Pythonだと111111111と出力
foo = 111111111
+ 222222222
print(foo)

・Rubyだと111111111と出力
foo = 111111111
+ 222222222
p foo

・Kotlinだと111111111と出力
var foo = 111111111
+ 222222222
println(foo)

セミコロンがある言語ならば長い行を自由に改行できる

[0483 デフォルトの名無しさん 2022/08/15(月) 17:19:36.40 ID:zuAYSXsv]

foo = (111111111
+ 222222222)
print(foo)

1つの評価式としたいのに途中改行を入れることを利点だと主張するなんてバカげている....
素直にC/C++の古めかしい記述を引き継ぎたい人が多いだけというのは、公式も認めてるのに

[0484 デフォルトの名無しさん 2022/08/15(月) 17:58:11.91 ID:wGU2BFOZ]

セパレータ無しで改行を無視するようにしたいなら、yamlのブロックスタイルぐらいが妥当かと。

[0485 デフォルトの名無しさん 2022/08/15(月) 18:28:05.88 ID:vxI8O7UY]

セミコロンが面倒とは言っても、インデントのタブと同じで頭使わないから楽だと思うんだがなぁ。
そんなに毛嫌いするようなことなんだろうか。

[0486 デフォルトの名無しさん 2022/08/15(月) 18:35:55.10 ID:zxOEKBbO]

もうここら辺の話は好みの問題もあるからこっちが正しいとか言っても揉めるだけ
>>483にしても無駄なカッコはヤダって奴が出るかも知れんし
foo = 111111111 +
222222222
で正しく処理できる言語もあるけどプラスの位置が気に入らんとか言う奴がいるかも知れんしな

[0487 デフォルトの名無しさん 2022/08/15(月) 18:42:32.98 ID:qHbAfBQi]

セミコロンがいるいらないなんてそんなに気にする事なのかな？
Cスタイルで無い書き方する言語の方がよっぽど見にくいんだよねぇ

[0488 デフォルトの名無しさん 2022/08/15(月) 19:05:59.41 ID:QBWih2zA]

Dartもそうだけどセミコロンなし言語に慣れてると忘れる時にいちいちエラーになってうざい
JSはprettierで自動入力できるけど、エラーになるのがめんどくさい

まあただの慣れの問題だけど

[0489 デフォルトの名無しさん 2022/08/15(月) 19:17:14.24 ID:Q0+/Bn9w]

PowerShell（; 不要） と C#（; 必要） 使ってるとたまにあれ？って思うことあるけどたいして混乱しないよ
そんなのにいちいち引っかかってたら他にもっと引っかかるところあると思うが

[0490 デフォルトの名無しさん 2022/08/15(月) 19:17:50.21 ID:jGpDADDF]

Rustはセミコロンレスにする実装が面倒ってだけやろ
エルゴノミクス的にはセミコロンなしのほうがいいに決まってる

[0491 デフォルトの名無しさん 2022/08/15(月) 19:34:59.12 ID:On5LnEYn]

むしろ482のような何も考えられない熟練者が、他の多くの言語を全否定してるのであって、Cスタイルを否定しているわけではない。
Cスタイルで無い書き方する言語の方が見にくいというのはよほど経験が足りないか、組み込みかシステムプログラミングでC/C++の
沼にどっぷりハマってるか....いまどきbashもTypescript/JSもLuaも書くだろうし、DeepleanningしたいならPythonぐらい触るでしょう？

[0492 デフォルトの名無しさん 2022/08/15(月) 19:42:50.19 ID:On5LnEYn]

フリーフォーマットスタイルになったのだって、B言語の毛の生えたC言語初期がブロック表す{}でさえ、当時の多くのコンピュータのキーボードで
打てなかったのに採用しており明らかにパーサーを簡単にしたいがためだけで、確かに欠陥は無いが、他の言語を否定する有益な要素には
全く成り得ない。「頭がCスタイル＝だから個人的にはそれが一番見やすい」という理論なら分かるが、一般化できるものではない

[0493 デフォルトの名無しさん 2022/08/15(月) 19:46:40.39 ID:DNbe8aKk]

フリーフォマットスタイルってウケる言いまわしだね

[0494 デフォルトの名無しさん 2022/08/15(月) 19:51:28.75 ID:v4xWLNJI]

些細なことで盛り上がってるな
昨日のRust叩きがすぐ論破されてRustは高機能で優秀だと決着してしまったから
今日のRust叩きはセミコロンと波カッコがテーマなのかい？

[0495 デフォルトの名無しさん 2022/08/15(月) 20:17:06.88 ID:1icmhpVn]

>>494
「誰にとって」高機能で優秀なのかを考えんとな。
リーダーとかマネージャーとかの管理者にとって、Rustはルールを強制して一定の安全性と性能を担保できる便利なルール。
その裏返しになるけど、コーダーみたいな実装者にとって、Rustは窮屈な制約や複雑な概念を押し付けられる不便な扱いづらいツール。

優れたプログラマーはコーダーであるとともにマネージャーでもリーダーでもあるからRustの利点は分からんでもないけど、普段使いにはしたくないツールだよなぁ。
今の複雑さじゃHaskellとかc++とかと大して変わらんから、そのうちもっと洗練された言語が出てくるんじゃない？

[0496 デフォルトの名無しさん 2022/08/15(月) 20:32:42.70 ID:IKaKwzzk]

ルールは強制じゃないんだよなあ
税金を払ってない金持ちがいるのと同じ

[0497 デフォルトの名無しさん 2022/08/15(月) 22:14:46.12 ID:i3sQrZ2z]

>>495
複雑な概念を押しつけられるというよりも、現実の複雑さを処理系が覆い隠さずそのまま見せている、ただしデフォルトでは安全装置付き、というのが自分の感覚には近いかなぁ

カジュアル用途にはshared xor mutabilityを採用したGCあり言語があれば良いと思うんだけどそれでも敷居高いと言われてしまうのかな

[0498 デフォルトの名無しさん 2022/08/15(月) 22:21:40.52 ID:i3sQrZ2z]

>>495はrustのチェックが過剰と言いたいのか、プログラムがエッジケースでクラッシュしても良いからプログラマーの自由にさせろと言いたいのか、どっちなんだろう

[0499 デフォルトの名無しさん 2022/08/15(月) 22:28:42.72 ID:vxI8O7UY]

>>491
>>482はべつに全否定なんかしていないだろう。
セミコロンを省略できることが無条件で優れているかのような主張に対して、そこにはやはり
トレードオフが存在することを示しているだけだと思うが。

[0500 デフォルトの名無しさん 2022/08/15(月) 22:34:42.13 ID:H/w3DVjw]

>>497
shared reference, mutable reference, ownedの3種類を常に分けるのは作る側も使う側も面倒でしょ
GC言語でdata raceを避けるためだけに許容できる面倒臭さではないと思う

[0501 デフォルトの名無しさん 2022/08/15(月) 22:37:46.04 ID:krDSEAE6]

>>499
>>482はサンプルが悪い
エアプじゃなければもう少しマシなの持ってきなよ

[0502 デフォルトの名無しさん 2022/08/15(月) 22:46:07.54 ID:vxI8O7UY]

>>501
全否定とサンプルが悪いのと全然関係ないが。
それはそうとして>>482はセミコロンを省略できる言語で改行するのに構文を意識しなければならない例として
わかりやすいと思ったが、どこがどうダメだと思った？

[0503 デフォルトの名無しさん 2022/08/15(月) 22:50:19.22 ID:1icmhpVn]

>>497
コーダーにとっては押し付けられるのも覆い隠さずむき出しなのも同じ。
運転するならマニュアルよりオートマの方が楽に目的地に行けるからねぇ。

[0504 デフォルトの名無しさん 2022/08/15(月) 23:08:45.28 ID:efQSXXjx]

>>500
まともなプログラマーならば
mutableかimmutableを必ず区別するしスクリプト言語にすら区別がある
GC言語だからそんな面倒な区別をしないなんてことはない
更にそのもの自体かreference (pointer)かの区別をする言語も多い

[0505 デフォルトの名無しさん 2022/08/15(月) 23:36:07.11 ID:zdpm5MVd]

>>504
immutableかmutableかの区別とはまた別

例えばPythonのiter()やC#のGetEnumerator()に相当するメソッドを
Rustではshared reference用のiter(),
mutable reference用のiter_mut(),
owned用のinto_iter()と3つ用意してその3つを使い分ける必要がある
他にも3種類の構造体を用意したり3種類ずつtraitをimplしたりする必要がある

Rustで3つを使い分ける主目的はメモリ安全性であってdata raceを防ぐのは副産物
メモリ安全性が確保されてるGC言語で副産物のためだけにやるほど価値があるとは思わない
data race detectorみたいなので十分

[0506 デフォルトの名無しさん 2022/08/15(月) 23:43:36.56 ID:efQSXXjx]

>>505
書き換えるのか書き換えずに読み取るだけなのか必ず区別する
プログラマーならそこは絶対に意識するところ
参照なのか実体なのかも同様に区別する
例えばcall by referenceなのか否かで変わってくるから常識

[0507 デフォルトの名無しさん 2022/08/15(月) 23:44:00.49 ID:bWP5l8ZG]

>>502
挙げてる言語が全てセミコロンのようなものが無ければ、改行をパースできない言語だけを挙げておいて
サンプルが悪くないと考えられることはセミコロンを入れる言語を優先したいだけでしょ？
そして482がいってるのはトレードオフなんて一言も言ってないし→同一人物だとすればサンプルも悪い

[0508 デフォルトの名無しさん 2022/08/15(月) 23:59:03.56 ID:1yqLKMZ0]

>>505
噓つき

まず、使い分けと言っても間違って使っていたらRustコンパイラが指摘してくれるから、他の言語のようにプログラマーに責任と義務を押し付ける形で使い分ける必要は全くない

次に、今まで様々なプログラムを書いてきて、そのための3種類の構造体やimplを用意する必要になったことは一度もない
プログラムでやりたいことは一つなのだからどれか一つに決まる
その選択を仮に間違えていてもRustコンパイラが指摘してくれるので必ず正解を選択できて楽勝

Rustはプログラマーへの責任圧力や負荷が非常に少ない
間違えてもコンパイラが賢くて教えてくれるし次第に慣れて間違いも激減

[0509 デフォルトの名無しさん 2022/08/16(火) 00:25:36.99 ID:ixQkAKAb]

>>506
>>505に書いてる事を理解してないでしょ
それだとRust的なaliasing xor mutabilityを実現するためにどういう言語機能が必要で
開発者にはどういうデメリットがあるのかわかんないよ

[0510 デフォルトの名無しさん 2022/08/16(火) 00:31:52.46 ID:FJ3wHtGm]

>>505
全部refcell相当にしてランタイムでよしなに処理できないかね？

[0511 デフォルトの名無しさん 2022/08/16(火) 00:45:43.29 ID:OuJTqPA4]

>>509
デタラメを書いている>>505の文章をよく読め
Rustに無知な>>505が妄想でデタラメを書き並べて無意味なRust叩きをしているだけだぜ

[0512 デフォルトの名無しさん 2022/08/16(火) 01:34:09.32 ID:VwgHy53B]

RefCellは無視してCellを使うのがコツかなと思ってる

[0513 デフォルトの名無しさん 2022/08/16(火) 01:41:29.91 ID:tWxob/nJ]

>>510
実行時のチェックのみでよければborrow checker無しの実装も可能かもしれないが
常にborrow済みでborrow_mutができない状況が量産されそう

[0514 デフォルトの名無しさん 2022/08/16(火) 02:21:22.55 ID:QGAuy2Qq]

Rustは便利でプログラミングしやすくて良いね
間違えてもコンパイラが必ず阻止して親切に教えてくれる
他の言語だと同じように間違えていても見かけの文法さえ合っていればコンパイラが通してしまう

[0515 デフォルトの名無しさん 2022/08/16(火) 05:56:45.08 ID:yor5shok]

とにかくRustさえ使っとけば安心安全だよね

[0516 デフォルトの名無しさん 2022/08/16(火) 06:08:59.99 ID:QGAuy2Qq]

いやRustはプログラミングしやすいことが感想
たまたま安全も付いてきた
あとなぜか高速も付いてきてラッキー

[0517 デフォルトの名無しさん 2022/08/16(火) 06:09:39.15 ID:weNk37uO]

xor mutabilityを実装するとライフタイムの解析みたいなことが必要になるから結局GC要らなくね？みたいなことになりそう

[0518 デフォルトの名無しさん 2022/08/16(火) 06:47:45.38 ID:tUBxw7eu]

3種類あると言ってたのに
xorとかいって2種類を意識してるのは違和感がある
意識の外にあるmoveの方が実は革新的だったりして

[0519 デフォルトの名無しさん 2022/08/16(火) 07:59:13.38 ID:sSvGV+9Q]

>>508
コンパライラが指摘出来るのに、勝手に使い分けてくれずに、使い分けをさせようとするのが、納得いかない。

勝手に解決できることは、出来るだけ勝手に解決をしてしまって欲しい。

[0520 デフォルトの名無しさん 2022/08/16(火) 08:09:09.89 ID:QGAuy2Qq]

>>519
コンパイラは神や予知者じゃないのだから
どちら側へと解決すべきかまでは分からない
だからコンパイラによるアドバイスを受けてプログラマーがその方向性を確定させる

[0521 デフォルトの名無しさん 2022/08/16(火) 10:10:30.02 ID:R/XB+eZ/]

>>507
>>482はみんな「セミコロンを省略できる言語」の例だと思うんだが。
いったいどの言語ならいいというんだろう？FORTRANかshかあるいはLISPとか？

[0522 デフォルトの名無しさん 2022/08/16(火) 11:21:12.43 ID:qWFX9EwW]

そもそもRustとかの新しい言語は演算子の途中とかで改行できるようにするためにセミコロンを用意したわけじゃないし…

[0523 デフォルトの名無しさん 2022/08/16(火) 11:34:08.30 ID:2x3mrzZQ]

;ない言語(例えば
python)で途中で改行したいなら(
)

[0524 デフォルトの名無しさん 2022/08/16(火) 12:15:04.38 ID:rcGuvRNd]

>>518
値の受け渡し方法の種類とmutabilityの違い

利便性を無視すれば可変参照をサポートしないようにして2種類に減らす事は可能

[0525 デフォルトの名無しさん 2022/08/16(火) 13:22:47.54 ID:lhfuWNrE]

>>522
まさにそう。見る角度によって美点を見出すのは人それぞれだがセミコロンなんてものを挙げて長い行が複数行で書けるなどと
長大なくだらない例を別言語叩きにしようとする腐った根性がまず気に入らない。公式すら見えてない白痴

[0526 デフォルトの名無しさん 2022/08/16(火) 13:53:44.58 ID:oZyv9MO8]

うむ
セミコロンの有無で気に入らない言語を叩き出したやつはキチガイ
それぞれにメリットはあるしプログラマーにとってもどうでもいい誤差

[0527 デフォルトの名無しさん 2022/08/16(火) 14:40:34.16 ID:R/XB+eZ/]

分類するとこんな感じかな。

1. 改行を文デリミタとして、文を途中で折り返したい場合には行継続を明示する　(FORTRANなど)
2. 改行に空白以上の文法的意味を持たせずに文分離記号、終端器具を用いる (ALGOLなど)
3. 1.の変形で、構文解析と組み合わせることで行継続の明示を不要とする (Pythonなど)

当然ながらどれも一長一短あるわな。

[0528 デフォルトの名無しさん 2022/08/16(火) 14:55:33.84 ID:oZyv9MO8]

セミコロンが有ったり無かったり些細なことで各プログラミング言語を批判する人は間違いなくキチガイ

[0529 デフォルトの名無しさん 2022/08/16(火) 15:00:16.01 ID:rvHyZbYe]

技術的な話が理解できないからセミコロンくらいしか口出しできないんだろ

[0530 デフォルトの名無しさん 2022/08/16(火) 17:28:09.35 ID:a2udn/hF]

言語を作る側と使う側の視点が噛み合ってないように見えるし、なんかマニアックな方向に議論が進んでるな

[0531 デフォルトの名無しさん 2022/08/16(火) 17:59:37.32 ID:olQxb0zT]

ASTとプレゼンテーション層としてのテキスト表現でしかないから内容と見た目の分離をすれば…みたいに考えてしまうが、htmlとcssの関係みたいにすぐそばに地獄の例もあるからなぁ。

[0532 デフォルトの名無しさん 2022/08/16(火) 18:09:52.12 ID:tUBxw7eu]

>>524
可変とか不変とかいう代わりに
swap可能とかswap不可能とかいえば良いのでは

swapって確かに何か変化はするが
もう一回swapすれば元に戻るという意味では何も変わってない

[0533 デフォルトの名無しさん 2022/08/16(火) 18:11:37.15 ID:pgEfkacG]

なんで母国語の文法でプログラミングできないの？
っていう質問と大差ないぐらいにはナンセンスなんだよなあ

[0534 デフォルトの名無しさん 2022/08/16(火) 18:32:26.44 ID:m9HqH8W6]

>>527
その分類だとRustのセミコロンの特殊性が埋没する

[0535 デフォルトの名無しさん 2022/08/16(火) 18:53:59.07 ID:wpAgGEI5]

>>534
Rustのセミコロンは実質的に「式の結果を捨てる演算子」だからなぁ。
あえて文としているのは最適化のためかね。

[0536 デフォルトの名無しさん 2022/08/16(火) 19:09:03.56 ID:R/XB+eZ/]

>>534
構文的には特殊なことなどなくPascal等と同じ.だろう。評価結果が違うだけ。

[0537 デフォルトの名無しさん 2022/08/16(火) 21:15:03.57 ID:I6WTAUR3]

プログラム言語の長短を議論したいなら、最低限、構文解析と型理論ぐらいは勉強しなよww
自分の使えるプログラミング言語の表層だけ見てあれこれ言っても仕方がない
せめて基礎知識ぐらいは身につけないと、自分の得意な言語こそが最強！レベルの話し合いにしかならない

[0538 デフォルトの名無しさん 2022/08/16(火) 21:27:16.28 ID:tUBxw7eu]

マイナス金利政策みたいに
何かを変えたいという目標が達成されるまで全く同じことを続ける人が一定数いる

[0539 デフォルトの名無しさん 2022/08/16(火) 21:55:08.25 ID:AvaBHQVi]

このスレ、次流行る言語について考察するスレだと思ったらなんか違う感じか

[0540 デフォルトの名無しさん 2022/08/16(火) 22:17:21.80 ID:6Bs0qU/k]

>>539
Rustが覇権したから推進派とアンチとの攻防戦の場となっているｗ

[0541 デフォルトの名無しさん 2022/08/16(火) 22:22:22.73 ID:bk3ffD66]

プログラミング言語のアンチをしてる人は精神的に何か病があるんじゃないか

[0542 デフォルトの名無しさん 2022/08/16(火) 22:23:06.14 ID:LmkLABMk]

NoSQLの謎の信仰で無知が露呈したRust信者w

[0543 デフォルトの名無しさん 2022/08/16(火) 22:25:20.93 ID:LmkLABMk]

>>541
他言語を貶めるRust信者のことだね
大半はRustじゃなくて信者を批判してるわけだが

[0544 デフォルトの名無しさん 2022/08/16(火) 22:34:52.91 ID:LmkLABMk]

別にRustを批判しているわけではない
どんな用途でもRustが最強で他の言語はゴミとかほざいてるRust信者を批判しているだけ
NoSQLは万能でRDBは不要とかほざいてるようにただの無知で適材適所という言葉を知らない馬鹿ってのが証明されてるわけだが

だからRustは低レイヤーには適しているがバックエンドやWebといった用途ではさほど適していないので流行らないってのに反論できずに発狂しているのが現実
やたらクラウドのコストガーメモリ効率ガーだとか主張するが運用する上での人件費のことを一切考えられないキチガイ

[0545 デフォルトの名無しさん 2022/08/16(火) 22:39:39.43 ID:bczdNrJL]

プログラマーは社会不適合者しかいないんだから仲良くせいや

[0546 デフォルトの名無しさん 2022/08/16(火) 22:42:24.87 ID:LmkLABMk]

簡単に言うとRustはCやC++を置き換える言語

だからCやC++が通常使わなれない用途で流行ることはまずない
これが現実、いくら信者が発狂しても現実は変わらんよ

[0547 デフォルトの名無しさん 2022/08/16(火) 22:43:33.40 ID:bk3ffD66]

>>543
言語の良さを語り合うのは問題ないと思うぜ
特定の言語を執拗に批判し続けたり粗探しをして叩いている異常者が問題視されている

[0548 デフォルトの名無しさん 2022/08/16(火) 22:45:57.82 ID:R/XB+eZ/]

ID:8YjBNSEW が自分のことを棚に上げて藁人形を持ち出した

[0549 デフォルトの名無しさん 2022/08/16(火) 22:48:22.06 ID:l1mRFV/Y]

>>544
調べてみたが『RDBは不要』と主張している人はこのスレに一人もいない
あなたが狂っているから全く存在しないものをあなただけが見えているのだろう
あなたは自分が狂っていることにそろそろ気付くべきだ

[0550 デフォルトの名無しさん 2022/08/16(火) 22:53:09.15 ID:LmkLABMk]

>>88
>>99
コストの観点でRDBは論外って言ってるから不要って言ってるようなもんじゃんw

コストを気にしてRDBを使わないって初めて聞いたんだが笑
どんだけここにいるRust妄信者って無知なんだよw

コスト気にするから全てのプログラムにおいてRDBを減らしつつRustを使えってwwwww

何で人件費のこととかは他のこと考えられないの？w

[0551 デフォルトの名無しさん 2022/08/16(火) 22:53:32.19 ID:aPDXDhC0]

>>546
そういう嘘はよくないなあ
流れとしては明らかに2系統あって
『自動メモリ解放で安全なのに、C言語と同じ省メモリ＆同じ速さが出る言語』として
スクリプト言語を含む様々なGC言語からRustへ、という流れが多い

[0552 デフォルトの名無しさん 2022/08/16(火) 22:57:57.27 ID:LmkLABMk]

Rustと他言語の関係も
RDBもNoSQLの関係も同じで
実際は要件に照らし合わせて適材適所で選択していくのが現実

Rust信者は適材適所って言葉を知らないからNoSQLが最強でRDBはゴミ
Rustが最強でGC言語はゴミ

と要件を無視しまるで全ての用途に対し万能であるかのように喧伝する

こういった思考停止したマウント意識の高い妄信者が死滅してくれればRustは日本でも流行っていくだろうw

[0553 デフォルトの名無しさん 2022/08/16(火) 22:59:41.00 ID:LmkLABMk]

>>551
> スクリプト言語を含む様々なGC言語からRustへ

それってあなたの感想ですよね？なんかそう言うデータあるんですか？
CやC++からRustに移行していくって流れなら一般的に言われてると思うけどそれは初めて聞いたわー
妄信者しか言ってないよね笑

[0554 デフォルトの名無しさん 2022/08/16(火) 23:01:02.80 ID:l1mRFV/Y]

>>550
ほら、あなたが狂っていることがこれで完全に証明された
あなたが指しているそれらのスレを見ると
『RDBは不要』との主張などこにもなく
むしろ逆で
『RDBの利用を必要最小限にする』とある
つまりRDBを最小限必要とするとの主張だ
以下ソース引用

>>88
> RDBはコストが高いだけでなくパフォーマンス面でも不利だから利用を最小限にする

>>99
> クラウドが提供するRDBの高コストなど現実を理解していれば
> RDBの利用を必要最小限にした方が有利なことが理解できるだろう

ソース引用以上
あなたが狂っているからあなたは誤読としくは意図的に嘘をつく狂った行動をあなたはとっていると証明された

[0555 デフォルトの名無しさん 2022/08/16(火) 23:03:45.36 ID:LmkLABMk]

そもそもGC言語ってのは誰でも書きやすいようになってるから流行ってるわけ
CとC++に比べて劇的に楽になっているってのが流行ってる最大の理由

Rustは当然GCがなくなる分自分で管理する必要がありそれなりの難易度があるからGC言語からRustに置き換わるなんて流れはどこにもありはしない
ほんと妄想が酷いんだなw

GCがボトルネックになるケースなんてごく稀であるし、そういったレアな要件で初めてRustに移行することを検討するべき
Rust信者はそう言った要件を無視し脳死でGC言語からRustへだとかほざいているけど
そんな流れはこの世のどこにも存在しない

[0556 デフォルトの名無しさん 2022/08/16(火) 23:06:19.94 ID:V3PalxnC]

いつものお二人さんw
まぁこの二人のための隔離スレだからいいんだけどさ

[0557 デフォルトの名無しさん 2022/08/16(火) 23:08:08.30 ID:aPDXDhC0]

>>552
その「NoSQLが最強でRDBはゴミ」などの書き込みはどこにあるんだ？

そういう妄想を書き込んで開き直ったり
特定の言語を執拗に批判し続けたり粗探しをして叩いている異常者がここでは問題視されている

[0558 デフォルトの名無しさん 2022/08/16(火) 23:08:46.78 ID:LmkLABMk]

>>554
不要って言ったのは邪推しただけかもしれないが
問題はそう言う言葉遊びではなくRust信者のコストが減るからあらゆる用途でRustがいいとかいう妄言が完全に矛盾してるから馬鹿にしてるだけだよw

それを運用していく上での人件費は？w

[0559 デフォルトの名無しさん 2022/08/16(火) 23:11:57.30 ID:LmkLABMk]

早くGC言語からRustって流れのソースを教えてくれよw

仮にPython使ってるとしたらなんでわざわざRustに変えないといけないのよ笑
どこにそんな流れがあるのか教えてくれ

[0560 デフォルトの名無しさん 2022/08/16(火) 23:17:55.21 ID:Wf4So6Y0]

GCか否かなんてことよりも
純粋にRustはプログラミングしやすいから
Rustが7年連続で最も愛されているプログラミング言語No.1となった

[0561 デフォルトの名無しさん 2022/08/16(火) 23:22:46.98 ID:Gb2scMub]

PythonだけでなくRubyからRustへ変えて高速化したCookpadの例もあるね
どの言語からも高速化するならRust一択になりそう

[0562 デフォルトの名無しさん 2022/08/16(火) 23:25:10.82 ID:tUBxw7eu]

Pythonは参照カウントもする中立派
高速化しない者だけが中立になれる

[0563 デフォルトの名無しさん 2022/08/16(火) 23:27:19.81 ID:LmkLABMk]

プログラミングしやすいらしいがクラウド用途ではGoばかりでRustは全然使われてないな

Rustはtraitとかマクロとか抽象化プログラミング、メタプログラミングの機能がやたらと充実してるけど、逆にそれのせいでプログラミングしにくくなってるのでは？
レベルの高いプログラマーではないとうまく扱えないピーキーさがある

シンプルな言語仕様のGoで書かれた実用的なプログラムがやたらと多いのを考えるとそう言う傾向が見て取れるよね

だからここにいるアホRust信者はRustなんてピーキーすぎて扱えないのが現実
だから他言語にマウントを取るしか能がないわけ

[0564 デフォルトの名無しさん 2022/08/16(火) 23:27:24.61 ID:hzx8DWaB]

こいつRust信者の仮面を被ったアンチRust工作者だな
そうでもなければここまでアホレス垂れ流し続けられないよ

[0565 デフォルトの名無しさん 2022/08/16(火) 23:36:57.97 ID:ZeqQ1iXO]

>>563
もしかしてRustでプログラミングして何かを作ったことない人なのかな
既存言語と比べてそれらの充実したRustの機能により格段にプログラミングしやすくなってるよ

[0566 デフォルトの名無しさん 2022/08/17(水) 05:04:30.24 ID:bVkA6pax]

>>565
「オートマよりもマニュアルの方が機能が充実しているから扱いやすい」ぐらいめちゃくちゃな主張だな。
あるいは「スマホよりパソコンの方が機能が充実しているから扱いやすい」とか。

[0567 デフォルトの名無しさん 2022/08/17(水) 06:30:44.49 ID:iOomOblS]

>>566
逆っぽい
色んなことがコンパイラにより自動化されているRustがオートマに相当かな

例としてヌルポ(事故)を避けることを考えてみると
(1)ヌルポを避ける機構を言語が提供していなくてプログラマーが手動で全て頑張らないといけない言語
(2)ヌルポを避ける機構を言語が提供してるけど適用必須でないためプログラマーが自分でその機構の利用を選択しなければならない言語
(3)ヌルポを避ける機構を言語が提供していて必ずその機構が用いられる言語
と3種類に分けた場合でもRustは自動適用の(3)だよね

他にもこのスレで既出の「データ競合回避」や「自動メモリ解放」なども同様
Rustはコンパイラが全て必ず適用してくれるからプログラマーの責任が激減してるよね
したがってRustがオートマに最も近いっぽい

[0568 デフォルトの名無しさん 2022/08/17(水) 06:38:31.18 ID:tVto1F2t]

良い物を作るだけで自動的に売れると思うのがオートマ
ゴリ押しするのがマニュアル

[0569 デフォルトの名無しさん 2022/08/17(水) 07:32:06.74 ID:qAPgSCZ7]

GC言語使ってる人にとってGCがないRustがオートマなわけがないだろう
C++がマニュアルだとしたらRustはセミオートマだ
GC言語はオートマ

[0570 デフォルトの名無しさん 2022/08/17(水) 07:51:45.43 ID:05yQ5lPP]

>>569
GC言語もRustもメモリ自動解放サポートで同じだからそこはいいとして、
それらの言語の中でもぬるぽ問題やデータ競合問題などもRustはサポートしているから、
Rustはオートマ度が最も高い言語の一つではないかしら。

[0571 デフォルトの名無しさん 2022/08/17(水) 08:00:37.20 ID:SLXSyyKd]

>>570
GC言語使ってる人は、もぬるぽ問題やデータ競合問題と無縁、考えたこともない人だっているよ。

例えば、私の席の近くでExcelのVBA使ってる人は、用語の説明からしないといけないレベル。

[0572 デフォルトの名無しさん 2022/08/17(水) 08:03:19.44 ID:/AaT26gR]

>>570
ならNimの方がオートマにふさわしいな。
Rustはせいぜい教官付きの教習車ぐらい。コストもそんなもんだろ。

[0573 デフォルトの名無しさん 2022/08/17(水) 08:19:18.07 ID:xIPygSHI]

>>571
考えたこともないなら単なるバカだな
データ競合はGC言語か否かに関係なく起きて防ぐ必要がある
ぬるぽもJavaからGoに至るまで多くのGC言語で起きて防ぐ必要がある

[0574 デフォルトの名無しさん 2022/08/17(水) 08:34:23.74 ID:SLXSyyKd]

>>573
バカで良いけれど、そんなの気にする必要もない要件もあるって事だよ。世の中何でもRustの機能を必要としているわけじゃないさ。

Pythonだと、ジャイアントロック掛けまくってるけれど、困らない事が多いという想定でしょう。

[0575 デフォルトの名無しさん 2022/08/17(水) 08:42:33.37 ID:/AaT26gR]

>>573
考える必要が無いからオートマなんだろ。オートマ使いはギアチェンジとかエンストとかほとんど意識しない。
問題を回避するためにコンパイラの指示に従う必要のあるRustはオートマじゃない。やっぱり教官付きマニュアル教習車だな。

[0576 デフォルトの名無しさん 2022/08/17(水) 08:45:03.08 ID:u0Nnvztf]

>>574
ここは次世代言語スレ
それら色々な機能がついている言語がメイン対象
だからRustが何歩かリードしてる感じ

[0577 デフォルトの名無しさん 2022/08/17(水) 09:13:39.86 ID:qAPgSCZ7]

>>573
並列処理を始めてやっと起きるのでは？
例えばNodeだとデータ競合は発生しないよ
シングルスレッドで行単位では処理が入れ替わらずawaitって書いてあるところ（コールバック単位）でスイッチングするから
競合状態はもちろん発生する、で、競合状態に関してはRustでも防ぐことは不可能

だからNode使ってる人にとってデータ競合はそもそも発生しないからその観点でRustに魅力を感じることはないよね

[0578 デフォルトの名無しさん 2022/08/17(水) 09:34:31.75 ID:zZknHbxd]

>>575
その、問題を回避するためにコンパイラの指示に従う、のが正しい解決方法で合ってる。
例えば、ぬるぽ問題回避(Null安全)は、KotlinでもSwiftでもRustと同じく別の型とする対応策。
Null安全でないコードが書かれると、コンパイラにより型不一致エラーとなり、コンパイラの指示に従いプログラマーがコードを修整して解決。

このように、ぬるぽ問題回避にしても、データ競合回避にしても、自動対応は無理なので、コンパイラが静的に検知してエラーとするのが正しい解決方法。
型システムの強化により、様々な問題に対応できるようになっていく。

[0579 デフォルトの名無しさん 2022/08/17(水) 09:51:56.11 ID:TMSqJNtq]

>>577
サーバーサイドをやってる周りではこういう状況
Node.jsはもちろん(Workerを除き)シングルスレッドで安全にasync/await並行処理できる
それだけで十分なところもあるけど次第にCPUコア活かして並列処理も加えて高速化したいところも増加中
その時にWorkerでは使い勝手の限界があるのはご存知と思う
すると今まで同様に安全にasync/await並行処理 ＋ 新たに並列処理を加えて高速化をできる環境を考えるとRustが筆頭候補
実際に移行したところも出てきているし少しずつサーバーサイドRust化の流れが今後主流になりそうな雰囲気

[0580 デフォルトの名無しさん 2022/08/17(水) 11:15:55.18 ID:8HFMEcaY]

>>579
サーバーサイドでRustとか何のギャグなの？って思うんだけどｗ
Goですらイマイチ伸びないのにｗ

[0581 デフォルトの名無しさん 2022/08/17(水) 11:47:55.34 ID:cnWCAZlk]

Rustはサーバーサイドでもやらないとこのまま消えて無くなるから必死なんだろ

[0582 デフォルトの名無しさん 2022/08/17(水) 12:58:48.28 ID:fQshOXYb]

>教官付きマニュアル教習車だな。
これは言い得て妙だな

[0583 デフォルトの名無しさん 2022/08/17(水) 13:05:23.96 ID:hpgzuSC5]

静的型付け言語は全てそのパターンだから
実行前にコンパイラに全てを静的にチェックしてもらい指導に従うパターンがプログラミング言語の最高峰なのではないかな

[0584 デフォルトの名無しさん 2022/08/17(水) 14:13:12.92 ID:9cI+CXMq]

最高峰ww

[0585 デフォルトの名無しさん 2022/08/17(水) 14:16:02.99 ID:3noakHYk]

ろくに準備をせずに登頂を試みると命に関わります

[0586 デフォルトの名無しさん 2022/08/17(水) 14:27:25.73 ID:8HFMEcaY]

めんどくささでは最高峰だよなぁｗ

[0587 デフォルトの名無しさん 2022/08/17(水) 14:52:45.44 ID:+DmyoQ23]

>>586
本気か？
静的型付け言語をめんどくさいと言うやつはプログラマーに向いていない

[0588 デフォルトの名無しさん 2022/08/17(水) 15:02:44.38 ID:nGJKKwlR]

かまちょ！

[0589 デフォルトの名無しさん 2022/08/17(水) 15:14:47.69 ID:8HFMEcaY]

>>587
ものによるだろｗ
頭悪い奴の方が型に依存しないと物を作れ無さそうだしｗ
全く逆だなｗ向いてないのはお前ｗ

[0590 デフォルトの名無しさん 2022/08/17(水) 15:39:54.22 ID:tUbX57fg]

その件は昔からはっきり答えが出ている
まともにプログラミングするならば静的型付けが必須
動的型付けだと実行時にムダにデバッグ時間を奪われて効率が悪い
いずれそのことを学習すると動的型付け言語から静的型付け言語へ移っていく
典型的な例がJavaScript(動的型付け)からTypeScript(静的型付け)へ

[0591 デフォルトの名無しさん 2022/08/17(水) 16:35:25.14 ID:OH5RfCzZ]

俺は型が無いとコードかけないな
メソッドの名前の一部しか覚えてなくてサジェスト機能に頼りまくってるわ

[0592 デフォルトの名無しさん 2022/08/17(水) 17:14:40.55 ID:UcZjJMoG]

>>590
ウェブのフロントエンドしかやってない人はその辺理解できない人多い印象
動けばオッケーなんだろね

[0593 デフォルトの名無しさん 2022/08/17(水) 17:44:11.47 ID:8HFMEcaY]

>>592
逆じゃね？
むしろフロントエンドに型とかいらんだろｗ元々javascriptなのだし
JavaとかC#とかだとjsonをデコードする為にもクラス用意したりとか逆にめんどくさく感じるわ
ほぼ一人のプロジェクトでクライアント側はUnity(C#)とかだったりするから仕方なく用意しているが
管理画面(vue等)でフロントも書いてるけどjsのままで不便だと思った事すらないし
TypeScriptなんか導入する気にもならんｗ

[0594 デフォルトの名無しさん 2022/08/17(水) 18:03:01.95 ID:nsDziyoO]

>>593
一人でやってるからじゃね？

[0595 デフォルトの名無しさん 2022/08/17(水) 18:06:52.80 ID:mUpHy2T2]

状況に合わせて使う道具を変える判断力すら持ち合わせてないやつは自称プログラマーでも最底辺だからな
適性はないよ

[0596 デフォルトの名無しさん 2022/08/17(水) 18:09:47.20 ID:YQ8B9Inh]

>>594
彼は趣味グラマだから涙
チーム開発の苦労とは無縁なのだ。

[0597 デフォルトの名無しさん 2022/08/17(水) 18:29:38.04 ID:UFtMHmKs]

このスレでRustなどを叩いている>>593氏ってやっぱりレベルがかなり低い人だったんだな

[0598 デフォルトの名無しさん 2022/08/17(水) 18:30:00.14 ID:UcZjJMoG]

>>593
デバッグが手間だから静的型付けが必要、という文脈なんだけど？
結局あなたが言ってるのは動けばオッケーってことでは？

[0599 デフォルトの名無しさん 2022/08/17(水) 18:52:35.57 ID:Lz3roYDy]

動的型とは端的に言えば値に型情報が付属していることであり、おそらくお前らは何か誤解している。
型を指定しないことが動的だと思っているんじゃないか？
図星じゃないか？

[0600 デフォルトの名無しさん 2022/08/17(水) 19:16:27.92 ID:/AaT26gR]

実行時の値とソースコードの変数の違いは重要だけど、この違いを意識しているプログラマーは少ないよね。

[0601 デフォルトの名無しさん 2022/08/17(水) 19:28:56.47 ID:rIjBJHpR]

実行前にコンパイル時点で静的に型も確定する静的型付け言語がベストだな

[0602 デフォルトの名無しさん 2022/08/17(水) 20:10:33.59 ID:QLQjt20q]

>>572
Nimはダメだよ
例えばref objectな変数は初期化も何もされないからヌルポ状態となり実際にSIGSEGVで落ちる

もちろんNimでもRustｂﾆ同様のoptionｂgえばヌルポｂﾅきるけｂﾇ
Nimでは前述のようにoptionを使わないコードも許されるからヌルポが起きてしまう

[0603 デフォルトの名無しさん 2022/08/17(水) 21:22:11.22 ID:cjKd/U5p]

Kotlin Rust Swift ← Null安全な新世代言語
Go Nim ← Null安全ではない旧世代言語

[0604 デフォルトの名無しさん 2022/08/17(水) 21:32:11.18 ID:daPCs1sI]

Swiftって将来性あんのかね
アップル依存大きすぎな時点で知れてると思うんだけど

[0605 デフォルトの名無しさん 2022/08/17(水) 22:14:45.59 ID:NE7yPquC]

>>559
多くのcli コマンドが go, rust で再実装されつつあるのは perl, python, ruby のようなスクリプト言語から go, rust といったちょうどよいモダンさのあるコンパイル型言語への大きな流れがある気がしている。

[0606 デフォルトの名無しさん 2022/08/17(水) 23:47:09.64 ID:tVto1F2t]

>>600
値と変数じゃなくて昔はデータ構造とアルゴリズムの違いを意識していた

どのような演算を想定しているかという型情報を
被演算子の側に付属させるというアイデア自体が
演算子と被演算子を一体化させ、両者を分けて考えない原因になった

[0607 デフォルトの名無しさん 2022/08/18(木) 08:11:22.29 ID:YglC0db6]

動的型付け言語のメリットてなんだ？
(習得が容易とか書き心地とかを除いて理論的なメリット)

[0608 デフォルトの名無しさん 2022/08/18(木) 08:38:35.77 ID:SRglimcB]

>>607
処理系の実装が容易
型検査いらないしホストの実装が直接的に実行時の動作を記述するため圧倒的にシンプル

[0609 デフォルトの名無しさん 2022/08/18(木) 08:39:41.85 ID:ywzuYu7m]

>>607
インスタンスの型判定を実際のインスタンスで行うことができるので、コードの適用範囲が広くなる。

C++を理解しているなら、dynamic castの適用事例を考えればいい。総称型で保管して具象型で使用するようなケースが代表的。

[0610 デフォルトの名無しさん 2022/08/18(木) 09:15:09.69 ID:X/mZUHYK]

>>608
> 型検査いらないし
実行時にやるだろ
なので動的型付け言語の多くはインタープリタ
ネイティブコンパイル言語だと逆に結構大変だよ

[0611 デフォルトの名無しさん 2022/08/18(木) 09:44:19.64 ID:zAUamPod]

実行時の型検査なんて、存在しないメンバにアクセスしようとしたらエラーとかオペランドが特定のデータ型でなければエラーといったルールを、演算子やオブジェクトの実装に組み込むだけだよ
ホストとの間で実行モデルやオブジェクトモデルを共有してるから楽勝
JITの場合もオブジェクトモデルは共有するから比較的簡単

[0612 デフォルトの名無しさん 2022/08/18(木) 09:50:57.04 ID:X/mZUHYK]

そんな言い方するなら静的型付け言語もコンパイル時にやるだけで似たようなもんだろ

[0613 デフォルトの名無しさん 2022/08/18(木) 09:55:55.60 ID:zAUamPod]

全然違うよ
ホスト言語で直接実装すりゃいいだけだからな
JITの場合も極限のパフォーマンスを求める静的型とは違ってホスト言語で書かれたランタイムの呼び出しを多用するのが普通だから、
インタプリタと大差ないし徐々にランタイムを使わないように改良していくアプローチが採れる

[0614 デフォルトの名無しさん 2022/08/18(木) 10:05:05.63 ID:X/mZUHYK]

>>613
型チェックとどこが違うのか具体的に書いて
あとホスト言語という謎用語使うならちゃんと定義してくれ
（ホスト言語自体はDSL界隈とかで使われてるけどコンパイラとかの文脈で使ってるの見たことない）

[0615 デフォルトの名無しさん 2022/08/18(木) 10:15:42.84 ID:zAUamPod]

事前に型検査をやろうとすると予め静的な型のモデルを厳密に定義しなきゃいけないでしょ？

[0616 デフォルトの名無しさん 2022/08/18(木) 10:30:27.96 ID:zAUamPod]

途中書き込み失礼
一方で動的型の場合、実行時のオブジェクトモデルさえ定義されていれば実行時の検査が可能であり、静的な型モデルと実行時のオブジェクトモデルの両方を厳密に定義する必要がない。
平たく言えば、実装が仕様だ、みたいな進め方をすることが難しいわけだ
更に、リフレクションが可能な処理系の場合には静的型であっても実行時に型検査を行う必要があるよね。

[0617 616 2022/08/18(木) 10:54:49.56 ID:EMP5KmCe]

> 平たく言えば、実装が仕様だ、みたいな進め方をすることが難しいわけだ
は静的型の場合ね。念のため。

[0618 デフォルトの名無しさん 2022/08/18(木) 11:15:33.98 ID:wupTTNap]

>>607
インタプリタのメリットは自分自身をコンパイルするコンパイラを作らないこと
言語は二つ以上になってしまうがそれでいい

他にもGCを実装する言語がGCに依存するんじゃないかとか
型情報を定義する言語がーとかいう問題に対する煩悩が消える

[0619 デフォルトの名無しさん 2022/08/18(木) 11:54:36.40 ID:u9P7LJR3]

>>615
型のモデルとかイマイチよくわからんが定義は必要だろ
動的型付でも実行時には必要なんだし

>>616
> 更に、リフレクションが可能な処理系の場合には静的型であっても実行時に型検査を行う必要があるよね。
動的型付と類似の処理だからね
そういう意味で面倒というならまだわかる

[0620 デフォルトの名無しさん 2022/08/18(木) 11:55:56.17 ID:Qribcf4L]

言語を作る側のメリットしかわかんねぇの？
言語を作る側じゃなく使う側のメリットを聞いてんだろ

[0621 デフォルトの名無しさん 2022/08/18(木) 12:42:07.20 ID:mMaPRsFU]

>>608
ツリーウォーク型のインタプリタなら楽だろうけど、速度出すにはJITとか考えないと行けないし、コンパイラ書くのと大差ない気がする

[0622 デフォルトの名無しさん 2022/08/18(木) 12:57:08.67 ID:ywzuYu7m]

>>620
具体的な実装をギリギリまで遅らせることができる＆設計が間違っていても無理やり嵌め込むことができる。
プロトタイピングとかライブラリ開発とかで楽できるし、リファクタリングで段階的に仕様を固めることができる。

最終的には静的型付けの方が堅牢になるけど、最初からミス無く設計するのは無理だから、開発初期は動的型付けの方が有利。

[0623 デフォルトの名無しさん 2022/08/18(木) 13:30:03.60 ID:wupTTNap]

>>620
言語でも仕事でも持続可能性のためには作る側が儲かるぐらいがちょうどいい

[0624 デフォルトの名無しさん 2022/08/18(木) 13:42:10.72 ID:u9P7LJR3]

>>620
>>608 から読み直せ

[0625 デフォルトの名無しさん 2022/08/18(木) 14:00:24.69 ID:gIZ4t15q]

Juliaはここに入らんの？

[0626 デフォルトの名無しさん 2022/08/18(木) 14:19:26.19 ID:yhLXdudb]

ぬるぽ

[0627 デフォルトの名無しさん 2022/08/18(木) 14:28:23.47 ID:PTM9RcdX]

もちろんプログラマーや生成物実行者やサービス利用者にとっては静的型付け言語の方が大きく有利
プログラミングも静的型付け言語は支援が大きく楽だし実行時デバッグも減らせる
そして実行速度も静的型付け言語の方が速くできるため実行者やサービス利用者も時間の節約や応答性の良さを得られる

[0628 デフォルトの名無しさん 2022/08/18(木) 14:31:48.41 ID:NacqCDdf]

>>624
>>608とか一番ダメな回答じゃん
このスレでイキってるやつらって結局このレベルなんだな
視野狭窄

[0629 デフォルトの名無しさん 2022/08/18(木) 14:33:36.79 ID:iuGFLMr5]

>>627
使い分けができない人の典型的な言い訳ですね

[0630 デフォルトの名無しさん 2022/08/18(木) 14:36:30.08 ID:X/mZUHYK]

>>628
だからダメダメって言ってるのに横からアホみたいに絡んでくるなよ

[0631 デフォルトの名無しさん 2022/08/18(木) 15:54:24.58 ID:bwUj40G0]

>>630
ダメさ加減は君も引けを取ってないぞ
イキり加減もねw

[0632 デフォルトの名無しさん 2022/08/18(木) 16:45:13.83 ID:X/mZUHYK]

はいはいw

[0633 デフォルトの名無しさん 2022/08/18(木) 16:58:47.72 ID:EY8RcqaI]

小規模なプログラムを早く作りたいというときに
動的型付け言語は向いている

[0634 デフォルトの名無しさん 2022/08/18(木) 17:26:35.30 ID:wupTTNap]

main関数の型がいつも同じなのはシェルが静的型付けではないからだ
設定より規約
独自のユーザー定義型を設定しなくても使える

[0635 デフォルトの名無しさん 2022/08/18(木) 18:13:32.09 ID:BsTRP920]

>>622
あえて突っ込んでみるが

>具体的な実装をギリギリまで遅らせることができる
to_foo()できるFooableなインスタンスを受け取る前提でBarを作るみたいなのは動的型付けでも静的型付けでも同じじゃない？

>設計が間違っていても無理やり嵌め込むことができる。
これも動的型付けでも静的方付けでも同じじゃない？
渡す型が間違ってるみたいなのは設計間違いというよりコーディングミスでしょ

[0636 デフォルトの名無しさん 2022/08/18(木) 18:32:21.72 ID:yLDzsouG]

>>607
今やない
モダンな言語は静的型だけど動的型のように書けるから

[0637 デフォルトの名無しさん 2022/08/18(木) 19:10:46.93 ID:74ku3J2B]

>>635
＞なインスタンスを受け取る前提

そういう前提を開発当初に決められなかったり、そもそも問題領域に対する知見が足りなくて手探りで開発を進めるたり。当然「前提」が間違っていることもある。
間違うことを前提に「とりあえず動くものを用意して情報収集しながら開発する」というプロトタイプ開発だと、静的型付けは設計が重すぎて使いづらい。そういうケースだと柔軟性の高い動的型付けの方が便利。

[0638 デフォルトの名無しさん 2022/08/18(木) 20:34:52.46 ID:kuToBQFh]

テスト書かないで書き散らすなら静的型はミスが生じにくい分本来的には有利だと思うけどね
ただ、静的型ってモデルとビューモデルみたいな似た型を複数作って左から右に渡すような設計をしがちだからコード量が増えやすいんだよね
静的型でも共通の型を使い回して重複を発生させないことはできるだろうけど、動的型と違って型が目に見えてしまうもんだから、
オプショナルな属性だらけの汚い型が目についてしまって、心理的に適切に型を使い分ける設計になりがち

[0639 デフォルトの名無しさん 2022/08/18(木) 20:43:30.66 ID:uPozsGij]

そもそもメンテをするつもりもテストをするつもりもない程度の用途なら、短いコードで完結に書けることが多い動的型言語は比較的有利そうだね
まあそういうときはなんでもいいから一番慣れてる言語を使えばええやんって感じだが

[0640 デフォルトの名無しさん 2022/08/18(木) 20:59:53.63 ID:VW7TsRc4]

>>637
いや、それは型推論の無かった静的型言語を使ってた時代の話だよ。
今時の言語は型推論あるからコード書く分には動的型言語と遜色ない。

いくら動的型言語が柔軟だと言ったって想定と異なる型のデータで関数なりメソッドなり呼ばれれば、その部分は動かない。下手したらデータ破壊しながら処理進めてしまいかねん。

[0641 デフォルトの名無しさん 2022/08/18(木) 21:02:31.69 ID:4Dlj1ckV]

>>638
そのあたりの問題は最近の静的型付け言語は既に解決済みではないかな
そういう様々な異なる型に対して、横断的な共通の扱いをしたいならば、
例えばRustでは用途ごとに3通りの対応方法を提供しているよね
(1) ボディ付きenumによる複数の異種型の横断的な収容
(2) impl Traitによる複数の異種型の横断的な共通振る舞いとその静的モノモーフィゼーション
(3) dyn Traitによる複数の異種型の横断的な共通振る舞いとその動的ディスパッチ

[0642 デフォルトの名無しさん 2022/08/18(木) 21:10:33.58 ID:ame2S//5]

プロトタイプには動的型って一見もっともなんだけど
じゃあいつ本番開発に移行すんの？ってのは気になるな
結局ある程度動き始めたらそのままズルズル行っちゃうのでは？
それとも「今日から静的型で書き直すので一ヶ月開発止まります」とかやるの？

[0643 デフォルトの名無しさん 2022/08/18(木) 21:10:45.17 ID:kuToBQFh]

>>641
そんな小難しいことを最初から真面目に考えて設計しなければならない時点で遅いんだよ

[0644 デフォルトの名無しさん 2022/08/18(木) 21:13:42.36 ID:pjyB7/7f]

動的型だと素早く開発できるという話は品質を犠牲にすれば素早く開発できるという話と同じ匂いを感じる

[0645 デフォルトの名無しさん 2022/08/18(木) 21:17:56.92 ID:4Dlj1ckV]

>>643
え？めっちゃ簡単な話しかしていないし
最初から設計せずとも後付けで型ごとに自由なタイミングで任意の対応traitを増やしていける仕組み

[0646 デフォルトの名無しさん 2022/08/18(木) 21:18:41.05 ID:FZFlEvPV]

かといってサーバーサイドに静的なJavaを導入して安全か？と言われてもなぁｗ
PHPだから危険なのか？という話だし
そもそも関数で引数に型の指定があるない関わらず期待した型じゃないと普通動かないし
静的だから安全というのは何か間違ってる気がするわ

[0647 デフォルトの名無しさん 2022/08/18(木) 21:24:02.04 ID:zSwNEg3i]

>>637
前提が間違ってた場合の修正範囲に
動的型付けと静的型付けで顕著な違いが出る？
出るならそれを具体的に説明してよ
できれば簡単な擬似コードとかで

柔軟性が高いとか設計が重いとか言うだけだと説得力が乏しい

[0648 デフォルトの名無しさん 2022/08/18(木) 21:25:00.81 ID:yMU9W3g1]

>>646
動的型付け言語でそれなりの規模のもの書いてたら
関数の引数の型が想定と違った結果
非常に調査が難解なバグとかエラーが出た頃には
致命的な結果になってるとか経験しませんかね…

[0649 デフォルトの名無しさん 2022/08/18(木) 21:25:37.80 ID:kuToBQFh]

>>642
>>644
まあそれはある
大抵、プロトタイプと言いながら作り過ぎなんだよ
本来プロトタイプってのは本当に必要最低限のハリボテで十分で、実際に客から金貰って売る前にPMFが完了していなければならない
現実として、そこまでやれるほど優秀なプロダクトマネージャはまず存在しないから、大抵のスタートアップは作って売ってから考えるという馬鹿な状況になる

[0650 デフォルトの名無しさん 2022/08/18(木) 21:26:20.58 ID:4Dlj1ckV]

>>646
そのあたりも最近の静的型付け言語が対応しているでしょう
例えばRustならば引数に対して型指定ではなくtrait指定にできるし
その具体化解決は静的にも動的にも可能だし
もちろんいずれも安全に適用できることをRustでは保証される

[0651 デフォルトの名無しさん 2022/08/18(木) 21:43:21.22 ID:mZ+fH4d1]

>>646
わかる
何か間違ってるよね

極端に言えば
「濡れた猫を電子レンジで温めようとしたらエラーで弾いてくれるから安全」
と同じイメージ

[0652 デフォルトの名無しさん 2022/08/18(木) 21:43:46.51 ID:vUREPivo]

>>643
？？？
動的型付け言語による開発でもこの程度の設計は必要だろ

[0653 デフォルトの名無しさん 2022/08/18(木) 21:48:40.33 ID:rKyKXmu0]

>>641
「ModelとViewModelみたいな似た型」で普通そんなことするんか？
したことあるんか？
そうさせるFWがあるんか？

[0654 デフォルトの名無しさん 2022/08/18(木) 21:57:29.78 ID:3gZlWdNz]

>>651
その場合だと
静的型付け言語ならば実行前にそれは危険だとコンパイルエラーで教えてくれて未遂で済む
動的型付け言語ならば実行してしまってネコ死んじゃったエラー

[0655 デフォルトの名無しさん 2022/08/18(木) 22:02:54.58 ID:UNnRVh9z]

>>648
ぶっちゃけないな
型の想定が違ってるのにそれらしく動いて
かつテストでも発見できないバグで
かつ調査が難解となると相当にレアでしょ

それに定義してる型とあっているからと言って
ドメインエラーを常に拾えるわけじゃない

[0656 デフォルトの名無しさん 2022/08/18(木) 22:08:16.63 ID:sNPBcISa]

>>654
猫を電子レンジに入れて本番で実行するような開発者のいるプロジェクトなら
動的型付け言語に比べたら静的型付け言語のほうがリスクは低いだろうね
ただそういう開発者を排除するほうが遥かに安全性が高いと思うよ

[0657 デフォルトの名無しさん 2022/08/18(木) 22:11:31.85 ID:i8FqLiOp]

静的型付け不要って主張してるのはPHPおじさんしかいないようだけど
何でこのスレにいるのかわからん

[0658 デフォルトの名無しさん 2022/08/18(木) 22:13:54.84 ID:FZFlEvPV]

>>657も何でいるのか分からんｗ
PHPやってていたらダメとか偏見も良い所
こんな事言っている奴はPHPでも作れんだろｗ

[0659 デフォルトの名無しさん 2022/08/18(木) 22:14:06.50 ID:rKyKXmu0]

類は友を呼ぶ

[0660 デフォルトの名無しさん 2022/08/18(木) 22:19:32.70 ID:yMU9W3g1]

>>655
テストで担保というのが手間でしょ
カバーできてなくて本番のランタイムで
エラーを経験してことないのはよっぽど
丁寧に書いているか大してもの作ってないかの
どっちかだね

あと関係ないドメインエラーとか待ちだすのは
詭弁論破の練習？

[0661 デフォルトの名無しさん 2022/08/18(木) 22:45:49.60 ID:VW7TsRc4]

>>656
で、そういう人を排除できてんの？

[0662 デフォルトの名無しさん 2022/08/18(木) 22:48:29.89 ID:VW7TsRc4]

>>655
＞それに定義してる型とあっているからと言って
＞ドメインエラーを常に拾えるわけじゃない

0か100の世界線の人ですか？
エラーは早い段階でわかったほうがいいというのは世界の常識だけど、お前の世界線では違うみたいだな。

[0663 デフォルトの名無しさん 2022/08/18(木) 22:56:27.19 ID:4eWuEs9Z]

猫とか車とか飯とか脳みそOOPかよ
お前らのしょうもない例え話は実害があるから本当迷惑なんだよ

[0664 デフォルトの名無しさん 2022/08/18(木) 23:30:39.35 ID:eFgxNJYT]

>>660
「あーそれなら確かに静的型付けにしてたら有利だね」
って言う現実的なコード例出してみてよ

ドメインエラーってのは
文字列を期待してるところに数値を渡したり
注文番号を期待してるところに配送番号を渡したり
First Nameを期待してるところにLast Nameを渡したりした状況のこと

[0665 デフォルトの名無しさん 2022/08/18(木) 23:36:33.83 ID:RTRtwr2z]

>>664
それぞれ別の型にしておけば静的に型チェックにて実行前にミスを無くせる
それよりも「文字列を期待してるところに数値を渡したり」が型不一致エラーとならない超弱い型付け言語を使ってるのかね？

[0666 デフォルトの名無しさん 2022/08/18(木) 23:40:19.24 ID:XhNJQXKP]

>>665
で現実にFirstName型とLastName型を定義して使い分けてるのかね？
OrderId型くらいなら使ってるところそこそこあるが多数派ではないわな

[0667 デフォルトの名無しさん 2022/08/18(木) 23:42:51.05 ID:yMU9W3g1]

>>666
お前さあ
自分の都合の良いように設計論の話と
どっかの現場の話を切り分けて話するのも
詭弁論破の練習？

[0668 デフォルトの名無しさん 2022/08/18(木) 23:52:50.33 ID:R+uszVYm]

>>667
答えられなくなったから逃げてるのかね？
静的型付けマンセーで思考停止してるのでなければ少しは考えてみれば？

[0669 デフォルトの名無しさん 2022/08/19(金) 00:09:50.57 ID:aSCRajpd]

>>666
FirstNameとLastNameを間違えるのはプログラミング言語やその型付け方法と関係ない話
そして静的型付け言語が不利になる話でもない
それにより何を主張したいのか？

もし本当に厳格に区別する必要があるならば各々を扱う専用型を設ければよい
そうせずに両方を文字列型で扱っても、変数名、フィールド／メンバー名、関数／メソッド名などの名付けを分ければ互いに入れ違いを避けられる

[0670 デフォルトの名無しさん 2022/08/19(金) 00:12:18.59 ID:0E/6U7Rf]

>>668
いやーすごいすごい完全論破されちゃったな
これでOK？

[0671 デフォルトの名無しさん 2022/08/19(金) 00:32:53.46 ID:QXliTxmo]

ドメインエラーとか型付けと関係ない話持ち出してきてるのは何なん？
型が何なのかわからん奴なんだろうな。そりゃ型付きが面倒・邪魔に感じるだろうよ。

[0672 デフォルトの名無しさん 2022/08/19(金) 00:40:23.18 ID:Djh9jYCC]

KEИTAωωω

[0673 デフォルトの名無しさん 2022/08/19(金) 00:45:33.75 ID:I3mMZROB]

変数に型がないRubyとかでも、ドメインモデリングするならバリューオブジェクトのクラスも作るし、
変数に型がある言語でもメンテの必要があるアプリケーションならテストコードは必須だろ

どっちがどういいかはトレードオフがあるだけ

[0674 デフォルトの名無しさん 2022/08/19(金) 07:54:59.22 ID:Ue9BSEu6]

静的型であっても型推論なら姓と名の型をそれぞれa, bとして
どっちもstringと確定するまではaとbは区別される
aとbが入れかわるコードが紛れ込んでいたらstring確定しなくてもa=bは確定

[0675 デフォルトの名無しさん 2022/08/19(金) 08:02:21.75 ID:QtzKKzJh]

そもそも、ここに書き込んでるような人は、意識高い人だから、自分を基準に考えてはダメでは？

[0676 デフォルトの名無しさん 2022/08/19(金) 08:09:54.91 ID:slQGFe9J]

スレタイにある次世代言語は全て静的型付け言語
静的型付け言語が圧倒的に優れているため全てがそうなっている
動的型付け言語には次世代言語が存在しない

[0677 デフォルトの名無しさん 2022/08/19(金) 08:39:00.86 ID:xzucV8hS]

>>647
Visitorパターンみたいな処理をする時かね。静的型付けだと型を識別するためにacceptが必要だけど、動的型付けなら動的に型を判定することで手を抜ける。

まぁ、そもそも静的型付け言語も動的な型判定をある程度取り込んでいるからなぁ。パターンマッチとか。
型判別可能な共用体を使える静的型付け言語なら、上手いこと動的に判定する範囲を制限できる。
けど、そういう言語てあったっけ？

[0678 デフォルトの名無しさん 2022/08/19(金) 08:54:53.36 ID:51hioa9S]

>>677
型判別可能な共用体はまさに>>641の(1)でしょう
それに加えてジェネリックから型を制限していく(2)や(3)の方法も可能

[0679 デフォルトの名無しさん 2022/08/19(金) 09:24:26.81 ID:9PLRQWOj]

今回セレクトされてないけどElixirとJuliaは動的型付けだね
Elixirはerlangの系譜だから特にこだわりがないかもしれないがJuliaが動的型付けなのは示唆的に思える

[0680 デフォルトの名無しさん 2022/08/19(金) 10:07:48.19 ID:Qq/sBFnc]

juliaが目指したのがpythonの置き換えだからでしょ。

[0681 デフォルトの名無しさん 2022/08/19(金) 10:24:36.76 ID:2gSW30An]

Juliaは少量のコードで大量の計算をする言語だからJITに無茶苦茶時間かけても大して問題にならないし、
そもそも数値計算で扱う型って整数と浮動小数点数とその配列が殆どで、型を厳密に扱う必要性が薄い
同様にFORTRANなんかも型は緩めだよ

[0682 デフォルトの名無しさん 2022/08/19(金) 11:40:00.25 ID:Qq/sBFnc]

型というかテンソルのshapeとかは気にするけどね。
ただ型というよりもうちょっと具体的というかレイヤーが低いとこでの合わせって感じではある。

[0683 デフォルトの名無しさん 2022/08/19(金) 11:47:47.45 ID:iXvbHE7r]

行列の大きさとかを型で指定したいと思うことはあるけどIdrisにあるような依存型が必要になるのかな
ちゃんと勉強してないからわからんw

[0684 デフォルトの名無しさん 2022/08/19(金) 12:07:38.97 ID:xzucV8hS]

>>678
ボディ付きenumというのはF#の判別共用体のことかしらん。Haskellだと直和型かね。

[0685 デフォルトの名無しさん 2022/08/19(金) 14:15:06.23 ID:F2zWUaSx]

>>684
いわゆる代数的データ型だな。
プログラミング言語によってそれを、
直和で表したり、
タグ付き共用体で表したり、
値格納付きenumで表したり、
視点は各々で異なるが同じもの。

[0686 デフォルトの名無しさん 2022/08/19(金) 18:07:04.50 ID:jOBplE6P]

Rustはデストラクタ内のエラーは無視される実装が多いので、
IO絡みのデータ構造はdropされる前にflushなりsync_allなり呼び出さないけないが、忘れられがちで誤ってプログラムが世に溢れている
このあたり良い感じに処理してくれる安心なシステムプログラミング向け言語ってありますか？

[0687 デフォルトの名無しさん 2022/08/19(金) 18:15:52.02 ID:J75ESMlr]

いい感じってなに

[0688 デフォルトの名無しさん 2022/08/19(金) 18:39:22.66 ID:EVfb4y4d]

RustはC++の3倍速い。

[0689 デフォルトの名無しさん 2022/08/19(金) 19:04:29.00 ID:jOBplE6P]

>>687
Rustベースで考えるならスコープ終端でのdropまでに特定の関数を呼び出していない場合コンパイルエラーにしてくれるようなものを想像している
標準ライブラリやサードパーティーライブラリもこのルールに従って作られていてほしい
?で関数の途中で抜けた場合はエラーにしない

[0690 デフォルトの名無しさん 2022/08/19(金) 19:10:51.99 ID:J75ESMlr]

>>689
ラッパー作ってDrop実装してその中で「特定の関数」を呼べばいいんじゃね
dropの前にflushなりsync_allなり呼ぶべきかは用途次第だと思う

[0691 デフォルトの名無しさん 2022/08/19(金) 19:20:17.50 ID:jOBplE6P]

>>690
それはFile等従来の構造体でもやっている
dropの中でエラーが発生した場合にpanicくらいしか呼び出し元に伝える手段がないのが問題
標準ライブラリでは単にエラーを無視する実装になっていて、他のライブラリも多くは同じだと思う

[0692 デフォルトの名無しさん 2022/08/19(金) 19:34:55.23 ID:J75ESMlr]

> dropの中でエラーが発生した場合にpanic

そっか
つらいね

[0693 デフォルトの名無しさん 2022/08/19(金) 19:37:53.86 ID:CKALhjuS]

Rustプログラマはすぐにpanicに頼る
アホなんだろうなと

[0694 デフォルトの名無しさん 2022/08/19(金) 19:39:05.15 ID:VXXXJYAW]

>>686
ない
良い感じに処理してくれる時点でシステムプログラミング言語ではない
システムプログラミング言語とは良い感じ処理してくれるシステムを作るための言語である

[0695 デフォルトの名無しさん 2022/08/19(金) 20:02:15.51 ID:/KG0lVfm]

>>691
ぶっちゃけどんな言語でもデストラクタ的な処理を途中で止めるのはダメじゃね？
そういうのは本来は独立した関数なりメソッドなりにするしか無いと思うが。

[0696 デフォルトの名無しさん 2022/08/19(金) 20:23:10.52 ID:F2zWUaSx]

>>693
それは逆でpanicは続行不可であり、
続行のためには発生してはいけないこと。
つまり続行させるつもりがないならば、
panicを引き起こしても構わない。
続行させる意志がある場所ならば、
自分でエラー処理を書いてpanicを発生させない。

>>695
もちろん用意されているので、
それを自分で呼べばエラー発生したかどうかも掴める。
そして、デストラクタでpanicすることもない。

[0697 デフォルトの名無しさん 2022/08/19(金) 20:55:29.37 ID:v6FNs4oE]

コンパイルエラーにするためにはどの経路を通っても終了処理を経由すると解釈できなくてはならないけどそれってあまり簡単ではなくないか

[0698 デフォルトの名無しさん 2022/08/19(金) 22:59:39.17 ID:Ue9BSEu6]

dropの呼び出し元ではなく
JoinHandle::joinの呼び出し元に結果を伝えればいいんでしょ
実際、panicの引数はjoinの戻り値になる

[0699 デフォルトの名無しさん 2022/08/19(金) 23:12:28.82 ID:4ESWFAwS]

>>689
自分でcontext manager的なものを作るのがいいと思う
flush以前にエラーが発生してる場合にflushすべきかどうかは
アプリロジックなのでコンパイルエラーにするのは何か違う気がする

[0700 デフォルトの名無しさん 2022/08/20(土) 01:26:15.59 ID:O8Vd08Ya]

>>689
アホか。
write(2)のマニュアルのエラー項目を読み直せ。
コンパイル時点で全部対処できると思ってるのかよ。

[0701 デフォルトの名無しさん 2022/08/20(土) 03:52:49.34 ID:fWT+hW9e]

>>695
その通りで原則drop内でエラーが発生しうる処理はやらせるべきではないよね
だからエラー発生しうる処理がdropに至るまでに呼び出されているかコンパイル時に検知できると良い

>>697
プログラムの実行パス内で値がmoveされたか否かの解析が現状できているので、それと同じ仕組みでできるのではないかな

>>698
マルチスレッドならそれでも良いけど、単なるIOで必ずスレッドなりタスクなり生成させるのはよろしくない
catch_unwindでも良いがあらゆるpanicをせき止めてしまうのはオーバーキルすぎる

>>699
そういうことではなくて、drop内でエラーが起きた場合の話を気にしている
flushを呼び忘れてスコープ終端に到達してしまった場合ね
BufWriterなんかだと書き込みデータ量が少ない場合にwrite(2)が一度も呼び出されないままdropが呼び出されて、
そこで初めてwriteしようとしてエラー検出されることがある
BufWriterのドキュメントにはdrop前にflush呼ぶようにとは書いてあるが、プログラマが気をつけるのではなくできる限り機械的に検知できるようにしたいよね

[0702 デフォルトの名無しさん 2022/08/20(土) 04:00:19.70 ID:fWT+hW9e]

>>700
コンパイル時にIOエラーに対処せよなんて話はしてないよ
そもそもコンパイル時にwrite(2)が呼び出されないんだからそのエラーに対処できるはずもない

drop内でエラーが発生しても検知できないから、dropの前にflushなどの呼び出しを強制できないの？という話

[0703 デフォルトの名無しさん 2022/08/20(土) 05:07:56.91 ID:O8Vd08Ya]

>>702
なるほど。
4回目ワクチンのせいで読解力が低下してるようだ。エロいページ見て心を静めてくる。

[0704 デフォルトの名無しさん 2022/08/20(土) 07:41:29.18 ID:Z3gHF10K]

論理的にモノを考えられるヤツは４回も打たない

[0705 デフォルトの名無しさん 2022/08/20(土) 09:18:15.53 ID:LHlXjeki]

医療従事者とか高齢者施設従業員とか正規の4回目来てるんですよ

[0706 デフォルトの名無しさん 2022/08/20(土) 10:31:20.74 ID:s9pWuoyY]

>>701
>そういうことではなくて、drop内でエラーが起きた場合の話を気にしている
わかってるよ
drop前に確実にflushが呼ばれるようにしてflushした場合のエラーをハンドリングしたいなら
context managerを自作するのがいいって話

buffer.len()をチェックしてcompile_error!でエラーにするようなAPIも作れなくは無いかもしれないけど
それをやる場合にもBufWriterへの一連操作をラップしたcontext manager的なのを作ることになるので
エラーにするんじゃなくてflushしてあげたほうが親切

[0707 デフォルトの名無しさん 2022/08/20(土) 11:15:29.57 ID:U3OCGo2f]

なにこれ
ワクチン接種証明書の例え話が役に立つという寓話なのか
fn hoge(&mut self) -> flush証明書 {
flush証明書::new(self.file)
}

[0708 デフォルトの名無しさん 2022/08/20(土) 14:05:39.10 ID:icDL1eXq]

>>686
システムプログラミング向け言語という時点でGC言語は対象外となる
無条件RAIIによる自動デストラクタ呼びを前提としている点でもGC言語は対象外となる

>>689
書き忘れていたらコンパイルエラーにするという時点で
RAIIもどき実現のためのusingやdeferなど使うGC言語はそれを書き忘れてもエラーとしないから
GC言語は前提にすら辿り着けないことになる

結局その機能を現在もしくは今後に実現できる言語は非常に限られている

[0709 デフォルトの名無しさん 2022/08/20(土) 14:47:10.43 ID:fWT+hW9e]

>>706
context managerを知らないんだけど、pythonの用語で合っているかな？
スコープの入り口と出口に処理を差し込むようなものに見えたけど、こんな関数を用意するようなイメージ？

fn with_file(f: impl FnOnce(&mut File) -> io::Result<T>) -> io::Result<T> {
　let file = File::create(...)?;
　let res = f(&mut file)?;
　file.flush()?
　Ok(res)
}

確かにこれで解決するケースも多いね

[0710 デフォルトの名無しさん 2022/08/20(土) 15:11:47.48 ID:icDL1eXq]

>>709
そういう単純な対応は他言語含めてよくあるパターンだが狭い範囲しかカバーできない欠点がある
例えば複数のファイルなどを順序前後して扱うと破綻
その観点の専用クロージャとなっているためそれ以外からの処理を巻き込みたい時にも破綻
ファイルディスクリプタを保持して戻りいつ解放かすぐ決定しない場合も破綻
並行並列化する時も破綻

[0711 デフォルトの名無しさん 2022/08/20(土) 15:25:13.28 ID:45hIb17g]

>>709
こういっては失礼かもしれないけど、なんて汚い実装だ....

[0712 デフォルトの名無しさん 2022/08/20(土) 15:32:14.61 ID:fWT+hW9e]

>>710
だから これで解決するケース "も" ある って書いたでしょ
もっとよいワークアラウンド考えるか次世代言語の仕様提案してくれ

>>711
どこがご不満？

[0713 デフォルトの名無しさん 2022/08/20(土) 16:19:57.30 ID:v+6xr1g0]

>>712
Rustスレで半年前に出ている以下のアプローチはどう？
他の言語では無理だけどRustならば所有権の行方を静的に解析してコンパイラが持っているため

https://mevius.5ch.net/test/read.cgi/tech/1636247099/700
＞ コンパイラは解析してdropさせるべき位置を把握しているから
＞ そこへ至る全ての経路上で例えばFinalize trait実装型はそのメソッドfinalize()を呼んでいないとコンパイルエラーとなる
＞ というような制約をするFinalize trait

[0714 デフォルトの名無しさん 2022/08/20(土) 16:55:09.50 ID:fWT+hW9e]

>>713
それは良さそう
dropに至るまでの処理でエラーが発生した場合はFinalize不要にするとかの考慮は必要そうだね
?で脱出したか否かで区別できるかな？

[0715 デフォルトの名無しさん 2022/08/20(土) 18:48:46.98 ID:s9pWuoyY]

>>709
そう、そういうイメージ
FileManager的なstructを定義してnewするときに内部でFile::createして持っておいて
withでクロージャを受け取るようにするとネストしたりしやすい気がする

buffer.len()とcompile_error!マクロでどうにかする方法は無理そうだった

あとは明示的flush未実行の型と実行済みの型とをそれぞれ作って
一連のI/O処理の戻り値をflush実行済みの型にしておくことで
flush忘れたらコンパイルエラーにするという方法ならできそう
面倒くさいけど

[0716 デフォルトの名無しさん 2022/08/20(土) 19:18:04.66 ID:fWT+hW9e]

>>715
後半のアイディアについてはコンパイルエラーにするのは難しそうだね
dropの呼び出しを禁止したりコンパイルエラーにしたりする方法は多分ないと思う
リンク時エラーにするアイデアはあるみたいだけど、ちとやり過ぎな感がある
https://mevius.5ch.net/test/read.cgi/tech/1636247099/695

[0717 デフォルトの名無しさん 2022/08/20(土) 21:47:48.47 ID:Nnwhfgo3]

リソース確保、開放といった共通化できる操作はテンプレート化したいが、そのために真にやりたい操作をクロージャや関数にして一段ネストを深くしてしまうのがなんか違う気がするんだよなぁ。

[0718 デフォルトの名無しさん 2022/08/20(土) 21:56:02.14 ID:L2ho5Ecd]

システムプログラミングじゃそれが本質的に指摘すべきことなんだから仕方ないだろ。

[0719 デフォルトの名無しさん 2022/08/20(土) 22:17:19.61 ID:INTsXp8j]

>>713のやり方ならば
そのような対応も不要でプログラムの構造も変えずに済むし
関数から返したり長生きしてもよいし
デストラクタでエラーが起きうる型に適用しておくだけでよく
利用側プログラムに他の付加コードは不要だから理想的にみえる

[0720 デフォルトの名無しさん 2022/08/20(土) 22:34:29.93 ID:Nnwhfgo3]

>>719
特定条件のときだけ開放処理が行われるみたいな分岐があるケースとか考え出すと難しくないかな。

まだ finalize してなければ finalize するみたいな処理を Rust が決定したdrop位置の直前に書かせるという制約を課すだけでいいのか？

[0721 デフォルトの名無しさん 2022/08/20(土) 23:34:50.48 ID:INTsXp8j]

>>720
>>713のメソッドfinalize()は最後に呼ばれるべきものだから
Selfで受けて消費しちゃう仕様でもいいよね
するとコンパイルエラーが起きない正しいプログラムでは自動drop()が全てfinalize()の中で起きる
つまりfinalize()以外で自動drop()が起きる部分をコンパイルエラーとすればよいのではないか？
例えばfinalize()を呼ばずにスコープブロックエンドに達しているコードと
ブロックから脱出return/breakしているコードをコンパイルエラーとする

[0722 デフォルトの名無しさん 2022/08/21(日) 00:02:05.58 ID:nsTQcirJ]

>>713は実現不可能だよ

[0723 デフォルトの名無しさん 2022/08/21(日) 00:50:42.36 ID:lVDdCtQC]

>>722
実現できる
コンパイラはdropする可能性のある場所を全て把握していて、そこへdrop()呼び出しコードを埋め込んでいる
つまり>>713を>>721の方法で実現するのは容易
finalize()内以外でdrop()呼び出すコードを必要としたらコンパイルエラーとする対応をコンパイラ加えるだけで実現できる

[0724 デフォルトの名無しさん 2022/08/21(日) 01:16:56.45 ID:WZRwYPWF]

こういう時は自前主義の方が冷静
自前でできないことを期待するのは虫が良過ぎる

[0725 デフォルトの名無しさん 2022/08/21(日) 02:47:44.56 ID:3Twjt0yr]

絵に描いた餅はおいしいですか？

[0726 デフォルトの名無しさん 2022/08/21(日) 05:02:05.10 ID:3JIuIXQv]

>>723
> finalize()内以外でdrop()呼び出すコードを必要としたらコンパイルエラーとする対応をコンパイラ加えるだけで実現できる
それは「現状では」実現不可能って言うんでは？

[0727 デフォルトの名無しさん 2022/08/21(日) 05:25:55.50 ID:s4gkGr9U]

Rustならば現状のコンパイラで実現できる
finalize()を呼び忘れていたらコンパイルエラーとすることが可能

[0728 デフォルトの名無しさん 2022/08/21(日) 09:26:43.80 ID:WZRwYPWF]

他人の現状よりも
自前でできそうな願望がいい

[0729 デフォルトの名無しさん 2022/08/21(日) 10:53:20.77 ID:sMoAQNMJ]

>>721,723
「つまり」の前後の論理が全くつながってない

[0730 デフォルトの名無しさん 2022/08/21(日) 11:04:13.82 ID:E81JiIrb]

つまり
絵にすらなってない餅

[0731 デフォルトの名無しさん 2022/08/21(日) 11:37:20.10 ID:smg3n+sN]

つまり霊感商法

[0732 デフォルトの名無しさん 2022/08/21(日) 12:28:30.42 ID:U3pRzeag]

容易と言い切るなら実装見せて欲しいな

[0733 デフォルトの名無しさん 2022/08/21(日) 13:05:23.69 ID:cZmfpBgr]

つまり複製おじさん論法

[0734 デフォルトの名無しさん 2022/08/21(日) 15:07:41.13 ID:ryFNR8Ig]

つまり「募ってはいるが募集はしていない」的な話？

[0735 デフォルトの名無しさん 2022/08/21(日) 16:22:57.49 ID:DLZoHpre]

つまり
現状のコンパイラで容易に実現できるが
コンパイラに手を加えずに実現できるわけではない
ということでしょw

[0736 デフォルトの名無しさん 2022/08/21(日) 17:39:47.32 ID:3JIuIXQv]

>>735
現状のrustならできるらしいよ ⇒ >>727
なおどうやるかは本人しか知らないみたいだけどw

[0737 デフォルトの名無しさん 2022/08/21(日) 18:17:26.66 ID:TCpdMLkc]

>>735
「現状のコンパイラで実現できる」
というのは
「現状のコンパイラ(の機能を活用してfinalize()内以外でdrop()呼び出すコードを必要としたらコンパイルエラーとする新機能をコンパイラに加えるだけ)で実現できる」
という意味なんでしょw

[0738 デフォルトの名無しさん 2022/08/21(日) 19:08:55.38 ID:FqN0DP7E]

次世代言語の話だから、現行言語をもとに「原理的には可能」で議論も悪かないと思うけどね。

[0739 デフォルトの名無しさん 2022/08/21(日) 19:35:37.95 ID:lf3rkmkM]

悪くはないがコンパイラに手を加える必要があるならそう言わんといかんわな。
しょーもないわかりやすいプライド見せられてもなって気分になるわけで。

[0740 デフォルトの名無しさん 2022/08/21(日) 21:17:28.45 ID:WZRwYPWF]

行動経済学あるある
実験前の説明では「原理的にはどっちを選んでもOK」と言う
実験後「経済的にはこっちを選ぶのはバカ」と言い出す

[0741 デフォルトの名無しさん 2022/08/21(日) 21:53:47.95 ID:CnjAlksW]

話題の要件は「finalize()等の関数を呼び忘れていたらコンパイルエラーにすることができるかどうか」でいいんだよな
そして他の言語ではそれを実現できなくて「Rustで実現できるか否か」という話でいいんだよな

それならば現行のRustで実現可能　実行確認可能なソースコード
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=7086ce3b73ad74a5375e970c7dfc5951

fn main() -> std::io::Result<()> {
let foo = Foo::new("Hello, World!");
foo.finalize()?; // この行をコメントにするとコンパイルエラー
Ok(())
}

struct Foo { s: String, }
impl Foo {
fn new(s: impl Into<String>) -> Self {
Foo { s: s.into() }
}
fn finalize(self) -> std::io::Result<()> {
let mut me = std::mem::ManuallyDrop::new(self);
println!("Finalizing... {}", me.s);
drop(&mut me.s);
Ok(())
}
}
impl Drop for Foo { ...

[0742 デフォルトの名無しさん 2022/08/21(日) 22:38:05.89 ID:5Mzum6WR]

>>741
それ>>716に書いてあるリンクエラーのコードを改変したんだとおもうが
let fooとfoo.finalize()の間に処理挟むだけでリンクエラー発生する

[0743 デフォルトの名無しさん 2022/08/21(日) 22:51:41.20 ID:CnjAlksW]

使い勝手を含めて改善すべき点はあるから
それらはRustコンパイラが直接サポートすることで解決すればよい
例えば>>741でも用いているManuallyDropはコンパイラサポートによりその機能を実現している

[0744 デフォルトの名無しさん 2022/08/21(日) 22:54:16.54 ID:3Twjt0yr]

リンクエラーってコンパイルエラーではなくない？

[0745 デフォルトの名無しさん 2022/08/21(日) 22:56:51.95 ID:3Twjt0yr]

この人これで日曜日丸1日潰したのかな

[0746 デフォルトの名無しさん 2022/08/21(日) 23:03:08.26 ID:U3pRzeag]

proc-macro作るとかclippyのlint追加するとかそういう方向性ならやりようはあるんでないの

[0747 デフォルトの名無しさん 2022/08/21(日) 23:05:54.42 ID:U3pRzeag]

型情報必要だからproc-macroは無理そう
compiler-pluginでなんとかしてくれ

[0748 デフォルトの名無しさん 2022/08/21(日) 23:07:11.79 ID:NvOkjJCY]

コンパイラがサポートすればリンク使わずに済むから真のコンパイルエラーとなるのでプロトタイプとしてはいいんじゃない

[0749 デフォルトの名無しさん 2022/08/21(日) 23:13:22.78 ID:U3pRzeag]

実用上は実行前に検出できれば良いのでリンク時エラーでも問題ないとは思うけど
リンクまでしないcargo checkやrust-analyzerやclippy等で検出できないという違いはあるから
コンパイルエラーとリンク時エラーは区別はした方が良いだろうね

[0750 デフォルトの名無しさん 2022/08/21(日) 23:26:12.30 ID:G9OTg+LF]

Rustではコンパイラ対応で完全版も実現できる見込みが立ったようだけど
他の言語ではどうなの？

[0751 デフォルトの名無しさん 2022/08/21(日) 23:31:54.00 ID:3Twjt0yr]

https://yoshitsugu.net/posts/2021-02-13-linear-haskell.html

Haskellはもうできるってさ

[0752 デフォルトの名無しさん 2022/08/21(日) 23:38:38.83 ID:t5TpzXQK]

>>743
使い勝手の問題に矮小化すんなよ
根本的に使えないじゃん

[0753 デフォルトの名無しさん 2022/08/21(日) 23:43:44.98 ID:sqA1fyA2]

>>742
確かに5行目に関係ないprintln!入れるだけでもエラーになる
何で？？

[0754 デフォルトの名無しさん 2022/08/21(日) 23:46:14.60 ID:G9OTg+LF]

>>751
関数型言語らしい観点からの拡張だね
Haskell側でもRustのborrow checkerについて言及してる点も興味深い
でもそのHaskellの拡張で今回のfinalize未呼び出し検知を静的に実現できるの？

[0755 デフォルトの名無しさん 2022/08/21(日) 23:54:38.26 ID:HHEr7LbV]

そもそものアプローチが間違ってるから
他の言語でどうこう言っても意味がない

[0756 デフォルトの名無しさん 2022/08/21(日) 23:59:27.31 ID:NvOkjJCY]

>>753
そこで関数呼び出しなどがあると
panicなどで巻き戻される時にfooを解放する必要があるためdropを必要とするからかな
コンパイラが直接サポートすればそこは区別できるしリンク方式を取らなくてもよいから大丈夫じゃないかな

[0757 デフォルトの名無しさん 2022/08/22(月) 00:06:59.32 ID:f/cMaiDM]

でもコンパイラはお前のこと嫌いって言ってたしサポートしないんじゃない？

[0758 デフォルトの名無しさん 2022/08/22(月) 00:20:24.88 ID:ckyr84/m]

そもそものアプローチというか
エラーが起きない時か気にしなくてよい時　→　デストラクタによる自動処理任せでOK
エラーやその有無を必ず欲しい時　→　flushやcloseなど自分で呼べばエラー取得できる

とはいえそれさえ書くのを忘れた時に
Rustコンパイラがコンパイルエラーとする機能も持てそうだとわかったから
さらなる機能向上に期待

GC言語はデストラクタによる自動処理すらないからそれ以前の問題だし
後始末の処理や指示を忘れてもエラーとならないし
忘れてクローズされていないファイルディスクリプタが多数溜まっていくこともよくあるｗ

[0759 デフォルトの名無しさん 2022/08/22(月) 01:49:28.39 ID:8Vh1g9M5]

>>758
>Rustコンパイラがコンパイルエラーとする機能も持てそうだとわかったから
持てそうじゃないって
Drop Obligationとは全く異なるフロー解析が必要になるからゼロから作る新機能だよ

[0760 デフォルトの名無しさん 2022/08/22(月) 07:51:24.23 ID:qagbwcru]

>>756
その仮説で正しそうだが念のため確認してみた

まず>>741の通りだとdrop()を呼び出さずに当然コンパイルが通るので
何でもいいから関数呼び出し(演算含む)するものを間に挟んでみた
　let foo = Foo::new("Hello, World!");
　println!("test"); // ←ここに挿入
　foo.finalize()?;
するとこの形はdrop()を呼び出ように変化するようでリンクエラーとなる
この関数呼び出しはfooの参照を使うか否かに関係なく同じ結果

ところがfoo生成前に置くとコンパイルが通る
　println!("test");
　let foo = Foo::new("Hello, World!");
　foo.finalize()?;

さらにfoo消滅後に置いてもコンパイルが通る
　let foo = Foo::new("Hello, World!");
　foo.finalize()?;
　println!("test");

したがってfooが有効な期間に何か関数呼び出しがそこで起きる時のみ
drop()が呼ばれるコードが用意されてリンクエラーとなっている
これはRustがpanic時もメモリ解放をきちんと扱う話とも合致する
つまりpanic時の巻き戻し時のfoo解放をコンパイラが用意している仮説で正しいようだ

[0761 デフォルトの名無しさん 2022/08/22(月) 08:10:55.66 ID:qagbwcru]

>>759
そのような別のフロー解析は不要

Rustコンパイラは常に正しくメモリ解放を行うために所有権が尽きてdropを呼び出すべきところを全て把握している
それとは区別する形で>>760のようにpanic時の巻き戻し時のdrop呼び出しも正解に把握している
したがって以下のように検出できる

・finalize()をどのパスでも常に忘れずに呼び出しているコード
　　→　非panic時のdropは必ずfinalize()内のみで起こる

・finalize()を呼び忘れているパスが存在するコード
　　→　非panic時のdropがfinalize()以外で起こる　→検出

よってRustコンパイラは新たな仕組みを必要とせずに
現在把握している情報のみでfinalize()呼び忘れを検出可能
容易に対応できることが確認された

[0762 デフォルトの名無しさん 2022/08/22(月) 10:01:20.83 ID:r+XKv1YE]

つまり現状はできないってことw

[0763 デフォルトの名無しさん 2022/08/22(月) 17:26:44.21 ID:5n0Fj/6k]

>>760
これってつまりリソース確保してから通常想定されるdropの位置までの間にある
すべての関数呼び出しの panic の可能性を考慮しないといけないから実用不可って事にならんか。

まだ try ... finally ... の方が実用的やないか。

[0764 デフォルトの名無しさん 2022/08/22(月) 19:22:34.50 ID:f/cMaiDM]

正解

[0765 デフォルトの名無しさん 2022/08/22(月) 20:08:33.05 ID:IT4AaIoU]

>>763
大きな誤解をしているようだが
C++やRustなどは関数(正解にはブロックスコープ)を抜ける時に常にデストラクタ(dropなど)を呼んでいる
これが即座のメモリ解放でありC++やRustが高速に動作するな理由
ただしC++でもRustでも所有権が移動したときにはそのデストラクタを呼ばず移動先に委ねられる

以上の基本事項の上でC++の例外やRustのpanicなどが起きたときには
関数呼び出しを自動的に多段に巻き戻して各々のメモリ解放つまりデストラクタ呼び出しをする
これは所有権が移動する場合でも移動する前に例外やpanicが起きればデストラクタが呼び出される
それが>>760のfooの生成と移動の間に挟まれたときのみデストラクタ(drop)が呼び出される仕組み

これらは全てコンパイル時点で静的に簡単に確定するため複雑さはなく実行時の余分なコストも発生しない
ここまでの話は現状のC++/Rustコンパイラがやっている普通のことである

>>761のfinalize記述忘れをコンパイルエラーとする新機能の話は
上述した現状の仕組みをそのまま活用できるため
その新機能を付加することがたやすいというだけの話だろう

[0766 デフォルトの名無しさん 2022/08/22(月) 21:09:18.36 ID:Imj2WwGw]

複製おじさんがまーた嘘ついてる

Rustが所有権(=dropする義務)をどう管理してるか知りたければ
“Drop Obligations”でググるといいよ

[0767 デフォルトの名無しさん 2022/08/22(月) 21:19:17.98 ID:GgQXua2G]

>>763
try ... finally ... を書かなきゃいけない時点で大きく負けてるやん
RAII言語は何も書かずともデストラクタで自動処理される
そのデストラクタでエラーが発生する可能性がある時にfinalize呼び出しを強制させる選択肢も用意する話が今のテーマ

[0768 デフォルトの名無しさん 2022/08/22(月) 21:21:32.89 ID:PwgKhJsq]

>>765
それってコンパイラがどのAPIがfinalizeが必要か必要ないか全て把握してないといけないよね。
OS毎に低レベルAPIなんて異なるし組込み向けだってあるだろうし、無理じゃね？

[0769 デフォルトの名無しさん 2022/08/22(月) 21:33:37.66 ID:GgQXua2G]

>>766
Drop obligationsはその話と関係ないじゃない？
RustコンパイラDevelopment Guideを見ても "Drop obligations" は変数の構造つまりenumやstructの中身とそのフィールド連鎖などについての話

[0770 デフォルトの名無しさん 2022/08/22(月) 21:47:48.22 ID:5n0Fj/6k]

>>765
いや、その付加した機能が実用にならないねという話をしたんだが。

[0771 デフォルトの名無しさん 2022/08/22(月) 21:49:45.94 ID:IT4AaIoU]

>>768
みんなが一貫してずっと型の話をしているのに唐突にAPIとか場違いの話を出すのはヤバいな
finalize呼び出しを義務付ける型は>>713の方式ならばFinalize trait実装型と書かれている
あるいは>>743のManuallyDropのようにラッピング方式での指定の可能性もありうる
いずれも明白に宣言を伴うためコンパイラにとってもプログラマーにとっても明瞭に区別できる

[0772 デフォルトの名無しさん 2022/08/22(月) 21:56:10.02 ID:IT4AaIoU]

>>770
実用的じゃないとはどういう意味だ？
現行でも実用的になっているコード（明示的に書けばエラーを捕捉できて、書き忘れてもデストラクタで自動実行される）に対して
書き忘れを防止できる選択機能を新たに用意しよう、という話だろ

[0773 デフォルトの名無しさん 2022/08/22(月) 21:57:46.65 ID:Wff0V8uB]

>>769
関係ないわけないやん複オジw

[0774 デフォルトの名無しさん 2022/08/22(月) 22:01:34.61 ID:GgQXua2G]

>>773
複オジって何

[0775 デフォルトの名無しさん 2022/08/22(月) 22:32:14.28 ID:kPK6Bkqr]

finalize強制の話は7年前から線形型として提案はされてる
具体的なユースケースとしてFinalizeトレイトなんかも出てるし

https://github.com/rust-lang/rfcs/issues/814

ただまぁ大改造だし他にやることもたくさんあるから当分検討されることはないだろうな

[0776 デフォルトの名無しさん 2022/08/22(月) 23:20:29.01 ID:9Y+0qHT9]

zenは急げ

[0777 デフォルトの名無しさん 2022/08/22(月) 23:32:48.78 ID:f/cMaiDM]

>>772
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f27f2dc5668cded5f61f8f23e030df61

本当はこういうことがやりたかったんだろ？
newとfinalizeの間に一切コードが書けないんじゃ使い道が皆無

もともと「スコープ終端でのdropまでに特定の関数を呼び出していない場合コンパイルエラー」にしたいだけだったのが
「newした直後に特定の関数を呼び出していない場合コンパイルエラー」という厳しすぎる条件になってるのが問題

[0778 デフォルトの名無しさん 2022/08/22(月) 23:35:51.97 ID:hmZ4rA6/]

>>775
そこに書いてる実現方法でも現実的だけどそれでも相当大変そうだね
各種API変更まで考慮すると費用対効果的に無さそう

[0779 デフォルトの名無しさん 2022/08/22(月) 23:43:22.53 ID:Y3KYPZ9p]

>>777
間に別の処理を入れてもエラーが起きないようにしたコードかと思って試しちゃったじゃないかw

[0780 デフォルトの名無しさん 2022/08/22(月) 23:47:06.94 ID:IdBsr831]

費用の問題というのも間違い
安くすれば需要がどんどん増えると思ったら大間違いだよ

[0781 デフォルトの名無しさん 2022/08/23(火) 00:19:09.94 ID:VIf97uqR]

>>777
> newとfinalizeの間に一切コードが書けないんじゃ使い道が皆無

なぜそんな自虐的な設定を勝手に設けているの？
この話の発端は>>686だと思うけどそんな制限ないし
ここ最近に出ているコンパイラ拡張提案でもそんな制限した案はないよ

[0782 デフォルトの名無しさん 2022/08/23(火) 00:38:06.00 ID:7xrG+Q0V]

そういえばHaskellのLinearTypesのやつ自分で試してから貼ろうと思ってたけど
実際hCloseを消したり2回呼んだりして出てきたエラーメッセージで検索したら
同じことやってた記事があったんでもうこれ貼ればいいやってなった

https://scrapbox.io/mrsekut-p/%E7%B7%9A%E5%BD%A2%E5%9E%8B%E3%81%A7%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9%E7%AE%A1%E7%90%86%E3%82%92%E3%81%99%E3%82%8B%E4%BE%8B

[0783 デフォルトの名無しさん 2022/08/23(火) 00:51:58.53 ID:7xrG+Q0V]

>>781
>>741に聞けば？

[0784 デフォルトの名無しさん 2022/08/23(火) 01:09:26.07 ID:VIf97uqR]

>>783
それは未対応の現在のコンパイラでの話だよね
そんなことも区別つかないの？

[0785 デフォルトの名無しさん 2022/08/23(火) 01:19:05.91 ID:7xrG+Q0V]

>>784
うん区別付いてない
その「対応」は具体的に何を指して言ってる？
>>775の線形型のpre-RFCのこと？

[0786 デフォルトの名無しさん 2022/08/23(火) 01:31:34.47 ID:c+AZPHFJ]

>>783
ヒント: 781 == 741

[0787 デフォルトの名無しさん 2022/08/23(火) 02:13:39.19 ID:fCFqRRwJ]

現状ではどの言語でも実現できていない話と、
新たに新機能追加／拡張を考えようという話の、
区別がついていないというよりも、
現状では出来ていないと叩いたり制限があると叩いたり、
ものごとの理解ができないキチガイか文句をつけて叩ければいいアンチのどちらか

[0788 デフォルトの名無しさん 2022/08/23(火) 02:47:14.79 ID:J1WyjKaU]

SFCエミュを2ヶ月くらいで組んでるから
Rustの生産性が低いって事はなさそうね
https://zenn.dev/tanakh/articles/nes-and-snes-emulator-in-rust

[0789 デフォルトの名無しさん 2022/08/23(火) 02:49:40.76 ID:J1WyjKaU]

いや1ヶ月か

[0790 デフォルトの名無しさん 2022/08/23(火) 07:50:29.67 ID:42j/MXVV]

やっと出てきたのがファミコンのエミュかあ

[0791 デフォルトの名無しさん 2022/08/23(火) 08:28:00.41 ID:JlLC2CR4]

つまり複オジは反省しない嘘つき常習犯

[0792 デフォルトの名無しさん 2022/08/23(火) 11:42:15.69 ID:bRky1rDt]

>>782
さすがHaskellさん

[0793 デフォルトの名無しさん 2022/08/23(火) 12:20:50.32 ID:dq4kOwAu]

この人何回もゲーム機エミュ書いてるからこの人の事例で言語の生産性は測れないよ。

絵師()みたいな人がよく言う
「これまでの人生+10分なんです」
と同じ。

[0794 デフォルトの名無しさん 2022/08/23(火) 12:30:30.94 ID:YWYNH3Bb]

>>793
何回も書いてるなら
他の言語で書いた時と比較すれば多少は参考になりそうだけど

[0795 デフォルトの名無しさん 2022/08/23(火) 12:39:54.59 ID:nhRs6AvL]

>>794
書くたびに習熟度が上がるからダメ
記憶をリセットしないと

[0796 デフォルトの名無しさん 2022/08/23(火) 12:40:44.01 ID:Dkez1B4S]

Rustの生産性が高い原因はプログラミングの書きやすさとコンパイル時点で確定保証されることの多さ

[0797 デフォルトの名無しさん 2022/08/23(火) 12:43:43.35 ID:3UvdpEti]

ISUCONでGoに匹敵するぐらい入賞チーム増えてきたらどんな用途でも生産性が高いと証明されるな

[0798 デフォルトの名無しさん 2022/08/23(火) 12:57:16.80 ID:AllLmU9s]

>>797
限られた時間内で場当たり的な対応をどれだけこなすかを競うISUCONは現実と離れすぎていてあまり意味がない
もちろん欠陥だらけのシステムの数々の問題点を見抜いて各々に対応する能力は非常に重要
現実にはその能力は安全かつ高速なシステム設計開発に使うものであり短時間での場当たり的な対応に競うものではない

[0799 デフォルトの名無しさん 2022/08/23(火) 13:33:30.00 ID:1ViQo793]

時間は正しく計測できるという仮定の下で
「時間が短過ぎる」等の判断をすることもまた現実から乖離していることがよくある

数年前の過去問と同じ問題がテストに出れば、時間は数年間あってもそれを計測する時計はない

[0800 デフォルトの名無しさん 2022/08/23(火) 13:45:48.88 ID:Ke3Ccl3f]

知識を問うテストじゃないはずなのに、ある特定の知識を知ってる人だけがサクッと解けるようなテストだったら、それは問題が悪問なだけ
出題者が悪い

[0801 デフォルトの名無しさん 2022/08/23(火) 13:55:00.75 ID:1ViQo793]

良問を出すべきというのは道徳か？
富裕層は貧困層に寄付するべきと言ってるのと同じ？

[0802 デフォルトの名無しさん 2022/08/23(火) 14:07:44.30 ID:tZOwf5lf]

ISUCONでRustチームがいっぱい参加して優勝まで取ってたら真逆のこと言いそう

[0803 デフォルトの名無しさん 2022/08/23(火) 14:30:22.22 ID:nhRs6AvL]

性格や適性の問題じゃないかな
ボトルネックの調査と解消を正しく真面目にやれるタイプのエンジニアにとっては、
言語なんかシステムにおける無数のファクターの一つとして相対的に評価されるものでしかないのだろう
Rust信者だったら自分好みにリファクタリングを始めて時間切れになりそうだ
もちろん後者のタイプの人間のほうが適しているタスクもあるだろうけどね

[0804 デフォルトの名無しさん 2022/08/23(火) 14:39:05.74 ID:IzGsbq3u]

ISUCONのステマかなんかなの？
参加人数少なくて困ってんのかな

賞金を最低でも1000万以上にしたり
グローバル展開してあらゆる国の開発者を集めたほうがいいんじゃないの？
今は実質日本人学生用のコンテストになってるから

[0805 デフォルトの名無しさん 2022/08/23(火) 14:46:37.67 ID:K++0I94y]

俺もまずはリファクタリングから手を付ける
見やすさ追加改変のしやすさ品質に速さなどあらゆることでリファクタリングが基礎になる
あとシステムアーキテクチャに問題があるときは場当たり的な対応より根本設計からやり直した方が長期的に得と分かっている

[0806 デフォルトの名無しさん 2022/08/23(火) 14:58:48.56 ID:hhf7jlH2]

どこも小学生の自由研究のノリだよなｗ

[0807 デフォルトの名無しさん 2022/08/23(火) 15:34:20.38 ID:1ViQo793]

ディズニーを超えたいと思えばまあ小学生っぽくなるわな

[0808 デフォルトの名無しさん 2022/08/23(火) 17:09:38.21 ID:cAD3vi3K]

youtubeの中学受験の図形関係の問題みたいなもんでパターンを覚えるみたいな感じで
競技プログラムって何かつまらないんだよねぇ

[0809 デフォルトの名無しさん 2022/08/23(火) 18:30:00.47 ID:jZlkNHy6]

>>808
クイズやパズルと一緒
ワンパターンだから飽きるのは仕方がない

[0810 デフォルトの名無しさん 2022/08/23(火) 20:26:06.49 ID:1ViQo793]

ギャンブルならつまらないリスクから逃げるのは常識
だがリスクがない場合、つまらないという理由だけで逃げるのは逆に難度高い

[0811 デフォルトの名無しさん 2022/08/24(水) 09:30:33.86 ID:8fOu5lGq]

据膳でも感染リスクあるし

[0812 デフォルトの名無しさん 2022/08/24(水) 09:31:10.38 ID:8fOu5lGq]

>>808
めっちゃ判りますω

[0813 デフォルトの名無しさん 2022/08/24(水) 10:08:32.23 ID:+3OYCnBx]

根源にある感情は「だからなに？」ってことなんだよ
できてもできなくても大差ないということ

[0814 デフォルトの名無しさん 2022/08/24(水) 11:01:24.29 ID:fCJqwszS]

ManuallyDrop<T>を知る事と
それを知ってたら何になるかを知る事を区別しないと混乱が起きる

[0815 デフォルトの名無しさん 2022/08/24(水) 13:47:39.28 ID:ymarx/03]

>>808
結局そのアルゴリズムを反復練習で書けるかみたいになっちゃうんだよな

[0816 デフォルトの名無しさん 2022/08/24(水) 15:20:22.21 ID:ymarx/03]

>>804
参加者はめちゃくちゃ多いよ
ぶっちゃけ業務としてやってる会社が多いけど
俺が参加してた初期の頃はみんな趣味だったんだよね

[0817 デフォルトの名無しさん 2022/08/24(水) 15:32:52.45 ID:rnKc3YSn]

>>816
年1回の1500人程度の参加でめちゃくちゃ多いというの？？
比べる対象じゃないのかもしれんが競プロは毎週万単位での参加者がいるぞ

[0818 デフォルトの名無しさん 2022/08/24(水) 15:49:29.31 ID:Up+C642J]

だから？
どうした？

[0819 デフォルトの名無しさん 2022/08/24(水) 16:22:02.33 ID:cy/h+3Se]

>>818
辛辣w

[0820 デフォルトの名無しさん 2022/08/24(水) 17:08:00.62 ID:/EMIJnR6]

実務に役立たない競プロよりは
まだISUCONのほうがマシ
なぜならISUCONはサーバーなど含めたシステム全体のアルゴリズム相当も含むため
しかしそれを限られた時間内にその場しのぎの対応を多数こなす競技ISUCONも実務とかけ離れすぎていて単なるゲーム
ちなみに競プロの人口の方が多いのはISUCONの方がより現実に近くて桁違いの知識を必要とするため

[0821 デフォルトの名無しさん 2022/08/24(水) 18:35:33.50 ID:ieoEEHaa]

参加者めちゃくちゃ少ないけどなw
しかも半数以上は新人研修や社内勉強会での参加者で本気で決勝目指してるような奴等ではない

[0822 デフォルトの名無しさん 2022/08/24(水) 21:44:22.89 ID:AMNp1Lvn]

ISUCONなんてもともと「いい感じにスピードアップコンテスト」みたいな雑な名前で、
そういうのが好きな運用者のガチ余興から始まったもんだろ。
ベンチマーカーの特性読んで穴見つけて異常点数取ったやつを「スゲェw」みたいに言うお祭り。

なんか箔をつけたい学生さんに目を付けられてからなんかへんな感じになってるけど。

[0823 デフォルトの名無しさん 2022/08/25(木) 02:43:34.63 ID:2mWcQmbM]

>>822
最近はそういうの無くなってるよ
そもそもお題のサンプル実装の時点ですげーよくできたものが出来上がってくる
仕事としてやってる会社も増えたからそうなるんだろう
昔はめちゃくちゃやっつけで雑だったから
やりようがいくらでもあったのにさ

[0824 デフォルトの名無しさん 2022/08/25(木) 10:35:08.58 ID:gyuOx2Xm]

ISUCONを仕事としてやる会社って何なんだよ

[0825 デフォルトの名無しさん 2022/08/25(木) 11:17:57.47 ID:dsHaE0cL]

Rustより難しい疑問だが
その辺にある石ころのように誰にも気付かれない悪問

[0826 デフォルトの名無しさん 2022/08/25(木) 11:44:01.01 ID:GTPpxCbw]

運動会を業務時間にやる会社もある

[0827 デフォルトの名無しさん 2022/08/25(木) 11:49:35.28 ID:uCcuWcZI]

夏休みの自由研究
運動会
学芸会
発表会

楽しそっすね～ｗ

[0828 デフォルトの名無しさん 2022/08/25(木) 12:32:16.39 ID:IO7/ZCzd]

研修とかトレーニングとしてってことだろ？

もしかして会社の箔を付けるためなのか？
うちはISUCON決勝進出したんですw的な

[0829 デフォルトの名無しさん 2022/08/25(木) 12:33:42.97 ID:WEV4zSsV]

業務時間扱いで技術大会の運営準備とか練習させてくれるの、わりとどんな業界でも普通だと思うが…。

従業員を工数としか扱わない会社に所属してるなら御愁傷様。

[0830 デフォルトの名無しさん 2022/08/25(木) 13:05:50.93 ID:2mWcQmbM]

>>828
そういう面は大きいよ
特に採用面ではかなり優位だろう
まともなエンジニアがあることがわかってるし

[0831 デフォルトの名無しさん 2022/08/25(木) 14:32:09.78 ID:Ku9BBrHT]

そろそろ学びやすく美しい言語が完成してもいい頃

[0832 デフォルトの名無しさん 2022/08/25(木) 15:34:35.21 ID:tT+jR3hx]

Pascalだな

[0833 デフォルトの名無しさん 2022/08/25(木) 15:39:13.49 ID:GTPpxCbw]

RustとLispであらゆる用途をカバーすべき

[0834 デフォルトの名無しさん 2022/08/25(木) 15:47:59.73 ID:Ku9BBrHT]

Lispはカッコばかりつけてるナルシストだからダメです

[0835 デフォルトの名無しさん 2022/08/25(木) 18:25:49.89 ID:gEeT03jW]

そもそもプログラミング言語って本当に必要なのか？

[0836 デフォルトの名無しさん 2022/08/25(木) 18:38:47.49 ID:cZPZ0A+R]

>>829
「仕事としてISUCONに参加する会社」と
「ISUCON参加を業務時間扱いしてくれる会社」は全然違うやろ

前者は半ば強制の指示命令ありき
後者は任意の研鑽を会社が支援するもの
「仕事としてやってる会社」という表現は完全に前者を念頭にしてるよね

まぁぶっちゃけどうでもいいけど

[0837 デフォルトの名無しさん 2022/08/25(木) 19:19:03.77 ID:S/wpzj9c]

>>835
言語がなきゃどうやってプログラミングするんだよ

[0838 デフォルトの名無しさん 2022/08/26(金) 03:56:04.98 ID:V0DMr4WT]

>>836
いや、後者を念頭にしても不自然ではないよ

[0839 デフォルトの名無しさん 2022/08/26(金) 09:47:57.02 ID:+QfZXmYy]

>>835
全てをアセンブラで書くのは無理だぞ

[0840 デフォルトの名無しさん 2022/08/26(金) 10:03:42.99 ID:i2SIEm4o]

>>822
>ISUCON=いい感じにスピードアップコンテスト
>ベンチマーカーの特性読んで穴見つけて異常点数取ったやつを「スゲェw」みたいに言うお祭り

へー勉強になったω
まじありがとう

[0841 デフォルトの名無しさん 2022/08/26(金) 10:05:33.66 ID:i2SIEm4o]

>>839
アセンブラも機械語という言語で方言もある

[0842 デフォルトの名無しさん 2022/08/26(金) 10:40:28.46 ID:+QfZXmYy]

>>841
アセンブラはセーフだと思ってたwww
まさかELFをバイナリエディタで手打ちしない限りは言語を使ってないことにならないのか.....

[0843 デフォルトの名無しさん 2022/08/26(金) 11:09:48.80 ID:bqHPcqBD]

>>842
それは機械語という言語だな

[0844 デフォルトの名無しさん 2022/08/26(金) 11:11:30.63 ID:+QfZXmYy]

>>843
何もできなくて草

[0845 デフォルトの名無しさん 2022/08/26(金) 11:12:24.53 ID:bqHPcqBD]

>>841
アセンブリ言語と機械語は違うよ
アセンブリ言語は機械語に厳密に変換できるがループや条件分岐などをマクロ定義できる
ニーモニックは機械語と言っていい

[0846 デフォルトの名無しさん 2022/08/26(金) 11:14:37.08 ID:bqHPcqBD]

>>844
何を言ってるんだ
フローチャートを書いてそれを頭の中で直接バイナリに変換して打ち込むくらい昔は珍しくなかったぞ

[0847 デフォルトの名無しさん 2022/08/26(金) 12:29:43.43 ID:GQPfjH41]

一度でいいからパンチカードでFizzBuzzみたいな簡単なプログラムを作って動かしてみたいな

[0848 デフォルトの名無しさん 2022/08/26(金) 13:56:53.79 ID:3b+WTPGR]

>>837
言語じゃなくて"プログラミング言語"ね
コメントからコード生成する技術も出てきているし、将来的にはプログラミング専用言語が必要な場面がより少なくなるのではと思った
画像生成AIに食わせる文章に工夫が必要なように、コード生成AI向けに自然言語をうまく書くような工夫が必要で、それがプログラミング言語と呼ばれるのかもしれないけど

[0849 デフォルトの名無しさん 2022/08/26(金) 14:02:54.19 ID:okIuNp+m]

>>835
仮に不要だとしてもどうせ
清濁併せ呑むべきという話になって必要な物と不要な物が混ざり合う

[0850 デフォルトの名無しさん 2022/08/26(金) 14:03:10.59 ID:qa0S1e+W]

>>848
さすがにそれは無理
プログラミングしたことないやつにはわからんだろうけど

[0851 デフォルトの名無しさん 2022/08/26(金) 14:57:53.05 ID:3b+WTPGR]

>>850
無理というのは、特定用途でプログラミング言語を代替するものすら現れることはないということ？
なんでそう言い切れるのかが分からない

[0852 デフォルトの名無しさん 2022/08/26(金) 15:00:23.56 ID:PzjtNrBy]

>>851
プログラミング言語が必要かどうかの話をしてる時に特定場面でプログラミングを代替できるものが生まれるかどうかの話にすり替えてたのか

[0853 デフォルトの名無しさん 2022/08/26(金) 15:17:47.21 ID:3b+WTPGR]

>>852
最初の投稿が言葉足らずというか大げさな表現だったね。申し訳ない

どんなケースでもプログラミング言語が必要ということはなくて、新たな何かで置き換えられる領域はある
その新たな何かこそが次世代言語なんじゃないか、という話をしたかった

[0854 デフォルトの名無しさん 2022/08/26(金) 15:27:12.00 ID:lGuTpQOP]

ローコ−ドやらノーコードやらは定期的にブームになるけど
結局は定着しないんだよね

[0855 デフォルトの名無しさん 2022/08/26(金) 15:27:17.81 ID:PzjtNrBy]

そんなん昔は全部ユーザーが自分でプログラムしてやってたのが今では完成済みが売られてるんだから今さらだろ

[0856 デフォルトの名無しさん 2022/08/26(金) 15:55:55.10 ID:CBlt+itq]

コードより正確に情報残す方法なんてほぼないわ。

[0857 デフォルトの名無しさん 2022/08/26(金) 15:56:16.83 ID:oTK8NYWm]

4GLとかあったなあ
使ったことないけど

[0858 デフォルトの名無しさん 2022/08/26(金) 15:57:51.53 ID:9rbmdHVu]

ノーコード/ローコードはもっとUIだけにフォーカスしたツールが欲しいわ
マウスポチポチでWebUI作ったらAPIにデータ投げてくれるだけでいいのに、今時のSaaSはだいたい余計な中途半端なDB機能がついてきやがる
まあ一気通貫で提供しないとユーザー企業に直接売れずSIerに主導権握られることになるから、SaaSビジネスとしては面白くないんだろうな

[0859 デフォルトの名無しさん 2022/08/26(金) 17:49:09.03 ID:okIuNp+m]

PCのUIはスマホ大勝利により失脚してるし
UIにも言語と同様の権力闘争があるのは自明の理

[0860 デフォルトの名無しさん 2022/08/26(金) 18:29:11.38 ID:fCaJRqVr]

>>847
っ https://www.masswerk.at/keypunch/
http://www.kloth.net/services/cardpunch.php
https://www.youtube.com/watch?v=vBSVIJsSux4

[0861 デフォルトの名無しさん 2022/08/26(金) 18:59:38.20 ID:fCaJRqVr]

>>853
そんなもの既にある

[0862 デフォルトの名無しさん 2022/08/26(金) 21:28:02.57 ID:3b+WTPGR]

>>861
じゃあこれ以上の発展は見込めないわけ？

[0863 デフォルトの名無しさん 2022/08/26(金) 21:34:15.25 ID:6BD/kEhJ]

現代だとどの言語も言語仕様の更新をしているわけだし新しい言語じゃなくても言語の新しいバージョンを使うってのでもいい気もするけどね

[0864 デフォルトの名無しさん 2022/08/26(金) 22:21:54.13 ID:ol+btYtb]

言語の仕組みなんてLISP、Java、Haskellらへんでほぼ出揃ってて、目新しいものなんてほとんどない
使いやすくこうしてみましたー、とか、いいとこ取りしてみましたー、みたいなのばっり

[0865 デフォルトの名無しさん 2022/08/27(土) 00:11:23.77 ID:N+6DqfIs]

新しいものなんて何もないといいつつ、新たなものを求めて次世代言語スレへやってきてしまう人々
若い頃に出会ったものは相対的にキラキラして見えるだけで、そんな出会いは二度とないので諦めましょう

[0866 デフォルトの名無しさん 2022/08/27(土) 00:58:29.99 ID:Qpr8Hymf]

今の時代はコアの理論や機能だけじゃ広まらない。
ライブラリやビルド・パッケージ等のエコシステムも揃ってさらにはGAMAあたりのサポートもないと中々広まらない時代になってる気がする。

[0867 デフォルトの名無しさん 2022/08/27(土) 04:05:38.65 ID:LpZt/R8y]

>>864
21世紀になってからも唯一Rustが画期的な言語として登場したくらいかな

差異は所有権の借用とライフタイムという概念の導入だけだがその効果が革命的で
GCなくても常に安全な即時の自動メモリ解放とC言語並の速度の両立を実現したことに加えて
データ競合(シングルスレッド時のmutual aliasingを含む)が全く無いことも実現

高速と安全という従来相容れない二者を静的にコンパイル時点で保証したインパクトは大きく
世界のIT大手たちが揃って共同でRust Foundation設立するまでに到った

[0868 デフォルトの名無しさん 2022/08/27(土) 08:35:20.66 ID:Wed6O2vP]

>>864 程度で新しい仕組みと言えちゃうなら実行中に一時停止しないことに命かけてるponyの方が余程新しい仕組みになっちゃう
標準入力をそのまま返すだけで新しいクラスを作成させられるからな

[0869 デフォルトの名無しさん 2022/08/27(土) 09:26:47.49 ID:/L4u6rBy]

>>865
>新たなものを求めて次世代言語スレへやってきてしまう人々

新たなものを求めてるんじゃなく
自分がマウント取れるネタを探しにやってきてるだけ
隔離スレと呼ばれる所以

[0870 デフォルトの名無しさん 2022/08/27(土) 11:11:47.40 ID:PlsxVQrZ]

心理学や行動経済学は新たなものを作らない
マウントに限定しなくても心理学全体がそういうものだ

[0871 デフォルトの名無しさん 2022/08/27(土) 11:51:54.64 ID:APSkyxtl]

>>867
rust-analyzerがバカスカメモリ食うのなんとかして

[0872 デフォルトの名無しさん 2022/08/27(土) 12:19:45.38 ID:rW3XYjqW]

所有権もC++のムーブが元なんだけどな
あれをデフォルトにしたらRustになったと言うだけ

[0873 デフォルトの名無しさん 2022/08/27(土) 13:34:38.00 ID:PlsxVQrZ]

ITの新しいところは二つある
低級言語からボトムアップで作るところ
無意識にバグを作ってしまうところ

[0874 デフォルトの名無しさん 2022/08/27(土) 14:02:19.73 ID:APSkyxtl]

所有権とlifetimeは元ネタがあったとはいえ、そこからshared xor mutableへと発展させたのは大きな発明だと思うよ

[0875 デフォルトの名無しさん 2022/08/27(土) 14:25:45.41 ID:L6zf9p1Z]

>>874
shared xor mutableも元ネタあるよ
トランザクションを使った同時実行制御の常識
それを所有権やライフタイムの考えと融合させて実用可能なものを作ったところが新しい

[0876 デフォルトの名無しさん 2022/08/27(土) 19:24:10.69 ID:4NYTelSG]

研究用プロトタイプとか言語の一部で適用可能にしたレベルで終わりそうなものを基盤にした処理系をいちから作り上げてメインストリームに持ってきたのはホントすごいと思うわ。

[0877 デフォルトの名無しさん 2022/08/27(土) 19:57:46.81 ID:cdahKvQA]

組み込みとか低水準で使えるようなシステムプログラミング向けの言語って、候補と呼べるものすら新しい言語はなかなか登場してなかったと思うんだけどなんでだろな

C/C++の存在感がでかすぎて言語開発者の興味が失われてたんかね、GCを贅沢に使った言語はめちゃくちゃたくさん登場してるのに
今となってはRustが成功しつつあるけど、Rustが登場しなかったらずーっとC/C++の天下だったんかな、いやだな

[0878 デフォルトの名無しさん 2022/08/27(土) 20:29:15.90 ID:XaCH/Kga]

>>872
C++はライフタイムを言語(コンパイラ)が把握管理できないため
ダングリングの発生を検知してコンパイルエラーとできず
セキュリティ含む深刻なバグを未だに量産し続けていることに問題がある

[0879 デフォルトの名無しさん 2022/08/27(土) 22:12:41.90 ID:PlsxVQrZ]

>>877
C++の時点で難易度がもう非常識なレベルになってるから
それ以上先に進むのは常識的にはできなかった

だが偶然その時にC++と関係ない人々の日常会話も非常識で過激になって行った
その結果、難解過ぎることの何が悪いのかと開き直るのを誰も止められなくなった

[0880 デフォルトの名無しさん 2022/08/27(土) 23:03:56.45 ID:rW3XYjqW]

>>878
いやだからC++にムーブができたんでしょ
std::moveとムーブコンストラクタとムーブ代入演算子を勉強しな？

[0881 デフォルトの名無しさん 2022/08/27(土) 23:22:25.52 ID:0oprUFWN]

>>880
それは所有権
Rustは借用とそのライフタイムを言語の制御下に置いたことで初めて安全なメモリ自動解放を実現した
C++がいかにダメな言語なのかをもう少し勉強したほうがいい

[0882 デフォルトの名無しさん 2022/08/27(土) 23:38:25.67 ID:WqKrPeWc]

安全なメモリ管理ってｗ
単に関数でnewしたものを保存してスコープが切れたら解放するだけでしょｗ
それC++でFile file;のように宣言したのと概ね同じなんじゃね？ｗ

[0883 デフォルトの名無しさん 2022/08/27(土) 23:43:33.94 ID:sUJYl6Ez]

Rustはオワコンだからあんま使いたくないな

[0884 デフォルトの名無しさん 2022/08/27(土) 23:45:55.57 ID:UglcSwzZ]

>>882
まずC++がメモリ管理バグを生産し続けている仕組みを学習すべきだな
それまでこのスレに出入り禁止

[0885 デフォルトの名無しさん 2022/08/28(日) 00:56:35.98 ID:7IFudYOE]

C++にはtemplate反対派もいるから
バッファ<T>の代わりにtemplateを使わないやつを再発明することで
オーバーランも再発し続ける

[0886 デフォルトの名無しさん 2022/08/28(日) 05:26:11.72 ID:qfec6UU9]

>>881
Rustの解説にもある通りRAIIがベースで、自動変数の応用例だけどな。

C++は元々cをコンパイルできるという大原則があって、その原則からスマートポインタ強制とかは行っていない。Rustはそのあたりのしがらみを捨てているんだからああなるだろ。
RustもC++の複雑さに加えてHaskellの難しさも取り込んでいるから、絶壁の学習曲線問題は悪化している。置き換えが進むのはc/c++の一部の領域のみで、Javaの領域とか食えないと思うわ。

[0887 デフォルトの名無しさん 2022/08/28(日) 06:06:08.65 ID:yYM00GDu]

>>886
その件でRAIIや自動変数と言い出してる時点で把握不足
それは以下の非常に大雑把に分けた3段階のうちの最初の(1)の部分でしかない

(1) RAIIとデストラクタ
(2) 所有権とその移動
(3) 借用とライフタイム

>>882も(1)止まり
>>880は(2)止まり
(1)と(2)だけではダングリングポインタの発生を防げない

[0888 デフォルトの名無しさん 2022/08/28(日) 07:28:26.48 ID:/BN7SwZG]

>>886
Rustの難しさがC++の難しさを引き継いでいるのかは疑問に少し疑問だし、Haskellの難しさに至っては全く受け継いでないと思うぞ
型に対する要求は小さいし、関数が純粋であることも求めてないし、遅延評価をベースにしてもいない

[0889 デフォルトの名無しさん 2022/08/28(日) 10:48:45.36 ID:7IFudYOE]

サブスクやリボ払いじゃないんだから
よく似た難しさに10回出くわしたら1回あたりのコストは1/10になるんだよ

まあそうなると「コスト」とは何かを定義するのが極めて困難になるんだけど

[0890 デフォルトの名無しさん 2022/08/28(日) 12:11:47.01 ID:kDu69pxs]

RustやC++やHaskellの難しいポイントってそれぞれ具体的にどういうところを指してるの？
単に難しさと言われても人によってイメージするもの違うのでは

[0891 デフォルトの名無しさん 2022/08/28(日) 12:52:57.69 ID:XrBOFvee]

Haskellの難しさは対象ドメインの一般的理解よりも一段二段高い抽象度を意識したプログラミングが必要なところ

[0892 デフォルトの名無しさん 2022/08/28(日) 13:12:40.64 ID:7IFudYOE]

Lisp世代とErlang世代の間に暗黒時代がある
モナドと型推論のプロトタイプもその時代にある
検索しても多分辿り着けないのは検索エンジンが原因でしょ

[0893 デフォルトの名無しさん 2022/08/28(日) 13:38:45.23 ID:eQVF2PFY]

トレイトとライフタイムが難しい

[0894 デフォルトの名無しさん 2022/08/28(日) 14:28:30.61 ID:5fPmE595]

>>893
トレイトはシンプルで分かりやすいけど
クラスが非常に難しい

例えば複数の型に共通する機能性質とメソッド群を用意したいことはプログラミングでよく発生する場合
トレイトだと複数の型々に関係なく独立してそのまま用意して各型に実装するだけだけでいいけど

クラスだと継承でやるにはその型自身に継承しなきゃいけなくて多重継承になったり継承ピラミッドが複雑化
あるいは継承は破綻するからメソッドを増やす別の方法を拡張して使い何のためにクラスを使っているのか本末転倒になる
結局クラスと型が分離できていないことにも問題が多い

Rustでは型とトレイトという二つの直交した概念だけで全てが済むからシンプルで分かりやすい
クラスも継承もないのはRustだけでなくGoでもそうだけど今までクラスと継承で遠回りしてきたプログラミング言語の到達点かなと思う

[0895 デフォルトの名無しさん 2022/08/28(日) 15:06:53.82 ID:17VtAmCD]

>>894
インターフェースも知らんのか？

[0896 デフォルトの名無しさん 2022/08/28(日) 15:17:26.17 ID:WHMHQcXx]

トレイトも型なのに何言ってんだこいつw

[0897 デフォルトの名無しさん 2022/08/28(日) 15:26:53.46 ID:7IFudYOE]

>>895
Linusを怒らせたのはそういう所だな
C++を知っていても使わない自由があると言いながら
実際に使わない者が現れれば「知らんのか？」とミスリードしてくる

[0898 デフォルトの名無しさん 2022/08/28(日) 15:34:27.90 ID:MtWOn5Ys]

>>897
C++にはインターフェースが無いことも知らんのか？
そりゃリーナスも怒るわw

[0899 デフォルトの名無しさん 2022/08/28(日) 15:39:21.95 ID:ntsn5RH7]

C++も素のままならまだいいのだが
やっぱり癌はSTLなどのライブラリや例外だな
内部で勝手に動的にメモリ確保したりとかするなよってｗ

[0900 デフォルトの名無しさん 2022/08/28(日) 15:57:21.77 ID:5fPmE595]

>>895
そのインターフェース等を批判してることを読み取れないのか？
クラスとインターフェースの2種類が必要となってしまっている
トレイトだけで済むRustがシンプルで分かりやすいことを認めたわけだな

[0901 デフォルトの名無しさん 2022/08/28(日) 16:07:51.94 ID:uFtLPU6J]

分かってなさそう

[0902 デフォルトの名無しさん 2022/08/28(日) 16:15:35.13 ID:5fPmE595]

>>896
トレイトは型ではない
例えばCopyトレイトやDisplayトレイトなどの既存のものから自作のものまで自由にトレイトを作れるが
それらトレイトはもちろん型ではなく機能や性質を示すだけである
ある型を作ったときにそれら任意のトレイトを実装するか否かは自由であり
あるトレイトを作ったときにどの型に対して実装するか否かも自由である

[0903 デフォルトの名無しさん 2022/08/28(日) 16:21:02.87 ID:eCF2zYYC]

スパゲティーは苦手だからCarbonに期待

[0904 デフォルトの名無しさん 2022/08/28(日) 16:22:01.22 ID:0b1WGCJ7]

Rustでは型とトレイトという二つの直交した概念だけで全てが済むからシンプルで分かりやすい

クラスとインターフェースの2種類が必要となってしまっている

ほーん

[0905 デフォルトの名無しさん 2022/08/28(日) 16:33:32.30 ID:Lrz1i+MR]

つまりクラスとか継承とかそんな複雑なものは要らないよな
型とインターフェースだけがあればいい
Goは実際にそうなっている

[0906 デフォルトの名無しさん 2022/08/28(日) 16:33:43.64 ID:kDu69pxs]

>>893
ライフタイム以前よりはかなり簡単になったけどまだ引っかかりどころは残ってる感じ？

[0907 デフォルトの名無しさん 2022/08/28(日) 16:44:44.59 ID:UslCRvMa]

>>900
Rustの公式リファレンスにもトレイトはインターフェースって書いてあるんですがww

[0908 デフォルトの名無しさん 2022/08/28(日) 16:48:30.90 ID:5qFsJjmO]

>>900
Rustはstructとimplとtraitの3種類が必要としまってますねwww

[0909 デフォルトの名無しさん 2022/08/28(日) 16:52:01.49 ID:5fPmE595]

>>907
そうだよ
インターフェース自体を問題にはしていない
クラスに加えて結局インターフェース等も必要としている状態を批判している
それならばGoやRustのように最初からクラスは無い方がシンプル

[0910 デフォルトの名無しさん 2022/08/28(日) 17:01:29.35 ID:5JaYE9jd]

C++20でconceptというのがあるんだな
これは知らんかったわ
C++も大変だねー

[0911 デフォルトの名無しさん 2022/08/28(日) 17:27:57.92 ID:VCib2hQJ]

rust は使ったことないがエラーメッセージが c++ より親切と聞いておる。

[0912 デフォルトの名無しさん 2022/08/28(日) 17:42:22.67 ID:eCF2zYYC]

ここに書き込んでるヤツのせいで本当にrustが嫌いになったわ

[0913 デフォルトの名無しさん 2022/08/28(日) 17:47:23.10 ID:ARvglkbX]

>>912
他人の意見ばかり気にしてないで、自分で判断したらいいのに

[0914 デフォルトの名無しさん 2022/08/28(日) 18:01:38.50 ID:9BfrdysB]

>>897
別にリーナス怒ってはないやろ
mallocで失敗したくらいで強制終了するしかないポンコツは流石に使えんわって言っただけで

[0915 デフォルトの名無しさん 2022/08/28(日) 18:04:31.62 ID:e6Sjxbuq]

>>911
C++と言うより原理的にテンプレート絡みのエラーメッセージはわかりにくいわな
まあそこは言語組込のrustに軍配上げるしかない

[0916 デフォルトの名無しさん 2022/08/28(日) 18:12:18.75 ID:ZW7HH5qp]

> クラスとインターフェースの2種類が必要となってしまっている

class に加えて interface があるのは救いなんだがｗ
実装ではなくてインタフェースに対してプログラミングせよ
ってのを実践するのに丁度いい潔い言語機能なんだが

[0917 デフォルトの名無しさん 2022/08/28(日) 18:24:29.65 ID:7IFudYOE]

interfaceでできることは (多重継承禁止しなければ) classでもできる
この客観的事実を、鬼滅棒みたいに振り回す人
と仲良くなるところまでがC++の難易度です

[0918 デフォルトの名無しさん 2022/08/28(日) 18:31:25.88 ID:ZW7HH5qp]

個人的にはC++でIFooとか涙ぐましいことやってんのも受け入れられるよ
問題は、言語ユーザが実装とインタフェースを分離したいという発想を持ってるかどうかだから

もちろんそうなったとき、よりスッキリすんのは言語として interface があるほうだよねって話

[0919 デフォルトの名無しさん 2022/08/28(日) 18:34:20.72 ID:RvFPV5Qc]

そもそもC++はオブジェクト指向言語ではないのでインターフェースは必要ない。

[0920 デフォルトの名無しさん 2022/08/28(日) 18:36:05.49 ID:ii1XaHH8]

>>903
Rustを使えば避けられるよ

>>908
implは単なる接着剤だよ
Goのように接着剤なしで書く方式もあるように
接着剤であるimplはそこで言う種類じゃないよ

[0921 デフォルトの名無しさん 2022/08/28(日) 18:39:21.55 ID:RvFPV5Qc]

そもそもRustは仕事がないのでimplは必要ない。

[0922 デフォルトの名無しさん 2022/08/28(日) 18:40:17.57 ID:ii1XaHH8]

>>918
うん
インタフェースは必要でむしろクラスが要らないよね
そのわかりやすい道を選んだのがGoとRust

[0923 デフォルトの名無しさん 2022/08/28(日) 18:44:55.39 ID:RvFPV5Qc]

Rustは仕事がない。
Goは仕事がある。
この差は大きい。

[0924 デフォルトの名無しさん 2022/08/28(日) 18:45:28.11 ID:iJSRjwGP]

雇われ仕事はな

[0925 デフォルトの名無しさん 2022/08/28(日) 18:46:02.45 ID:eCF2zYYC]

>>913
自分の判断ではrustはスパゲッティだから

[0926 デフォルトの名無しさん 2022/08/28(日) 18:47:05.71 ID:eCF2zYYC]

ていうか、Rustって使ってる人少なすぎじゃね？

[0927 デフォルトの名無しさん 2022/08/28(日) 18:48:13.72 ID:TZ0QCmjM]

メソッドが無いってんならともかく、クラスが無いと言っても明示的なクラス定義に比べてソースコードの物理的レイアウトの自由度が高いというくらいの話でしかないでしょ
そんなドヤ顔で語るほどのことでもない

[0928 デフォルトの名無しさん 2022/08/28(日) 19:04:58.89 ID:ii1XaHH8]

>>925
少なくとも他の言語と比べたらスパゲティになりにくいね

>>927
メソッド自体はクラスと関係なくてクラスベースのプログラミング言語でなくても存在するものだよ
クラスを特徴付けるものはクラスの親子関係を示す継承だね
GoとRustに継承はないからクラスとは明確に異なるよ

[0929 デフォルトの名無しさん 2022/08/28(日) 19:06:04.35 ID:TZ0QCmjM]

クラスに継承は必須ではないよ
VBAのクラスに継承は無いぞ？

[0930 デフォルトの名無しさん 2022/08/28(日) 19:06:48.27 ID:RvFPV5Qc]

Rust、Haskellは仕事がない。

[0931 デフォルトの名無しさん 2022/08/28(日) 19:07:23.94 ID:L4K2SyLA]

>>920
implは操作の定義
structはデータの定義

この2つを分けたことの意味が分からないようならRust辞めたほうがいいよ

[0932 デフォルトの名無しさん 2022/08/28(日) 19:08:15.18 ID:RvFPV5Qc]

始めても居ないだろ。

[0933 デフォルトの名無しさん 2022/08/28(日) 19:16:42.43 ID:p0vNwv3L]

Goのimplicitなインターフェース実装よりも
Rustのexplicitなトレイト実装のほうが断然いい

ただJavaと違ってC#やSwiftならExtensionで後からクラスにインターフェース実装追加できるからGoやRustの方式が特に優れてるわけでも無いと思うけどね

[0934 デフォルトの名無しさん 2022/08/28(日) 19:25:12.79 ID:ii1XaHH8]

>>929
VBAは他にもできないことや制限されることが色々とあるから置いときましょ

>>931
違うよ
implは『実装』の定義だよ
structは(構造体の)『型』の定義だよ

[0935 デフォルトの名無しさん 2022/08/28(日) 19:32:34.36 ID:Lrz1i+MR]

>>933
優れてるかどうかは誰も言っていなくて
元々の話はRustはトレイトがあるから複雑で難しいとかいう批判に対して始まった議論やろ
実際にはクラスとそれに纏わる諸々がないからGoもRustもクラスのある言語より簡単でわかりやすくなってる

[0936 デフォルトの名無しさん 2022/08/28(日) 19:39:33.75 ID:jYJ6rDEN]

importしないと使えないメソッドがあるのが理解できない

[0937 デフォルトの名無しさん 2022/08/28(日) 19:45:44.96 ID:BvDaIb58]

問題はクラスではなく副作用だよ
勘違いするなよ
クラスのメンバーが途中で書き換えられたりしなければ問題はないのよ

[0938 デフォルトの名無しさん 2022/08/28(日) 19:49:05.31 ID:lJnoAt2m]

rustはstructのフィールドごとにmut設定できないので欠陥言語

[0939 デフォルトの名無しさん 2022/08/28(日) 19:53:38.21 ID:fprIa6qZ]

次スレのタイトルは

次世代言語28 Rust

にしとこうか？

[0940 デフォルトの名無しさん 2022/08/28(日) 19:55:42.04 ID:RvFPV5Qc]

仕事がない言語に未来はない。

[0941 デフォルトの名無しさん 2022/08/28(日) 20:11:14.04 ID:iJSRjwGP]

仕事があっても未来がない言語の方が多い件

[0942 デフォルトの名無しさん 2022/08/28(日) 20:17:59.03 ID:RvFPV5Qc]

RustはPHPより優れているんだ！！といくら主張しようとも。
Rustは仕事が無くてPHPは仕事があるんだから仕方がない。

[0943 デフォルトの名無しさん 2022/08/28(日) 20:18:38.81 ID:e6Sjxbuq]

>>941
具体的にどういう言語に未来がないの？

[0944 デフォルトの名無しさん 2022/08/28(日) 20:25:11.67 ID:pOmrVgZH]

>>943
COBOL Fortran Ruby Perl VB.NET VBScript Delphi

[0945 デフォルトの名無しさん 2022/08/28(日) 20:25:27.41 ID:lJnoAt2m]

コボラーの人たちは逃げ切ったと思う
くいっぱぐれなかったコボラー

[0946 デフォルトの名無しさん 2022/08/28(日) 20:30:40.83 ID:DhGNghcs]

Objective-Cもまだ仕事はあるだろうけど未来はないな

[0947 デフォルトの名無しさん 2022/08/28(日) 20:35:31.36 ID:RvFPV5Qc]

全部、一時代を築いた言語たちじゃないか。

[0948 デフォルトの名無しさん 2022/08/28(日) 20:36:35.22 ID:DhGNghcs]

だから仕事と過去はあるけど未来がないと言われてるんだろ

[0949 デフォルトの名無しさん 2022/08/28(日) 20:38:56.54 ID:DhGNghcs]

Elmとかいうの一時期Qiitaで流行ってたけどもう下火だな

[0950 デフォルトの名無しさん 2022/08/28(日) 20:48:08.93 ID:RvFPV5Qc]

世界で見捨てられたころに日本で流行らせようとする人たちが出てくるのは何故なんだろうな。

[0951 デフォルトの名無しさん 2022/08/28(日) 20:51:32.52 ID:7IFudYOE]

流行らせよう・・・そんな未来形は使う必要がねえんだ

[0952 デフォルトの名無しさん 2022/08/28(日) 20:52:32.31 ID:lJnoAt2m]

PHPとRoRのプロの人は今後も食いっぱぐれないと思う

[0953 デフォルトの名無しさん 2022/08/28(日) 20:57:10.97 ID:pOmrVgZH]

COBOLみたいに進化が止まればね
PHPはアグレッシブに言語仕様変えてるから往年のぺちぱーにとっては厳しくなりつつあるんじゃないか？

[0954 デフォルトの名無しさん 2022/08/28(日) 21:08:03.91 ID:CjJz/pgW]

>>935
トレードオフなんだよ
得たものもあれば失ったものもある
ある状況において簡単になってるように見えるだけ

[0955 デフォルトの名無しさん 2022/08/28(日) 21:09:02.48 ID:M1jTd8eK]

おれRoR得意だけどRails使ってるとこはフットワーク軽いとこ多いし、みんなどんどんGoに置き換えてるよ
Railsにフロントもやらせるとゴチャっとしてメンテしづらくなりやすいし、APIだけやらせるんならRailsである必要性もないし・・・

[0956 デフォルトの名無しさん 2022/08/28(日) 21:25:19.61 ID:JJMPEtcG]

>>955
APIだけの場合でもモデルの作りやすさとか考えると全然あり
まぁLambdaとかでコスト削減したいなら無し

[0957 デフォルトの名無しさん 2022/08/28(日) 21:31:52.80 ID:FsgvCgwF]

スレタイは次世代言語じゃなく新世代言語にしとけば？
それならスレタイにある現世代の言語でも違和感ないから

[0958 デフォルトの名無しさん 2022/08/28(日) 21:41:34.26 ID:BvDaIb58]

>>955
Goにする理由がわからないなあ
Web APIだけならRailsで十分でしょうよ

[0959 デフォルトの名無しさん 2022/08/28(日) 22:08:57.12 ID:e6Sjxbuq]

>>944
C, C++, C#, Python, JavaScript/TypeScript, Go,

[0960 デフォルトの名無しさん 2022/08/28(日) 22:10:55.80 ID:iJSRjwGP]

>>959
未来のある言語ばかりだな

[0961 デフォルトの名無しさん 2022/08/28(日) 22:12:52.50 ID:e6Sjxbuq]

>>944
途中で書き込んでしまった
あとFORTRANはスパコンとかの数値演算系ではまだまだ現役で未来がないわけじゃないよ

[0962 デフォルトの名無しさん 2022/08/28(日) 22:16:33.25 ID:iJSRjwGP]

>>961
Formura「いつのスーパーコンピュータの話をしてるんだ」

[0963 デフォルトの名無しさん 2022/08/28(日) 22:41:58.53 ID:gOapjWvD]

YouTube で有名な雑食系エンジニア・KENTA が勧めるキャリアパスは、
Ruby on Rails → Go のみ

さらに彼は、PHP, Scala をオワコン認定した。
要するに、この2つはRailsに勝てる要素がない

時価総額1兆円のGitLab は、Railsで続けることを宣言している

[0964 デフォルトの名無しさん 2022/08/28(日) 22:54:34.17 ID:M1jTd8eK]

ああ、ごめんなさい、ガイジを召喚しちゃった・・・

[0965 デフォルトの名無しさん 2022/08/28(日) 22:58:49.50 ID:e6Sjxbuq]

>>962
富岳とかの利用方法見たらわかるけど、最初に載せてる
なんだかんだ言って言語仕様的に最適化し易いのとライブラリに1日の長がある

[コンパイラ/インタプリタ]
富士通コンパイラ(Fortran2008 & Fortran2018サブセット, C11 & GNU拡張仕様・Clang拡張仕様, C++14 & C++17サブセット & GNU拡張仕様・Clang拡張仕様, OpenMP 4.5 & OpenMP 5.0サブセット), GNUコンパイラ, Julia, OpenJDK (Java), Python, Ruby, XcalableMP, LLVM
https://www.hpci-office.jp/pages/r-ccs_riken_2022-2

[0966 デフォルトの名無しさん 2022/08/28(日) 23:01:39.48 ID:iJSRjwGP]

>>965
それ今はまだ使われてるってだけで未来の話はしてないよね

[0967 デフォルトの名無しさん 2022/08/28(日) 23:11:01.40 ID:BvDaIb58]

Fortranは過去の資産が大量にあるからなあ
しかもバリバリ現役のが
普通にCOBOL以上だよ

[0968 デフォルトの名無しさん 2022/08/28(日) 23:15:53.85 ID:e6Sjxbuq]

>>966
新規案件もあるしコンパイラの改善も進んでるけど？
あんたの未来の定義はなに？

[0969 デフォルトの名無しさん 2022/08/28(日) 23:23:42.78 ID:iJSRjwGP]

>>968
話の流れくらい把握してから聞いてくれよ

[0970 デフォルトの名無しさん 2022/08/28(日) 23:27:23.09 ID:e6Sjxbuq]

>>969
把握できてないのは貴方では？

[0971 デフォルトの名無しさん 2022/08/28(日) 23:52:33.65 ID:1VE+JRD5]

次の土方言語

[0972 デフォルトの名無しさん 2022/08/29(月) 00:01:26.37 ID:RL/dmmx9]

機能を追加しつつげてるC#辺りの方が、次世代って言わないだろけれど、時代に合わせて進化続けてる感じするよ。

[0973 デフォルトの名無しさん 2022/08/29(月) 00:13:24.90 ID:DkZBXm10]

C#は一つの言語にアグレッシブに手を入れ続けるという点では現在進行系で最も成功している言語だろうね
単純な言語仕様の量で言えばもはやC++を超えてるんじゃないか

[0974 デフォルトの名無しさん 2022/08/29(月) 00:15:09.28 ID:m+eGoc7U]

C#に一番類似してるやつとさっさと決着つければいいのに
PythonとRubyがとうの昔にやったことを未だにできてない

[0975 デフォルトの名無しさん 2022/08/29(月) 00:24:30.02 ID:5N7ZaELz]

Javaと言いたいのかもしれないが、C#の方が別物になりすぎて今や全然類似していない
今だと一番類似してるのはKotlinあたりだろうが、シェアではそもそも全く勝負になってないな

[0976 デフォルトの名無しさん 2022/08/29(月) 00:38:48.50 ID:q9iRl6Qa]

科学計算系の現役のライブラリの中覗くとFortranのコードベタ移植してたりするよね

[0977 デフォルトの名無しさん 2022/08/29(月) 01:40:27.72 ID:oXLAwjez]

>>953
PHPは太古のコードも割と動くからな…

[0978 デフォルトの名無しさん 2022/08/29(月) 06:56:36.80 ID:5dAad4gs]

>>970
IEの新規案件もまだあるんだがそれでもJScriptに未来があると言うのか

[0979 デフォルトの名無しさん 2022/08/29(月) 07:04:39.97 ID:7/v7fhbZ]

>>978
> IEの新規案件もまだあるんだが
それ一般的なのか？

[0980 デフォルトの名無しさん 2022/08/29(月) 07:10:46.62 ID:5dAad4gs]

>>979
新規案件があるくらいじゃ未来があるとは言えんという話だぞ
話の流れずっと理解してないな

[0981 デフォルトの名無しさん 2022/08/29(月) 07:32:15.58 ID:7/v7fhbZ]

>>980
詭弁のガイドライン
2. ごくまれな反例をとりあげる

[0982 デフォルトの名無しさん 2022/08/29(月) 07:42:30.60 ID:RxdzUhf3]

>>942
次世代言語スレでそれ言われてもw

[0983 デフォルトの名無しさん 2022/08/29(月) 08:14:52.94 ID:q9iRl6Qa]

Rsstは土方言語何人分の戦闘力を持ってるの？人件費ペイできる？

[0984 デフォルトの名無しさん 2022/08/29(月) 08:32:22.22 ID:5dAad4gs]

反例は一つあれば十分というのを知らんのか
論文くらい書いたことあるだろ

[0985 デフォルトの名無しさん 2022/08/29(月) 08:57:30.33 ID:nDT/a4Yr]

>>984
バカなの？
そんなのでいいなら
> COBOL Fortran Ruby Perl VB.NET VBScript Delphi
だって新規案件の一例くらいあるだろ
少なくともうちでVB.NETはまだ現役だし、受注案件だけどDelphi案件もあったし
そもそも IE は開発元がやめるって言ってるのにw

[0986 デフォルトの名無しさん 2022/08/29(月) 09:00:20.14 ID:5dAad4gs]

新規案件があるけど未来がないって話をしてるのにマジで流れを読まず反射だけでレスするやつだな

[0987 デフォルトの名無しさん 2022/08/29(月) 10:39:54.92 ID:5N7ZaELz]

未来とは？
仮に十年後の案件数と定義するならたぶんRustはCOBOLやVB.NETには勝てないだろうな

[0988 デフォルトの名無しさん 2022/08/29(月) 10:47:42.18 ID:7/v7fhbZ]

>>986
だからお前の未来の定義はなんだよw
FORTRANは今後も使われ続けるのに未来がないというなら定義を示せ

[0989 デフォルトの名無しさん 2022/08/29(月) 11:05:20.92 ID:5Xz3DP2S]

>>980
次スレの未来もヨロ

[0990 デフォルトの名無しさん 2022/08/29(月) 11:09:13.81 ID:m+eGoc7U]

仕事は手段
目的はお金だがそれも未来を未定義にしておく手段でしかない
溜め込んだお金でいったい何を買いたいのかを定義しないと

[0991 デフォルトの名無しさん 2022/08/29(月) 11:22:48.11 ID:5dAad4gs]

次スレ
https://mevius.5ch.net/test/read.cgi/tech/1661739736/

[0992 デフォルトの名無しさん 2022/08/29(月) 13:24:53.95 ID:pKi3id7l]

Fortranをpythonで書き直すプロジェクトやってるけど
なかなか辛い
トランスレータ作ろうか？って話になってる

[0993 デフォルトの名無しさん 2022/08/29(月) 15:22:41.69 ID:TPR5Zi0L]

共産主義国家にレッドコーダーが多い理由

[0994 デフォルトの名無しさん 2022/08/29(月) 15:28:49.68 ID:XtVEyX62]

numpyでええやん

[0995 デフォルトの名無しさん 2022/08/29(月) 17:54:32.14 ID:q9iRl6Qa]

Fortran変数名の規則が他の言語とだいぶ違うし変な省略多いしマジ読みづらい

[0996 デフォルトの名無しさん 2022/08/29(月) 18:58:34.91 ID:vUI7JH1g]

ブッラータ

[0997 デフォルトの名無しさん 2022/08/30(火) 00:59:24.56 ID:O4AMSTyA]

>>887
なぜC++や他の言語はその(3)まで進めなかったのだろう？

[0998 デフォルトの名無しさん 2022/08/30(火) 02:29:24.49 ID:KhloiM1N]

>>997
コンパイラが収束しない

[0999 デフォルトの名無しさん 2022/08/30(火) 08:10:41.84 ID:V3AAJ1E8]

>>997
ガチガチになりすぎて実用的じゃないから、GCに任せる方向になった。

[1000 デフォルトの名無しさん 2022/08/30(火) 08:11:01.83 ID:V3AAJ1E8]

1000