次世代言語26 TypeScript Swift Go Kotlin Nim

■ このスレッドは過去ログ倉庫に格納されています
2022/06/21(火) 09:27:46.30ID:5vOFCGpG
スレタイ（順番はRedMonk準拠）以外の言語もok

※　Rustは現世代最強言語なので除外します

前スレ

次世代言語25 TypeScript Swift Go Kotlin Rust Nim
https://mevius.5ch.net/test/read.cgi/tech/1650185555/
200デフォルトの名無しさん
垢版 |
2022/07/22(金) 07:02:16.68ID:FhKnOINS
アセンブラはスタックやメモリーにアクセスするプログラムを書かされる。
Cはメモリーにアクセスするプリグラムを書かされる。

Javaはスタックもメモリーも意識する必要がない。
すなわちJavaが最も優れている。
2022/07/22(金) 07:23:24.99ID:oyZ2TNIq
>>199
メモリについてもそれ以外についても
抽象度が高い方がプログラミングしやすい
アセンブラよりもスタックとヒープというメモリについての抽象化をした言語の方が扱いやすい

一方で過度の抽象化は実用性を失う
例えばメモリとローカルディスクとネット上のディスクを全て統合して一つの巨大なメモリ空間に抽象化すると
巨大なメモリ空間を扱う極一部の用途を除いて過度の抽象化となってしまい速度差があるものは別々のままの方が好ましい

スタックとヒープを意識せずに済むPythonやRubyやJavaScriptなどの言語も同様な面がある
スタックとヒープには速度差があるため速さを重視する用途から見ると過渡の抽象化といえる
速さを重視せず意識しない用途をオモチャ用途と呼ぶならばPythonやRubyやJavaScriptはオモチャ用途すなわちオモチャ言語とも言えないことはない
2022/07/22(金) 08:16:15.80ID:FDKNW5k7
>>187
サブセットが欲しいのであって、併用できないのは要らん。
2022/07/22(金) 08:17:52.69ID:8hejYpL6
おもちゃ程度の事しかしないので、おもちゃ言語で困ってないんだよね。

Rustが、安全で効率良い速いって言われても、書き捨てのPythonでも10秒程度で処理が終わってしまうようなものだと、わざわざRustでってならないさ。

システムプログラミング向け次世代と、もっと緩いおもちゃ向け次世代みたいな感じに分けないと、話が噛み合わない気がする。
2022/07/22(金) 09:02:33.80ID:bANXE+J8
>>198
動的言語コンプレックス恥ずかしい
2022/07/22(金) 09:15:01.41ID:50nE7LhG
>>202
ダメな部分を使わなきゃいいだけじゃね？
間違って使うというならチェックツール作ればいい
2022/07/22(金) 09:57:43.45ID:q3/dBWm5
だからOS、ドライバとかの低レイヤーとWebみたいなのを分けて考えるべきだろ

何でもかんでもRustとはならない
適材適所
2022/07/22(金) 10:34:06.65ID:YNBeKdpL
コンパイル時のメタプログラミングを駆使すると実行時の電気代が安いんよ
ランニングコストを情報隠蔽とはならない
208デフォルトの名無しさん
垢版 |
2022/07/22(金) 11:20:36.22ID:emgmw9dd
>>202,205
どちらも一理ある

>>203
>システムプログラミング向け次世代と、もっと緩いおもちゃ向け次世代みたいな感じに分けないと、話が噛み合わない気がする。
一種と二種みたいなもんだな
209デフォルトの名無しさん
垢版 |
2022/07/22(金) 11:22:08.43ID:emgmw9dd
>>207
SDGsという言葉は胡散臭くて嫌いだが
SDGsの観点から言っても良質のコードを描くことは絶対地球に優しいよな
2022/07/22(金) 11:39:15.65ID:YNBeKdpL
Cのプリプロセッサの存在自体が納得できない人のために
マクロ言語ではなく型システムなら納得できるだろうとなったのがC++
コンパイラではなくインタプリタに近い方式なら前処理が無くなるだろうとなったのがPython
2022/07/22(金) 11:45:23.20ID:LVIZaCij
>>205
それを他人に強制できる、標準orデファクトとして確立したものが欲しい、ということだよ。
コーティングスタンダードでもいいんだけど、独自に作るのは重たいし、教育するのも大変だから、出来合いのものが欲しいところ。
2022/07/22(金) 11:59:28.82ID:ZDp8+ZKO
>>211
>それを他人に強制できる、標準orデファクトとして確立したものが欲しい、ということだよ。
くだらない理由だな。お前の人集めが酷いだけだろ。
2022/07/22(金) 12:21:12.21ID:G8DPlZOX
>>207
メタプログラミング駆使しなくても静的に書けば実行時の電気代が安くなる

