[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2ch.scのread.cgiへ]
Update time : 12/19 17:51 / Filesize : 321 KB / Number-of Response : 1030
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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



1 名前:デフォルトの名無しさん [2022/03/22(火) 03:23:41.60 ID:ZDHdo9X7.net]
スレタイ以外の言語もok

前スレ
次世代言語23 Go Nim Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1638086359/

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

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

482 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 20:25:45.56 ID:8mvJZb/O.net]
kotlinとjavaは相互運用可能なのに、わざわざjavaを選択する発想なんて出てこないだろ

goは学習コスト低い分、この先流行りに乗って採用する企業は増えるかも知れんが、機能不足故にいずれ見離されるんじゃない?

rustは初心者には複雑すぎるし、それこそweb開発でメリットがあまりない

kotlinはともかく、rustやgoが10年先も使われるイメージが想像できない

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

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

485 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 20:28:18.67 ID:82POVtug.net]
まあJavaやpythonに比べたらkotlin,swift,rustなんてまだまだでしょ

https://i.imgur.com/1uhp9kc.png

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

487 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 20:40:11.88 ID:fN/L9gSF.net]
最初の言語としてKotlinやSwiftは選びたくない

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



489 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 20:52:42.92 ID:fN/L9gSF.net]
一番最初の言語に選びたくないNo1は今のところRustかな?
まあそんなことにはならないでしょうが

自分は最初はBASICだった

もう使うことはないと思ってたらAppleiiのエミュにBASICが入ってて
使ったことはないのに適当にやっても結構動くものが作れた

490 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 21:04:57.35 ID:jsmatYo9.net]
CからC++に行かずにRUSTに行く

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

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

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

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

495 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 21:18:44.27 ID:hteyj+L8.net]
システムプログラミングでしょ

496 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 21:28:32.93 ID:8mvJZb/O.net]
rustはシステムプログラミングとか、低レベルプログラミングの分野で生き残ると思いますよ
あくまで俺が話してるのはweb系の話

ちょっと主張を代えてしまうようで申し訳ないけど、俺が主張したいのは、kotlinが来るというよりも、goやrustがこの先web開発で盛り上がりを見せるとは思えないということです

497 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 21:28:36.30 ID:jsmatYo9.net]
Javaやってた人が楽したくてkotlin触るのがほとんどだと思うわ

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



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

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

501 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 21:34:05.83 ID:ZGNch3sg.net]
FlutterとセットでDartは?

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

個人的にはgoは無いな…

503 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 21:43:41.67 ID:fN/L9gSF.net]
>>499
TSかな?

504 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 21:44:13.55 ID:8mvJZb/O.net]
>>496
そこなんですけど、今goが流行ってるのってコンテナ構成にマッチしていたり、並行処理が得意だったりメリットがあるからだと認識しています。

とは言え、goはパターンマッチングがやりにくかったり、関数の戻り値が複数あったりで、お世辞にもコーディングが快適とは言えない。
なので、goに代わるkotlinや swiftくらいのちょうどいいレベルの言語仕様の言語が出てきて、使われるようになるんじゃない、みたいな見解を持ってます。
この意見がスレタイとマッチしてなくて、申し訳なかった

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

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

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

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



509 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 22:03:45.09 ID:oCmbM95T.net]
現実問題としてRustに勝てる言語が出現してくる気配すらないのはマズいよな
当面はRustが最終解なのかもしれないが

> Rustの以下のメリットを持つ代替言語が存在しないため
> ・ガベージコレクションを必要とせずC言語と同等の速さと省メモリを実現
> ・各種データ競合やメモリ使用の安全性を保証
> ・現代的な各種プログラミングパラダイムを洗練して採り入れており非常にプログラミングしやすい

510 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 22:26:51.26 ID:vLZKRt0y.net]
どういう理屈でコスト回収するんだろ

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

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

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

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

515 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 23:22:32.66 ID:fN/L9gSF.net]
どちらにしても|x|と言う表現は個人的にはキモいと思う
洗練されていない

