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

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2022/03/22(火) 03:23:41.60ID:ZDHdo9X7
スレタイ以外の言語もok

前スレ
次世代言語23 Go Nim Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1638086359/
2022/04/06(水) 11:32:57.60ID:SQHVCoBe
>>531
双方向リストなんてライブラリにあるのを使うだけだからそんなの関係ないだろ
同様にベクターコンテナもライブラリにあるのをそのまま使うだけ
それとも君は毎回自作してるのかね？
2022/04/06(水) 11:38:59.86ID:XB6J8/aS
RustにGCが無いのは特徴であり
この言語の方向性においては利点でしかない思ってるよ
GC無しでRAIIでなんとかしていこうず！という潔い言語
中途半端にならなくて清々しいよ
2022/04/06(水) 11:41:06.57ID:j3mCjXSb
>>531
GC言語とはガベージコレクションが必須な言語
一方でC/C++/RustはGCが必須ではなくGCが必要な用途の時だけGCすればよい言語
だからどうしても循環参照などでGCが必要ならばC/C++/RustでもGCをするモジュールなどが用いられている
2022/04/06(水) 11:42:07.19ID:azRXBWjT
>>528 >>529

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

バカはトンカチを持つと何でも釘に見えると言うけど、Rustユーザーはその典型だな。
2022/04/06(水) 11:46:18.46ID:iij/35sY
>>531
またそんなデマカセを書いてるな
ヤラセ記事ならともかく実際のプログラムでそんな変な実装をしている例を見たことがない
妄想で叩くのはやめとけ
2022/04/06(水) 11:46:52.40ID:azRXBWjT
>>533
C言語とあともう一つ今どきのプログラミングパラダイムを備えた言語を使いこなせる人……つまり普通にまともなプログラマー

なるほど、PythoneやJavaだけを使っているプログラマーは普通でもまともでも無いということを主張したいんだな。
2022/04/06(水) 11:50:43.24ID:yFuiayyW
>>537
でもその人の書き込みを見たら
Web分野と限定してるね
Web分野でのPythonなんてPythonしか使えない人しか採用しない状況だから
話としては合ってるんじゃないかな
2022/04/06(水) 11:54:58.50ID:YS4iOCfL
>>539
それはそうやろw
Javaしか出来ないなら土方で間違いない
2022/04/06(水) 12:32:21.96ID:rwS/Q696
>>540
webでもPython置き換えとしてRustが出てくることは無い。
web用途だからといって所有権だのスコープ・ライフタイムだのを回避できるわけじゃないしな。

>>541
Rustユーザーが初心者・初級者を馬鹿にするようじゃなぁ。Rustの失敗は約束されたな。
2022/04/06(水) 12:44:42.90ID:4NhGLksY
>>542
意味不明だな
唐突に所有権とか言い出して何が言いたいんだ？
2022/04/06(水) 12:58:29.92ID:6roFDaHL
>>536
えっ・・・？GCがないからRust最強他はクソじゃなかったんですか？(´∵｀)
どこぞのチンカスメンがマス書いた野良イブラリでGCとかRustユーザーのおじさんたちって・・・(´∵｀)
2022/04/06(水) 13:56:24.32ID:2Yw46+Tv
>>544
RustやC++は非GC言語やで
2022/04/06(水) 14:20:43.99ID:1nRPgXLc
また意味不明の非GC言語なんて言い出してんのかｗ、リファレンスカウント使ってんだからそんな意味のない宣伝もうやめろよ？
2022/04/06(水) 14:36:07.84ID:6roFDaHL
は？今の時代にリファカンとかｗ
2022/04/06(水) 14:41:06.01ID:6A9Aeuem
ここはおじさんスレだからそれを楽しめ
2022/04/06(水) 14:46:08.13ID:Fm2KF3vu
参照カウントのガベージコレクション
https://developer.mozilla.org/ja/docs/Web/JavaScript/Memory_Management#reference-counting_garbage_collection

これは、最も素朴なガベージコレクションアルゴリズムです。このアルゴリズムは、"あるオブジェクトがもはや必要ない"ことを、"あるオブジェクトがその他のオブジェクトから参照されていない"ことと定義します。あるオブジェクトは、それに対する参照がゼロの時にガベージコレクト可能であると見なされます。
2022/04/06(水) 14:48:22.40ID:7ui2nPA0
>>517
引数の最後のブロックを特別扱いで記述できる文法はrubyからgroovyを経由してkotlinにも引き継がれていて、わりと欠かせない記述方法になってる
ここの https://dogwood008.github.io/kotlin-web-site-ja/docs/reference/lambdas.html
これみたいな記法を頻繁に使うからいまさら無くなっても困る
lock (lock) {
sharedResource.operation()
}
2022/04/06(水) 14:57:27.14ID:rwS/Q696
>>543
スレの流れが追えていないのに口を出すなよ。最初の方の>470 >471 >475から所有権出てるわ。

