次世代言語24 Go Nim Rust Swift Kotlin TypeScriptat TECH
次世代言語24 Go Nim Rust Swift Kotlin TypeScript - 暇つぶし2ch286:デフォルトの名無しさん
22/03/26 23:34:15.32 Vvd4qIhx.net
なんか哀れだよね彼は

287:デフォルトの名無しさん
22/03/26 23:41:42.26 9q2PYIcF.net
同じ型の方が設計意図が明白になるし、繋げやすいからw それだけだよw 他のにする理由がないよねw
まあもとのスレにも理由は書いたけどw

288:デフォルトの名無しさん
22/03/26 23:58:50.18 +vg1NaC4.net
>>286
繋げやすい??
全く意味不明だ
繋げるならばメソッドチェーンにすべき
そしてVecが中間生成物となるのは無駄となるバッドパターン
イテレータメソッドチェーンにすべき
イテレータを使わないならばスライスを引数で渡すべき

289:デフォルトの名無しさん
22/03/27 00:23:39.64 PoGWmBV8.net
>>287
君にとって意味不明なら意味不明でいいよw そう思っていればいいw
ポリシーとはそういうものw 菜食主義者に肉を食わないとはケシカランって言ってるようなものだからw

290:デフォルトの名無しさん
22/03/27 00:25:07.45 v5PJ1K00.net
>>286
借用で済ませて良い場所で所有権要求するのは普通じゃないからドキュメントコメントにちゃんと書いた方が良いよ

291:デフォルトの名無しさん
22/03/27 00:30:12.96 wv2YT7DD.net
>>288
技術分野でのポリシーとはまず意味のある目的がありそのために設定される
それを説明せずにポリシーとだけ唱えて普通ではない非合理なインタフェースにしているから叩かれる

292:デフォルトの名無しさん
22/03/27 01:18:29.05 PoGWmBV8.net
wwwww
知ってて書いてるんだと思うが、もとを読めば分かるけど、参照で受けてるよw

293:デフォルトの名無しさん
22/03/27 01:35:46.26 BChElFEF.net
>>291
見てみた
確かに引数の型をVecの参照にしてることがわかった
そして元のお題では一貫してずっとlet input = ["a", "b", "c"];となっているのに
引数の型をVecの参照にしてしまったためそこだけlet input = vec!["a", "b", "c"];としている
つまりに引数の型をVecの参照したのは明白な失敗となっている
もちろん正解は引数の型をスライスにすること
これで配列もVecも受け取れる

294:デフォルトの名無しさん
22/03/27 03:52:33.29 PoGWmBV8.net
>>292
だから失敗したからではなくて、何度も言ってるようにポリシーとして合わせたんだよw
正解は動くことw 2つの方法からsliceとしない方を選択したのw

295:デフォルトの名無しさん
22/03/27 04:12:54.52 keWGy6tX.net
>>293
それまでに他の人たちが書いたコードは入力元データが全てlet input = ["a", "b", "c"];と配列になっているね
そして関数の引数の型は全てスライス&[T]となっているね
ところが唐突にその引数の型を&Vec<T>へと変更したコードが登場
それまでの入力元の配列をスライスで渡すことが出来なくなる破綻
破綻の辻褄を合わせるため入力元データを配列から無駄で無意味なlet input = vec!["a", "b", "c"];へと変更
それまで入力元が配列でもスライスでもVecでも大丈夫だったのに入力元がVecしか受け付けなくなっているね

296:デフォルトの名無しさん
22/03/27 07:57:46.18 DQbwsS9F.net
> 2つの方法からsliceとしない方を選択したのw
キミはスライスが何なのかも知らなかったでしょ
自分の知能が低いのを弁えないと恥かくよ

297:デフォルトの名無しさん
22/03/27 08:56:07.10 PoGWmBV8.net
>>294-295
何を言いたいのか知らんが、I/F部分は自由にいじってるので、渡す型が変わるのなんて何の問題もないよw

298:デフォルトの名無しさん
22/03/27 09:20:19.51 aDr0zmJe.net
>>296
元々は利便性の良いスライスや効率で優る配列も受け付けていたのに
貴方の変更では効率の劣るVecのみを受け付けとなってコードが退化している

299:デフォルトの名無しさん
22/03/27 10:51:24.60 PoGWmBV8.net
>>297
何度も言ってるようにポリシーw

300:デフォルトの名無しさん
22/03/27 10:56:32.38 hQNNJiB+.net
>>298
劣ったコードにするポリシーかよ…

301:デフォルトの名無しさん
22/03/27 11:10:30.04 DQbwsS9F.net
さすがに可哀想やからもうやめたれ

302:デフォルトの名無しさん
22/03/27 11:41:31.93 PoGWmBV8.net
>>299-300
別に劣っても可哀想でもないよw 意図が明白なコードになってるw

303:デフォルトの名無しさん
22/03/27 12:11:24.82 mrHY19JA.net
面白い課題なんだね
input = ['a', 'b', 'c']; と集合が与えられた時に
そのべき集合(=全ての部分集合)を返す関数subsets()を作成せよ、ってことか
[]とか['a']とか['a', 'b']とか['a', 'b', 'c']とか全てを漏れなく返せと

304:デフォルトの名無しさん
22/03/27 12:27:49.24 PoGWmBV8.net
初学の人でもすぐ書ける簡単なロジックだよw

305:デフォルトの名無しさん
22/03/27 12:39:06.02 w1ZdsVcb.net
>>303
じゃあプログラム書いてみて

306:デフォルトの名無しさん
22/03/27 14:06:20.96 v5PJ1K00.net
>>301
Vec<T>を引数で受けることは配列全体の所有権を関数に委譲するという意図を表明してるんだけど
そういう意図ということで認識合ってる?

307:デフォルトの名無しさん
22/03/27 15:46:34.95 PoGWmBV8.net
このスレでも参照って何度も書いてんだけどw アホなのw?

308:デフォルトの名無しさん
22/03/27 20:05:48.71 beT1hCdX.net
たかだか数年で身につけたスキル、しかも数年後には使ってないかもしれないスキルでイキってんじゃねーよ

309:デフォルトの名無しさん
22/03/27 21:23:46.37 PoGWmBV8.net
Rustは数年後にはなくなってるかもねw

310:デフォルトの名無しさん
22/03/27 23:33:02.98 Pk6DsGJR.net
人間よりは長生きしてもらわないと
AIが人間に勝てそうな所がどんどん減っていく

311:デフォルトの名無しさん
22/03/27 23:40:27.92 PoGWmBV8.net
Rustなんて人間に負けっぱなしな印象しかないけど・・・w

312:デフォルトの名無しさん
22/03/28 05:38:25.18 1zvMDK8z.net
恥ずかしながら質問なんだがNimって何?

313:デフォルトの名無しさん
22/03/28 06:43:08.84 dhMFtSYI.net
中間生成となるVecを使わずにイテレータを返すイテレータにするという点と
2進数でべき集合を表現するという点が面白いね
fn subsets<T>(input: &[T]) -> impl Iterator<Item=impl Iterator<Item=&T>> {
let len = input.len();
(0..(1 << len))
.map(move |bits| (0..len)
.filter(move |index| bits & (1 << index) != 0)
.map(|index| &input[index]))
}
fn main() {
let input = ["a", "b", "c"];
use itertools::Itertools;
for (i, iter) in subsets(&input).enumerate() {
println!("{}: {:03b}: [{:?}]", i, i, iter.format(", "));
}
}
出力
0: 000: []
1: 001: ["a"]
2: 010: ["b"]
3: 011: ["a", "b"]
4: 100: ["c"]
5: 101: ["a", "c"]
6: 110: ["b", "c"]
7: 111: ["a", "b", "c"]

314:デフォルトの名無しさん
22/03/28 08:08:20.92 hQA9uA7d.net
>>311
目の前にある箱で検索しろ
URLリンク(ja.wikipedia.org)

315:デフォルトの名無しさん
22/03/28 11:24:54.13 cDjwoBcZ.net
>>297
横からみてた感想だけど、コードの目的(全てのサブセットを列挙する)達成できているのに退化とは?
その論説は本来の設問からすると別のゴールが生えてる

316:デフォルトの名無しさん
22/03/28 12:05:00.42 6B08HyS+.net
ツッコミついでにスライスの参照ではなくVecでインターフェース書くメリットについて考えてみたが
これ考え方がモロにPythonのそれだわ
こういう設計はRustだとあんまりやらないが、これをVecから派生した型へのimplとして書くとそこまで違和感ない
「Rustっぽくない」のは指摘されてる通りだが、思想としてはたぶんそこから来てる

317:デフォルトの名無しさん
22/03/28 12:12:56.02 6B08HyS+.net
Pythonはそのまま例えばこんな感じで書かれた関数をオブジェクトに代入してメソッドに使えるからPythonって言ったけど
とにかくオブジェクト指向にどっぷり頭まで漬かった設計だな
元の「どちらのやり方もある」発言も、「関数型の書き方に寄せるかオブジェクト指向的な書き方に寄せるか」という意味なら納得
(まあオブジェクト指向に寄せるならimplで書けよなんだが)

318:デフォルトの名無しさん
22/03/28 14:02:45.07 aDLT1T3I.net
>>314
元々に挙げられていた例は入力が配列
そして彼のコードは配列を入力として受け付けなくなっているから退化であっている