rubyを毛嫌いしていたのもそれと冒頭の大文字小文字でpublicかどうか決めてる部分

516 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 23:25:05.56 ID:EpygGO7e.net]
rubyはブロックを1つ渡すときのやり方に特化されてるくせにメソッドチェーンで
ブロック渡し使うとなんかキモいよな

Rubyのクロージャでも{}を省略できたら見た目が良かったかもな

517 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 23:26:31.88 ID:/ryaTu8Q.net]
実際問題、GoのerrorはEitherだから、実は最新の設計なんだよね

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



519 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 01:16:54.79 ID:5q0U6A70.net]
GoのマルチリターンはEitherのつもりなのにTupleだし、沼設計としては最先端なんだよな…

理想: e+v
現実: (e+1)*(v+1)=(e+v)+ev+1

結果が完全な失敗と完全な成功だけじゃないところもまた、現実のそのものである。

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

521 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 06:13:11.45 ID:X7GvwD6X.net]
>>510
これなあ

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

523 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 08:28:24.14 ID:FubAROXf.net]
>>476
そういうことを言っているからRustユーザーは駄目なんだ。
ヒープもスタックもメモリ管理も知らないGC前提の高級言語のユーザーが所有権とかmoveとかを理解するまで、一体いくつ新概念を理解しなきゃいけないか。
理解を助けるメタファーもろくに無いし、「非常に簡単」はありえない。

まぁ、
>c++とhaskellあたりを学んでおけば大したことないし
とかいう発想だから、Rustユーザーは自分達がどれだけ他言語ユーザーから乖離しているか気づいていないか。

524 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 08:38:33.64 ID:ByE3BIzU.net]
Rust使い人は使えばいい

メモリ管理などの低レベルなことに専心したくないから大多数の人はGC言語を使ってるのであって
Rust必須になればみなプログラムやめるよ

メモリ管理は関心の集中先ではないからなあ

525 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 08:42:49.90 ID:ByE3BIzU.net]
使い人→使いたい人

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

527 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 09:01:33.33 ID:ByE3BIzU.net]
GCだったらそれすら意識しなくていい

528 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 09:03:47.07 ID:ByE3BIzU.net]
move |bits|

&



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

530 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 10:56:17.94 ID:X7GvwD6X.net]
>>524
それなぁ

531 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 11:00:12.47 ID:X7GvwD6X.net]
>>521
2種類の人種がいるんだよ

自動車産業に例えたら、(1)地方の工場勤務の期間工と(2)研究開発センターのエンジニア

(1)はRustは使用しなくていい。というか理解できなくて使えない。Pythonとかで頭を使わないコード書くだけだから。例えるなら、ラインで組み立て作業を1日延々しているだけのルーチンワーク要員。

(2)はRustなどを使用してシステムプロラミングWebassemblyなどでローレイヤーや基盤を作っていく。例えるなら自動車のエンジンやデザインの設計者。

532 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 11:12:27.97 ID:P2epzghE.net]
普通のプログラマー
 PythonでもJavaScriptでもRustでも用途毎に使い分ける

似非プログラマー
 特定のスクリプト言語しか使えない

533 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 11:18:53.29 ID:UtHY9/K6.net]
このスレは期間工限定です

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

これはRustを批判するんじゃなくて
GC言語の価値を改めて評価できるという例

535 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 11:27:36.38 ID:XNY/VGtp.net]
>>530
呼ばれた気がした

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

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

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



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

540 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 11:42:07.19 ID:azRXBWjT.net]
>>528 >>529

>>471が「RustがPythoneを置き換える」とかいう妄想を垂れ流しているから突っ込んだだけだよ。

バカはトンカチを持つと何でも釘に見えると言うけど、Rustユーザーはその典型だな。

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

542 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 11:46:52.40 ID:azRXBWjT.net]
>>533
C言語とあともう一つ今どきのプログラミングパラダイムを備えた言語を使いこなせる人……つまり普通にまともなプログラマー

なるほど、PythoneやJavaだけを使っているプログラマーは普通でもまともでも無いということを主張したいんだな。

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