そう、COBOLならね
2022/07/22(金) 12:23:13.63ID:LVIZaCij
>>212
コストとか単価を気にしない富豪はうらやましいですなぁ。
215デフォルトの名無しさん
垢版 |
2022/07/22(金) 12:46:18.43ID:65NBtvCk
>>167
＞その通り
＞で結局C/C++でええやんという話に戻る

お前の後輩の中のダメな奴にコード書かせてもそう言えるのか？
2022/07/22(金) 12:47:04.23ID:efNbKFVE
>>211
適当なリポジトリからclang-tidy等の静的検証ツールのルール設定をパクってくるとかはどうですか
2022/07/22(金) 13:32:14.29ID:YNBeKdpL
趣味のコミュニティなら駄目なコードはどんどん捨てる富豪になれば問題ないけど
趣味じゃない場合は貧乏というかケチになる
2022/07/22(金) 14:03:33.19ID:50nE7LhG
>>211
だからチェックツール作れよ
CIでチェック通らなきゃビルド不可にしときゃいいだけだろ
2022/07/22(金) 14:30:36.22ID:ZDp8+ZKO
いやケチるなら余計に人は選べよ。
2022/07/22(金) 15:07:10.50ID:hnGDX2CP
>>207
サーバーコスト(クラウドコスト)を考えると使う言語を変えることで速さと省メモリにより数倍～十数倍差が出るのは大きいもんな
あとは避けられる実行時エラー(例外含む)をできる限りコンパイル時に静的に解決したいわけだろ
ならばRustがベストチョイス
2022/07/22(金) 15:17:47.41ID:dO8Qo8Lr
>>206
むしろWebはRustむけ
2022/07/22(金) 17:13:14.54ID:efNbKFVE
Webという括り方が雑すぎる
223デフォルトの名無しさん
垢版 |
2022/07/22(金) 17:45:58.45ID:iaUAG8EO
どうせあれとあれを区別出来てないんだろうな
2022/07/22(金) 18:08:11.96ID:8hejYpL6
そのうち、HTMLやCSSのコーダーが、Rustで書き始めるわけか。
テスト工数は減らなさそうだし、制作費上がりそうで嫌だなぁ。
2022/07/22(金) 18:24:55.78ID:hnGDX2CP
>>221
こちらもWeb関係でRustを使っている
2022/07/22(金) 18:31:07.28ID:YNBeKdpL
アルゴリズムとデータ(構造)を区別するのやめようって言い始めた人も悪いのだよ
227デフォルトの名無しさん
垢版 |
2022/07/22(金) 19:46:38.86ID:56UVShba
型推論がモダンなら、動作推論でスタックヒープ最適化ぐらいあって良いのではないか
2022/07/22(金) 21:07:06.38ID:Fn4mSUKv
>>227
そう、Goならね
2022/07/23(土) 00:56:36.98ID:xoLMiefm
>>228
コンパイル時になるべく静的に解決して実行時の負荷をゼロもしくは可能な限り少なくしたいのに
Goはその真逆で実行時の負荷が大きい(ランタイムがデカい)から好ましくない
2022/07/23(土) 07:49:46.21ID:i/T78yqA
もしかして、Rust製のWordpressみたいなCMSあったりします？
2022/07/23(土) 08:34:42.30ID:+NLDKrMc
こういう奴に限ってロクなアルゴリズム書いてない、遅いうえに負荷だらけなのはお前のせい
2022/07/23(土) 08:45:37.01ID:YgKX3LKM
>>229
で、それをWebに適用したがる理由は？
なんのメリットがあんの？
2022/07/23(土) 09:08:24.13ID:z+0uNfVv
なくはないが、1要素に過ぎない
そういうやつに限って実行環境について無頓着で、クソ巨大なコンテナイメージ作ったりするし
2022/07/23(土) 09:12:35.67ID:YgKX3LKM
IOバウンドが主体の現代プログラムで積極的にRustを採用したがる理由がわからない
OSやドライバみたいな低レイヤーならわかる
2022/07/23(土) 09:30:42.73ID:h0kR6t/A
>>234
単一のリクエストの処理についてはその通りだけど、
1ノードで同時に処理するリクエストが増えていけばCPUまたはメモリが上限に達してスケールアウトが必要になる
つまりCPUやメモリの消費を削減することでノード数を少なくでき、コストを抑えられる
まあ現実にはDBや人件費の方が金かかるから大した効果はないんだからね
2022/07/23(土) 10:35:13.77ID:PgM2fTTz
>>234
IOバウンドが現代プログラムの主体というのはさすがに特定分野しか見てなさ過ぎ
2022/07/23(土) 11:04:56.52ID:zqWGCIwO
最近覚えたIOバウンドって言葉を使ってみたかったんだろうな
って感想しかない
2022/07/23(土) 11:22:01.68ID:YgKX3LKM
>>235
NodeやGoに比べて何%効率がいいの？なんかデータある？
2022/07/23(土) 11:24:44.12ID:YgKX3LKM
このスレにいるなんでもかんでもRustにしろおじさんはRust使ってる日本の企業是非あげてほしい
2022/07/23(土) 11:37:34.85ID:Oc+8bztj
MirakurunとMirakcとか見ればわかるけどメモリ効率が劇的にRustは優れてるけどCPUは大して変わらない
そこにコストをかけるモチベーションがどこまであるかって話じゃないの、録画サーバーはラズパイとか低スペPCで動かすっていうモチベーションがある

Rust推しの人はなんで実行コストのばかり話をして開発効率を軽視するのか？OS開発以外で企業で使われることはほとんどないだろうね。
2022/07/23(土) 11:37:55.41ID:XVn4RLKh
>>238
その2つを同列に並べるなよ
RustとGoの差よりNodeとGoの差のほうがはるかに大きいぞ
2022/07/23(土) 11:39:54.42ID:lSlSJyR5
>>239
ボッチの自宅開発者にそういうの求めるのは酷
2022/07/23(土) 11:50:03.97ID:gjUW5TY/
>>240
実行コストは情報隠蔽ができない高水準のスペック
だが開発コストは隠蔽できるので
低レイヤーの事情をいちいち考慮して右往左往したくないんじゃないかな
2022/07/23(土) 11:56:58.24ID:PgM2fTTz
>>240
開発効率の話は客観的な比較難しいのでは
なんか良い指標ある？
2022/07/23(土) 12:26:01.80ID:zqWGCIwO
>>244
普通にIPAが白書出してるよ
残念ながらRustは主要開発言語には入ってないけど
https://www.ipa.go.jp/ikc/publish/whitepaper_dl.html
2022/07/23(土) 12:54:16.63ID:KTZwFAzP
>>245
それ見ると指標はFPかSLOCだけ
しかも両方とも主開発言語による有意な差はないという結論

調査方法を考えれば当たり前の結論だけどね
2022/07/23(土) 12:56:45.10ID:KTZwFAzP
そもそもIPAが土方のやり方を推奨してるのが問題
248デフォルトの名無しさん
垢版 |
2022/07/23(土) 13:05:43.74ID:xNUThAwD
主観的にはRustはかなり開発効率高い
言語そのものもいいし周辺のエコシステムもいい
学習コストなんて二束三文だし
2022/07/23(土) 13:09:35.85ID:bizn9oDX
ScalaやHaskellでも同じこと言ってた
2022/07/23(土) 13:14:10.92ID:gjUW5TY/
他の言語で、初期化と代入の違いを学習したコスト
初期化時には参照カウントが2以上にならないという事実を認識するコスト

こういうのはRustの学習コストにはあたらない
251デフォルトの名無しさん
垢版 |
2022/07/23(土) 14:13:31.48ID:vuZXWhrA
今更な話じゃなく次世代言語の話してくれ。
2022/07/23(土) 14:30:45.45ID:7X2pFb00
現状Rustはライブラリの選択と学習と継続的な監査のコストが著しく高い
速度やリソース面でそれを補って余りあるメリットがあるようなシステムにしか採用されない