ChMateとか導入したら？
2022/04/06(水) 23:24:49.88ID:DtmD4s0L
>>551
その所有権がどうしたんだい？
所有権が理解できないなら参照も理解できないから
参照渡しと値渡しの区別もつかないことになる
どの言語でもそういう話は理解しないと使えないから
所有権の概念があるかどうかで困るプログラマーは存在しない
2022/04/06(水) 23:41:02.75ID:6roFDaHL
コードの所有権もない派遣さんが何か言ってらｗ
2022/04/07(木) 01:43:23.21ID:tEZE72Zs
#[derive(Clone, Copy)]
struct Code(String);
2022/04/07(木) 07:31:09.34ID:zb08jYei
>>552
こういうRustユーザーが多いなら、RustのHaskell化は約束されたようなものだな。
Rustコミュニティー全体がその認識なら致命的かと。
2022/04/07(木) 07:42:19.84ID:wRPEswS2
Rustは当面プログラミング言語の王者として君臨し続けるのではないか
高速かつ省メモリかつ安全という他の言語が満たせないRustのアドバンテージを崩せる新言語が登場しない限り

> Rustの以下のメリットを持つ代替言語が存在しないため
> ・ガベージコレクションを必要とせずC言語と同等の速さと省メモリを実現
> ・各種データ競合やメモリ使用の安全性を保証
> ・現代的な各種プログラミングパラダイムを洗練して採り入れており非常にプログラミングしやすい
2022/04/07(木) 08:03:31.90ID:/n3eSctb
俺はRustは廃れるに一票
このスレ見てる限り信者がカルトすぎる
Go信者が可愛く見えるレベル

そもそも設計で差を付けられるレベルなら、言語に拘る意味もそこまでない
このスレがそういう趣旨だというのもあるとは思うが、言語への執着が酷すぎ
2022/04/07(木) 08:10:05.04ID:zl/syFdq
はっきり言って近代的な言語なら仕様も習得もそのコーディングもどの言語でも大差ないんよ
そうなると言語自体として本質的な有利な面を持つRustがじわじわと広まる結果となるかな
2022/04/07(木) 08:56:02.87ID:/n3eSctb
>>558
> どの言語でも大差ない
だから敢えて独自路線を、というのがGoの当初の目的でもあったろ
（上手く行ってるかは別）

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

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

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

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