544 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 11:54:58.50 ID:YS4iOCfL.net]
>>539
それはそうやろw
Javaしか出来ないなら土方で間違いない

545 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 12:32:21.96 ID:rwS/Q696.net]
>>540
webでもPython置き換えとしてRustが出てくることは無い。
web用途だからといって所有権だのスコープ・ライフタイムだのを回避できるわけじゃないしな。

>>541
Rustユーザーが初心者・初級者を馬鹿にするようじゃなぁ。Rustの失敗は約束されたな。

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

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

548 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 13:56:24.32 ID:2Yw46+Tv.net]
>>544
RustやC++は非GC言語やで



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

550 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 14:36:07.84 ID:6roFDaHL.net]
は?今の時代にリファカンとかw

551 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 14:41:06.01 ID:6A9Aeuem.net]
ここはおじさんスレだからそれを楽しめ

552 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 14:46:08.13 ID:Fm2KF3vu.net]
参照カウントのガベージコレクション
https://developer.mozilla.org/ja/docs/Web/JavaScript/Memory_Management#reference-counting_garbage_collection

これは、最も素朴なガベージコレクションアルゴリズムです。このアルゴリズムは、"あるオブジェクトがもはや必要ない"ことを、"あるオブジェクトがその他のオブジェクトから参照されていない"ことと定義します。あるオブジェクトは、それに対する参照がゼロの時にガベージコレクト可能であると見なされます。

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

554 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 14:57:27.14 ID:rwS/Q696.net]
>>543
スレの流れが追えていないのに口を出すなよ。最初の方の>470 >471 >475から所有権出てるわ。

ChMateとか導入したら?

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

556 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 23:41:02.75 ID:6roFDaHL.net]
コードの所有権もない派遣さんが何か言ってらw

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

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



559 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 07:42:19.84 ID:wRPEswS2.net]
Rustは当面プログラミング言語の王者として君臨し続けるのではないか
高速かつ省メモリかつ安全という他の言語が満たせないRustのアドバンテージを崩せる新言語が登場しない限り

> Rustの以下のメリットを持つ代替言語が存在しないため
> ・ガベージコレクションを必要とせずC言語と同等の速さと省メモリを実現
> ・各種データ競合やメモリ使用の安全性を保証
> ・現代的な各種プログラミングパラダイムを洗練して採り入れており非常にプログラミングしやすい

560 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 08:03:31.90 ID:/n3eSctb.net]
俺はRustは廃れるに一票
このスレ見てる限り信者がカルトすぎる
Go信者が可愛く見えるレベル

そもそも設計で差を付けられるレベルなら、言語に拘る意味もそこまでない
このスレがそういう趣旨だというのもあるとは思うが、言語への執着が酷すぎ

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

562 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 08:56:02.87 ID:/n3eSctb.net]
>>558
> どの言語でも大差ない
だから敢えて独自路線を、というのがGoの当初の目的でもあったろ
(上手く行ってるかは別)

> 本質的な有利な面を持つRust
俺はあれは筋が悪いと見てる
寿命管理はmoveではなくupが多分正解で、これを綺麗に書ける言語が出てきたらその瞬間終わる
(それ以前にGCの方がいいが)

あとRustの問題は、多分プログラマが上達しない事
これは長期的には絶望的に不味い
「C++はプログラマを育てる言語だ」というのはC++始祖の持論だが、これは考える事を強いるからだ
Rustの場合は(このスレ見る限り)「コンパイラが全てやってくれる!考えなくて済む!」のノリのようで、これは絶望的

Rustは「C++の特定の使い方」に近似出来、コンパイラがその形式を強制する
だからC++をこの形式で使っている連中は確実に移行する
そうではないC++使いが移行する事はない
Rustを使えばデバッグしなくて済むから楽!とか言ってる初心者連中は戦力にならない