言語だけでみればライフタイム周りの煩雑さがある分だけC#よりもやや面倒という程度
2022/07/23(土) 14:41:37.43ID:tu3rIwC3
rustが向いてるのは明らかにミドルウェア層だわな。
アプリ層で使おうとするとかまともに仕事で使ったことない奴の戯言でしかないわ。
2022/07/23(土) 14:51:11.37ID:zqWGCIwO
>>246
> しかも両方とも主開発言語による有意な差はないという結論
どこをどう読んだらそんなアホな結論に達するんだ？
https://i.imgur.com/OQpwGw9.jpg
2022/07/23(土) 15:00:55.50ID:Bnag5ryf
むしろメモリ効率こそ現代の言語で重要なんだぞ？
CPUの性能は頭打ちというのを知らず？
機械学習みたいな行列演算するなら別だが普通のシステムプログラミングやWebアプリ、組み込みみたいな要件ではコアのパフォーマンスなど無意味

スクリプト言語みたいなGCコテコテの言語が速いことは絶対にない
現代のメモリアーキテクチャを知ってればあんなに参照を作りまくって
オブジェクトに触りまくって速いわけない
それはGoも同じ
現にGoは遅い
現代の言語での要件はスタックとヒープをプログラマが明確に意識でき
かつメモリ管理を安全にできる
これができているのは今のところRustのみ
2022/07/23(土) 15:14:50.07ID:QXN0FRoF
>>255
DockerとかKubernetesとかコンテナ技術を活用してマシンのリソースを有効活用するって流れになってるのはそうだけど
Rustで置き換えるってのは聞いたことがないな

> スクリプト言語みたいなGCコテコテの言語が速いことは絶対にない
それはIO待ちがほとんどないCPU処理が主体なプログラムでの話じゃない？
Goは適当に並行処理書いても極力処理がブロックしないように動作するけど
Rustは中断ポイントを自分で記述する必要があるから注意して書かないとGoより遅いなんてことはザラにある

このスレッドにあるベンチマークとか見ればいかにGoが優秀であるかがわかる
https://www.reddit.com/r/rust/comments/lg0a7b/benchmarking_tokio_tasks_and_goroutines/

IO待ち主体のプログラムはいかにブロックせずに処理するかが大事なのであってメモリ効率がボトルネックになることはないわ
2022/07/23(土) 15:31:18.71ID:Bnag5ryf
>>255
そういう特定のユースケースの話をしてるわけじゃないよ
そりゃベンチマークによって速かったり遅かったり
特定のエッジケースで速かったり遅かったりはあるでしょう