これが無理だからGCを使うのだ、という事に対しても俺は肯定的で、それでいいと思うが、
Rustが目指しているのは「GCが無いと困る馬鹿でも補助輪を付けてチェックするからなんとかなり、
GC無し並の速度が出ます」であって、結局は馬鹿向けの補助輪でしかない
そこで苦労する程度ならガチでC++で苦労した方が上達するからそうしろ、でしかない
（まあ馬鹿でも何とかなるように、というのが言語の進歩でもあるのだが）
2022/04/07(木) 08:56:07.07ID:hOTZf/Ps
言語の普及について語るときにキラーアプリを語ればいいと思う
Rubyが普及したのはRuby on Railsがあったから。
Pythonが普及したのはAIライブラリ(tensorflowなど）があったか。
RustにはRubyのRoRやpythonのAIに相当するものがあるか？もしくはこれからでてくるか？
そのヒントとしてはWebAssemblyにあるように思う。
2022/04/07(木) 09:01:27.48ID:5wMGrsUW
　:::....　　　／|＼||　　　
　　　　 ／／|'＼＼.... ...:::.. .......
　　　　|／　,'|-､ ＼＼
　　　　|／　,'|-､ ＼＼＼
　　　　|／　,'|-､ ＼＼＼|.... ...:::.. .......
　　　　|／　,'|-､ ＼＼＼|:..。..... ...:::.. .......
　　　　|／　,'|-､ ＼＼＼|__|
　　　　|／　,'|-､ ＼＼＼|:...|ヽ　.... ...:::.. .......
　　　　|／　,'|-､ ＼＼＼|::::|　|::.....　
　|￣￣￣￣￣＼､'＼＼|;;:.|_,,|＿＿＿　　　
　| □□ □□ |　|＼, ＼|;;::....　　　　　|＼
　| □□ □□ |　|　 |￣￣￣￣|＼;: . |　 |
　| □□ □□ |　|　 |□□□□|　 |::...|　 |;;:
　| □□ □□ |　|　 |□□□□|　 |::...|　 |:;:.／
　| □□ □□ |　|　 |□□□□|　 |::...|　 ／
　| □□ □□ |.._|__,,|□□□□|　 |::...|／　　
,,|￣￣￣||￣￣＼≡＼,□□□|／ ,／

今北産業 [IMAKITA INDUSTRIAL CO.,LTD]
　　　　　（1978〜　日本）
2022/04/07(木) 09:02:23.11ID:qcT6PBEO
RustのようにCと同等の速さと省メモリの言語が出てくればRustが敗れる可能性が出てくる
現時点では存在しないためRustの天下が続きそう
2022/04/07(木) 09:26:02.84ID:/n3eSctb
>>560
> WebAssembly
ねえよ馬鹿タレ
というかこのWebAssembly推しは一体何なん？
シェア的にもあり得ないし、ググラビリティもJSに比してゴミ以下だろ

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

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

元々JSだったのは「ソースじゃないと信頼出来ない」という事であり、
それが「最早そういう状況ではないのでバイナリでもいい。速さ重要」となってきているからこそのWebAssemblyではあるが、
ならばそのうち「もうネイティブバイナリでよくね？サンドボックスを仮想的に作ろう。これが最速」となって、
ネイティブバイナリをブラウザ内で実行する状況になって終わると思うけど
仮想周りは本当に進歩したし、何故か知らんがアメリカ人はエミュには執着するしで、これも時間の問題
2022/04/07(木) 09:37:09.90ID:Nyl3OsEM
確かにWebAssemblyではガベージコレクションのないRustが一強になってるな
WebAssemblyにおいてreference typeがサポートされたためDOM操作の壁が大きく低くなり実用的となったことも大きい
今後Rustによるフロントエンドが更に進むことが確実となった
565デフォルトの名無しさん
垢版 |
2022/04/07(木) 10:03:19.72ID:6mRJTF59
>>559
世にあるc/c++メモリ周りの扱いによるバグやセキュリティホールの殆どは、「GCがないと困るバカ」以外の人間が書いているわけだが。
2022/04/07(木) 10:10:10.15ID:hOTZf/Ps
>>563
おまえが（１）のタイプだということはわかったから黙ってくれｗ

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

（２）はRustなどを使用してシステムプロラミングWebassemblyなどでローレイヤーや基盤を作っていく。例えるなら自動車のエンジンやデザインの設計者。
2022/04/07(木) 10:18:58.15ID:/n3eSctb
>>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は書いてないかもしれんが）
2022/04/07(木) 10:23:06.36ID:/n3eSctb
>>565
> メモリ周りの扱いによるバグやセキュリティホールの殆ど
具体的にはどんな奴よ？
そしてそれがRustやJava等だと「自動的に」「どんな馬鹿が書いても」大丈夫だとでも？
2022/04/07(木) 10:29:46.01ID:FJnsEJOV
WebAssemblyでなぜ利用トップがRustで2位がC++なのか？
理由は簡単でGC言語は圧倒的に不利であるため
またWebAssembly自体でのGC導入が問題点多すぎで当面無くなったことも大きい

次になぜC++ではなくRustが1位なのか？
理由は簡単でRustの方が圧倒的にプログラミングしやすいため
Rustが有利なこと自体はWebAssembly以外の分野でも全く同じだが歴史の積み重ねの差がまだある
歴史的に新しいWebAssemblyでは後発言語の不利な点がないためRust有利が顕著に現れた
2022/04/07(木) 10:33:32.72ID:/n3eSctb
>>566
Rust信者は(1)のくせに(2)を気取ってる、勘違い意識高い系馬鹿だね

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

だから正直、ここで信者がやってる布教なんて全く意味ないと思うんだけどな
ウザイだけで
571デフォルトの名無しさん
垢版 |
2022/04/07(木) 11:27:45.58ID:wigEobQO
ビックテックがこぞって使ってるんだからほっといてもある程度は流行るでしょ
俺は楽に稼ぎたいしみんなにもそうなってほしいからRust推してるわ
2022/04/07(木) 11:35:37.24ID:gomi3ocO
>>570
決めつけは低能のあかし
2022/04/07(木) 11:37:41.07ID:QfJTmIv3
>>557
> 俺はRustは廃れるに一票

キミの投票はキミのカーチャンにでも見てもらってください
キミのカーチャン以外はそんな一票になんの興味も無いので
2022/04/07(木) 12:20:35.64ID:pGmXk0tm
Rustは順調にhaskell化しているな。
いい傾向だ。
2022/04/07(木) 12:40:08.52ID:OdIUq1Z2
Rustはプログラミング言語にとって根源的に重要な要素「データ競合やメモリ扱いで安全性が保証される」及び「C言語と同様に最高速＆省メモリ」を両立する唯一の言語
新たな言語が出現しないとRust最優位は崩れないのではないか
2022/04/07(木) 13:09:09.76ID:a0EStXea
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のシェアを奪えるか
2022/04/07(木) 13:44:56.72ID:tEZE72Zs
>>564
RustWasmでDOM操作まともにやれるならやってみたいなと思って最近調べてるんだけど、
https://zenn.dev/igrep/articles/2021-11-wasm-reference-types
によるとReference Typesを使うとむしろパフォーマンスは下がるらしいし、JSにはまだ到底及ばないらしいんだよね
実際使ってみての感想とか、↑のベンチ取り方おかしいわヴォケとかあったら聞きたいんだけど、どう？
2022/04/07(木) 14:06:25.86ID:WjxXuLmC
Rustの話は専用スレ立ててそっちでやれよ
ウザイにもほどがある
2022/04/07(木) 14:34:20.48ID:86kfLMWB
>>578
それはWebのDOM要素とWebAssemblyでのReference Typesの話だろ
Rustなどの特定の言語の話じゃない
それすら理解できないやつが的外れな文句を言うな
2022/04/07(木) 14:43:19.94ID:hOTZf/Ps
>>578
そんな言論統制したら比較すれの意味がなるなるだろ
Rustの話を禁止したらここはGoの話題だけになりGoがRustに比べてはやってるんの？って勘違いする人がでてくる
2022/04/07(木) 17:08:40.53ID:6pGOygc2
>>580
実際そうだし何の問題もない。
2022/04/07(木) 17:13:11.30ID:uI5WJg3m
>>580
Rustは習得が簡単とか大嘘つくやついるしなぁ。
話題にするのはいいけど嘘八百はいかんよ。
2022/04/07(木) 17:15:20.82ID:pxHwe1Kf
>>582
Rustは簡単やろ
どこが難しい？
2022/04/07(木) 17:23:30.39ID:uI5WJg3m
>>583
所有権、ライフタイム、moveセマンティック、参照・借用、型システム、その他もろもろの概念を「ほとんど全部使わないと」まともなプログラムができないところ。
だから「C++とHaskellが使えればRustは簡単」とかいうアホなコメントが出てくる。
2022/04/07(木) 17:57:35.76ID:+6isarPd
>>584
僭越ながら横から失礼しますが、概念の数は学習の難易度とは比例しません。
個別の概念を合わせた結果、目的の用途に合致するようになるかどうかのほうが重要かと思います。

機械語だったら概念の数がRustとGoよりもずっと少なくなると思いますが、機械語を使えばプログラミングしやすくなると思いますか？
2022/04/07(木) 17:58:57.87ID:K7k5hu80
なるでしょ
文法が少ないからGoは誰でも簡単に使えるのだから
2022/04/07(木) 18:23:34.25ID:6J24GmAj
>>568
全ての問題が解決すると思ってるのは馬鹿なので相手にしなくて良い
ゼロイチの議論しかしない人もそう
人間誰しも馬鹿な間違いをする可能性があって、間違いを見逃す頻度を大きく下げられることに価値がある
2022/04/07(木) 18:37:02.12ID:D5y31O0v
>>586
でも両方書ける人はGoよりRustの方がプログラミングしやすいと100%答える現実を見ると
Goは言語機能不足という感じやね
2022/04/07(木) 18:50:26.86ID:6pGOygc2
>>588
>でも両方書ける人はGoよりRustの方がプログラミングしやすいと100%答える現実を見ると
そんな現実はお前の脳内にしかない。
2022/04/07(木) 18:56:45.12ID:wax9VJjI
Rustも使いこなせる人でGoの方がプログラミング使いやすいと言う人を見たことないな
こればっかりはGoの貧弱な言語仕様では仕方ないところかと
2022/04/07(木) 18:56:54.01ID:pGmXk0tm
>>585
「概念の数が増えない段階なら」学習は簡単でしょうな。ADDとかの概念そのものは簡単に学習できる。
ただ、機械語の場合はメモリの位置にも機能&概念があるから、それらを含めると「概念の数が少ない」とは言えない。

あと、
>>584
目的の用途に合致するようになるかどうかのほうが重要かと思います。

というのは学習においては成り立たなくて、「すでに習得した概念 (日常生活なども含む) に沿っているか」の方が重要。
例えばオブジェクト指向はいろいろな概念の集まった複雑な考え方だけど、「対象物を操作する」という日常生活で慣れ親しんだ概念を下敷きにしているから比較的習得しやすい。
2022/04/07(木) 19:53:12.89ID:+6isarPd
>>591
同意です。

が、私が強調したい部分は、言語仕様が簡略な分、必要最低限の複雑性が代わりに言語以外のところに現れることです。

CPUレジスタの固有機能や命令セットの違いとかもまさにその通りで、言語自体の概念ではないが、目的の用途に取り組む場合に必要なる知識だったします。

RustとGoを学習する場合も勿論、言語を構成する概念だけ、一通り目を通せば終わり、というわけではないですよね？
2022/04/07(木) 19:53:35.29ID:48p+VEp6
雑魚ウェブプログラマーの俺からするとRustはGoに比べて言語機能がリッチでいいんだが、まだライブラリ（Rustではクレート）が十分に揃ってないように感じるのと、クレートがすごい細かい単位で分割されてるからたくさんクレートを組み合わせて使わないといけないのが難点かな
個人的には早くまともなORMを出してほしい。1番使われてるであろうORMのDieselが非同期に対応してないのは辛いw
2022/04/07(木) 20:33:59.30ID:hOTZf/Ps
>>593
そうあせるな。JavaだってまともなO/Rマッパーが追加されるまで１０年くらいかかってる。

Java
- 1996年　Java 1.0
- 1999年 JavaEE
- 2006年 JavaEEにJPA(O/Rマッパー）追加
 
Rust
- 2015年 Rust1.0
595デフォルトの名無しさん
垢版 |
2022/04/07(木) 20:39:59.88ID:zb08jYei
>>592
そこは>>584で述べた通り、Rustは
「もろもろの概念をほとんど全部使わないとまともなプログラムができない」
というのが学習する上で凶悪な障壁になっている。
例えばPythonなら基本的なメソッド呼び出しから段階的にプログラムを作りながら学習していけるけど、
Rustは関数ひとつ呼び出すにも所有権、スコープ、ライフタイム（RAII）、moveセマンティック、参照・借用あたりの概念を習得しないとそもそもプログラムが作れない。
自動車のマニュアルをいきなり習うようなもので、そりゃ挫折する人間も増えるかと。
まずはオートマで運転に慣れてから限定解除したほうが習得しやすいよね。
596デフォルトの名無しさん
垢版 |
2022/04/07(木) 20:43:09.58ID:eYC8sBa3
25年前からの10年と7年前からの10年を同じく扱いにするなよ。
2022/04/07(木) 21:06:58.62ID:/n3eSctb
>>587
お前、ホームドアがなかった頃にホームから落ちたことあるか？
俺はないよ。


大都会では用水路に蓋がなく、偶に人が落ちて死んでる。
それらがほぼ暗渠になってるトン菌民とかからすると非難囂々だが、
住んでる連中は蓋がない事に慣れてるし、落ちる事もほぼないので、今後も蓋がされる気配はない。

同様な事はホームドアにも言える。
実際、ホームドアがなかった頃、困った奴はどれくらい居る？
俺は落ちた事も、落ちそうになった事もない。
ホームの端は歩かないというのが鉄則で、
混雑してる場合は何かの拍子で押されて一歩よろめいても問題ない程度の余裕を持って歩く、
それが出来ないなら諦めて人混みの流れに乗る、としてきたからだ。
これは電車通勤してる奴はみんなそうしてるし、実際に殆どの奴は落ちた事がないはず。
落ちるような奴は、そもそも保険も注意も足りてないだけ。

ガードレールがあり、歩道と車道が完全に分離してる道と、そうでない道、どの経路を通るかの選択も同じ。
車が通らない道が一番安全で、次にガードレール付きの歩道がある道、そうじゃない道の順なのは誰でも分かる。
なら、安全な道を選択すれば事故の確率は減らせる。


同じなんだよ。危険性があると分かっているのなら、上位での回避努力は出来る。
それがホームドアがなくても殆どの人が落ちた事がない理由だ。
上位での回避努力をして、さらにチェッカーが付いていれば、さらに事故を減らせる。
しかしRustは、上位の努力をせずにゴリゴリチェッカーだけで安全を確保しようとしてる。
それは俺は違うと思うし、今まで落ちた事もないから、俺にはRust流ホームドアも要らんよ、としか思わない。
(なおホームドア自体は視覚障害者や児童の為に有った方がいいが)

Rustの連中が言ってる安全性は、C/C++で特に困ってない連中には何の魅力もない。
その安全性は多分開発速度の向上に寄与するはずだが、Rustで早くなったって話もないでしょ。
2022/04/07(木) 21:32:17.79ID:6pGOygc2
非同期でないORMとか意味わからん。誰が使うんだ？
rustがランタイム速いとか言ってもそれじゃ全く意味ないじゃん。
2022/04/07(木) 21:32:21.20ID:+6isarPd
>>595
実際は概念一つ一つを念入りに調査せずに、初心者の内はとりあえず思ったまま書いて、
コンパイラに渡してエラーになったら修正するのが普通かと思いますね。

たぶん、人によっては間違ったコードがCIとかでエラーになることを恥と思う気持ちもあるが、些細な問題です。
私もよく、失敗したくないときは、ローカルでコンパイルしてからプッシュするようにしています。
そこは基本的に気持ちの問題ですよね。
2022/04/07(木) 21:35:29.56ID:ikFGu1Ah
じゃあ動的型付け言語でも問題ないな
自分で気を付ければいいだけなんだから
2022/04/07(木) 21:38:19.51ID:+6isarPd
>>595
たとえばの話、多くの初心者は再帰関数を使って、スタックオーバーフローを起こして初めて、スタックというものを意識をするわけですが、
それまでは、スタックという概念をまったく気にせずにプログラムを作っていたことも、よくありますよね？

Rustの所有権周りの概念のうち、どれだけこのスタックのアナロジーに当てはまるかは多分人それぞれですが、
少なくとも、所有権の概念を細分化してできた概念の数が、そのまま敷居の高さになることはないと思います。
2022/04/07(木) 21:41:34.29ID:bwKax5i+
>>597
GAFAMのような大企業はホームから突き落とされるリスクが現実的だからホームドアを必要とするんだよ
ただお前さんのプログラムは攻撃者に狙われるほど広く使われていないというだけ
もちろんそういうマイナーなプログラムに安全性は不要というならそれは自由だけど
2022/04/07(木) 21:46:07.49ID:bwKax5i+
あと酔っ払ってホームから転落する大人もいるってのもあるな
つまり一流のプログラマでも絶対にミスをしないということはないから機械的にチェックしたいという話
2022/04/07(木) 21:59:21.50ID:/n3eSctb
>>600
実際俺はJSで特に苦労もしてない。

Rustの信者連中が間違ってるのは、Rust公式勝手訳日本語版まえがき(前スレ990)にある、
> やっかいな落とし穴を回避する術
を学ぼうともしてない事なんだよ。
これを学んでからRustを使えば確かに二重チェックになって意味はあるが、
学ばずに済ませようとするのは間違いだよ。
（とはいえ結果は君らが負うのだから好きにすればいいが）

ホームドアがない時には、端を歩かない、走ったりもしない、というのは鉄則だった。
ホームドアがあるから、走ったりしても安全！というのは明確な間違いだよ。
そんな事をしてる限り、危険予知能力なんて絶対に身に付かないから、
Rust以外の言語だとまともにプログラミング出来なくなるとも思う。
(それも含めて選ぶのもまた自由だけど)


>>602
GAFAM連中は「やっかいな落とし穴を回避する術」を知ってる上でやってるから二重チェックになってて意味がある。
ここのRust信者はこれを知らずに「Rustを使いさえすれば安全！バグ無し！」とか、
一時のHaskell連中と同じ事を言いだしてるから、ただのカルトであり、意味がない。

ただそれはさておき、コンパイラのチェックが厳しければ生産性が向上するはずなのだが、
実際聞いた事ないだろ？
実際には二重チェックとしてしか使われておらず、なければないで済む範囲での使用に留まっているから、
生産性の向上分が見えてこないだけ。
本当にRustじゃないと無理だっていうものがあれば、キラーアプリとしてそれが出てくる。
ないんだから、そういう事。
2022/04/07(木) 22:07:07.36ID:gzjYIF1u
>>604
やっかいな落とし穴が何に該当するかよくわからないのだけどrustやるならC++での危険回避法を熟知しておけということ？
606デフォルトの名無しさん
垢版 |
2022/04/07(木) 22:09:45.98ID:zb08jYei
>>599
> 実際は概念一つ一つを念入りに調査せずに、初心者の内はとりあえず思ったまま書いて、
> コンパイラに渡してエラーになったら修正するのが普通かと思いますね。
Rustの場合、初心者がまともに動くプログラムに到達するまでいくつも修正しなきゃいけないのが問題だっつうの。
エンストしまくってたらマニュアル運転の練習もクソも無いわな。

>>601
> たとえばの話、多くの初心者は再帰関数を使って、スタックオーバーフローを起こして初めて、
> スタックというものを意識をするわけですが、
ここからすでに前提が間違っている。
Pythonとかは再帰関数を使用しなくてもプログラムを実装できるけど、
Rustは所有権を使用しなけりゃ変数定義も関数呼び出しもできない。

> 少なくとも、所有権の概念を細分化してできた概念の数が、そのまま敷居の高さになることはないと思います。
ここも間違っている。
細分化して段階的に学習できればまだマシな方で、Rustの場合は所有権の概念をほぼ丸呑みしないとプログラムできない。
クラッチとギアとハンドルを同時に操作しないとマニュアル車を前に進めることもできないようなもんだ。
2022/04/07(木) 22:32:09.52ID:/n3eSctb
>>605
いやC++に限らず、プログラミング全般で、
そこに危険があれば、どうやったら上位で回避出来るかは、術がある。
これまで何とかやってきてるんだから当たり前だろ。

面倒だから一々言う気もないけど、「データ競合」については前スレで既に書いたとおり、
・メインスレッド＋サブスレッドでディスパッチ前に全部解決
で完全に回避出来る。
この構成を採用しているのがC#のGUIで、
どうもお前らは言語に対してのこだわりが過ぎてて、これがC#を褒めてるように聞こえるらしいが、
どの言語であってもこの構成にすれば回避可能で、C#のGUIではそれをフレームワークとして強制してるだけ。
だからC#では、フレームワークを正しく使う気があれば、「術を知らなくても」自然と回避できることになる。
他言語なら、この知識があれば、同様に自前で回避出来るだけ。

Rustの場合はこれをコンパイラのチェックにより同様に「術を知らなくても」回避出来るようにしている。(回避術は異なるが）
その他諸々突っ込んで、「コンパイルが通りさえすればOK」を目指すのも一つの手で、実際そうしてるようだが、
本来それはあくまで「Rustではどういう術を強制する事によって、どの問題を回避している」と認識出来てからやるべき問題。
それを初心者のうちはある程度すっ飛ばしても構わないとは思うが、知らずに済ませるのはどうかと思うよ。
566の(2)のつもりなら特に。

実際にRustが採用している術は、C++でのRAIIとunique_ptrに近いから、
これらを既に常用してたら、グダグダ言われずともRustに移行するだろうよ。
ただ、回避する術は一つじゃないから、違う術を使ってる連中は、Rustを使う事はないだろう。（俺はこちら）

そして本来は、どんな術があるのかを学ぶのが学習で、
元々はデザインパターンもこの方向だったはずだが、何かおかしな事になっちゃって見捨てられた感じになってるが。
2022/04/07(木) 22:40:48.67ID:eUNchQrd
Rust自体は好きだけどPythonの代替先になるというのは現状個人的には全く考えられないなぁ
単一所有権ベースの書き方が、意識せずとも間違いなく書ける内容なら静的チェックがなくても取り沙汰されないし、それがメリットとしても喧伝されないと思うんだよな
別分野だけど機械学習系だと公式のラッパー先としてまず出てこない言語だし、やっぱ性能とは別の事に頭使いたいジャンルだと不向きだと思うよ
もし広い範囲でPythonの代替になると思ってる人が居るんだとしたら、普段のスクリプティングとかもRustで書いてんのかな
2022/04/07(木) 22:41:15.91ID:QfJTmIv3
ようしわかった
もうわかった
ついにわかった
言ってほしいんだろ？
そういうことだろ？

Rustはしょうもないクソ言語で未来はないし
GAFAMが使ってるのもそれはそいつらがアホだからだ
ね、これでこの話おしまい

こんなクソ言語だれも使わなくていいからね
心配しなくていいからね
こんなクソ言語消えてなくなるから
誰も使わないからね

俺は使うけど
2022/04/07(木) 22:43:27.27ID:YR3mJewM
いや駄目だ俺が使う
2022/04/07(木) 23:00:34.39ID:/n3eSctb
>>608
> 単一所有権ベースの書き方
これが演算には絶望的に不向き。ウザイだけ。
ただし鯖等では確かに「上から下に流れる」ように書くので、「単一所有権ベース」でも多分問題なく書ける。

だからまあ、現時点でWeb限定に近いのは、既に住分けてる、とも言える。
他のアプリでも、自前で状態管理するのを極力止めて、内部でRESTfulにすれば、そこそこ行けるはず。
2022/04/07(木) 23:24:34.67ID:hOTZf/Ps
>>610
ついやいや俺が
2022/04/07(木) 23:38:47.04ID:+6isarPd
>>606
言いたいことは分かります。
要は学習成果の可視化しにくいインターバルが長いと不利ということですよね？

学習した先に何を求めるかは人それぞれですし、
それって結局、言語機能を部分的にでも成果として、学習者が捉えられるかどうかだけの問題じゃないんですか？
（Rustの所有権を部分的にできるかは平行線なので置いておいて）

案外若い世代はところどころデジタルリテラシーがあるので、
プログラミング学習ができないと危惧して、変にレール敷くような考え方はしなくても良いんじゃないですか？
614デフォルトの名無しさん
垢版 |
2022/04/07(木) 23:51:03.44ID:eYC8sBa3
1ヶ月に一度1ー2時間ほどプログラミングします
といった程度の人達が、あやふやな知識のまま
目的の動くもの素早く作れる言語でないと
広い裾野には訴求しない
ニッチな人のニーズには合致する可能性はあるけど
2022/04/08(金) 00:23:55.25ID:PcnkB3on
>>607
要はライブラリなど自分が依存するものの中身がどうなっているかはちゃんと把握した上で使えって話と、
自分が困ってないなら無理に道具を変える必要がないって話ね
rustというよりrustを変に持ち上げてる人に対するコメントだった訳ね
2022/04/08(金) 00:24:56.07ID:nM4swqos
我々の生きているうちにもしそんな素晴らしい汎用言語が出来ると夢が広がりますよね。
未来の言語研究に期待しましょう。
2022/04/08(金) 00:26:25.71ID:PcnkB3on
>>614
たしかに、次世代言語なんて銘打ったスレに集まるような人向けの言語なんてニッチの最たるものだろうね
2022/04/08(金) 00:31:27.96ID:TpfOdACd
>>613
>学習した先に何を求めるかは人それぞれですし、
なら、なおさらPythonの代替をRustに求めるのは無理。
まさしく>>608の通り、学習した先に「やっぱ性能とは別の事に頭使いたい」というならRustは不要だわな。

>>609
いやいや、自分もRustは認めているよ？ Forthと同じぐらいには。
2022/04/08(金) 00:47:01.39ID:nM4swqos
>>618
そうですね。別に性能だけの話じゃないと思うが、
いろいろ気にしない人には確かにPythonでプログラミングを勧めるのも一つの手だと思いますね。
2022/04/08(金) 01:01:29.96ID:8ljQsUz4
Rustに移行するのはC++から来る人が多いだろうな

ptyhon、java,typescript、スクリプト系からは少ないだろう
621デフォルトの名無しさん
垢版 |
2022/04/08(金) 03:06:12.85ID:Km060/QD
>>597
長々と書いてるけど、お前って一人で開発してんの？
なら好きなの使えばいーじゃん。
2022/04/08(金) 06:34:32.60ID:z2O+b+J1
>>608
Pythonなんて超遅いダメ言語だろ
C/C++に移行すれば10倍くらい速くなるぞ
メモリ使用量も大きく減る
2022/04/08(金) 07:08:41.73ID:F6GdhFTs
>>622
用途が違うものを比較しても意味ないよ
2022/04/08(金) 07:36:43.85ID:5MIkz0s/
>>620
JavaScript(Node.js)からRustへ来たけど特に難しいところは無かったよ
JavaScriptでPromise返す並行プログラミングしていたから
RustでFuture返す並行プログラミングにすぐ移行できた
2022/04/08(金) 07:50:10.89ID:aDtoFpcQ
RubyやPHPからRustに来る人はゼロではないだろうけど少ないだろ
それぐらいなぜ認めたくないのか？

用途が違う
2022/04/08(金) 07:51:28.36ID:3RXqham9
みんな色々と考えるんたな。
自分の使う言語を選んで仕事始める人が多いのか？
2022/04/08(金) 07:54:38.16ID:atDB72kn
>>625
RubyからRustへも多いよ
例えばこのスレでも>>510へのレス状況から少なくとも3名は居る
2022/04/08(金) 08:00:35.35ID:aDtoFpcQ
病気なのか？
2022/04/08(金) 08:08:54.70ID:jLbA7OdY
俺がスクリプト言語からRustも使うようになった理由はスクリプト言語っぽく書けて便利で速いから
今後もそういう人が増えるのは間違いない
2022/04/08(金) 08:15:42.34ID:CQiu8f2R
>>629
完全に同意
2022/04/08(金) 08:22:48.61ID:G9TYKjMP
ぼくも(^o^)
2022/04/08(金) 08:38:19.52ID:16DK1NKj
>>626
逆よ
仕事を選ぶと言語が決まることがほとんど
2022/04/08(金) 09:31:00.03ID:gFm4wviN
>>629
設定に無理があるｗテキトーなパースするだけにrustなんか絶対に使わねーよ。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況