というかね、根本的なところで、寿命管理や所有権とかは「面倒」であって「苦労」はしない
だからやらなくて済むのならそれが一番いいが、
やれと言われればやるだけであり、手間が増えるだけで、出来ないものでもなく、それ自体には苦労もしない
だから根本的な立ち位置がイマイチなんだよRustは
そしてこれに苦労するような連中は、そもそもプログラミング能力が低いだけなのだから、
そこで苦労する事は糧となるから頑張れ、でもある

これが無理だからGCを使うのだ、という事に対しても俺は肯定的で、それでいいと思うが、
Rustが目指しているのは「GCが無いと困る馬鹿でも補助輪を付けてチェックするからなんとかなり、
GC無し並の速度が出ます」であって、結局は馬鹿向けの補助輪でしかない
そこで苦労する程度ならガチでC++で苦労した方が上達するからそうしろ、でしかない
(まあ馬鹿でも何とかなるように、というのが言語の進歩でもあるのだが)

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

564 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 09:01:27.48 ID:5wMGrsUW.net]
 :::....   /|\||   
     //|'\\.... ...:::.. .......
    |/ ,'|-、 \\
    |/ ,'|-、 \\\
    |/ ,'|-、 \\\|.... ...:::.. .......
    |/ ,'|-、 \\\|:..。..... ...:::.. .......
    |/ ,'|-、 \\\|__|
    |/ ,'|-、 \\\|:...|ヽ .... ...:::.. .......
    |/ ,'|-、 \\\|::::| |::..... 
 | ̄ ̄ ̄ ̄ ̄\、'\\|;;:.|_,,|___   
 | □□ □□ | |\, \|;;::....     |\
 | □□ □□ | |  | ̄ ̄ ̄ ̄|\;: . |  |
 | □□ □□ | |  |□□□□|  |::...|  |;;:
 | □□ □□ | |  |□□□□|  |::...|  |:;:./
 | □□ □□ | |  |□□□□|  |::...|  /
 | □□ □□ |.._|__,,|□□□□|  |::...|/  
,,| ̄ ̄ ̄|| ̄ ̄\≡\,□□□|/ ,/

今北産業 [IMAKITA INDUSTRIAL CO.,LTD]
     (1978〜 日本)

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

566 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 09:26:02.84 ID:/n3eSctb.net]
>>560
> WebAssembly
ねえよ馬鹿タレ
というかこのWebAssembly推しは一体何なん?
シェア的にもあり得ないし、ググラビリティもJSに比してゴミ以下だろ

Webの場合はそもそもクライアントサイドで何が出来て何をやるべきかが分かってない事が多く、
つまり、他言語で既に十分出来てる連中でもクライアントサイドを書く時には、まずこれを理解せねばならず、
一番手っ取り早いのはJSであり、これを避けては通れない
JS/TSである程度クライアントサイドをこなしてからなら他言語でWebAssemblyでもいいが、
JSに比してググラビリティも0に近いWebAssemblyでクライアントサイド入門とか、ただの自殺
俺はWebAssembly推しは完全にミスリードで、糾弾されるべきだと思ってるよ

この状況で、JSに比してWebAssemblyが主流になる状況は、現在のところあり得ない
だいたい、Rustをわざわざ学んでWebAssemblyするくらいなら、上記のようにそれ以前にJSを通るし、
ほぼ全部のサイトでJSで十分だからこそ圧倒的シェアになってる

元々JSだったのは「ソースじゃないと信頼出来ない」という事であり、
それが「最早そういう状況ではないのでバイナリでもいい。速さ重要」となってきているからこそのWebAssemblyではあるが、
ならばそのうち「もうネイティブバイナリでよくね?サンドボックスを仮想的に作ろう。これが最速」となって、
ネイティブバイナリをブラウザ内で実行する状況になって終わると思うけど
仮想周りは本当に進歩したし、何故か知らんがアメリカ人はエミュには執着するしで、これも時間の問題

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

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



569 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 10:10:10.15 ID:hOTZf/Ps.net]
>>563
おまえが(1)のタイプだということはわかったから黙ってくれw

(1)はRustは使用しなくていい。というか理解できなくて使えない。Pythonとかで頭を使わないコード書くだけだから。例えるなら、ラインで組み立て作業を1日延々しているだけのルーチンワーク要員。