319:デフォルトの名無しさん
22/03/28 14:31:13.30 tMGTgyj2.net
>>316
そのimplを使ったオブジェクト指向的な書き方でもその理由はおかしい
例えばRustには以下のようなrepeatというメソッドが標準ライブラリにある
assert_eq!(vec![1, 2].repeat(3), vec![1, 2, 1, 2, 1, 2]);
もちろんご指摘のようにimplで書かれているのでメソッドとして使えている
しかしソースコードを見てみると次のようになっている
 impl<T> [T] {
  fn repeat(&self, n: usize) -> Vec<T>
  (以下略)
つまりVec<T>に対してではなくスライス[T]に対してimplされている
したがって配列に対しても適用できる
assert_eq!([1, 2].repeat(3), vec![1, 2, 1, 2, 1, 2]);
もちろんスライスに対しても適用できる
let v = [0, 1, 2, 3, 4];
assert_eq!(v[1..=2].repeat(3), vec![1, 2, 1, 2, 1, 2]);
>>315
上述の状況なのでその指摘では皆が納得できる理由や説明になっていない
メリットについて考えてみたとのことだがVecにimplするメリットもない

320:デフォルトの名無しさん
22/03/28 22:32:51.22 O2ikFAVr.net
ガイガー君完敗か

321:デフォルトの名無しさん
22/03/28 23:11:23.81 51Y1Thh9.net
1+1=の結果とか誰も興味ない上、俺がindex版、iterator版、vector版3つ正解を書いてやった後も、誰も興味のないその話題をひたすら続けて無視された挙げ句、このスレにまで持ってき


322:て見当違いな自画自賛と自作自演の嵐w どれだけバカなんだよw



323:デフォルトの名無しさん
22/03/28 23:19:40.94 ie9Ayk2m.net
>>318
ガイガー君とやらは配列とスライスの違いすら知らなかった超初心者だから仕方ないんじゃないか
もちろんスライスに対して実装すればVecにも配列にも適用できるからそれがベストチョイス

324:デフォルトの名無しさん
22/03/29 01:19:51.25 lkDcLhrw.net
>>312
Rustってスクリプト言語みたいに簡単に書けるんやな

325:デフォルトの名無しさん
22/03/29 17:06:45.34 7Qo2cIhC.net
このスレなんでJuliaは扱わないの?

326:デフォルトの名無しさん
22/03/29 18:10:38.94 wvo3NcdM.net
Juliaって数値計算に特化してるイメージなんだけどそれ以外の用途でも良い感じに使えるの?

327:デフォルトの名無しさん
22/03/29 19:43:35.70 4eDRgxgo.net
数値計算というのはひたすら配列に対してループをぶん回すもんで、FortranやJuliaはそういう処理の記述に特化している
そういう意味だと、数値計算以外だと昔のCOBOLみたいに愚直に一行ずつレコードを処理していくような古典的なバッチ処理には向いてるんじゃないかな

328:デフォルトの名無しさん
22/03/29 22:44:22.64 zunmlMTL.net
>>321
本人乙w 配列とスライスの違いは分かってたけど、配列の定義を誤って覚えてただけだよw
Juliaは入れていいと思うw

329:デフォルトの名無しさん
22/03/29 22:53:46.10 Wg3aSHjk.net
>>326
あんたは [T] を配列だと思っていた
もちろん [T] はスライスが正解
これはあんたが配列とスライスの違いをわかっていなかったことを意味する

330:デフォルトの名無しさん
22/03/30 08:18:40.34 LPYfd5on.net
型無し糞言語勧めてくる屑どもを全員●したい

331:デフォルトの名無しさん
22/03/30 08:41:28.55 wafreB6+.net
今時型無し言語を使うやつはそんなにいないだろ
動的型付け言語は使うが

332:デフォルトの名無しさん
22/03/30 09:47:02.31 /0rPh2g4.net
代表的な型なし言語:Smalltalk、BCPL、B言語、アセンブリ言語

333:デフォルトの名無しさん
22/03/30 16:32:49.22 uX6cnVWL.net
動的型付け言語は型無し糞言語じゃないんだ
僕はまだ大丈夫なんだ
こういうやつよな
●したくなるのは
注連縄を首に巻いて通勤快速に連結してやりたくなるよな

334:デフォルトの名無しさん
22/03/30 21:28:09.18 MqQwCbKz.net
型無しと動的型付けを間違えていたことを糊塗しようと必死

335:デフォルトの名無しさん
22/03/30 21:47:02.85 sZZS0bBr.net
>>331
動的型付け言語には型はちゃんとあるぞ
型を忘れる静的言語、型を覚えてる動的言語
URLリンク(dankogai.livedoor.blog)

336:デフォルトの名無しさん
22/03/30 21:52:53.10 9xKIjqbP.net
もちろん強い静的型付け言語の方が圧倒的に優れている
ほとんどのバグはコンパイル時点で検出できる
言語によっては実行時のエラーや善きせぬ例外を無くすこともできる
そのため強い静的型付け言語が最もプログラミング生産性も高い

337:デフォルトの名無しさん
22/03/30 21:58:42.01 txMnCN3x.net
>>333
バカなことばかり書いてあるダメなページだな
> 動的言語の値は、実行時においても自分の型を覚えている。
> このことは何を意味するか?
> 実行時に値の型を調べ、それに対応したコードを実行するプログラムが書けるということだ。
これはまともな静的型付け言語でも出来る
しかもコンパイル時に安全に型をチェックして実行時にエラーをなくすことさえ可能
動的型付け言語ではそのような安全性は無く実行時エラーの山

338:デフォルトの名無しさん
22/03/30 22:01:00.78 kwE0Wrnf.net
正直動的型付けのメリットをあまり感じない

339:デフォルトの名無しさん
22/03/30 22:02:22.01 usrXoLFt.net
いまさら型の動的静的言い出してもウンザリだから
それは君たちが各自自分で勉強して自分で満足してくれ
どっちが優れてるだのどうだの素人の見解1ミリもいらんから

340:デフォルトの名無しさん
22/03/30 22:06:41.15 ibIM88PL.net
このスレ雰囲気からして学生が多い気がするが、一般的には
型あり:ソースコードに型を明記する=静的型
型無し:そうじゃない=動的型
だぞ。ただし「型無し」と全くの初心者に言うと「本当に型がない」と勘違いしてしまう為、
「動的型付け言語」と『教育上』言われる事があってもおかしくないが、それは学校での話。
プログラミング界での用語は上記の通り。
330内はアセンブラしか知らんが、アセンブラにも型(サイズ)はあって、
floatとdoubleは命令が違うし、byte/word/doublewordも命令が違う。
(だから本当の意味で型がない言語なんて実装しようがない)
ただまあ、この辺のごくごく初歩的なところをまずは抑えるべきだよ。
生産性なんてその後の話、一通り書けるようになってからでいい。
心配しなくても初心者の時に書いたコードなんて後から見たらゴミ同然でしかない物ばかりだよ。

341:デフォルトの名無しさん
22/03/30 22:09:14.11 MqQwCbKz.net
>型あり:ソースコードに型を明記する=静的型
>型無し:そうじゃない=動的型
どこの一般だよ

342:デフォルトの名無しさん
22/03/30 22:10:48.06 1lFVb3RX.net
いずれにしても動的型付け言語はバグがあっても実行時になるまで検出できないクソ言語
強き静的型付け言語がベストと結論が出ている

343:デフォルトの名無しさん
22/03/30 22:15:34.40 usrXoLFt.net
よかったですね
ハイ終了

344:デフォルトの名無しさん
22/03/30 22:33:44.92 YEeL7eMZ.net
ちょっとした短いスクリプトを書く程度ならば動的型付け言語でも大丈夫
そうでなくプログラミングをするならば静的型付けのメリットが非常に大きいね

345:デフォルトの名無しさん
22/03/30 22:47:29.54 Xsfwo5z4.net
個人的にどちらが好みかと言われると静的型付け言語なんだけど、自分全然Pythonとか使うので、そういう言語を唾棄してる人的に雑な書き捨てをするときは何の言語使うのか正直気になる

346:デフォルトの名無しさん
22/03/30 22:52:27.20 Cwc9b4uh.net
>>343
ものに依る
例えば簡単なものならシェルスクリプト
よくいる何でもかんでもPython屋さんたちはシェルスクリプトも静的型付け言語も使えないがために陥ってる

347:デフォルトの名無しさん
22/03/30 23:01:10.09 liAwZQUf.net
PHP
Ruby
Perl
この辺は人として見下してるな
死んでもいいゴミだと思ってる

348:デフォルトの名無しさん
22/03/30 23:09:42.25 UJJsLtPb.net
PHPないと個人サイト作成不便だよ。
pythonで書いてた時期もあったがやはりPHPのが楽だしCPU負荷も少ない。

349:デフォルトの名無しさん
22/03/30 23:13:37.76 BGd1I7D3.net
個人サイトなら静的サイトジェネレータで十分な場合も多い

350:デフォルトの名無しさん
22/03/30 23:23:35.91 7iBx/H5p.net
>>346
おもちゃ程度ならPHPで十分だね
しかしアクセスされるたびに動的サーバーサイドレンダリングをしているわけで無駄すぎ
例えばアクセス数のある企業がそれをしたら負荷のせいで複数のサーバーが必要になりやすい
>>347の言うように出来る限り静的サイトジェネレーションがベスト

351:デフォルトの名無しさん
22/03/30 23:26:27.50 liAwZQUf.net
PHPerは性根が腐ってる
人間のくず

352:デフォルトの名無しさん
22/03/30 23:30:47.36 RO3HBLZh.net
サーバーサイドレンダリング…?

353:デフォルトの名無しさん
22/03/30 23:35:38.07 UJJsLtPb.net
静的サイト生成系は結局すぐやめたなぁ。
JSで無理くりなことやりはじめたりして個人サイトレベルだと逆に作りが歪む傾向がある。

354:デフォルトの名無しさん
22/03/30 23:46:31.10 liAwZQUf.net
歪んでるのはPHPerの脳みそだろ
ビルから飛び降りて矯正しろ

355:デフォルトの名無しさん
22/03/30 23:49:24.01 UJJsLtPb.net
自分は普段はc++とc#ばかりだけど...
だけどphpの方が楽、blazorとか逆にしんどかったし。

356:デフォルトの名無しさん
22/03/30 23:58:31.85 BjMRLjMo.net
>>353
選び方が極端すぎ
BlazorはJavaScriptの代わりにC#で書いてブラウザ上をWebAssemblyで動かす究極のアホ
C#はランタイムがデカい上にGCランタイムも必要なわけでそれらを全てブラウザ上のWebAssemblyで動かす
巨大で重くて遅い

357:デフォルトの名無しさん
22/03/31 00:17:05.37 nlcs9ENP.net
負荷が高いからCGIは使わない、PHPは使わない、
共用格安24時間稼働サーバーでnodeやjavaは基本動いてないからそれらは使わない、
VPSで個人サイト運営とか手間なだけだからやらない。
そうなると何でサーバー側で判定必要な処理書いてるのさ。
3大クラウド使って普通の個人サイトにGoでサーバー処理でも書いてんの?

358:デフォルトの名無しさん
22/03/31 00:28:30.60 LBSBAbTE.net
>>354
WebAssembly使うならGCの無いRust一択だな
C++でもよいがRustに対してC++使うメリットがないため
この新たな分野ではC++よりもRustの方がシェア高い

359:デフォルトの名無しさん
22/04/01 21:23:07.86 KJ3cEQ7q.net
>>344
なるほど、返答ありがとう
ということはシェルスクリプトレベルなら許容するけど、シェルスクリプトで扱えないデータ構造が出てくるような場合は、もう静的型付き言語じゃないとありえないって感じなんだね

360:デフォルトの名無しさん
22/04/01 22:34:27.42 06FQxcF3.net
おシェル芸とか勘弁してくれや
書いた本人すら読めない

361:デフォルトの名無しさん
22/04/02 08:35:29.97 4T2g1HGg.net
どの言語も読めないのはそいつの能力が低いだけ
その一方でプログラミング開発デバッグ効率は言語により大きく異なる
強い静的型付けでコンパイル時に可能な限りエラーを出し尽くしてくれるほど効率がいい

362:デフォルトの名無しさん
22/04/02 10:10:09.80 qwJ1jUe9.net
コマンドラインツールでもweb使うとかになるとpythonで書くかな
他は可能な限りシェル

363:デフォルトの名無しさん
22/04/02 10:43:36.91 ofyuLHc/.net
pythonが十分に普及してくれたんで最近はsh/batのかわりにpy一本で済ませることが多くなってきた。

364:デフォルトの名無しさん
22/04/02 11:11:35.19 GmlBdpVN.net
ちんちんシュッ!シュッ!シュッ!

365:デフォルトの名無しさん
22/04/02 12:13:37.37 qwJ1jUe9.net
めちゃくちゃ楽したいときはipynbもありかなーと最近思っている
手作業混ぜなきゃいけないけど表を加工するタスクとか、pandasのto_clipboardで時短できる

366:デフォルトの名無しさん
22/04/02 14:47:38.25 pHmc1XXg.net
>>361
わかる。
sed, awk, curlにbashの配列使ってとかやってたのを一時期perl5に移そうかと思ったけど、これだけpythonが一般化したらもう全部pythonでいいやって思った。

367:デフォルトの名無しさん
22/04/02 14:53:32.80 huJOhBgh.net
pythonのクソみたいなエラーメッセージは二年ほど前に解消された

368:デフォルトの名無しさん
22/04/02 15:17:59.11 aIdGEsvv.net
pythonのインデントによるフォワードルールに慣れてくるとC風の{};が体が拒否反応起こす。begin/end系も論外

369:デフォルトの名無しさん
22/04/02 15:42:43.12 Yphv2UuC.net
インデント系言語はコードフォーマット自分で整えるのが前提なのがなぁ
適当に {} を書いて保存するとフォーマッタが良い感じに整形してくれるのに慣れるともう離れられなくなる

370:デフォルトの名無しさん
22/04/02 15:43:08.95 Yphv2UuC.net
フォーマットというかインデントか

371:デフォルトの名無しさん
22/04/02 15:55:36.79 6GewdDTG.net
生産とデバッグ効率は言語というより開発環境とライブラリがものをいうからなぁ。
少々言語自体にアドバンテージがあっても環境しょぼきゃデバッグも時間かかるだけだし
ライブラリも数万数十万人といった十分な使用実績ないなら主要な機能さえバグがある可能性が高くなるし。

372:デフォルトの名無しさん
22/04/02 16:27:09.73 AD4X0KNq.net
コンパイル時点で問題点をエラーにしてくれない言語こそ開発効率が非常に低い
なぜなら実行時にエラーを引き起こすからだ
その結果として実行時デバッグという無駄な時間のかかる行為が必要となる

373:デフォルトの名無しさん
22/04/02 17:19:49.44 Eaxn3zCS.net
PoopHatePoorの悪口はやめろ

374:デフォルトの名無しさん
22/04/02 18:15:03.99 t3Z/t1xC.net
静的型付けでも実行時エラーを避けられないダメな言語は多い

375:デフォルトの名無しさん
22/04/02 18:23:24.14 +a+ANJVh.net
>>367
コードジェネレーターとかで非常に面倒。
YAMLみたいに両対応してくれればな。

376:デフォルトの名無しさん
22/04/02 19:18:12.91 huJOhBgh.net
pythonのインデントは20年前は馬鹿にしてたけどコードの行数が少なくて済むので一覧性が上がる効果がある
自分は主にC#使ってるけど行数が増えるのでもう何とかして{}減らないかと常に思ってる

377:デフォルトの名無しさん
22/04/02 19:26:43.20 pHmc1XXg.net
>>366
その部分は俺は今も波括弧ブロックの方がみやすいわ。

378:デフォルトの名無しさん
22/04/02 19:52:57.36 Eaxn3zCS.net
目Parseする時に {} は視認性が上がるからあった方がよい
実験結果が示している

379:デフォルトの名無しさん
22/04/02 19:59:17.80 huJOhBgh.net
()は目パース処理されてるらしいけどブラケットはそういう話は聞いたことはないけどな
実際は一行に一個{や}がある状態だから視認性には関係がないかと…

380:デフォルトの名無しさん
22/04/02 20:13:00.21 Yphv2UuC.net
>>374
C#は { を独立した行にするから余計に縦幅が長くなるのかもね

381:デフォルトの名無しさん
22/04/02 20:56:57.66 ezdDFz2p.net
>>370
Pythonなどの動的型付け言語はそのへん悲惨だもんな

382:デフォルトの名無しさん
22/04/02 21:08:24.40 Yphv2UuC.net
>>379
type annotationつけたpythonなら良い?

383:デフォルトの名無しさん
22/04/02 21:51:17.40 oz2OEgJO.net
>>380
強い静的型付け言語を使ったことないのかね
単なる型アノテーションなんておもちゃ

384:デフォルトの名無しさん
22/04/02 21:55:55.31 /mZUsJdk.net
人間が管理できる規模のうちは型アノテーションでも十分
コードの規模がデカくなってくるとコンパイル時チェックがないとやってられん

385:デフォルトの名無しさん
22/04/02 22:01:13.39 ofyuLHc/.net
>>381
型付けの強弱とアノテーションかどうかって関係ないでしょ

386:デフォルトの名無しさん
22/04/02 22:15:52.11 Q6e3gTSV.net
TypeScriptですらオモチャと言われているのにアノテーション程度ではな

387:デフォルトの名無しさん
22/04/02 23:13:17.46 Eaxn3zCS.net
例え型アノテがあったとしてもウンポコペチプーだけは絶対に許してはならない
導入しようとしてくるエタヒニンのガイジどもは全員アウシュビのガス室送りにすべき

388:デフォルトの名無しさん
22/04/02 23:47:53.77 Yphv2UuC.net
>>381
強い静的型付け、かつ、型エラーがある場合は実行すらできない言語が良いということかな?
それとも動的型部分を一切排除して型付けをグローバルに強制したいということ?

389:デフォルトの名無しさん
22/04/02 23:55:58.32 AkfUdAt8.net
goはエラーハンドリングめんどい
まだkotlinの方がいいよ

390:デフォルトの名無しさん
22/04/03 03:17:07.00 Y2X5X0mD.net
>>382
コンパイル時チェックがないとやってられん、に同意
Rustのように型だけでなく書き換え競合などもコンパイルエラーとしてくれるのが理想的

391:ワイドショーは見るな
22/04/03 05:25:31.65 qYWEirZv.net
ソ連の核は綺麗な核
ポル・ポトはアジア的優しさ
北朝鮮は地上の楽園
珊瑚自作自演事件
南京・慰安婦捏造
教科書書き換え「誤報」事件
朝日・武富士裏献金事件
拉致問題切り捨て
サイレント魔女リティ
風の息遣い
五味ボマー
変態新聞
村木局長犯人扱い
その他人民裁判ならぬマスコミ裁判は数知れず
そしてマスコミお得意の「報道しない自由」
これでも貴方は新聞を信用しますか
これでも貴方は新聞を購読しますか
よく考えて下さい

392:デフォルトの名無しさん
22/04/03 09:41:03.41 DNCDVh6y.net
以前の彼は紳士的でした
ところが並列処理での変数の取り扱いにバグが紛れていて不正確な変更が行われこんなことにばかり言うようになってしまいました
手遅れになる前にRustを使いましょう

393:デフォルトの名無しさん
22/04/03 09:45:44.13 N+64wXdQ.net
でもPHPの方が需要あるよね

394:デフォルトの名無しさん
22/04/03 09:54:03.47 ajg4rWD0.net
>>391
RustとPHPの需要を比較しても意味ないですよね
例えるなら小麦粉をもっと食べましょう。と言ってるのに対してスパゲティのほうが人気店あるよね?っていってるようなものですよ。

395:デフォルトの名無しさん
22/04/03 10:25:30.38 DNCDVh6y.net
PHPでまともに仕事してるならいいだろ
Rust使えば何でも許されてニート生活しててもいいわけじゃない

396:デフォルトの名無しさん
22/04/03 10:52:41.24 N+64wXdQ.net
なんかお勉強界隈でルースト?ってゆうの流行ってるみたいですけど、それで仕事できるんですか?
それでワープレより顧客にバリュー提供できるってゆうんですか?

397:デフォルトの名無しさん
22/04/03 10:58:50.79 DNCDVh6y.net
rust サビ 発音はラスト
マジンガーZでルストハリケーンって相手がサビる兵器があったけどアレ

398:デフォルトの名無しさん
22/04/03 11:03:35.19 DNCDVh6y.net
>>394
今の時点ではそのレベルのバリュー提供は無理だね
学校のサイトの管理を理系の先生がやってるけどワードプレス使ってる
rustは多分10年後もその牙城は崩せない
と言うか未来永劫に先生がrust使ってサイト管理をするようにはならない

399:デフォルトの名無しさん
22/04/03 11:14:22.42 1jVKF75a.net
>>377
俺は逆の話しか聞いたことない。
波括弧は目パースされてるが丸括弧はされてない。
例えばlispは丸括弧だらけだけど、あれの括弧の整合性はエディタ支援がでかい。

400:デフォルトの名無しさん
22/04/03 15:53:41.27 kjO3l4sO.net
>>384
TypeScriptはJSの全ての値に型をつけるために無茶な仕様追加してるからな
ゼロベースで設計すればマシな言語になるのにな

401:デフォルトの名無しさん
22/04/03 16:06:48.55 YCOwGNk6.net
Typescriptには
完全なオーバーロードと
完全な形比較機能がほしいな

402:デフォルトの名無しさん
22/04/03 16:13:43.21 enboo0xE.net
>>398
そういう発想のaltJSはみんな死んじゃったんじゃないかな…

403:デフォルトの名無しさん
22/04/03 16:15:00.29 /giYNahv.net
goは詳しくないが。
関数で複数の値を返却できるが、エンジニアのスキル差がある時に、コードの整合性を保つのがめんどい。
Jsonのパースがめんどい。
とりあえず言語仕様として提供する機能が少なすぎて、Java、Rubyとかに慣れたエンジニアからしたら使いづらい。
メリットとデメリットは表裏一体の側面もあるが、こういう意見を持つエンジニアの方が多分多いんじゃね?
少なくともwebサービス開発においては、goは一時の流行りで終わると思うわ。複数人でのコードの管理がめんどいもん。
結局、言語仕様が複雑すぎず軽すぎずが好まれる傾向にあると思う。なので、スレタイに含まれる言語の中ではKotlinに一票

404:デフォルトの名無しさん
22/04/03 16:20:18.51 kjO3l4sO.net
>>400
それで成功したから生JSと混ぜられるのは必要なんだろうな
俺はかっちりした言語を使いたいけど

405:デフォルトの名無しさん
22/04/03 16:22:15.40 RzJGOQaY.net
TypeScriptが実現しようとしているのはVSCode上でのJSの完璧な型検査であって、別に最強の独自言語を作りたいわけでもコンパイル時チェックをしたいわけでもない
MSが提案しているJSへの型アノテーションの導入が実現したらTypeScriptは.ts.dのみを残して役目を終える

406:デフォルトの名無しさん
22/04/03 17:52:10.08 rc6NcMYZ.net
ナデラのMSは良いMS

407:デフォルトの名無しさん
22/04/03 18:03:50.41 PXdtBjdx.net
だ、Dart…

408:デフォルトの名無しさん
22/04/03 19:57:40.10 DNCDVh6y.net
>>401
どういう認識なんだ?
普通はgoは低機能だから誰が書いてもほぼ同じコードになるのがメリットだと言われてるんだけどw

409:デフォルトの名無しさん
22/04/03 20:01:53.30 k51Q+Vww.net
>>401
言語機能が少なくて文句言われてるが?
ジェネリクスがようやく入ったレベルだぞ

410:デフォルトの名無しさん
22/04/03 20:38:24.09 N+64wXdQ.net
>>406
それ言語機能が少なすぎてコピペしまくり=誰が書いても同じになる
というのがオチなんだよね
控えめに言ってゲェージ

411:デフォルトの名無しさん
22/04/03 20:40:34.46 k51Q+Vww.net
>>408
コピペと言語機能は無関係だろ

412:デフォルトの名無しさん
22/04/03 20:53:04.52 En8qx50/.net
goのエラー処理は俺が2019年に業務でちょっと触った時は
if err !=nil {}
みたいなのをひたすら書くしかなくて愕然とした経験があるんだが、これって今は改善されてるの?
比較的新しい言語にしてはずいぶん泥臭いことやるんだなって思った

413:デフォルトの名無しさん
22/04/03 21:02:47.89 N+64wXdQ.net
Go「ぜんぶ ひらがな に すれば かんじ や かたかな が なくて よみやすいね!」
言うほど読みやすいか?

414:デフォルトの名無しさん
22/04/03 21:03:41.40 /giYNahv.net
>>410
されてない認識
これめちゃくちゃめんどいし、戻り値の管理が無駄に煩雑になるだけだと思うんだが
パターンマッチングもめんどい

415:デフォルトの名無しさん
22/04/03 21:05:03.73 N+64wXdQ.net
>>409
ジェネリクスがないからコピペ or interface{}でAny化して型安全を捨てる言語やぞ
エアプは黙っとれ

416:デフォルトの名無しさん
22/04/03 21:32:49.77 DNCDVh6y.net
>>408
違うよ
文法が厳格でしっかり書いてないと枝葉みたいなしょうもない理由でコンパイル通らない
それでレベルが担保される

417:デフォルトの名無しさん
22/04/03 21:35:23.71 DNCDVh6y.net
コーディングになんでエアプが出てくるんだろうか?
語彙が貧困すぎる
脳が死んでないか?

418:デフォルトの名無しさん
22/04/03 21:49:33.85 gPxpOVle.net
高度に抽象化され凝縮度の高い用語を使ってるだけだよ
エアプガイジは黙っとれ

419:デフォルトの名無しさん
22/04/03 21:56:36.46 DNCDVh6y.net
ガイジ ← 脳が委縮した差別主義者が使う言葉
エアプ ← いつまでもゲームでしか物事を例えられない人が使う言葉

420:デフォルトの名無しさん
22/04/03 21:59:40.61 gPxpOVle.net
脳が委縮した差別主義者いつまでもゲームでしか物事を例えられない人は黙っとれ
Goみたいな文だな

421:デフォルトの名無しさん
22/04/03 22:02:18.79 DNCDVh6y.net
いやいや使い方が違うだろ
見不明な置換するなよw
本物の馬鹿なんだな

422:デフォルトの名無しさん
22/04/03 22:03:00.73 DNCDVh6y.net
意味不明

423:デフォルトの名無しさん
22/04/03 22:18:16.65 9lFqLTmO.net
go の if err 1= nil は貧者のEither/Result型って感じはするな
rust の enum みたいなものを導入すると付随していろいろなものを導入する必要があり言語仕様が膨らむということならば
シンプルな仕組みで代替するという go なりの割り切りなんだと思うけど
実際のところどうなんだろうね

424:デフォルトの名無しさん
22/04/03 22:32:45.61 F6bFXWLK.net
Goのエラーハンドリングの仕様については、長いこと議論され続けてるよ
Go1はもう変わらんだろうけど、Go2は新しい仕組み入りそう
URLリンク(go.googlesource.com)

425:デフォルトの名無しさん
22/04/04 02:08:47.79 pXIYfz5U.net
Rustなどのように『値付きenum=タグ付きunion』を導入している言語たちは
色々シンプルかつ効率と容易さと美しさを両立できているから
プログラミング言語として常備すべき基本的な型なのだと思われる

426:デフォルトの名無しさん
22/04/04 07:33:26.24 fw6p8g0C.net
Goにいまさらenum導入しても標準ライブラリから全部変えないとあまり恩恵ないし
if err !=nil {}のシンタックスシュガー導入くらいが妥当だろうね

427:デフォルトの名無しさん
22/04/04 13:42:12.37 lSnbwV1p.net
関数が複数の値を返却できるのはメリットのように見えて、ソースコードの規模が大きくなるほど型の管理が難しくなるだけだと思うわ
KENTAという人はgo推してるが、保守性の高いコード組みやすい代替言語にすぐ取って代えられると思うんだよな

428:デフォルトの名無しさん
22/04/04 14:41:15.89 mbicHYAd.net
>>374
20年前にPythonがこんなに普及するとは思わなかったよ。
Perl 便利って思ってたもの。

429:デフォルトの名無しさん
22/04/04 19:55:04.23 hAxNvJK9.net
PerlとRubyが自爆してPythonだけ生き残った感はあるが。

430:デフォルトの名無しさん
22/04/04 19:58:12.66 Mr7tYRvj.net
三大Poop言語と言えば?

431:デフォルトの名無しさん
22/04/04 20:08:25.60 ZaQ2qXNU.net
10年ぶりにプログラミング学習勧めてるけどpython面白いなー
5chではそんな流行ってない感じ?

432:デフォルトの名無しさん
22/04/04 20:13:10.33 w+f2Elco.net
>>429
5ch全体ではわからないけど少なくともこのスレではpythonは下火
今一番流行っているのはRustだね。
一番人気。それだけにアンチも多くて喧々諤々の議論が巻き起こっている状態。
というよりRustの勢いが羨ましくてファビョってるだけだけどなw

433:デフォルトの名無しさん
22/04/04 20:48:23.61 mbicHYAd.net
Perl 6 は Raku になったし、自滅かもしれんが、Ruby は「ペナンブラ氏の24時間書店」に登場する位にカリフォルニアの方では認知されてたと思ったんだけど。

434:デフォルトの名無しさん
22/04/04 21:22:41.62 yu8UGqfF.net
>>413
コード生成すりゃいいじゃん

435:デフォルトの名無しさん
22/04/04 21:23:22.47 yu8UGqfF.net
>>429
すれ違い

436:デフォルトの名無しさん
22/04/04 21:24:09.92 yu8UGqfF.net
>>427
PHPもだが言語機能に大差はないからあとはライブラリの質だけの差になった
そこで圧倒的差がついた

437:デフォルトの名無しさん
22/04/04 21:25:42.99 yu8UGqfF.net
>>426
年齢はPerlと大して変わらんからな
Pythonなんてモダンな要素全くないのにここまで流行ったのは凄い
特にRubyやRailsみたいな積極的なマーケティングとかもしてないのに

438:デフォルトの名無しさん
22/04/04 21:32:16.24 CuNEs20T.net
ついにRubyが反撃の狼煙を上げる
RubyのWebAssembly/WASIへの移植が実現、プレリリース版のバイナリ公開。RubyGemsにも対応
URLリンク(www.publickey1.jp)

439:デフォルトの名無しさん
22/04/04 21:48:11.28 g5kOP8Pm.net
>>436
ぜひRailsに導入してほしい
総スカン食らって完全終了だろう

440:デフォルトの名無しさん
22/04/04 23:20:01.52 yu8UGqfF.net
>>436
これRubyインタプリタをwasmにコンパイルしてそれ上で動かすんだろ?
ありえんでしょ

441:デフォルトの名無しさん
2022/04/0


442:4(月) 23:35:26.89 ID:AN+U/Dr9.net



443:デフォルトの名無しさん
22/04/04 23:45:58.24 TGLutmH3.net
>>435
たしかにまあRubyはRailsがキラーアプリとなって日の目を見ることが出来たけど、Pythonは人気を得るきっかけとかあったのかな
GoogleはPythonをめちゃ使ってて、GuidoがGoogleに入社した2005年頃にはすでにPythonがスクリプト言語の中では勝ち組感があったんだろうけども、なんでやろ

444:デフォルトの名無しさん
22/04/04 23:50:33.75 6MqP0wMX.net
>>436
WebAssemblyでガベージコレクションのある言語を動かすのは無駄の極致

445:デフォルトの名無しさん
22/04/04 23:56:53.89 yu8UGqfF.net
>>439
Cもそうだけど

446:デフォルトの名無しさん
22/04/05 00:05:51.56 2NHa52hR.net
Cを使うならRustにした方が機能豊富でプログラミングしやすいよ
もちろんデータ競合もメモリ管理ミスも検出してくれる
そしてほとんどの場合で速度差もない

447:デフォルトの名無しさん
22/04/05 00:48:48.74 vdX4VYV5.net
The Rust Programming Language 日本語版 をちょこっと読んでみたけどC++作ったストラウストラップが変態だった気がしてしまう

448:デフォルトの名無しさん
22/04/05 01:05:33.37 CALU2HjK.net
コード生成もコピペ扱いするならrustのderiveもコピペだよな

449:デフォルトの名無しさん
22/04/05 01:29:37.39 /ryaTu8Q.net
>>442
ガイジの真似とてコピペを走らば即ちガイジなり
CがガイジだからGoもガイジで~ぇすでええんか?

450:デフォルトの名無しさん
22/04/05 01:35:13.81 u+FS9OX1.net
>>446
だからコピペじゃないって
君のいうコピペより上の概念だよ
人が介在してない

451:デフォルトの名無しさん
22/04/05 01:37:22.57 /ryaTu8Q.net
>>447
機械がするコピペはきれいなコピペか?違うだろ?バカか?

452:デフォルトの名無しさん
22/04/05 01:42:08.31 u+FS9OX1.net
>>448
君のいうコードジェネージョンがコピペというなら
ジェネリクスも中身は型が違う同じコード生成してるだけだよ?
はい勝った
完膚なきまでに勝った
ここを君を導きたかった
勝ち俺の勝ち
ジェネリクス否定
矛盾
ジェネリクスはコンパイラによるコードジェネーション
勝ち俺の勝ち
勝ち完全
フルに勝ち
勝った

453:デフォルトの名無しさん
22/04/05 01:46:35.34 raev6Sae.net
>>449
見事に勝っちゃったねえ
レスバ見てたけどそこに導こうとしてるのはわかったよ
そっちに行くな!って思ってた
そもそもコンパイラがコードジェネレータだしね
本質的には同じことしてるわけで機会がコピペしてるからなあ
そっちに行っても負けは確定する

454:デフォルトの名無しさん
22/04/05 01:50:00.91 u+FS9OX1.net
>>450
いや危なかったジェネリクスがゴミっていう風に持っていくと絶対に勝てないからね
勝つにはなんとか相手を捻じ曲げさせるしかなかった
うまく誘導できたよ
負けるかと思った

455:デフォルトの名無しさん
22/04/05 01:53:56.08 QYmdMKfu.net
>>413
そんなにGoは酷い言語なのか
なぜそんなことに?

456:デフォルトの名無しさん
22/04/05 02:13:39.62 a+cPs4U5.net
>>448
そうだよ。

457:デフォルトの名無しさん
22/04/05 02:19:13.35 fMFdzsU+.net
元の話はこれか
型安全を捨てるのは暴挙だな
>>413
> ジェネリクスがないからコピペ or interface{}でAny化して型安全を捨てる言語やぞ

458:デフォルトの名無しさん
22/04/05 07:05:37.18 82POVtug.net
>>440
pythonはなんといってもAI(ディープラーニング)が起爆剤だろ
あとは自動化・RPA関連(Excel連携、スクレイピング)でもライブラリが豊富で人気がでた

459:デフォルトの名無しさん
22/04/05 07:07:35.56 82POVtug.net
たった3ヶ月でウェブエンジニアになれた
きっかけはRailsを学んだこと
とか言ってるの最高に気持ち悪い
今はRustとかやって難しいところに悩んでる人がエンジニアだと思う

460:デフォルトの名無しさん
22/04/05 07:20:44.40 fQZQ0DHq.net
Rust自体は特に難しくはない
もしRustを難しいと感じるようなレベルの人ならば一般的にプログラミングに向いていない

461:デフォルトの名無しさん
22/04/05 08:14:13.65 /ryaTu8Q.net
なんかバカが勝手に盛り上がってて藁
どこのチンカス野郎がマス書いたコピペジェネレータと言語標準じゃ全く次元が違うだろ
はい勝った
完膚なきまでに勝った
ここを君を導きたかった
勝ち俺の勝ち
ジェネリクス否定
矛盾
ジェネリクスはコンパイラによるコードジェネーション
勝ち俺の勝ち
勝ち完全
フルに勝ち
勝った
見事に勝っちゃったねえ
レスバ見てたけどそこに導こうとしてるのはわかったよ
そっちに行くな!って思ってた
そもそもコンパイラがコードジェネレータとかワロス
本質的には同じでないわけでガイジがコピペしてるからなあ
そっちに行っても負けは確定する

462:デフォルトの名無しさん
22/04/05 08:37:48.08 VqqpMSri.net
>>456
でもそういう奴等はわかりやすい地雷で助かる
IT業界は人手不足だって言われているのは「自走できる」人材の不足なのに、どっかのYoutuberやプログラミングスクールの言うことを鵜呑みにしてRailsで作成したポートフォリオをドヤ顔で出してくるような奴は俺が企業の採用担当だったら速攻で落とすわ

463:デフォルトの名無しさん
22/04/05 09:19:59.73 pUAnaqqP.net
>>454
Goはおもちゃ言語だから

464:デフォルトの名無しさん
22/04/05 13:07:10.50 dZMax2uf.net
ひろみGO

465:デフォルトの名無しさん
22/04/05 14:27:50.37 ZwTPjiXX.net
>>455
AI関連の前に科学技術系のライブラリをpythonでって流れは結構あった。
そこらへんがperl、rubyにはなかった。
float回りをいじくると途端に言語や開発環境が汚くなるわけだが、その辺を躊躇しなかったってのが良くも悪くもある。

466:デフォルトの名無しさん
22/04/05 14:54:27.96 hteyj+L8.net
>>455
せやな、現在の圧倒的なPython人気はAI関連が充実してるからやな
でもGoogle社内の開発言語にもっと昔から採用されてたのにはAIは関係ないやろ
>>462
NumPyやSciPyみたいなのがキラーアプリだと?
もっとよく思い返すとRed Hat、Debian、GentooなどのOSでパッケージマネージャなど様々なツールがPythonで実装されてたし、
数値計算とか関係なく、スクリプト言語のデファクトスタンダードとしての地位を2000年ぐらいには確立してたね
キラーアプリがあるからというよりは、単純に開発者コンセンサスを得やすい言語だったんだろうな、と思ってきた

467:デフォルトの名無しさん
22/04/05 15:30:06.85 ZwTPjiXX.net
>>463
いやそのころのpythonのパッケージ管理ツールって相当ひどかったぞ。
まともに依存関係を解決できることなんてほとんど期待できなかったし。
まあ今もそういう傾向はあるが。

468:デフォルトの名無しさん
22/04/05 15:49:46.89 Zafpq7jd.net
pythonは2007年ごろには将来デスクトップ系ではスクリプトの中核になるから小さな社内スクリプトやプラグインのスクリプトは可能な限りpythonにしましょうってずっと自分は運動してたわ。
幸い反対する人もほとんどいなかったな。
もちろんアプリはpythonでは書かないが。
AIなんかはあまり関係ないなぁ。

469:デフォルトの名無しさん
22/04/05 15:55:55.07 VZWFnuGC.net
40-300行ぐらいのpythonスクリプトは便利だわ
Windowsだと特にshell(cmd)の扱いづらさが際立つし

470:デフォルトの名無しさん
22/04/05 16:01:09.15 Om5krohy.net
googleはyoutubeや検索エンジンをpythonで実装してたもんな
それでpythonが注目されだした
確か書き換えたらコード量が大幅に減ったのとメンテナンスコストが下がったんだ
当時はC++,java,PytohnがGoogle三大言語だった
今は知らんけど

471:デフォルトの名無しさん
22/04/05 16:03:31.17 Zafpq7jd.net
pythonはmayaのプラグイン組み込み言語でもあったから
行列やベクトルや虚数を使った回転などを多用する層が
そこで増えていったってながれもあるやろな。

472:デフォルトの名無しさん
22/04/05 16:19:20.26 I+HzSIOd.net
カーニハン、ロブ・パイクが1999年に出したプログラミング作法(The Practice of Programming)では Perl, awk, C++, Java, C で処理速度とソースコードの行数表にしてた。

473:デフォルトの名無しさん
22/04/05 17:31:17.76 kTsaT80P.net
ポストPythonってJuliaなの?

474:デフォルトの名無しさん
22/04/05 17:35:57.79 82POVtug.net
>>470
Rustだろうな
Web業界はRustに移行しはじめている

475:デフォルトの名無しさん
22/04/05 17:36:28.83 X/Z+fkc6.net
ベターPythonかもしれないがポストPythonではないだろう

476:デフォルトの名無しさん
22/04/05 18:09:13.50 Zafpq7jd.net
rustは広くは使われないだろうねぇ。
システム部分以外は
ルーズで簡単で気にかけることや
独特な概念が少ない言語でないと広く使われない
プログラミング未経験者が数日である程度書ける程度のでないと

477:デフォルトの名無しさん
22/04/05 18:21:07.39 RXEj+ZGQ.net
そこでKotlinですよ
ベターJavaの位置付けで学習コストも低い
Scalaほど複雑でもなく、初心者にも手を出しやすいからRustよりはWebでは使われるんじゃないかね
Goは学習コストが低いとかで誤魔化してるだけで、一昔前の使いづらい言語みたいな感じ

478:デフォルトの名無しさん
22/04/05 18:54:22.88 iyhQru73.net
>>471
所有権気にしなきゃいけないのにPythonの後継は無いなぁ。
>>52
>c++とhaskellあたりを学んでおけば大したことないし
とかいう世界だろ。

479:デフォルトの名無しさん
22/04/05 19:19:35.56 4JjDvpWU.net
>>475
理解する気がないから勘違いしてるのだろうけど
所有権なんて難しい話ではなく非常に簡単なことだぞ
このスレにもRustのコードが多数書かれてきてるようだが何か難しいことや特殊なことあったか?

480:デフォルトの名無しさん
22/04/05 19:48:47.33 3noiRnfQ.net
Kotlinなんてぱっとせんもん一生泥から出てこんやろw
webでは絶対流行らない
Javaで既に作られてるもんはわざわざKotlinにしようなんてならんし
Javaに慣れ親しんでる層はJava17を導入するやろな
Javaみたいなのを毛嫌いする層はそもそもKotlinに見向きもしてないし

481:デフォルトの名無しさん
22/04/05 20:20:35.48 fN/L9gSF.net
まあKotlinはswiftと同じ位置づけで表には出てこない気がする

482:デフォルトの名無しさん
22/04/05 20:25:45.56 8mvJZb/O.net
kotlinとjavaは相互運用可能なのに、わざわざjavaを選択する発想なんて出てこないだろ
goは学習コスト低い分、この先流行りに乗って採用する企業は増えるかも知れんが、機能不足故にいずれ見離されるんじゃない?
rustは初心者には複雑すぎるし、それこそweb開発でメリットがあまりない
kotlinはともかく、rustやgoが10年先も使われるイメージが想像できない

483:デフォルトの名無しさん
22/04/05 20:27:09.43 fN/L9gSF.net
これからは同じ内容をどれだけ短くてわかりやすく書けるかと言うことに
各言語は対応せざるを得ない状況になる

484:デフォルトの名無しさん
22/04/05 20:28:17.56 3noiRnfQ.net
いや逆や
わざわざKotlinをwebで採用する意味ないし
今もそんなことしてる会社は物好きな少数のみ

485:デフォルトの名無しさん
22/04/05 20:28:18.67 82POVtug.net
まあJavaやpythonに比べたらkotlin,swift,rustなんてまだまだでしょ
URLリンク(i.imgur.com)

486:デフォルトの名無しさん
22/04/05 20:33:11.57 3noiRnfQ.net
goは流行ってるし機能拡張していってるんやから機能不足やから廃れるってことはないやろ
つい最近genericsが導入されたやん
フレームワークにしろ何にしろ使う人が増えればより充実して行くもんよ
こういうのは流れが大事
流れがないswift、Kotlinが今更伸びることはないやろ

487:デフォルトの名無しさん
22/04/05 20:40:11.88 fN/L9gSF.net
最初の言語としてKotlinやSwiftは選びたくない

488:デフォルトの名無しさん
22/04/05 20:51:09.86 RriiMuS9.net
>>479
むしろRustだけは生き残ることが確実
Rustの以下のメリットを持つ代替言語が存在しないため
・ガベージコレクションを必要とせずC言語と同等の速さと省メモリを実現
・各種データ競合やメモリ使用の安全性を保証
・現代的な各種プログラミングパラダイムを洗練して採り入れており非常にプログラミングしやすい

489:デフォルトの名無しさん
22/04/05 20:52:42.92 fN/L9gSF.net
一番最初の言語に選びたくないNo1は今のところRustかな?
まあそんなことにはならないでしょうが
自分は最初はBASICだった
もう使うことはないと思ってたらAppleiiのエミュにBASICが入ってて
使ったことはないのに適当にやっても結構動くものが作れた

490:デフォルトの名無しさん
22/04/05 21:04:57.35 jsmatYo9.net
CからC++に行かずにRUSTに行く

491:デフォルトの名無しさん
22/04/05 21:11:03.50 ks20fz6N.net
>>487
たぶんそれが正解
スクリプト言語程度で良い用途は別として
普通にちゃんとしたプログラミングをするならばC言語で基本をまず学んだ上でRustがベストかな

492:デフォルトの名無しさん
22/04/05 21:14:31.44 jsmatYo9.net
Cからちょっとだけアセンブラ(オプションで出力させたものを解読できる程度)もありかも知れない

493:デフォルトの名無しさん
22/04/05 21:17:03.29 fN/L9gSF.net
C → Rust
その人たちは何がやりたくてプログラミングするのか疑問だなあ

494:デフォルトの名無しさん
22/04/05 21:18:27.03 /ryaTu8Q.net
>>474
Kotlinやろうとしたら必然的にJVMとJavaも勉強しないとだよね
学習コスト3倍じゃん
バカじゃん

495:デフォルトの名無しさん
22/04/05 21:18:44.27 hteyj+L8.net
システムプログラミングでしょ

496:デフォルトの名無しさん
22/04/05 21:28:32.93 8mvJZb/O.net
rustはシステムプログラミングとか、低レベルプログラミングの分野で生き残ると思いますよ
あくまで俺が話してるのはweb系の話
ちょっと主張を代えてしまうようで申し訳ないけど、俺が主張したいのは、kotlinが来るというよりも、goやrustがこの先web開発で盛り上がりを見せるとは思えないということです

497:デフォルトの名無しさん
22/04/05 21:28:36.30 jsmatYo9.net
Javaやってた人が楽したくてkotlin触るのがほとんどだと思うわ

498:デフォルトの名無しさん
22/04/05 21:32:44.23 u+FS9OX1.net
>>493
サーバーサイドに関してはpython一択になると思うよ
今の若手がpython推しなんだからそいつらが偉くなったらみんなpythonになる
現に俺が管理して利権として享受してるサービスをpythonでリプレースしようという案が出てきてる
全力で防いでるが

499:デフォルトの名無しさん
22/04/05 21:33:48.12 m6fZyHop.net
>>493
大規模ウェブサイトのバックエンドにgoやらrustやら使う事例は多いからweb系とひとくくりにするのもちょっと不正確では

500:デフォルトの名無しさん
22/04/05 21:33:58.15 MlP9V3nG.net
>>493
うちはWeb系だけどRustを使っています
WebAssemblyでRust以外に良い選択肢がないと思います
実際に一般的な調査でもWebAssemblyで使う言語の1位がRustですね

501:デフォルトの名無しさん
22/04/05 21:34:05.83 ZGNch3sg.net
FlutterとセットでDartは?

502:デフォルトの名無しさん
22/04/05 21:38:03.57 DitKiC+e.net
railsやってた人が動的型付言語で大規模開発は
もう嫌じゃーとなったときにどこに行くかねえ
JVMがgoかrustか
個人的にはgoは無いな…

503:デフォルトの名無しさん
22/04/05 21:43:41.67 fN/L9gSF.net
>>499
TSかな?

504:デフォルトの名無しさん
22/04/05 21:44:13.55 8mvJZb/O.net
>>496
そこなんですけど、今goが流行ってるのってコンテナ構成にマッチしていたり、並行処理が得意だったりメリットがあるからだと認識しています。
とは言え、goはパターンマッチングがやりにくかったり、関数の戻り値が複数あったりで、お世辞にもコーディングが快適とは言えない。
なので、goに代わるkotlinや swiftくらいのちょうどいいレベルの言語仕様の言語が出てきて、使われるようになるんじゃない、みたいな見解を持ってます。
この意見がスレタイとマッチしてなくて、申し訳なかった

505:デフォルトの名無しさん
22/04/05 21:44:21.70 u7gEIfJv.net
>>499
RubyとRustはコード記述が似てる面多いね
クロージャ(ラムダ)で |引数| になる点とか

506:デフォルトの名無しさん
22/04/05 21:47:59.27 cdGLCT5H.net
実際の流行りと5chプログラマーのrustへのお熱っぷりには乖離があると思うが
プログラマーがそれだけ好くんだから大した言語よな
go嫌いはif err != nilがキモく感じて嫌がってるのかもしれない

507:デフォルトの名無しさん
22/04/05 21:48:34.22 ZJzYuLv9.net
>>501
RustならGoの戻り値の問題はいわゆる代数的データ型となる値包含enumでシンプルかつ扱いやすく解決しているし
パターンマッチングについても同じくenum拡張されて非常に強力やな

508:デフォルトの名無しさん
22/04/05 21:54:38.07 ZwTPjiXX.net
rust信者はただサンクコスト回収のために必死になってるだけだわ。
そういう活動が逆効果ってことを全く理解していない。

509:デフォルトの名無しさん
22/04/05 22:03:45.09 oCmbM95T.net
現実問題としてRustに勝てる言語が出現してくる気配すらないのはマズいよな
当面はRustが最終解なのかもしれないが
> Rustの以下のメリットを持つ代替言語が存在しないため
> ・ガベージコレクションを必要とせずC言語と同等の速さと省メモリを実現
> ・各種データ競合やメモリ使用の安全性を保証
> ・現代的な各種プログラミングパラダイムを洗練して採り入れており非常にプログラミングしやすい

510:デフォルトの名無しさん
22/04/05 22:26:51.26 vLZKRt0y.net
どういう理屈でコスト回収するんだろ

511:デフォルトの名無しさん
22/04/05 22:49:42.89 CALU2HjK.net
信者というかワナビーじゃないの
サンクコストに感じるのは

512:デフォルトの名無しさん
22/04/05 22:56:37.28 A4DfkOI9.net
食わず嫌いのアンチがコストがかかると思い込んでいるだけではないか
むしろRustは様々なコスト削減になる
プログラミング&デバッグ開発効率が良くなるだけでなく
高速化と省メモリ化によりサーバーやクラウド類の支出コスト削減も大きい

513:デフォルトの名無しさん
22/04/05 23:13:12.17 jhOIIm2D.net
>>502
rubyしか使ってなかったときは気づかなかったが
rustも使うようになってrubyのブロックがくっつく形がキモく感じるようになった
ruby.foo {|x| x}.bar {|x| x} # ←キモい &blockが一個しか渡せない問題もある
rust.foo(|x| x).bar(|x| x, |y| y) // ←スッキリ

514:デフォルトの名無しさん
22/04/05 23:21:49.33 1v6++hVm.net
すでにC++, C#, Haskell, Scala, Rustといろいろ渡り歩いてるから
サンクコストなんて感じてないんだよなぁ
Rustの次に移行したい面白い言語が見当たらないからRustに留まってるだけで

515:デフォルトの名無しさん
22/04/05 23:22:32.66 fN/L9gSF.net
どちらにしても|x|と言う表現は個人的にはキモいと思う
洗練されていない
rubyを毛嫌いしていたのもそれと冒頭の大文字小文字でpublicかどうか決めてる部分

516:デフォルトの名無しさん
22/04/05 23:25:05.56 EpygGO7e.net
rubyはブロックを1つ渡すときのやり方に特化されてるくせにメソッドチェーンで
ブロック渡し使うとなんかキモいよな
Rubyのクロージャでも{}を省略できたら見た目が良かったかもな

517:デフォルトの名無しさん
22/04/05 23:26:31.88 /ryaTu8Q.net
実際問題、GoのerrorはEitherだから、実は最新の設計なんだよね

518:デフォルトの名無しさん
22/04/05 23:28:52.60 shnfpWMI.net
>>514
代数的データ型ならばそれを便利かつ容易に扱える様々な仕組みがないとメリットがない
Goにはそれがない
Rustにはそれがある

519:デフォルトの名無しさん
22/04/06 01:16:54.79 5q0U6A70.net
GoのマルチリターンはEitherのつもりなのにTupleだし、沼設計としては最先端なんだよな…
理想: e+v
現実: (e+1)*(v+1)=(e+v)+ev+1
結果が完全な失敗と完全な成功だけじゃないところもまた、現実のそのものである。

520:デフォルトの名無しさん
22/04/06 03:20:12.66 wPZ6Wy+h.net
>>510
ほんとここだけは直してほしい
Ruby全盛時に設計しちゃったもんだから
余計な要素が入り込んだ

521:デフォルトの名無しさん
22/04/06 06:13:11.45 X7GvwD6X.net
>>510
これなあ

522:デフォルトの名無しさん
22/04/06 07:11:19.53 XNY/VGtp.net
GUI のアプリ開発に向いてるのはどれなの?
C++やC#の次のイメージだけど。

523:デフォルトの名無しさん
22/04/06 08:28:24.14 FubAROXf.net
>>476
そういうことを言っているからRustユーザーは駄目なんだ。
ヒープもスタックもメモリ管理も知らないGC前提の高級言語のユーザーが所有権とかmoveとかを理解するまで、一体いくつ新概念を理解しなきゃいけないか。
理解を助けるメタファーもろくに無いし、「非常に簡単」はありえない。
まぁ、
>c++とhaskellあたりを学んでおけば大したことないし
とかいう発想だから、Rustユーザーは自分達がどれだけ他言語ユーザーから乖離しているか気づいていないか。

524:デフォルトの名無しさん
22/04/06 08:38:33.64 ByE3BIzU.net
Rust使い人は使えばいい
メモリ管理などの低レベルなことに専心したくないから大多数の人はGC言語を使ってるのであって
Rust必須になればみなプログラムやめるよ
メモリ管理は関心の集中先ではないからなあ

525:デフォルトの名無しさん
22/04/06 08:42:49.90 ByE3BIzU.net
使い人→使いたい人

526:デフォルトの名無しさん
22/04/06 08:59:55.51 ERAAutfZ.net
>>521
食わず嫌いで勘違いしすぎていて痛すぎる
メモリ管理するためのコードを書くのがRustだと勘違い?
例えばRustのプログラム例>>312のどこでメモリ管理してる?
メモリ管理なんて面倒なことするコードを書きたくないからRustを使うのだよ

527:デフォルトの名無しさん
22/04/06 09:01:33.33 ByE3BIzU.net
GCだったらそれすら意識しなくていい

528:デフォルトの名無しさん
22/04/06 09:03:47.07 ByE3BIzU.net
move |bits|
&

529:デフォルトの名無しさん
22/04/06 09:10:21.22 aOWfxLhU.net
>>525
それの何を問題視してるのかしら
moveはクロージャに変数キャプチャするかどうかでGC言語にもある概念
&は単なる参照でこれもGC言語にもある概念

530:デフォルトの名無しさん
22/04/06 10:56:17.94 X7GvwD6X.net
>>524
それなぁ

531:デフォルトの名無しさん
22/04/06 11:00:12.47 X7GvwD6X.net
>>521
2種類の人種がいるんだよ
自動車産業に例えたら、(1)地方の工場勤務の期間工と(2)研究開発センターのエンジニア
(1)はRustは使用しなくていい。というか理解できなくて使えない。Pythonとかで頭を使わないコード書くだけだから。例えるなら、ラインで組み立て作業を1日延々しているだけのルーチンワーク要員。
(2)はRustなどを使用してシステムプロラミングWebassemblyなどでローレイヤーや基盤を作っていく。例えるなら自動車のエンジンやデザインの設計者。

532:デフォルトの名無しさん
22/04/06 11:12:27.97 P2epzghE.net
普通のプログラマー
 PythonでもJavaScriptでもRustでも用途毎に使い分ける
似非プログラマー
 特定のスクリプト言語しか使えない

533:デフォルトの名無しさん
22/04/06 11:18:53.29 UtHY9/K6.net
このスレは期間工限定です

534:デフォルトの名無しさん
22/04/06 11:27:29.43 XB6J8/aS.net
Rustでメモリ管理はしなきゃいけないでしょw
双方向リストを普通に書くと循環参照でるよね
WeakとRcをプログラマが手動で必死に使い分けてなんとかするのがrust
一方で循環参照もなんとかケアしてくれる(かもしれない)のがGC言語
これはRustを批判するんじゃなくて
GC言語の価値を改めて評価できるという例

535:デフォルトの名無しさん
22/04/06 11:27:36.38 XNY/VGtp.net
>>530
呼ばれた気がした

536:デフォルトの名無しさん
22/04/06 11:29:06.13 PUvuY8jT.net
>>505
Rustを難しいと勝手に思い込んでいるようだけどそれは勘違い
C言語とあともう一つ今どきのプログラミングパラダイムを備えた言語を使いこなせる人ならばRustは容易に楽に習得できる
つまり普通にまともなプログラマーにとっては難しいことは何もない

537:デフォルトの名無しさん
22/04/06 11:32:57.60 SQHVCoBe.net
>>531
双方向リストなんてライブラリにあるのを使うだけだからそんなの関係ないだろ
同様にベクターコンテナもライブラリにあるのをそのまま使うだけ
それとも君は毎回自作してるのかね?

538:デフォルトの名無しさん
22/04/06 11:38:59.86 XB6J8/aS.net
RustにGCが無いのは特徴であり
この言語の方向性においては利点でしかない思ってるよ
GC無しでRAIIでなんとかしていこうず!という潔い言語
中途半端にならなくて清々しいよ

539:デフォルトの名無しさん
22/04/06 11:41:06.57 j3mCjXSb.net
>>531
GC言語とはガベージコレクションが必須な言語
一方でC/C++/RustはGCが必須ではなくGCが必要な用途の時だけGCすればよい言語
だからどうしても循環参照などでGCが必要ならばC/C++/RustでもGCをするモジュールなどが用いられている

540:デフォルトの名無しさん
22/04/06 11:42:07.19 azRXBWjT.net
>>528 >>529
>>471が「RustがPythoneを置き換える」とかいう妄想を垂れ流しているから突っ込んだだけだよ。
バカはトンカチを持つと何でも釘に見えると言うけど、Rustユーザーはその典型だな。

541:デフォルトの名無しさん
22/04/06 11:46:18.46 iij/35sY.net
>>531
またそんなデマカセを書いてるな
ヤラセ記事ならともかく実際のプログラムでそんな変な実装をしている例を見たことがない
妄想で叩くのはやめとけ

542:デフォルトの名無しさん
22/04/06 11:46:52.40 azRXBWjT.net
>>533
C言語とあともう一つ今どきのプログラミングパラダイムを備えた言語を使いこなせる人……つまり普通にまともなプログラマー
なるほど、PythoneやJavaだけを使っているプログラマーは普通でもまともでも無いということを主張したいんだな。

543:デフォルトの名無しさん
22/04/06 11:50:43.24 yFuiayyW.net
>>537
でもその人の書き込みを見たら
Web分野と限定してるね
Web分野でのPythonなんてPythonしか使えない人しか採用しない状況だから
話としては合ってるんじゃないかな

544:デフォルトの名無しさん
22/04/06 11:54:58.50 YS4iOCfL.net
>>539
それはそうやろw
Javaしか出来ないなら土方で間違いない

545:デフォルトの名無しさん
22/04/06 12:32:21.96 rwS/Q696.net
>>540
webでもPython置き換えとしてRustが出てくることは無い。
web用途だからといって所有権だのスコープ・ライフタイムだのを回避できるわけじゃないしな。
>>541
Rustユーザーが初心者・初級者を馬鹿にするようじゃなぁ。Rustの失敗は約束されたな。

546:デフォルトの名無しさん
22/04/06 12:44:42.90 4NhGLksY.net
>>542
意味不明だな
唐突に所有権とか言い出して何が言いたいんだ?

547:デフォルトの名無しさん
22/04/06 12:58:29.92 6roFDaHL.net
>>536
えっ・・・?GCがないからRust最強他はクソじゃなかったんですか?(´∵`)
どこぞのチンカスメンがマス書いた野良イブラリでGCとかRustユーザーのおじさんたちって・・・(´∵`)

548:デフォルトの名無しさん
22/04/06 13:56:24.32 2Yw46+Tv.net
>>544
RustやC++は非GC言語やで

549:デフォルトの名無しさん
22/04/06 14:20:43.99 1nRPgXLc.net
また意味不明の非GC言語なんて言い出してんのかw、リファレンスカウント使ってんだからそんな意味のない宣伝もうやめろよ?

550:デフォルトの名無しさん
22/04/06 14:36:07.84 6roFDaHL.net
は?今の時代にリファカンとかw

551:デフォルトの名無しさん
22/04/06 14:41:06.01 6A9Aeuem.net
ここはおじさんスレだからそれを楽しめ

552:デフォルトの名無しさん
22/04/06 14:46:08.13 Fm2KF3vu.net
参照カウントのガベージコレクション
URLリンク(developer.mozilla.org)
これは、最も素朴なガベージコレクションアルゴリズムです。このアルゴリズムは、"あるオブジェクトがもはや必要ない"ことを、"あるオブジェクトがその他のオブジェクトから参照されていない"ことと定義します。あるオブジェクトは、それに対する参照がゼロの時にガベージコレクト可能であると見なされます。

553:デフォルトの名無しさん
22/04/06 14:48:22.40 7ui2nPA0.net
>>517
引数の最後のブロックを特別扱いで記述できる文法はrubyからgroovyを経由してkotlinにも引き継がれていて、わりと欠かせない記述方法になってる
ここの URLリンク(dogwood008.github.io)
これみたいな記法を頻繁に使うからいまさら無くなっても困る
lock (lock) {
sharedResource.operation()
}

554:デフォルトの名無しさん
22/04/06 14:57:27.14 rwS/Q696.net
>>543
スレの流れが追えていないのに口を出すなよ。最初の方の>470 >471 >475から所有権出てるわ。
ChMateとか導入したら?

555:デフォルトの名無しさん
22/04/06 23:24:49.88 DtmD4s0L.net
>>551
その所有権がどうしたんだい?
所有権が理解できないなら参照も理解できないから
参照渡しと値渡しの区別もつかないことになる
どの言語でもそういう話は理解しないと使えないから
所有権の概念があるかどうかで困るプログラマーは存在しない

556:デフォルトの名無しさん
22/04/06 23:41:02.75 6roFDaHL.net
コードの所有権もない派遣さんが何か言ってらw

557:デフォルトの名無しさん
22/04/07 01:43:23.21 tEZE72Zs.net
#[derive(Clone, Copy)]
struct Code(String);

558:デフォルトの名無しさん
22/04/07 07:31:09.34 zb08jYei.net
>>552
こういうRustユーザーが多いなら、RustのHaskell化は約束されたようなものだな。
Rustコミュニティー全体がその認識なら致命的かと。

559:デフォルトの名無しさん
22/04/07 07:42:19.84 wRPEswS2.net
Rustは当面プログラミング言語の王者として君臨し続けるのではないか
高速かつ省メモリかつ安全という他の言語が満たせないRustのアドバンテージを崩せる新言語が登場しない限り
> Rustの以下のメリットを持つ代替言語が存在しないため
> ・ガベージコレクションを必要とせずC言語と同等の速さと省メモリを実現
> ・各種データ競合やメモリ使用の安全性を保証
> ・現代的な各種プログラミングパラダイムを洗練して採り入れており非常にプログラミングしやすい

560:デフォルトの名無しさん
22/04/07 08:03:31.90 /n3eSctb.net
俺はRustは廃れるに一票
このスレ見てる限り信者がカルトすぎる
Go信者が可愛く見えるレベル
そもそも設計で差を付けられるレベルなら、言語に拘る意味もそこまでない
このスレがそういう趣旨だというのもあるとは思うが、言語への執着が酷すぎ

561:デフォルトの名無しさん
22/04/07 08:10:05.04 zl/syFdq.net
はっきり言って近代的な言語なら仕様も習得もそのコーディングもどの言語でも大差ないんよ
そうなると言語自体として本質的な有利な面を持つRustがじわじわと広まる結果となるかな

562:デフォルトの名無しさん
22/04/07 08:56:02.87 /n3eSctb.net
>>558
> どの言語でも大差ない
だから敢えて独自路線を、というのがGoの当初の目的でもあったろ
(上手く行ってるかは別)
> 本質的な有利な面を持つRust
俺はあれは筋が悪いと見てる
寿命管理はmoveではなくupが多分正解で、これを綺麗に書ける言語が出てきたらその瞬間終わる
(それ以前にGCの方がいいが)
あとRustの問題は、多分プログラマが上達しない事
これは長期的には絶望的に不味い
「C++はプログラマを育てる言語だ」というのはC++始祖の持論だが、これは考える事を強いるからだ
Rustの場合は(このスレ見る限り)「コンパイラが全てやってくれる!考えなくて済む!」のノリのようで、これは絶望的
Rustは「C++の特定の使い方」に近似出来、コンパイラがその形式を強制する
だからC++をこの形式で使っている連中は確実に移行する
そうではないC++使いが移行する事はない
Rustを使えばデバッグしなくて済むから楽!とか言ってる初心者連中は戦力にならない
というかね、根本的なところで、寿命管理や所有権とかは「面倒」であって「苦労」はしない
だからやらなくて済むのならそれが一番いいが、
やれと言われればやるだけであり、手間が増えるだけで、出来ないものでもなく、それ自体には苦労もしない
だから根本的な立ち位置がイマイチなんだよRustは
そしてこれに苦労するような連中は、そもそもプログラミング能力が低いだけなのだから、
そこで苦労する事は糧となるから頑張れ、でもある
これが無理だからGCを使うのだ、という事に対しても俺は肯定的で、それでいいと思うが、
Rustが目指しているのは「GCが無いと困る馬鹿でも補助輪を付けてチェックするからなんとかなり、
GC無し並の速度が出ます」であって、結局は馬鹿向けの補助輪でしかない
そこで苦労する程度ならガチでC++で苦労した方が上達するからそうしろ、でしかない
(まあ馬鹿でも何とかなるように、というのが言語の進歩でもあるのだが)

563:デフォルトの名無しさん
22/04/07 08:56:07.07 hOTZf/Ps.net
言語の普及について語るときにキラーアプリを語ればいいと思う
Rubyが普及したのはRuby on Railsがあったから。
Pythonが普及したのはAIライブラリ(tensorflowなど)があったか。
RustにはRubyのRoRやpythonのAIに相当するものがあるか?もしくはこれからでてくるか?
そのヒントとしてはWebAssemblyにあるように思う。

564:デフォルトの名無しさん
22/04/07 09:01:27.48 5wMGrsUW.net
 :::....   /|\||   
     //|'\\.... ...:::.. .......
    |/ ,'|-、 \\
    |/ ,'|-、 \\\
    |/ ,'|-、 \\\|.... ...:::.. .......
    |/ ,'|-、 \\\|:..。..... ...:::.. .......
    |/ ,'|-、 \\\|__|
    |/ ,'|-、 \\\|:...|ヽ .... ...:::.. .......
    |/ ,'|-、 \\\|::::| |::..... 
 | ̄ ̄ ̄ ̄ ̄\、'\\|;;:.|_,,|___   
 | □□ □□ | |\, \|;;::....     |\
 | □□ □□ | |  | ̄ ̄ ̄ ̄|\;: . |  |
 | □□ □□ | |  |□□□□|  |::...|  |;;:
 | □□ □□ | |  |□□□□|  |::...|  |:;:./
 | □□ □□ | |  |□□□□|  |::...|  /
 | □□ □□ |.._|__,,|□□□□|  |::...|/  
,,| ̄ ̄ ̄|| ̄ ̄\≡\,□□□|/ ,/
今北産業 [IMAKITA INDUSTRIAL CO.,LTD]
     (1978~ 日本)

565:デフォルトの名無しさん
22/04/07 09:02:23.11 qcT6PBEO.net
RustのようにCと同等の速さと省メモリの言語が出てくればRustが敗れる可能性が出てくる
現時点では存在しないためRustの天下が続きそう

566:デフォルトの名無しさん
22/04/07 09:26:02.84 /n3eSctb.net
>>560
> WebAssembly
ねえよ馬鹿タレ
というかこのWebAssembly推しは一体何なん?
シェア的にもあり得ないし、ググラビリティもJSに比してゴミ以下だろ
Webの場合はそもそもクライアントサイドで何が出来て何をやるべきかが分かってない事が多く、
つまり、他言語で既に十分出来てる連中でもクライアントサイドを書く時には、まずこれを理解せねばならず、
一番手っ取り早いのはJSであり、これを避けては通れない
JS/TSである程度クライアントサイドをこなしてからなら他言語でWebAssemblyでもいいが、
JSに比してググラビリティも0に近いWebAssemblyでクライアントサイド入門とか、ただの自殺
俺はWebAssembly推しは完全にミスリードで、糾弾されるべきだと思ってるよ
この状況で、JSに比してWebAssemblyが主流になる状況は、現在のところあり得ない
だいたい、Rustをわざわざ学んでWebAssemblyするくらいなら、上記のようにそれ以前にJSを通るし、
ほぼ全部のサイトでJSで十分だからこそ圧倒的シェアになってる
元々JSだったのは「ソースじゃないと信頼出来ない」という事であり、
それが「最早そういう状況ではないのでバイナリでもいい。速さ重要」となってきているからこそのWebAssemblyではあるが、
ならばそのうち「もうネイティブバイナリでよくね?サンドボックスを仮想的に作ろう。これが最速」となって、
ネイティブバイナリをブラウザ内で実行する状況になって終わると思うけど
仮想周りは本当に進歩したし、何故か知らんがアメリカ人はエミュには執着するしで、これも時間の問題

567:デフォルトの名無しさん
22/04/07 09:37:09.90 Nyl3OsEM.net
確かにWebAssemblyではガベージコレクションのないRustが一強になってるな
WebAssemblyにおいてreference typeがサポートされたためDOM操作の壁が大きく低くなり実用的となったことも大きい
今後Rustによるフロントエンドが更に進むことが確実となった

568:デフォルトの名無しさん
22/04/07 10:03:19.72 6mRJTF59.net
>>559
世にあるc/c++メモリ周りの扱いによるバグやセキュリティホールの殆どは、「GCがないと困るバカ」以外の人間が書いているわけだが。

569:デフォルトの名無しさん
22/04/07 10:10:10.15 hOTZf/Ps.net
>>563
おまえが(1)のタイプだということはわかったから黙ってくれw
(1)はRustは使用しなくていい。というか理解できなくて使えない。Pythonとかで頭を使わないコード書くだけだから。例えるなら、ラインで組み立て作業を1日延々しているだけのルーチンワーク要員。
(2)はRustなどを使用してシステムプロラミングWebassemblyなどでローレイヤーや基盤を作っていく。例えるなら自動車のエンジンやデザインの設計者。

570:デフォルトの名無しさん
22/04/07 10:18:58.15 /n3eSctb.net
>>564
> 確かにWebAssemblyではガベージコレクションのないRustが一強になってるな
今は、だろ
> (WebAssembly は将来的にガベージコレクションによるメモリー管理を行う言語をサポートする 高レベルの目標 を持っている事に注意してください)。
> URLリンク(developer.mozilla.org)
要するに今はGCの直接サポートがないから
GC言語だと436のようにGC部分も自前で用意してやる必要があるが、
直接サポートされれば丸々この部分は落とせ、436も完全に
「Rubyでもクライアントサイドが書ける」と言ってもいいくらいの物になるのだろうよ
この意味では、Ruby(436)のアプローチは正しい
とはいえ、肝心の(上記リンクの先)
> URLリンク(webassembly.org)
に「GCをこれからサポートする予定です!」という記述がないのだが、これは落とされたのか?
落とされてないのなら、サポート後はJS嫌いな奴はRyby/Python等でクライアントサイドを書くのも既定路線
ガチ最速目指すのならC++で書くのも既定路線
Rustは「『C++では無理な馬鹿にとっては』最速」というだけであり、この冠詞が取れない限り厳しいよ
C++はWebをやろうとしてないだけであって、出来ないわけではないので
RoRの状況知らんが、もしかして一番喜んでるのはRoRの連中かもよ?
これまで全部サーバーサイドレンダリングするか、諦めてJS書くかしかなかったのが、
Rubyで全て完結するようになるから。
(既にasm.js使ってJSは書いてないかもしれんが)

571:デフォルトの名無しさん
22/04/07 10:23:06.36 /n3eSctb.net
>>565
> メモリ周りの扱いによるバグやセキュリティホールの殆ど
具体的にはどんな奴よ?
そしてそれがRustやJava等だと「自動的に」「どんな馬鹿が書いても」大丈夫だとでも?

572:デフォルトの名無しさん
22/04/07 10:29:46.01 FJnsEJOV.net
WebAssemblyでなぜ利用トップがRustで2位がC++なのか?
理由は簡単でGC言語は圧倒的に不利であるため
またWebAssembly自体でのGC導入が問題点多すぎで当面無くなったことも大きい
次になぜC++ではなくRustが1位なのか?
理由は簡単でRustの方が圧倒的にプログラミングしやすいため
Rustが有利なこと自体はWebAssembly以外の分野でも全く同じだが歴史の積み重ねの差がまだある
歴史的に新しいWebAssemblyでは後発言語の不利な点がないためRust有利が顕著に現れた

573:デフォルトの名無しさん
22/04/07 10:33:32.72 /n3eSctb.net
>>566
Rust信者は(1)のくせに(2)を気取ってる、勘違い意識高い系馬鹿だね
(2)なら最初からC++を使うし、そのスタイルがRustで強制しているスタイルと合致してれば、
これまた迷うことなく最初からRustを使うし、移行にも躊躇ない
だから正直、ここで信者がやってる布教なんて全く意味ないと思うんだけどな
ウザイだけで

574:デフォルトの名無しさん
22/04/07 11:27:45.58 wigEobQO.net
ビックテックがこぞって使ってるんだからほっといてもある程度は流行るでしょ
俺は楽に稼ぎたいしみんなにもそうなってほしいからRust推してるわ

575:デフォルトの名無しさん
22/04/07 11:35:37.24 gomi3ocO.net
>>570
決めつけは低能のあかし

576:デフォルトの名無しさん
22/04/07 11:37:41.07 QfJTmIv3.net
>>557
> 俺はRustは廃れるに一票
キミの投票はキミのカーチャンにでも見てもらってください
キミのカーチャン以外はそんな一票になんの興味も無いので

577:デフォルトの名無しさん
22/04/07 12:20:35.64 pGmXk0tm.net
Rustは順調にhaskell化しているな。
いい傾向だ。

578:デフォルトの名無しさん
22/04/07 12:40:08.52 OdIUq1Z2.net
Rustはプログラミング言語にとって根源的に重要な要素「データ競合やメモリ扱いで安全性が保証される」及び「C言語と同様に最高速&省メモリ」を両立する唯一の言語
新たな言語が出現しないとRust最優位は崩れないのではないか

579:デフォルトの名無しさん
22/04/07 13:09:09.76 a0EStXea.net
Ruby on Rails 7 で、脱Node.js, Webpack, Babel。
IE の死滅により、ES5 へ変換しなくても、ブラウザはES6 のままで動く
WebSocket を使う、Hotwire で、
近年、React に奪われたシェアを回復すべく、
SPA のgame changer を目指すのが、Railsの野望!
Rubyだけで、SPA になったから、React, Vue.js は今後どうなるのか?
Railsが、SPAのシェアを奪えるか

580:デフォルトの名無しさん
22/04/07 13:44:56.72 tEZE72Zs.net
>>564
RustWasmでDOM操作まともにやれるならやってみたいなと思って最近調べてるんだけど、
URLリンク(zenn.dev)
によるとReference Typesを使うとむしろパフォーマンスは下がるらしいし、JSにはまだ到底及ばないらしいんだよね
実際使ってみての感想とか、↑のベンチ取り方おかしいわヴォケとかあったら聞きたいんだけど、どう?

581:デフォルトの名無しさん
22/04/07 14:06:25.86 WjxXuLmC.net
Rustの話は専用スレ立ててそっちでやれよ
ウザイにもほどがある

582:デフォルトの名無しさん
22/04/07 14:34:20.48 86kfLMWB.net
>>578
それはWebのDOM要素とWebAssemblyでのReference Typesの話だろ
Rustなどの特定の言語の話じゃない
それすら理解できないやつが的外れな文句を言うな

583:デフォルトの名無しさん
22/04/07 14:43:19.94 hOTZf/Ps.net
>>578
そんな言論統制したら比較すれの意味がなるなるだろ
Rustの話を禁止したらここはGoの話題だけになりGoがRustに比べてはやってるんの?って勘違いする人がでてくる

584:デフォルトの名無しさん
22/04/07 17:08:40.53 6pGOygc2.net
>>580
実際そうだし何の問題もない。

585:デフォルトの名無しさん
22/04/07 17:13:11.30 uI5WJg3m.net
>>580
Rustは習得が簡単とか大嘘つくやついるしなぁ。
話題にするのはいいけど嘘八百はいかんよ。

586:デフォルトの名無しさん
22/04/07 17:15:20.82 pxHwe1Kf.net
>>582
Rustは簡単やろ
どこが難しい?

587:デフォルトの名無しさん
22/04/07 17:23:30.39 uI5WJg3m.net
>>583
所有権、ライフタイム、moveセマンティック、参照・借用、型システム、その他もろもろの概念を「ほとんど全部使わないと」まともなプログラムができないところ。
だから「C++とHaskellが使えればRustは簡単」とかいうアホなコメントが出てくる。

588:デフォルトの名無しさん
22/04/07 17:57:35.76 +6isarPd.net
>>584
僭越ながら横から失礼しますが、概念の数は学習の難易度とは比例しません。
個別の概念を合わせた結果、目的の用途に合致するようになるかどうかのほうが重要かと思います。
機械語だったら概念の数がRustとGoよりもずっと少なくなると思いますが、機械語を使えばプログラミングしやすくなると思いますか?

589:デフォルトの名無しさん
22/04/07 17:58:57.87 K7k5hu80.net
なるでしょ
文法が少ないからGoは誰でも簡単に使えるのだから

590:デフォルトの名無しさん
22/04/07 18:23:34.25 6J24GmAj.net
>>568
全ての問題が解決すると思ってるのは馬鹿なので相手にしなくて良い
ゼロイチの議論しかしない人もそう
人間誰しも馬鹿な間違いをする可能性があって、間違いを見逃す頻度を大きく下げられることに価値がある

591:デフォルトの名無しさん
22/04/07 18:37:02.12 D5y31O0v.net
>>586
でも両方書ける人はGoよりRustの方がプログラミングしやすいと100%答える現実を見ると
Goは言語機能不足という感じやね

592:デフォルトの名無しさん
22/04/07 18:50:26.86 6pGOygc2.net
>>588
>でも両方書ける人はGoよりRustの方がプログラミングしやすいと100%答える現実を見ると
そんな現実はお前の脳内にしかない。


次ページ
最新レス表示
レスジャンプ
類似スレ一覧
スレッドの検索
話題のニュース
おまかせリスト
オプション
しおりを挟む
スレッドに書込
スレッドの一覧
暇つぶし2ch