もっと数学的かつ抽象的に考えよう
ヒープにオブジェクトが1000個あります
しかしそのうち本当にヒープに乗せる必要があるオブジェクトが100個しかありませんでした
本来ヒープに100個しか必要のないオブジェクトなのに無駄な
ヒープアクセスが900個も起きてしまう
これをメモリ効率が悪いという
Goでもこれは起きうる
もちろんそれが*起きないように*書くこともできなくはないが
エスケープ解析などをしないとわからないし非常に難しいでしょう
しかしrustではこのようなことは起きない
2022/07/23(土) 15:31:55.55ID:Bnag5ryf
レス番間違えた
259デフォルトの名無しさん
垢版 |
2022/07/23(土) 15:40:38.68ID:FAO+OpS7
自演失敗お
2022/07/23(土) 16:04:31.85ID:zqWGCIwO
>>257
> 無駄なヒープアクセスが900個も起きてしまう
> これをメモリ効率が悪いという
お前はまず用語をちゃんと使えるようになってから出直してこい
2022/07/23(土) 16:08:37.49ID:Bnag5ryf
>>260
よくわからない
何が間違ってるの？
2022/07/23(土) 16:14:43.93ID:PgM2fTTz
>>252
ライブラリの選択コストが低い言語ってのは標準ライブラリがでかい言語のこと？
2022/07/23(土) 16:22:30.56ID:zqWGCIwO
>>261
アクセス回数の話なら実行効率
メモリー効率は必要とされるメモリーの量
2022/07/23(土) 16:33:12.53ID:L+Wx1/B2
自演rust狂信者の圧倒的な敗北.....
Rc<T>で無駄なメモリアクセスが起きてることを分かってない。参照カウントで、かなり無駄なカウントアップ・ダウンが現実に起きてるし非効率。
エスケープ解析なんぞでわかるのはほんの一部、goでメモリアクセスが遅めに見えるのは、goroutine間の変数への排他制御が無いからだしGCのせいでもない
古典的なメニーコアを素直に活用できない言語では起きない事を同じ土俵で無理に比べようとしている
確かにgoやrustがstructを使って、javaのようにobjectではないのはメモリー効率を考えているけど、ピープなんちゃらの説明はホントに
分かってないアホの説明。GCで掃除される対象の変数へのアクセスのことを言いたいのだと思うけど、そんなのアクセスするかはGCアルゴリズム次第だ
1回でいいから参照カウントの欠点を調べてこい
265デフォルトの名無しさん
垢版 |
2022/07/23(土) 16:47:16.76ID:GCyS0Uey
AndroidアプリをKotlinベースで作っているんですが、
一定時間スマホ操作ができなくなるような機能を作りたいのですが、どうやればできますかね？
いわゆるデジタルデトックスアプリみたいに、一定時間画面を覆って操作できなくなるアプリ
（バックグラウンド写ったりしないやつ）を想定してます
2022/07/23(土) 17:07:56.92ID:ObegvUfD
>>263
無駄なヒープアロケーションが900あるって書いてあるやん
>>257の文章は気持ち悪いけど
そういうことは起きうるよねとは思うよ
2022/07/23(土) 17:11:14.32ID:4etWwAtX
>>265
セキュリティ的に問題があるから無理
何もできないホームアプリを作って設定するくらいじゃないかな
それでも抜け道を完全に防ぐことはできないと思う
奥の手としては、バックグラウンドサービスでマルチスレッドで無駄な計算をぶん回して使用に耐えないくらい重くすればいい
2022/07/23(土) 17:30:04.86ID:zqWGCIwO
>>266
> 無駄なヒープアロケーションが900あるって書いてあるやん
お前プログラマに向いてないだろ...
書いてあるのは
> 無駄なヒープアクセスが900個も起きてしまう
な
2022/07/23(土) 18:08:33.07ID:jqS/WIc6
>>264
プログラミング経験が少なく勘違いしてるのだと思うけど
C++のshared_ptrやRustのRc/Arcはほとんどのプログラムではその出現が0個～数えられる程度
別の者が同時に同じ物を指し誰が使い終わるかわからないという特殊な状況でしか使われないため出現がレア
実際にプログラミングをするとそのようなケースは多くを避けることができるため極一部でのみ使用となっている
ガベージコレクション言語が全てをガベージとして捨てて回収するコストと比較してC++とRustのこの極一部のみを参照カウントで管理する方式は圧倒的に速くて有利となっている
2022/07/23(土) 18:17:12.38ID:IVV76sYn
> C++のshared_ptrやRustのRc/Arcはほとんどのプログラムではその出現が0個～数えられる程度

🤭
2022/07/23(土) 18:23:45.94ID:1dNQWzE2
>>256
それは無意味な比較
いくつもリプライコメントが付いて指摘されているように
まずまもともな並行処理コードの比較となっていない
次にそのコードのことをしたいならば別の適用をすることでGoとRustでほぼ同じ時間となることもリプライで示されている
きちんと読まずにそんなことでRust叩きをするアンチは愚か
2022/07/23(土) 18:28:20.30ID:PgM2fTTz
>>264
何と何を比較していて何が優れていると言っているのかがまったくわからん...
主張を明らかにするかID変えないで発言追えるようにしてくれ
2022/07/23(土) 18:43:45.96ID:QXN0FRoF
>>271
リプライ読んだ上で言ってるけど？文盲か？
Goはランタイムが賢いから適当に書いても極力ブロックしない様に高速に動作する
Rustは中断ポイントを自分で指定する必要があるから無駄にブロックしないように注意しないといけないって書いたよね？

つまり適当に書いたGo>>>適当に書いたRust