(2)はRustなどを使用してシステムプロラミングWebassemblyなどでローレイヤーや基盤を作っていく。例えるなら自動車のエンジンやデザインの設計者。

570 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 10:18:58.15 ID:/n3eSctb.net]
>>564
> 確かにWebAssemblyではガベージコレクションのないRustが一強になってるな
今は、だろ

> (WebAssembly は将来的にガベージコレクションによるメモリー管理を行う言語をサポートする 高レベルの目標 を持っている事に注意してください)。
> https://developer.mozilla.org/ja/docs/WebAssembly/Concepts
要するに今はGCの直接サポートがないから
GC言語だと436のようにGC部分も自前で用意してやる必要があるが、
直接サポートされれば丸々この部分は落とせ、436も完全に
「Rubyでもクライアントサイドが書ける」と言ってもいいくらいの物になるのだろうよ
この意味では、Ruby(436)のアプローチは正しい

とはいえ、肝心の(上記リンクの先)
> https://webassembly.org/docs/high-level-goals/
に「GCをこれからサポートする予定です!」という記述がないのだが、これは落とされたのか?
落とされてないのなら、サポート後はJS嫌いな奴はRyby/Python等でクライアントサイドを書くのも既定路線
ガチ最速目指すのならC++で書くのも既定路線
Rustは「『C++では無理な馬鹿にとっては』最速」というだけであり、この冠詞が取れない限り厳しいよ
C++はWebをやろうとしてないだけであって、出来ないわけではないので

RoRの状況知らんが、もしかして一番喜んでるのはRoRの連中かもよ?
これまで全部サーバーサイドレンダリングするか、諦めてJS書くかしかなかったのが、
Rubyで全て完結するようになるから。
(既にasm.js使ってJSは書いてないかもしれんが)

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

572 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 10:29:46.01 ID:FJnsEJOV.net]
WebAssemblyでなぜ利用トップがRustで2位がC++なのか?
理由は簡単でGC言語は圧倒的に不利であるため
またWebAssembly自体でのGC導入が問題点多すぎで当面無くなったことも大きい

次になぜC++ではなくRustが1位なのか?
理由は簡単でRustの方が圧倒的にプログラミングしやすいため
Rustが有利なこと自体はWebAssembly以外の分野でも全く同じだが歴史の積み重ねの差がまだある
歴史的に新しいWebAssemblyでは後発言語の不利な点がないためRust有利が顕著に現れた

573 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 10:33:32.72 ID:/n3eSctb.net]
>>566
Rust信者は(1)のくせに(2)を気取ってる、勘違い意識高い系馬鹿だね

(2)なら最初からC++を使うし、そのスタイルがRustで強制しているスタイルと合致してれば、
これまた迷うことなく最初からRustを使うし、移行にも躊躇ない

だから正直、ここで信者がやってる布教なんて全く意味ないと思うんだけどな
ウザイだけで

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

575 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 11:35:37.24 ID:gomi3ocO.net]
>>570
決めつけは低能のあかし

576 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 11:37:41.07 ID:QfJTmIv3.net]
>>557
> 俺はRustは廃れるに一票

キミの投票はキミのカーチャンにでも見てもらってください
キミのカーチャン以外はそんな一票になんの興味も無いので

577 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 12:20:35.64 ID:pGmXk0tm.net]
Rustは順調にhaskell化しているな。
いい傾向だ。

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



579 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 13:09:09.76 ID: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 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 13:44:56.72 ID:tEZE72Zs.net]
>>564
RustWasmでDOM操作まともにやれるならやってみたいなと思って最近調べてるんだけど、
https://zenn.dev/igrep/articles/2021-11-wasm-reference-types
によるとReference Typesを使うとむしろパフォーマンスは下がるらしいし、JSにはまだ到底及ばないらしいんだよね
実際使ってみての感想とか、↑のベンチ取り方おかしいわヴォケとかあったら聞きたいんだけど、どう?






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧](;´∀`)<321KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef