スレタイ以外の言語もok
前スレ
https://mevius.5ch.net/test/read.cgi/tech/1655771266/
次世代言語27 TypeScript Swift Go Kotlin Rust Nim
レス数が1000を超えています。これ以上書き込みはできません。
2022/08/05(金) 08:26:38.87ID:TpiqaUBm
2022/08/05(金) 08:37:03.30ID:KgIsFrhc
ワッチョイないから立て直し？
2022/08/05(金) 09:05:00.04ID:b6gTveVP
ここは歴代ずっとワッチョイ無しの自由な雑談ができる次世代言語スレ
あと特定の言語を排除しようとするおかしな人は無視していい
あと特定の言語を排除しようとするおかしな人は無視していい
2022/08/05(金) 09:42:49.97ID:/hLfNpmA
ﾜｯﾁｮｲありスレはこちら
次世代言語27 Nim Zig Pony Carbon Gleam
https://mevius.5ch.net/test/read.cgi/tech/1659660050/
次世代言語27 Nim Zig Pony Carbon Gleam
https://mevius.5ch.net/test/read.cgi/tech/1659660050/
2022/08/05(金) 13:52:56.66ID: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の開発に使っている。
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の開発に使っている。
6デフォルトの名無しさん
2022/08/05(金) 19:29:36.02ID:BU8XQp8V ここが新しいRustのスレでつか？
7デフォルトの名無しさん
2022/08/05(金) 19:37:35.48ID:+d0T8I82 >>5
図がわかりやすくていいね
図がわかりやすくていいね
2022/08/05(金) 20:37:12.78ID:/2EXcwTq
2022/08/05(金) 20:40:03.72ID:Z7rCc0jt
>>5
設計図共有サイト、謎の半導体メーカー・エヌビディア！ｗｗｗ
設計図共有サイト、謎の半導体メーカー・エヌビディア！ｗｗｗ
2022/08/05(金) 22:17:43.36ID:BMQn4j6g
今からtsは要らないよな
11デフォルトの名無しさん
2022/08/05(金) 23:40:01.91ID:neUxGv7V2022/08/06(土) 00:27:04.14ID:VEv62Z69
2022/08/06(土) 03:44:12.91ID:XeXelAmy
>>10
WebブラウザでJavaScriptかWasmが必須だからTSは欠点あれど重要な位置を保つでしょう
Wasm by Rustだけでも行けるけど両者の異なる利点を両取りするハイブリッドが主流になると予想
WebブラウザでJavaScriptかWasmが必須だからTSは欠点あれど重要な位置を保つでしょう
Wasm by Rustだけでも行けるけど両者の異なる利点を両取りするハイブリッドが主流になると予想
2022/08/06(土) 05:46:10.00ID:LQR5jobs
>>13
もう「次世代」じゃないだろ。
もう「次世代」じゃないだろ。
2022/08/06(土) 05:59:09.03ID:0/UjvMUm
マルチスレッドで使えないからウェブアセンブリ意味ないじゃんっていわれてたけど解決したんかい？
2022/08/06(土) 10:17:41.69ID:LLV93bqs
>>5
Java C# より微妙に右に行ってるのは理由があってのことなのかね？
Java C# より微妙に右に行ってるのは理由があってのことなのかね？
2022/08/06(土) 10:35:52.17ID:WeMd0Hwa
Rustがパフォーマンスも生産性も最強ならISUCONで全然使われてないってのは何でなの？
18デフォルトの名無しさん
2022/08/06(土) 11:25:45.97ID:aWQzwcS0 生産性も指す範囲が認識違ってるからじゃない。
動くものを短い時間で作れるかじゃなくて、継続開発におけるメンテコストが小さくなるのが特徴なんでは。
動くものを短い時間で作れるかじゃなくて、継続開発におけるメンテコストが小さくなるのが特徴なんでは。
19デフォルトの名無しさん
2022/08/06(土) 11:37:56.35ID:Zy70ULhC 難解でスパゲティ化しやすいからメンテコストは上がると思う。
2022/08/06(土) 11:55:38.60ID:rrIoMakq
21デフォルトの名無しさん
2022/08/06(土) 11:58:56.35ID:Zy70ULhC >>20
従来のプログラミング言語より開発期間が延びることは、開発者も認めてる。
従来のプログラミング言語より開発期間が延びることは、開発者も認めてる。
2022/08/06(土) 12:10:11.68ID:JDezbopU
GoがISUCONでは圧倒的みたいだけど、Goは素早くパフォーマンスが出るプログラムを作れるってことが証明されてるな
またGoは継続的メンテの生産性も非常に高い
グーグルのような大企業やKubernetesなどクラウド関連のツールで使われていることから証明されてる
継続メンテの生産性を上げるためにはコードの可読性が重要なわけだけどGoほど他人の書いたコードが読みやすい言語を俺は知らない
機能を削りまくってオーバーエンジニアリングを不可能にさせてるってのがかなり可読性に寄与してると思う
あと標準ライブラリが充実してるのも可読性あげてる
つまり生産性で最強なのはGo。
またGoは継続的メンテの生産性も非常に高い
グーグルのような大企業やKubernetesなどクラウド関連のツールで使われていることから証明されてる
継続メンテの生産性を上げるためにはコードの可読性が重要なわけだけどGoほど他人の書いたコードが読みやすい言語を俺は知らない
機能を削りまくってオーバーエンジニアリングを不可能にさせてるってのがかなり可読性に寄与してると思う
あと標準ライブラリが充実してるのも可読性あげてる
つまり生産性で最強なのはGo。
2022/08/06(土) 12:16:05.20ID:XcW48Anf
>>16
nikkeiにそういうの求めちゃダメだから
nikkeiにそういうの求めちゃダメだから
24デフォルトの名無しさん
2022/08/06(土) 12:33:16.19ID:Zy70ULhC Rustを流行らせようと頑張ってるのは、セミナー商法の人たちだろ。
成果なんか出ないから、長期にわたって相談があり、報酬が得られる。
成果なんか出ないから、長期にわたって相談があり、報酬が得られる。
2022/08/06(土) 12:39:09.16ID:/NAfx8SK
>>21
Rustは抽象的に開発効率よくプログラミングしやすいため開発期間は短くなってるな
Rustは抽象的に開発効率よくプログラミングしやすいため開発期間は短くなってるな
2022/08/06(土) 13:27:01.16ID:SGd1AFHA
>>25
なんかデータあるんですか？
なんかデータあるんですか？
2022/08/06(土) 13:35:05.96ID:hNQC/RRg
逆効果になってる事をいまだに分からないバカ専用言語
2022/08/06(土) 13:51:00.45ID:fIYdbcv5
基本的にはプログラムは書いた通りに動く
想定を超えた効果が生じるという主張自体が、基本からかなり乖離している
想定を超えた効果が生じるという主張自体が、基本からかなり乖離している
29デフォルトの名無しさん
2022/08/06(土) 14:04:55.90ID:Zy70ULhC2022/08/06(土) 14:08:52.98ID:TnfZT8O1
31デフォルトの名無しさん
2022/08/06(土) 14:09:49.54ID:Zy70ULhC 統一教会が動員されてるのでは？
32デフォルトの名無しさん
2022/08/06(土) 14:11:24.34ID:Zy70ULhC33デフォルトの名無しさん
2022/08/06(土) 14:12:15.10ID:Zy70ULhC 統一教会がセミナー商法で儲けようとして自民党の先生方とタッグを組んだってことでは？
2022/08/06(土) 14:17:36.29ID:fIYdbcv5
行き過ぎた金儲けは経済の失敗でしょ
エンジニアリングの失敗みたいに言うなよ
エンジニアリングの失敗みたいに言うなよ
35デフォルトの名無しさん
2022/08/06(土) 14:19:54.18ID:Zy70ULhC Rustは世界で全く注目されない失敗言語。
日本でのみ注目されてるのは、何らかの工作がある。
統一教会の信者になっても、幸福にはならない。
日本でのみ注目されてるのは、何らかの工作がある。
統一教会の信者になっても、幸福にはならない。
36デフォルトの名無しさん
2022/08/06(土) 14:22:09.40ID:Zy70ULhC RustはC++のサブセットだから、普通は「C++でおｋ」ってなる。
それが世界標準。
日本だけ異常値を示すのは、何らかの事情がある。
統一教会とか統一教会とか統一教会とか。
それが世界標準。
日本だけ異常値を示すのは、何らかの事情がある。
統一教会とか統一教会とか統一教会とか。
37デフォルトの名無しさん
2022/08/06(土) 14:28:25.57ID:Zy70ULhC 統一教会のマネー部門が「プログラミング教育必修化に伴う新規事業の立ち上げ」と関連して「Rustの国家言語化」を推進してるんだろ。
38デフォルトの名無しさん
2022/08/06(土) 14:30:13.11ID:Zy70ULhC 「ファミリー」「世界」「みんなの」ってつく教材が出てきたら、統一を疑え。
全国の小中学生が統一の教科書で学ぶ異常事態。
全国の小中学生が統一の教科書で学ぶ異常事態。
2022/08/06(土) 14:36:06.27ID:fIYdbcv5
hello worldをhello 世界って書いたらアウトってことか
2022/08/06(土) 14:38:56.74ID:k4A078eF
安全性と可読性がトレードオフになるケースについてrust厨は全く考慮してないんだよな。
41デフォルトの名無しさん
2022/08/06(土) 14:41:47.93ID:Zy70ULhC それ以前に、メモリーでバグるのは初心者だけなので、戦力化した後は必要とされなくなる機能。
そこに全振りした言語が受け入れられるわけはなく、実際、世界では受け入れられていない。
そこに全振りした言語が受け入れられるわけはなく、実際、世界では受け入れられていない。
42デフォルトの名無しさん
2022/08/06(土) 14:45:08.37ID:Zy70ULhC ちなみにわたくしはC++で書く時も、newとかdeleteとか、もはや書いていませんから。
2022/08/06(土) 15:03:35.78ID:95xiI4eN
>>40
可読性はRustが優れていると感じた
例えば前スレのこのRustのコードも他の言語のコードより読みやすい
https://gist.github.com/rust-play/f03d2e73ee4e76acf69c98b7a8b8d322
可読性はRustが優れていると感じた
例えば前スレのこのRustのコードも他の言語のコードより読みやすい
https://gist.github.com/rust-play/f03d2e73ee4e76acf69c98b7a8b8d322
2022/08/06(土) 15:19:50.06ID:LK6Z1Hbl
>>43
全く同じことをしているのにoptimized.cやoptimuzed.cppの可読性が低いのはC/C++が原始的というか抽象度が低いためだろう
全く同じことをしているのにoptimized.cやoptimuzed.cppの可読性が低いのはC/C++が原始的というか抽象度が低いためだろう
2022/08/06(土) 16:23:13.29ID:OUo1sMqN
Rust＝スパゲティ
でもメモリは安心
でもメモリは安心
2022/08/06(土) 16:55:09.41ID:SdbuTVvd
こっちが本スレか
2022/08/06(土) 17:07:52.91ID:n2+0u9Mg
何故か、ここのスレでは銀の弾丸みたいに叫んでる人が目立っているのが、気になる。
48デフォルトの名無しさん
2022/08/06(土) 18:11:23.30ID:Zy70ULhC 統一教会の信者さんが叫んでるだけでは。
49デフォルトの名無しさん
2022/08/06(土) 18:32:09.80ID:Zy70ULhC50デフォルトの名無しさん
2022/08/06(土) 19:40:54.78ID:dh8YGzDk なんか山上みたいなやつだな
2022/08/06(土) 20:38:42.34ID:Snr/GczG
なんか単なる手続き型から外れれば外れるほど流行らなくなるのを見てると初心者を取り込むことがいかに大事かということを考えさせられる
2022/08/06(土) 21:01:46.81ID:fIYdbcv5
銀の弾丸って単語だけ流行らせて
「人数を2倍にしても時間は半分にならない」って事実を教えなかったことを反省しろよ
逆に時間を何倍かにすれば猿が人に進化するのでは？
「人数を2倍にしても時間は半分にならない」って事実を教えなかったことを反省しろよ
逆に時間を何倍かにすれば猿が人に進化するのでは？
2022/08/06(土) 21:34:34.98ID:95xiI4eN
>>51
手続き型の方が分かりやすいと勘違いしてしまうのは手続き型で学習を始めた場合の初心者のうちだけで
次のステップでだらだらと手続き型で書くのは分かりにくく保守性も悪いと気付く
そして手続き型な部分を完全に排除してしまうと効率悪いことも理解できると最善に組み合わせたハイブリッドへ進む
手続き型の方が分かりやすいと勘違いしてしまうのは手続き型で学習を始めた場合の初心者のうちだけで
次のステップでだらだらと手続き型で書くのは分かりにくく保守性も悪いと気付く
そして手続き型な部分を完全に排除してしまうと効率悪いことも理解できると最善に組み合わせたハイブリッドへ進む
2022/08/06(土) 22:22:50.50ID:fIYdbcv5
昔話では、正直者を完全に（排除ではなく）コピーするのが非効率と思い込んで
ハイブリッドへ進んでしまう物語が多い
ハイブリッドへ進んでしまう物語が多い
55デフォルトの名無しさん
2022/08/06(土) 22:26:51.83ID:Zy70ULhC もう全部入りのC++でいいじゃん。
2022/08/06(土) 23:19:33.24ID:Snr/GczG
2022/08/06(土) 23:28:47.16ID:LK6Z1Hbl
2022/08/06(土) 23:38:04.36ID:95xiI4eN
>>56
末端のユーザーなんてどうでもよい
自分たちがいかに全体(デバッグ時、メンテ時、実行時リソースなど含む)を効率よく出来るかが重要
様々な点で効率の悪い言語が簡単だからという理由で世間で普及していてもどうでもよい話
末端のユーザーなんてどうでもよい
自分たちがいかに全体(デバッグ時、メンテ時、実行時リソースなど含む)を効率よく出来るかが重要
様々な点で効率の悪い言語が簡単だからという理由で世間で普及していてもどうでもよい話
2022/08/07(日) 00:04:55.22ID:ql1TgpH2
2022/08/07(日) 00:15:54.62ID:nCVSRdWl
61デフォルトの名無しさん
2022/08/07(日) 11:08:52.89ID:wbukB5Xn 次世代とスレタイあるのに何故今の言語を必死にアピールしてるのかね。
せめてその言語の将来のバージョンでの新機能とか廃止される機能について書けないのかね。
せめてその言語の将来のバージョンでの新機能とか廃止される機能について書けないのかね。
2022/08/07(日) 11:14:42.58ID:xKkoyfCO
次世代wと書くだけでおバカさんが爆釣だからに決まっとるやん
2022/08/07(日) 11:48:34.37ID:kBhOCwz1
隔離スレあるからRustアンチ装ってネガキャンしていいよね
2022/08/07(日) 11:49:29.82ID:yn0NLwDm
ジェネリクスを採用するか落とすか
実数クラスは複素数クラスを継承するか
この辺りで時間が止まってるのが現実
実数クラスは複素数クラスを継承するか
この辺りで時間が止まってるのが現実
65デフォルトの名無しさん
2022/08/07(日) 12:02:03.02ID:r7YsBDkd C++はメタ言語でもあるので、言語設計者が使い方を決めるのではなく、ユーザーが使い方を決めるのですよ。
2022/08/07(日) 13:50:25.50ID:6loH3/Cb
今さらC++なんて古い言語を使うメリットが無い
67デフォルトの名無しさん
2022/08/07(日) 14:19:10.56ID:r7YsBDkd メタ言語なので、頭の良い人が使えば次世代を今使えるし、頭の悪い人が使えば昔のパラダイムで使うことになるのでは？
68デフォルトの名無しさん
2022/08/07(日) 14:22:24.87ID:r7YsBDkd そもそもRustはC++のサブセットなので、最終的にはC++を使いこなせるようになることを目指すのでは？
2022/08/07(日) 14:31:11.81ID:IfZGncFx
せやな頑張って極めてくれ
70デフォルトの名無しさん
2022/08/07(日) 15:20:51.91ID:r7YsBDkd おまえがな～♪
2022/08/08(月) 02:39:57.76ID:qWA0y/14
2022/08/08(月) 09:56:34.48ID:O/c+BDEK
>>16
Rustはまだ分かるがGolangがさらに右に行くのはおかしいな。
Rustはまだ分かるがGolangがさらに右に行くのはおかしいな。
2022/08/08(月) 10:06:06.54ID:oHs/K700
最近のC#は値型のサポートが強化されていて、GCを避けたRust的なタスクもある程度カバーできるようになっている
少なくともGoよりは右だな
少なくともGoよりは右だな
2022/08/08(月) 10:10:15.41ID:jJMmsTXK
あたりまえだけどGCはあった方がいいに決まってる
そんなにGCがないことが重要ならISUCONはみんなRustを使ってる
Webやサーバーサイドのプログラムは他にボトルネックがあるからGCの有無なんてどうでもいいんだよ
そんなの気にせず適当にかけたほうがよい
Rustは適当に書くことはできない
だから適していない
そんなにGCがないことが重要ならISUCONはみんなRustを使ってる
Webやサーバーサイドのプログラムは他にボトルネックがあるからGCの有無なんてどうでもいいんだよ
そんなの気にせず適当にかけたほうがよい
Rustは適当に書くことはできない
だから適していない
2022/08/08(月) 10:24:49.37ID:oHs/K700
GCが走ることで一時的にレイテンシが増大することがあるから、
安定したレイテンシでレスポンスを返すことが重要ならGCを避けることも検討する必要があるかもしれない
まあWeb程度ならプロファイル取ってGCに大きな負荷をかけている「極一部の」コードについて実装を修正するだけの話なので、
Rustに書き換えようぜとか言い出す極論馬鹿は無視してよい
安定したレイテンシでレスポンスを返すことが重要ならGCを避けることも検討する必要があるかもしれない
まあWeb程度ならプロファイル取ってGCに大きな負荷をかけている「極一部の」コードについて実装を修正するだけの話なので、
Rustに書き換えようぜとか言い出す極論馬鹿は無視してよい
2022/08/08(月) 10:30:03.58ID:5wQFqA4Q
適当に書けるか否かはGCの有無関係ある？
2022/08/08(月) 10:30:20.15ID:5wQFqA4Q
適当に書けるか否かはGCの有無関係ある？
2022/08/08(月) 10:30:32.39ID:oZ9hPUlf
2022/08/08(月) 10:31:14.85ID:5wQFqA4Q
適当に書けるか否かはGCの有無関係ある？
2022/08/08(月) 10:37:54.22ID:oZ9hPUlf
>>74
GCがあったほうがよいとの主張を初めて見ました
GCは無い方が当然有利です
ただしRust登場以前はGC無しだとC/C++となりメモリ解放がプログラマーの責任となり複雑な場合は穴が発生しがちでした
今は自動メモリ解放されるRustがありますからGC無しでもそのような問題を避けられます
GCがあったほうがよいとの主張を初めて見ました
GCは無い方が当然有利です
ただしRust登場以前はGC無しだとC/C++となりメモリ解放がプログラマーの責任となり複雑な場合は穴が発生しがちでした
今は自動メモリ解放されるRustがありますからGC無しでもそのような問題を避けられます
2022/08/08(月) 10:41:10.14ID:/aBGPumi
>>80
生産性のことを言ってるけど
C++やCをあらゆるプログラムで使う人ってなかなかいないよね？
RubyやPythonが流行ってたのはGC言語だからでは？
Rustはその流れに逆行してるのでC++やCを置き換えてもRuby Python. Node Goを置き換えることはないね
生産性のことを言ってるけど
C++やCをあらゆるプログラムで使う人ってなかなかいないよね？
RubyやPythonが流行ってたのはGC言語だからでは？
Rustはその流れに逆行してるのでC++やCを置き換えてもRuby Python. Node Goを置き換えることはないね
2022/08/08(月) 10:52:59.61ID:/aBGPumi
あとRust信者はGCを毛嫌いしているが最近はどんどん進化してる
コンピュータ側の進化に期待しないのはなぜ？
それに対してユーザーに責任を丸投げしてるのがRust
OSやドライバ開発者には良いが大半の開発者にとってそれは無駄な負担となる
コンピュータ側の進化に期待しないのはなぜ？
それに対してユーザーに責任を丸投げしてるのがRust
OSやドライバ開発者には良いが大半の開発者にとってそれは無駄な負担となる
2022/08/08(月) 11:14:27.79ID:6lpblQL4
>>82
ウソはよくないな
Rustの世界的な利用調査結果を見てもOSやドライバなんかではなく
圧倒的なRust利用トップがサーバーサイド／バックエンド分野
軽くて速くてプログラミングしやすいRustが使われる
そしてリソースコスト激減から反応性の良さまで恩恵を得られるのがRust
ウソはよくないな
Rustの世界的な利用調査結果を見てもOSやドライバなんかではなく
圧倒的なRust利用トップがサーバーサイド／バックエンド分野
軽くて速くてプログラミングしやすいRustが使われる
そしてリソースコスト激減から反応性の良さまで恩恵を得られるのがRust
2022/08/08(月) 11:21:23.06ID:lzv6yAzd
スパゲッティRustは適当に書けないよな
85デフォルトの名無しさん
2022/08/08(月) 11:30:43.29ID:/aLuVjy4 Rustで書くとスパゲティ化を防いで読み書きメンテしやすい良いコードになる利点もありますね
2022/08/08(月) 11:41:49.41ID:Chuc2bn/
>>78
クラウド利用料なんて大抵はDBが大半を占めるし、人件費に比べたら安いもんだよ
仮にAWS費用が月100万円として、そのうち20%がアプリのコンピューティング費用だとしよう
もしRustへの書き換えでコンピューティング費用が50%になれば月10万円の節約だ
単価200万の凄腕Rustプログラマが一ヶ月で作業したらペイするまでに20ヶ月かかる
そして以後もRustを使える高単価の人間を飼う必要があるわけだ
Rust信者としても、GC言語しか使えないプログラマよりも自分達の単価が大幅に高いことは否定したくないだろう？
クラウド利用料なんて大抵はDBが大半を占めるし、人件費に比べたら安いもんだよ
仮にAWS費用が月100万円として、そのうち20%がアプリのコンピューティング費用だとしよう
もしRustへの書き換えでコンピューティング費用が50%になれば月10万円の節約だ
単価200万の凄腕Rustプログラマが一ヶ月で作業したらペイするまでに20ヶ月かかる
そして以後もRustを使える高単価の人間を飼う必要があるわけだ
Rust信者としても、GC言語しか使えないプログラマよりも自分達の単価が大幅に高いことは否定したくないだろう？
2022/08/08(月) 12:02:17.62ID:Og0DlKRv
なんでもかんでもRustが良い、っていってるのはどうみても仕事経験の薄いキッズだろ
納得なんか不可能だから構うなよ
納得なんか不可能だから構うなよ
2022/08/08(月) 12:06:40.32ID:6lpblQL4
>>86
クラウドでDBのコストが高いのはRDB利用時だけだぞ
RDBはコストが高いだけでなくパフォーマンス面でも不利だから利用を最小限にする
そしてクラウド提供の安く高パフォーマンスの非RDBなDBを用いたり自前の非RDBなDBサーバをクラウドに構築
いずれにしてもRustが活躍する領域
クラウドでDBのコストが高いのはRDB利用時だけだぞ
RDBはコストが高いだけでなくパフォーマンス面でも不利だから利用を最小限にする
そしてクラウド提供の安く高パフォーマンスの非RDBなDBを用いたり自前の非RDBなDBサーバをクラウドに構築
いずれにしてもRustが活躍する領域
2022/08/08(月) 12:07:15.97ID:xzpYaZGN
正直Rustの仕事なんて一度も見た事が無い
業務に使われている事が本当にあるのか？
少なくとも日本で採用するような会社殆ど無い気がする
業務に使われている事が本当にあるのか？
少なくとも日本で採用するような会社殆ど無い気がする
2022/08/08(月) 12:11:11.88ID:Chuc2bn/
>>88
まさに仕事経験の薄いキッズだねえ
まさに仕事経験の薄いキッズだねえ
91デフォルトの名無しさん
2022/08/08(月) 12:20:00.34ID:TAwO3GZO2022/08/08(月) 12:28:08.43ID:/aLuVjy4
>>86
それDBサーバー費用が高くなっているは何でもかんでもSQLに押し付けているパターンの時ですよ
技術力のないところはそれで仕方ないでしょうけどそれは無駄で非効率ですから普通は可能な限りNoSQLにして費用を下げるとともに効率を上げます
SQLを使わない代わりにその様々な処理のコードを書くことになりますが最適化が出来るため高速化と費用激減の両方を得られます
そこで使われている言語はGC言語よりもRustが好ましいことは言うまでもないでしょう
それDBサーバー費用が高くなっているは何でもかんでもSQLに押し付けているパターンの時ですよ
技術力のないところはそれで仕方ないでしょうけどそれは無駄で非効率ですから普通は可能な限りNoSQLにして費用を下げるとともに効率を上げます
SQLを使わない代わりにその様々な処理のコードを書くことになりますが最適化が出来るため高速化と費用激減の両方を得られます
そこで使われている言語はGC言語よりもRustが好ましいことは言うまでもないでしょう
2022/08/08(月) 12:34:17.42ID:QO/dWc4g
RustだけでなくNoSQLに幻想を抱くキッズ
2022/08/08(月) 12:35:55.92ID:/aBGPumi
じゃあISUCONでRust出て予選通過してみたらどうなの
100万円もらえるし学生でも優勝してたりするぞ
Rustキッズ頑張れよ笑
100万円もらえるし学生でも優勝してたりするぞ
Rustキッズ頑張れよ笑
2022/08/08(月) 12:39:46.19ID:/aBGPumi
そんなにコストコスト気になるのに人件費を気にしないのはなぜ？
個人開発ならともかくRustキッズ曰くエンタープライズでバックエンドサーバーサイド分野で広まりまくってるらしいじゃん
個人開発ならともかくRustキッズ曰くエンタープライズでバックエンドサーバーサイド分野で広まりまくってるらしいじゃん
2022/08/08(月) 12:40:30.24ID:LL3uQ1oy
Rustでエスケープ解析に触れない奴は勉強不足だから無視していいよ。
2022/08/08(月) 12:53:17.40ID:Chuc2bn/
十分な実務経験があってRust推す人はどちらかというとRDB好きな人が多い印象だな
RDBは固定長レコード時代の設計思想を色濃く受け継いでいて、
変なORMを噛まさずに正しく使えばクライアント側のメモリ管理が極めて効率的だからRustとは思想的な相性が良いと思うよ
RDBは固定長レコード時代の設計思想を色濃く受け継いでいて、
変なORMを噛まさずに正しく使えばクライアント側のメモリ管理が極めて効率的だからRustとは思想的な相性が良いと思うよ
2022/08/08(月) 13:01:54.54ID:YWEH8Nnf
Rustキッズも草だがISUCONキッズも草
二人ともまともな仕事探しなよ
二人ともまともな仕事探しなよ
2022/08/08(月) 13:04:26.73ID:6lpblQL4
>>97
大手ITの様々なサービスがなぜ非RDB利用なのか
クラウドでなぜ非RDBが提供されているのか
クラウドが提供するRDBの高コストなど現実を理解していれば
RDBの利用を必要最小限にした方が有利なことが理解できるだろう
大手ITの様々なサービスがなぜ非RDB利用なのか
クラウドでなぜ非RDBが提供されているのか
クラウドが提供するRDBの高コストなど現実を理解していれば
RDBの利用を必要最小限にした方が有利なことが理解できるだろう
100デフォルトの名無しさん
2022/08/08(月) 13:10:53.01ID:PVcyS4q4 >>99
コストの問題じゃねーよw
コストの問題じゃねーよw
101デフォルトの名無しさん
2022/08/08(月) 13:11:12.07ID:HxYRacQm 好き嫌いで決めるもんじゃないでしょ
102デフォルトの名無しさん
2022/08/08(月) 13:29:22.09ID:GCEjPBap >>94
Rustで予選突破しましたという記事がすぐみつかるんたが…
Rustで予選突破しましたという記事がすぐみつかるんたが…
103デフォルトの名無しさん
2022/08/08(月) 13:31:44.99ID:QO/dWc4g104デフォルトの名無しさん
2022/08/08(月) 13:51:44.39ID:CLPoy81X Perlが1/5に対してRustは1/19
つまりPerlエンジニアの方がRustより強い
つまりPerlエンジニアの方がRustより強い
105デフォルトの名無しさん
2022/08/08(月) 13:53:43.99ID:/aBGPumi Goの半分ぐらい通過するようになってから普及してると言ってくれ
106デフォルトの名無しさん
2022/08/08(月) 14:02:38.72ID:/aLuVjy4 競技プログラミングもISUCONも実際にある仕事と離れすぎていてゲームの範疇といった感じ
もちろんアルゴリズムを考え付き実装する能力やシステムの問題点を見つけ出し改善する能力は非常に重要だけど時間で競うものではないね
ましてやそこでの使用言語の状況に意味はないでしょう
もちろんアルゴリズムを考え付き実装する能力やシステムの問題点を見つけ出し改善する能力は非常に重要だけど時間で競うものではないね
ましてやそこでの使用言語の状況に意味はないでしょう
107デフォルトの名無しさん
2022/08/08(月) 14:08:02.05ID:WrKjimA+ 何かと優劣付けたがる生き物っているけど
割と煙たがられてたイメージだわ
割と煙たがられてたイメージだわ
108デフォルトの名無しさん
2022/08/08(月) 14:10:56.01ID:MJuU9BY+109デフォルトの名無しさん
2022/08/08(月) 14:16:32.02ID:QO/dWc4g 2019年のRust参加者は0組だったことを踏まえると、ISUCONでのRust利用者は異常にめちゃくちゃ増えてるから、これからどうなるかはわからんけどね
2019年はRustの参加者0組だった
2019年はRustの参加者0組だった
110デフォルトの名無しさん
2022/08/08(月) 14:17:03.91ID:QO/dWc4g 推敲するつもりが間違って送信してしまった・・・
https://isucon.net/archives/53789935.html
https://isucon.net/archives/53789935.html
111デフォルトの名無しさん
2022/08/08(月) 14:30:44.53ID:z8XdWceR >>103
むしろそこにCもC++も無いのになぜ非GC言語からRustだけが参戦できているのか？が重要なところだ
Rustという言語がカバーできる領域の広さ強さを示している
過去にはC++での参戦もあったがC++は消滅したのもそれを裏付ける
あとISUCONではこの前までRustには参考実装すら用意されなかった
今はGoの参考実装から移植してくれる人のおかげで用意されるようになったようだ
とはいえど初期状態ではGoが起動といったように扱いに差がある
そのほか様々なハンデがありつつもRustはむしろ健闘しているといえる
むしろそこにCもC++も無いのになぜ非GC言語からRustだけが参戦できているのか？が重要なところだ
Rustという言語がカバーできる領域の広さ強さを示している
過去にはC++での参戦もあったがC++は消滅したのもそれを裏付ける
あとISUCONではこの前までRustには参考実装すら用意されなかった
今はGoの参考実装から移植してくれる人のおかげで用意されるようになったようだ
とはいえど初期状態ではGoが起動といったように扱いに差がある
そのほか様々なハンデがありつつもRustはむしろ健闘しているといえる
112デフォルトの名無しさん
2022/08/08(月) 14:34:47.89ID:QO/dWc4g Goの利用者なんてもはやペチパーみたいなもんだし、本当にRustが強いというなら他言語利用者よりもダントツな通過率を見せてほしいものだ
113デフォルトの名無しさん
2022/08/08(月) 15:28:50.47ID:nLF3s4L3 ISUCONよく知らんけど
言語の速度が直接影響を与えるような課題はまずないでしょ
しかしなぜそこまでGoが多いのか理解不能ではある
言語の速度が直接影響を与えるような課題はまずないでしょ
しかしなぜそこまでGoが多いのか理解不能ではある
114デフォルトの名無しさん
2022/08/08(月) 18:33:28.61ID:sf8DoyKQ115デフォルトの名無しさん
2022/08/08(月) 18:44:43.21ID:YeAhfKJe116デフォルトの名無しさん
2022/08/08(月) 18:48:36.68ID:sf8DoyKQ >>115
ISUCONが何か知らないけど、キミの情報だけ見ると、アプリ用言語とウェブ用言語で使われる使われないが分かれてるように見えるよ。
ISUCONが何か知らないけど、キミの情報だけ見ると、アプリ用言語とウェブ用言語で使われる使われないが分かれてるように見えるよ。
117デフォルトの名無しさん
2022/08/08(月) 18:51:02.17ID:Ztz4OmA/ 勉強会と称して会社でセミナー開いて社員から参加料徴収してそう
118デフォルトの名無しさん
2022/08/08(月) 18:57:37.93ID:YeAhfKJe119デフォルトの名無しさん
2022/08/08(月) 18:59:58.38ID:sf8DoyKQ >>118
HTMLの次に手を出すのがJavascriptやRustじゃないかな？
HTMLの次に手を出すのがJavascriptやRustじゃないかな？
120デフォルトの名無しさん
2022/08/08(月) 19:06:15.39ID:xzpYaZGN Goももう終わりそうな感じがするのだが
webでもAPI用途で使う分にはアリかも知れないがそこまで高速化がアプリで必要無いんだよね
ボトルネックは大体RDBとかだしPHPで十分なんだよね
webでもAPI用途で使う分にはアリかも知れないがそこまで高速化がアプリで必要無いんだよね
ボトルネックは大体RDBとかだしPHPで十分なんだよね
121デフォルトの名無しさん
2022/08/08(月) 19:06:45.72ID:GdyVfCQX >>115
運営が実装を提供してる言語に限定されるからだよ
運営が実装を提供してる言語に限定されるからだよ
122デフォルトの名無しさん
2022/08/08(月) 19:14:13.82ID:sf8DoyKQ ウェブの人たちって信仰に篤いでしょ。
このスレのRust民の書き込み見る感じ、ウェブの人たちじゃないかなあと思うよ。
このスレのRust民の書き込み見る感じ、ウェブの人たちじゃないかなあと思うよ。
123デフォルトの名無しさん
2022/08/08(月) 19:25:42.83ID:U++CWrZh >>121
ISUCONでの使用言語は自由で制限なし
運営が需要から判断していくつかの言語で参考実装を提供するけど
それは無視して自分で自由にコードを書いてもよい
例えば以前はRustの参考実装は提供されなかったけどその時からRust利用での参加者はいた
ISUCONで使用する言語は任意であり各参加者が自由に選べる
ISUCONでの使用言語は自由で制限なし
運営が需要から判断していくつかの言語で参考実装を提供するけど
それは無視して自分で自由にコードを書いてもよい
例えば以前はRustの参考実装は提供されなかったけどその時からRust利用での参加者はいた
ISUCONで使用する言語は任意であり各参加者が自由に選べる
124デフォルトの名無しさん
2022/08/08(月) 19:29:52.39ID:vqcSUYjk125デフォルトの名無しさん
2022/08/08(月) 19:35:28.21ID:sf8DoyKQ でも、ウェブで一番使われてるのがPHPでは？
126デフォルトの名無しさん
2022/08/08(月) 19:38:38.94ID:Ztz4OmA/ ワープレな？
127デフォルトの名無しさん
2022/08/08(月) 19:42:30.46ID:xzpYaZGN >>124みたいな型を連呼する奴ってロクにプログラム組めないんだろうなぁ
現実的な話サーバーサイドにjsも無いけどTSとか余計に無いｗ
こんなトランスパイル前提の言語なんて確実に消えるから
PHPすら扱えないならこの板来るなよｗ
現実的な話サーバーサイドにjsも無いけどTSとか余計に無いｗ
こんなトランスパイル前提の言語なんて確実に消えるから
PHPすら扱えないならこの板来るなよｗ
128デフォルトの名無しさん
2022/08/08(月) 19:47:48.61ID:vqcSUYjk >>127
C10k問題知ってる？Nodeが流行った理由が非同期プログラミングに強いことだけど
何でトランスパイラ前提だと消えるんだ？
そんなことより動的型でPHPだとまともに保守ができないゴミプログラムが生産されるだけ
まさにゴミそのもの
C10k問題知ってる？Nodeが流行った理由が非同期プログラミングに強いことだけど
何でトランスパイラ前提だと消えるんだ？
そんなことより動的型でPHPだとまともに保守ができないゴミプログラムが生産されるだけ
まさにゴミそのもの
129デフォルトの名無しさん
2022/08/08(月) 19:54:31.05ID:vqcSUYjk そもそもRubyやPHPみたいな動的型付け言語が流行った理由ってのは
C++やJavaだと変数の宣言ですら型定義が必要で面倒臭いところ
それに対して最近では静的型付けも進化して型推論装備が当たり前となった
これに伴い簡単に扱えるため動的言語をあえて使うメリットも無くなった
Pythonとか型ヒント機能を追加して静的型付けの特徴も取り入れてることから
今時動的型付けなんて時代遅れだということがわかる
型ヒント追加したなんちゃってPHPよりTypescriptやGoやRustの方が生産性は高い
新規プロジェクトでPHPなんてどこも採用してないわ
C++やJavaだと変数の宣言ですら型定義が必要で面倒臭いところ
それに対して最近では静的型付けも進化して型推論装備が当たり前となった
これに伴い簡単に扱えるため動的言語をあえて使うメリットも無くなった
Pythonとか型ヒント機能を追加して静的型付けの特徴も取り入れてることから
今時動的型付けなんて時代遅れだということがわかる
型ヒント追加したなんちゃってPHPよりTypescriptやGoやRustの方が生産性は高い
新規プロジェクトでPHPなんてどこも採用してないわ
130デフォルトの名無しさん
2022/08/08(月) 20:20:36.46ID:xzpYaZGN うわコイツ絶対仕事してないわｗ
普通にサーバーサイドはPHPが一番多いし
お前どこの世界にいるの？ｗ
型連呼する奴は仕事していない事が良く分かるｗ
普通にサーバーサイドはPHPが一番多いし
お前どこの世界にいるの？ｗ
型連呼する奴は仕事していない事が良く分かるｗ
131デフォルトの名無しさん
2022/08/08(月) 20:38:48.95ID:vqcSUYjk 時代の流れについていけないPHPおじさんw
132デフォルトの名無しさん
2022/08/08(月) 20:46:44.42ID:xj88ZuYt 昔ながらのLAMP環境ならそりゃPHPしかないよね
133デフォルトの名無しさん
2022/08/08(月) 21:28:14.57ID:DIxb8BnQ134デフォルトの名無しさん
2022/08/08(月) 23:43:42.79ID:bVB3HabO 自社サービスなら比較的コードと密になるNoSQLの判断も可能やけど
SI案件だと無責任すぎてキャッシュ以外には導入躊躇するよ
SI案件だと無責任すぎてキャッシュ以外には導入躊躇するよ
135デフォルトの名無しさん
2022/08/09(火) 00:24:19.37ID:Plwa9BCw 当然だけどRDBMSの上位互換なNoSQLなんて存在しないしケースバイケースだよ
用途にジャストフィットするなら採用を検討すればいいけど、
ノウハウがないなら耐久試験や障害復旧のシナリオテストなんかもしたいし、かなり時間がかかるね
そもそもRDBでは実現困難なものがあるからそういうのでは使うべき
Redisにあるデータ構造が必要ならRedisを使うし、全文検索が必要なら検索エンジンを使う
RDBで十分なのに無理やりNoSQLをなんでもかんでも使おうとすると、正規化やトランザクション処理が得意なRDBと違って、データが冗長になったりロック処理でわけわからんくなる
あとコストについても、速度がウリなmemcachedやRedisなんかは全部メモリに載せないといけないから大量データを処理するとメモリバカ食いになってメモリたくさん積んだマシンが必要になる
そこも結局はトレードオフだ
用途にジャストフィットするなら採用を検討すればいいけど、
ノウハウがないなら耐久試験や障害復旧のシナリオテストなんかもしたいし、かなり時間がかかるね
そもそもRDBでは実現困難なものがあるからそういうのでは使うべき
Redisにあるデータ構造が必要ならRedisを使うし、全文検索が必要なら検索エンジンを使う
RDBで十分なのに無理やりNoSQLをなんでもかんでも使おうとすると、正規化やトランザクション処理が得意なRDBと違って、データが冗長になったりロック処理でわけわからんくなる
あとコストについても、速度がウリなmemcachedやRedisなんかは全部メモリに載せないといけないから大量データを処理するとメモリバカ食いになってメモリたくさん積んだマシンが必要になる
そこも結局はトレードオフだ
136デフォルトの名無しさん
2022/08/09(火) 01:32:01.59ID:gtiGofbP >>89
トヨタとかいう地方にある会社で募集してたらしいぞ
トヨタとかいう地方にある会社で募集してたらしいぞ
137デフォルトの名無しさん
2022/08/09(火) 07:45:51.86ID:rWBkFnPj 既存システムは過去資産からPHPが多いね。
でもまぁ過去に安易に書いちゃってたから、うちの他部署もバージョンアップするのに苦労してるわ。動的言語はダメだなと思った。
でもまぁ過去に安易に書いちゃってたから、うちの他部署もバージョンアップするのに苦労してるわ。動的言語はダメだなと思った。
138デフォルトの名無しさん
2022/08/09(火) 09:09:16.70ID:xpcAQEM+ アップデートってバージョン0からバージョン100に飛んだ方が安上がりだよな
1ずつ増やしてたらコスト100倍
1ずつ増やしてたらコスト100倍
139デフォルトの名無しさん
2022/08/09(火) 11:13:57.93ID:IRkfDrb4 rust案件、なくはないがこれ明らかに前任者が逃げ出したなって案件ばっか。
140デフォルトの名無しさん
2022/08/09(火) 11:16:03.77ID:HlyJMO/P 新規はいいが保守案件なんて誰がやりたがるんだろう
お前らやりたいか？
お前らやりたいか？
141デフォルトの名無しさん
2022/08/09(火) 11:33:50.25ID:MRbKMm0e >>139
そんな嘘を付いてまで逆恨みしている理由を知りたい
そんな嘘を付いてまで逆恨みしている理由を知りたい
142デフォルトの名無しさん
2022/08/09(火) 11:39:41.66ID: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
現実を見ましょう。
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
143デフォルトの名無しさん
2022/08/09(火) 11:48:22.42ID:oe9CXP3N Rustの引継案件はやりたくないな
今では誰も使ってない変なライブラリだらけになってそう
Goなんかはその点では古くなりにくいよね
今では誰も使ってない変なライブラリだらけになってそう
Goなんかはその点では古くなりにくいよね
144デフォルトの名無しさん
2022/08/09(火) 11:50:05.69ID:8voMgtSF145デフォルトの名無しさん
2022/08/09(火) 11:52:09.51ID:tyWaLZiX 型付けって、静的動的よりも強いか弱いの方が重要じゃないの？
146デフォルトの名無しさん
2022/08/09(火) 11:54:00.44ID:tyWaLZiX >>144
かなり高待遇だけど、こんな高待遇じゃないと、人来ないって事？
かなり高待遇だけど、こんな高待遇じゃないと、人来ないって事？
147デフォルトの名無しさん
2022/08/09(火) 12:08:34.66ID:oe9CXP3N 業務委託だからこんなもんでしょ
148デフォルトの名無しさん
2022/08/09(火) 12:09:53.05ID:yNLec7bJ149デフォルトの名無しさん
2022/08/09(火) 12:13:30.83ID:OiwkcGrC フリーランスで業務委託って責任負わせるって事か？ｗ
準委任しかやってられんよｗ
準委任しかやってられんよｗ
150デフォルトの名無しさん
2022/08/09(火) 13:28:04.16ID:SUUVydRq PHP使ってもいいけど型明示しとけ。
151デフォルトの名無しさん
2022/08/09(火) 13:54:44.47ID:xpcAQEM+ 整数は整数と明示したいが32ビットとか64ビットとか明示したくない
そこで型名をTとする
そこで型名をTとする
152デフォルトの名無しさん
2022/08/09(火) 14:00:22.05ID:/NVuMDrB153デフォルトの名無しさん
2022/08/09(火) 14:24:45.63ID:tyWaLZiX154デフォルトの名無しさん
2022/08/09(火) 14:29:29.55ID:rviNpZ1q155デフォルトの名無しさん
2022/08/09(火) 18:40:37.50ID:oM0lzHLp それ以前に、Rustの案件ではない。
156デフォルトの名無しさん
2022/08/09(火) 19:34:23.64ID:lYYrXFKS157デフォルトの名無しさん
2022/08/09(火) 19:38:57.62ID:oM0lzHLp Rustより速かった。
158デフォルトの名無しさん
2022/08/09(火) 21:03:55.36ID:xpcAQEM+ シェルスクリプトでは、Cと同じ速さのコマンドがあるのは常識で分かる
だがそれを他のスクリプト言語で真似したら多くの人が認知的不協和に陥る
だがそれを他のスクリプト言語で真似したら多くの人が認知的不協和に陥る
159デフォルトの名無しさん
2022/08/09(火) 21:05:46.33ID:tnSRgX+g160デフォルトの名無しさん
2022/08/09(火) 21:06:10.39ID:tnSRgX+g あと非同期プログラミングがまともにできないのでゴミ
161デフォルトの名無しさん
2022/08/09(火) 21:10:47.11ID:EZ4MxSsh 大手で素のPHPが選ばれないのはメンテナンス性が低いから
PHPが7以降速いのはある程度やってる人なら知ってるよ
PHPが7以降速いのはある程度やってる人なら知ってるよ
162デフォルトの名無しさん
2022/08/09(火) 21:21:08.54ID:qPgdF1zn >>159
じゃあお前はシェルスクリプトも使わないのかよ
じゃあお前はシェルスクリプトも使わないのかよ
163デフォルトの名無しさん
2022/08/09(火) 22:06:42.97ID:tnSRgX+g164デフォルトの名無しさん
2022/08/09(火) 22:59:20.68ID:H83BYiRN 正直、Cに型は無いようなもんだしな。
PHP良いぞ。単ファイル単機能で作ったら保守性もそこまで下がらん。
あれはHTML返すから地獄になる。
そもそも本当にPHPやってる会社は静的解析ぐらい内製してるでしょ。
PHP良いぞ。単ファイル単機能で作ったら保守性もそこまで下がらん。
あれはHTML返すから地獄になる。
そもそも本当にPHPやってる会社は静的解析ぐらい内製してるでしょ。
165デフォルトの名無しさん
2022/08/09(火) 23:16:15.02ID:oM0lzHLp これからはキャストの時代ですしね。
166デフォルトの名無しさん
2022/08/10(水) 01:05:45.94ID:EEq1efXU >>164
metaくらいしかPHPやってないってこと？
metaくらいしかPHPやってないってこと？
167デフォルトの名無しさん
2022/08/10(水) 01:38:00.37ID:BY9mJTpO facebookは型付きの独自PHPを実装してそれ使ってるらしいからね
過去の資産が多すぎてそうするしかなかったのだろうけど
過去の資産が多すぎてそうするしかなかったのだろうけど
168デフォルトの名無しさん
2022/08/10(水) 01:48:08.23ID:uIeHvMMb PHPを開発に使ってる会社って事業初期に大量のPHP資産が作られてメンテせざるを得ない会社、っていうイメージしかない
169デフォルトの名無しさん
2022/08/10(水) 02:23:41.34ID:nT9pe/lB ウェブって、当たるも八卦当たらぬも八卦だから。
PHPで始めるのは合理的。
PHPは速いので、当たった場合もリファインまでの時間を稼いでくれるし。
PHPで始めるのは合理的。
PHPは速いので、当たった場合もリファインまでの時間を稼いでくれるし。
170デフォルトの名無しさん
2022/08/10(水) 03:05:15.44ID: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を使い続ける宣言をしている
これにより、優秀なプロが使わなくなるので、
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を使い続ける宣言をしている
171デフォルトの名無しさん
2022/08/10(水) 03:08:04.53ID:nT9pe/lB HaskellはRustと同じコンセプトだから廃れないだろ。
172デフォルトの名無しさん
2022/08/10(水) 03:43:44.42ID:nT9pe/lB HaskellとRustは紙一重。
173デフォルトの名無しさん
2022/08/10(水) 05:49:31.44ID:i8JPdX8W174デフォルトの名無しさん
2022/08/10(水) 07:15:25.76ID:nT9pe/lB 商用はZend Server使うので、滅茶苦茶速いっすよ。
175デフォルトの名無しさん
2022/08/10(水) 07:54:12.37ID:i8JPdX8W >>174
ベンチでも使われた普及しているphpはZend Serverと同じZend Engineが使われている
ベンチでも使われた普及しているphpはZend Serverと同じZend Engineが使われている
176デフォルトの名無しさん
2022/08/10(水) 08:22:36.36ID:rcQfSgy+ 待望の新言語
オブジェクト崇拝は罪！ 古ヘブライ文字で記述する創世的プログラミング言語が降臨
そこはかとなく神聖な感じのするソースコードがやんごとない
https://forest.watch.impress.co.jp/docs/serial/yajiuma/1431426.html
オブジェクト崇拝は罪！ 古ヘブライ文字で記述する創世的プログラミング言語が降臨
そこはかとなく神聖な感じのするソースコードがやんごとない
https://forest.watch.impress.co.jp/docs/serial/yajiuma/1431426.html
177デフォルトの名無しさん
2022/08/10(水) 08:26:31.40ID:LYpt5XQN178デフォルトの名無しさん
2022/08/10(水) 09:35:03.01ID:bxuLoLIR179デフォルトの名無しさん
2022/08/10(水) 10:02:39.54ID:bLf0UnoD 確かに、ペチパーって難しいシステム構成をやりたがらないから、意外とPHP資産って扱いやすいんだよね
過去にSIerが入って無茶苦茶になったシステムに比べたら遥かにマシ
過去にSIerが入って無茶苦茶になったシステムに比べたら遥かにマシ
180デフォルトの名無しさん
2022/08/10(水) 10:10:18.14ID:bxuLoLIR その点で言うとJavaとかRubyで組まれたものがわりと厄介
181デフォルトの名無しさん
2022/08/10(水) 10:21:20.47ID:bLf0UnoD そうそう、それなりに頭使って真面目に作られた、しかし複雑さを制御できるだけのスキルが開発者にないシステムが一番厄介なんだよねえ
難しいものを難しいまま実装して変なデータ連携が大量に生じ、そのくせ目的は正しいことが多いから業務と切り離せなくなる
難しいものを難しいまま実装して変なデータ連携が大量に生じ、そのくせ目的は正しいことが多いから業務と切り離せなくなる
182デフォルトの名無しさん
2022/08/10(水) 10:40:05.09ID:bxuLoLIR Javaの場合標準ライブラリの設計が汚いからそれに習って作られてるシステム自体も設計が汚くてどうしようもないんだよなあ
オブジェクト指向が主流じゃない時代にようわからんヤツが指揮を執って無理やりクラス書いてたってのもあるだろうけど
オブジェクト指向が主流じゃない時代にようわからんヤツが指揮を執って無理やりクラス書いてたってのもあるだろうけど
183デフォルトの名無しさん
2022/08/10(水) 12:42:08.99ID:wdsDlMgu Rustをやり始めてわかったんだけど
一般的に設計が下手だとデータの依存関係がぐちゃぐちゃになりGC言語はそれでも通っちゃうのに対して
Rustで通すにはデータの依存関係を整理するのが一番の近道となるため良い設計にさせられしまう
結果的にRustで書いたコードはメンテナンス性も良くなるという良い副作用が
一般的に設計が下手だとデータの依存関係がぐちゃぐちゃになりGC言語はそれでも通っちゃうのに対して
Rustで通すにはデータの依存関係を整理するのが一番の近道となるため良い設計にさせられしまう
結果的にRustで書いたコードはメンテナンス性も良くなるという良い副作用が
184デフォルトの名無しさん
2022/08/10(水) 12:52:13.96ID:ibGL2wT8 それのどこがいい設計というの？
185デフォルトの名無しさん
2022/08/10(水) 12:57:14.26ID:h5nM35rr 文盲か？
データの依存関係が整理されてるなら、そうでないやつよりいい設計と言えるだろ。
俺はRust使ったことないけどね。
データの依存関係が整理されてるなら、そうでないやつよりいい設計と言えるだろ。
俺はRust使ったことないけどね。
186デフォルトの名無しさん
2022/08/10(水) 13:01:14.16ID:OAjuzVE6 COBOLおすすめ
187デフォルトの名無しさん
2022/08/10(水) 13:24:29.70ID:v2DFTKIi 依存関係がぐちゃぐちゃだとRustでは通らないというのはAがBに依存していてBがAに依存しているというような循環参照があるとRustでは通らないってこと?
循環がある複雑な設計ができないというのはメリットかもしれないけど、どうしても循環が必要な場合はRustは使えないってこと?
循環がある複雑な設計ができないというのはメリットかもしれないけど、どうしても循環が必要な場合はRustは使えないってこと?
188デフォルトの名無しさん
2022/08/10(水) 13:29:04.51ID:bxuLoLIR >>187
共通部分Cを別に括りだしてAとB両方がCを参照するようにすれば大半の場合循環参照は回避できるはずだけど
共通部分Cを別に括りだしてAとB両方がCを参照するようにすれば大半の場合循環参照は回避できるはずだけど
189デフォルトの名無しさん
2022/08/10(水) 13:46:25.86ID:sNqQ8ycT GCは関係なさそう
無理矢理こじつけるならvirtualデストラクタに関係あるが
重要なのはvirtualの方だ
無理矢理こじつけるならvirtualデストラクタに関係あるが
重要なのはvirtualの方だ
190デフォルトの名無しさん
2022/08/10(水) 13:47:44.80ID:cEafvHu4 相当本人の設計レベルが低いんじゃ。。
191デフォルトの名無しさん
2022/08/10(水) 13:51:24.78ID:w+A7Q7I0 >>187
Rustでもそういう互いに依存しあう形も可能だがその分だけ少しだけ複雑な型となる
つまりRustではそんな形を取るよりもスッキリと依存関係が整理された良いデータ設計をした方が書きやすい
そのためRustで書くと自然に良い設計のプログラムになるよう誘導される
Rustでもそういう互いに依存しあう形も可能だがその分だけ少しだけ複雑な型となる
つまりRustではそんな形を取るよりもスッキリと依存関係が整理された良いデータ設計をした方が書きやすい
そのためRustで書くと自然に良い設計のプログラムになるよう誘導される
192デフォルトの名無しさん
2022/08/10(水) 13:56:50.60ID:eN3aIK3B つまり、rustはenterprises向けではない
193デフォルトの名無しさん
2022/08/10(水) 13:58:59.52ID:uIeHvMMb RefCellとか使うと、実行時に借用チェックしてパニックが起きうるんでしょ？
そうするとRust使う意味がなくなっちゃうしな
そうするとRust使う意味がなくなっちゃうしな
194デフォルトの名無しさん
2022/08/10(水) 14:00:14.32ID:bxuLoLIR >>192
いうてもGoogleやMSやFBなんかは積極的にRust導入していくって言ってるしな
いうてもGoogleやMSやFBなんかは積極的にRust導入していくって言ってるしな
195デフォルトの名無しさん
2022/08/10(水) 14:02:45.42ID:sNqQ8ycT gotoはスパゲッティだがcomefromは良い設計という説がある
これを拡大解釈すると
traitとかinterfaceとかの実装側だけが依存関係を宣言するのはスパゲッティである
逆にエンドユーザー側から依存関係を列挙したい
つまり、追放されていたCの共用体の汚名返上をした方がいいのでは
これを拡大解釈すると
traitとかinterfaceとかの実装側だけが依存関係を宣言するのはスパゲッティである
逆にエンドユーザー側から依存関係を列挙したい
つまり、追放されていたCの共用体の汚名返上をした方がいいのでは
196デフォルトの名無しさん
2022/08/10(水) 14:06:25.83ID:bxuLoLIR >>195
共用体はC++じゃなくCじゃなきゃダメな組込みやカーネルなんかの分野だといつでも現役だけどね
共用体はC++じゃなくCじゃなきゃダメな組込みやカーネルなんかの分野だといつでも現役だけどね
197デフォルトの名無しさん
2022/08/10(水) 15:00:30.99ID:B0kpAn2f >>195
Cの共用体は時代遅れの遺物。
例えばRustでは、排他データ共用であるタグ付き共用体＝ボディ付きenumと、同一データ共用であるtransmuteの、
役割の異なる二つの機能に分化され利便性も安全性も向上している。
Cの共用体は時代遅れの遺物。
例えばRustでは、排他データ共用であるタグ付き共用体＝ボディ付きenumと、同一データ共用であるtransmuteの、
役割の異なる二つの機能に分化され利便性も安全性も向上している。
198デフォルトの名無しさん
2022/08/10(水) 16:04:48.53ID:AhsVHkEa199デフォルトの名無しさん
2022/08/10(水) 16:38:38.42ID:v2DFTKIi Rust使うかどうかに関係なく互いに依存しあうコードとかぐちゃぐちゃな設計は書かないでってみんなに呼びかければいいじゃん。
200デフォルトの名無しさん
2022/08/10(水) 17:06:24.53ID:ZFTliHm/ プロトタイピングレベルだと設計なんて気にしてられない。
Rustはそういうのには使えんな。
Rustはそういうのには使えんな。
201デフォルトの名無しさん
2022/08/10(水) 17:57:07.65ID:h5nM35rr いやいや設計のためにプロトタイピングするんだろ。
本来プロトタイプは捨てるのが前提だから。
捨てる前提だからRust使うまでもないのは同意で、それこそ動的型言語でさくっと作るのでもよい。
本来プロトタイプは捨てるのが前提だから。
捨てる前提だからRust使うまでもないのは同意で、それこそ動的型言語でさくっと作るのでもよい。
202デフォルトの名無しさん
2022/08/10(水) 18:30:28.73ID:F9/ptNap Rustで実用的なソフトウェアを作るにはC/C++の10倍の労力と注意深さが必要。
203デフォルトの名無しさん
2022/08/10(水) 18:35:36.42ID:JllE9vuQ204デフォルトの名無しさん
2022/08/10(水) 18:42:49.97ID:tg6K1NO5205デフォルトの名無しさん
2022/08/10(水) 18:45:06.71ID:F9/ptNap 実用的でメジャーなソフトウェアが皆無。
206デフォルトの名無しさん
2022/08/10(水) 19:12:56.65ID:jrkTB4/i linux
207デフォルトの名無しさん
2022/08/10(水) 19:41:01.41ID:sk3AyQrK208デフォルトの名無しさん
2022/08/10(水) 19:54:14.10ID:bxuLoLIR209デフォルトの名無しさん
2022/08/10(水) 20:20:53.11ID:ELagABQ4 皆一体何と戦っているんだ
210デフォルトの名無しさん
2022/08/10(水) 20:36:32.94ID:1/irOBHJ211デフォルトの名無しさん
2022/08/10(水) 21:12:32.20ID:NmnQYtNj Firefoxって、そんなにRustで置き換えられてる？
元が大きいのもあって、大して置き換わってなかったような。
元が大きいのもあって、大して置き換わってなかったような。
212デフォルトの名無しさん
2022/08/10(水) 21:15:46.69ID:Kdr/lhnJ How much Rust in Firefox?
https://4e6.github.io/firefox-lang-stats/
https://4e6.github.io/firefox-lang-stats/
213デフォルトの名無しさん
2022/08/10(水) 21:47:08.63ID:sNqQ8ycT >>209
むしろ個人と個人の戦いを回避したいから集団を作らせようとしている印象だが
むしろ個人と個人の戦いを回避したいから集団を作らせようとしている印象だが
214デフォルトの名無しさん
2022/08/10(水) 21:56:02.90ID:y2CjdAWq >>203
お前の言う設計は範囲が狭いな。逆に俺の言う設計は広くておおざっぱ過ぎるか？
お前の言う設計は範囲が狭いな。逆に俺の言う設計は広くておおざっぱ過ぎるか？
215デフォルトの名無しさん
2022/08/10(水) 23:16:30.22ID:OAjuzVE6 >>212
なんで安全のために全部Rsutに置き換えないの？
なんで安全のために全部Rsutに置き換えないの？
216デフォルトの名無しさん
2022/08/10(水) 23:36:42.52ID:sNqQ8ycT217デフォルトの名無しさん
2022/08/11(木) 00:11:49.77ID:ZCQSRwpp Rustで書くと危険な部分もあるんですねえ。
218デフォルトの名無しさん
2022/08/11(木) 00:25:31.63ID:8gPi/LG+219デフォルトの名無しさん
2022/08/11(木) 00:37:42.94ID:5NB7ephI 目的を固定すると危険しかない
220デフォルトの名無しさん
2022/08/11(木) 00:55:10.26ID:ScqLZwtD >>215
100と0しかない世界線の住人か？
100と0しかない世界線の住人か？
221デフォルトの名無しさん
2022/08/11(木) 02:27:09.28ID:THycMkTK Cloudflare WorkersがC, C++, Rustに加えて
Python, Scala, Kotlin, Reason, Dartに対応したけど
Reasonなんて使ってる奴おるんか？
https://blog.cloudflare.com/cloudflare-workers-announces-broad-language-support/
Python, Scala, Kotlin, Reason, Dartに対応したけど
Reasonなんて使ってる奴おるんか？
https://blog.cloudflare.com/cloudflare-workers-announces-broad-language-support/
222デフォルトの名無しさん
2022/08/11(木) 02:53:54.65ID:ZCQSRwpp223デフォルトの名無しさん
2022/08/11(木) 03:13:46.61ID:Sybzs6gH >>222
プログラミング言語によってHTMLを扱えたり扱えなかったりすることはありません
プログラミング言語によってHTMLを扱えたり扱えなかったりすることはありません
224デフォルトの名無しさん
2022/08/11(木) 03:33:33.51ID:ZCQSRwpp >>223
仕様書を読めばわかるんですけど、HTMLは相互参照の山なんですよ。
ですからRustには荷が重いというか、HTMLはRust殺しなんですよね。
これ、Rustが悪いのかHTMLが悪いのかというと、自分はHTMLの設計が古臭いと思いますね。
理論的にはRustの方が正しいと思います。
仕様書を読めばわかるんですけど、HTMLは相互参照の山なんですよ。
ですからRustには荷が重いというか、HTMLはRust殺しなんですよね。
これ、Rustが悪いのかHTMLが悪いのかというと、自分はHTMLの設計が古臭いと思いますね。
理論的にはRustの方が正しいと思います。
225デフォルトの名無しさん
2022/08/11(木) 03:40:04.40ID:ZCQSRwpp そもそも現在のHTML仕様はJSとC++を前提に書かれていて、その他の言語で取り扱うには、特有の事情を考慮しないといけないんですよね。
C#で取り扱おうとか、Javaで取り扱おうとか、そういうのはあまり問題ないんですよ。
C++同様、フルコースの言語なんで。
ところが、Cで取り扱おうとか、Rustで取り扱おうということになると、いろいろ考える必要がある。
これはいずれHTML仕様のほうを修正していくべきなんでしょうね。
C#で取り扱おうとか、Javaで取り扱おうとか、そういうのはあまり問題ないんですよ。
C++同様、フルコースの言語なんで。
ところが、Cで取り扱おうとか、Rustで取り扱おうということになると、いろいろ考える必要がある。
これはいずれHTML仕様のほうを修正していくべきなんでしょうね。
226デフォルトの名無しさん
2022/08/11(木) 03:48:44.40ID:D5CYg6Pn それはHTMLというかDOMでは？
227デフォルトの名無しさん
2022/08/11(木) 06:57:33.65ID:/IbLiGYi228デフォルトの名無しさん
2022/08/11(木) 07:15:59.88ID:CtVRnCBa Rustでちょっと複雑なことさせると
すぐスパゲティになっちゃうんだろうな
すぐスパゲティになっちゃうんだろうな
229デフォルトの名無しさん
2022/08/11(木) 07:24:38.68ID:pHX8OKOv230デフォルトの名無しさん
2022/08/11(木) 08:05:18.95ID:4s9DVfCr231デフォルトの名無しさん
2022/08/11(木) 08:23:24.72ID:BGDDy7T+ こんな感じだと、Rust好き的には、まず現実世界をRustで扱いやすいように修正するところからだね～
232デフォルトの名無しさん
2022/08/11(木) 08:34:02.44ID:7v/bWlgJ233デフォルトの名無しさん
2022/08/11(木) 08:52:59.49ID:swhQx1y1234デフォルトの名無しさん
2022/08/11(木) 11:12:00.07ID:AMWlPSdy >HTMLは相互参照の山なんですよ。
複オジなみのアホ迷言だなww
複オジなみのアホ迷言だなww
235デフォルトの名無しさん
2022/08/11(木) 11:23:16.28ID:9TqIqLGI C/C++のプログラム用のライブラリをRsutで書こうとするとグルーコードまみれになって危険と言いたいのか？
236デフォルトの名無しさん
2022/08/11(木) 11:28:04.54ID:vbpLy+Rh このスレに場違いなC++君がいつも頓珍漢なことを言ってるのは
叩き道具としてC++を持ち出しているだけであってC++でプログラミングしているわけではなく無知なため
叩き道具としてC++を持ち出しているだけであってC++でプログラミングしているわけではなく無知なため
237デフォルトの名無しさん
2022/08/11(木) 11:29:28.19ID:ScqLZwtD238デフォルトの名無しさん
2022/08/11(木) 11:34:46.22ID:5NB7ephI 効率的市場ってやつ？
0秒で100年先を織り込むという
0秒で100年先を織り込むという
239デフォルトの名無しさん
2022/08/11(木) 11:35:01.03ID:CYbTzNpy240デフォルトの名無しさん
2022/08/11(木) 12:06:59.79ID:iYrezZwU C++で枯れてるモジュールをRustなどで書き直す必要はないわな
241デフォルトの名無しさん
2022/08/11(木) 12:16:07.83ID:CYbTzNpy そういうこと
Rustに全て書き換えることは可能だけど
既にそういう状況にあるものを書き換える労力に意味はない
だからどこの企業やプロジェクトでも同じで新たなシステム改変部分からRust使用となっている
Rustに全て書き換えることは可能だけど
既にそういう状況にあるものを書き換える労力に意味はない
だからどこの企業やプロジェクトでも同じで新たなシステム改変部分からRust使用となっている
242デフォルトの名無しさん
2022/08/11(木) 12:16:35.32ID:7cUH/Z7I >>234
まあ、<a href="...">...</a> のことを言ってるならあながち間違いじゃないけど、プログラムから扱う話しとはあまり関係ないよね
まあ、<a href="...">...</a> のことを言ってるならあながち間違いじゃないけど、プログラムから扱う話しとはあまり関係ないよね
243デフォルトの名無しさん
2022/08/11(木) 12:31:23.76ID:dNzT5Twj244デフォルトの名無しさん
2022/08/11(木) 13:03:40.31ID:q4niyik3 HTMLってw
またおじさんが知ったかで暴れてるのか
何回論破されて負けてもこの調子だし話にならんな
本物はさっさと消えてくれ
またおじさんが知ったかで暴れてるのか
何回論破されて負けてもこの調子だし話にならんな
本物はさっさと消えてくれ
245デフォルトの名無しさん
2022/08/11(木) 13:11:32.71ID: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などをはじめとする
複数の言語のエネルギー効率を相対的に示した研究結果を紹介している。
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などをはじめとする
複数の言語のエネルギー効率を相対的に示した研究結果を紹介している。
246デフォルトの名無しさん
2022/08/11(木) 13:57:53.80ID:5NB7ephI 弱参照の目的が「強参照のバグを回避するため」と誤解されてるんだな
生ポインタを安全にすることが目的だと思った方が現実に近い
unsafe生ポインタでできることは安全な弱参照でもできる
生ポインタを安全にすることが目的だと思った方が現実に近い
unsafe生ポインタでできることは安全な弱参照でもできる
247デフォルトの名無しさん
2022/08/11(木) 14:40:08.04ID:9t95Zhl+ >>194
ここで言うエンタープライズは、月数十万のバカにいつまでも確定しない要件を曖昧に実装させるような泥団子システムを作る業界のことだと思う。
Rustだとコンパイルが通らないからゴミを検収に出して時間稼ぐみたいなテクニックが使えない。
ここで言うエンタープライズは、月数十万のバカにいつまでも確定しない要件を曖昧に実装させるような泥団子システムを作る業界のことだと思う。
Rustだとコンパイルが通らないからゴミを検収に出して時間稼ぐみたいなテクニックが使えない。
248デフォルトの名無しさん
2022/08/11(木) 15:07:05.88ID:6Sj50xSo >>245
そうか？いうほどFirefoxはエネルギー効率良くないです。なんやかんやいうても一番はOS標準搭載のブラウザーでmacOSならSafariでWindowsならEdgeです
いうほどFirefox常用してるけど早くもないし、終了時が重いのはやめてほしい
そうか？いうほどFirefoxはエネルギー効率良くないです。なんやかんやいうても一番はOS標準搭載のブラウザーでmacOSならSafariでWindowsならEdgeです
いうほどFirefox常用してるけど早くもないし、終了時が重いのはやめてほしい
249デフォルトの名無しさん
2022/08/11(木) 15:15:41.02ID:1vyjl3kW Web開発でのデバッグ用途ならFirefoxの方が使い勝手がいい
250デフォルトの名無しさん
2022/08/11(木) 15:18:20.72ID:ZCQSRwpp251デフォルトの名無しさん
2022/08/11(木) 15:19:27.76ID:ZCQSRwpp ちなみに相互参照が多用されているので、参照カウントでは解決できないですよ。
そこがHTML仕様の厄介なところです。
そこがHTML仕様の厄介なところです。
252デフォルトの名無しさん
2022/08/11(木) 15:30:14.14ID:8SRrL23l >仕様がC++向けに書かれているので
この妄想の元ネタってなんなんだろうか。ちょっと気になる。
この妄想の元ネタってなんなんだろうか。ちょっと気になる。
253デフォルトの名無しさん
2022/08/11(木) 15:41:42.85ID:7cUH/Z7I 俺はちっとも気にならないのでよそでやって欲しい
254デフォルトの名無しさん
2022/08/11(木) 15:56:07.13ID:5NB7ephI 任意の妄想を書き込み可能な脆弱性
に反応して脆弱性を突くだけの機械的なムーブなのでは
に反応して脆弱性を突くだけの機械的なムーブなのでは
255デフォルトの名無しさん
2022/08/11(木) 17:05:52.29ID:Kd3rFp17256デフォルトの名無しさん
2022/08/11(木) 17:25:03.43ID:NtDJBq0Q GAFAMの中だとAmazonが一番Rust推しだと思う
MozillaのリストラのときもRust開発者大量に採用してたし
MozillaのリストラのときもRust開発者大量に採用してたし
257デフォルトの名無しさん
2022/08/11(木) 19:00:28.74ID:X+IfO94A おちめのあまぞん
258デフォルトの名無しさん
2022/08/11(木) 19:06:10.54ID:cYo9lEj1259デフォルトの名無しさん
2022/08/11(木) 19:29:30.88ID:ZCQSRwpp Rust草創期、財団設立に関わったことで、引くに引けなくなってるのでは？
損切りできない体質は悲劇を招きますよ。
もっとも、一部門の話に過ぎないとは思いますが。
損切りできない体質は悲劇を招きますよ。
もっとも、一部門の話に過ぎないとは思いますが。
260デフォルトの名無しさん
2022/08/11(木) 19:30:12.29ID:K1VoPj4Z261デフォルトの名無しさん
2022/08/11(木) 19:33:35.06ID:ZCQSRwpp >>258
アマゾンは一人一人に対して個別のHTMLを返すんですよ。
もちろん、JSで読み込むような部分もあるんですが、そういうのは広告のようなもので、価格の提示など本質的な部分はサーバ側でHTMLに組み込みます。
したがって電気代が大変でしょうね。
従来の産業では、製鉄所が自前あるいは共同の発電所を持つことが当たり前ですが、アマゾンも発電所をお持ちかもしれませんね。
アマゾンは一人一人に対して個別のHTMLを返すんですよ。
もちろん、JSで読み込むような部分もあるんですが、そういうのは広告のようなもので、価格の提示など本質的な部分はサーバ側でHTMLに組み込みます。
したがって電気代が大変でしょうね。
従来の産業では、製鉄所が自前あるいは共同の発電所を持つことが当たり前ですが、アマゾンも発電所をお持ちかもしれませんね。
262デフォルトの名無しさん
2022/08/11(木) 19:36:26.39ID:ZCQSRwpp >>260
Rustで実用的なソフトウェアを書くことは難しく、Rustの開発主体であるMozillaでさえ自身のブラウザの二割しかRustを適用できていません。
いまとなっては、失敗だったと認めざるを得ないでしょう。
Rustで実用的なソフトウェアを書くことは難しく、Rustの開発主体であるMozillaでさえ自身のブラウザの二割しかRustを適用できていません。
いまとなっては、失敗だったと認めざるを得ないでしょう。
263デフォルトの名無しさん
2022/08/11(木) 19:40:30.56ID:9TqIqLGI 久しぶりにこのスレでNG使ったわ
264デフォルトの名無しさん
2022/08/11(木) 19:41:50.30ID:ZCQSRwpp https://trends.google.co.jp/trends/explore?q=%2Fm%2F0dsbpg6,%2Fm%2F05z1_,%2Fm%2F07sbkfb
世界でRustはすでにオワコン言語の地位を獲得しています。
オワコンの地位を獲得したころ、なぜか日本で書籍やセミナーが増えました。
世界でRustはすでにオワコン言語の地位を獲得しています。
オワコンの地位を獲得したころ、なぜか日本で書籍やセミナーが増えました。
265デフォルトの名無しさん
2022/08/11(木) 19:43:48.57ID:CtVRnCBa >>262
みんなそこまで言わないように気を使ってるのに…
みんなそこまで言わないように気を使ってるのに…
266デフォルトの名無しさん
2022/08/11(木) 19:45:33.11ID:ZCQSRwpp はっきり言わないと、統一教会みたいに詐欺師がのさばりますよ。
267デフォルトの名無しさん
2022/08/11(木) 19:47:57.82ID:ZjpQa1eK >>259
Rust FoundationをGoogle・Microsoft・Amazonなどが共同で設立したのは昨年2021年2月ですが
あなたの言うRust草創期にAmazonがRustの財団の設立に関わったとはこのことを意味していますか？
Rust FoundationをGoogle・Microsoft・Amazonなどが共同で設立したのは昨年2021年2月ですが
あなたの言うRust草創期にAmazonがRustの財団の設立に関わったとはこのことを意味していますか？
268デフォルトの名無しさん
2022/08/11(木) 19:50:22.88ID:ZCQSRwpp >>267
ドッグイヤーと言われるIT業界ですからね。
ドッグイヤーと言われるIT業界ですからね。
269デフォルトの名無しさん
2022/08/11(木) 19:53:31.47ID:xU6QWn2b270デフォルトの名無しさん
2022/08/11(木) 20:01:54.70ID:7cUH/Z7I >>258
まあざっくりその認識でいいと思う
まあざっくりその認識でいいと思う
271デフォルトの名無しさん
2022/08/11(木) 20:15:26.31ID:WVfR2Wgm まぁ日本ではPHPばかり使われるのがこのスレの流れでもわかるわ。
次のスレタイからは 次世代 の冠は外せよ。
次のスレタイからは 次世代 の冠は外せよ。
272デフォルトの名無しさん
2022/08/11(木) 20:24:34.40ID:TxCQzsqx Rust叩きしてる人がいつもおかしなことばかり書き込むので素性を怪しんでいたけど、
クラウドのトップシェアのAWSを知らないとは驚いた。
そういう常識のない人がRust叩きしていたと分かり納得できた。
クラウドのトップシェアのAWSを知らないとは驚いた。
そういう常識のない人がRust叩きしていたと分かり納得できた。
273デフォルトの名無しさん
2022/08/11(木) 21:02:00.22ID:PxUPmcND Rustは一部の天才向けの言語
AWSの開発者なんて一部の天才しかいない
大半の開発者はAWSを開発する側ではなく利用して問題解決をする側
後者の人間がRustを使いこなしてサービスを作れるわけがない
AWSの開発者なんて一部の天才しかいない
大半の開発者はAWSを開発する側ではなく利用して問題解決をする側
後者の人間がRustを使いこなしてサービスを作れるわけがない
274デフォルトの名無しさん
2022/08/11(木) 21:21:47.16ID:5NB7ephI Webサービス音痴になっても言語まで音痴になるな！
275デフォルトの名無しさん
2022/08/11(木) 21:58:11.55ID: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とメモリの使用率を削減する。
次世代言語の本命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とメモリの使用率を削減する。
276デフォルトの名無しさん
2022/08/11(木) 22:20:00.16ID:C2sFOKfB Rust叩きの人はRustは知らないを通り越して
なんにも知らない人が多いな
なんにも知らない人が多いな
277デフォルトの名無しさん
2022/08/11(木) 22:48:43.13ID:ZCQSRwpp Haskellと同じ道を歩いてる。
278デフォルトの名無しさん
2022/08/11(木) 22:57:05.95ID: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週間掛かる
バグが多い・長時間掛かるなど、効率が悪いと年収が下がる
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週間掛かる
バグが多い・長時間掛かるなど、効率が悪いと年収が下がる
279デフォルトの名無しさん
2022/08/11(木) 23:09:50.33ID:ScqLZwtD >>277
AWSでHaskellサポートされたことあったっけ？
AWSでHaskellサポートされたことあったっけ？
280デフォルトの名無しさん
2022/08/11(木) 23:34:23.21ID:5NB7ephI AIが過去に何度か失敗していて今回も失敗するという主張と同じ道
281デフォルトの名無しさん
2022/08/11(木) 23:37:34.61ID:ZCQSRwpp アメリカでオワコンになると日本でごり押しが始まるけど、どういう仕組みなんだ？
282デフォルトの名無しさん
2022/08/11(木) 23:55:00.67ID: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
それらの支援が必要な言語と異なり
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
283デフォルトの名無しさん
2022/08/12(金) 00:31:07.27ID:KPbB5azj284デフォルトの名無しさん
2022/08/12(金) 01:02:30.18ID:J29cS/Aj ウェブサービスを作るのに、
C++ みたいなポインターとか、デバイスは関係ない
AWS とかウェブサービスなどは、
デバイスを抽象化して貸し出している層の話
C++ みたいなポインターとか、デバイスは関係ない
AWS とかウェブサービスなどは、
デバイスを抽象化して貸し出している層の話
285デフォルトの名無しさん
2022/08/12(金) 01:12:39.99ID:ijOecH2p アプリで通用しないからウェブへ逃げた言語のひとつでは？
286デフォルトの名無しさん
2022/08/12(金) 02:03:25.74ID:Pwp1hh6y287デフォルトの名無しさん
2022/08/12(金) 02:15:46.05ID:NovzwVFL こんなことずっと言ってるのにまだコンテナエンジンさえまともに作れてないっていうね。。
288デフォルトの名無しさん
2022/08/12(金) 02:33:18.95ID:bDQmrk+5 少なくとも次世代言語は動的型付言語じゃなく型推論のある静的型付言語だろうな。
289デフォルトの名無しさん
2022/08/12(金) 02:49:37.47ID:ijOecH2p Rustで出来てる有名なソフトって何？
290デフォルトの名無しさん
2022/08/12(金) 03:29:00.86ID:ES0c90Y+ Node.jsより速くて色々と便利なDenoとか
Electronより速くてバイナリ生成も小さいTauriとか
Electronより速くてバイナリ生成も小さいTauriとか
291デフォルトの名無しさん
2022/08/12(金) 03:34:06.83ID:ijOecH2p Tauriって本体はWebkitかChromiumだろ。
Firefoxならまだしも。
Firefoxならまだしも。
292デフォルトの名無しさん
2022/08/12(金) 05:24:48.42ID:ijOecH2p 人造人間11号用のアプリ作れる？
293デフォルトの名無しさん
2022/08/12(金) 06:16:48.79ID:KPbB5azj 別に新興宗教を作らなくても伝統的なやつをコピーするだけでいいんだよ
294デフォルトの名無しさん
2022/08/12(金) 07:17:38.32ID:8aFEsxK9 >>289
Unixコマンド
Unixコマンド
295デフォルトの名無しさん
2022/08/12(金) 09:56:58.91ID:XPcdhorI >>289
Linux
Linux
296デフォルトの名無しさん
2022/08/12(金) 10:02:43.86ID:4Mgm88NN LinuxのカーネルはCでしょｗ
肝心なところにRustなんて使われない
肝心なところにRustなんて使われない
297デフォルトの名無しさん
2022/08/12(金) 10:08:16.88ID:25v3e0MP Rustは所有権システムのせいで他システムから移行するのがなかなか難しい
新規に作るならいいが既存システムをそのまま変えるのは厳しく構造を変えていかないといけない
新規に作るならいいが既存システムをそのまま変えるのは厳しく構造を変えていかないといけない
298デフォルトの名無しさん
2022/08/12(金) 11:32:56.40ID:KPbB5azj 人間同士の会話で詭弁と嘘をじゃんじゃん使う汚い手口を知ってるなら
Rustでもルールの抜け道を使って
PHP並みに汚い今まで通りの書き方ができるんだよ
Rustでもルールの抜け道を使って
PHP並みに汚い今まで通りの書き方ができるんだよ
299デフォルトの名無しさん
2022/08/12(金) 12:29:18.76ID:Oy5swSwT300デフォルトの名無しさん
2022/08/12(金) 12:48:08.34ID:c/mjoCjH >>299
おまえその手の仕事したことないだろw
おまえその手の仕事したことないだろw
301デフォルトの名無しさん
2022/08/12(金) 12:58:53.09ID:eVusMPKY >>247
検収する側としては、ソースにunsafeが入っていないかgrepして入ってたら検収しないとか、アホな事言うのも出てくるかもね。
最近も暴れてた人はRust擁護しているのかと思ったら、叩いてる方だったのか…
検収する側としては、ソースにunsafeが入っていないかgrepして入ってたら検収しないとか、アホな事言うのも出てくるかもね。
最近も暴れてた人はRust擁護しているのかと思ったら、叩いてる方だったのか…
302デフォルトの名無しさん
2022/08/12(金) 13:04:31.64ID:/hoT7fNk 既に動いてる一体的システムを改変なしに他の言語へ移すのは移行用の後継言語へ移す以外だとコスパ悪いからあまり行われないね
もちろんAPIで分離されている別システムなら話は別で高速化のためにC++やRustなど含めて自由に他の言語へ可能
もちろんAPIで分離されている別システムなら話は別で高速化のためにC++やRustなど含めて自由に他の言語へ可能
303デフォルトの名無しさん
2022/08/12(金) 13:13:52.69ID:KPbB5azj 参照カウントしないポインタが欲しいだけならunsafeではなくWeakを使う
304デフォルトの名無しさん
2022/08/12(金) 13:19:20.77ID:0xlDyyuc305デフォルトの名無しさん
2022/08/12(金) 13:37:01.57ID:KPbB5azj 自分が使いたい時に使うでしょ
自分が何をやりたいのかを他人に判断させるな
自分が何をやりたいのかを他人に判断させるな
306デフォルトの名無しさん
2022/08/12(金) 13:53:28.10ID:0xlDyyuc307デフォルトの名無しさん
2022/08/12(金) 14:04:45.01ID:s5ItonLD 何の話かよくわからないけど
不便な旧言語のままでいい人はそれで構わないんじゃないの？
もちろんC++は不便だからCarbonなどが出てきている
そしてCarbonの公式FAQにもあるようにあくまでも既存C++コードのためのものであってRustが使えるならRustの方が好ましいと明記されている
不便な旧言語のままでいい人はそれで構わないんじゃないの？
もちろんC++は不便だからCarbonなどが出てきている
そしてCarbonの公式FAQにもあるようにあくまでも既存C++コードのためのものであってRustが使えるならRustの方が好ましいと明記されている
308デフォルトの名無しさん
2022/08/12(金) 14:41:41.60ID:KPbB5azj Javaの文化が歪んでいるのをRustに投影しているように見える
static変数が利用可能なのはstatic変数を使わせないためである
JNIが利用可能なのはJNIを使わせないためである
static変数が利用可能なのはstatic変数を使わせないためである
JNIが利用可能なのはJNIを使わせないためである
309デフォルトの名無しさん
2022/08/12(金) 15:19:13.21ID:UMYGy7UQ いい感じに隔離スレとして機能してるねココ
310デフォルトの名無しさん
2022/08/12(金) 17:33:04.35ID:ijOecH2p unsafeが利用可能なのはunsafeを使わせないためである
311デフォルトの名無しさん
2022/08/12(金) 17:39:56.81ID:KPbB5azj 目的は何々であるという説には陰謀論レベルの信憑性しかない
312デフォルトの名無しさん
2022/08/12(金) 17:58:30.16ID:B8WuAqqn ScalaとかHaskell好きだけどねえ
初心者が使いこなすのは大変だから流行らないよね
初心者が使いこなすのは大変だから流行らないよね
313デフォルトの名無しさん
2022/08/12(金) 18:40:09.03ID:pHCKIPO9 一定数に名前が知られている時点で流行ってると言って良いと思うよ
314デフォルトの名無しさん
2022/08/12(金) 19:35:03.04ID:8aFEsxK9 Scala vs Haske vs Rustみたいなスレを作った方がいいかもね
315デフォルトの名無しさん
2022/08/12(金) 19:41:01.12ID:mai+3JG0 C vs C++ vs Rust だけでいいだろ
大方の興味はこの１点につきる
大方の興味はこの１点につきる
316デフォルトの名無しさん
2022/08/12(金) 19:43:26.46ID:ijOecH2p >>315
RustはC++のサブセットだから意味ないと思う。
RustはC++のサブセットだから意味ないと思う。
317デフォルトの名無しさん
2022/08/12(金) 19:50:24.38ID:ijOecH2p >>312
初心者が何言っとる。
初心者が何言っとる。
318デフォルトの名無しさん
2022/08/12(金) 23:23:35.24ID:3qV0/cHh Zig が存在するのに、なぜ他の言語でプロジェクトを開始するのでしょうか?
319デフォルトの名無しさん
2022/08/12(金) 23:58:58.03ID:P0zPe4di320デフォルトの名無しさん
2022/08/13(土) 00:30:17.86ID:xQE0tEua そのとおりです。 Rust では、プログラムは常に malloc と free を呼び出します。 Zig では、メモリを最初に 1 回割り当てることができます。
321デフォルトの名無しさん
2022/08/13(土) 00:46:50.18ID:9pjJ9/xa Rust叩きしてる人はなぜいつも無知なのだろうか
322デフォルトの名無しさん
2022/08/13(土) 01:03:17.60ID:xQE0tEua Rust ユーザーが jemalloc を使用する必要があるのはなぜですか
323デフォルトの名無しさん
2022/08/13(土) 01:57:28.21ID:N+gF026L324デフォルトの名無しさん
2022/08/13(土) 02:07:32.42ID:yjuU6Mz4 アホジャップが生産性低いのは
メタプログラミングできないとの
JIS配列でアホみたいな足枷はめられてるから
USキーボードでDvorak配列は当たり前
俺たちタイプライターの時代じゃなくて
コンピューターの時代に生きてるんだよな
アップデートして時代に追いつこう
メタプログラミングできないとの
JIS配列でアホみたいな足枷はめられてるから
USキーボードでDvorak配列は当たり前
俺たちタイプライターの時代じゃなくて
コンピューターの時代に生きてるんだよな
アップデートして時代に追いつこう
325デフォルトの名無しさん
2022/08/13(土) 02:34:08.59ID:xrD8032t >>322
一般論として全ての用途に有利なメモリアロケータはもちろん存在しない
またアプリケーションプログラムの方もその用途によっては標準とは別のメモリアロケータ利用が最適化に効くものも当然ある
したがってもし必要と判断した時に利用するメモリアロケータを変えられることが好ましい
調べてみると
Rustもそのようなメモリアロケータを変更可能な言語
jemallocはある種の用途で有利になりうるメモリアロケータ
そして両者を組み合わせて用いることに支障はないようだが何を問題にしているのか？
一般論として全ての用途に有利なメモリアロケータはもちろん存在しない
またアプリケーションプログラムの方もその用途によっては標準とは別のメモリアロケータ利用が最適化に効くものも当然ある
したがってもし必要と判断した時に利用するメモリアロケータを変えられることが好ましい
調べてみると
Rustもそのようなメモリアロケータを変更可能な言語
jemallocはある種の用途で有利になりうるメモリアロケータ
そして両者を組み合わせて用いることに支障はないようだが何を問題にしているのか？
326デフォルトの名無しさん
2022/08/13(土) 03:03:54.43ID:9Y2sM84k Haskellのときも、世界が見限ったころに5chで流行り始めた。
327デフォルトの名無しさん
2022/08/13(土) 03:04:25.86ID:9Y2sM84k 実用性のない言語は使われない。
328デフォルトの名無しさん
2022/08/13(土) 03:41:52.55ID:fGEsvyaQ Haskellは大量のgarbageを撒き散らすうえにGCが遅いため実行時間が遅いのが致命的な古い言語
しかし代数的データ型やパターンマッチに型クラスなど有用なものが多く後の言語に影響を与えた
30年前の言語をわざわざ次世代言語スレに持ち出してきて叩く人はおかしい
しかし代数的データ型やパターンマッチに型クラスなど有用なものが多く後の言語に影響を与えた
30年前の言語をわざわざ次世代言語スレに持ち出してきて叩く人はおかしい
329デフォルトの名無しさん
2022/08/13(土) 03:47:09.96ID:9Y2sM84k Rustも世界が見限ったので5chで流行り始めてる。
330デフォルトの名無しさん
2022/08/13(土) 03:59:57.56ID:9Y2sM84k331デフォルトの名無しさん
2022/08/13(土) 04:10:31.61ID:xQE0tEua332デフォルトの名無しさん
2022/08/13(土) 04:21:51.20ID:6QfP9d8W333デフォルトの名無しさん
2022/08/13(土) 04:22:46.97ID:3CEN1DwX334デフォルトの名無しさん
2022/08/13(土) 04:49:06.79ID:9Y2sM84k FacebookがRustを採用。
↓
Facebookの失墜。
↓
世界がRustを見限る。
Facebookが戦犯。
↓
Facebookの失墜。
↓
世界がRustを見限る。
Facebookが戦犯。
335デフォルトの名無しさん
2022/08/13(土) 05:17:02.03ID:qcqt1f6R >>245の記事によると
世界でトップシェアのクラウドAWSがその提供サービス実装にRustを使っているようだぜ
世界でトップシェアのクラウドAWSがその提供サービス実装にRustを使っているようだぜ
336デフォルトの名無しさん
2022/08/13(土) 05:34:22.29ID:9Y2sM84k >>335
終わりの始まり。
終わりの始まり。
337デフォルトの名無しさん
2022/08/13(土) 06:07:19.25ID:9Y2sM84k Rustで出来てる有名なソフトって何かあるの？
338デフォルトの名無しさん
2022/08/13(土) 06:28:22.11ID:lzc5RUpA AWSだけでなくLinux OSもAndroid OSもRustを採用したから終わりの始まり
339デフォルトの名無しさん
2022/08/13(土) 07:38:54.55ID:njvmvUJk あくまでも適してるのは低レイヤー
340デフォルトの名無しさん
2022/08/13(土) 08:13:13.08ID:9Y2sM84k Linux OSもAndroid OSもCで書かれてる。
341デフォルトの名無しさん
2022/08/13(土) 08:17:14.35ID:9Y2sM84k Rustで書かれてるメジャーなOSって何かあるの？
342デフォルトの名無しさん
2022/08/13(土) 09:28:15.05ID:KZ/RfVV4 あったら何なの？無かったら何なの？
関係ないんだよお前には
関係ないんだよお前には
343デフォルトの名無しさん
2022/08/13(土) 09:42:57.35ID:2Qk1ejrP なんかGoもRustも違うんだよな～
求めてる言語じゃないっていうか
Cをベースにして欲しいんだよ俺は
C++は論外
求めてる言語じゃないっていうか
Cをベースにして欲しいんだよ俺は
C++は論外
344デフォルトの名無しさん
2022/08/13(土) 09:49:20.23ID:9Y2sM84k Rubyはどうだい？
345デフォルトの名無しさん
2022/08/13(土) 09:55:35.86ID:Dkd+eytH >>325
メモリ安全を売りにしているRustだから、メモリアロケータもRust製に拘った方が良いとかは無い？
メモリ安全を売りにしているRustだから、メモリアロケータもRust製に拘った方が良いとかは無い？
346デフォルトの名無しさん
2022/08/13(土) 09:58:00.87ID:JIF8rHbt >>343
C#をネイティブコンパイルで
C#をネイティブコンパイルで
347デフォルトの名無しさん
2022/08/13(土) 10:00:10.89ID:ogpUFXWj ■Rust使用実績
<OS>
- Linux
- Android
<基盤、ミドルウェア>
- AWS
<アプリケーション>
- Firefox
<Webアプリ>
- Cookpad
- Dwango
<OS>
- Linux
- Android
<基盤、ミドルウェア>
- AWS
<アプリケーション>
- Firefox
<Webアプリ>
- Cookpad
- Dwango
348デフォルトの名無しさん
2022/08/13(土) 10:16:01.13ID:UHqBjcNr WebアプリでRust使ってるやつはバカそのもの
349デフォルトの名無しさん
2022/08/13(土) 10:45:37.81ID:TjiWtf4M350デフォルトの名無しさん
2022/08/13(土) 11:10:16.71ID:N+gF026L GCがメモリ解放を「遅延」する特性を
プログラミング全般に応用した遅延評価は
GCの失墜を象徴する芸術作品なんだよ
プログラミング全般に応用した遅延評価は
GCの失墜を象徴する芸術作品なんだよ
351デフォルトの名無しさん
2022/08/13(土) 11:30:18.26ID:nBIkkk5z352デフォルトの名無しさん
2022/08/13(土) 11:41:11.76ID:njvmvUJk GCが適さない環境でメモリ管理するいいやり方が所有権システムってだけなのでは？
GCが特に問題ならない環境でその所有権システムをわざわざ利用するメリットは？
GCが特に問題ならない環境でその所有権システムをわざわざ利用するメリットは？
353デフォルトの名無しさん
2022/08/13(土) 11:45:26.29ID:N+gF026L Haskellの場合は構文木のグラフ簡約がなければGCのグラフ探索もほとんど不要だよね
354デフォルトの名無しさん
2022/08/13(土) 11:56:00.20ID:BhfPzEVU >>352
静的型付けとか所有権とかは
難しいものでもなく慣れだけで簡単で
実際に使っていると大した手間も無く
メリットばかりが得られるんだよ
コンパイル時点で静的に全て決まるから
実行時にその分の無駄なデバッグなども不要
どの分野とか全ての分野で同じ
更にオマケとして
高速と省メモリが付いてくる
もちろん安全性も付いてくる
静的型付けとか所有権とかは
難しいものでもなく慣れだけで簡単で
実際に使っていると大した手間も無く
メリットばかりが得られるんだよ
コンパイル時点で静的に全て決まるから
実行時にその分の無駄なデバッグなども不要
どの分野とか全ての分野で同じ
更にオマケとして
高速と省メモリが付いてくる
もちろん安全性も付いてくる
355デフォルトの名無しさん
2022/08/13(土) 12:17:05.15ID:if0JSPrf >>352
エコ
エコ
356デフォルトの名無しさん
2022/08/13(土) 12:27:39.76ID:njvmvUJk 信者曰くデメリットなくてコストもかからずメリットしかないらしいけど
競プロでもISUCONでも全然人気ないし、エンタープライズでもほとんど見ないね
競プロでもISUCONでも全然人気ないし、エンタープライズでもほとんど見ないね
357デフォルトの名無しさん
2022/08/13(土) 12:38:30.52ID:Dkd+eytH UnityがC#からRustに乗り換えでもしたら、
私でもRustを扱える難易度かもしれない。
私でもRustを扱える難易度かもしれない。
358デフォルトの名無しさん
2022/08/13(土) 12:44:13.20ID:7TnExSFS そもそもGCがボトルネックになるケースって相当なレアだと思うんだけど
GCをなくしたいモチベーションがよくわからない
GCをなくしたいモチベーションがよくわからない
359デフォルトの名無しさん
2022/08/13(土) 12:53:11.09ID:l2wlkFvH GCかどうかはどうでもいい話
高速＆省メモリ
だと
エコ＆利用者も快適＆リソース料金コストも安い
つまり良いこと尽くしなので高速＆省メモリを選ぶ
結果として非効率なGCは論外
高速＆省メモリ
だと
エコ＆利用者も快適＆リソース料金コストも安い
つまり良いこと尽くしなので高速＆省メモリを選ぶ
結果として非効率なGCは論外
360デフォルトの名無しさん
2022/08/13(土) 12:57:18.86ID:njvmvUJk エンタープライズでは開発コスト重視するからRustはコストの観点では論外だね
開発メンバが抜けた時に継続してメンテできるか？新たな人材の確保は容易化？を最優先に考えるから
コストで有利に働くのはあくまでも個人開発の場合だね
開発メンバが抜けた時に継続してメンテできるか？新たな人材の確保は容易化？を最優先に考えるから
コストで有利に働くのはあくまでも個人開発の場合だね
361デフォルトの名無しさん
2022/08/13(土) 12:58:30.25ID:njvmvUJk NoSQL最強でRDBは不要おじさんw
無知そのものw
無知そのものw
362デフォルトの名無しさん
2022/08/13(土) 13:02:33.78ID:cJQbCMHe なにがし言語が使える人材、なんて人材の探し方してるの？
それでエンタープライズは笑う
それでエンタープライズは笑う
363デフォルトの名無しさん
2022/08/13(土) 13:04:50.07ID:HNkVMULx >>352
メモリ以外のリソース、コネクションやファイルハンドラやらも所有権の枠組みで管理できるので並列処理でリソース管理周りのバグを出したくなければRustが理に適ってるシーンもある。
GC付きの言語でメモリ以外のリソースをGC的に管理しようとする取り組みとか無いのかね。
tryで囲んだりdefer書くとかで責務をいつまでも書き手に委ね続けるのは言語設計者の怠慢だわ。
メモリ以外のリソース、コネクションやファイルハンドラやらも所有権の枠組みで管理できるので並列処理でリソース管理周りのバグを出したくなければRustが理に適ってるシーンもある。
GC付きの言語でメモリ以外のリソースをGC的に管理しようとする取り組みとか無いのかね。
tryで囲んだりdefer書くとかで責務をいつまでも書き手に委ね続けるのは言語設計者の怠慢だわ。
364デフォルトの名無しさん
2022/08/13(土) 13:07:30.57ID:njvmvUJk イキってRustなんて使ったところで技術的負債になるだけ
あくまでもC++を置き換えるだけだからイキって採用しないようにしろよ
あくまでもC++を置き換えるだけだからイキって採用しないようにしろよ
365デフォルトの名無しさん
2022/08/13(土) 13:07:51.86ID:ppHUbuJC エスケープ解析に触れないでGCと所有権を比較するのはさすがに無能すぎる。
あと、所有権に言及して設計の制約を無視する奴は詐欺師。
Rustはまず効率化のために制約の下でできる範囲で設計して、無理なら設計を破棄してやり直す(か、そもそもコーダーにやらせない)思想だろ。
あと、所有権に言及して設計の制約を無視する奴は詐欺師。
Rustはまず効率化のために制約の下でできる範囲で設計して、無理なら設計を破棄してやり直す(か、そもそもコーダーにやらせない)思想だろ。
366デフォルトの名無しさん
2022/08/13(土) 13:19:05.90ID:uzvb9KsU >>360
現実世界だと大手IT各社がRustを採用しているのはどうしてなの？
現実世界だと大手IT各社がRustを採用しているのはどうしてなの？
367デフォルトの名無しさん
2022/08/13(土) 13:23:30.97ID:N+gF026L >>363
デストラクタ内でポインタをいじる処理を許せばGCの性能が死ぬ
デストラクタ内でポインタをいじる処理を許せばGCの性能が死ぬ
368デフォルトの名無しさん
2022/08/13(土) 13:35:35.80ID:6QfP9d8W >>363
C#のusingじゃだめですか
C#のusingじゃだめですか
369デフォルトの名無しさん
2022/08/13(土) 13:36:08.73ID:HNkVMULx370デフォルトの名無しさん
2022/08/13(土) 13:40:47.26ID:r/AYssCA371デフォルトの名無しさん
2022/08/13(土) 13:40:59.10ID:njvmvUJk >>366
ヒント 低レイヤー C++
ヒント 低レイヤー C++
372デフォルトの名無しさん
2022/08/13(土) 13:45:03.23ID:HNkVMULx >>368
C#のusingやkotlinのuseが正解っぽい感じはするんだけど、GCみたいにそもそも普段は意識しなくて済む感じになってほしい。
C#のusingやkotlinのuseが正解っぽい感じはするんだけど、GCみたいにそもそも普段は意識しなくて済む感じになってほしい。
373デフォルトの名無しさん
2022/08/13(土) 13:54:48.24ID:njvmvUJk >>370
向いていると専用の違いがわからない馬鹿
向いていると専用の違いがわからない馬鹿
374デフォルトの名無しさん
2022/08/13(土) 14:02:11.57ID:35Vbbs0e ここにあるファイルを末尾に日付を入れてネットワーク上のNASにコピーした後、削除し空ファイルを作ってください。
これをRustでやる奴はウンコ、普通にbashで書く
これをRustでやる奴はウンコ、普通にbashで書く
375デフォルトの名無しさん
2022/08/13(土) 14:06:21.25ID:N+gF026L Pythonの__del__の仕様を確認したらむちゃくちゃ大雑把だった
こんなのスクリプト以外で許されるわけねえだろ
こんなのスクリプト以外で許されるわけねえだろ
376デフォルトの名無しさん
2022/08/13(土) 14:10:23.92ID:6QfP9d8W >>374
エラー処理の要件次第ではbashだと辛くなりそうな予感がするんですが
エラー処理の要件次第ではbashだと辛くなりそうな予感がするんですが
377デフォルトの名無しさん
2022/08/13(土) 14:19:49.12ID:w1Rw8Hpr378デフォルトの名無しさん
2022/08/13(土) 14:49:04.30ID:98LBn3Jf >>326
日本が伊達にIT後進国じゃないってことだよな
日本が伊達にIT後進国じゃないってことだよな
379デフォルトの名無しさん
2022/08/13(土) 14:51:34.28ID:98LBn3Jf >>343
zig
zig
380デフォルトの名無しさん
2022/08/13(土) 15:27:52.15ID:1A00TS1y >>374
それだとファイルの末尾だと誤読しうる
おそらくファイル名の末尾の意味だろう
そういう処理は用途によってはbashスクリプトも当然使っている
ただし色んなエラー処理をしだすとシェルスクリプトでは面倒なこともある
そのためプログラミング言語を使う場合もある
Rustを使っているものもある
それだとファイルの末尾だと誤読しうる
おそらくファイル名の末尾の意味だろう
そういう処理は用途によってはbashスクリプトも当然使っている
ただし色んなエラー処理をしだすとシェルスクリプトでは面倒なこともある
そのためプログラミング言語を使う場合もある
Rustを使っているものもある
381デフォルトの名無しさん
2022/08/13(土) 15:36:28.85ID:1A00TS1y >>377
GCはいつ起こるかわからない
そしてその使い方ではGCが起きるまでクローズが遅延される
すると色んな問題が起こる
OSリソースがその間占有され続ける
占有オープンなら他者が利用できないなど
GC言語を使うなら面倒でもdeferやusingなどで明示的に後処理するしかないだろう
もちろんC++やRustならばRAIIにより即座に解放されクローズ処理もされるため面倒な記述は不要である
GCはいつ起こるかわからない
そしてその使い方ではGCが起きるまでクローズが遅延される
すると色んな問題が起こる
OSリソースがその間占有され続ける
占有オープンなら他者が利用できないなど
GC言語を使うなら面倒でもdeferやusingなどで明示的に後処理するしかないだろう
もちろんC++やRustならばRAIIにより即座に解放されクローズ処理もされるため面倒な記述は不要である
382デフォルトの名無しさん
2022/08/13(土) 15:40:18.08ID:w1Rw8Hpr383デフォルトの名無しさん
2022/08/13(土) 15:56:23.29ID:1A00TS1y >>382
RAII言語の方が優秀だと認識できているならばよろしい
RAII言語の方が優秀だと認識できているならばよろしい
384デフォルトの名無しさん
2022/08/13(土) 16:14:32.90ID:w1Rw8Hpr385デフォルトの名無しさん
2022/08/13(土) 17:08:08.82ID:1A00TS1y386デフォルトの名無しさん
2022/08/13(土) 17:28:21.83ID:njvmvUJk NoSQL最強おじさん笑
RAII最強おじさん笑
RAII最強おじさん笑
387デフォルトの名無しさん
2022/08/13(土) 17:30:58.15ID:w1Rw8Hpr388デフォルトの名無しさん
2022/08/13(土) 17:33:59.86ID:Dkd+eytH >>375
そんな雑なものがたくさんあるのに、Rustにすべきなんて言う人とはいつ迄も平行線な気がするよね。
そんな雑なものがたくさんあるのに、Rustにすべきなんて言う人とはいつ迄も平行線な気がするよね。
389デフォルトの名無しさん
2022/08/13(土) 17:41:30.08ID:WN46//k4 >>363
それが怠慢とかｗ
どこでメモリ（リソース）を確保してどこで解放するかをプログラマが選択出来なきゃ
それこそ自由度が無く使いにくい言語になる
GCがあるから解放しなくてもいつかやってくれるから明示的に書かないという思想が
正しいと思っているならおかしい
それが怠慢とかｗ
どこでメモリ（リソース）を確保してどこで解放するかをプログラマが選択出来なきゃ
それこそ自由度が無く使いにくい言語になる
GCがあるから解放しなくてもいつかやってくれるから明示的に書かないという思想が
正しいと思っているならおかしい
390デフォルトの名無しさん
2022/08/13(土) 17:50:27.94ID:N+gF026L391デフォルトの名無しさん
2022/08/13(土) 18:03:09.67ID:ctGwDZYY useとかusingとかdeferとか
書き忘れていたら実行前にエラーとなってくれればいいんだけどね
忘れずに書いていることに依存させる言語仕様はよくないね
書き忘れていたら実行前にエラーとなってくれればいいんだけどね
忘れずに書いていることに依存させる言語仕様はよくないね
392デフォルトの名無しさん
2022/08/13(土) 18:12:50.43ID:46rvE8i+ GCは結局メモリとGCの二つを管理しなきゃいけなくなって非効率なんじゃないか？
393デフォルトの名無しさん
2022/08/13(土) 18:14:07.67ID:9Y2sM84k 量子プロセッサ時代のプログラミング言語とか、意義のある会議は出来ないものか。
394デフォルトの名無しさん
2022/08/13(土) 18:42:16.49ID:MTqiLV7H ここ隔離スレなので特定のトピックに興味あるなら専用スレ立てた方が良いよ
395デフォルトの名無しさん
2022/08/13(土) 21:59:10.85ID:8G4SUPRt ファイルの自動クローズがRAIIで無条件かGCなので何らか明示指定かの話を見ていて思ったんだけど、
メモリの自動解放はこれまでGC言語だけの特権でGCにはデメリットもあれどメモリの自動解放という何もかもを上回るメリットが前面にあったのよね。
ところがGCがないのにメモリを自動解放するプログラミング言語が登場しちゃって危機感を覚える人も登場しちゃって、
メモリの自動解放はこれまでGC言語だけの特権でGCにはデメリットもあれどメモリの自動解放という何もかもを上回るメリットが前面にあったのよね。
ところがGCがないのにメモリを自動解放するプログラミング言語が登場しちゃって危機感を覚える人も登場しちゃって、
396デフォルトの名無しさん
2022/08/13(土) 22:51:24.09ID:6wAoLN5t GCがない(?)のにメモリを自動解放するプログラミング言語は昔からありますが……C++と言いましてね。
C++で（Rustみたいに）スタックフレームに何でも押し込むスタイルにするとどうなるのかねぇ。
C++で（Rustみたいに）スタックフレームに何でも押し込むスタイルにするとどうなるのかねぇ。
397デフォルトの名無しさん
2022/08/13(土) 23:40:22.03ID:9Y2sM84k 重要なものがキャッシュに乗りにくくなるのでは？
398デフォルトの名無しさん
2022/08/13(土) 23:54:24.87ID:601ao6Ev そもそもRustもC++も含め、RAIIは何でもスタックに積んでいるわけではない
スタック上の値のように振る舞うように作られているだけで、内部的にヒープにメモリを確保しポインタを保持しているケースが多い
スタック上の値のように振る舞うように作られているだけで、内部的にヒープにメモリを確保しポインタを保持しているケースが多い
399デフォルトの名無しさん
2022/08/14(日) 00:25:46.03ID:b9F5IowR Rustは自動メモリー管理が売りなんだから、C++のように自由に何でも出来たらダメでは？
400デフォルトの名無しさん
2022/08/14(日) 00:49:36.36ID:b9F5IowR JavaとHaskellの良いとこ取りのように宣伝されてたけど、悪いところを併せ持ってしまったのでは？
401デフォルトの名無しさん
2022/08/14(日) 07:17:26.98ID:tJlVM+m7 >>396
C++はメモリを自動解放しない。
unique_ptrやshared_ptrを忘れずに利用し間違えずに使用した場合のみ自動解放されるが、
それはその正しく作られたプログラムがメモリを自動解放しているのであり、
C++という言語自体がメモリを自動解放することはない。
一方でGC言語やRust言語などはプログラムの記述と関係なくメモリが自動解放される。
C++はメモリを自動解放しない。
unique_ptrやshared_ptrを忘れずに利用し間違えずに使用した場合のみ自動解放されるが、
それはその正しく作られたプログラムがメモリを自動解放しているのであり、
C++という言語自体がメモリを自動解放することはない。
一方でGC言語やRust言語などはプログラムの記述と関係なくメモリが自動解放される。
402デフォルトの名無しさん
2022/08/14(日) 07:54:47.25ID:osAuRY7C 事実上今時のプログラムで生ポインタなんて使わないしアスペの>>401は知らんけど普通のプログラマにとってメモリー解放はC++程度で充分
403デフォルトの名無しさん
2022/08/14(日) 08:05:26.58ID:tJlVM+m7404デフォルトの名無しさん
2022/08/14(日) 08:19:24.23ID:J5VfX3cG >>401
一般ユーザーがめったに使わないnewで言いがかりつけるなよ。Rustのunsafeみたいなものだろ。
一般ユーザーがめったに使わないnewで言いがかりつけるなよ。Rustのunsafeみたいなものだろ。
405デフォルトの名無しさん
2022/08/14(日) 08:30:27.75ID:osAuRY7C はいはい、アスペは何を指摘されているかも理解できないからどうでもいいわ
406デフォルトの名無しさん
2022/08/14(日) 08:44:12.34ID:FX5vs6id ムッシュムラムラ
407デフォルトの名無しさん
2022/08/14(日) 09:20:45.22ID:lDco67Nc RAIIみたいなありふれたものじゃなくてxor mutabilityをアピールした方が良いのでは
408デフォルトの名無しさん
2022/08/14(日) 09:37:16.54ID:TQqmfXCA >>407
これ
これ
409デフォルトの名無しさん
2022/08/14(日) 09:38:28.08ID:gLXUvNT9410デフォルトの名無しさん
2022/08/14(日) 10:03:55.97ID:TQqmfXCA411デフォルトの名無しさん
2022/08/14(日) 10:19:19.22ID:q44Oj4I2412デフォルトの名無しさん
2022/08/14(日) 10:29:55.69ID:oyMyAes/ あくまでもOS開発の用途で採用されてるだけ
413デフォルトの名無しさん
2022/08/14(日) 10:38:15.56ID:q44Oj4I2 >>412
Rustの世界的大規模な調査結果により
Rustの利用対象はサーバーサイド/バックエンドが最多で
以下クラウド、分散システム、WebAssembly/Webフロント、組み込みといった状況になっている
Rustの世界的大規模な調査結果により
Rustの利用対象はサーバーサイド/バックエンドが最多で
以下クラウド、分散システム、WebAssembly/Webフロント、組み込みといった状況になっている
414デフォルトの名無しさん
2022/08/14(日) 10:43:52.82ID:oyMyAes/415デフォルトの名無しさん
2022/08/14(日) 10:48:15.10ID:q44Oj4I2416デフォルトの名無しさん
2022/08/14(日) 10:58:46.14ID:J5MpSH/Q >>407
XORじゃないけどな
XORじゃないけどな
417デフォルトの名無しさん
2022/08/14(日) 11:16:29.29ID:UOAed9Kc before == afterのことをimmutableというなら
==の定義とかあるんですか？
まさか、大手企業を観測すれば==の定義が分かると思ってるマッドサイエンティストはいないよね
==の定義とかあるんですか？
まさか、大手企業を観測すれば==の定義が分かると思ってるマッドサイエンティストはいないよね
418デフォルトの名無しさん
2022/08/14(日) 11:19:12.35ID:q44Oj4I2419デフォルトの名無しさん
2022/08/14(日) 11:47:03.37ID:E6D9Byfe 現実には複数の状態のストアに跨がる論理的な競合の方がずっと問題で、単一データの読み書きの競合なんてアトミック変数くらいで十分
420デフォルトの名無しさん
2022/08/14(日) 11:59:58.73ID:N9EVRHSm 実行時に同時に読み書きしうるかどうかをコンパイラが厳密に検知することは不可能
Rustがやってるのは大幅に安全側に倒すアプローチで、それでいいんだったら関数型みたいにそもそもミュータブルなデータを共有しない、でも立派に対策になってるよね
実際それで十分なケースが殆どでしょ
Rustがやってるのは大幅に安全側に倒すアプローチで、それでいいんだったら関数型みたいにそもそもミュータブルなデータを共有しない、でも立派に対策になってるよね
実際それで十分なケースが殆どでしょ
421デフォルトの名無しさん
2022/08/14(日) 12:04:57.82ID:npbVW+VU Rustはdata raceはふせげてもrace conditionは防げない
銀の弾丸でも何でもない
銀の弾丸でも何でもない
422デフォルトの名無しさん
2022/08/14(日) 12:09:32.20ID:q44Oj4I2 >>419
アトミック変数を忘れたら競合する
さらにアトミック変数を使ってもそのコストがかかる
Rustでは静的にコンパイル時にデータ競合を必ず排除する
アトミック操作を必要とするならば指摘してくれる
multiple readers XOR single writerを守っていれば当然(コストの高い)アトミック操作を必要とせずにコンパイルが通る
したがってRustは他の言語よりもコストを低くデータ競合の安全性を常に満たせる
アトミック変数を忘れたら競合する
さらにアトミック変数を使ってもそのコストがかかる
Rustでは静的にコンパイル時にデータ競合を必ず排除する
アトミック操作を必要とするならば指摘してくれる
multiple readers XOR single writerを守っていれば当然(コストの高い)アトミック操作を必要とせずにコンパイルが通る
したがってRustは他の言語よりもコストを低くデータ競合の安全性を常に満たせる
423デフォルトの名無しさん
2022/08/14(日) 12:11:52.89ID:npbVW+VU 並行処理をしてないのにいちいちいらない制約かけられる方がコスト高いわ
424デフォルトの名無しさん
2022/08/14(日) 12:12:26.58ID:N9EVRHSm425デフォルトの名無しさん
2022/08/14(日) 12:17:06.31ID:qTNce3WZ 並行処理を安全に実装するのが難しいから、需要があってGoとかRustみたいな言語が登場してるのであって、直列なコードしか書かないなら昔の言語でもよくね
426デフォルトの名無しさん
2022/08/14(日) 12:18:16.18ID:N9EVRHSm427デフォルトの名無しさん
2022/08/14(日) 12:35:39.15ID:q44Oj4I2 >>424
そんな当たり前のことで問題のすり替えをするのは行儀がよろしくない
>422では明確にデータ競合の話をしている
どの話であってもまずはデータ競合を起こさないことが必須
しかしこれまでの言語はプログラマー任せであり言語として実行前に静的にデータ競合を防ぐ機能を持たなかった
Rustはそれを実現するとともにコストの高いアトミック操作無しでもデータ競合を避ける形もサポートした
そんな当たり前のことで問題のすり替えをするのは行儀がよろしくない
>422では明確にデータ競合の話をしている
どの話であってもまずはデータ競合を起こさないことが必須
しかしこれまでの言語はプログラマー任せであり言語として実行前に静的にデータ競合を防ぐ機能を持たなかった
Rustはそれを実現するとともにコストの高いアトミック操作無しでもデータ競合を避ける形もサポートした
428デフォルトの名無しさん
2022/08/14(日) 12:48:55.73ID:E6D9Byfe429デフォルトの名無しさん
2022/08/14(日) 13:14:59.37ID:q44Oj4I2430デフォルトの名無しさん
2022/08/14(日) 13:29:25.97ID:UOAed9Kc やっぱRAIIを意識しないと会話が成立しないぞ
読みたい情報が消されたり書き換えられているバグよりも危険なのは
情報を記憶する領域自体が消滅しているバグだから
書き換えを制限する効果よりもmoveやdropを制限する効果を見なければ本質が見えない
読みたい情報が消されたり書き換えられているバグよりも危険なのは
情報を記憶する領域自体が消滅しているバグだから
書き換えを制限する効果よりもmoveやdropを制限する効果を見なければ本質が見えない
431デフォルトの名無しさん
2022/08/14(日) 13:35:19.72ID:cZJLOqDl432デフォルトの名無しさん
2022/08/14(日) 13:53:29.77ID:ghgoUiTh データ競合可能性の回避をしてないシステムやアプリって存在するの？
433デフォルトの名無しさん
2022/08/14(日) 14:01:21.37ID:lDco67Nc 並列処理しなくてもmutable aliasingにまつわるバグは起こりうるよね
典型的にはコレクションのイテレート中の要素追加とか
これを防ぐ仕組みを整えたらうまいこと並列処理にも応用できたという話であってデータ競合を防ぐことが本質ではない
典型的にはコレクションのイテレート中の要素追加とか
これを防ぐ仕組みを整えたらうまいこと並列処理にも応用できたという話であってデータ競合を防ぐことが本質ではない
434デフォルトの名無しさん
2022/08/14(日) 14:09:17.85ID:osAuRY7C >>432
回避し切れてないシステムやアプリはそこそこ存在するけどw
回避し切れてないシステムやアプリはそこそこ存在するけどw
435デフォルトの名無しさん
2022/08/14(日) 14:32:21.17ID:Zv4+MM+J mutable aliasingはGC言語でも防げないからなぁ
これが一度Rustに慣れてしまうと他に戻れなくなる原因の一つかも
他言語も積極的に取り入れてほしいところ
これが一度Rustに慣れてしまうと他に戻れなくなる原因の一つかも
他言語も積極的に取り入れてほしいところ
436デフォルトの名無しさん
2022/08/14(日) 15:49:07.29ID:UOAed9Kc コレクションが変更されたら
影響のあるすべてのイテレータに何か通知するべき
ここで、すべてのイテレータのリストを強参照してるとメモリが解放されないバグを作れる
GC言語でも弱参照大事
影響のあるすべてのイテレータに何か通知するべき
ここで、すべてのイテレータのリストを強参照してるとメモリが解放されないバグを作れる
GC言語でも弱参照大事
437デフォルトの名無しさん
2022/08/14(日) 15:56:50.41ID:b9F5IowR Rustはオワコンだろ。
438デフォルトの名無しさん
2022/08/14(日) 16:16:26.65ID:lDco67Nc >>436
GC言語ってそこまでケアしてくれるのが普通なの？
GC言語ってそこまでケアしてくれるのが普通なの？
439デフォルトの名無しさん
2022/08/14(日) 16:30:43.31ID:b9F5IowR そういうレベルで設計する人たちだと、RustやReactなんかが良いのかもしれないな。
「レベルが高い」と思ってそうなのがアホだけど。
「弊社はアホが多いから、これで行くしかない」というのが正しい態度では？
「レベルが高い」と思ってそうなのがアホだけど。
「弊社はアホが多いから、これで行くしかない」というのが正しい態度では？
440デフォルトの名無しさん
2022/08/14(日) 16:41:26.12ID:psUND9lq すばらしい洞察
441デフォルトの名無しさん
2022/08/14(日) 16:46:59.70ID:Zv4+MM+J 実際「自分はアホなのでバグのないC++は書けない」と思ってRust書いてるよ
年とともに集中力も維持し続けられなくなるし、コンパイラに助けてもらわないとどうしようもない
年とともに集中力も維持し続けられなくなるし、コンパイラに助けてもらわないとどうしようもない
442デフォルトの名無しさん
2022/08/14(日) 17:03:40.00ID:lDco67Nc 昔の静的型付けvs動的型付け論争思い出すね
開発者は十分賢いと仮定しレビューやテストでバグを見つけられれば十分とする立場と、
実行前に機械的に抽出できるバグは潰しておきたい立場の違い
開発者は十分賢いと仮定しレビューやテストでバグを見つけられれば十分とする立場と、
実行前に機械的に抽出できるバグは潰しておきたい立場の違い
443デフォルトの名無しさん
2022/08/14(日) 17:06:11.09ID:2tPpitqi Rustで「簡単」になるのははチームやコードを管理するリーダーやマネージャーで、実装するコーダーにとっては「簡単」じゃないのにな。
444デフォルトの名無しさん
2022/08/14(日) 17:08:43.26ID:b9F5IowR そういうレベルだと、なに使っても同じでは？
445デフォルトの名無しさん
2022/08/14(日) 17:10:46.46ID:lDco67Nc レビューやテストでなんとかできるなら現世代言語で十分だよね
次世代言語という観点では、実行前により多くの問題点を検出することや、検出できる問題の量を保ったままコード記述の自由度を高めることが期待されてることのひとつだと思う
次世代言語という観点では、実行前により多くの問題点を検出することや、検出できる問題の量を保ったままコード記述の自由度を高めることが期待されてることのひとつだと思う
446デフォルトの名無しさん
2022/08/14(日) 17:10:54.70ID: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を採用するに至ったというわけだ。
人手に頼る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を採用するに至ったというわけだ。
447デフォルトの名無しさん
2022/08/14(日) 17:12:42.24ID:lpUzUHFf イテレータなんてないし、for rangeで回ってくるのは常にコピーだよ。
448デフォルトの名無しさん
2022/08/14(日) 18:49:23.51ID:2zwTzsHO Rustはモダンとか言っておきながら今時セミコロン入力を強要するゴミ言語
セミコロン省略するとreturnを省略できる？何のメリットがあんのそれ
可読性が悪くなるだけだよね
JSみたいにフォーマッタで自動入力もできないしゴミ
セミコロン省略するとreturnを省略できる？何のメリットがあんのそれ
可読性が悪くなるだけだよね
JSみたいにフォーマッタで自動入力もできないしゴミ
449デフォルトの名無しさん
2022/08/14(日) 19:57:13.45ID:TQqmfXCA >>448
Rustを書いたことないか、チュートリアルレベルでしか触ってなさそう
Rustを書いたことないか、チュートリアルレベルでしか触ってなさそう
450デフォルトの名無しさん
2022/08/14(日) 21:15:44.48ID:B+F1bo8h 文法や記述は様々な言語をやっていれば誤差と慣れだけの問題となる
それに文句をつけるのは初心者と異常者のみ
そのRustに関して言えばセミコロンや中括弧(波括弧)は機能面で必要だからある
逆に例えば「 if (条件) 」の丸括弧は不要だから「 if 条件 」
それに文句をつけるのは初心者と異常者のみ
そのRustに関して言えばセミコロンや中括弧(波括弧)は機能面で必要だからある
逆に例えば「 if (条件) 」の丸括弧は不要だから「 if 条件 」
451デフォルトの名無しさん
2022/08/14(日) 22:57:09.94ID:549c+n4K 関数型のElixir は、データを書き換えられない。immutable。
新規作成しかできない
だから、並行処理に強い
新規作成しかできない
だから、並行処理に強い
452デフォルトの名無しさん
2022/08/14(日) 23:52:55.91ID:lDco67Nc >>448
こういう議論も地味に重要だと思う
セミコロンなしでreturn必須な言語の方が可読性高いのかな？
returnを書くことで読み手にとって何が明確になるんだろうか
フォーマッタでの自動入力って何？
こういう議論も地味に重要だと思う
セミコロンなしでreturn必須な言語の方が可読性高いのかな？
returnを書くことで読み手にとって何が明確になるんだろうか
フォーマッタでの自動入力って何？
453デフォルトの名無しさん
2022/08/14(日) 23:58:23.93ID:QUSc/NM6454デフォルトの名無しさん
2022/08/15(月) 00:30:10.08ID:yUQkYoQs 文法はフォーマッタやコード生成、静的解析などのツールの作りやすさ影響してくるからあまり馬鹿にしない方が良い
455デフォルトの名無しさん
2022/08/15(月) 01:04:12.66ID:p/fNcd9R 日本人は一部はセンスあるが
RustやElixer等メタプログラミング言語が理解できないやつが多すぎる
RustやElixer等メタプログラミング言語が理解できないやつが多すぎる
456デフォルトの名無しさん
2022/08/15(月) 01:17:24.43ID:DNbe8aKk 外国人でも抽象的な概念についての難易度は同じだゾ・・・
457デフォルトの名無しさん
2022/08/15(月) 09:39:59.10ID:r7x/NN7r セミコロンを省略するとreturnになるわけではないぞ
・Rustでは式にセミコロンをつけると文になる
・ブロック({stmts}のこと)の最後の式が、そのブロックを評価したときの式となる
この二つのルールが原則で、関数のブロックの最後のセミコロンを省略すると、関数を評価した値になるってだけ
let a = {
let mut b = Builder::new();
b.add(foo);
b.add(bar);
b.build()
};
このルールのおかげでこのようなコードが書けるようになる(return文は関数から抜けるためにしか使えないので、ブロックの評価には使えない)
一時変数のスコープを最小限に抑えることができるし、mutableで宣言した変数を、スコープを抜けたらimmutableに戻すこともできる
慣れれば見やすいし、意味的なメリットも多い
・Rustでは式にセミコロンをつけると文になる
・ブロック({stmts}のこと)の最後の式が、そのブロックを評価したときの式となる
この二つのルールが原則で、関数のブロックの最後のセミコロンを省略すると、関数を評価した値になるってだけ
let a = {
let mut b = Builder::new();
b.add(foo);
b.add(bar);
b.build()
};
このルールのおかげでこのようなコードが書けるようになる(return文は関数から抜けるためにしか使えないので、ブロックの評価には使えない)
一時変数のスコープを最小限に抑えることができるし、mutableで宣言した変数を、スコープを抜けたらimmutableに戻すこともできる
慣れれば見やすいし、意味的なメリットも多い
458デフォルトの名無しさん
2022/08/15(月) 10:33:46.88ID:p/fNcd9R459デフォルトの名無しさん
2022/08/15(月) 10:41:42.04ID:8YjBNSEW460デフォルトの名無しさん
2022/08/15(月) 11:14:59.57ID:0McKJS85 バカはバカを呼び寄せる
461デフォルトの名無しさん
2022/08/15(月) 11:41:54.68ID:i3sQrZ2z >>459がどの言語の文法を理想と考えているのかが気になる
golang?
golang?
462デフォルトの名無しさん
2022/08/15(月) 12:05:46.45ID:r7x/NN7r なぜRustに対する批判が具体的なものじゃなくて、「意味不明」とか「不要」とか主観的で何を指しているのかわからないような言葉ばかりなんだろう
463デフォルトの名無しさん
2022/08/15(月) 12:17:22.73ID:A27GovSV 文末のセミコロンが必須な主なプログラミング言語
C C++ Java Perl PHP など
この状況でRustのセミコロンを叩いているのはこれらの言語を知らない初心者？
しかもRustは文と値の区別のためセミコロンの有無を活用して意味付けしている
C C++ Java Perl PHP など
この状況でRustのセミコロンを叩いているのはこれらの言語を知らない初心者？
しかもRustは文と値の区別のためセミコロンの有無を活用して意味付けしている
464デフォルトの名無しさん
2022/08/15(月) 12:21:25.57ID:8YjBNSEW465デフォルトの名無しさん
2022/08/15(月) 12:39:14.98ID:vxI8O7UY Python Ruby JavaScript Scala Kotlin あとなにがあったっけなぁ
466デフォルトの名無しさん
2022/08/15(月) 12:42:41.40ID:8YjBNSEW >>457
逆にセミコロンなしをデフォルトにしてセミコロンとかつけると式になるとかでもいいのでは？
その書き方ができると便利なのは否定しないけど、その恩恵を得るためだけに全てにセミコロン付けるのを押し付けるのは余計なコストだっていいたいわ
逆にセミコロンなしをデフォルトにしてセミコロンとかつけると式になるとかでもいいのでは？
その書き方ができると便利なのは否定しないけど、その恩恵を得るためだけに全てにセミコロン付けるのを押し付けるのは余計なコストだっていいたいわ
467デフォルトの名無しさん
2022/08/15(月) 12:52:23.38ID: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;
}
これもエラーとなる
昔から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;
}
これもエラーとなる
468デフォルトの名無しさん
2022/08/15(月) 12:53:34.04ID:A27GovSV >>467のようにGoは「セミコロンが必須だけど、省略可で、自動セミコロン挿入される言語」であるため
うっかり改行すると自動セミコロン挿入により文法エラーとなってしまう
うっかり改行すると自動セミコロン挿入により文法エラーとなってしまう
469デフォルトの名無しさん
2022/08/15(月) 12:53:34.61ID:lLs0VW2c Rustで文と式が混在するのは最適化のため？文でエラーが発生したときはどうなるんかね？
resultとかの戻り値用変数があると自然だけど、末尾呼び出し最適化が面倒になるので痛し痒し。
resultとかの戻り値用変数があると自然だけど、末尾呼び出し最適化が面倒になるので痛し痒し。
470デフォルトの名無しさん
2022/08/15(月) 13:06:38.69ID:8YjBNSEW471デフォルトの名無しさん
2022/08/15(月) 13:10:39.72ID:r7x/NN7r >>466
文にセミコロンをつけると式になるって文法を整合性を保ったまま定義できるとは思えない....
1とかtrueみたいな一つの値は式として扱う
ifやmatchはデフォルトで文として扱い、セミコロンをつけると式になるって文法にすると
let x = f(if cond { ... } else { ... };)
みたいな文で、どこが文でどこが式なのか曖昧さを持ってしまう気がする
文にセミコロンをつけると式になるって文法を整合性を保ったまま定義できるとは思えない....
1とかtrueみたいな一つの値は式として扱う
ifやmatchはデフォルトで文として扱い、セミコロンをつけると式になるって文法にすると
let x = f(if cond { ... } else { ... };)
みたいな文で、どこが文でどこが式なのか曖昧さを持ってしまう気がする
472デフォルトの名無しさん
2022/08/15(月) 13:14:43.30ID:r7x/NN7r 構文解析の簡単さってかなり大事なことだと思う
language serverも軽くなるしコンパイルも早くなる
適当に書いてフォーマッタで整形するって書き方もできるようになる
セミコロンをつけるのが面倒なのは分かるけど、それ以上の恩恵があるのは事実
language serverも軽くなるしコンパイルも早くなる
適当に書いてフォーマッタで整形するって書き方もできるようになる
セミコロンをつけるのが面倒なのは分かるけど、それ以上の恩恵があるのは事実
473デフォルトの名無しさん
2022/08/15(月) 13:15:05.13ID:JDmNxXPp 文法エラーになってからわざわざ直すのは面倒くさくないの？
JS/TSでもASIの罠にはまらないように考えるほうが面倒だから基本セミコロン付けているな
JS/TSでもASIの罠にはまらないように考えるほうが面倒だから基本セミコロン付けているな
474デフォルトの名無しさん
2022/08/15(月) 13:19:28.24ID:zxOEKBbO475デフォルトの名無しさん
2022/08/15(月) 13:22:56.61ID:r7x/NN7r >>469
Rustでは文は
Item(関数の定義や構造体の定義など)
LetStatement(let文)
ExpressionStatement(式にセミコロンつけたやつ)
MacroInvocation(hoge!();みたいにマクロの使用にセミコロンつけたやつ)
しかないから、そもそも文はエラーを生成しない
文の中の式がエラーを生成することはあるけど、文法上はハンドリングも式の中で行われる
https://doc.rust-lang.org/stable/reference/statements.html
Rustでは文は
Item(関数の定義や構造体の定義など)
LetStatement(let文)
ExpressionStatement(式にセミコロンつけたやつ)
MacroInvocation(hoge!();みたいにマクロの使用にセミコロンつけたやつ)
しかないから、そもそも文はエラーを生成しない
文の中の式がエラーを生成することはあるけど、文法上はハンドリングも式の中で行われる
https://doc.rust-lang.org/stable/reference/statements.html
476デフォルトの名無しさん
2022/08/15(月) 13:23:00.24ID:8YjBNSEW477デフォルトの名無しさん
2022/08/15(月) 13:32:10.82ID:r7x/NN7r >>476
式の全てにセミコロンが強要されているわけではないぞ
Block(ifとかmatchとかの{}を使うやつ)を含む式であるExpressionWithBlockではセミコロンの省略が可能とされている
だから、式を文として扱うべき場所で必要最低限のセミコロンが強制されている
https://doc.rust-lang.org/stable/reference/statements.html#expression-statements
式の全てにセミコロンが強要されているわけではないぞ
Block(ifとかmatchとかの{}を使うやつ)を含む式であるExpressionWithBlockではセミコロンの省略が可能とされている
だから、式を文として扱うべき場所で必要最低限のセミコロンが強制されている
https://doc.rust-lang.org/stable/reference/statements.html#expression-statements
478デフォルトの名無しさん
2022/08/15(月) 13:36:40.79ID:zxOEKBbO479デフォルトの名無しさん
2022/08/15(月) 14:50:27.64ID:iWGF+SuJ セミコロンは面倒だし書かなくていいならそれに越した事ないけど
JSみたいに罠に嵌るくらいなら明示的に書くのでも別にいい
Rustはじめた当初はセミコロンの有無で戻り値が変わるのはめちゃイライラしたけど2週間もすれば慣れる
セミコロン不要言語ではRubyやSwiftは縛りが少なくて扱いやすい
Pythonは改行できるケースがかなり限定されてるから扱いにくい(そのくせ1行80文字にしろとかアタオカ)
JSみたいに罠に嵌るくらいなら明示的に書くのでも別にいい
Rustはじめた当初はセミコロンの有無で戻り値が変わるのはめちゃイライラしたけど2週間もすれば慣れる
セミコロン不要言語ではRubyやSwiftは縛りが少なくて扱いやすい
Pythonは改行できるケースがかなり限定されてるから扱いにくい(そのくせ1行80文字にしろとかアタオカ)
480デフォルトの名無しさん
2022/08/15(月) 15:00:02.78ID:i3sQrZ2z 話題か全然次世代言語っぽくないな
次世代言語は人間の考えを忖度して良い感じにコードを解釈して欲しい
セミコロンとか些細な文法レベルじゃなくて、自動的に最適なアルゴリズム選んでくれるとか
次世代言語は人間の考えを忖度して良い感じにコードを解釈して欲しい
セミコロンとか些細な文法レベルじゃなくて、自動的に最適なアルゴリズム選んでくれるとか
481デフォルトの名無しさん
2022/08/15(月) 15:18:34.31ID:n9YpVahh どういうトレードオフの上に成り立ってるかを理解しようとしない人とは技術的な議論はない立たないわな
482デフォルトの名無しさん
2022/08/15(月) 16:06:15.48ID:fboUSwN3 長い行を途中で改行したくなったらどうなるか？
・JavaScriptだと正しく333333333と出力
let foo = 111111111
+ 222222222
console.log(foo)
・Goだとエラー(+222222222が使われていない)となる
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)
セミコロンがある言語ならば長い行を自由に改行できる
・JavaScriptだと正しく333333333と出力
let foo = 111111111
+ 222222222
console.log(foo)
・Goだとエラー(+222222222が使われていない)となる
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)
セミコロンがある言語ならば長い行を自由に改行できる
483デフォルトの名無しさん
2022/08/15(月) 17:19:36.40ID:zuAYSXsv foo = (111111111
+ 222222222)
print(foo)
1つの評価式としたいのに途中改行を入れることを利点だと主張するなんてバカげている....
素直にC/C++の古めかしい記述を引き継ぎたい人が多いだけというのは、公式も認めてるのに
+ 222222222)
print(foo)
1つの評価式としたいのに途中改行を入れることを利点だと主張するなんてバカげている....
素直にC/C++の古めかしい記述を引き継ぎたい人が多いだけというのは、公式も認めてるのに
484デフォルトの名無しさん
2022/08/15(月) 17:58:11.91ID:wGU2BFOZ セパレータ無しで改行を無視するようにしたいなら、yamlのブロックスタイルぐらいが妥当かと。
485デフォルトの名無しさん
2022/08/15(月) 18:28:05.88ID:vxI8O7UY セミコロンが面倒とは言っても、インデントのタブと同じで頭使わないから楽だと思うんだがなぁ。
そんなに毛嫌いするようなことなんだろうか。
そんなに毛嫌いするようなことなんだろうか。
486デフォルトの名無しさん
2022/08/15(月) 18:35:55.10ID:zxOEKBbO もうここら辺の話は好みの問題もあるからこっちが正しいとか言っても揉めるだけ
>>483にしても無駄なカッコはヤダって奴が出るかも知れんし
foo = 111111111 +
222222222
で正しく処理できる言語もあるけどプラスの位置が気に入らんとか言う奴がいるかも知れんしな
>>483にしても無駄なカッコはヤダって奴が出るかも知れんし
foo = 111111111 +
222222222
で正しく処理できる言語もあるけどプラスの位置が気に入らんとか言う奴がいるかも知れんしな
487デフォルトの名無しさん
2022/08/15(月) 18:42:32.98ID:qHbAfBQi セミコロンがいるいらないなんてそんなに気にする事なのかな？
Cスタイルで無い書き方する言語の方がよっぽど見にくいんだよねぇ
Cスタイルで無い書き方する言語の方がよっぽど見にくいんだよねぇ
488デフォルトの名無しさん
2022/08/15(月) 19:05:59.41ID:QBWih2zA Dartもそうだけどセミコロンなし言語に慣れてると忘れる時にいちいちエラーになってうざい
JSはprettierで自動入力できるけど、エラーになるのがめんどくさい
まあただの慣れの問題だけど
JSはprettierで自動入力できるけど、エラーになるのがめんどくさい
まあただの慣れの問題だけど
489デフォルトの名無しさん
2022/08/15(月) 19:17:14.24ID:Q0+/Bn9w PowerShell（; 不要） と C#（; 必要） 使ってるとたまにあれ？って思うことあるけどたいして混乱しないよ
そんなのにいちいち引っかかってたら他にもっと引っかかるところあると思うが
そんなのにいちいち引っかかってたら他にもっと引っかかるところあると思うが
490デフォルトの名無しさん
2022/08/15(月) 19:17:50.21ID:jGpDADDF Rustはセミコロンレスにする実装が面倒ってだけやろ
エルゴノミクス的にはセミコロンなしのほうがいいに決まってる
エルゴノミクス的にはセミコロンなしのほうがいいに決まってる
491デフォルトの名無しさん
2022/08/15(月) 19:34:59.12ID:On5LnEYn むしろ482のような何も考えられない熟練者が、他の多くの言語を全否定してるのであって、Cスタイルを否定しているわけではない。
Cスタイルで無い書き方する言語の方が見にくいというのはよほど経験が足りないか、組み込みかシステムプログラミングでC/C++の
沼にどっぷりハマってるか....いまどきbashもTypescript/JSもLuaも書くだろうし、DeepleanningしたいならPythonぐらい触るでしょう？
Cスタイルで無い書き方する言語の方が見にくいというのはよほど経験が足りないか、組み込みかシステムプログラミングでC/C++の
沼にどっぷりハマってるか....いまどきbashもTypescript/JSもLuaも書くだろうし、DeepleanningしたいならPythonぐらい触るでしょう？
492デフォルトの名無しさん
2022/08/15(月) 19:42:50.19ID:On5LnEYn フリーフォーマットスタイルになったのだって、B言語の毛の生えたC言語初期がブロック表す{}でさえ、当時の多くのコンピュータのキーボードで
打てなかったのに採用しており明らかにパーサーを簡単にしたいがためだけで、確かに欠陥は無いが、他の言語を否定する有益な要素には
全く成り得ない。「頭がCスタイル＝だから個人的にはそれが一番見やすい」という理論なら分かるが、一般化できるものではない
打てなかったのに採用しており明らかにパーサーを簡単にしたいがためだけで、確かに欠陥は無いが、他の言語を否定する有益な要素には
全く成り得ない。「頭がCスタイル＝だから個人的にはそれが一番見やすい」という理論なら分かるが、一般化できるものではない
493デフォルトの名無しさん
2022/08/15(月) 19:46:40.39ID:DNbe8aKk フリーフォマットスタイルってウケる言いまわしだね
494デフォルトの名無しさん
2022/08/15(月) 19:51:28.75ID:v4xWLNJI 些細なことで盛り上がってるな
昨日のRust叩きがすぐ論破されてRustは高機能で優秀だと決着してしまったから
今日のRust叩きはセミコロンと波カッコがテーマなのかい？
昨日のRust叩きがすぐ論破されてRustは高機能で優秀だと決着してしまったから
今日のRust叩きはセミコロンと波カッコがテーマなのかい？
495デフォルトの名無しさん
2022/08/15(月) 20:17:06.88ID:1icmhpVn >>494
「誰にとって」高機能で優秀なのかを考えんとな。
リーダーとかマネージャーとかの管理者にとって、Rustはルールを強制して一定の安全性と性能を担保できる便利なルール。
その裏返しになるけど、コーダーみたいな実装者にとって、Rustは窮屈な制約や複雑な概念を押し付けられる不便な扱いづらいツール。
優れたプログラマーはコーダーであるとともにマネージャーでもリーダーでもあるからRustの利点は分からんでもないけど、普段使いにはしたくないツールだよなぁ。
今の複雑さじゃHaskellとかc++とかと大して変わらんから、そのうちもっと洗練された言語が出てくるんじゃない？
「誰にとって」高機能で優秀なのかを考えんとな。
リーダーとかマネージャーとかの管理者にとって、Rustはルールを強制して一定の安全性と性能を担保できる便利なルール。
その裏返しになるけど、コーダーみたいな実装者にとって、Rustは窮屈な制約や複雑な概念を押し付けられる不便な扱いづらいツール。
優れたプログラマーはコーダーであるとともにマネージャーでもリーダーでもあるからRustの利点は分からんでもないけど、普段使いにはしたくないツールだよなぁ。
今の複雑さじゃHaskellとかc++とかと大して変わらんから、そのうちもっと洗練された言語が出てくるんじゃない？
496デフォルトの名無しさん
2022/08/15(月) 20:32:42.70ID:IKaKwzzk ルールは強制じゃないんだよなあ
税金を払ってない金持ちがいるのと同じ
税金を払ってない金持ちがいるのと同じ
497デフォルトの名無しさん
2022/08/15(月) 22:14:46.12ID:i3sQrZ2z >>495
複雑な概念を押しつけられるというよりも、現実の複雑さを処理系が覆い隠さずそのまま見せている、ただしデフォルトでは安全装置付き、というのが自分の感覚には近いかなぁ
カジュアル用途にはshared xor mutabilityを採用したGCあり言語があれば良いと思うんだけどそれでも敷居高いと言われてしまうのかな
複雑な概念を押しつけられるというよりも、現実の複雑さを処理系が覆い隠さずそのまま見せている、ただしデフォルトでは安全装置付き、というのが自分の感覚には近いかなぁ
カジュアル用途にはshared xor mutabilityを採用したGCあり言語があれば良いと思うんだけどそれでも敷居高いと言われてしまうのかな
498デフォルトの名無しさん
2022/08/15(月) 22:21:40.52ID:i3sQrZ2z >>495はrustのチェックが過剰と言いたいのか、プログラムがエッジケースでクラッシュしても良いからプログラマーの自由にさせろと言いたいのか、どっちなんだろう
499デフォルトの名無しさん
2022/08/15(月) 22:28:42.72ID:vxI8O7UY500デフォルトの名無しさん
2022/08/15(月) 22:34:42.13ID:H/w3DVjw >>497
shared reference, mutable reference, ownedの3種類を常に分けるのは作る側も使う側も面倒でしょ
GC言語でdata raceを避けるためだけに許容できる面倒臭さではないと思う
shared reference, mutable reference, ownedの3種類を常に分けるのは作る側も使う側も面倒でしょ
GC言語でdata raceを避けるためだけに許容できる面倒臭さではないと思う
501デフォルトの名無しさん
2022/08/15(月) 22:37:46.04ID:krDSEAE6502デフォルトの名無しさん
2022/08/15(月) 22:46:07.54ID:vxI8O7UY503デフォルトの名無しさん
2022/08/15(月) 22:50:19.22ID:1icmhpVn504デフォルトの名無しさん
2022/08/15(月) 23:08:45.28ID:efQSXXjx >>500
まともなプログラマーならば
mutableかimmutableを必ず区別するしスクリプト言語にすら区別がある
GC言語だからそんな面倒な区別をしないなんてことはない
更にそのもの自体かreference (pointer)かの区別をする言語も多い
まともなプログラマーならば
mutableかimmutableを必ず区別するしスクリプト言語にすら区別がある
GC言語だからそんな面倒な区別をしないなんてことはない
更にそのもの自体かreference (pointer)かの区別をする言語も多い
505デフォルトの名無しさん
2022/08/15(月) 23:36:07.11ID: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みたいなので十分
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みたいなので十分
506デフォルトの名無しさん
2022/08/15(月) 23:43:36.56ID:efQSXXjx >>505
書き換えるのか書き換えずに読み取るだけなのか必ず区別する
プログラマーならそこは絶対に意識するところ
参照なのか実体なのかも同様に区別する
例えばcall by referenceなのか否かで変わってくるから常識
書き換えるのか書き換えずに読み取るだけなのか必ず区別する
プログラマーならそこは絶対に意識するところ
参照なのか実体なのかも同様に区別する
例えばcall by referenceなのか否かで変わってくるから常識
507デフォルトの名無しさん
2022/08/15(月) 23:44:00.49ID:bWP5l8ZG >>502
挙げてる言語が全てセミコロンのようなものが無ければ、改行をパースできない言語だけを挙げておいて
サンプルが悪くないと考えられることはセミコロンを入れる言語を優先したいだけでしょ？
そして482がいってるのはトレードオフなんて一言も言ってないし→同一人物だとすればサンプルも悪い
挙げてる言語が全てセミコロンのようなものが無ければ、改行をパースできない言語だけを挙げておいて
サンプルが悪くないと考えられることはセミコロンを入れる言語を優先したいだけでしょ？
そして482がいってるのはトレードオフなんて一言も言ってないし→同一人物だとすればサンプルも悪い
508デフォルトの名無しさん
2022/08/15(月) 23:59:03.56ID:1yqLKMZ0 >>505
噓つき
まず、使い分けと言っても間違って使っていたらRustコンパイラが指摘してくれるから、他の言語のようにプログラマーに責任と義務を押し付ける形で使い分ける必要は全くない
次に、今まで様々なプログラムを書いてきて、そのための3種類の構造体やimplを用意する必要になったことは一度もない
プログラムでやりたいことは一つなのだからどれか一つに決まる
その選択を仮に間違えていてもRustコンパイラが指摘してくれるので必ず正解を選択できて楽勝
Rustはプログラマーへの責任圧力や負荷が非常に少ない
間違えてもコンパイラが賢くて教えてくれるし次第に慣れて間違いも激減
噓つき
まず、使い分けと言っても間違って使っていたらRustコンパイラが指摘してくれるから、他の言語のようにプログラマーに責任と義務を押し付ける形で使い分ける必要は全くない
次に、今まで様々なプログラムを書いてきて、そのための3種類の構造体やimplを用意する必要になったことは一度もない
プログラムでやりたいことは一つなのだからどれか一つに決まる
その選択を仮に間違えていてもRustコンパイラが指摘してくれるので必ず正解を選択できて楽勝
Rustはプログラマーへの責任圧力や負荷が非常に少ない
間違えてもコンパイラが賢くて教えてくれるし次第に慣れて間違いも激減
509デフォルトの名無しさん
2022/08/16(火) 00:25:36.99ID:ixQkAKAb510デフォルトの名無しさん
2022/08/16(火) 00:31:52.46ID:FJ3wHtGm >>505
全部refcell相当にしてランタイムでよしなに処理できないかね？
全部refcell相当にしてランタイムでよしなに処理できないかね？
511デフォルトの名無しさん
2022/08/16(火) 00:45:43.29ID:OuJTqPA4512デフォルトの名無しさん
2022/08/16(火) 01:34:09.32ID:VwgHy53B RefCellは無視してCellを使うのがコツかなと思ってる
513デフォルトの名無しさん
2022/08/16(火) 01:41:29.91ID:tWxob/nJ514デフォルトの名無しさん
2022/08/16(火) 02:21:22.55ID:QGAuy2Qq Rustは便利でプログラミングしやすくて良いね
間違えてもコンパイラが必ず阻止して親切に教えてくれる
他の言語だと同じように間違えていても見かけの文法さえ合っていればコンパイラが通してしまう
間違えてもコンパイラが必ず阻止して親切に教えてくれる
他の言語だと同じように間違えていても見かけの文法さえ合っていればコンパイラが通してしまう
515デフォルトの名無しさん
2022/08/16(火) 05:56:45.08ID:yor5shok とにかくRustさえ使っとけば安心安全だよね
516デフォルトの名無しさん
2022/08/16(火) 06:08:59.99ID:QGAuy2Qq いやRustはプログラミングしやすいことが感想
たまたま安全も付いてきた
あとなぜか高速も付いてきてラッキー
たまたま安全も付いてきた
あとなぜか高速も付いてきてラッキー
517デフォルトの名無しさん
2022/08/16(火) 06:09:39.15ID:weNk37uO xor mutabilityを実装するとライフタイムの解析みたいなことが必要になるから結局GC要らなくね？みたいなことになりそう
518デフォルトの名無しさん
2022/08/16(火) 06:47:45.38ID:tUBxw7eu 3種類あると言ってたのに
xorとかいって2種類を意識してるのは違和感がある
意識の外にあるmoveの方が実は革新的だったりして
xorとかいって2種類を意識してるのは違和感がある
意識の外にあるmoveの方が実は革新的だったりして
519デフォルトの名無しさん
2022/08/16(火) 07:59:13.38ID:sSvGV+9Q520デフォルトの名無しさん
2022/08/16(火) 08:09:09.89ID:QGAuy2Qq521デフォルトの名無しさん
2022/08/16(火) 10:10:30.02ID:R/XB+eZ/522デフォルトの名無しさん
2022/08/16(火) 11:21:12.43ID:qWFX9EwW そもそもRustとかの新しい言語は演算子の途中とかで改行できるようにするためにセミコロンを用意したわけじゃないし…
523デフォルトの名無しさん
2022/08/16(火) 11:34:08.30ID:2x3mrzZQ ;ない言語(例えば
python)で途中で改行したいなら(
)
python)で途中で改行したいなら(
)
524デフォルトの名無しさん
2022/08/16(火) 12:15:04.38ID:rcGuvRNd525デフォルトの名無しさん
2022/08/16(火) 13:22:47.54ID:lhfuWNrE >>522
まさにそう。見る角度によって美点を見出すのは人それぞれだがセミコロンなんてものを挙げて長い行が複数行で書けるなどと
長大なくだらない例を別言語叩きにしようとする腐った根性がまず気に入らない。公式すら見えてない白痴
まさにそう。見る角度によって美点を見出すのは人それぞれだがセミコロンなんてものを挙げて長い行が複数行で書けるなどと
長大なくだらない例を別言語叩きにしようとする腐った根性がまず気に入らない。公式すら見えてない白痴
526デフォルトの名無しさん
2022/08/16(火) 13:53:44.58ID:oZyv9MO8 うむ
セミコロンの有無で気に入らない言語を叩き出したやつはキチガイ
それぞれにメリットはあるしプログラマーにとってもどうでもいい誤差
セミコロンの有無で気に入らない言語を叩き出したやつはキチガイ
それぞれにメリットはあるしプログラマーにとってもどうでもいい誤差
527デフォルトの名無しさん
2022/08/16(火) 14:40:34.16ID:R/XB+eZ/ 分類するとこんな感じかな。
1. 改行を文デリミタとして、文を途中で折り返したい場合には行継続を明示する (FORTRANなど)
2. 改行に空白以上の文法的意味を持たせずに文分離記号、終端器具を用いる (ALGOLなど)
3. 1.の変形で、構文解析と組み合わせることで行継続の明示を不要とする (Pythonなど)
当然ながらどれも一長一短あるわな。
1. 改行を文デリミタとして、文を途中で折り返したい場合には行継続を明示する (FORTRANなど)
2. 改行に空白以上の文法的意味を持たせずに文分離記号、終端器具を用いる (ALGOLなど)
3. 1.の変形で、構文解析と組み合わせることで行継続の明示を不要とする (Pythonなど)
当然ながらどれも一長一短あるわな。
528デフォルトの名無しさん
2022/08/16(火) 14:55:33.84ID:oZyv9MO8 セミコロンが有ったり無かったり些細なことで各プログラミング言語を批判する人は間違いなくキチガイ
529デフォルトの名無しさん
2022/08/16(火) 15:00:16.01ID:rvHyZbYe 技術的な話が理解できないからセミコロンくらいしか口出しできないんだろ
530デフォルトの名無しさん
2022/08/16(火) 17:28:09.35ID:a2udn/hF 言語を作る側と使う側の視点が噛み合ってないように見えるし、なんかマニアックな方向に議論が進んでるな
531デフォルトの名無しさん
2022/08/16(火) 17:59:37.32ID:olQxb0zT ASTとプレゼンテーション層としてのテキスト表現でしかないから内容と見た目の分離をすれば…みたいに考えてしまうが、htmlとcssの関係みたいにすぐそばに地獄の例もあるからなぁ。
532デフォルトの名無しさん
2022/08/16(火) 18:09:52.12ID:tUBxw7eu533デフォルトの名無しさん
2022/08/16(火) 18:11:37.15ID:pgEfkacG なんで母国語の文法でプログラミングできないの？
っていう質問と大差ないぐらいにはナンセンスなんだよなあ
っていう質問と大差ないぐらいにはナンセンスなんだよなあ
534デフォルトの名無しさん
2022/08/16(火) 18:32:26.44ID:m9HqH8W6 >>527
その分類だとRustのセミコロンの特殊性が埋没する
その分類だとRustのセミコロンの特殊性が埋没する
535デフォルトの名無しさん
2022/08/16(火) 18:53:59.07ID:wpAgGEI5536デフォルトの名無しさん
2022/08/16(火) 19:09:03.56ID:R/XB+eZ/ >>534
構文的には特殊なことなどなくPascal等と同じ.だろう。評価結果が違うだけ。
構文的には特殊なことなどなくPascal等と同じ.だろう。評価結果が違うだけ。
537デフォルトの名無しさん
2022/08/16(火) 21:15:03.57ID:I6WTAUR3 プログラム言語の長短を議論したいなら、最低限、構文解析と型理論ぐらいは勉強しなよww
自分の使えるプログラミング言語の表層だけ見てあれこれ言っても仕方がない
せめて基礎知識ぐらいは身につけないと、自分の得意な言語こそが最強！レベルの話し合いにしかならない
自分の使えるプログラミング言語の表層だけ見てあれこれ言っても仕方がない
せめて基礎知識ぐらいは身につけないと、自分の得意な言語こそが最強！レベルの話し合いにしかならない
538デフォルトの名無しさん
2022/08/16(火) 21:27:16.28ID:tUBxw7eu マイナス金利政策みたいに
何かを変えたいという目標が達成されるまで全く同じことを続ける人が一定数いる
何かを変えたいという目標が達成されるまで全く同じことを続ける人が一定数いる
539デフォルトの名無しさん
2022/08/16(火) 21:55:08.25ID:AvaBHQVi このスレ、次流行る言語について考察するスレだと思ったらなんか違う感じか
540デフォルトの名無しさん
2022/08/16(火) 22:17:21.80ID:6Bs0qU/k >>539
Rustが覇権したから推進派とアンチとの攻防戦の場となっているｗ
Rustが覇権したから推進派とアンチとの攻防戦の場となっているｗ
541デフォルトの名無しさん
2022/08/16(火) 22:22:22.73ID:bk3ffD66 プログラミング言語のアンチをしてる人は精神的に何か病があるんじゃないか
542デフォルトの名無しさん
2022/08/16(火) 22:23:06.14ID:LmkLABMk NoSQLの謎の信仰で無知が露呈したRust信者w
543デフォルトの名無しさん
2022/08/16(火) 22:25:20.93ID:LmkLABMk544デフォルトの名無しさん
2022/08/16(火) 22:34:52.91ID:LmkLABMk 別にRustを批判しているわけではない
どんな用途でもRustが最強で他の言語はゴミとかほざいてるRust信者を批判しているだけ
NoSQLは万能でRDBは不要とかほざいてるようにただの無知で適材適所という言葉を知らない馬鹿ってのが証明されてるわけだが
だからRustは低レイヤーには適しているがバックエンドやWebといった用途ではさほど適していないので流行らないってのに反論できずに発狂しているのが現実
やたらクラウドのコストガーメモリ効率ガーだとか主張するが運用する上での人件費のことを一切考えられないキチガイ
どんな用途でもRustが最強で他の言語はゴミとかほざいてるRust信者を批判しているだけ
NoSQLは万能でRDBは不要とかほざいてるようにただの無知で適材適所という言葉を知らない馬鹿ってのが証明されてるわけだが
だからRustは低レイヤーには適しているがバックエンドやWebといった用途ではさほど適していないので流行らないってのに反論できずに発狂しているのが現実
やたらクラウドのコストガーメモリ効率ガーだとか主張するが運用する上での人件費のことを一切考えられないキチガイ
545デフォルトの名無しさん
2022/08/16(火) 22:39:39.43ID:bczdNrJL プログラマーは社会不適合者しかいないんだから仲良くせいや
546デフォルトの名無しさん
2022/08/16(火) 22:42:24.87ID:LmkLABMk 簡単に言うとRustはCやC++を置き換える言語
だからCやC++が通常使わなれない用途で流行ることはまずない
これが現実、いくら信者が発狂しても現実は変わらんよ
だからCやC++が通常使わなれない用途で流行ることはまずない
これが現実、いくら信者が発狂しても現実は変わらんよ
547デフォルトの名無しさん
2022/08/16(火) 22:43:33.40ID:bk3ffD66548デフォルトの名無しさん
2022/08/16(火) 22:45:57.82ID:R/XB+eZ/ ID:8YjBNSEW が自分のことを棚に上げて藁人形を持ち出した
549デフォルトの名無しさん
2022/08/16(火) 22:48:22.06ID:l1mRFV/Y >>544
調べてみたが『RDBは不要』と主張している人はこのスレに一人もいない
あなたが狂っているから全く存在しないものをあなただけが見えているのだろう
あなたは自分が狂っていることにそろそろ気付くべきだ
調べてみたが『RDBは不要』と主張している人はこのスレに一人もいない
あなたが狂っているから全く存在しないものをあなただけが見えているのだろう
あなたは自分が狂っていることにそろそろ気付くべきだ
550デフォルトの名無しさん
2022/08/16(火) 22:53:09.15ID:LmkLABMk551デフォルトの名無しさん
2022/08/16(火) 22:53:32.19ID:aPDXDhC0 >>546
そういう嘘はよくないなあ
流れとしては明らかに2系統あって
『自動メモリ解放で安全なのに、C言語と同じ省メモリ＆同じ速さが出る言語』として
スクリプト言語を含む様々なGC言語からRustへ、という流れが多い
そういう嘘はよくないなあ
流れとしては明らかに2系統あって
『自動メモリ解放で安全なのに、C言語と同じ省メモリ＆同じ速さが出る言語』として
スクリプト言語を含む様々なGC言語からRustへ、という流れが多い
552デフォルトの名無しさん
2022/08/16(火) 22:57:57.27ID:LmkLABMk Rustと他言語の関係も
RDBもNoSQLの関係も同じで
実際は要件に照らし合わせて適材適所で選択していくのが現実
Rust信者は適材適所って言葉を知らないからNoSQLが最強でRDBはゴミ
Rustが最強でGC言語はゴミ
と要件を無視しまるで全ての用途に対し万能であるかのように喧伝する
こういった思考停止したマウント意識の高い妄信者が死滅してくれればRustは日本でも流行っていくだろうw
RDBもNoSQLの関係も同じで
実際は要件に照らし合わせて適材適所で選択していくのが現実
Rust信者は適材適所って言葉を知らないからNoSQLが最強でRDBはゴミ
Rustが最強でGC言語はゴミ
と要件を無視しまるで全ての用途に対し万能であるかのように喧伝する
こういった思考停止したマウント意識の高い妄信者が死滅してくれればRustは日本でも流行っていくだろうw
553デフォルトの名無しさん
2022/08/16(火) 22:59:41.00ID:LmkLABMk >>551
> スクリプト言語を含む様々なGC言語からRustへ
それってあなたの感想ですよね？なんかそう言うデータあるんですか？
CやC++からRustに移行していくって流れなら一般的に言われてると思うけどそれは初めて聞いたわー
妄信者しか言ってないよね笑
> スクリプト言語を含む様々なGC言語からRustへ
それってあなたの感想ですよね？なんかそう言うデータあるんですか？
CやC++からRustに移行していくって流れなら一般的に言われてると思うけどそれは初めて聞いたわー
妄信者しか言ってないよね笑
554デフォルトの名無しさん
2022/08/16(火) 23:01:02.80ID:l1mRFV/Y >>550
ほら、あなたが狂っていることがこれで完全に証明された
あなたが指しているそれらのスレを見ると
『RDBは不要』との主張などこにもなく
むしろ逆で
『RDBの利用を必要最小限にする』とある
つまりRDBを最小限必要とするとの主張だ
以下ソース引用
>>88
> RDBはコストが高いだけでなくパフォーマンス面でも不利だから利用を最小限にする
>>99
> クラウドが提供するRDBの高コストなど現実を理解していれば
> RDBの利用を必要最小限にした方が有利なことが理解できるだろう
ソース引用以上
あなたが狂っているからあなたは誤読としくは意図的に嘘をつく狂った行動をあなたはとっていると証明された
ほら、あなたが狂っていることがこれで完全に証明された
あなたが指しているそれらのスレを見ると
『RDBは不要』との主張などこにもなく
むしろ逆で
『RDBの利用を必要最小限にする』とある
つまりRDBを最小限必要とするとの主張だ
以下ソース引用
>>88
> RDBはコストが高いだけでなくパフォーマンス面でも不利だから利用を最小限にする
>>99
> クラウドが提供するRDBの高コストなど現実を理解していれば
> RDBの利用を必要最小限にした方が有利なことが理解できるだろう
ソース引用以上
あなたが狂っているからあなたは誤読としくは意図的に嘘をつく狂った行動をあなたはとっていると証明された
555デフォルトの名無しさん
2022/08/16(火) 23:03:45.36ID:LmkLABMk そもそもGC言語ってのは誰でも書きやすいようになってるから流行ってるわけ
CとC++に比べて劇的に楽になっているってのが流行ってる最大の理由
Rustは当然GCがなくなる分自分で管理する必要がありそれなりの難易度があるからGC言語からRustに置き換わるなんて流れはどこにもありはしない
ほんと妄想が酷いんだなw
GCがボトルネックになるケースなんてごく稀であるし、そういったレアな要件で初めてRustに移行することを検討するべき
Rust信者はそう言った要件を無視し脳死でGC言語からRustへだとかほざいているけど
そんな流れはこの世のどこにも存在しない
CとC++に比べて劇的に楽になっているってのが流行ってる最大の理由
Rustは当然GCがなくなる分自分で管理する必要がありそれなりの難易度があるからGC言語からRustに置き換わるなんて流れはどこにもありはしない
ほんと妄想が酷いんだなw
GCがボトルネックになるケースなんてごく稀であるし、そういったレアな要件で初めてRustに移行することを検討するべき
Rust信者はそう言った要件を無視し脳死でGC言語からRustへだとかほざいているけど
そんな流れはこの世のどこにも存在しない
556デフォルトの名無しさん
2022/08/16(火) 23:06:19.94ID:V3PalxnC いつものお二人さんw
まぁこの二人のための隔離スレだからいいんだけどさ
まぁこの二人のための隔離スレだからいいんだけどさ
557デフォルトの名無しさん
2022/08/16(火) 23:08:08.30ID:aPDXDhC0 >>552
その「NoSQLが最強でRDBはゴミ」などの書き込みはどこにあるんだ？
そういう妄想を書き込んで開き直ったり
特定の言語を執拗に批判し続けたり粗探しをして叩いている異常者がここでは問題視されている
その「NoSQLが最強でRDBはゴミ」などの書き込みはどこにあるんだ？
そういう妄想を書き込んで開き直ったり
特定の言語を執拗に批判し続けたり粗探しをして叩いている異常者がここでは問題視されている
558デフォルトの名無しさん
2022/08/16(火) 23:08:46.78ID:LmkLABMk >>554
不要って言ったのは邪推しただけかもしれないが
問題はそう言う言葉遊びではなくRust信者のコストが減るからあらゆる用途でRustがいいとかいう妄言が完全に矛盾してるから馬鹿にしてるだけだよw
それを運用していく上での人件費は？w
不要って言ったのは邪推しただけかもしれないが
問題はそう言う言葉遊びではなくRust信者のコストが減るからあらゆる用途でRustがいいとかいう妄言が完全に矛盾してるから馬鹿にしてるだけだよw
それを運用していく上での人件費は？w
559デフォルトの名無しさん
2022/08/16(火) 23:11:57.30ID:LmkLABMk 早くGC言語からRustって流れのソースを教えてくれよw
仮にPython使ってるとしたらなんでわざわざRustに変えないといけないのよ笑
どこにそんな流れがあるのか教えてくれ
仮にPython使ってるとしたらなんでわざわざRustに変えないといけないのよ笑
どこにそんな流れがあるのか教えてくれ
560デフォルトの名無しさん
2022/08/16(火) 23:17:55.21ID:Wf4So6Y0 GCか否かなんてことよりも
純粋にRustはプログラミングしやすいから
Rustが7年連続で最も愛されているプログラミング言語No.1となった
純粋にRustはプログラミングしやすいから
Rustが7年連続で最も愛されているプログラミング言語No.1となった
561デフォルトの名無しさん
2022/08/16(火) 23:22:46.98ID:Gb2scMub PythonだけでなくRubyからRustへ変えて高速化したCookpadの例もあるね
どの言語からも高速化するならRust一択になりそう
どの言語からも高速化するならRust一択になりそう
562デフォルトの名無しさん
2022/08/16(火) 23:25:10.82ID:tUBxw7eu Pythonは参照カウントもする中立派
高速化しない者だけが中立になれる
高速化しない者だけが中立になれる
563デフォルトの名無しさん
2022/08/16(火) 23:27:19.81ID:LmkLABMk プログラミングしやすいらしいがクラウド用途ではGoばかりでRustは全然使われてないな
Rustはtraitとかマクロとか抽象化プログラミング、メタプログラミングの機能がやたらと充実してるけど、逆にそれのせいでプログラミングしにくくなってるのでは？
レベルの高いプログラマーではないとうまく扱えないピーキーさがある
シンプルな言語仕様のGoで書かれた実用的なプログラムがやたらと多いのを考えるとそう言う傾向が見て取れるよね
だからここにいるアホRust信者はRustなんてピーキーすぎて扱えないのが現実
だから他言語にマウントを取るしか能がないわけ
Rustはtraitとかマクロとか抽象化プログラミング、メタプログラミングの機能がやたらと充実してるけど、逆にそれのせいでプログラミングしにくくなってるのでは？
レベルの高いプログラマーではないとうまく扱えないピーキーさがある
シンプルな言語仕様のGoで書かれた実用的なプログラムがやたらと多いのを考えるとそう言う傾向が見て取れるよね
だからここにいるアホRust信者はRustなんてピーキーすぎて扱えないのが現実
だから他言語にマウントを取るしか能がないわけ
564デフォルトの名無しさん
2022/08/16(火) 23:27:24.61ID:hzx8DWaB こいつRust信者の仮面を被ったアンチRust工作者だな
そうでもなければここまでアホレス垂れ流し続けられないよ
そうでもなければここまでアホレス垂れ流し続けられないよ
565デフォルトの名無しさん
2022/08/16(火) 23:36:57.97ID:ZeqQ1iXO566デフォルトの名無しさん
2022/08/17(水) 05:04:30.24ID:bVkA6pax567デフォルトの名無しさん
2022/08/17(水) 06:30:44.49ID:iOomOblS >>566
逆っぽい
色んなことがコンパイラにより自動化されているRustがオートマに相当かな
例としてヌルポ(事故)を避けることを考えてみると
(1)ヌルポを避ける機構を言語が提供していなくてプログラマーが手動で全て頑張らないといけない言語
(2)ヌルポを避ける機構を言語が提供してるけど適用必須でないためプログラマーが自分でその機構の利用を選択しなければならない言語
(3)ヌルポを避ける機構を言語が提供していて必ずその機構が用いられる言語
と3種類に分けた場合でもRustは自動適用の(3)だよね
他にもこのスレで既出の「データ競合回避」や「自動メモリ解放」なども同様
Rustはコンパイラが全て必ず適用してくれるからプログラマーの責任が激減してるよね
したがってRustがオートマに最も近いっぽい
逆っぽい
色んなことがコンパイラにより自動化されているRustがオートマに相当かな
例としてヌルポ(事故)を避けることを考えてみると
(1)ヌルポを避ける機構を言語が提供していなくてプログラマーが手動で全て頑張らないといけない言語
(2)ヌルポを避ける機構を言語が提供してるけど適用必須でないためプログラマーが自分でその機構の利用を選択しなければならない言語
(3)ヌルポを避ける機構を言語が提供していて必ずその機構が用いられる言語
と3種類に分けた場合でもRustは自動適用の(3)だよね
他にもこのスレで既出の「データ競合回避」や「自動メモリ解放」なども同様
Rustはコンパイラが全て必ず適用してくれるからプログラマーの責任が激減してるよね
したがってRustがオートマに最も近いっぽい
568デフォルトの名無しさん
2022/08/17(水) 06:38:31.18ID:tVto1F2t 良い物を作るだけで自動的に売れると思うのがオートマ
ゴリ押しするのがマニュアル
ゴリ押しするのがマニュアル
569デフォルトの名無しさん
2022/08/17(水) 07:32:06.74ID:qAPgSCZ7 GC言語使ってる人にとってGCがないRustがオートマなわけがないだろう
C++がマニュアルだとしたらRustはセミオートマだ
GC言語はオートマ
C++がマニュアルだとしたらRustはセミオートマだ
GC言語はオートマ
570デフォルトの名無しさん
2022/08/17(水) 07:51:45.43ID:05yQ5lPP >>569
GC言語もRustもメモリ自動解放サポートで同じだからそこはいいとして、
それらの言語の中でもぬるぽ問題やデータ競合問題などもRustはサポートしているから、
Rustはオートマ度が最も高い言語の一つではないかしら。
GC言語もRustもメモリ自動解放サポートで同じだからそこはいいとして、
それらの言語の中でもぬるぽ問題やデータ競合問題などもRustはサポートしているから、
Rustはオートマ度が最も高い言語の一つではないかしら。
571デフォルトの名無しさん
2022/08/17(水) 08:00:37.20ID:SLXSyyKd572デフォルトの名無しさん
2022/08/17(水) 08:03:19.44ID:/AaT26gR573デフォルトの名無しさん
2022/08/17(水) 08:19:18.07ID:xIPygSHI574デフォルトの名無しさん
2022/08/17(水) 08:34:23.74ID:SLXSyyKd >>573
バカで良いけれど、そんなの気にする必要もない要件もあるって事だよ。世の中何でもRustの機能を必要としているわけじゃないさ。
Pythonだと、ジャイアントロック掛けまくってるけれど、困らない事が多いという想定でしょう。
バカで良いけれど、そんなの気にする必要もない要件もあるって事だよ。世の中何でもRustの機能を必要としているわけじゃないさ。
Pythonだと、ジャイアントロック掛けまくってるけれど、困らない事が多いという想定でしょう。
575デフォルトの名無しさん
2022/08/17(水) 08:42:33.37ID:/AaT26gR >>573
考える必要が無いからオートマなんだろ。オートマ使いはギアチェンジとかエンストとかほとんど意識しない。
問題を回避するためにコンパイラの指示に従う必要のあるRustはオートマじゃない。やっぱり教官付きマニュアル教習車だな。
考える必要が無いからオートマなんだろ。オートマ使いはギアチェンジとかエンストとかほとんど意識しない。
問題を回避するためにコンパイラの指示に従う必要のあるRustはオートマじゃない。やっぱり教官付きマニュアル教習車だな。
576デフォルトの名無しさん
2022/08/17(水) 08:45:03.08ID:u0Nnvztf577デフォルトの名無しさん
2022/08/17(水) 09:13:39.86ID:qAPgSCZ7 >>573
並列処理を始めてやっと起きるのでは？
例えばNodeだとデータ競合は発生しないよ
シングルスレッドで行単位では処理が入れ替わらずawaitって書いてあるところ（コールバック単位）でスイッチングするから
競合状態はもちろん発生する、で、競合状態に関してはRustでも防ぐことは不可能
だからNode使ってる人にとってデータ競合はそもそも発生しないからその観点でRustに魅力を感じることはないよね
並列処理を始めてやっと起きるのでは？
例えばNodeだとデータ競合は発生しないよ
シングルスレッドで行単位では処理が入れ替わらずawaitって書いてあるところ（コールバック単位）でスイッチングするから
競合状態はもちろん発生する、で、競合状態に関してはRustでも防ぐことは不可能
だからNode使ってる人にとってデータ競合はそもそも発生しないからその観点でRustに魅力を感じることはないよね
578デフォルトの名無しさん
2022/08/17(水) 09:34:31.75ID:zZknHbxd >>575
その、問題を回避するためにコンパイラの指示に従う、のが正しい解決方法で合ってる。
例えば、ぬるぽ問題回避(Null安全)は、KotlinでもSwiftでもRustと同じく別の型とする対応策。
Null安全でないコードが書かれると、コンパイラにより型不一致エラーとなり、コンパイラの指示に従いプログラマーがコードを修整して解決。
このように、ぬるぽ問題回避にしても、データ競合回避にしても、自動対応は無理なので、コンパイラが静的に検知してエラーとするのが正しい解決方法。
型システムの強化により、様々な問題に対応できるようになっていく。
その、問題を回避するためにコンパイラの指示に従う、のが正しい解決方法で合ってる。
例えば、ぬるぽ問題回避(Null安全)は、KotlinでもSwiftでもRustと同じく別の型とする対応策。
Null安全でないコードが書かれると、コンパイラにより型不一致エラーとなり、コンパイラの指示に従いプログラマーがコードを修整して解決。
このように、ぬるぽ問題回避にしても、データ競合回避にしても、自動対応は無理なので、コンパイラが静的に検知してエラーとするのが正しい解決方法。
型システムの強化により、様々な問題に対応できるようになっていく。
579デフォルトの名無しさん
2022/08/17(水) 09:51:56.11ID:TMSqJNtq >>577
サーバーサイドをやってる周りではこういう状況
Node.jsはもちろん(Workerを除き)シングルスレッドで安全にasync/await並行処理できる
それだけで十分なところもあるけど次第にCPUコア活かして並列処理も加えて高速化したいところも増加中
その時にWorkerでは使い勝手の限界があるのはご存知と思う
すると今まで同様に安全にasync/await並行処理 ＋ 新たに並列処理を加えて高速化をできる環境を考えるとRustが筆頭候補
実際に移行したところも出てきているし少しずつサーバーサイドRust化の流れが今後主流になりそうな雰囲気
サーバーサイドをやってる周りではこういう状況
Node.jsはもちろん(Workerを除き)シングルスレッドで安全にasync/await並行処理できる
それだけで十分なところもあるけど次第にCPUコア活かして並列処理も加えて高速化したいところも増加中
その時にWorkerでは使い勝手の限界があるのはご存知と思う
すると今まで同様に安全にasync/await並行処理 ＋ 新たに並列処理を加えて高速化をできる環境を考えるとRustが筆頭候補
実際に移行したところも出てきているし少しずつサーバーサイドRust化の流れが今後主流になりそうな雰囲気
580デフォルトの名無しさん
2022/08/17(水) 11:15:55.18ID:8HFMEcaY581デフォルトの名無しさん
2022/08/17(水) 11:47:55.34ID:cnWCAZlk Rustはサーバーサイドでもやらないとこのまま消えて無くなるから必死なんだろ
582デフォルトの名無しさん
2022/08/17(水) 12:58:48.28ID:fQshOXYb >教官付きマニュアル教習車だな。
これは言い得て妙だな
これは言い得て妙だな
583デフォルトの名無しさん
2022/08/17(水) 13:05:23.96ID:hpgzuSC5 静的型付け言語は全てそのパターンだから
実行前にコンパイラに全てを静的にチェックしてもらい指導に従うパターンがプログラミング言語の最高峰なのではないかな
実行前にコンパイラに全てを静的にチェックしてもらい指導に従うパターンがプログラミング言語の最高峰なのではないかな
584デフォルトの名無しさん
2022/08/17(水) 14:13:12.92ID:9cI+CXMq 最高峰ww
585デフォルトの名無しさん
2022/08/17(水) 14:16:02.99ID:3noakHYk ろくに準備をせずに登頂を試みると命に関わります
586デフォルトの名無しさん
2022/08/17(水) 14:27:25.73ID:8HFMEcaY めんどくささでは最高峰だよなぁｗ
587デフォルトの名無しさん
2022/08/17(水) 14:52:45.44ID:+DmyoQ23588デフォルトの名無しさん
2022/08/17(水) 15:02:44.38ID:nGJKKwlR かまちょ！
589デフォルトの名無しさん
2022/08/17(水) 15:14:47.69ID:8HFMEcaY590デフォルトの名無しさん
2022/08/17(水) 15:39:54.22ID:tUbX57fg その件は昔からはっきり答えが出ている
まともにプログラミングするならば静的型付けが必須
動的型付けだと実行時にムダにデバッグ時間を奪われて効率が悪い
いずれそのことを学習すると動的型付け言語から静的型付け言語へ移っていく
典型的な例がJavaScript(動的型付け)からTypeScript(静的型付け)へ
まともにプログラミングするならば静的型付けが必須
動的型付けだと実行時にムダにデバッグ時間を奪われて効率が悪い
いずれそのことを学習すると動的型付け言語から静的型付け言語へ移っていく
典型的な例がJavaScript(動的型付け)からTypeScript(静的型付け)へ
591デフォルトの名無しさん
2022/08/17(水) 16:35:25.14ID:OH5RfCzZ 俺は型が無いとコードかけないな
メソッドの名前の一部しか覚えてなくてサジェスト機能に頼りまくってるわ
メソッドの名前の一部しか覚えてなくてサジェスト機能に頼りまくってるわ
592デフォルトの名無しさん
2022/08/17(水) 17:14:40.55ID:UcZjJMoG593デフォルトの名無しさん
2022/08/17(水) 17:44:11.47ID:8HFMEcaY >>592
逆じゃね？
むしろフロントエンドに型とかいらんだろｗ元々javascriptなのだし
JavaとかC#とかだとjsonをデコードする為にもクラス用意したりとか逆にめんどくさく感じるわ
ほぼ一人のプロジェクトでクライアント側はUnity(C#)とかだったりするから仕方なく用意しているが
管理画面(vue等)でフロントも書いてるけどjsのままで不便だと思った事すらないし
TypeScriptなんか導入する気にもならんｗ
逆じゃね？
むしろフロントエンドに型とかいらんだろｗ元々javascriptなのだし
JavaとかC#とかだとjsonをデコードする為にもクラス用意したりとか逆にめんどくさく感じるわ
ほぼ一人のプロジェクトでクライアント側はUnity(C#)とかだったりするから仕方なく用意しているが
管理画面(vue等)でフロントも書いてるけどjsのままで不便だと思った事すらないし
TypeScriptなんか導入する気にもならんｗ
594デフォルトの名無しさん
2022/08/17(水) 18:03:01.95ID:nsDziyoO >>593
一人でやってるからじゃね？
一人でやってるからじゃね？
595デフォルトの名無しさん
2022/08/17(水) 18:06:52.80ID:mUpHy2T2 状況に合わせて使う道具を変える判断力すら持ち合わせてないやつは自称プログラマーでも最底辺だからな
適性はないよ
適性はないよ
596デフォルトの名無しさん
2022/08/17(水) 18:09:47.20ID:YQ8B9Inh597デフォルトの名無しさん
2022/08/17(水) 18:29:38.04ID:UFtMHmKs このスレでRustなどを叩いている>>593氏ってやっぱりレベルがかなり低い人だったんだな
598デフォルトの名無しさん
2022/08/17(水) 18:30:00.14ID:UcZjJMoG599デフォルトの名無しさん
2022/08/17(水) 18:52:35.57ID:Lz3roYDy 動的型とは端的に言えば値に型情報が付属していることであり、おそらくお前らは何か誤解している。
型を指定しないことが動的だと思っているんじゃないか？
図星じゃないか？
型を指定しないことが動的だと思っているんじゃないか？
図星じゃないか？
600デフォルトの名無しさん
2022/08/17(水) 19:16:27.92ID:/AaT26gR 実行時の値とソースコードの変数の違いは重要だけど、この違いを意識しているプログラマーは少ないよね。
601デフォルトの名無しさん
2022/08/17(水) 19:28:56.47ID:rIjBJHpR 実行前にコンパイル時点で静的に型も確定する静的型付け言語がベストだな
602デフォルトの名無しさん
2022/08/17(水) 20:10:33.59ID:QLQjt20q >>572
Nimはダメだよ
例えばref objectな変数は初期化も何もされないからヌルポ状態となり実際にSIGSEGVで落ちる
もちろんNimでもRustｂﾆ同様のoptionｂgえばヌルポｂﾅきるけｂﾇ
Nimでは前述のようにoptionを使わないコードも許されるからヌルポが起きてしまう
Nimはダメだよ
例えばref objectな変数は初期化も何もされないからヌルポ状態となり実際にSIGSEGVで落ちる
もちろんNimでもRustｂﾆ同様のoptionｂgえばヌルポｂﾅきるけｂﾇ
Nimでは前述のようにoptionを使わないコードも許されるからヌルポが起きてしまう
603デフォルトの名無しさん
2022/08/17(水) 21:22:11.22ID:cjKd/U5p Kotlin Rust Swift ← Null安全な新世代言語
Go Nim ← Null安全ではない旧世代言語
Go Nim ← Null安全ではない旧世代言語
604デフォルトの名無しさん
2022/08/17(水) 21:32:11.18ID:daPCs1sI Swiftって将来性あんのかね
アップル依存大きすぎな時点で知れてると思うんだけど
アップル依存大きすぎな時点で知れてると思うんだけど
605デフォルトの名無しさん
2022/08/17(水) 22:14:45.59ID:NE7yPquC >>559
多くのcli コマンドが go, rust で再実装されつつあるのは perl, python, ruby のようなスクリプト言語から go, rust といったちょうどよいモダンさのあるコンパイル型言語への大きな流れがある気がしている。
多くのcli コマンドが go, rust で再実装されつつあるのは perl, python, ruby のようなスクリプト言語から go, rust といったちょうどよいモダンさのあるコンパイル型言語への大きな流れがある気がしている。
606デフォルトの名無しさん
2022/08/17(水) 23:47:09.64ID:tVto1F2t >>600
値と変数じゃなくて昔はデータ構造とアルゴリズムの違いを意識していた
どのような演算を想定しているかという型情報を
被演算子の側に付属させるというアイデア自体が
演算子と被演算子を一体化させ、両者を分けて考えない原因になった
値と変数じゃなくて昔はデータ構造とアルゴリズムの違いを意識していた
どのような演算を想定しているかという型情報を
被演算子の側に付属させるというアイデア自体が
演算子と被演算子を一体化させ、両者を分けて考えない原因になった
607デフォルトの名無しさん
2022/08/18(木) 08:11:22.29ID:YglC0db6 動的型付け言語のメリットてなんだ？
(習得が容易とか書き心地とかを除いて理論的なメリット)
(習得が容易とか書き心地とかを除いて理論的なメリット)
608デフォルトの名無しさん
2022/08/18(木) 08:38:35.77ID:SRglimcB609デフォルトの名無しさん
2022/08/18(木) 08:39:41.85ID:ywzuYu7m >>607
インスタンスの型判定を実際のインスタンスで行うことができるので、コードの適用範囲が広くなる。
C++を理解しているなら、dynamic castの適用事例を考えればいい。総称型で保管して具象型で使用するようなケースが代表的。
インスタンスの型判定を実際のインスタンスで行うことができるので、コードの適用範囲が広くなる。
C++を理解しているなら、dynamic castの適用事例を考えればいい。総称型で保管して具象型で使用するようなケースが代表的。
610デフォルトの名無しさん
2022/08/18(木) 09:15:09.69ID:X/mZUHYK611デフォルトの名無しさん
2022/08/18(木) 09:44:19.64ID:zAUamPod 実行時の型検査なんて、存在しないメンバにアクセスしようとしたらエラーとかオペランドが特定のデータ型でなければエラーといったルールを、演算子やオブジェクトの実装に組み込むだけだよ
ホストとの間で実行モデルやオブジェクトモデルを共有してるから楽勝
JITの場合もオブジェクトモデルは共有するから比較的簡単
ホストとの間で実行モデルやオブジェクトモデルを共有してるから楽勝
JITの場合もオブジェクトモデルは共有するから比較的簡単
612デフォルトの名無しさん
2022/08/18(木) 09:50:57.04ID:X/mZUHYK そんな言い方するなら静的型付け言語もコンパイル時にやるだけで似たようなもんだろ
613デフォルトの名無しさん
2022/08/18(木) 09:55:55.60ID:zAUamPod 全然違うよ
ホスト言語で直接実装すりゃいいだけだからな
JITの場合も極限のパフォーマンスを求める静的型とは違ってホスト言語で書かれたランタイムの呼び出しを多用するのが普通だから、
インタプリタと大差ないし徐々にランタイムを使わないように改良していくアプローチが採れる
ホスト言語で直接実装すりゃいいだけだからな
JITの場合も極限のパフォーマンスを求める静的型とは違ってホスト言語で書かれたランタイムの呼び出しを多用するのが普通だから、
インタプリタと大差ないし徐々にランタイムを使わないように改良していくアプローチが採れる
614デフォルトの名無しさん
2022/08/18(木) 10:05:05.63ID:X/mZUHYK >>613
型チェックとどこが違うのか具体的に書いて
あとホスト言語という謎用語使うならちゃんと定義してくれ
（ホスト言語自体はDSL界隈とかで使われてるけどコンパイラとかの文脈で使ってるの見たことない）
型チェックとどこが違うのか具体的に書いて
あとホスト言語という謎用語使うならちゃんと定義してくれ
（ホスト言語自体はDSL界隈とかで使われてるけどコンパイラとかの文脈で使ってるの見たことない）
615デフォルトの名無しさん
2022/08/18(木) 10:15:42.84ID:zAUamPod 事前に型検査をやろうとすると予め静的な型のモデルを厳密に定義しなきゃいけないでしょ？
616デフォルトの名無しさん
2022/08/18(木) 10:30:27.96ID:zAUamPod 途中書き込み失礼
一方で動的型の場合、実行時のオブジェクトモデルさえ定義されていれば実行時の検査が可能であり、静的な型モデルと実行時のオブジェクトモデルの両方を厳密に定義する必要がない。
平たく言えば、実装が仕様だ、みたいな進め方をすることが難しいわけだ
更に、リフレクションが可能な処理系の場合には静的型であっても実行時に型検査を行う必要があるよね。
一方で動的型の場合、実行時のオブジェクトモデルさえ定義されていれば実行時の検査が可能であり、静的な型モデルと実行時のオブジェクトモデルの両方を厳密に定義する必要がない。
平たく言えば、実装が仕様だ、みたいな進め方をすることが難しいわけだ
更に、リフレクションが可能な処理系の場合には静的型であっても実行時に型検査を行う必要があるよね。
617616
2022/08/18(木) 10:54:49.56ID:EMP5KmCe > 平たく言えば、実装が仕様だ、みたいな進め方をすることが難しいわけだ
は静的型の場合ね。念のため。
は静的型の場合ね。念のため。
618デフォルトの名無しさん
2022/08/18(木) 11:15:33.98ID:wupTTNap >>607
インタプリタのメリットは自分自身をコンパイルするコンパイラを作らないこと
言語は二つ以上になってしまうがそれでいい
他にもGCを実装する言語がGCに依存するんじゃないかとか
型情報を定義する言語がーとかいう問題に対する煩悩が消える
インタプリタのメリットは自分自身をコンパイルするコンパイラを作らないこと
言語は二つ以上になってしまうがそれでいい
他にもGCを実装する言語がGCに依存するんじゃないかとか
型情報を定義する言語がーとかいう問題に対する煩悩が消える
619デフォルトの名無しさん
2022/08/18(木) 11:54:36.40ID:u9P7LJR3620デフォルトの名無しさん
2022/08/18(木) 11:55:56.17ID:Qribcf4L 言語を作る側のメリットしかわかんねぇの？
言語を作る側じゃなく使う側のメリットを聞いてんだろ
言語を作る側じゃなく使う側のメリットを聞いてんだろ
621デフォルトの名無しさん
2022/08/18(木) 12:42:07.20ID:mMaPRsFU >>608
ツリーウォーク型のインタプリタなら楽だろうけど、速度出すにはJITとか考えないと行けないし、コンパイラ書くのと大差ない気がする
ツリーウォーク型のインタプリタなら楽だろうけど、速度出すにはJITとか考えないと行けないし、コンパイラ書くのと大差ない気がする
622デフォルトの名無しさん
2022/08/18(木) 12:57:08.67ID:ywzuYu7m >>620
具体的な実装をギリギリまで遅らせることができる＆設計が間違っていても無理やり嵌め込むことができる。
プロトタイピングとかライブラリ開発とかで楽できるし、リファクタリングで段階的に仕様を固めることができる。
最終的には静的型付けの方が堅牢になるけど、最初からミス無く設計するのは無理だから、開発初期は動的型付けの方が有利。
具体的な実装をギリギリまで遅らせることができる＆設計が間違っていても無理やり嵌め込むことができる。
プロトタイピングとかライブラリ開発とかで楽できるし、リファクタリングで段階的に仕様を固めることができる。
最終的には静的型付けの方が堅牢になるけど、最初からミス無く設計するのは無理だから、開発初期は動的型付けの方が有利。
623デフォルトの名無しさん
2022/08/18(木) 13:30:03.60ID:wupTTNap >>620
言語でも仕事でも持続可能性のためには作る側が儲かるぐらいがちょうどいい
言語でも仕事でも持続可能性のためには作る側が儲かるぐらいがちょうどいい
624デフォルトの名無しさん
2022/08/18(木) 13:42:10.72ID:u9P7LJR3625デフォルトの名無しさん
2022/08/18(木) 14:00:24.69ID:gIZ4t15q Juliaはここに入らんの？
626デフォルトの名無しさん
2022/08/18(木) 14:19:26.19ID:yhLXdudb ぬるぽ
627デフォルトの名無しさん
2022/08/18(木) 14:28:23.47ID:PTM9RcdX もちろんプログラマーや生成物実行者やサービス利用者にとっては静的型付け言語の方が大きく有利
プログラミングも静的型付け言語は支援が大きく楽だし実行時デバッグも減らせる
そして実行速度も静的型付け言語の方が速くできるため実行者やサービス利用者も時間の節約や応答性の良さを得られる
プログラミングも静的型付け言語は支援が大きく楽だし実行時デバッグも減らせる
そして実行速度も静的型付け言語の方が速くできるため実行者やサービス利用者も時間の節約や応答性の良さを得られる
628デフォルトの名無しさん
2022/08/18(木) 14:31:48.41ID:NacqCDdf629デフォルトの名無しさん
2022/08/18(木) 14:33:36.79ID:iuGFLMr5 >>627
使い分けができない人の典型的な言い訳ですね
使い分けができない人の典型的な言い訳ですね
630デフォルトの名無しさん
2022/08/18(木) 14:36:30.08ID:X/mZUHYK >>628
だからダメダメって言ってるのに横からアホみたいに絡んでくるなよ
だからダメダメって言ってるのに横からアホみたいに絡んでくるなよ
631デフォルトの名無しさん
2022/08/18(木) 15:54:24.58ID:bwUj40G0632デフォルトの名無しさん
2022/08/18(木) 16:45:13.83ID:X/mZUHYK はいはいw
633デフォルトの名無しさん
2022/08/18(木) 16:58:47.72ID:EY8RcqaI 小規模なプログラムを早く作りたいというときに
動的型付け言語は向いている
動的型付け言語は向いている
634デフォルトの名無しさん
2022/08/18(木) 17:26:35.30ID:wupTTNap main関数の型がいつも同じなのはシェルが静的型付けではないからだ
設定より規約
独自のユーザー定義型を設定しなくても使える
設定より規約
独自のユーザー定義型を設定しなくても使える
635デフォルトの名無しさん
2022/08/18(木) 18:13:32.09ID:BsTRP920 >>622
あえて突っ込んでみるが
>具体的な実装をギリギリまで遅らせることができる
to_foo()できるFooableなインスタンスを受け取る前提でBarを作るみたいなのは動的型付けでも静的型付けでも同じじゃない？
>設計が間違っていても無理やり嵌め込むことができる。
これも動的型付けでも静的方付けでも同じじゃない？
渡す型が間違ってるみたいなのは設計間違いというよりコーディングミスでしょ
あえて突っ込んでみるが
>具体的な実装をギリギリまで遅らせることができる
to_foo()できるFooableなインスタンスを受け取る前提でBarを作るみたいなのは動的型付けでも静的型付けでも同じじゃない？
>設計が間違っていても無理やり嵌め込むことができる。
これも動的型付けでも静的方付けでも同じじゃない？
渡す型が間違ってるみたいなのは設計間違いというよりコーディングミスでしょ
636デフォルトの名無しさん
2022/08/18(木) 18:32:21.72ID:yLDzsouG637デフォルトの名無しさん
2022/08/18(木) 19:10:46.93ID:74ku3J2B >>635
＞なインスタンスを受け取る前提
そういう前提を開発当初に決められなかったり、そもそも問題領域に対する知見が足りなくて手探りで開発を進めるたり。当然「前提」が間違っていることもある。
間違うことを前提に「とりあえず動くものを用意して情報収集しながら開発する」というプロトタイプ開発だと、静的型付けは設計が重すぎて使いづらい。そういうケースだと柔軟性の高い動的型付けの方が便利。
＞なインスタンスを受け取る前提
そういう前提を開発当初に決められなかったり、そもそも問題領域に対する知見が足りなくて手探りで開発を進めるたり。当然「前提」が間違っていることもある。
間違うことを前提に「とりあえず動くものを用意して情報収集しながら開発する」というプロトタイプ開発だと、静的型付けは設計が重すぎて使いづらい。そういうケースだと柔軟性の高い動的型付けの方が便利。
638デフォルトの名無しさん
2022/08/18(木) 20:34:52.46ID:kuToBQFh テスト書かないで書き散らすなら静的型はミスが生じにくい分本来的には有利だと思うけどね
ただ、静的型ってモデルとビューモデルみたいな似た型を複数作って左から右に渡すような設計をしがちだからコード量が増えやすいんだよね
静的型でも共通の型を使い回して重複を発生させないことはできるだろうけど、動的型と違って型が目に見えてしまうもんだから、
オプショナルな属性だらけの汚い型が目についてしまって、心理的に適切に型を使い分ける設計になりがち
ただ、静的型ってモデルとビューモデルみたいな似た型を複数作って左から右に渡すような設計をしがちだからコード量が増えやすいんだよね
静的型でも共通の型を使い回して重複を発生させないことはできるだろうけど、動的型と違って型が目に見えてしまうもんだから、
オプショナルな属性だらけの汚い型が目についてしまって、心理的に適切に型を使い分ける設計になりがち
639デフォルトの名無しさん
2022/08/18(木) 20:43:30.66ID:uPozsGij そもそもメンテをするつもりもテストをするつもりもない程度の用途なら、短いコードで完結に書けることが多い動的型言語は比較的有利そうだね
まあそういうときはなんでもいいから一番慣れてる言語を使えばええやんって感じだが
まあそういうときはなんでもいいから一番慣れてる言語を使えばええやんって感じだが
640デフォルトの名無しさん
2022/08/18(木) 20:59:53.63ID:VW7TsRc4 >>637
いや、それは型推論の無かった静的型言語を使ってた時代の話だよ。
今時の言語は型推論あるからコード書く分には動的型言語と遜色ない。
いくら動的型言語が柔軟だと言ったって想定と異なる型のデータで関数なりメソッドなり呼ばれれば、その部分は動かない。下手したらデータ破壊しながら処理進めてしまいかねん。
いや、それは型推論の無かった静的型言語を使ってた時代の話だよ。
今時の言語は型推論あるからコード書く分には動的型言語と遜色ない。
いくら動的型言語が柔軟だと言ったって想定と異なる型のデータで関数なりメソッドなり呼ばれれば、その部分は動かない。下手したらデータ破壊しながら処理進めてしまいかねん。
641デフォルトの名無しさん
2022/08/18(木) 21:02:31.69ID:4Dlj1ckV >>638
そのあたりの問題は最近の静的型付け言語は既に解決済みではないかな
そういう様々な異なる型に対して、横断的な共通の扱いをしたいならば、
例えばRustでは用途ごとに3通りの対応方法を提供しているよね
(1) ボディ付きenumによる複数の異種型の横断的な収容
(2) impl Traitによる複数の異種型の横断的な共通振る舞いとその静的モノモーフィゼーション
(3) dyn Traitによる複数の異種型の横断的な共通振る舞いとその動的ディスパッチ
そのあたりの問題は最近の静的型付け言語は既に解決済みではないかな
そういう様々な異なる型に対して、横断的な共通の扱いをしたいならば、
例えばRustでは用途ごとに3通りの対応方法を提供しているよね
(1) ボディ付きenumによる複数の異種型の横断的な収容
(2) impl Traitによる複数の異種型の横断的な共通振る舞いとその静的モノモーフィゼーション
(3) dyn Traitによる複数の異種型の横断的な共通振る舞いとその動的ディスパッチ
642デフォルトの名無しさん
2022/08/18(木) 21:10:33.58ID:ame2S//5 プロトタイプには動的型って一見もっともなんだけど
じゃあいつ本番開発に移行すんの？ってのは気になるな
結局ある程度動き始めたらそのままズルズル行っちゃうのでは？
それとも「今日から静的型で書き直すので一ヶ月開発止まります」とかやるの？
じゃあいつ本番開発に移行すんの？ってのは気になるな
結局ある程度動き始めたらそのままズルズル行っちゃうのでは？
それとも「今日から静的型で書き直すので一ヶ月開発止まります」とかやるの？
643デフォルトの名無しさん
2022/08/18(木) 21:10:45.17ID:kuToBQFh >>641
そんな小難しいことを最初から真面目に考えて設計しなければならない時点で遅いんだよ
そんな小難しいことを最初から真面目に考えて設計しなければならない時点で遅いんだよ
644デフォルトの名無しさん
2022/08/18(木) 21:13:42.36ID:pjyB7/7f 動的型だと素早く開発できるという話は品質を犠牲にすれば素早く開発できるという話と同じ匂いを感じる
645デフォルトの名無しさん
2022/08/18(木) 21:17:56.92ID:4Dlj1ckV646デフォルトの名無しさん
2022/08/18(木) 21:18:41.05ID:FZFlEvPV かといってサーバーサイドに静的なJavaを導入して安全か？と言われてもなぁｗ
PHPだから危険なのか？という話だし
そもそも関数で引数に型の指定があるない関わらず期待した型じゃないと普通動かないし
静的だから安全というのは何か間違ってる気がするわ
PHPだから危険なのか？という話だし
そもそも関数で引数に型の指定があるない関わらず期待した型じゃないと普通動かないし
静的だから安全というのは何か間違ってる気がするわ
647デフォルトの名無しさん
2022/08/18(木) 21:24:02.04ID:zSwNEg3i >>637
前提が間違ってた場合の修正範囲に
動的型付けと静的型付けで顕著な違いが出る？
出るならそれを具体的に説明してよ
できれば簡単な擬似コードとかで
柔軟性が高いとか設計が重いとか言うだけだと説得力が乏しい
前提が間違ってた場合の修正範囲に
動的型付けと静的型付けで顕著な違いが出る？
出るならそれを具体的に説明してよ
できれば簡単な擬似コードとかで
柔軟性が高いとか設計が重いとか言うだけだと説得力が乏しい
648デフォルトの名無しさん
2022/08/18(木) 21:25:00.81ID:yMU9W3g1649デフォルトの名無しさん
2022/08/18(木) 21:25:37.80ID:kuToBQFh650デフォルトの名無しさん
2022/08/18(木) 21:26:20.58ID:4Dlj1ckV >>646
そのあたりも最近の静的型付け言語が対応しているでしょう
例えばRustならば引数に対して型指定ではなくtrait指定にできるし
その具体化解決は静的にも動的にも可能だし
もちろんいずれも安全に適用できることをRustでは保証される
そのあたりも最近の静的型付け言語が対応しているでしょう
例えばRustならば引数に対して型指定ではなくtrait指定にできるし
その具体化解決は静的にも動的にも可能だし
もちろんいずれも安全に適用できることをRustでは保証される
651デフォルトの名無しさん
2022/08/18(木) 21:43:21.22ID:mZ+fH4d1652デフォルトの名無しさん
2022/08/18(木) 21:43:46.51ID:vUREPivo653デフォルトの名無しさん
2022/08/18(木) 21:48:40.33ID:rKyKXmu0654デフォルトの名無しさん
2022/08/18(木) 21:57:29.78ID:3gZlWdNz655デフォルトの名無しさん
2022/08/18(木) 22:02:54.58ID:UNnRVh9z >>648
ぶっちゃけないな
型の想定が違ってるのにそれらしく動いて
かつテストでも発見できないバグで
かつ調査が難解となると相当にレアでしょ
それに定義してる型とあっているからと言って
ドメインエラーを常に拾えるわけじゃない
ぶっちゃけないな
型の想定が違ってるのにそれらしく動いて
かつテストでも発見できないバグで
かつ調査が難解となると相当にレアでしょ
それに定義してる型とあっているからと言って
ドメインエラーを常に拾えるわけじゃない
656デフォルトの名無しさん
2022/08/18(木) 22:08:16.63ID:sNPBcISa >>654
猫を電子レンジに入れて本番で実行するような開発者のいるプロジェクトなら
動的型付け言語に比べたら静的型付け言語のほうがリスクは低いだろうね
ただそういう開発者を排除するほうが遥かに安全性が高いと思うよ
猫を電子レンジに入れて本番で実行するような開発者のいるプロジェクトなら
動的型付け言語に比べたら静的型付け言語のほうがリスクは低いだろうね
ただそういう開発者を排除するほうが遥かに安全性が高いと思うよ
657デフォルトの名無しさん
2022/08/18(木) 22:11:31.85ID:i8FqLiOp 静的型付け不要って主張してるのはPHPおじさんしかいないようだけど
何でこのスレにいるのかわからん
何でこのスレにいるのかわからん
658デフォルトの名無しさん
2022/08/18(木) 22:13:54.84ID:FZFlEvPV659デフォルトの名無しさん
2022/08/18(木) 22:14:06.50ID:rKyKXmu0 類は友を呼ぶ
660デフォルトの名無しさん
2022/08/18(木) 22:19:32.70ID:yMU9W3g1 >>655
テストで担保というのが手間でしょ
カバーできてなくて本番のランタイムで
エラーを経験してことないのはよっぽど
丁寧に書いているか大してもの作ってないかの
どっちかだね
あと関係ないドメインエラーとか待ちだすのは
詭弁論破の練習？
テストで担保というのが手間でしょ
カバーできてなくて本番のランタイムで
エラーを経験してことないのはよっぽど
丁寧に書いているか大してもの作ってないかの
どっちかだね
あと関係ないドメインエラーとか待ちだすのは
詭弁論破の練習？
661デフォルトの名無しさん
2022/08/18(木) 22:45:49.60ID:VW7TsRc4 >>656
で、そういう人を排除できてんの？
で、そういう人を排除できてんの？
662デフォルトの名無しさん
2022/08/18(木) 22:48:29.89ID:VW7TsRc4 >>655
＞それに定義してる型とあっているからと言って
＞ドメインエラーを常に拾えるわけじゃない
0か100の世界線の人ですか？
エラーは早い段階でわかったほうがいいというのは世界の常識だけど、お前の世界線では違うみたいだな。
＞それに定義してる型とあっているからと言って
＞ドメインエラーを常に拾えるわけじゃない
0か100の世界線の人ですか？
エラーは早い段階でわかったほうがいいというのは世界の常識だけど、お前の世界線では違うみたいだな。
663デフォルトの名無しさん
2022/08/18(木) 22:56:27.19ID:4eWuEs9Z 猫とか車とか飯とか脳みそOOPかよ
お前らのしょうもない例え話は実害があるから本当迷惑なんだよ
お前らのしょうもない例え話は実害があるから本当迷惑なんだよ
664デフォルトの名無しさん
2022/08/18(木) 23:30:39.35ID:eFgxNJYT >>660
「あーそれなら確かに静的型付けにしてたら有利だね」
って言う現実的なコード例出してみてよ
ドメインエラーってのは
文字列を期待してるところに数値を渡したり
注文番号を期待してるところに配送番号を渡したり
First Nameを期待してるところにLast Nameを渡したりした状況のこと
「あーそれなら確かに静的型付けにしてたら有利だね」
って言う現実的なコード例出してみてよ
ドメインエラーってのは
文字列を期待してるところに数値を渡したり
注文番号を期待してるところに配送番号を渡したり
First Nameを期待してるところにLast Nameを渡したりした状況のこと
665デフォルトの名無しさん
2022/08/18(木) 23:36:33.83ID:RTRtwr2z666デフォルトの名無しさん
2022/08/18(木) 23:40:19.24ID:XhNJQXKP667デフォルトの名無しさん
2022/08/18(木) 23:42:51.05ID:yMU9W3g1668デフォルトの名無しさん
2022/08/18(木) 23:52:50.33ID:R+uszVYm669デフォルトの名無しさん
2022/08/19(金) 00:09:50.57ID:aSCRajpd >>666
FirstNameとLastNameを間違えるのはプログラミング言語やその型付け方法と関係ない話
そして静的型付け言語が不利になる話でもない
それにより何を主張したいのか？
もし本当に厳格に区別する必要があるならば各々を扱う専用型を設ければよい
そうせずに両方を文字列型で扱っても、変数名、フィールド／メンバー名、関数／メソッド名などの名付けを分ければ互いに入れ違いを避けられる
FirstNameとLastNameを間違えるのはプログラミング言語やその型付け方法と関係ない話
そして静的型付け言語が不利になる話でもない
それにより何を主張したいのか？
もし本当に厳格に区別する必要があるならば各々を扱う専用型を設ければよい
そうせずに両方を文字列型で扱っても、変数名、フィールド／メンバー名、関数／メソッド名などの名付けを分ければ互いに入れ違いを避けられる
670デフォルトの名無しさん
2022/08/19(金) 00:12:18.59ID:0E/6U7Rf671デフォルトの名無しさん
2022/08/19(金) 00:32:53.46ID:QXliTxmo ドメインエラーとか型付けと関係ない話持ち出してきてるのは何なん？
型が何なのかわからん奴なんだろうな。そりゃ型付きが面倒・邪魔に感じるだろうよ。
型が何なのかわからん奴なんだろうな。そりゃ型付きが面倒・邪魔に感じるだろうよ。
672デフォルトの名無しさん
2022/08/19(金) 00:40:23.18ID:Djh9jYCC KEИTAωωω
673デフォルトの名無しさん
2022/08/19(金) 00:45:33.75ID:I3mMZROB 変数に型がないRubyとかでも、ドメインモデリングするならバリューオブジェクトのクラスも作るし、
変数に型がある言語でもメンテの必要があるアプリケーションならテストコードは必須だろ
どっちがどういいかはトレードオフがあるだけ
変数に型がある言語でもメンテの必要があるアプリケーションならテストコードは必須だろ
どっちがどういいかはトレードオフがあるだけ
674デフォルトの名無しさん
2022/08/19(金) 07:54:59.22ID:Ue9BSEu6 静的型であっても型推論なら姓と名の型をそれぞれa, bとして
どっちもstringと確定するまではaとbは区別される
aとbが入れかわるコードが紛れ込んでいたらstring確定しなくてもa=bは確定
どっちもstringと確定するまではaとbは区別される
aとbが入れかわるコードが紛れ込んでいたらstring確定しなくてもa=bは確定
675デフォルトの名無しさん
2022/08/19(金) 08:02:21.75ID:QtzKKzJh そもそも、ここに書き込んでるような人は、意識高い人だから、自分を基準に考えてはダメでは？
676デフォルトの名無しさん
2022/08/19(金) 08:09:54.91ID:slQGFe9J スレタイにある次世代言語は全て静的型付け言語
静的型付け言語が圧倒的に優れているため全てがそうなっている
動的型付け言語には次世代言語が存在しない
静的型付け言語が圧倒的に優れているため全てがそうなっている
動的型付け言語には次世代言語が存在しない
677デフォルトの名無しさん
2022/08/19(金) 08:39:00.86ID:xzucV8hS >>647
Visitorパターンみたいな処理をする時かね。静的型付けだと型を識別するためにacceptが必要だけど、動的型付けなら動的に型を判定することで手を抜ける。
まぁ、そもそも静的型付け言語も動的な型判定をある程度取り込んでいるからなぁ。パターンマッチとか。
型判別可能な共用体を使える静的型付け言語なら、上手いこと動的に判定する範囲を制限できる。
けど、そういう言語てあったっけ？
Visitorパターンみたいな処理をする時かね。静的型付けだと型を識別するためにacceptが必要だけど、動的型付けなら動的に型を判定することで手を抜ける。
まぁ、そもそも静的型付け言語も動的な型判定をある程度取り込んでいるからなぁ。パターンマッチとか。
型判別可能な共用体を使える静的型付け言語なら、上手いこと動的に判定する範囲を制限できる。
けど、そういう言語てあったっけ？
678デフォルトの名無しさん
2022/08/19(金) 08:54:53.36ID:51hioa9S679デフォルトの名無しさん
2022/08/19(金) 09:24:26.81ID:9PLRQWOj 今回セレクトされてないけどElixirとJuliaは動的型付けだね
Elixirはerlangの系譜だから特にこだわりがないかもしれないがJuliaが動的型付けなのは示唆的に思える
Elixirはerlangの系譜だから特にこだわりがないかもしれないがJuliaが動的型付けなのは示唆的に思える
680デフォルトの名無しさん
2022/08/19(金) 10:07:48.19ID:Qq/sBFnc juliaが目指したのがpythonの置き換えだからでしょ。
681デフォルトの名無しさん
2022/08/19(金) 10:24:36.76ID:2gSW30An Juliaは少量のコードで大量の計算をする言語だからJITに無茶苦茶時間かけても大して問題にならないし、
そもそも数値計算で扱う型って整数と浮動小数点数とその配列が殆どで、型を厳密に扱う必要性が薄い
同様にFORTRANなんかも型は緩めだよ
そもそも数値計算で扱う型って整数と浮動小数点数とその配列が殆どで、型を厳密に扱う必要性が薄い
同様にFORTRANなんかも型は緩めだよ
682デフォルトの名無しさん
2022/08/19(金) 11:40:00.25ID:Qq/sBFnc 型というかテンソルのshapeとかは気にするけどね。
ただ型というよりもうちょっと具体的というかレイヤーが低いとこでの合わせって感じではある。
ただ型というよりもうちょっと具体的というかレイヤーが低いとこでの合わせって感じではある。
683デフォルトの名無しさん
2022/08/19(金) 11:47:47.45ID:iXvbHE7r 行列の大きさとかを型で指定したいと思うことはあるけどIdrisにあるような依存型が必要になるのかな
ちゃんと勉強してないからわからんw
ちゃんと勉強してないからわからんw
684デフォルトの名無しさん
2022/08/19(金) 12:07:38.97ID:xzucV8hS >>678
ボディ付きenumというのはF#の判別共用体のことかしらん。Haskellだと直和型かね。
ボディ付きenumというのはF#の判別共用体のことかしらん。Haskellだと直和型かね。
685デフォルトの名無しさん
2022/08/19(金) 14:15:06.23ID:F2zWUaSx686デフォルトの名無しさん
2022/08/19(金) 18:07:04.50ID:jOBplE6P Rustはデストラクタ内のエラーは無視される実装が多いので、
IO絡みのデータ構造はdropされる前にflushなりsync_allなり呼び出さないけないが、忘れられがちで誤ってプログラムが世に溢れている
このあたり良い感じに処理してくれる安心なシステムプログラミング向け言語ってありますか？
IO絡みのデータ構造はdropされる前にflushなりsync_allなり呼び出さないけないが、忘れられがちで誤ってプログラムが世に溢れている
このあたり良い感じに処理してくれる安心なシステムプログラミング向け言語ってありますか？
687デフォルトの名無しさん
2022/08/19(金) 18:15:52.02ID:J75ESMlr いい感じってなに
688デフォルトの名無しさん
2022/08/19(金) 18:39:22.66ID:EVfb4y4d RustはC++の3倍速い。
689デフォルトの名無しさん
2022/08/19(金) 19:04:29.00ID:jOBplE6P >>687
Rustベースで考えるならスコープ終端でのdropまでに特定の関数を呼び出していない場合コンパイルエラーにしてくれるようなものを想像している
標準ライブラリやサードパーティーライブラリもこのルールに従って作られていてほしい
?で関数の途中で抜けた場合はエラーにしない
Rustベースで考えるならスコープ終端でのdropまでに特定の関数を呼び出していない場合コンパイルエラーにしてくれるようなものを想像している
標準ライブラリやサードパーティーライブラリもこのルールに従って作られていてほしい
?で関数の途中で抜けた場合はエラーにしない
690デフォルトの名無しさん
2022/08/19(金) 19:10:51.99ID:J75ESMlr691デフォルトの名無しさん
2022/08/19(金) 19:20:17.50ID:jOBplE6P >>690
それはFile等従来の構造体でもやっている
dropの中でエラーが発生した場合にpanicくらいしか呼び出し元に伝える手段がないのが問題
標準ライブラリでは単にエラーを無視する実装になっていて、他のライブラリも多くは同じだと思う
それはFile等従来の構造体でもやっている
dropの中でエラーが発生した場合にpanicくらいしか呼び出し元に伝える手段がないのが問題
標準ライブラリでは単にエラーを無視する実装になっていて、他のライブラリも多くは同じだと思う
692デフォルトの名無しさん
2022/08/19(金) 19:34:55.23ID:J75ESMlr > dropの中でエラーが発生した場合にpanic
そっか
つらいね
そっか
つらいね
693デフォルトの名無しさん
2022/08/19(金) 19:37:53.86ID:CKALhjuS Rustプログラマはすぐにpanicに頼る
アホなんだろうなと
アホなんだろうなと
694デフォルトの名無しさん
2022/08/19(金) 19:39:05.15ID:VXXXJYAW695デフォルトの名無しさん
2022/08/19(金) 20:02:15.51ID:/KG0lVfm696デフォルトの名無しさん
2022/08/19(金) 20:23:10.52ID:F2zWUaSx697デフォルトの名無しさん
2022/08/19(金) 20:55:29.37ID:v6FNs4oE コンパイルエラーにするためにはどの経路を通っても終了処理を経由すると解釈できなくてはならないけどそれってあまり簡単ではなくないか
698デフォルトの名無しさん
2022/08/19(金) 22:59:39.17ID:Ue9BSEu6 dropの呼び出し元ではなく
JoinHandle::joinの呼び出し元に結果を伝えればいいんでしょ
実際、panicの引数はjoinの戻り値になる
JoinHandle::joinの呼び出し元に結果を伝えればいいんでしょ
実際、panicの引数はjoinの戻り値になる
699デフォルトの名無しさん
2022/08/19(金) 23:12:28.82ID:4ESWFAwS >>689
自分でcontext manager的なものを作るのがいいと思う
flush以前にエラーが発生してる場合にflushすべきかどうかは
アプリロジックなのでコンパイルエラーにするのは何か違う気がする
自分でcontext manager的なものを作るのがいいと思う
flush以前にエラーが発生してる場合にflushすべきかどうかは
アプリロジックなのでコンパイルエラーにするのは何か違う気がする
700デフォルトの名無しさん
2022/08/20(土) 01:26:15.59ID:O8Vd08Ya701デフォルトの名無しさん
2022/08/20(土) 03:52:49.34ID:fWT+hW9e >>695
その通りで原則drop内でエラーが発生しうる処理はやらせるべきではないよね
だからエラー発生しうる処理がdropに至るまでに呼び出されているかコンパイル時に検知できると良い
>>697
プログラムの実行パス内で値がmoveされたか否かの解析が現状できているので、それと同じ仕組みでできるのではないかな
>>698
マルチスレッドならそれでも良いけど、単なるIOで必ずスレッドなりタスクなり生成させるのはよろしくない
catch_unwindでも良いがあらゆるpanicをせき止めてしまうのはオーバーキルすぎる
>>699
そういうことではなくて、drop内でエラーが起きた場合の話を気にしている
flushを呼び忘れてスコープ終端に到達してしまった場合ね
BufWriterなんかだと書き込みデータ量が少ない場合にwrite(2)が一度も呼び出されないままdropが呼び出されて、
そこで初めてwriteしようとしてエラー検出されることがある
BufWriterのドキュメントにはdrop前にflush呼ぶようにとは書いてあるが、プログラマが気をつけるのではなくできる限り機械的に検知できるようにしたいよね
その通りで原則drop内でエラーが発生しうる処理はやらせるべきではないよね
だからエラー発生しうる処理がdropに至るまでに呼び出されているかコンパイル時に検知できると良い
>>697
プログラムの実行パス内で値がmoveされたか否かの解析が現状できているので、それと同じ仕組みでできるのではないかな
>>698
マルチスレッドならそれでも良いけど、単なるIOで必ずスレッドなりタスクなり生成させるのはよろしくない
catch_unwindでも良いがあらゆるpanicをせき止めてしまうのはオーバーキルすぎる
>>699
そういうことではなくて、drop内でエラーが起きた場合の話を気にしている
flushを呼び忘れてスコープ終端に到達してしまった場合ね
BufWriterなんかだと書き込みデータ量が少ない場合にwrite(2)が一度も呼び出されないままdropが呼び出されて、
そこで初めてwriteしようとしてエラー検出されることがある
BufWriterのドキュメントにはdrop前にflush呼ぶようにとは書いてあるが、プログラマが気をつけるのではなくできる限り機械的に検知できるようにしたいよね
702デフォルトの名無しさん
2022/08/20(土) 04:00:19.70ID:fWT+hW9e >>700
コンパイル時にIOエラーに対処せよなんて話はしてないよ
そもそもコンパイル時にwrite(2)が呼び出されないんだからそのエラーに対処できるはずもない
drop内でエラーが発生しても検知できないから、dropの前にflushなどの呼び出しを強制できないの？という話
コンパイル時にIOエラーに対処せよなんて話はしてないよ
そもそもコンパイル時にwrite(2)が呼び出されないんだからそのエラーに対処できるはずもない
drop内でエラーが発生しても検知できないから、dropの前にflushなどの呼び出しを強制できないの？という話
703デフォルトの名無しさん
2022/08/20(土) 05:07:56.91ID:O8Vd08Ya704デフォルトの名無しさん
2022/08/20(土) 07:41:29.18ID:Z3gHF10K 論理的にモノを考えられるヤツは４回も打たない
705デフォルトの名無しさん
2022/08/20(土) 09:18:15.53ID:LHlXjeki 医療従事者とか高齢者施設従業員とか正規の4回目来てるんですよ
706デフォルトの名無しさん
2022/08/20(土) 10:31:20.74ID:s9pWuoyY >>701
>そういうことではなくて、drop内でエラーが起きた場合の話を気にしている
わかってるよ
drop前に確実にflushが呼ばれるようにしてflushした場合のエラーをハンドリングしたいなら
context managerを自作するのがいいって話
buffer.len()をチェックしてcompile_error!でエラーにするようなAPIも作れなくは無いかもしれないけど
それをやる場合にもBufWriterへの一連操作をラップしたcontext manager的なのを作ることになるので
エラーにするんじゃなくてflushしてあげたほうが親切
>そういうことではなくて、drop内でエラーが起きた場合の話を気にしている
わかってるよ
drop前に確実にflushが呼ばれるようにしてflushした場合のエラーをハンドリングしたいなら
context managerを自作するのがいいって話
buffer.len()をチェックしてcompile_error!でエラーにするようなAPIも作れなくは無いかもしれないけど
それをやる場合にもBufWriterへの一連操作をラップしたcontext manager的なのを作ることになるので
エラーにするんじゃなくてflushしてあげたほうが親切
707デフォルトの名無しさん
2022/08/20(土) 11:15:29.57ID:U3OCGo2f なにこれ
ワクチン接種証明書の例え話が役に立つという寓話なのか
fn hoge(&mut self) -> flush証明書 {
flush証明書::new(self.file)
}
ワクチン接種証明書の例え話が役に立つという寓話なのか
fn hoge(&mut self) -> flush証明書 {
flush証明書::new(self.file)
}
708デフォルトの名無しさん
2022/08/20(土) 14:05:39.10ID:icDL1eXq709デフォルトの名無しさん
2022/08/20(土) 14:47:10.43ID: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)
}
確かにこれで解決するケースも多いね
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)
}
確かにこれで解決するケースも多いね
710デフォルトの名無しさん
2022/08/20(土) 15:11:47.48ID:icDL1eXq >>709
そういう単純な対応は他言語含めてよくあるパターンだが狭い範囲しかカバーできない欠点がある
例えば複数のファイルなどを順序前後して扱うと破綻
その観点の専用クロージャとなっているためそれ以外からの処理を巻き込みたい時にも破綻
ファイルディスクリプタを保持して戻りいつ解放かすぐ決定しない場合も破綻
並行並列化する時も破綻
そういう単純な対応は他言語含めてよくあるパターンだが狭い範囲しかカバーできない欠点がある
例えば複数のファイルなどを順序前後して扱うと破綻
その観点の専用クロージャとなっているためそれ以外からの処理を巻き込みたい時にも破綻
ファイルディスクリプタを保持して戻りいつ解放かすぐ決定しない場合も破綻
並行並列化する時も破綻
711デフォルトの名無しさん
2022/08/20(土) 15:25:13.28ID:45hIb17g >>709
こういっては失礼かもしれないけど、なんて汚い実装だ....
こういっては失礼かもしれないけど、なんて汚い実装だ....
712デフォルトの名無しさん
2022/08/20(土) 15:32:14.61ID:fWT+hW9e713デフォルトの名無しさん
2022/08/20(土) 16:19:57.30ID:v+6xr1g0 >>712
Rustスレで半年前に出ている以下のアプローチはどう？
他の言語では無理だけどRustならば所有権の行方を静的に解析してコンパイラが持っているため
https://mevius.5ch.net/test/read.cgi/tech/1636247099/700
＞ コンパイラは解析してdropさせるべき位置を把握しているから
＞ そこへ至る全ての経路上で例えばFinalize trait実装型はそのメソッドfinalize()を呼んでいないとコンパイルエラーとなる
＞ というような制約をするFinalize trait
Rustスレで半年前に出ている以下のアプローチはどう？
他の言語では無理だけどRustならば所有権の行方を静的に解析してコンパイラが持っているため
https://mevius.5ch.net/test/read.cgi/tech/1636247099/700
＞ コンパイラは解析してdropさせるべき位置を把握しているから
＞ そこへ至る全ての経路上で例えばFinalize trait実装型はそのメソッドfinalize()を呼んでいないとコンパイルエラーとなる
＞ というような制約をするFinalize trait
714デフォルトの名無しさん
2022/08/20(土) 16:55:09.50ID:fWT+hW9e715デフォルトの名無しさん
2022/08/20(土) 18:48:46.98ID:s9pWuoyY >>709
そう、そういうイメージ
FileManager的なstructを定義してnewするときに内部でFile::createして持っておいて
withでクロージャを受け取るようにするとネストしたりしやすい気がする
buffer.len()とcompile_error!マクロでどうにかする方法は無理そうだった
あとは明示的flush未実行の型と実行済みの型とをそれぞれ作って
一連のI/O処理の戻り値をflush実行済みの型にしておくことで
flush忘れたらコンパイルエラーにするという方法ならできそう
面倒くさいけど
そう、そういうイメージ
FileManager的なstructを定義してnewするときに内部でFile::createして持っておいて
withでクロージャを受け取るようにするとネストしたりしやすい気がする
buffer.len()とcompile_error!マクロでどうにかする方法は無理そうだった
あとは明示的flush未実行の型と実行済みの型とをそれぞれ作って
一連のI/O処理の戻り値をflush実行済みの型にしておくことで
flush忘れたらコンパイルエラーにするという方法ならできそう
面倒くさいけど
716デフォルトの名無しさん
2022/08/20(土) 19:18:04.66ID:fWT+hW9e >>715
後半のアイディアについてはコンパイルエラーにするのは難しそうだね
dropの呼び出しを禁止したりコンパイルエラーにしたりする方法は多分ないと思う
リンク時エラーにするアイデアはあるみたいだけど、ちとやり過ぎな感がある
https://mevius.5ch.net/test/read.cgi/tech/1636247099/695
後半のアイディアについてはコンパイルエラーにするのは難しそうだね
dropの呼び出しを禁止したりコンパイルエラーにしたりする方法は多分ないと思う
リンク時エラーにするアイデアはあるみたいだけど、ちとやり過ぎな感がある
https://mevius.5ch.net/test/read.cgi/tech/1636247099/695
717デフォルトの名無しさん
2022/08/20(土) 21:47:48.47ID:Nnwhfgo3 リソース確保、開放といった共通化できる操作はテンプレート化したいが、そのために真にやりたい操作をクロージャや関数にして一段ネストを深くしてしまうのがなんか違う気がするんだよなぁ。
718デフォルトの名無しさん
2022/08/20(土) 21:56:02.14ID:L2ho5Ecd システムプログラミングじゃそれが本質的に指摘すべきことなんだから仕方ないだろ。
719デフォルトの名無しさん
2022/08/20(土) 22:17:19.61ID:INTsXp8j >>713のやり方ならば
そのような対応も不要でプログラムの構造も変えずに済むし
関数から返したり長生きしてもよいし
デストラクタでエラーが起きうる型に適用しておくだけでよく
利用側プログラムに他の付加コードは不要だから理想的にみえる
そのような対応も不要でプログラムの構造も変えずに済むし
関数から返したり長生きしてもよいし
デストラクタでエラーが起きうる型に適用しておくだけでよく
利用側プログラムに他の付加コードは不要だから理想的にみえる
720デフォルトの名無しさん
2022/08/20(土) 22:34:29.93ID:Nnwhfgo3 >>719
特定条件のときだけ開放処理が行われるみたいな分岐があるケースとか考え出すと難しくないかな。
まだ finalize してなければ finalize するみたいな処理を Rust が決定したdrop位置の直前に書かせるという制約を課すだけでいいのか？
特定条件のときだけ開放処理が行われるみたいな分岐があるケースとか考え出すと難しくないかな。
まだ finalize してなければ finalize するみたいな処理を Rust が決定したdrop位置の直前に書かせるという制約を課すだけでいいのか？
721デフォルトの名無しさん
2022/08/20(土) 23:34:50.48ID:INTsXp8j722デフォルトの名無しさん
2022/08/21(日) 00:02:05.58ID:nsTQcirJ >>713は実現不可能だよ
723デフォルトの名無しさん
2022/08/21(日) 00:50:42.36ID:lVDdCtQC724デフォルトの名無しさん
2022/08/21(日) 01:16:56.45ID:WZRwYPWF こういう時は自前主義の方が冷静
自前でできないことを期待するのは虫が良過ぎる
自前でできないことを期待するのは虫が良過ぎる
725デフォルトの名無しさん
2022/08/21(日) 02:47:44.56ID:3Twjt0yr 絵に描いた餅はおいしいですか？
726デフォルトの名無しさん
2022/08/21(日) 05:02:05.10ID:3JIuIXQv727デフォルトの名無しさん
2022/08/21(日) 05:25:55.50ID:s4gkGr9U Rustならば現状のコンパイラで実現できる
finalize()を呼び忘れていたらコンパイルエラーとすることが可能
finalize()を呼び忘れていたらコンパイルエラーとすることが可能
728デフォルトの名無しさん
2022/08/21(日) 09:26:43.80ID:WZRwYPWF 他人の現状よりも
自前でできそうな願望がいい
自前でできそうな願望がいい
729デフォルトの名無しさん
2022/08/21(日) 10:53:20.77ID:sMoAQNMJ >>721,723
「つまり」の前後の論理が全くつながってない
「つまり」の前後の論理が全くつながってない
730デフォルトの名無しさん
2022/08/21(日) 11:04:13.82ID:E81JiIrb つまり
絵にすらなってない餅
絵にすらなってない餅
731デフォルトの名無しさん
2022/08/21(日) 11:37:20.10ID:smg3n+sN つまり霊感商法
732デフォルトの名無しさん
2022/08/21(日) 12:28:30.42ID:U3pRzeag 容易と言い切るなら実装見せて欲しいな
733デフォルトの名無しさん
2022/08/21(日) 13:05:23.69ID:cZmfpBgr つまり複製おじさん論法
734デフォルトの名無しさん
2022/08/21(日) 15:07:41.13ID:ryFNR8Ig つまり「募ってはいるが募集はしていない」的な話？
735デフォルトの名無しさん
2022/08/21(日) 16:22:57.49ID:DLZoHpre つまり
現状のコンパイラで容易に実現できるが
コンパイラに手を加えずに実現できるわけではない
ということでしょw
現状のコンパイラで容易に実現できるが
コンパイラに手を加えずに実現できるわけではない
ということでしょw
736デフォルトの名無しさん
2022/08/21(日) 17:39:47.32ID:3JIuIXQv737デフォルトの名無しさん
2022/08/21(日) 18:17:26.66ID:TCpdMLkc >>735
「現状のコンパイラで実現できる」
というのは
「現状のコンパイラ(の機能を活用してfinalize()内以外でdrop()呼び出すコードを必要としたらコンパイルエラーとする新機能をコンパイラに加えるだけ)で実現できる」
という意味なんでしょw
「現状のコンパイラで実現できる」
というのは
「現状のコンパイラ(の機能を活用してfinalize()内以外でdrop()呼び出すコードを必要としたらコンパイルエラーとする新機能をコンパイラに加えるだけ)で実現できる」
という意味なんでしょw
738デフォルトの名無しさん
2022/08/21(日) 19:08:55.38ID:FqN0DP7E 次世代言語の話だから、現行言語をもとに「原理的には可能」で議論も悪かないと思うけどね。
739デフォルトの名無しさん
2022/08/21(日) 19:35:37.95ID:lf3rkmkM 悪くはないがコンパイラに手を加える必要があるならそう言わんといかんわな。
しょーもないわかりやすいプライド見せられてもなって気分になるわけで。
しょーもないわかりやすいプライド見せられてもなって気分になるわけで。
740デフォルトの名無しさん
2022/08/21(日) 21:17:28.45ID:WZRwYPWF 行動経済学あるある
実験前の説明では「原理的にはどっちを選んでもOK」と言う
実験後「経済的にはこっちを選ぶのはバカ」と言い出す
実験前の説明では「原理的にはどっちを選んでもOK」と言う
実験後「経済的にはこっちを選ぶのはバカ」と言い出す
741デフォルトの名無しさん
2022/08/21(日) 21:53:47.95ID: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 { ...
そして他の言語ではそれを実現できなくて「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 { ...
742デフォルトの名無しさん
2022/08/21(日) 22:38:05.89ID:5Mzum6WR743デフォルトの名無しさん
2022/08/21(日) 22:51:41.20ID:CnjAlksW 使い勝手を含めて改善すべき点はあるから
それらはRustコンパイラが直接サポートすることで解決すればよい
例えば>>741でも用いているManuallyDropはコンパイラサポートによりその機能を実現している
それらはRustコンパイラが直接サポートすることで解決すればよい
例えば>>741でも用いているManuallyDropはコンパイラサポートによりその機能を実現している
744デフォルトの名無しさん
2022/08/21(日) 22:54:16.54ID:3Twjt0yr リンクエラーってコンパイルエラーではなくない？
745デフォルトの名無しさん
2022/08/21(日) 22:56:51.95ID:3Twjt0yr この人これで日曜日丸1日潰したのかな
746デフォルトの名無しさん
2022/08/21(日) 23:03:08.26ID:U3pRzeag proc-macro作るとかclippyのlint追加するとかそういう方向性ならやりようはあるんでないの
747デフォルトの名無しさん
2022/08/21(日) 23:05:54.42ID:U3pRzeag 型情報必要だからproc-macroは無理そう
compiler-pluginでなんとかしてくれ
compiler-pluginでなんとかしてくれ
748デフォルトの名無しさん
2022/08/21(日) 23:07:11.79ID:NvOkjJCY コンパイラがサポートすればリンク使わずに済むから真のコンパイルエラーとなるのでプロトタイプとしてはいいんじゃない
749デフォルトの名無しさん
2022/08/21(日) 23:13:22.78ID:U3pRzeag 実用上は実行前に検出できれば良いのでリンク時エラーでも問題ないとは思うけど
リンクまでしないcargo checkやrust-analyzerやclippy等で検出できないという違いはあるから
コンパイルエラーとリンク時エラーは区別はした方が良いだろうね
リンクまでしないcargo checkやrust-analyzerやclippy等で検出できないという違いはあるから
コンパイルエラーとリンク時エラーは区別はした方が良いだろうね
750デフォルトの名無しさん
2022/08/21(日) 23:26:12.30ID:G9OTg+LF Rustではコンパイラ対応で完全版も実現できる見込みが立ったようだけど
他の言語ではどうなの？
他の言語ではどうなの？
751デフォルトの名無しさん
2022/08/21(日) 23:31:54.00ID:3Twjt0yr752デフォルトの名無しさん
2022/08/21(日) 23:38:38.83ID:t5TpzXQK753デフォルトの名無しさん
2022/08/21(日) 23:43:44.98ID:sqA1fyA2754デフォルトの名無しさん
2022/08/21(日) 23:46:14.60ID:G9OTg+LF >>751
関数型言語らしい観点からの拡張だね
Haskell側でもRustのborrow checkerについて言及してる点も興味深い
でもそのHaskellの拡張で今回のfinalize未呼び出し検知を静的に実現できるの？
関数型言語らしい観点からの拡張だね
Haskell側でもRustのborrow checkerについて言及してる点も興味深い
でもそのHaskellの拡張で今回のfinalize未呼び出し検知を静的に実現できるの？
755デフォルトの名無しさん
2022/08/21(日) 23:54:38.26ID:HHEr7LbV そもそものアプローチが間違ってるから
他の言語でどうこう言っても意味がない
他の言語でどうこう言っても意味がない
756デフォルトの名無しさん
2022/08/21(日) 23:59:27.31ID:NvOkjJCY >>753
そこで関数呼び出しなどがあると
panicなどで巻き戻される時にfooを解放する必要があるためdropを必要とするからかな
コンパイラが直接サポートすればそこは区別できるしリンク方式を取らなくてもよいから大丈夫じゃないかな
そこで関数呼び出しなどがあると
panicなどで巻き戻される時にfooを解放する必要があるためdropを必要とするからかな
コンパイラが直接サポートすればそこは区別できるしリンク方式を取らなくてもよいから大丈夫じゃないかな
757デフォルトの名無しさん
2022/08/22(月) 00:06:59.32ID:f/cMaiDM でもコンパイラはお前のこと嫌いって言ってたしサポートしないんじゃない？
758デフォルトの名無しさん
2022/08/22(月) 00:20:24.88ID:ckyr84/m そもそものアプローチというか
エラーが起きない時か気にしなくてよい時 → デストラクタによる自動処理任せでOK
エラーやその有無を必ず欲しい時 → flushやcloseなど自分で呼べばエラー取得できる
とはいえそれさえ書くのを忘れた時に
Rustコンパイラがコンパイルエラーとする機能も持てそうだとわかったから
さらなる機能向上に期待
GC言語はデストラクタによる自動処理すらないからそれ以前の問題だし
後始末の処理や指示を忘れてもエラーとならないし
忘れてクローズされていないファイルディスクリプタが多数溜まっていくこともよくあるｗ
エラーが起きない時か気にしなくてよい時 → デストラクタによる自動処理任せでOK
エラーやその有無を必ず欲しい時 → flushやcloseなど自分で呼べばエラー取得できる
とはいえそれさえ書くのを忘れた時に
Rustコンパイラがコンパイルエラーとする機能も持てそうだとわかったから
さらなる機能向上に期待
GC言語はデストラクタによる自動処理すらないからそれ以前の問題だし
後始末の処理や指示を忘れてもエラーとならないし
忘れてクローズされていないファイルディスクリプタが多数溜まっていくこともよくあるｗ
759デフォルトの名無しさん
2022/08/22(月) 01:49:28.39ID:8Vh1g9M5 >>758
>Rustコンパイラがコンパイルエラーとする機能も持てそうだとわかったから
持てそうじゃないって
Drop Obligationとは全く異なるフロー解析が必要になるからゼロから作る新機能だよ
>Rustコンパイラがコンパイルエラーとする機能も持てそうだとわかったから
持てそうじゃないって
Drop Obligationとは全く異なるフロー解析が必要になるからゼロから作る新機能だよ
760デフォルトの名無しさん
2022/08/22(月) 07:51:24.23ID: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解放をコンパイラが用意している仮説で正しいようだ
その仮説で正しそうだが念のため確認してみた
まず>>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解放をコンパイラが用意している仮説で正しいようだ
761デフォルトの名無しさん
2022/08/22(月) 08:10:55.66ID:qagbwcru >>759
そのような別のフロー解析は不要
Rustコンパイラは常に正しくメモリ解放を行うために所有権が尽きてdropを呼び出すべきところを全て把握している
それとは区別する形で>>760のようにpanic時の巻き戻し時のdrop呼び出しも正解に把握している
したがって以下のように検出できる
・finalize()をどのパスでも常に忘れずに呼び出しているコード
→ 非panic時のdropは必ずfinalize()内のみで起こる
・finalize()を呼び忘れているパスが存在するコード
→ 非panic時のdropがfinalize()以外で起こる →検出
よってRustコンパイラは新たな仕組みを必要とせずに
現在把握している情報のみでfinalize()呼び忘れを検出可能
容易に対応できることが確認された
そのような別のフロー解析は不要
Rustコンパイラは常に正しくメモリ解放を行うために所有権が尽きてdropを呼び出すべきところを全て把握している
それとは区別する形で>>760のようにpanic時の巻き戻し時のdrop呼び出しも正解に把握している
したがって以下のように検出できる
・finalize()をどのパスでも常に忘れずに呼び出しているコード
→ 非panic時のdropは必ずfinalize()内のみで起こる
・finalize()を呼び忘れているパスが存在するコード
→ 非panic時のdropがfinalize()以外で起こる →検出
よってRustコンパイラは新たな仕組みを必要とせずに
現在把握している情報のみでfinalize()呼び忘れを検出可能
容易に対応できることが確認された
762デフォルトの名無しさん
2022/08/22(月) 10:01:20.83ID:r+XKv1YE つまり現状はできないってことw
763デフォルトの名無しさん
2022/08/22(月) 17:26:44.21ID:5n0Fj/6k >>760
これってつまりリソース確保してから通常想定されるdropの位置までの間にある
すべての関数呼び出しの panic の可能性を考慮しないといけないから実用不可って事にならんか。
まだ try ... finally ... の方が実用的やないか。
これってつまりリソース確保してから通常想定されるdropの位置までの間にある
すべての関数呼び出しの panic の可能性を考慮しないといけないから実用不可って事にならんか。
まだ try ... finally ... の方が実用的やないか。
764デフォルトの名無しさん
2022/08/22(月) 19:22:34.50ID:f/cMaiDM 正解
765デフォルトの名無しさん
2022/08/22(月) 20:08:33.05ID:IT4AaIoU >>763
大きな誤解をしているようだが
C++やRustなどは関数(正解にはブロックスコープ)を抜ける時に常にデストラクタ(dropなど)を呼んでいる
これが即座のメモリ解放でありC++やRustが高速に動作するな理由
ただしC++でもRustでも所有権が移動したときにはそのデストラクタを呼ばず移動先に委ねられる
以上の基本事項の上でC++の例外やRustのpanicなどが起きたときには
関数呼び出しを自動的に多段に巻き戻して各々のメモリ解放つまりデストラクタ呼び出しをする
これは所有権が移動する場合でも移動する前に例外やpanicが起きればデストラクタが呼び出される
それが>>760のfooの生成と移動の間に挟まれたときのみデストラクタ(drop)が呼び出される仕組み
これらは全てコンパイル時点で静的に簡単に確定するため複雑さはなく実行時の余分なコストも発生しない
ここまでの話は現状のC++/Rustコンパイラがやっている普通のことである
>>761のfinalize記述忘れをコンパイルエラーとする新機能の話は
上述した現状の仕組みをそのまま活用できるため
その新機能を付加することがたやすいというだけの話だろう
大きな誤解をしているようだが
C++やRustなどは関数(正解にはブロックスコープ)を抜ける時に常にデストラクタ(dropなど)を呼んでいる
これが即座のメモリ解放でありC++やRustが高速に動作するな理由
ただしC++でもRustでも所有権が移動したときにはそのデストラクタを呼ばず移動先に委ねられる
以上の基本事項の上でC++の例外やRustのpanicなどが起きたときには
関数呼び出しを自動的に多段に巻き戻して各々のメモリ解放つまりデストラクタ呼び出しをする
これは所有権が移動する場合でも移動する前に例外やpanicが起きればデストラクタが呼び出される
それが>>760のfooの生成と移動の間に挟まれたときのみデストラクタ(drop)が呼び出される仕組み
これらは全てコンパイル時点で静的に簡単に確定するため複雑さはなく実行時の余分なコストも発生しない
ここまでの話は現状のC++/Rustコンパイラがやっている普通のことである
>>761のfinalize記述忘れをコンパイルエラーとする新機能の話は
上述した現状の仕組みをそのまま活用できるため
その新機能を付加することがたやすいというだけの話だろう
766デフォルトの名無しさん
2022/08/22(月) 21:09:18.36ID:Imj2WwGw 複製おじさんがまーた嘘ついてる
Rustが所有権(=dropする義務)をどう管理してるか知りたければ
“Drop Obligations”でググるといいよ
Rustが所有権(=dropする義務)をどう管理してるか知りたければ
“Drop Obligations”でググるといいよ
767デフォルトの名無しさん
2022/08/22(月) 21:19:17.98ID:GgQXua2G >>763
try ... finally ... を書かなきゃいけない時点で大きく負けてるやん
RAII言語は何も書かずともデストラクタで自動処理される
そのデストラクタでエラーが発生する可能性がある時にfinalize呼び出しを強制させる選択肢も用意する話が今のテーマ
try ... finally ... を書かなきゃいけない時点で大きく負けてるやん
RAII言語は何も書かずともデストラクタで自動処理される
そのデストラクタでエラーが発生する可能性がある時にfinalize呼び出しを強制させる選択肢も用意する話が今のテーマ
768デフォルトの名無しさん
2022/08/22(月) 21:21:32.89ID:PwgKhJsq769デフォルトの名無しさん
2022/08/22(月) 21:33:37.66ID:GgQXua2G >>766
Drop obligationsはその話と関係ないじゃない？
RustコンパイラDevelopment Guideを見ても "Drop obligations" は変数の構造つまりenumやstructの中身とそのフィールド連鎖などについての話
Drop obligationsはその話と関係ないじゃない？
RustコンパイラDevelopment Guideを見ても "Drop obligations" は変数の構造つまりenumやstructの中身とそのフィールド連鎖などについての話
770デフォルトの名無しさん
2022/08/22(月) 21:47:48.22ID:5n0Fj/6k >>765
いや、その付加した機能が実用にならないねという話をしたんだが。
いや、その付加した機能が実用にならないねという話をしたんだが。
771デフォルトの名無しさん
2022/08/22(月) 21:49:45.94ID:IT4AaIoU772デフォルトの名無しさん
2022/08/22(月) 21:56:10.02ID:IT4AaIoU >>770
実用的じゃないとはどういう意味だ？
現行でも実用的になっているコード（明示的に書けばエラーを捕捉できて、書き忘れてもデストラクタで自動実行される）に対して
書き忘れを防止できる選択機能を新たに用意しよう、という話だろ
実用的じゃないとはどういう意味だ？
現行でも実用的になっているコード（明示的に書けばエラーを捕捉できて、書き忘れてもデストラクタで自動実行される）に対して
書き忘れを防止できる選択機能を新たに用意しよう、という話だろ
773デフォルトの名無しさん
2022/08/22(月) 21:57:46.65ID:Wff0V8uB >>769
関係ないわけないやん複オジw
関係ないわけないやん複オジw
774デフォルトの名無しさん
2022/08/22(月) 22:01:34.61ID:GgQXua2G >>773
複オジって何
複オジって何
775デフォルトの名無しさん
2022/08/22(月) 22:32:14.28ID:kPK6Bkqr finalize強制の話は7年前から線形型として提案はされてる
具体的なユースケースとしてFinalizeトレイトなんかも出てるし
https://github.com/rust-lang/rfcs/issues/814
ただまぁ大改造だし他にやることもたくさんあるから当分検討されることはないだろうな
具体的なユースケースとしてFinalizeトレイトなんかも出てるし
https://github.com/rust-lang/rfcs/issues/814
ただまぁ大改造だし他にやることもたくさんあるから当分検討されることはないだろうな
776デフォルトの名無しさん
2022/08/22(月) 23:20:29.01ID:9Y+0qHT9 zenは急げ
777デフォルトの名無しさん
2022/08/22(月) 23:32:48.78ID:f/cMaiDM >>772
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f27f2dc5668cded5f61f8f23e030df61
本当はこういうことがやりたかったんだろ？
newとfinalizeの間に一切コードが書けないんじゃ使い道が皆無
もともと「スコープ終端でのdropまでに特定の関数を呼び出していない場合コンパイルエラー」にしたいだけだったのが
「newした直後に特定の関数を呼び出していない場合コンパイルエラー」という厳しすぎる条件になってるのが問題
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f27f2dc5668cded5f61f8f23e030df61
本当はこういうことがやりたかったんだろ？
newとfinalizeの間に一切コードが書けないんじゃ使い道が皆無
もともと「スコープ終端でのdropまでに特定の関数を呼び出していない場合コンパイルエラー」にしたいだけだったのが
「newした直後に特定の関数を呼び出していない場合コンパイルエラー」という厳しすぎる条件になってるのが問題
778デフォルトの名無しさん
2022/08/22(月) 23:35:51.97ID:hmZ4rA6/779デフォルトの名無しさん
2022/08/22(月) 23:43:22.53ID:Y3KYPZ9p >>777
間に別の処理を入れてもエラーが起きないようにしたコードかと思って試しちゃったじゃないかw
間に別の処理を入れてもエラーが起きないようにしたコードかと思って試しちゃったじゃないかw
780デフォルトの名無しさん
2022/08/22(月) 23:47:06.94ID:IdBsr831 費用の問題というのも間違い
安くすれば需要がどんどん増えると思ったら大間違いだよ
安くすれば需要がどんどん増えると思ったら大間違いだよ
781デフォルトの名無しさん
2022/08/23(火) 00:19:09.94ID:VIf97uqR782デフォルトの名無しさん
2022/08/23(火) 00:38:06.00ID: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
実際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
783デフォルトの名無しさん
2022/08/23(火) 00:51:58.53ID:7xrG+Q0V784デフォルトの名無しさん
2022/08/23(火) 01:09:26.07ID:VIf97uqR785デフォルトの名無しさん
2022/08/23(火) 01:19:05.91ID:7xrG+Q0V786デフォルトの名無しさん
2022/08/23(火) 01:31:34.47ID:c+AZPHFJ >>783
ヒント: 781 == 741
ヒント: 781 == 741
787デフォルトの名無しさん
2022/08/23(火) 02:13:39.19ID:fCFqRRwJ 現状ではどの言語でも実現できていない話と、
新たに新機能追加／拡張を考えようという話の、
区別がついていないというよりも、
現状では出来ていないと叩いたり制限があると叩いたり、
ものごとの理解ができないキチガイか文句をつけて叩ければいいアンチのどちらか
新たに新機能追加／拡張を考えようという話の、
区別がついていないというよりも、
現状では出来ていないと叩いたり制限があると叩いたり、
ものごとの理解ができないキチガイか文句をつけて叩ければいいアンチのどちらか
788デフォルトの名無しさん
2022/08/23(火) 02:47:14.79ID:J1WyjKaU SFCエミュを2ヶ月くらいで組んでるから
Rustの生産性が低いって事はなさそうね
https://zenn.dev/tanakh/articles/nes-and-snes-emulator-in-rust
Rustの生産性が低いって事はなさそうね
https://zenn.dev/tanakh/articles/nes-and-snes-emulator-in-rust
789デフォルトの名無しさん
2022/08/23(火) 02:49:40.76ID:J1WyjKaU いや1ヶ月か
790デフォルトの名無しさん
2022/08/23(火) 07:50:29.67ID:42j/MXVV やっと出てきたのがファミコンのエミュかあ
791デフォルトの名無しさん
2022/08/23(火) 08:28:00.41ID:JlLC2CR4 つまり複オジは反省しない嘘つき常習犯
792デフォルトの名無しさん
2022/08/23(火) 11:42:15.69ID:bRky1rDt >>782
さすがHaskellさん
さすがHaskellさん
793デフォルトの名無しさん
2022/08/23(火) 12:20:50.32ID:dq4kOwAu この人何回もゲーム機エミュ書いてるからこの人の事例で言語の生産性は測れないよ。
絵師()みたいな人がよく言う
「これまでの人生+10分なんです」
と同じ。
絵師()みたいな人がよく言う
「これまでの人生+10分なんです」
と同じ。
794デフォルトの名無しさん
2022/08/23(火) 12:30:30.94ID:YWYNH3Bb795デフォルトの名無しさん
2022/08/23(火) 12:39:54.59ID:nhRs6AvL796デフォルトの名無しさん
2022/08/23(火) 12:40:44.01ID:Dkez1B4S Rustの生産性が高い原因はプログラミングの書きやすさとコンパイル時点で確定保証されることの多さ
797デフォルトの名無しさん
2022/08/23(火) 12:43:43.35ID:3UvdpEti ISUCONでGoに匹敵するぐらい入賞チーム増えてきたらどんな用途でも生産性が高いと証明されるな
798デフォルトの名無しさん
2022/08/23(火) 12:57:16.80ID:AllLmU9s >>797
限られた時間内で場当たり的な対応をどれだけこなすかを競うISUCONは現実と離れすぎていてあまり意味がない
もちろん欠陥だらけのシステムの数々の問題点を見抜いて各々に対応する能力は非常に重要
現実にはその能力は安全かつ高速なシステム設計開発に使うものであり短時間での場当たり的な対応に競うものではない
限られた時間内で場当たり的な対応をどれだけこなすかを競うISUCONは現実と離れすぎていてあまり意味がない
もちろん欠陥だらけのシステムの数々の問題点を見抜いて各々に対応する能力は非常に重要
現実にはその能力は安全かつ高速なシステム設計開発に使うものであり短時間での場当たり的な対応に競うものではない
799デフォルトの名無しさん
2022/08/23(火) 13:33:30.00ID:1ViQo793 時間は正しく計測できるという仮定の下で
「時間が短過ぎる」等の判断をすることもまた現実から乖離していることがよくある
数年前の過去問と同じ問題がテストに出れば、時間は数年間あってもそれを計測する時計はない
「時間が短過ぎる」等の判断をすることもまた現実から乖離していることがよくある
数年前の過去問と同じ問題がテストに出れば、時間は数年間あってもそれを計測する時計はない
800デフォルトの名無しさん
2022/08/23(火) 13:45:48.88ID:Ke3Ccl3f 知識を問うテストじゃないはずなのに、ある特定の知識を知ってる人だけがサクッと解けるようなテストだったら、それは問題が悪問なだけ
出題者が悪い
出題者が悪い
801デフォルトの名無しさん
2022/08/23(火) 13:55:00.75ID:1ViQo793 良問を出すべきというのは道徳か？
富裕層は貧困層に寄付するべきと言ってるのと同じ？
富裕層は貧困層に寄付するべきと言ってるのと同じ？
802デフォルトの名無しさん
2022/08/23(火) 14:07:44.30ID:tZOwf5lf ISUCONでRustチームがいっぱい参加して優勝まで取ってたら真逆のこと言いそう
803デフォルトの名無しさん
2022/08/23(火) 14:30:22.22ID:nhRs6AvL 性格や適性の問題じゃないかな
ボトルネックの調査と解消を正しく真面目にやれるタイプのエンジニアにとっては、
言語なんかシステムにおける無数のファクターの一つとして相対的に評価されるものでしかないのだろう
Rust信者だったら自分好みにリファクタリングを始めて時間切れになりそうだ
もちろん後者のタイプの人間のほうが適しているタスクもあるだろうけどね
ボトルネックの調査と解消を正しく真面目にやれるタイプのエンジニアにとっては、
言語なんかシステムにおける無数のファクターの一つとして相対的に評価されるものでしかないのだろう
Rust信者だったら自分好みにリファクタリングを始めて時間切れになりそうだ
もちろん後者のタイプの人間のほうが適しているタスクもあるだろうけどね
804デフォルトの名無しさん
2022/08/23(火) 14:39:05.74ID:IzGsbq3u ISUCONのステマかなんかなの？
参加人数少なくて困ってんのかな
賞金を最低でも1000万以上にしたり
グローバル展開してあらゆる国の開発者を集めたほうがいいんじゃないの？
今は実質日本人学生用のコンテストになってるから
参加人数少なくて困ってんのかな
賞金を最低でも1000万以上にしたり
グローバル展開してあらゆる国の開発者を集めたほうがいいんじゃないの？
今は実質日本人学生用のコンテストになってるから
805デフォルトの名無しさん
2022/08/23(火) 14:46:37.67ID:K++0I94y 俺もまずはリファクタリングから手を付ける
見やすさ追加改変のしやすさ品質に速さなどあらゆることでリファクタリングが基礎になる
あとシステムアーキテクチャに問題があるときは場当たり的な対応より根本設計からやり直した方が長期的に得と分かっている
見やすさ追加改変のしやすさ品質に速さなどあらゆることでリファクタリングが基礎になる
あとシステムアーキテクチャに問題があるときは場当たり的な対応より根本設計からやり直した方が長期的に得と分かっている
806デフォルトの名無しさん
2022/08/23(火) 14:58:48.56ID:hhf7jlH2 どこも小学生の自由研究のノリだよなｗ
807デフォルトの名無しさん
2022/08/23(火) 15:34:20.38ID:1ViQo793 ディズニーを超えたいと思えばまあ小学生っぽくなるわな
808デフォルトの名無しさん
2022/08/23(火) 17:09:38.21ID:cAD3vi3K youtubeの中学受験の図形関係の問題みたいなもんでパターンを覚えるみたいな感じで
競技プログラムって何かつまらないんだよねぇ
競技プログラムって何かつまらないんだよねぇ
809デフォルトの名無しさん
2022/08/23(火) 18:30:00.47ID:jZlkNHy6810デフォルトの名無しさん
2022/08/23(火) 20:26:06.49ID:1ViQo793 ギャンブルならつまらないリスクから逃げるのは常識
だがリスクがない場合、つまらないという理由だけで逃げるのは逆に難度高い
だがリスクがない場合、つまらないという理由だけで逃げるのは逆に難度高い
811デフォルトの名無しさん
2022/08/24(水) 09:30:33.86ID:8fOu5lGq 据膳でも感染リスクあるし
812デフォルトの名無しさん
2022/08/24(水) 09:31:10.38ID:8fOu5lGq >>808
めっちゃ判りますω
めっちゃ判りますω
813デフォルトの名無しさん
2022/08/24(水) 10:08:32.23ID:+3OYCnBx 根源にある感情は「だからなに？」ってことなんだよ
できてもできなくても大差ないということ
できてもできなくても大差ないということ
814デフォルトの名無しさん
2022/08/24(水) 11:01:24.29ID:fCJqwszS ManuallyDrop<T>を知る事と
それを知ってたら何になるかを知る事を区別しないと混乱が起きる
それを知ってたら何になるかを知る事を区別しないと混乱が起きる
815デフォルトの名無しさん
2022/08/24(水) 13:47:39.28ID:ymarx/03 >>808
結局そのアルゴリズムを反復練習で書けるかみたいになっちゃうんだよな
結局そのアルゴリズムを反復練習で書けるかみたいになっちゃうんだよな
816デフォルトの名無しさん
2022/08/24(水) 15:20:22.21ID:ymarx/03817デフォルトの名無しさん
2022/08/24(水) 15:32:52.45ID:rnKc3YSn818デフォルトの名無しさん
2022/08/24(水) 15:49:29.31ID:Up+C642J だから？
どうした？
どうした？
819デフォルトの名無しさん
2022/08/24(水) 16:22:02.33ID:cy/h+3Se >>818
辛辣w
辛辣w
820デフォルトの名無しさん
2022/08/24(水) 17:08:00.62ID:/EMIJnR6 実務に役立たない競プロよりは
まだISUCONのほうがマシ
なぜならISUCONはサーバーなど含めたシステム全体のアルゴリズム相当も含むため
しかしそれを限られた時間内にその場しのぎの対応を多数こなす競技ISUCONも実務とかけ離れすぎていて単なるゲーム
ちなみに競プロの人口の方が多いのはISUCONの方がより現実に近くて桁違いの知識を必要とするため
まだISUCONのほうがマシ
なぜならISUCONはサーバーなど含めたシステム全体のアルゴリズム相当も含むため
しかしそれを限られた時間内にその場しのぎの対応を多数こなす競技ISUCONも実務とかけ離れすぎていて単なるゲーム
ちなみに競プロの人口の方が多いのはISUCONの方がより現実に近くて桁違いの知識を必要とするため
821デフォルトの名無しさん
2022/08/24(水) 18:35:33.50ID:ieoEEHaa 参加者めちゃくちゃ少ないけどなw
しかも半数以上は新人研修や社内勉強会での参加者で本気で決勝目指してるような奴等ではない
しかも半数以上は新人研修や社内勉強会での参加者で本気で決勝目指してるような奴等ではない
822デフォルトの名無しさん
2022/08/24(水) 21:44:22.89ID:AMNp1Lvn ISUCONなんてもともと「いい感じにスピードアップコンテスト」みたいな雑な名前で、
そういうのが好きな運用者のガチ余興から始まったもんだろ。
ベンチマーカーの特性読んで穴見つけて異常点数取ったやつを「スゲェw」みたいに言うお祭り。
なんか箔をつけたい学生さんに目を付けられてからなんかへんな感じになってるけど。
そういうのが好きな運用者のガチ余興から始まったもんだろ。
ベンチマーカーの特性読んで穴見つけて異常点数取ったやつを「スゲェw」みたいに言うお祭り。
なんか箔をつけたい学生さんに目を付けられてからなんかへんな感じになってるけど。
823デフォルトの名無しさん
2022/08/25(木) 02:43:34.63ID:2mWcQmbM >>822
最近はそういうの無くなってるよ
そもそもお題のサンプル実装の時点ですげーよくできたものが出来上がってくる
仕事としてやってる会社も増えたからそうなるんだろう
昔はめちゃくちゃやっつけで雑だったから
やりようがいくらでもあったのにさ
最近はそういうの無くなってるよ
そもそもお題のサンプル実装の時点ですげーよくできたものが出来上がってくる
仕事としてやってる会社も増えたからそうなるんだろう
昔はめちゃくちゃやっつけで雑だったから
やりようがいくらでもあったのにさ
824デフォルトの名無しさん
2022/08/25(木) 10:35:08.58ID:gyuOx2Xm ISUCONを仕事としてやる会社って何なんだよ
825デフォルトの名無しさん
2022/08/25(木) 11:17:57.47ID:dsHaE0cL Rustより難しい疑問だが
その辺にある石ころのように誰にも気付かれない悪問
その辺にある石ころのように誰にも気付かれない悪問
826デフォルトの名無しさん
2022/08/25(木) 11:44:01.01ID:GTPpxCbw 運動会を業務時間にやる会社もある
827デフォルトの名無しさん
2022/08/25(木) 11:49:35.28ID:uCcuWcZI 夏休みの自由研究
運動会
学芸会
発表会
楽しそっすね～ｗ
運動会
学芸会
発表会
楽しそっすね～ｗ
828デフォルトの名無しさん
2022/08/25(木) 12:32:16.39ID:IO7/ZCzd 研修とかトレーニングとしてってことだろ？
もしかして会社の箔を付けるためなのか？
うちはISUCON決勝進出したんですw的な
もしかして会社の箔を付けるためなのか？
うちはISUCON決勝進出したんですw的な
829デフォルトの名無しさん
2022/08/25(木) 12:33:42.97ID:WEV4zSsV 業務時間扱いで技術大会の運営準備とか練習させてくれるの、わりとどんな業界でも普通だと思うが…。
従業員を工数としか扱わない会社に所属してるなら御愁傷様。
従業員を工数としか扱わない会社に所属してるなら御愁傷様。
830デフォルトの名無しさん
2022/08/25(木) 13:05:50.93ID:2mWcQmbM831デフォルトの名無しさん
2022/08/25(木) 14:32:09.78ID:Ku9BBrHT そろそろ学びやすく美しい言語が完成してもいい頃
832デフォルトの名無しさん
2022/08/25(木) 15:34:35.21ID:tT+jR3hx Pascalだな
833デフォルトの名無しさん
2022/08/25(木) 15:39:13.49ID:GTPpxCbw RustとLispであらゆる用途をカバーすべき
834デフォルトの名無しさん
2022/08/25(木) 15:47:59.73ID:Ku9BBrHT Lispはカッコばかりつけてるナルシストだからダメです
835デフォルトの名無しさん
2022/08/25(木) 18:25:49.89ID:gEeT03jW そもそもプログラミング言語って本当に必要なのか？
836デフォルトの名無しさん
2022/08/25(木) 18:38:47.49ID:cZPZ0A+R >>829
「仕事としてISUCONに参加する会社」と
「ISUCON参加を業務時間扱いしてくれる会社」は全然違うやろ
前者は半ば強制の指示命令ありき
後者は任意の研鑽を会社が支援するもの
「仕事としてやってる会社」という表現は完全に前者を念頭にしてるよね
まぁぶっちゃけどうでもいいけど
「仕事としてISUCONに参加する会社」と
「ISUCON参加を業務時間扱いしてくれる会社」は全然違うやろ
前者は半ば強制の指示命令ありき
後者は任意の研鑽を会社が支援するもの
「仕事としてやってる会社」という表現は完全に前者を念頭にしてるよね
まぁぶっちゃけどうでもいいけど
837デフォルトの名無しさん
2022/08/25(木) 19:19:03.77ID:S/wpzj9c >>835
言語がなきゃどうやってプログラミングするんだよ
言語がなきゃどうやってプログラミングするんだよ
838デフォルトの名無しさん
2022/08/26(金) 03:56:04.98ID:V0DMr4WT >>836
いや、後者を念頭にしても不自然ではないよ
いや、後者を念頭にしても不自然ではないよ
839デフォルトの名無しさん
2022/08/26(金) 09:47:57.02ID:+QfZXmYy >>835
全てをアセンブラで書くのは無理だぞ
全てをアセンブラで書くのは無理だぞ
840デフォルトの名無しさん
2022/08/26(金) 10:03:42.99ID:i2SIEm4o841デフォルトの名無しさん
2022/08/26(金) 10:05:33.66ID:i2SIEm4o >>839
アセンブラも機械語という言語で方言もある
アセンブラも機械語という言語で方言もある
842デフォルトの名無しさん
2022/08/26(金) 10:40:28.46ID:+QfZXmYy843デフォルトの名無しさん
2022/08/26(金) 11:09:48.80ID:bqHPcqBD >>842
それは機械語という言語だな
それは機械語という言語だな
844デフォルトの名無しさん
2022/08/26(金) 11:11:30.63ID:+QfZXmYy >>843
何もできなくて草
何もできなくて草
845デフォルトの名無しさん
2022/08/26(金) 11:12:24.53ID:bqHPcqBD846デフォルトの名無しさん
2022/08/26(金) 11:14:37.08ID:bqHPcqBD847デフォルトの名無しさん
2022/08/26(金) 12:29:43.43ID:GQPfjH41 一度でいいからパンチカードでFizzBuzzみたいな簡単なプログラムを作って動かしてみたいな
848デフォルトの名無しさん
2022/08/26(金) 13:56:53.79ID:3b+WTPGR >>837
言語じゃなくて"プログラミング言語"ね
コメントからコード生成する技術も出てきているし、将来的にはプログラミング専用言語が必要な場面がより少なくなるのではと思った
画像生成AIに食わせる文章に工夫が必要なように、コード生成AI向けに自然言語をうまく書くような工夫が必要で、それがプログラミング言語と呼ばれるのかもしれないけど
言語じゃなくて"プログラミング言語"ね
コメントからコード生成する技術も出てきているし、将来的にはプログラミング専用言語が必要な場面がより少なくなるのではと思った
画像生成AIに食わせる文章に工夫が必要なように、コード生成AI向けに自然言語をうまく書くような工夫が必要で、それがプログラミング言語と呼ばれるのかもしれないけど
849デフォルトの名無しさん
2022/08/26(金) 14:02:54.19ID:okIuNp+m850デフォルトの名無しさん
2022/08/26(金) 14:03:10.59ID:qa0S1e+W851デフォルトの名無しさん
2022/08/26(金) 14:57:53.05ID:3b+WTPGR852デフォルトの名無しさん
2022/08/26(金) 15:00:23.56ID:PzjtNrBy >>851
プログラミング言語が必要かどうかの話をしてる時に特定場面でプログラミングを代替できるものが生まれるかどうかの話にすり替えてたのか
プログラミング言語が必要かどうかの話をしてる時に特定場面でプログラミングを代替できるものが生まれるかどうかの話にすり替えてたのか
853デフォルトの名無しさん
2022/08/26(金) 15:17:47.21ID:3b+WTPGR >>852
最初の投稿が言葉足らずというか大げさな表現だったね。申し訳ない
どんなケースでもプログラミング言語が必要ということはなくて、新たな何かで置き換えられる領域はある
その新たな何かこそが次世代言語なんじゃないか、という話をしたかった
最初の投稿が言葉足らずというか大げさな表現だったね。申し訳ない
どんなケースでもプログラミング言語が必要ということはなくて、新たな何かで置き換えられる領域はある
その新たな何かこそが次世代言語なんじゃないか、という話をしたかった
854デフォルトの名無しさん
2022/08/26(金) 15:27:12.00ID:lGuTpQOP ローコ－ドやらノーコードやらは定期的にブームになるけど
結局は定着しないんだよね
結局は定着しないんだよね
855デフォルトの名無しさん
2022/08/26(金) 15:27:17.81ID:PzjtNrBy そんなん昔は全部ユーザーが自分でプログラムしてやってたのが今では完成済みが売られてるんだから今さらだろ
856デフォルトの名無しさん
2022/08/26(金) 15:55:55.10ID:CBlt+itq コードより正確に情報残す方法なんてほぼないわ。
857デフォルトの名無しさん
2022/08/26(金) 15:56:16.83ID:oTK8NYWm 4GLとかあったなあ
使ったことないけど
使ったことないけど
858デフォルトの名無しさん
2022/08/26(金) 15:57:51.53ID:9rbmdHVu ノーコード/ローコードはもっとUIだけにフォーカスしたツールが欲しいわ
マウスポチポチでWebUI作ったらAPIにデータ投げてくれるだけでいいのに、今時のSaaSはだいたい余計な中途半端なDB機能がついてきやがる
まあ一気通貫で提供しないとユーザー企業に直接売れずSIerに主導権握られることになるから、SaaSビジネスとしては面白くないんだろうな
マウスポチポチでWebUI作ったらAPIにデータ投げてくれるだけでいいのに、今時のSaaSはだいたい余計な中途半端なDB機能がついてきやがる
まあ一気通貫で提供しないとユーザー企業に直接売れずSIerに主導権握られることになるから、SaaSビジネスとしては面白くないんだろうな
859デフォルトの名無しさん
2022/08/26(金) 17:49:09.03ID:okIuNp+m PCのUIはスマホ大勝利により失脚してるし
UIにも言語と同様の権力闘争があるのは自明の理
UIにも言語と同様の権力闘争があるのは自明の理
860デフォルトの名無しさん
2022/08/26(金) 18:29:11.38ID:fCaJRqVr861デフォルトの名無しさん
2022/08/26(金) 18:59:38.20ID:fCaJRqVr >>853
そんなもの既にある
そんなもの既にある
862デフォルトの名無しさん
2022/08/26(金) 21:28:02.57ID:3b+WTPGR >>861
じゃあこれ以上の発展は見込めないわけ？
じゃあこれ以上の発展は見込めないわけ？
863デフォルトの名無しさん
2022/08/26(金) 21:34:15.25ID:6BD/kEhJ 現代だとどの言語も言語仕様の更新をしているわけだし新しい言語じゃなくても言語の新しいバージョンを使うってのでもいい気もするけどね
864デフォルトの名無しさん
2022/08/26(金) 22:21:54.13ID:ol+btYtb 言語の仕組みなんてLISP、Java、Haskellらへんでほぼ出揃ってて、目新しいものなんてほとんどない
使いやすくこうしてみましたー、とか、いいとこ取りしてみましたー、みたいなのばっり
使いやすくこうしてみましたー、とか、いいとこ取りしてみましたー、みたいなのばっり
865デフォルトの名無しさん
2022/08/27(土) 00:11:23.77ID:N+6DqfIs 新しいものなんて何もないといいつつ、新たなものを求めて次世代言語スレへやってきてしまう人々
若い頃に出会ったものは相対的にキラキラして見えるだけで、そんな出会いは二度とないので諦めましょう
若い頃に出会ったものは相対的にキラキラして見えるだけで、そんな出会いは二度とないので諦めましょう
866デフォルトの名無しさん
2022/08/27(土) 00:58:29.99ID:Qpr8Hymf 今の時代はコアの理論や機能だけじゃ広まらない。
ライブラリやビルド・パッケージ等のエコシステムも揃ってさらにはGAMAあたりのサポートもないと中々広まらない時代になってる気がする。
ライブラリやビルド・パッケージ等のエコシステムも揃ってさらにはGAMAあたりのサポートもないと中々広まらない時代になってる気がする。
867デフォルトの名無しさん
2022/08/27(土) 04:05:38.65ID:LpZt/R8y >>864
21世紀になってからも唯一Rustが画期的な言語として登場したくらいかな
差異は所有権の借用とライフタイムという概念の導入だけだがその効果が革命的で
GCなくても常に安全な即時の自動メモリ解放とC言語並の速度の両立を実現したことに加えて
データ競合(シングルスレッド時のmutual aliasingを含む)が全く無いことも実現
高速と安全という従来相容れない二者を静的にコンパイル時点で保証したインパクトは大きく
世界のIT大手たちが揃って共同でRust Foundation設立するまでに到った
21世紀になってからも唯一Rustが画期的な言語として登場したくらいかな
差異は所有権の借用とライフタイムという概念の導入だけだがその効果が革命的で
GCなくても常に安全な即時の自動メモリ解放とC言語並の速度の両立を実現したことに加えて
データ競合(シングルスレッド時のmutual aliasingを含む)が全く無いことも実現
高速と安全という従来相容れない二者を静的にコンパイル時点で保証したインパクトは大きく
世界のIT大手たちが揃って共同でRust Foundation設立するまでに到った
868デフォルトの名無しさん
2022/08/27(土) 08:35:20.66ID:Wed6O2vP >>864 程度で新しい仕組みと言えちゃうなら実行中に一時停止しないことに命かけてるponyの方が余程新しい仕組みになっちゃう
標準入力をそのまま返すだけで新しいクラスを作成させられるからな
標準入力をそのまま返すだけで新しいクラスを作成させられるからな
869デフォルトの名無しさん
2022/08/27(土) 09:26:47.49ID:/L4u6rBy870デフォルトの名無しさん
2022/08/27(土) 11:11:47.40ID:PlsxVQrZ 心理学や行動経済学は新たなものを作らない
マウントに限定しなくても心理学全体がそういうものだ
マウントに限定しなくても心理学全体がそういうものだ
871デフォルトの名無しさん
2022/08/27(土) 11:51:54.64ID:APSkyxtl >>867
rust-analyzerがバカスカメモリ食うのなんとかして
rust-analyzerがバカスカメモリ食うのなんとかして
872デフォルトの名無しさん
2022/08/27(土) 12:19:45.38ID:rW3XYjqW 所有権もC++のムーブが元なんだけどな
あれをデフォルトにしたらRustになったと言うだけ
あれをデフォルトにしたらRustになったと言うだけ
873デフォルトの名無しさん
2022/08/27(土) 13:34:38.00ID:PlsxVQrZ ITの新しいところは二つある
低級言語からボトムアップで作るところ
無意識にバグを作ってしまうところ
低級言語からボトムアップで作るところ
無意識にバグを作ってしまうところ
874デフォルトの名無しさん
2022/08/27(土) 14:02:19.73ID:APSkyxtl 所有権とlifetimeは元ネタがあったとはいえ、そこからshared xor mutableへと発展させたのは大きな発明だと思うよ
875デフォルトの名無しさん
2022/08/27(土) 14:25:45.41ID:L6zf9p1Z876デフォルトの名無しさん
2022/08/27(土) 19:24:10.69ID:4NYTelSG 研究用プロトタイプとか言語の一部で適用可能にしたレベルで終わりそうなものを基盤にした処理系をいちから作り上げてメインストリームに持ってきたのはホントすごいと思うわ。
877デフォルトの名無しさん
2022/08/27(土) 19:57:46.81ID:cdahKvQA 組み込みとか低水準で使えるようなシステムプログラミング向けの言語って、候補と呼べるものすら新しい言語はなかなか登場してなかったと思うんだけどなんでだろな
C/C++の存在感がでかすぎて言語開発者の興味が失われてたんかね、GCを贅沢に使った言語はめちゃくちゃたくさん登場してるのに
今となってはRustが成功しつつあるけど、Rustが登場しなかったらずーっとC/C++の天下だったんかな、いやだな
C/C++の存在感がでかすぎて言語開発者の興味が失われてたんかね、GCを贅沢に使った言語はめちゃくちゃたくさん登場してるのに
今となってはRustが成功しつつあるけど、Rustが登場しなかったらずーっとC/C++の天下だったんかな、いやだな
878デフォルトの名無しさん
2022/08/27(土) 20:29:15.90ID:XaCH/Kga879デフォルトの名無しさん
2022/08/27(土) 22:12:41.90ID:PlsxVQrZ >>877
C++の時点で難易度がもう非常識なレベルになってるから
それ以上先に進むのは常識的にはできなかった
だが偶然その時にC++と関係ない人々の日常会話も非常識で過激になって行った
その結果、難解過ぎることの何が悪いのかと開き直るのを誰も止められなくなった
C++の時点で難易度がもう非常識なレベルになってるから
それ以上先に進むのは常識的にはできなかった
だが偶然その時にC++と関係ない人々の日常会話も非常識で過激になって行った
その結果、難解過ぎることの何が悪いのかと開き直るのを誰も止められなくなった
880デフォルトの名無しさん
2022/08/27(土) 23:03:56.45ID:rW3XYjqW881デフォルトの名無しさん
2022/08/27(土) 23:22:25.52ID:0oprUFWN882デフォルトの名無しさん
2022/08/27(土) 23:38:25.67ID:WqKrPeWc 安全なメモリ管理ってｗ
単に関数でnewしたものを保存してスコープが切れたら解放するだけでしょｗ
それC++でFile file;のように宣言したのと概ね同じなんじゃね？ｗ
単に関数でnewしたものを保存してスコープが切れたら解放するだけでしょｗ
それC++でFile file;のように宣言したのと概ね同じなんじゃね？ｗ
883デフォルトの名無しさん
2022/08/27(土) 23:43:33.94ID:sUJYl6Ez Rustはオワコンだからあんま使いたくないな
884デフォルトの名無しさん
2022/08/27(土) 23:45:55.57ID:UglcSwzZ885デフォルトの名無しさん
2022/08/28(日) 00:56:35.98ID:7IFudYOE C++にはtemplate反対派もいるから
バッファ<T>の代わりにtemplateを使わないやつを再発明することで
オーバーランも再発し続ける
バッファ<T>の代わりにtemplateを使わないやつを再発明することで
オーバーランも再発し続ける
886デフォルトの名無しさん
2022/08/28(日) 05:26:11.72ID:qfec6UU9 >>881
Rustの解説にもある通りRAIIがベースで、自動変数の応用例だけどな。
C++は元々cをコンパイルできるという大原則があって、その原則からスマートポインタ強制とかは行っていない。Rustはそのあたりのしがらみを捨てているんだからああなるだろ。
RustもC++の複雑さに加えてHaskellの難しさも取り込んでいるから、絶壁の学習曲線問題は悪化している。置き換えが進むのはc/c++の一部の領域のみで、Javaの領域とか食えないと思うわ。
Rustの解説にもある通りRAIIがベースで、自動変数の応用例だけどな。
C++は元々cをコンパイルできるという大原則があって、その原則からスマートポインタ強制とかは行っていない。Rustはそのあたりのしがらみを捨てているんだからああなるだろ。
RustもC++の複雑さに加えてHaskellの難しさも取り込んでいるから、絶壁の学習曲線問題は悪化している。置き換えが進むのはc/c++の一部の領域のみで、Javaの領域とか食えないと思うわ。
887デフォルトの名無しさん
2022/08/28(日) 06:06:08.65ID:yYM00GDu888デフォルトの名無しさん
2022/08/28(日) 07:28:26.48ID:/BN7SwZG >>886
Rustの難しさがC++の難しさを引き継いでいるのかは疑問に少し疑問だし、Haskellの難しさに至っては全く受け継いでないと思うぞ
型に対する要求は小さいし、関数が純粋であることも求めてないし、遅延評価をベースにしてもいない
Rustの難しさがC++の難しさを引き継いでいるのかは疑問に少し疑問だし、Haskellの難しさに至っては全く受け継いでないと思うぞ
型に対する要求は小さいし、関数が純粋であることも求めてないし、遅延評価をベースにしてもいない
889デフォルトの名無しさん
2022/08/28(日) 10:48:45.36ID:7IFudYOE サブスクやリボ払いじゃないんだから
よく似た難しさに10回出くわしたら1回あたりのコストは1/10になるんだよ
まあそうなると「コスト」とは何かを定義するのが極めて困難になるんだけど
よく似た難しさに10回出くわしたら1回あたりのコストは1/10になるんだよ
まあそうなると「コスト」とは何かを定義するのが極めて困難になるんだけど
890デフォルトの名無しさん
2022/08/28(日) 12:11:47.01ID:kDu69pxs RustやC++やHaskellの難しいポイントってそれぞれ具体的にどういうところを指してるの？
単に難しさと言われても人によってイメージするもの違うのでは
単に難しさと言われても人によってイメージするもの違うのでは
891デフォルトの名無しさん
2022/08/28(日) 12:52:57.69ID:XrBOFvee Haskellの難しさは対象ドメインの一般的理解よりも一段二段高い抽象度を意識したプログラミングが必要なところ
892デフォルトの名無しさん
2022/08/28(日) 13:12:40.64ID:7IFudYOE Lisp世代とErlang世代の間に暗黒時代がある
モナドと型推論のプロトタイプもその時代にある
検索しても多分辿り着けないのは検索エンジンが原因でしょ
モナドと型推論のプロトタイプもその時代にある
検索しても多分辿り着けないのは検索エンジンが原因でしょ
893デフォルトの名無しさん
2022/08/28(日) 13:38:45.23ID:eQVF2PFY トレイトとライフタイムが難しい
894デフォルトの名無しさん
2022/08/28(日) 14:28:30.61ID:5fPmE595 >>893
トレイトはシンプルで分かりやすいけど
クラスが非常に難しい
例えば複数の型に共通する機能性質とメソッド群を用意したいことはプログラミングでよく発生する場合
トレイトだと複数の型々に関係なく独立してそのまま用意して各型に実装するだけだけでいいけど
クラスだと継承でやるにはその型自身に継承しなきゃいけなくて多重継承になったり継承ピラミッドが複雑化
あるいは継承は破綻するからメソッドを増やす別の方法を拡張して使い何のためにクラスを使っているのか本末転倒になる
結局クラスと型が分離できていないことにも問題が多い
Rustでは型とトレイトという二つの直交した概念だけで全てが済むからシンプルで分かりやすい
クラスも継承もないのはRustだけでなくGoでもそうだけど今までクラスと継承で遠回りしてきたプログラミング言語の到達点かなと思う
トレイトはシンプルで分かりやすいけど
クラスが非常に難しい
例えば複数の型に共通する機能性質とメソッド群を用意したいことはプログラミングでよく発生する場合
トレイトだと複数の型々に関係なく独立してそのまま用意して各型に実装するだけだけでいいけど
クラスだと継承でやるにはその型自身に継承しなきゃいけなくて多重継承になったり継承ピラミッドが複雑化
あるいは継承は破綻するからメソッドを増やす別の方法を拡張して使い何のためにクラスを使っているのか本末転倒になる
結局クラスと型が分離できていないことにも問題が多い
Rustでは型とトレイトという二つの直交した概念だけで全てが済むからシンプルで分かりやすい
クラスも継承もないのはRustだけでなくGoでもそうだけど今までクラスと継承で遠回りしてきたプログラミング言語の到達点かなと思う
895デフォルトの名無しさん
2022/08/28(日) 15:06:53.82ID:17VtAmCD >>894
インターフェースも知らんのか？
インターフェースも知らんのか？
896デフォルトの名無しさん
2022/08/28(日) 15:17:26.17ID:WHMHQcXx トレイトも型なのに何言ってんだこいつw
897デフォルトの名無しさん
2022/08/28(日) 15:26:53.46ID:7IFudYOE898デフォルトの名無しさん
2022/08/28(日) 15:34:27.90ID:MtWOn5Ys899デフォルトの名無しさん
2022/08/28(日) 15:39:21.95ID:ntsn5RH7 C++も素のままならまだいいのだが
やっぱり癌はSTLなどのライブラリや例外だな
内部で勝手に動的にメモリ確保したりとかするなよってｗ
やっぱり癌はSTLなどのライブラリや例外だな
内部で勝手に動的にメモリ確保したりとかするなよってｗ
900デフォルトの名無しさん
2022/08/28(日) 15:57:21.77ID:5fPmE595 >>895
そのインターフェース等を批判してることを読み取れないのか？
クラスとインターフェースの2種類が必要となってしまっている
トレイトだけで済むRustがシンプルで分かりやすいことを認めたわけだな
そのインターフェース等を批判してることを読み取れないのか？
クラスとインターフェースの2種類が必要となってしまっている
トレイトだけで済むRustがシンプルで分かりやすいことを認めたわけだな
901デフォルトの名無しさん
2022/08/28(日) 16:07:51.94ID:uFtLPU6J 分かってなさそう
902デフォルトの名無しさん
2022/08/28(日) 16:15:35.13ID:5fPmE595 >>896
トレイトは型ではない
例えばCopyトレイトやDisplayトレイトなどの既存のものから自作のものまで自由にトレイトを作れるが
それらトレイトはもちろん型ではなく機能や性質を示すだけである
ある型を作ったときにそれら任意のトレイトを実装するか否かは自由であり
あるトレイトを作ったときにどの型に対して実装するか否かも自由である
トレイトは型ではない
例えばCopyトレイトやDisplayトレイトなどの既存のものから自作のものまで自由にトレイトを作れるが
それらトレイトはもちろん型ではなく機能や性質を示すだけである
ある型を作ったときにそれら任意のトレイトを実装するか否かは自由であり
あるトレイトを作ったときにどの型に対して実装するか否かも自由である
903デフォルトの名無しさん
2022/08/28(日) 16:21:02.87ID:eCF2zYYC スパゲティーは苦手だからCarbonに期待
904デフォルトの名無しさん
2022/08/28(日) 16:22:01.22ID:0b1WGCJ7 Rustでは型とトレイトという二つの直交した概念だけで全てが済むからシンプルで分かりやすい
クラスとインターフェースの2種類が必要となってしまっている
ほーん
クラスとインターフェースの2種類が必要となってしまっている
ほーん
905デフォルトの名無しさん
2022/08/28(日) 16:33:32.30ID:Lrz1i+MR つまりクラスとか継承とかそんな複雑なものは要らないよな
型とインターフェースだけがあればいい
Goは実際にそうなっている
型とインターフェースだけがあればいい
Goは実際にそうなっている
906デフォルトの名無しさん
2022/08/28(日) 16:33:43.64ID:kDu69pxs >>893
ライフタイム以前よりはかなり簡単になったけどまだ引っかかりどころは残ってる感じ？
ライフタイム以前よりはかなり簡単になったけどまだ引っかかりどころは残ってる感じ？
907デフォルトの名無しさん
2022/08/28(日) 16:44:44.59ID:UslCRvMa >>900
Rustの公式リファレンスにもトレイトはインターフェースって書いてあるんですがww
Rustの公式リファレンスにもトレイトはインターフェースって書いてあるんですがww
908デフォルトの名無しさん
2022/08/28(日) 16:48:30.90ID:5qFsJjmO >>900
Rustはstructとimplとtraitの3種類が必要としまってますねwww
Rustはstructとimplとtraitの3種類が必要としまってますねwww
909デフォルトの名無しさん
2022/08/28(日) 16:52:01.49ID:5fPmE595 >>907
そうだよ
インターフェース自体を問題にはしていない
クラスに加えて結局インターフェース等も必要としている状態を批判している
それならばGoやRustのように最初からクラスは無い方がシンプル
そうだよ
インターフェース自体を問題にはしていない
クラスに加えて結局インターフェース等も必要としている状態を批判している
それならばGoやRustのように最初からクラスは無い方がシンプル
910デフォルトの名無しさん
2022/08/28(日) 17:01:29.35ID:5JaYE9jd C++20でconceptというのがあるんだな
これは知らんかったわ
C++も大変だねー
これは知らんかったわ
C++も大変だねー
911デフォルトの名無しさん
2022/08/28(日) 17:27:57.92ID:VCib2hQJ rust は使ったことないがエラーメッセージが c++ より親切と聞いておる。
912デフォルトの名無しさん
2022/08/28(日) 17:42:22.67ID:eCF2zYYC ここに書き込んでるヤツのせいで本当にrustが嫌いになったわ
913デフォルトの名無しさん
2022/08/28(日) 17:47:23.10ID:ARvglkbX >>912
他人の意見ばかり気にしてないで、自分で判断したらいいのに
他人の意見ばかり気にしてないで、自分で判断したらいいのに
914デフォルトの名無しさん
2022/08/28(日) 18:01:38.50ID:9BfrdysB915デフォルトの名無しさん
2022/08/28(日) 18:04:31.62ID:e6Sjxbuq916デフォルトの名無しさん
2022/08/28(日) 18:12:18.75ID:ZW7HH5qp > クラスとインターフェースの2種類が必要となってしまっている
class に加えて interface があるのは救いなんだがｗ
実装ではなくてインタフェースに対してプログラミングせよ
ってのを実践するのに丁度いい潔い言語機能なんだが
class に加えて interface があるのは救いなんだがｗ
実装ではなくてインタフェースに対してプログラミングせよ
ってのを実践するのに丁度いい潔い言語機能なんだが
917デフォルトの名無しさん
2022/08/28(日) 18:24:29.65ID:7IFudYOE interfaceでできることは (多重継承禁止しなければ) classでもできる
この客観的事実を、鬼滅棒みたいに振り回す人
と仲良くなるところまでがC++の難易度です
この客観的事実を、鬼滅棒みたいに振り回す人
と仲良くなるところまでがC++の難易度です
918デフォルトの名無しさん
2022/08/28(日) 18:31:25.88ID:ZW7HH5qp 個人的にはC++でIFooとか涙ぐましいことやってんのも受け入れられるよ
問題は、言語ユーザが実装とインタフェースを分離したいという発想を持ってるかどうかだから
もちろんそうなったとき、よりスッキリすんのは言語として interface があるほうだよねって話
問題は、言語ユーザが実装とインタフェースを分離したいという発想を持ってるかどうかだから
もちろんそうなったとき、よりスッキリすんのは言語として interface があるほうだよねって話
919デフォルトの名無しさん
2022/08/28(日) 18:34:20.72ID:RvFPV5Qc そもそもC++はオブジェクト指向言語ではないのでインターフェースは必要ない。
920デフォルトの名無しさん
2022/08/28(日) 18:36:05.49ID:ii1XaHH8921デフォルトの名無しさん
2022/08/28(日) 18:39:21.55ID:RvFPV5Qc そもそもRustは仕事がないのでimplは必要ない。
922デフォルトの名無しさん
2022/08/28(日) 18:40:17.57ID:ii1XaHH8923デフォルトの名無しさん
2022/08/28(日) 18:44:55.39ID:RvFPV5Qc Rustは仕事がない。
Goは仕事がある。
この差は大きい。
Goは仕事がある。
この差は大きい。
924デフォルトの名無しさん
2022/08/28(日) 18:45:28.11ID:iJSRjwGP 雇われ仕事はな
925デフォルトの名無しさん
2022/08/28(日) 18:46:02.45ID:eCF2zYYC >>913
自分の判断ではrustはスパゲッティだから
自分の判断ではrustはスパゲッティだから
926デフォルトの名無しさん
2022/08/28(日) 18:47:05.71ID:eCF2zYYC ていうか、Rustって使ってる人少なすぎじゃね？
927デフォルトの名無しさん
2022/08/28(日) 18:48:13.72ID:TZ0QCmjM メソッドが無いってんならともかく、クラスが無いと言っても明示的なクラス定義に比べてソースコードの物理的レイアウトの自由度が高いというくらいの話でしかないでしょ
そんなドヤ顔で語るほどのことでもない
そんなドヤ顔で語るほどのことでもない
928デフォルトの名無しさん
2022/08/28(日) 19:04:58.89ID:ii1XaHH8929デフォルトの名無しさん
2022/08/28(日) 19:06:04.35ID:TZ0QCmjM クラスに継承は必須ではないよ
VBAのクラスに継承は無いぞ？
VBAのクラスに継承は無いぞ？
930デフォルトの名無しさん
2022/08/28(日) 19:06:48.27ID:RvFPV5Qc Rust、Haskellは仕事がない。
931デフォルトの名無しさん
2022/08/28(日) 19:07:23.94ID:L4K2SyLA932デフォルトの名無しさん
2022/08/28(日) 19:08:15.18ID:RvFPV5Qc 始めても居ないだろ。
933デフォルトの名無しさん
2022/08/28(日) 19:16:42.43ID:p0vNwv3L Goのimplicitなインターフェース実装よりも
Rustのexplicitなトレイト実装のほうが断然いい
ただJavaと違ってC#やSwiftならExtensionで後からクラスにインターフェース実装追加できるからGoやRustの方式が特に優れてるわけでも無いと思うけどね
Rustのexplicitなトレイト実装のほうが断然いい
ただJavaと違ってC#やSwiftならExtensionで後からクラスにインターフェース実装追加できるからGoやRustの方式が特に優れてるわけでも無いと思うけどね
934デフォルトの名無しさん
2022/08/28(日) 19:25:12.79ID:ii1XaHH8935デフォルトの名無しさん
2022/08/28(日) 19:32:34.36ID:Lrz1i+MR >>933
優れてるかどうかは誰も言っていなくて
元々の話はRustはトレイトがあるから複雑で難しいとかいう批判に対して始まった議論やろ
実際にはクラスとそれに纏わる諸々がないからGoもRustもクラスのある言語より簡単でわかりやすくなってる
優れてるかどうかは誰も言っていなくて
元々の話はRustはトレイトがあるから複雑で難しいとかいう批判に対して始まった議論やろ
実際にはクラスとそれに纏わる諸々がないからGoもRustもクラスのある言語より簡単でわかりやすくなってる
936デフォルトの名無しさん
2022/08/28(日) 19:39:33.75ID:jYJ6rDEN importしないと使えないメソッドがあるのが理解できない
937デフォルトの名無しさん
2022/08/28(日) 19:45:44.96ID:BvDaIb58 問題はクラスではなく副作用だよ
勘違いするなよ
クラスのメンバーが途中で書き換えられたりしなければ問題はないのよ
勘違いするなよ
クラスのメンバーが途中で書き換えられたりしなければ問題はないのよ
938デフォルトの名無しさん
2022/08/28(日) 19:49:05.31ID:lJnoAt2m rustはstructのフィールドごとにmut設定できないので欠陥言語
939デフォルトの名無しさん
2022/08/28(日) 19:53:38.21ID:fprIa6qZ 次スレのタイトルは
次世代言語28 Rust
にしとこうか？
次世代言語28 Rust
にしとこうか？
940デフォルトの名無しさん
2022/08/28(日) 19:55:42.04ID:RvFPV5Qc 仕事がない言語に未来はない。
941デフォルトの名無しさん
2022/08/28(日) 20:11:14.04ID:iJSRjwGP 仕事があっても未来がない言語の方が多い件
942デフォルトの名無しさん
2022/08/28(日) 20:17:59.03ID:RvFPV5Qc RustはPHPより優れているんだ！！といくら主張しようとも。
Rustは仕事が無くてPHPは仕事があるんだから仕方がない。
Rustは仕事が無くてPHPは仕事があるんだから仕方がない。
943デフォルトの名無しさん
2022/08/28(日) 20:18:38.81ID:e6Sjxbuq >>941
具体的にどういう言語に未来がないの？
具体的にどういう言語に未来がないの？
944デフォルトの名無しさん
2022/08/28(日) 20:25:11.67ID:pOmrVgZH >>943
COBOL Fortran Ruby Perl VB.NET VBScript Delphi
COBOL Fortran Ruby Perl VB.NET VBScript Delphi
945デフォルトの名無しさん
2022/08/28(日) 20:25:27.41ID:lJnoAt2m コボラーの人たちは逃げ切ったと思う
くいっぱぐれなかったコボラー
くいっぱぐれなかったコボラー
946デフォルトの名無しさん
2022/08/28(日) 20:30:40.83ID:DhGNghcs Objective-Cもまだ仕事はあるだろうけど未来はないな
947デフォルトの名無しさん
2022/08/28(日) 20:35:31.36ID:RvFPV5Qc 全部、一時代を築いた言語たちじゃないか。
948デフォルトの名無しさん
2022/08/28(日) 20:36:35.22ID:DhGNghcs だから仕事と過去はあるけど未来がないと言われてるんだろ
949デフォルトの名無しさん
2022/08/28(日) 20:38:56.54ID:DhGNghcs Elmとかいうの一時期Qiitaで流行ってたけどもう下火だな
950デフォルトの名無しさん
2022/08/28(日) 20:48:08.93ID:RvFPV5Qc 世界で見捨てられたころに日本で流行らせようとする人たちが出てくるのは何故なんだろうな。
951デフォルトの名無しさん
2022/08/28(日) 20:51:32.52ID:7IFudYOE 流行らせよう・・・そんな未来形は使う必要がねえんだ
952デフォルトの名無しさん
2022/08/28(日) 20:52:32.31ID:lJnoAt2m PHPとRoRのプロの人は今後も食いっぱぐれないと思う
953デフォルトの名無しさん
2022/08/28(日) 20:57:10.97ID:pOmrVgZH COBOLみたいに進化が止まればね
PHPはアグレッシブに言語仕様変えてるから往年のぺちぱーにとっては厳しくなりつつあるんじゃないか？
PHPはアグレッシブに言語仕様変えてるから往年のぺちぱーにとっては厳しくなりつつあるんじゃないか？
954デフォルトの名無しさん
2022/08/28(日) 21:08:03.91ID:CjJz/pgW955デフォルトの名無しさん
2022/08/28(日) 21:09:02.48ID:M1jTd8eK おれRoR得意だけどRails使ってるとこはフットワーク軽いとこ多いし、みんなどんどんGoに置き換えてるよ
Railsにフロントもやらせるとゴチャっとしてメンテしづらくなりやすいし、APIだけやらせるんならRailsである必要性もないし・・・
Railsにフロントもやらせるとゴチャっとしてメンテしづらくなりやすいし、APIだけやらせるんならRailsである必要性もないし・・・
956デフォルトの名無しさん
2022/08/28(日) 21:25:19.61ID:JJMPEtcG957デフォルトの名無しさん
2022/08/28(日) 21:31:52.80ID:FsgvCgwF スレタイは次世代言語じゃなく新世代言語にしとけば？
それならスレタイにある現世代の言語でも違和感ないから
それならスレタイにある現世代の言語でも違和感ないから
958デフォルトの名無しさん
2022/08/28(日) 21:41:34.26ID:BvDaIb58959デフォルトの名無しさん
2022/08/28(日) 22:08:57.12ID:e6Sjxbuq >>944
C, C++, C#, Python, JavaScript/TypeScript, Go,
C, C++, C#, Python, JavaScript/TypeScript, Go,
960デフォルトの名無しさん
2022/08/28(日) 22:10:55.80ID:iJSRjwGP >>959
未来のある言語ばかりだな
未来のある言語ばかりだな
961デフォルトの名無しさん
2022/08/28(日) 22:12:52.50ID:e6Sjxbuq962デフォルトの名無しさん
2022/08/28(日) 22:16:33.25ID:iJSRjwGP >>961
Formura「いつのスーパーコンピュータの話をしてるんだ」
Formura「いつのスーパーコンピュータの話をしてるんだ」
963デフォルトの名無しさん
2022/08/28(日) 22:41:58.53ID:gOapjWvD YouTube で有名な雑食系エンジニア・KENTA が勧めるキャリアパスは、
Ruby on Rails → Go のみ
さらに彼は、PHP, Scala をオワコン認定した。
要するに、この2つはRailsに勝てる要素がない
時価総額1兆円のGitLab は、Railsで続けることを宣言している
Ruby on Rails → Go のみ
さらに彼は、PHP, Scala をオワコン認定した。
要するに、この2つはRailsに勝てる要素がない
時価総額1兆円のGitLab は、Railsで続けることを宣言している
964デフォルトの名無しさん
2022/08/28(日) 22:54:34.17ID:M1jTd8eK ああ、ごめんなさい、ガイジを召喚しちゃった・・・
965デフォルトの名無しさん
2022/08/28(日) 22:58:49.50ID: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
富岳とかの利用方法見たらわかるけど、最初に載せてる
なんだかんだ言って言語仕様的に最適化し易いのとライブラリに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
966デフォルトの名無しさん
2022/08/28(日) 23:01:39.48ID:iJSRjwGP >>965
それ今はまだ使われてるってだけで未来の話はしてないよね
それ今はまだ使われてるってだけで未来の話はしてないよね
967デフォルトの名無しさん
2022/08/28(日) 23:11:01.40ID:BvDaIb58 Fortranは過去の資産が大量にあるからなあ
しかもバリバリ現役のが
普通にCOBOL以上だよ
しかもバリバリ現役のが
普通にCOBOL以上だよ
968デフォルトの名無しさん
2022/08/28(日) 23:15:53.85ID:e6Sjxbuq969デフォルトの名無しさん
2022/08/28(日) 23:23:42.78ID:iJSRjwGP >>968
話の流れくらい把握してから聞いてくれよ
話の流れくらい把握してから聞いてくれよ
970デフォルトの名無しさん
2022/08/28(日) 23:27:23.09ID:e6Sjxbuq >>969
把握できてないのは貴方では？
把握できてないのは貴方では？
971デフォルトの名無しさん
2022/08/28(日) 23:52:33.65ID:1VE+JRD5 次の土方言語
972デフォルトの名無しさん
2022/08/29(月) 00:01:26.37ID:RL/dmmx9 機能を追加しつつげてるC#辺りの方が、次世代って言わないだろけれど、時代に合わせて進化続けてる感じするよ。
973デフォルトの名無しさん
2022/08/29(月) 00:13:24.90ID:DkZBXm10 C#は一つの言語にアグレッシブに手を入れ続けるという点では現在進行系で最も成功している言語だろうね
単純な言語仕様の量で言えばもはやC++を超えてるんじゃないか
単純な言語仕様の量で言えばもはやC++を超えてるんじゃないか
974デフォルトの名無しさん
2022/08/29(月) 00:15:09.28ID:m+eGoc7U C#に一番類似してるやつとさっさと決着つければいいのに
PythonとRubyがとうの昔にやったことを未だにできてない
PythonとRubyがとうの昔にやったことを未だにできてない
975デフォルトの名無しさん
2022/08/29(月) 00:24:30.02ID:5N7ZaELz Javaと言いたいのかもしれないが、C#の方が別物になりすぎて今や全然類似していない
今だと一番類似してるのはKotlinあたりだろうが、シェアではそもそも全く勝負になってないな
今だと一番類似してるのはKotlinあたりだろうが、シェアではそもそも全く勝負になってないな
976デフォルトの名無しさん
2022/08/29(月) 00:38:48.50ID:q9iRl6Qa 科学計算系の現役のライブラリの中覗くとFortranのコードベタ移植してたりするよね
977デフォルトの名無しさん
2022/08/29(月) 01:40:27.72ID:oXLAwjez >>953
PHPは太古のコードも割と動くからな…
PHPは太古のコードも割と動くからな…
978デフォルトの名無しさん
2022/08/29(月) 06:56:36.80ID:5dAad4gs >>970
IEの新規案件もまだあるんだがそれでもJScriptに未来があると言うのか
IEの新規案件もまだあるんだがそれでもJScriptに未来があると言うのか
979デフォルトの名無しさん
2022/08/29(月) 07:04:39.97ID:7/v7fhbZ980デフォルトの名無しさん
2022/08/29(月) 07:10:46.62ID:5dAad4gs981デフォルトの名無しさん
2022/08/29(月) 07:32:15.58ID:7/v7fhbZ982デフォルトの名無しさん
2022/08/29(月) 07:42:30.60ID:RxdzUhf3 >>942
次世代言語スレでそれ言われてもw
次世代言語スレでそれ言われてもw
983デフォルトの名無しさん
2022/08/29(月) 08:14:52.94ID:q9iRl6Qa Rsstは土方言語何人分の戦闘力を持ってるの？人件費ペイできる？
984デフォルトの名無しさん
2022/08/29(月) 08:32:22.22ID:5dAad4gs 反例は一つあれば十分というのを知らんのか
論文くらい書いたことあるだろ
論文くらい書いたことあるだろ
985デフォルトの名無しさん
2022/08/29(月) 08:57:30.33ID:nDT/a4Yr >>984
バカなの？
そんなのでいいなら
> COBOL Fortran Ruby Perl VB.NET VBScript Delphi
だって新規案件の一例くらいあるだろ
少なくともうちでVB.NETはまだ現役だし、受注案件だけどDelphi案件もあったし
そもそも IE は開発元がやめるって言ってるのにw
バカなの？
そんなのでいいなら
> COBOL Fortran Ruby Perl VB.NET VBScript Delphi
だって新規案件の一例くらいあるだろ
少なくともうちでVB.NETはまだ現役だし、受注案件だけどDelphi案件もあったし
そもそも IE は開発元がやめるって言ってるのにw
986デフォルトの名無しさん
2022/08/29(月) 09:00:20.14ID:5dAad4gs 新規案件があるけど未来がないって話をしてるのにマジで流れを読まず反射だけでレスするやつだな
987デフォルトの名無しさん
2022/08/29(月) 10:39:54.92ID:5N7ZaELz 未来とは？
仮に十年後の案件数と定義するならたぶんRustはCOBOLやVB.NETには勝てないだろうな
仮に十年後の案件数と定義するならたぶんRustはCOBOLやVB.NETには勝てないだろうな
988デフォルトの名無しさん
2022/08/29(月) 10:47:42.18ID:7/v7fhbZ989デフォルトの名無しさん
2022/08/29(月) 11:05:20.92ID:5Xz3DP2S >>980
次スレの未来もヨロ
次スレの未来もヨロ
990デフォルトの名無しさん
2022/08/29(月) 11:09:13.81ID:m+eGoc7U 仕事は手段
目的はお金だがそれも未来を未定義にしておく手段でしかない
溜め込んだお金でいったい何を買いたいのかを定義しないと
目的はお金だがそれも未来を未定義にしておく手段でしかない
溜め込んだお金でいったい何を買いたいのかを定義しないと
991デフォルトの名無しさん
2022/08/29(月) 11:22:48.11ID:5dAad4gs992デフォルトの名無しさん
2022/08/29(月) 13:24:53.95ID:pKi3id7l Fortranをpythonで書き直すプロジェクトやってるけど
なかなか辛い
トランスレータ作ろうか？って話になってる
なかなか辛い
トランスレータ作ろうか？って話になってる
993デフォルトの名無しさん
2022/08/29(月) 15:22:41.69ID:TPR5Zi0L 共産主義国家にレッドコーダーが多い理由
994デフォルトの名無しさん
2022/08/29(月) 15:28:49.68ID:XtVEyX62 numpyでええやん
995デフォルトの名無しさん
2022/08/29(月) 17:54:32.14ID:q9iRl6Qa Fortran変数名の規則が他の言語とだいぶ違うし変な省略多いしマジ読みづらい
996デフォルトの名無しさん
2022/08/29(月) 18:58:34.91ID:vUI7JH1g ブッラータ
997デフォルトの名無しさん
2022/08/30(火) 00:59:24.56ID:O4AMSTyA >>887
なぜC++や他の言語はその(3)まで進めなかったのだろう？
なぜC++や他の言語はその(3)まで進めなかったのだろう？
998デフォルトの名無しさん
2022/08/30(火) 02:29:24.49ID:KhloiM1N >>997
コンパイラが収束しない
コンパイラが収束しない
999デフォルトの名無しさん
2022/08/30(火) 08:10:41.84ID:V3AAJ1E8 >>997
ガチガチになりすぎて実用的じゃないから、GCに任せる方向になった。
ガチガチになりすぎて実用的じゃないから、GCに任せる方向になった。
1000デフォルトの名無しさん
2022/08/30(火) 08:11:01.83ID:V3AAJ1E8 1000
10011001
Over 1000Thread このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 24日 23時間 44分 24秒
新しいスレッドを立ててください。
life time: 24日 23時間 44分 24秒
10021002
Over 1000Thread 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
レス数が1000を超えています。これ以上書き込みはできません。
ニュース
- 高市首相、トランプ米大統領に「早期に会いたい」 日中関係悪化受け… ★4 [BFU★]
- 【コメ】卸売業者「簡単に安売りできない」「大暴落起きれば大赤字に」 JA「新米の販売進度が近年になく遅い。コメの回転が悪い」 ★5 [Hitzeschleier★]
- 「もうキモくてキモくて…」29歳女性が語る“おぢアタック”の実態。「俺ならイケるかも」年下女性を狙う勘違い中年男性には共通点が [Hitzeschleier★]
- テレビ朝日 本社から男性が転落し死亡。関連会社社員か 当たった通行人が左肩軽傷 [阿弥陀ヶ峰★]
- テレビ朝日本社から20～30代の関連会社社員とみられる男性が転落し死亡 六本木けやき坂通りの通行人にはけが人なし [少考さん★]
- 「これいいじゃん!!!」 セブン-イレブンの1620円で買える“1人用クリスマスケーキ”🎂に注目殺到「天才すぎる」 [パンナ・コッタ★]
- 【高市速報】中国、最後通牒 [308389511]
- なんか最近の男って顔がいい以外にも身長やスタイルの良さや声の良さまで要求されてないか？
- 声優って何で写真の無断転載に厳しいの？
- 【速報】テレビ朝日本社から20代〜30代の男性が飛び降り自殺して死亡 東京･六本木 [597533159]
- 【実況】博衣こよりのえちえちスーパーダンガンロンパ6🧪
- お前らってほくそ笑んだことある？