となるわけ。
2022/07/23(土) 18:45:49.99ID:1dNQWzE2
>>269
Rcが極一部にしか出てこないのもそうだが
>>264はもっと大きな勘違いをしていて「Rc<T>で無駄なメモリアクセスが起きてる」と書いて参照カウントを批判している
実際にはRc<T>にアクセスしても付加コストはゼロでRcでないポインタとコストは同じ
つまり無駄なメモリアクセスは発生しない
参照カウントにアクセスされるのは生成clone時や解放drop時などのみ
2022/07/23(土) 18:50:33.61ID:1dNQWzE2
>>273
中断ポイントを自分で指定するとは意味がよくわからないので解説してほしい
もう一つ、適当に書いたコード同士の比較をしていることも現実離れしていて何をしたいのかわからない
2022/07/23(土) 19:26:59.84ID:zqWGCIwO
>>273
> つまり適当に書いたGo>>>適当に書いたRust
そういう主張ならGoのほうが楽に書けると言うべき
2022/07/23(土) 20:04:44.48ID:C7rfIgjP
>>276
ちよっと違う
その部分の話に限定すると
Goは他に選択肢なく書けてそこそこの性能が出る素人向け
C++/Rustはもっと多様な選択肢を取れてGoより高い性能を出せる玄人向け
そのことに加えてGoはランタイムコストが高くメモリについてもGCコストがかかる
あとGoは使用が適している分野が狭い
2022/07/23(土) 20:24:12.66ID:z/1+plFJ
つまりエンタープライズに適してるのはGoで
選ばれた人が作る出来のいいOSSに適してるのはRustだな

玄人によるRust>>>>>>素人によるGo>>>ここにいる自称玄人によるRust

ということだな
2022/07/23(土) 20:37:54.47ID:1dNQWzE2
>>278
使っているとGoは性能面だけでなく開発面での限界も感じてくる
Goはあくまでも簡素なスクリプト言語＋αの位置付け
2022/07/23(土) 20:43:18.42ID:z/1+plFJ
とか自称玄人がほざいておりますわw
2022/07/23(土) 20:59:08.03ID:wfVoITZZ
>>279
さすがにお前が言うと説得力ゼロ
282デフォルトの名無しさん
垢版 |
2022/07/23(土) 21:00:05.36ID:uphZtYPd
Goの出自からしてpythonの置き換えみたいなとこあるし。
2022/07/23(土) 21:02:59.95ID:C7rfIgjP
Goは言語仕様が弱すぎて開発に向かないが並行プログラミングが上手くできるスクリプト言語と捉えると優秀なスクリプト言語
2022/07/23(土) 21:13:25.84ID:PT0x9Gwm
Googleはわざわざ開発に向かない言語を開発して社内で使ってるわけかw
Google社員ですらC++は扱えずに問題だらけだったからそれらを解決するためにGoを開発したわけだけどな

Rustは明らかにC++の代替だね。つまりOS開発やドライバ開発、OSS用途に向いてるだろうね
で、WebプログラミングをC++ってやりますかって話ですよ

ここにいる自称玄人の方々はOS開発とかドライバ開発とかしてないくせにRustという言語使ってることだけにアイデンティティを感じる可哀想なおっさんなんだよな結局
だから他言語を馬鹿にしてマウント取ることに生きがいを持った人生を送ってるわけだね

Goで作られた素晴らしいソフトでDockerやKubernetesやGoogleサービスがあるわけだけど、重要なのは何を問題解決するであって特定の言語をこだわって作るわけじゃないよ、自称玄人さんw
2022/07/23(土) 21:33:42.76ID:7qigD5jo
>>284
RustをC++の代替としてしかとらえることが出来ないのは理解不足だな
CやC++とは異なりRustは自動メモリ解放だからという理由だけではないが現実にJavaからRustへの移行も起きている
さらにスクリプト言語からの移行例もある
これらは高速さや省メモリの観点からだけではなく並行並列プログラミングにおけるデータ競合の問題までもRustは解決していることが大きい
Rustがデータ競合をコンパイル時にエラーとして見つけ出してくれることはバグの減少や実行時デバッグの激減ももたらしている
286デフォルトの名無しさん
垢版 |
2022/07/23(土) 21:34:22.09ID:yM9izZ/V
webやってる人間ならむしろrustに好意的になるよ
子供にはわからんか
2022/07/23(土) 21:36:09.58ID:u2Y0Vizw
docker,kubernetesを実装しても開発言語に向かないとか言われちゃうの意味わからんわ。
2022/07/23(土) 21:44:18.63ID:PT0x9Gwm
>>285
日本企業の採用例は？どこに移行例があるの？
メルカリはGo使いまくってるみたいだけどそういう企業ってRustあるの？
GoogleやMicrosoftもOS開発で注目してるだけだよね？

データ競合なんて多数あるバグのほんの一部でしかないしそれだけ持ち出されても何も響かないね
競合状態は防げないわけだし、データ競合ならGoでもランタイムだか検知する機能はある、テストでも検知できる、それで十分としか思わないね。
2022/07/23(土) 21:44:33.34ID:C7rfIgjP
>>287
Goは言語仕様が弱いから開発には不向きだけど
高度な仕組みは不足していても地道に書いていけばもちろん何でも作れる
成果物があることと開発に向いていないことは矛盾しない
2022/07/23(土) 21:53:20.94ID:PT0x9Gwm
>>289
〇〇の機能がある自慢ならHaskellやScalaもよくされていたけどこれらの言語って普及しましたかね？

継承を排除してるのがその代表例。
Goの割り切ったシンプルさはエンタープライズでの大規模スケールするソフトウエアの開発を促進させている

RustはOS開発やドライバ、組み込みには普及することはあるけどWebやバックエンドといった高レイヤーでは確実に普及しない。理由はScala、Haskellが普及しないのと同じ。
機能自慢だけで企業で使っていくための実用性がない。
Googleでさえ社員がC++など複雑な言語を使いこなせないからあえて機能を削ったGoを採用している。
2022/07/23(土) 21:55:03.92ID:7qigD5jo
>>288
日本企業にこだわるところが理解できないが
例えばクックパッドがRubyで遅いのをRustへ移行した例などあるだろう

Goはランタイムがデータ競合を検知するとの主張は実行時の時点でGoの敗北を意味している
データ競合を静的に実行前に検知できるようにしたRustを使うほうがよい
2022/07/23(土) 21:55:41.92ID:PT0x9Gwm
低レイヤー何も触ってないくせにマウント取るためにRust使って他言語貶めてるゴミクズが多すぎるわ

もはやマウント取ることが目的になってる
2022/07/23(土) 21:55:49.25ID:PgM2fTTz
>>288
並列絡むバグをテストで検知できれば十分というのは同意できないなぁ
Goがその辺頑張ってるのは知ってるけどそれでも
2022/07/23(土) 22:00:23.38ID:PT0x9Gwm
>>291
開発コストはなんで度外視するの？

例えば単体テストはカバレッジ100%行かなくてもリリースするわけでしょ？それは開発コストとトレードオフをかけた結果80%とか基準を下げてるって面もあるわけ

データ競合は防げても競合状態はRustでも防げないわけで並行処理プログラミングが確実に安全に書けるって保証されてるわけでもないぞ
データ競合なんで数あるバグのうちの1つしかないわけで

GoとRustだと明らかに開発コストは桁違いであって特に新規にプロジェクトに参加したメンバーがいる場合に差が出てくるね
2022/07/23(土) 22:02:31.75ID:PT0x9Gwm
>>291
てめーが移行例がたくさんあるとかほざいてるから聞いてんじゃん
日本人なんだからまず日本企業の採用例を聞いてるわけだが
海外企業でもいいよ

ごくごく一部しかないだろ
大半はOS開発用途。
2022/07/23(土) 22:03:24.19ID:PT0x9Gwm
Discordしか知らないだろう自称玄人どもはw
2022/07/23(土) 22:08:40.01ID:PT0x9Gwm
Web業界でC++よりRubyが流行ったのも開発コストの削減が目的なのであって
RustがRubyみたいにWeb業界で普及することはないだろうね。
自称玄人は実行コストのことしか考えないがそれならアセンブリが最強だろ。
結局開発コストと実行コストが優れてるGoが現時点での最適解となる。時点でNode(Deno)
RustがWeb企業で普及することはまずないね。OS開発の用途では普及していくだろう、
2022/07/23(土) 22:12:19.51ID:RQhphYGe
>>290
勉強してからRustを批判した方がいいよ

継承を排除したことをGoの利点と言われてもRustも継承がなくGoと同じだよ
Rustは従来の言語にあった不要な部分や古い部分をばっさりと切り捨てて最新の高機能なパラダイムを組み合わせてシンプルに作った言語
だからRustもGoと同じくクラスも無いし例外(try-throw-catch)も無い

一方でRustは例えば代数的データ型のようなシンプルかつ有用なものを採用
代数的データ型を採用せずに次世代言語を名乗るのはおこがましいので例に出しました
Goとの比較で言えばGoは代数的データ型を欠いているためにエラー返り値の面倒な扱いを招いています
同じように例外を無くしてもGoは記述が面倒になりRustは便利になっていますね
299デフォルトの名無しさん
垢版 |
2022/07/23(土) 22:51:05.66ID:jaxJ03Ml
だからお前ら次世代言語の話しろよ。
それ以外は別スレ建ててやれや。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況