次世代言語24 Go Nim Rust Swift Kotlin TypeScriptat TECH
次世代言語24 Go Nim Rust Swift Kotlin TypeScript - 暇つぶし2ch39:デフォルトの名無しさん
22/03/23 07:21:13.86 k8Z8CHR2.net
>>37
Rust推しはキチガイってことですねw
JavaScriptはデフォルトconstじゃないですw
出来るところをconstにしよう!なら問題ないw
デフォルトをconstにする=制限と言ってるだけw だってmutとか書かないといけない=制限だからw
そして書いた瞬間に確実に「制約」になるからねw
明示的に書けば外せるから制約じゃない!とかアホとしかw

40:デフォルトの名無しさん
22/03/23 07:21:58.94 k8Z8CHR2.net
>>38
Erlangなんて日本じゃほぼ使われてませんw

41:デフォルトの名無しさん
22/03/23 07:23:16.59 iWJcW09w.net
>>36
君がプログラムを書いたことがないからじゃないか?
>>34が書いているようにRustは選択肢が色々と用意されていてプログラマーがそれらを選択することができる言語
もちろんcloneやcopyは最小限にしたほうが望ましいからそれらはデフォルト適用になっていない
合理的である

42:デフォルトの名無しさん
22/03/23 07:24:41.53 k8Z8CHR2.net
>>41
そうして書かれたコードが制約過多だって言ってんだよw

43:デフォルトの名無しさん
22/03/23 07:31:08.29 kDmi0r/e.net
頭いいなら機械語直接書いてくれ
俺は頭悪いからモダンな構文使える言語を選ぶよ

44:デフォルトの名無しさん
22/03/23 07:33:34.18 k8Z8CHR2.net
じゃあgoっていう簡単な言語があるよw Rustとかいうゴミ言語を勧めるバカの言うことは聞かない方がいいよw

45:デフォルトの名無しさん
22/03/23 07:35:26.97 QsWn2aJ/.net
Goの良さもRustの良さもわかるからそこまで論争になるのがよくわからないw

46:デフォルトの名無しさん
22/03/23 07:39:15.66 k8Z8CHR2.net
俺は遊んでるだけだけどw

47:デフォルトの名無しさん
22/03/23 07:40:32.44 k8Z8CHR2.net
なんかやたら噛み付いてくるんだよねw 事実なのにちょっとでもRustをディスるとw

48:デフォルトの名無しさん
22/03/23 07:41:18.55 Ur6oGy1g.net
なぜ論争になるかより、なぜ相手にするのかが疑問だ
NG放り込めば始末できるのに

49:デフォルトの名無しさん
22/03/23 07:41:49.60 YNaZlr7q.net
>>39
色んなプログラミング言語を知らないあなたが無知にみえます
Rustの場合は関数型言語に近くてif式、match式、loop式といったように文ではなく値を返すことが可能なものが多いです
そのため必然的にほとんどの変数利用はimmutableとなります
もちろんRustはmutableも使えますからそこに制限は全くないです
上述したようにif式、match式、loop式といった値を返すことも可能な点でも他の言語よりも自由度と表現力が増しています

50:デフォルトの名無しさん
22/03/23 07:43:00.65 k8Z8CHR2.net
我慢できないようだよw なんでかは知らないw
あ、別スレに貼ったやつを燃料として投下しておこうw
スレリンク(tech板:730番)
学習曲線やゔぁ!w

51:デフォルトの名無しさん
22/03/23 07:46:48.46 k8Z8CHR2.net
>>49
近くねーよw 関数型に近い表現が出来るとしか言われてねーよw
そして最近の言語は程度の差こそあれ近い表現も遅延評価も出来るよw

52:デフォルトの名無しさん
22/03/23 07:57:06.22 QsWn2aJ/.net
rustは学習曲線高いと言っても、一番最初にrustを勉強すると大変だとは思うけど、c++とhaskellあたりを学んでおけば大したことないし、コンパイラがうるさいおかげでよくわからないままメモリ周りのバグを含んだクソコードを書かないという点ではハードルはむしろ低いんじゃないか?
goはそれとは逆のアプローチを取ってるだけでどちらが優れているとかではない気がする。
片方を過剰に擁護するのはプログラミング言語についてあまり知らないから自分の理解できるところだけ切り抜いて騒いでるだけにしか見えない。
goが馬鹿向けの言語とか言ってる人もいるけど、goを使って素晴らしいソフトウェアを作り上げた優秀なエンジニアもたくさんいることを知らずに言ってるなら本当に恥ずかしいことだと思うw

53:デフォルトの名無しさん
22/03/23 07:59:10.53 FgzylXVH.net
>>52
キミは賢くてかつ弁えてるね

54:デフォルトの名無しさん
22/03/23 08:02:19.50 IC5SATyv.net
>>44
横入りですまんがGoは言語の機能が低すぎるせいで無駄に記述が長くなり苦痛
書いていると同じパターンが何度も出てくる
Go言語のサポートが少ないため冗長なことを人間がさせられてしまう

55:デフォルトの名無しさん
22/03/23 08:19:52.35 7xSibnEC.net
>>52
>c++とhaskellあたりを学んでおけば大したことないし
つまり初級者・中級者お断りということかね。
PythonとかJavaあたりのユーザーは絶望的かと。

56:デフォルトの名無しさん
22/03/23 08:23:01.04 k8Z8CHR2.net
C++の前にCは習得しておきたいし、C++自身もHaskellも学習曲線やばいけどねw
ヤバい言語を2つも習得してようやく他の言語と比較しうる学習曲線になるRustって一体・・・w
Goの冗長さはRustの言語的制約と似たようなものw
明快さの代わりに受け入れざるを得ないw この手の問題は開発環境によりほんのり改善できるw

57:デフォルトの名無しさん
22/03/23 08:34:40.79 Bhs+4jj4.net
>>55
C++もHaskellも全く知らないけど
Rustを普通レベルには使えるようになったから
C++もHaskellを知らなくても大丈夫なことは保証するよ

58:デフォルトの名無しさん
22/03/23 08:37:32.32 ED6mevIO.net
今こそJava復活の時
[速報]JavaOneが復活、今年10月にラスベガスで開催。2017年以来5年ぶり
URLリンク(www.publickey1.jp)

59:デフォルトの名無しさん
22/03/23 08:42:55.48 QsWn2aJ/.net
>>55
この表現は確かに不適切だったと思う。
伝えたかったのは、cライクな構文、メモリ周りの知識、型システムの知識があればrustが極端に難しい言語ってわけではないってことなんだ。
そしてこれらの知識はプログラミングを書いていれば自然と知ることになるものだと思ってる。(c++とhaskellが書けないと理解できないと言いたかったわけではない)
プログラミング初学の人や、プログラマではないが仕事の道具としてスクリプト言語を使ってるような人が学ぶ言語じゃないのとは思うけど、アプリケーションの開発を行うような人にとっては難しすぎる言語仕様じゃない。

60:デフォルトの名無しさん
22/03/23 08:47:46.12 k8Z8CHR2.net
違う違うぞ
使えるようになったつもりなだけだw
RustにはC++とHaskellが必須!C++の難解なエラーを気が狂いそうなほど読み解き、公衆の面前でモナドとは・・・っていうポエムを書いてからでないと本当の意味でRustの扉は開かないw

61:デフォルトの名無しさん
22/03/23 09:06:26.09 +IZ6XP4Y.net
>>59
同感
Rustを難しいと言うのは大げさもしくは批判派によるレッテルだと学んで分かった
むしろRustを使うことでの絶大な効果に驚いた
一番大きかったのは実行時デバッグの激減
コンパイル時点で実行時に起き得る様々な問題を食い止めてくれるため開発効率が一気に上がった
使いやすさに加えて実行の速さや省メモリなど一石多鳥

62:デフォルトの名無しさん
22/03/23 09:23:15.77 QsWn2aJ/.net
>>61
伝わってよかった....
後半の部分も完全に同意する。ブレークポイント貼って変数の値をチェックしながらデバッガをいじくり回すみたいなことをする頻度が激減したのが大きい。
ヤバそうな部分もunsafeとかunwrapみたいにコード上に明示されるのが地味に快適。自分にとってコードって書くことより読むほうが大変だから、そういうところがありがたい。

63:38
22/03/23 09:35:58.30 znQ4kzdw.net
確か、Elixir はスクエニで使っている。
ニコ生でも、会議をやっていた
他には、組み込みのNerves
YouTube で有名な、雑食系エンジニア・KENTA のサロンは、Ruby on Rails だけど
ポートフォリオは、Elixir のPhoenix

64:デフォルトの名無しさん
22/03/23 10:03:50.80 Hqya9b1R.net
>>62
書きより読み重視ってのは最近の言語全般の傾向であるように思う
GoとRustは全然方向性違うけど、ソースコードの情報量増やして読むコストを下げるという点では同じかな、と
OSSなんかだと書く人より読む人が遥かに多いし、個人開発だったとしても半年前のコードなんて覚えてないから結局読みやすさは重要だよね

65:デフォルトの名無しさん
22/03/23 10:52:27.45 FgzylXVH.net
書きやすい言語ほど読みにくいよね
書き手の自制心にもよるんだけど
rubyとか書いてるときすっげーストレスないんだけど
あとから見るとその時のノリで書いてるのがよくわかる
Javaは現代視点だとやや冗長かもしれんが
後から読んでも意外と読みやすい

66:デフォルトの名無しさん
22/03/23 11:32:06.34 znQ4kzdw.net
可読性は重要。
漏れなんか、一月前の自分のコードでも、自分で書いたと分からないからw
この処理は、いつの間に誰が書いたの?
とか、よく他人に聞くw

67:デフォルトの名無しさん
22/03/23 11:33:27.01 k1M19ntv.net
>>62
たしかにRustでは実行しながらの無駄なデバッグ時間が無くなった
コンパイラによるチェックが厳しい言語ほどプログラミング効率が良くなると実感した
>>64
その通りで1年経つと自分で書いたコードでも忘れてる
機能追加などで再び触るときに読みやすさだけでなく
Rustではデータの扱いや構造をいじった時にミスるとコンパイラが敏感に叱ってくれるのが良い
おかげで時間生産性が大きく改善した

68:デフォルトの名無しさん
22/03/23 12:00:43.29 WWS7e+O4.net
>>59
>cライクな構文、メモリ周りの知識、型システムの知識があればrustが極端に難しい言語ってわけではないってこと
Pythonユーザーはカスリもしないし、Javaユーザーもcライクな構文以外は知識無いだろ。
>そしてこれらの知識はプログラミングを書いていれば自然と知ることになるものだと思ってる。
そりゃ傲慢だね。
PythonとかJavaを使うのにコールスタックとかヒープとか意識したっけ?

69:デフォルトの名無しさん
22/03/23 12:23:50.13 EvHbv07S.net
>>68
技術に対する知識も興味も意欲もない人でも
誰でも簡単とかいう主張はしないと思うが…

70:デフォルトの名無しさん
22/03/23 12:44:20.95 WWS7e+O4.net
>>69
>技術に対する知識も興味も意欲もない人
なるほど。Rustユーザーにとっては
>cライクな構文、メモリ周りの知識、型システムの知識
が技術に対する知識・興味・意欲を持つ人のレベルということか。
このハードルをクリアしているPython・Javaユーザーってどれくらいいるのかな?

71:デフォルトの名無しさん
22/03/23 12:50:13.13 k8Z8CHR2.net
Rust信者の単発IDがなんかいってるだけw
やってることがやばいんよねw
Rust別に読みやすくないし、変更しにくいし、習得大変だし、ごく一部の超高速超並列処理が必要なクリティカルな領域以外はいいことないからw

72:デフォルトの名無しさん
22/03/23 13:09:38.08 svGg7ZtK.net
C言語やってC++言語は何となく知っているレベルでRustやればいいなら、C++中途半端な人には嬉しい。
C++用のライブラリなんかは移植しやすいのだろうか。

73:デフォルトの名無しさん
22/03/23 14:02:38.40 QZvXUCU9.net
>>72
移植しやすさはライブラリの作りに依存すると思う
グローバル変数を雑に使うライブラリなんかだとインターフェースやデータの持ち方を見直す必要がある
スレッドセーフなライブラリならある程度はベタに移植できると思う
ただ枯れてる既存のライブラリをわざわざ移植するのは特別な理由のない限りやる必要はないと思う

74:デフォルトの名無しさん
22/03/23 14:05:59.79 aOOT3ZZt.net
>>71
Rust程度で難しいというなら
あんさんプログラミングに向いてまへんわ
スクリプトをいじる程度にしとき

75:デフォルトの名無しさん
22/03/23 16:32:34.63 WWS7e+O4.net
>>74
Rustは初級者・中級者お断りということですな。

76:デフォルトの名無しさん
22/03/23 16:44:05.96 QZvXUCU9.net
>>75
Rustの得意とするシステムプログラミング領域がそもそも初心者お断りというか、初心者が手を出そうとしない領域だよね

77:デフォルトの名無しさん
22/03/23 16:47:42.50 5QD+Xegu.net
>>75
Rustは普通のプログラマーなら余裕
ちょろっとスクリプトを書くだけの似非プログラマーには無理

78:デフォルトの名無しさん
22/03/23 19:17:49.04 Ur6oGy1g.net
なぜ簡単に分断工作にひっかかるのか
うちじゃ老若男女Rust使っとるよ

79:デフォルトの名無しさん
22/03/23 19:24:04.56 XLgqvJYc.net
先入観のない初心者はRustの学習が速い
Rustは抽象度高く分かりやすく出来ているから
無理に既存の低レベルのものに例えて考えないほうが飲み込みが早いということかも

80:デフォルトの名無しさん
22/03/23 19:40:00.68 kDmi0r/e.net
Pythonから来たけど今は楽しくRust書いてる
Cは一切やったことがない

81:デフォルトの名無しさん
22/03/23 19:40:04.95 QZvXUCU9.net
本当の初学者向けの優しさというのは入門書が多いとかチュートリアルが充実してるとかで
言語仕様の善し悪しはそんなに影響しないのでは
というかプログラミング初心者がrust使って何する想定なの?

82:デフォルトの名無しさん
22/03/23 19:51:24.40 fgK+Upwy.net
CLIからWEBまで普通のことはRustでできるから人それぞれと思う

83:デフォルトの名無しさん
22/03/23 20:00:27.47 S8syHMIu.net
Rustユーザーの多くは初心者向きじゃないという認識のようですな。
ちょろっとスクリプトを書くだけの初心者とか初級者はお断り、と。

84:デフォルトの名無しさん
22/03/23 20:12:48.64 NzxRseYp.net
>>83
そういうのはインタプリタ&スクリプト言語でもいけるケースが多い
もちろんRustで書けば速さや省メモリの点でも有利なので環境によってはRustも使う

85:デフォルトの名無しさん
22/03/23 20:58:37.09 k8Z8CHR2.net
Rustなんて誰も使わないので大丈夫ですw
嘘ばかりついてるから、誰も信用せず、普及もしないw

86:デフォルトの名無しさん
22/03/23 21:18:39.03 sIPI2inn.net
そうだね

87:デフォルトの名無しさん
22/03/23 21:40:33.95 Zj8OyINv.net
Rustの案件関わった人大体C++戻っていくよね

88:デフォルトの名無しさん
22/03/23 21:47:49.22 EHvtOoqR.net
>>25
dockerはgo製と聞いたことがある。

89:デフォルトの名無しさん
22/03/23 22:20:55.11 ln8rDjYo.net
>>52
> goが馬鹿向けの言語とか言ってる人もいるけど
それは俺の事だろうが、俺はそれ自体を馬鹿にしているわけではない。
実際、元祖馬鹿向けCのJavaはCよりも成功してる。
簡単は正義だ。問題は、前スレ870で言ったとおり、簡単の使い方は単純には3通りあって、
A. もっと馬鹿を雇って人件費を抑える
B. 簡単になった分早く処理して、回転数で稼ぐ
C. これまでは複雑すぎて現実的に不可能だった事に挑戦する
で、「楽になった=(A)」しかやってないのなら馬鹿にされて然るべき。
(B)(C)に関しては方向性は違うがいずれも脳味噌フル回転だから、「楽」とは感じられないはずなので。
が、まあ、(A)で行くのも自由だし、一々他人を馬鹿にする趣味もないしで、これは放置だ。
ただ俺は(C)を目指すから、それ(キラーアプリ)は何だ?と最初から何度も尋ねてるのに、
出てこない=君らも目指してないし、これまでも目指した人が誰も居なくて完成品もないから列挙出来ない
のだから、馬鹿にされても文句言えないと思うけど。手段が目的化してるだけだし。
(この点はRustも同様。
> 安全側に振ったC++なRust (32)
というのは当たってる。馬鹿向けC++になってしまっていて、(C)を目指した奴が居ないのも同じ)
多分な、コンパイル時にエラー=文法エラーにしないといけない、と固執してる点が間違ってる。
初心者がよくやるミスを救済したいのなら、IDEで色を付けるだけで済む。例えば、
・ローカル変数と、それ以外の変数(クロージャ等)は、色を変える (これは既に言ったが)
・再代入されてる変数は、色を変える
後者もすさまじく馬鹿っぽいが、現実的にこれで問題ないだろうよ。(まあ俺はimmutableでもいいんだが)
本来プログラマが学ぶべきなのは、Rust公式勝手訳日本語版まえがき(前スレ990)にある、
> やっかいな落とし穴を回避する術
なんだよ。それを文法にしてそれ以外はエラーにすれば学ばなくてもよくね?文法だけでいけるよね!
がRustの試みでもあるようだけど、ならコンパイラではなくリンターにするべきだったと思うのだが。
(と思ってたが…Goのは出てきたがまあ書いたので投稿しておく)

90:デフォルトの名無しさん
22/03/23 22:21:53.85 ln8rDjYo.net
>>88
なるほどDockerなら上手くランタイムと融合して実装の手間は大いに減る気はする。
(他言語では自前で実装しなければならない部分がランタイム内に既に実装されてるという意味で)
ランタイムがOSモドキなので仮想系は確かに強いかも。
ただしこれは言語の強さというよりは、処理系が偶々フィットした感じだが。

91:デフォルトの名無しさん
22/03/23 23:05:09.57 k8Z8CHR2.net
何を勘違いしてるのか知らんが、GoにVMはないし、仮想系?ってなんだよw
OSもどきというのはどういうこと?w
ILなどをその場で解釈/実行したり必要ならnativeにして実行を動的に実施する機能が追加されてるだけ(?)じゃないんか?w
gollvmみたいなのはあるけどw

92:デフォルトの名無しさん
22/03/23 23:48:27.71 uZNiLL5S.net
Dockerってシステムコールしまくってコンテナの実行環境を整備してるだけだろ?
コンテナの実行というクソ重い仕事に比べたらそりゃGoのオーバーヘッドなんか何の問題にもならんだろうな

93:デフォルトの名無しさん
22/03/24 01:09:04.02 pqCNb7jw.net
rustってライブラリの充実度って現状どんな感じですか?
結局pythonが当たったのってライブラリの充実度がでかかったのでそこ重要な感じがするんですけど

94:デフォルトの名無しさん
22/03/24 01:11:18.00 1Vr2GJ3G.net
どこの馬の骨が書いたのか分からないゴミみたいなのが散乱してるだけの原初の野原状態w

95:デフォルトの名無しさん
22/03/24 01:13:44.30 pqCNb7jw.net
やっぱりまだそんな段階ですか
そりゃそうでしょうね

96:デフォルトの名無しさん
22/03/24 01:17:23.42 Fp4rCRr5.net
>>92
合ってるところの方が少ないな

97:デフォルトの名無しさん
22/03/24 01:47:46.62 4DXDecHD.net
>>93
Rustならば普通のほとんどの分野でライブラリは充実していて問題ない状況

98:デフォルトの名無しさん
22/03/24 02:28:03.86 WqRDDg3u.net
>>89
あまりにもデタラメすぎ
普通のプログラミング経験がないのか?
色を付けたりリントが頑張れば何とかなると思い込んでる時点でお子様プログラマーだな

99:デフォルトの名無しさん
22/03/24 02:41:26.25 1Vr2GJ3G.net
>>97
はいはい嘘乙
こういうのはRustの学習用何かを売りたいだけのアホだから踊らされないでね

100:デフォルトの名無しさん
22/03/24 03:24:56.84 LzBWTpj6.net
>>99
たいてい必要とするライブラリが充実しているので合ってるじゃね
むしろRustで困ったこと何があるの?

101:デフォルトの名無しさん
22/03/24 04:31:02.79 1Vr2GJ3G.net
どこの誰が作ってんのか分からんやばいライブラリを疑心暗鬼で使わないといけないからw
俺は業務で使ったことはないから、その辺の知見はないw
npmとかだと人気とか見れるし、これが定番ってのがある程度見えてるんだけど、Rustにはそれらが全くないのだよw

102:デフォルトの名無しさん
22/03/24 04:41:53.12 aaqsPLkK.net
>>101
なぜそんな嘘を付きまくっているの?
npmのJavaScriptと比べても開発状況は同じ
さらにダウンロード数やその推移もRustは全て公開されていて人気状況ももちろんわかる

103:デフォルトの名無しさん
22/03/24 05:50:03.15 IpI64M2x.net
自分でライブラリのコード読むような連中はRust使う旨味無いからC++使い続けてるでしょ
漏れの分野じゃRustの気配全く無いぞ

104:デフォルトの名無しさん
22/03/24 05:51:15.02 1Vr2GJ3G.net
>>102
同じというのが嘘なんだよ。例えばこういうのw Rustにはないでしょ?
URLリンク(www.npmtrends.com)
そしてそもそも定番というのがないw 基準がないと分からんのだよねw

105:デフォルトの名無しさん
22/03/24 05:54:59.24 1Vr2GJ3G.net
ちなみにどこかの日本人が自分で作ってたのがあるのは知ってるけど、そういうことじゃないから先に言っておくねw

106:デフォルトの名無しさん
22/03/24 07:00:09.81 FIGV+eJh.net
同じなんて言ってないだろ
人気だから安心理論は笑うが

107:デフォルトの名無しさん
22/03/24 07:08:59.34 FIGV+eJh.net
あ、同じって言ってた
同じじゃねえょ

108:デフォルトの名無しさん
22/03/24 09:02:13.23 uXrCWmC0.net
2021年のRust利用に関する調査結果が発表
URLリンク(codezine.jp)
WebAssemblyアプリ開発で最も使われている言語はRust
URLリンク(www.publickey1.jp)
グーグルやMSが「Rust」言語でOS開発、背景に国家による諜報活動の影
URLリンク(xtech.nikkei.com)
「Atom」の開発者が究極のコードエディターを目指す ~「Zed」の開発が始動
「Electron」を捨て、Rust言語を採用。GPUI、tree-sitterなどで武装し、超高速なコードエディターに
URLリンク(forest.watch.impress.co.jp)
プログラミング言語「Rust」の普及に立ちはだかる壁
URLリンク(japan.zdnet.com)
なぜ「Rustは難しい言語」とされるのか―習得の難しさとその対策をWebエンジニアが考察
URLリンク(atmarkit.itmedia.co.jp)


109:4.html



110:デフォルトの名無しさん
22/03/24 10:45:51.40 +3oKH6IH.net
人気だから云々というのはデータサイエンティストの商売道具なんだな
それに、変数の型など書かない方が、実行時のデータを分析する仕事は増える

111:デフォルトの名無しさん
22/03/24 10:56:08.60 Ae+CEOFA.net
>>104
おまえnpm trendsの内容を見てないだろ
単にダウンロード数などの数値がわかるだけだぞ
>>105
npm trendsも個人がやっているだけだぞ

112:デフォルトの名無しさん
22/03/24 11:40:40.62 v7pSPIP9.net
ダウンロードのグラフを見て採用を決めるアホはいないからそこはどうでもええよ
どうせnpm公式を見ることになるし
Rustなら同じ情報は URLリンク(crates.io) にあるし
その詳細ドキュメント URLリンク(docs.rs) を見て決めるよ

113:デフォルトの名無しさん
22/03/24 12:21:02.66 Hvf7BfqR.net
cratesはいい名前のライブラリ程放置ライブラリで、いいライブラリはわけわからん名前だから口コミ以外でライブラリ見つけられんのよな
でも口コミが有効な程ユーザーがいないので結論としてライブラリ見つけられん

114:デフォルトの名無しさん
22/03/24 12:28:49.48 cpMYWIcY.net
>>112
そんなの要らん
検索でダウンロード順などにも出来るぜ
人気だけで決めるようなレベルの人ならそれで十分
どの世界でも同じだが普通は内容を見て検討

115:デフォルトの名無しさん
22/03/24 12:34:42.64 Dh9iIqia.net
Rustの話は専用スレ立ててそっちでやってくれよ
さすがにウザイ

116:デフォルトの名無しさん
22/03/24 12:53:05.46 tho1Y8H6.net
いつも同じパターン
RustとC#のアンチなガイガー君がたくさん書き込みをしてそれらを叩く

RustとC#の話ばかりになる

Rustは人も多いので色んな情報や質問が出てきてガイガー君が寝てる時間も盛り上がってる現状

117:デフォルトの名無しさん
22/03/24 13:14:59.00 Fp4rCRr5.net
例の人はすでにRust系のスレでもずーとあばれてるんだな
>>114

118:デフォルトの名無しさん
22/03/24 13:28:40.21 PqQGlENL.net
rust普及させたんだろ

119:デフォルトの名無しさん
22/03/24 13:30:34.37 hpnd5vIU.net
結局rust厨ってのは他の言語に対してマウント取りたいだけだから自分のスレに行かんのだろう

120:デフォルトの名無しさん
22/03/24 13:38:11.84 C/wmaJvp.net
>>116
そうなのよ
C++Rustスレで暴れているだけならいいのだけど
Rust本スレでもRust叩きをして荒らしていて困ってるの

121:デフォルトの名無しさん
22/03/24 14:03:00.30 cnbeCFj/.net
>>113
内容を見るにはまず見つける必要があるんだが……
ダウンロード順は人気の分野のものしか見つからん

122:デフォルトの名無しさん
22/03/24 14:10:28.86 cnbeCFj/.net
例えばダウンロード順だとwebとかで検索してもactix-webは二ページ目になるんだよな
我々はarctic-webが人気と知っているからこれを見つけることが出来るが、知らなかったら見つけられんだろこれ

123:デフォルトの名無しさん
22/03/24 14:16:19.41 JB9oIWQh.net
人気バカにしてるやついるけどかなり重要な要素だろ
今後継続してメンテナンスされやすいかどうかの違いは大きい

124:デフォルトの名無しさん
22/03/24 14:46:16.02 RmgcY/8b.net
>>121
ダウンロード数が多いのが並ぶ分野ならば2ページ目も当然見る
1ページ目の各々の内容を確認すればweb関連のうち自分が目的とするものか否かはすぐわかる
そして今actix-webより上に並ぶものを見てみたがいずれも重要な存在ばかり
中身を見て自分が今必要なものではなくとも把握しておく価値あるものがズラリ

125:デフォルトの名無しさん
22/03/24 14:50:46.28 RmgcY/8b.net
>>122
Rustに限らずどこでも同じだが
ダウンロード数が多いものと人気は食い違うこともある
例えば複数の領域にまたがるものはダウンロードが多くなる
しかし自分が求めている特定の領域に限れば1番人気とは限らない

126:デフォルトの名無しさん
22/03/24 18:22:21.38 sVFN7N70.net
>>123
うーん。これは流行らない言語大好き言語マニアの考え方
成果が出る人間の大多数は他分野のものを把握するより自分が作りたいものに集中するので、こういうオタクに占有された言語はキツい
ゆるふわのpythonとかjsなんかが流行るのが現実だからな

127:デフォルトの名無しさん
22/03/24 19:07:56.38 d1t9w96u.net
>>125
それは明らかにあなたの勘違い
今回の質問者は"web"なんていう非常に幅広い曖昧な単語で検索している
これでは多くのライブラリ検索システムにおいてもwebに関係した様々なものが大量に出るであろう
各人で目的のものが異なるのだから質問者の目的のものが2ページ目に出たのは何ら不思議ではない結果

128:デフォルトの名無しさん
22/03/24 19:14:33.26 sVFN7N70.net
>>126
よく知らんけどactix-webが一ページに出るようなキーワードって何かある?
もちろんactix以外で

129:デフォルトの名無しさん
22/03/24 19:18:08.10 bcPLTUMY.net
rust web frameworkでググる

130:デフォルトの名無しさん
22/03/24 19:19:33.96 sVFN7N70.net
>>128
それは人気の分野でしか出来ない方法だな
actixはフレームワークという人気分野だからググったらヒットするけど、ユーザーの少ない分野ではそれは無理

131:デフォルトの名無しさん
22/03/24 19:28:38.65 /Tjfy9fL.net
ちんちんシュッ!シュッ!シュッ!

132:デフォルトの名無しさん
22/03/24 19:32:23.67 Fp4rCRr5.net
rubygemsでwebと検索してもrailsはトップに
来ないけどモーダメダメってこと?

133:デフォルトの名無しさん
22/03/24 19:32:38.88 Qyn6vTpY.net
googleで検索するよな

134:デフォルトの名無しさん
22/03/24 19:36:43.94 M5U7EZzR.net
URLリンク(crates.io) で『web framework』検索してsort by「Recent Downloads」したら
actix-webも5位に出るな
>>121は『web』とだけ検索したのが敗因では?

135:デフォルトの名無しさん
22/03/24 19:44:58.04 geCTUqVE.net
URLリンク(crates.io)
フレームワークタグで見ればactixだらけだしまあいいんじゃね

136:デフォルトの名無しさん
22/03/24 19:45:35.24 1Vr2GJ3G.net
必死なRust信者が単発IDで頑張ってるねw
crate.ioでは良い関連が導出できないのか、そもそも関連の深いものがないのか、効果皆無だったから出さなかったw
ようは全然alternativeが提示されないってことねw
人気=ダウンロード数とできないかどうかなんて些細な点だから、そんな例外を考慮する前に基礎的な仕組みがないことを嘆く必要があるよw
RustスレでRustの話をするのは何の問題もないと思うw
ただvsスレでもない他の言語スレでスレ違いを指摘されても延々とRustの話をしてたRust信者はどうかと思うw
このスレでも嫌われてるよねw Rust w
Rustの教材そんなに売りたいの?w 炎上商法?w 多分こう書くと勉強しはじめる人が増えてゴミ記事が大量に湧くんだろうねw

137:デフォルトの名無しさん
22/03/24 20:16:44.07 /HBDruak.net
>>135
そりゃcrate.ioでは出てこなくて当然
あとここはスレタイにRustもあるし次世代言語の一つなのでスレ違いではない
そもそも貴方がRust叩きをしている筆頭

138:デフォルトの名無しさん
22/03/24 20:22:21.45 1Vr2GJ3G.net
>>136
スレ違いなところに出張して無関係なRustの話を延々放置してても続けるし、指摘してこちらに誘導しても居残り続けるRust信者が嫌われてるという話だよw
ここでRustが叩かれてるのはそういう理由だという話をしているw
Rust自体の魅力は放っておいても世間に滲んでいっていたというのに、お前ら信者が嘘と誇張とルール無視し放題でヘイトを稼いでいるせいで全く浸透してないんだよw

139:デフォルトの名無しさん
22/03/24 20:23:24.39 vuY47/Di.net
そだね~

140:デフォルトの名無しさん
22/03/24 20:40:30.55 fuI32trL.net
アンチには大人気だよな
アンチも湧かない言語は息してない

141:デフォルトの名無しさん
22/03/24 21:22:05.35 1Vr2GJ3G.net
こんなところ読んでる奴は大抵の言語はすでに知っててROMってるのが大半w
他の言語をディスるRust信者は単純に嫌われて(恐らく相当強力な)ユーザーを減らし続けてるだけと分かってくれw

142:デフォルトの名無しさん
22/03/24 22:00:47.79 K94Y9ZL5.net
ユーザーってGAFAMのこと?

143:デフォルトの名無しさん
22/03/24 22:25:26.45 iUQBARfO.net
世の中に影響与えられるほどこの板に人口居るとも思えないが...

144:デフォルトの名無しさん
22/03/24 23:03:48.67 9cbRkQeA.net
対象が有名人などでも何でも同じだが
好きか嫌いかではなく
実は興味があるか無いかの二択
嫌いとかアンチは興味がある側の人
それら含めて興味がある人が多いと話題性があり盛り上がる
そして知らなかった人やそれまで興味を持たなかった人々が興味を持つ機会となる
さらにそこから一定数はファンが生じる

145:デフォルトの名無しさん
22/03/24 23:18:11.18 1Vr2GJ3G.net
炎上商法で成功したソフトなんて1つもないよw 残念だったねw
悲惨な末路しかないw

146:デフォルトの名無しさん
22/03/24 23:18:59.49 DqvTJnEp.net
>>100
やっぱりpythonがブレークした一つのきっかけはnumpyとか機械学習系とかだと思うんですけどその手のライブラリはもう揃ってきてるんですか?

147:デフォルトの名無しさん
22/03/24 23:20:45.72 1Vr2GJ3G.net
このスレで叩かれたり見た人がツイッターで呟く
→違和感を感じた誰かが引用RT
→影響力のある人の目に止まり原因を追い始める
→辿り着いて絶句
→Rust今後やばそうだって思って一歩引いて静観を決める(←イマココ)

148:デフォルトの名無しさん
22/03/24 23:22:34.32 rSdCMchJ.net
>>146
妄想ストーリーにしても上手く作れや

149:デフォルトの名無しさん
22/03/24 23:32:01.53 1Vr2GJ3G.net
肌で感じるTLなんだがw 俺は呟いてないけどw

150:デフォルトの名無しさん
22/03/24 23:51:19.57 rNy1eSrz.net
タブレットモードで使ってるのが悪いのか、Rust謹製のFirefoxはしょっちゅう固まる。
閉じることが出来なくなるのが辛い。

151:デフォルトの名無しさん
22/03/25 00:05:26.84 1tDoEuXw.net
>>149
Linuxで使っているがFirefoxが固まったことはないな
そのOS側の問題ではないか?

152:デフォルトの名無しさん
22/03/25 00:47:48.87 4OElhmyv.net
>>140
このスレをざっと読んだけれど
叩かれている言語はC#とRustで
叩いているのは連投しているキミだと感じた
キミの主張ではどの言語が誰に叩かれているんだい?

153:デフォルトの名無しさん
22/03/25 00:50:09.82 Sf6AbPmi.net
Rustが俺含むRust信者以外にw

154:デフォルトの名無しさん
22/03/25 01:28:59.11 4czHOVAh.net
>>151
そいつ、ここしばらくいろんなスレで荒らしまわってる通称ガイガー君で、何かを聞いてもまともに議論にならないよ

155:デフォルトの名無しさん
22/03/25 02:44:54.38 Sf6AbPmi.net
自演楽しそうだねw 単発ID君w

156:デフォルトの名無しさん
22/03/25 08:17:20.71 yQTGjdBz.net
このスレrustしか話題ないなか?w
いい悪いは別として圧倒的にrustは注目されてて他の言語(Nimとか)は空気だなwwww

157:デフォルトの名無しさん
22/03/25 08:21:15.09 6IycpRpt.net
Nimはオワコン
人気が出なかったからな

158:デフォルトの名無しさん
22/03/25 08:29:35.16 XAr12dgF.net
nimのドット演算子は合理的だと思うけどなぁ。
Pythonあたりに取り込まれんかね。
嫌われている関数呼び出し構文がずいぶん改善すると思う。

159:デフォルトの名無しさん
22/03/25 08:34:02.92 Sf6AbPmi.net
表現方法など1種類であればどうでもいい

160:デフォルトの名無しさん
22/03/25 08:35:38.62 Sf6AbPmi.net
2種類以上あったり、設定により変更できたりしたらオワコンw

161:デフォルトの名無しさん
22/03/25 08:37:33.51 XAr12dgF.net
>>158
Pythonは関数とインスタンスメソッドで呼び出しが2種類あるから駄目なんだよ。

162:デフォルトの名無しさん
22/03/25 08:37:51.44 6IycpRpt.net
今時大企業の莫大な資金力なしに流行る言語を生み出して勝たせることが出来るわけもなし

163:デフォルトの名無しさん
22/03/25 08:43:11.44 Sf6AbPmi.net
表現するものが違ってんじゃん

164:デフォルトの名無しさん
22/03/25 09:08:32.18 u1kd+8tP.net
スレタイにある言語だとNimとRust以外はもう採用領域もある程度固まってて良くも悪くも話題がない
Rustはまだそのレベルに到達するかどうかってラインだから、人によって見方が違って話題になるんだろうね
Nimとかはそもそも知ってる人がほとんどいないレベルだろうからなぁ

165:デフォルトの名無しさん
22/03/25 09:51:57.04 Wd4k06Lv.net
>>163
これだけ幅広く使われているRustに対してそんなに見方変わる?

166:デフォルトの名無しさん
22/03/25 10:35:10.27 yQTGjdBz.net
じゃあ次すれのタイトルはこれでいいなw
次世代言語25 Go Rust

167:デフォルトの名無しさん
22/03/25 10:42:45.45 ON48JF13.net
採用領域とはなんだ?
要するに採用された物以外を規制してるんだろ
Rustが参照を規制しているのと同じようなことを
機械ではなく人間が手動でやってる

168:デフォルトの名無しさん
22/03/25 10:51:27.96 9ogzvJw1.net
>>166
参照を規制してプログラミングするのはどの言語でも同じ
そうしなければ一番広い意味でのデータ競合がどの言語でも起きうる
Rustはそれをどんなに複雑なパターンでもコンパイラがチェックしてくれるという違い

169:デフォルトの名無しさん
22/03/25 11:08:02.15 4czHOVAh.net
Rustが有力になる領域はOSみたいなミドルウェアやベアメタルとかの低レベルなシステムプログラミングよ
その辺だとそもそもC/C++/Rustしか選択肢にないけど

170:デフォルトの名無しさん
22/03/25 11:10:17.42 k+N4+RC0.net
>>168
NimってCにトランスパイルされるらしいけど低レベル領域で使えたりしないの?

171:デフォルトの名無しさん
22/03/25 11:14:36.50 eoZx8ezX.net
Rustを試したことなくてイメージだけで語ってるやつは
ボローチェッカさんの存在を身に染みてないんやろなw
他の言語だとコンパイラさんに叩かれるだけだけど
Rustの場合はボローチェッカさんにも詰められるんやぞ

172:デフォルトの名無しさん
22/03/25 11:21:56.33 QvA9KxTG.net
>>170
あれは本当にありがたいよね
プログラミングの効率が一気に上がった
実行時に無駄にデバッグしていた時間がほとんど無くなったのが大きい

173:デフォルトの名無しさん
22/03/25 11:52:02.01 mOGsJD9H.net
>>169
低レベルを扱いやすくする概念の有無だろ?

174:デフォルトの名無しさん
22/03/25 11:55:17.22 mOGsJD9H.net
>>168
実行速度が求められたり、複雑さなのに安定性が求められるものに向いている気がする
口では何と言っていても実態では安定性にそれほど価値を置いてないケースも多々あるから

175:デフォルトの名無しさん
22/03/25 11:58:21.38 k+N4+RC0.net
>>170
NLL入ってからborrow checkerに怒られることはほとんどなくなったよ
>>172
単によく知らないから質問しただけなんだけど、
Nimは低レベルを扱いやすくする機能は特にないってことか
Cへとトランスパイルされるのは低レベルへの対応というよりも、対応プラットフォーム増やすことや性能稼ぐことが目的という理解で正しい?

176:デフォルトの名無しさん
22/03/25 12:12:09.59 whQHGuOj.net
NimはDと同じようなイメージだな
C++からいろいろ便利にしましたって感じなんだけど、それを言うならC++20だって良くなってるし、わざわざ乗り換えるほどでもないよね、ってなりがち
Rustくらいの特徴が何があれば、多少面倒でも乗り換える人は出てくるんだろうけど

177:デフォルトの名無しさん
22/03/25 12:12:46.01 vqaIaLyp.net
>>174
以前のRustコンパイラはたしかに厳しすぎて吐くエラーも見にくかったけど
non lexical lifetime対応した今のRustコンパイラは普通に書いていれば困ることはなく
コンパイラの出すエラーも非常に見やすくて何が問題なのかすぐわかる上に
何を直すと良いかのアドバイスもあったりしてコンパイラ親切さトップ言語になったね

178:デフォルトの名無しさん
22/03/25 12:28:24.72 XAr12dgF.net
>>175
Rustはbetter c じゃなくてsmart/simplified c++あたりだわな。
Rustよりマイルドなc++標準サブセット出ないかな。

179:デフォルトの名無しさん
22/03/25 12:29:22.46 Sf6AbPmi.net
Rustとかどうでもいいよねw 興味もないしそのうち消えてなくなるよw

180:デフォルトの名無しさん
22/03/25 12:33:45.17 XkeiXeqJ.net
>>178
もちろんRustより良い言語が出てくればそうなるし良い言語が出てくるのは良いこと
しかし現状ではRustより良い言語がないし他に登場する気配もない

181:デフォルトの名無しさん
22/03/25 13:20:25.76 yp7Tyx5s.net
Rustより良い言語が出て自然と消えるのは良いことだろ
ただ、今のところはRustは良い言語だし使いたいと思う

182:デフォルトの名無しさん
22/03/25 14:31:56.50 +bBvNTMI.net
Rust は、Linux カーネルの開発の一部で取り入れるよ、っていう話で初めて注目した。

183:デフォルトの名無しさん
22/03/25 14:32:33.84 2aIwxdP0.net
>>176
おかげでよりブラックボックス化したけどな。まともな文法定義がもうできなくなってる。

184:デフォルトの名無しさん
22/03/25 15:05:30.24 vFivvmZ5.net
>>182
例えばどういう問題が発生してるの?

185:デフォルトの名無しさん
22/03/25 15:22:50.24 k+N4+RC0.net
>>182
NLL導入で文法には影響ないと思うけど何のことが言いたいの?

186:デフォルトの名無しさん
22/03/25 16:28:19.83 yp7Tyx5s.net
>>184
セマンティクスのことを言いたいんじゃないか?

187:デフォルトの名無しさん
22/03/25 16:42:28.63 xgDHHux/.net
具体例を上げてないしレス乞食じゃないの?

188:デフォルトの名無しさん
22/03/25 16:50:09.59 k+N4+RC0.net
>>185
文法定義を気にする人がそんな変な用語の使い方するはずないと思う

189:デフォルトの名無しさん
22/03/25 18:08:36.16 /LCeqdiL.net
>>182
何もブラックボックス化していないし文法定義に変化はない
Rustを叩く人はなぜデタラメばかり言うのだろうか

190:デフォルトの名無しさん
22/03/25 19:28:43.78 szsym4Ce.net
>>184 >>188
え? より厳密になってんじゃないの?
機能の安定化とNLLのバックポートを備えたRust 1.36
Rust 2015でNLLがサポートされたため、古いボローチェッカは間もなく言語から削除されることになる。この移行を安全に行なうために、新たなボローチェッカでは、古いボローチェッカでは受け入れられていたが、新たなボローチェッカでは違反になるコードに対して、警告を発するようになる予定だ。

191:デフォルトの名無しさん
22/03/25 19:46:16.71 xP1gtcBq.net
そろそろ次の次世代出てきませんか

192:デフォルトの名無しさん
22/03/25 19:52:52.64 k+N4+RC0.net
>>189
それは古いborrow checkerのバグでコンパイル通ってなかったコードがエラーなるということだと思う
基本的には新しいborrow checkerの方が制約は緩いはず

193:デフォルトの名無しさん
22/03/25 19:53:32.69 k+N4+RC0.net
>>191
バグでコンパイル通ってなかった、ではなく、バグでコンパイル通ってしまっていた、が正しい

194:デフォルトの名無しさん
22/03/25 20:22:05.99 RUUx2+G1.net
でもバクだろうと通らなくなるんだから文法変わってるという意見が正しいな、ごちゃごちゃ並べ立て言い訳してるみたいだけど

195:デフォルトの名無しさん
22/03/25 20:27:31.26 k+N4+RC0.net
>>193
文法じゃないでしょ

196:デフォルトの名無しさん
22/03/25 20:29:27.44 Mjr9Vw0y.net
文法ってのが構文+意味論みたいなのを指してるなら
NLL導入前後で構文は変わらず意味論は変わったから、まぁ全体としては変わってるでいいんじゃない?
それはそれとして文法定義ができないってのは意味不明だけど

197:デフォルトの名無しさん
22/03/25 20:34:34.89 k9SUNOiI.net
>>193
文法は一切変わっていない
大雑把に言うと
以前はコードの文字通りに追うだけで借用ライフタイムを無駄に広く取ってチェックしていた
だから厳しすぎて今では通る普通のコードが通らなかったりした
変更以降は実際に使われている状況を追うことで借用ライフタイムを実用の意味あるものとした
だからほとんどのケースで緩くなってプログラミングする上で困ることがなくなった

198:デフォルトの名無しさん
22/03/25 20:56:18.04 k+N4+RC0.net
>>189 で言われてるNLL導入でコンパイル通らなくなるcrateって
URLリンク(github.com)
で挙げられてるやつのことかな
壊れる是非はともかくcraterみたいな取り組みは他の言語もパクって欲しい

199:デフォルトの名無しさん
22/03/25 20:58:59.81 tb8uqVBL.net
>>196
フロー解析に頼るって信者的にどうなの?
あくまで型でチェックしてるのが美しいんじゃなかったのか

200:デフォルトの名無しさん
22/03/25 21:02:27.36 I37gdFG5.net
>>196
ある2つの形式言語ABで、同じ文章がAで受理してBで拒否するんだったら、そりゃ「ABは文法が違う」としか言えんな。
まぁ、だからと言って言語自体を否定する類の話じゃないけど、Rustを神聖視するあまり横車を押そうとするのはアホに見えるからやめたほうがいいよ。

201:デフォルトの名無しさん
22/03/25 21:14:19.83 I37gdFG5.net
>>197
crate.ioのこと?
ruby gemとかpython pip とかけっこう一般的な話だと思うけど、何か違うの?

202:デフォルトの名無しさん
22/03/25 21:17:24.39 LQTFL9vM.net
>>199
その程度で文法が変わったとは言わないと思う
その解釈だと今後もRustは文法がどんどん変わる計画となっている
例えばライフタイムについても現在stableでは通らないものがnightlyでは通るように更に緩くなっていくことが確定している
一方でeditionが変われば今まで通っていた記述がエラーとなるなど通らなくなることもある
Rustは今後もどんどん使いやすく向上していくよ

203:デフォルトの名無しさん
22/03/25 21:18:41.95 Sf6AbPmi.net
バカだから他の言語より劣ること分かってないんだよw

204:デフォルトの名無しさん
22/03/25 21:19:38.13 Sf6AbPmi.net
Rustっていうゴミ言語なんてどうでもいいよねw

205:デフォルトの名無しさん
22/03/25 21:23:34.44 0Q30DE2u.net
Rustプログラマーは給料上がっていくだろうね
そうすると人口も増えていく
パイソンもそうだったし

206:デフォルトの名無しさん
22/03/25 21:23:43.31 YQJ39BAy.net
>>201
最終的にライフタイムや借用を人間が一切明示しなくなってGCなしC#みたいになるのがゴールなの?
それでいいのか信者は

207:デフォルトの名無しさん
22/03/25 21:24:25.90 VGJQOYmV.net
>>201
通らなかったものが使えるようになるのはただの拡張だがその逆は破壊的変更。
後者がそう頻繁にあるとは思わんがな。

208:デフォルトの名無しさん
22/03/25 21:25:38.70 I37gdFG5.net
>>201
>その解釈だと今後もRustは文法がどんどん変わる計画となっている
当たり前だろ。
お前は何を言っているんだ? 形式言語の文法を何だと考えているんだか。
そういうアホな主張をするからRust信者は狂信者扱いされるんだよ。

209:デフォルトの名無しさん
22/03/25 21:28:33.82 1BFpe92B.net
>>205
まずは基礎知識を学習すべし
知識なく語るのは愚か

210:デフォルトの名無しさん
22/03/25 21:34:20.09 UcduMPNV.net
>>198
せめてライフタイムとは何かを学ぼうよ
型チェックとは全く関係ない話だよ

211:デフォルトの名無しさん
22/03/25 21:40:29.03 AozLNx79.net
>>200
craterはcrates.ioの全クレートをコンパイルしてみてコンパイラのバージョンアップで壊れるやつがいないかどうかチェックする仕組みのこと
スクリプト言語だとチェックできるのが構文エラーくらいしかないからあまり意味はないかも

212:デフォルトの名無しさん
22/03/25 22:03:36.42 cG5UiOtS.net
>>207
確かに言語の拡張も文法が変わったと言える
どのプログラミング言語も常に文法を変えながら拡張されていくのだろう

213:デフォルトの名無しさん
22/03/25 22:14:57.99 hMpMFfsx.net
>>205
意味が分からないな
コンパイラが正確に正誤を判定してくれるならそれが最善だろ

214:デフォルトの名無しさん
22/03/25 22:16:06.05 4czHOVAh.net
>>182
>まともな文法定義がもうできなくなってる。
意味不明

215:デフォルトの名無しさん
22/03/25 22:30:28.83 6wzTiGXz.net
>>201
同じコードで通る/通らないが変わるのなら、それは普通は「文法の変更」という。
なぜなら、
Error: コード生成が出来ない
Warinig: コードは生成可能だが、普通はこんな事をする必要もないからバグだよね?
だから。ここをRustはおそらく(haskell信者が一時期言ってた)
・Rustのアプリにはバグがない。なぜなら、バグのあるコードは全てコンパイラが落とすから
をやりたいのだろう、通常は警告のところをエラーにしてる。
ただこれは一部馬鹿にとっては逆効果で、
・エラーがなければ全て良し
だと勘違いしてしまってるように見える。
(別人だが)フレームワークにドキュメントで禁止されてるコード食わせてドヤってる馬鹿とか、
>>98 もそう。今時のエディタだと文字列/正規表現リテラルは色が付くが、
エスケープを失敗するとコード全体がリテラルの色になる。いくら馬鹿でもこれを無視はしないだろ。
従う気があればエディタで『予定と違う場所に』色が付くだけで十分なんだよ。
本来は警告も無視せず、一つ一つ問題がないか確認するものだし。
その辺面倒くさがってエラーに一本化した結果、悪癖が付いてしまってる。

ただまあこれはいいとして、
Go(2009)/Docker(2013)だから、これはタイミング的にも「これで勝つる!」だったのだろう。
とはいえDockerは普通の人が組むアプリではないので他案件/構造も引き続き募集中だが、
結局Rust(2010)にはないのか?本当にメモリ安全な言語がなくて困ってる奴がいれば飛びついているはずで、
時期的には2014頃に何か出現しててもおかしくないのだが。
未だに何もないのなら、所詮は馬鹿向けC++で、ポシャる見通しの方が高いだろうよ。

216:デフォルトの名無しさん
22/03/25 22:38:33.17 eYNPgwi0.net
>>214はまたいつもの意味不明なことしか言えないキチガイだな

217:デフォルトの名無しさん
22/03/25 22:39:20.33 SCzIX8G9.net
Dockerのくだり分からん

218:デフォルトの名無しさん
22/03/25 22:43:28.74 4czHOVAh.net
Ruby on Railsのようなキラーアプリ(ライブラリ)はRustにないのか、っていう話でしょ
そもそもRustはシステムプログラミング言語だし、そういう低レイヤーに縁がないエンジニアはこれからも使う可能性低いっしょ

219:デフォルトの名無しさん
22/03/25 22:49:09.03 k+N4+RC0.net
>>199
文法って言ったらシンタックスであってコンパイラはシンタックスだけをチェックしてるわけじゃないんだから
コンパイラが受理しないからと言って文法が違うとはならないでしょ
>>214
文法の変更って言ったら普通は例えばBNFが変わるとかそういう話でしょ

220:デフォルトの名無しさん
22/03/25 22:49:43.62 883KHxPC.net
>>214
君は書き込みをする前に二つの点を改善しなさい
一つ目は意味の分かる文章を書くこと
頭をゼロにして読み返してみればおかしなところに気付くはず
二つ目は批判したい対象についてもっと学習すること
妄想で話を進めるから意味不明と間違いが多い

221:デフォルトの名無しさん
22/03/25 22:55:01.03 6wzTiGXz.net
>>216
(スレ的に昔の話を混ぜ込んでわかりにくくなってたのならすまん)
90で言ったとおり、Dockerを組みたいのならGoは多分最適で、結果、
Go(2009)/Docker(2013)と順当な期間でデビューし、その界隈では広く使われるに至ってる。
Dockerのアイデアが先にあって偶々出てきたGoに飛びついたのか、
GoにインスパイアされてDockerの構造を思いついたのかは分からんが。
Rustが「他の言語では現実的に不可能な」レベルの得意分野があるのなら、
同様に、Rustが最適だ、と思えるアプリが既にあるか、開発中のはず。
俺は何度も言ってるが(C)を目指すべきだと思ってるので、(89参照)
その言語が得意とする構造等があれば、
俺が作りたいアプリにそれが含まれてたらその言語を使う、というだけ。
(言語の習得が目的ではない)

222:デフォルトの名無しさん
22/03/25 23:09:22.77 f8iKGyO6.net
>>220
前にもデタラメと意味不明なことを書いていた人だったのか
浅はかな知識ならびに自分勝手にこうでなければならないと決めつけた話を元に暴走しているためにデタラメと意味不明になっている

223:デフォルトの名無しさん
22/03/25 23:13:11.92 v9JvqvSg.net
>>194
顔真っ赤で内容ゼロの反論してきて不覚にもワロタw

224:デフォルトの名無しさん
22/03/25 23:17:57.63 sK8SIzoZ.net
>>218
文法=構文って思ってるのは分かるけど皆がそうとは限らないよ
自分だったら構文と意味論の区別が問題になるようなこのケースで
文法なんてあいまいな用語は使わないけど
強いて言うなら構文と意味論は両方文法に含まれると思っている

225:デフォルトの名無しさん
22/03/25 23:20:42.33 Sf6AbPmi.net
ほとんどが単発IDの自演だぞw

226:デフォルトの名無しさん
22/03/25 23:20:59.36 UErfWwQw.net
>>193
いわゆる普通に文法を意味するところのsyntaxは変わっていない

227:デフォルトの名無しさん
22/03/25 23:25:23.45 k+N4+RC0.net
>>223
カジュアルに文法って言葉使ってるなら自分も気にしないんだけど
>>182 が文法定義って言ってたり
>>199 で形式言語って言ってたりして
それどういう意味で言ってるの?ってのが気になってつっかかってしまった

228:デフォルトの名無しさん
22/03/25 23:26:20.50 4czHOVAh.net
>>220
実際、Rustの最高のターゲットはシステムプログラミングだから、そういう意味ではCと似ている
だからLinuxカーネル、Android OSみたいな巨大プロジェクトでも採用されるまでに至った
その他の有名事例はFirefoxは常識として、Dropboxのファイルストレージ、DiscordのStateサーバ、Figmaのmultiplayerサーバ、AWSのS3/CloudFront/Bottlerocketとかかな
URLリンク(www.rust-lang.org)
細かく挙げればここにあるようにいくらでもあるけど、眺めてみると件数としてはhigh performanceを求めて採用する事例が多いかな

229:デフォルトの名無しさん
22/03/25 23:32:52.17 6wzTiGXz.net
>>218
> コンパイラが受理しないからと言って文法が違うとはならないでしょ
少なくともCではほぼ同義だし、他言語でもそんなもんだと思うけど。
Cの場合は「自分の足を撃て」で躊躇なく撃つ言語なので、エラーは、
・シンタックスエラー
・記憶領域(変数のサイズ)等が確定的でなく、オブジェクトコードに出来ない
 (これはC特有で、要はソースを食わせる順が間違ってたりしててサイズを知らない物が存在した場合。
 2パスコンパイルをしてる他言語では発生しない)
だから、他言語でもコンパイルが通らない=文法エラー、という認識が普通だと思うよ。
Rustの場合は他言語だと警告のところをエラーにしてるから話がおかしくなる。
元々全部警告にしてたら、誰も文法が変わったとは認識しないだろうよ。
だけどそういうコードの存在自体を許さないのだから、エラーにしているわけで。
元々コンパイラは色々情報持ってるんだから、気づいたおかしなところも吐いてくれ=警告で、
なら警告チェックを厳しくしてバグ検出出来るんじゃね?=リンターなわけ。
だから簡易リント機能は元々コンパイラにあって、さらにそれを強化して専用にした物がリンターと呼ばれる。
で、ここで「文法が変わった」かどうかを争ってても意味ないと思うが。
他言語出身者なら、同じコードで通る/通らないが変わるのなら、「文法が変わった」と認識するし、
コンパイラ屋なら、構文解釈に変更なくリント機能だけが強化/緩和されたのなら、「文法は変わってない」と言い張るだろうさ。
(実際にリント機能部分だけの変更なのかは知らんが)

230:デフォルトの名無しさん
22/03/25 23:36:20.64 8M8bRdYX.net
例えば自分はWebでReact/Next.jsを使っているんだけど
そこで使われているトランスパイラがRust製のswcへ変わったよ
色んな分野で代替する新たな良いものが出てくるとRust製が多いね

231:デフォルトの名無しさん
22/03/25 23:41:25.24 k+N4+RC0.net
>>228
Cみたいなシンタックスにセマンティクスが浸食してる言語例に出すあたりマジで何も分かってないんですね
それにCのエラーだってシンタックスエラー以外に型エラーとかいろいろあるでしょ
とにかく文法という言葉の使い方が独特すぎるからあなたの言うところの文法とは何かをちゃんと定義して欲しい
コンパイル時にエラーと判断されうるものは全て文法という理解で良い?
リンク時エラーも文法エラー?

232:デフォルトの名無しさん
22/03/25 23:57:36.32 6wzTiGXz.net
>>227
> Linuxカーネル
それ前も言ったけど、forkしただけで、採用されてないよ。
> Firefox
結果シェアはズタボロに落ちて最早ゴミ。対応面倒で切られてる始末だろ。
> Discord
ブログにあった件なら、生存オブジェクトが大量にあるのにGC言語(Go)を使った点が間違ってる。
ただ、Go側で「GC非対象ヒープ」を(自前ででも)用意すれば済んだ話。
あれで言語移行したのはただの趣味だと思うよ。
他は知らんが、Goでも採用実績なんていくらでもあるし、Rustよりは多いと思うよ。
それを全部見るのは無理なので、折角詳しくて布教したがってる連中が居るのだから聞いてみるか、というわけ。
Goの連中はピンポイントでDockerを出してきたし、納得するものでもある。
Rustにはねえのか?という話。
(ただしDockerと同様の物を俺が組む事は多分無いので、他案件/構造も募集)
>>229
本当に「この言語じゃないと現実的に無理」なら、「書き換え」ではなく「新分野を開拓」出来るはずだ。
Dockerの構造は「新規」だよ。

233:デフォルトの名無しさん
22/03/26 00:05:21.48 xT2VrKPz.net
>>231
そんな言いがかりみたいなでたらめ並べてうれしいのかね
それともそれら次々とRustで置き換わっていく恐怖に怯えての言動かね

234:デフォルトの名無しさん
22/03/26 00:18:45.11 JI2pA1P6.net
ドッカーは確かにgoで書かれているが、作ったイメージをコンテナとして動かすランタイムはRustで書かれてたりするのだよね
抽象化されてることすら知らなそうけど

235:デフォルトの名無しさん
22/03/26 00:19:28.54 W/ip1wOX.net
>>231
そんなにGo使いたいならRustのことを気にせずGo使ってどうぞ
Goも良い言語だから安心してね

236:デフォルトの名無しさん
22/03/26 00:22:51.04 W/ip1wOX.net
実際、Dockerほどの人気があるプロダクトはめったに生まれないからね

237:デフォルトの名無しさん
22/03/26 00:27:20.02 Z1/vdmI3.net
ランタイムあるからGoだけではコンテナランタイム作れないって聞いたんだけど本当?

238:デフォルトの名無しさん
22/03/26 00:30:14.44 9D+dR2jG.net
>>232
> 次々とRustで置き換わっていく恐怖に怯えての言動かね
自意識過剰すぎ。
というか、俺はお前らがそこまで言語に拘る意味が分からない。
それが適してたらそれを使うだけ、だろ。
俺がその言語作ったわけでもないし、その言語を使えば俺が偉くなるわけでもないし。
お前が修得出来たのなら、俺も修得出来るし、他の人も同様に修得出来るだけ。
修得で無理に差別化しようとするからおかしな事になるのだと思うが。

>>234
Goは味見して糞言語だったからもう使う気はないがな。
同じ事を何度も書かせて、しかも、それを悪いとしてない事が無理だ。
俺が切れたのはJSONのタグ記述だが。
(ああGo的には自動生成出来るような仕組みがあるから問題ないんだ!としている事は知ってる)

239:デフォルトの名無しさん
22/03/26 00:33:29.42 3brWv6vK.net
Dockerコンテナランタイムは色々あってもちろんRust製もある

240:デフォルトの名無しさん
22/03/26 00:35:20.61 W/ip1wOX.net
>>237
じゃあ自分の使いたい言語を使っていいよ
こんなスレに文句を書きに来てるぐらいだから、本当はRustのことが気になって気になってしょうがないんだろうけど

241:デフォルトの名無しさん
22/03/26 00:43:54.51 9q2PYIcF.net
dockerのどの辺がRustで書かれてんの???wwwww

242:デフォルトの名無しさん
22/03/26 00:44:14.12 d6z2UOgm.net
>>237の人は前スレから一貫していて
Goに対してもクソ言動と批判しつつ
Rustを叩くための棍棒としてGoを使っている
C#については絶賛

243:デフォルトの名無しさん
22/03/26 00:44:35.30 9D+dR2jG.net
>>239
リスカブス乙
俺は定期的に他言語情報をクロールしてるだけだよ。
ただNimがCソースを吐くとは知らなかったのでちょっと気になってるが。(使うとは言ってない)

244:デフォルトの名無しさん
22/03/26 00:51:02.81 9D+dR2jG.net
>>241
> C#については絶賛
してねえだろ。
実際GUIは糞で、JSの方が数段マシ。そりゃ世の中のGUIがHTMLになるのも納得だよ。
GUIのメインスレッド+サブスレッドの構造もよろしくないと思ってる。
(ここら辺も既に書いたが)
ただな、どの言語にも一長一短はあるんだよ。みんな色々考えて、改善してきてるわけだから。
だから、○○言語最強!ではなくて、言語特性を理解した上で選択、としたいわけ。

245:デフォルトの名無しさん
22/03/26 00:54:11.51 AS0dCv5n.net
>>241
それに対してガイガー君がC#を叩く構図だね
もちろんそれ以外の時はガイガー君はRust叩き
二人ともロクでなし

246:デフォルトの名無しさん
22/03/26 00:54:44.30 47RFB1/G.net
Firefoxが墜ちたのは旧エクステンションを切ったからで…(またこの話?)

247:デフォルトの名無しさん
22/03/26 00:58:24.45 W/ip1wOX.net
>>242
そういうのが気になるなら vlang もいいかもね

248:デフォルトの名無しさん
22/03/26 01:01:58.12 LzDSDoUW.net
>>243
JavaScriptも良い言語だけど
型が弱いしTypeScriptは中途半端だから
最近Rustに移ったよ
もちろんサーバーサイドだけでなくブラウザサイドもRustでWASM
WASM⇔JavaScriptのオーバヘッドは誤差範囲とわかり実用的

249:デフォルトの名無しさん
22/03/26 01:25:19.73 9q2PYIcF.net
俺はC#を叩いたことは一度もないw
間違いを指摘し続けてただけだぞw
Rustは変なビジネスチャンスばかり狙った信者が嘘八百並べ立ててるから、すごい怪しげな新興宗教になってるw

250:デフォルトの名無しさん
22/03/26 01:29:08.29 9q2PYIcF.net
半年くらい前までは俺も静かにRustの普及を望んでたんだけどねw
今はもう・・・やばい印象しか受けない

251:デフォルトの名無しさん
22/03/26 01:57:44.71 Y9M7cL9r.net
>>249
ガイガー君は嘘つきだな
Rustの配列とスライスの違いすら知らないことがこのまえ発覚したことで全てバレた
Rust初心者でも知っていることなのにな

252:デフォルトの名無しさん
22/03/26 02:31:08.59 9q2PYIcF.net
[T]がarrayで&[T]がスライスだと間違って覚えてただけだろw 原因はarrayを初期化以外で使ってなかったからってちゃんと書いたw
多分Rustをやってる期間は多分お前よりはるかに長いよw

253:デフォルトの名無しさん
22/03/26 03:04:03.73 R0l+7kK3.net
>>251
そんな間違いする人を初めて見た
正解は[T]がスライスで&はその参照
&が参照を意味するだけにすぎないことも知らない時点でRustを知らないと確定

254:デフォルトの名無しさん
22/03/26 03:36:58.66 9q2PYIcF.net
ないないw きっといっぱいいるw こんな説明だからw
URLリンク(doc.rust-lang.org)

255:デフォルトの名無しさん
22/03/26 04:31:22.21 NboHt8Df.net
>>251
> [T]がarrayで&[T]がスライスだと間違って覚えてただけだろw
酷くおバカな間違いだな
Rustを使ったことがないからそういう勘違いをしてしまう
ちゃんと公式ドキュメントの各1行目を読もうぜ
配列
URLリンク(doc.rust-lang.org)
A fixed-size array, denoted [T; N], for the element type, T, and the non-negative compile-time constant size, N.
スライス
URLリンク(doc.rust-lang.org)
A dynamically-sized view into a contiguous sequence, [T].

256:デフォルトの名無しさん
22/03/26 06:43:20.01 9q2PYIcF.net
それはAPIリファレンスだろw

257:デフォルトの名無しさん
22/03/26 07:50:27.56 ZP/Jhtaq.net
>>62
それ、C/C++が全く出来ないレベルじゃん。メモリやポインターの理解が出来てないから実行時デバッグに時間が掛かる。普通は処理を書いたら動くことを確認するだけで済む。

258:デフォルトの名無しさん
22/03/26 07:54:07.76 Vvd4qIhx.net
>>251
> 多分Rustをやってる期間は多分お前よりはるかに長いよw
はるかに長い期間やっててそれでは知能が低いです

259:デフォルトの名無しさん
22/03/26 08:12:28.41 3FEKWr2M.net
>>256
それはそういう話じゃないと思うぜ
C++とRustの両方使いこなせると分かるが
低レベルであるポインタアクセスがRustでは無くなり抽象化された参照アクセスとなり
安全でないアクセスがコンパイル時点で排除されるためその種の実行時デバッグが無くなる
その件だと思われる

260:デフォルトの名無しさん
22/03/26 08:24:24.55 9q2PYIcF.net
>>257
ただの記憶違いに知能は関係ないw 実際それで困ったことがないからなw

261:デフォルトの名無しさん
22/03/26 08:47:16.92 9LDujC2l.net
>>259
その件は君が嘘をついていると明確になっている
その件の書き込みを見ると君はarrayとsliceを勘違いしただけでなく関数からarrayで返すと明言している
一方でその関数は返り型宣言で必ず[T; N]が現れる
このNは定数であるからさらに宣言することになりarrayでNの存在を忘れる人はいない
しかし君はarrayを[T]だと間違えて覚えていたわけだから矛盾する
君はRustのコードを書いたことがないという結論となる

262:デフォルトの名無しさん
22/03/26 09:14:29.48 9q2PYIcF.net
何を勘違いしちゃったのか知らないけど、こう書いてあるんだけどw
「arrayは定義はあるんだけど、今まで初期化にしか使わなかったから、使わなすぎて間違って覚えてたw」

263:デフォルトの名無しさん
22/03/26 09:23:18.54 6PoAfdDe.net
>>260
正確にはガイガー君はsliceで受けてArrayで返すと言っている
この発言の時点でガイガー君はRustを知らないと証拠
動的サイズのスライスで受けて固定サイズの配列を返すのは不可能だからだ
Nが判明しないと配列で返せないが実行時になるまでスライスの長さは不明
この点からもガイガー君はRustを知らない

264:デフォルトの名無しさん
22/03/26 09:51:30.12 9q2PYIcF.net
ニュアンスが違うんだよw
「それは俺のポリシーとして、可能ならVecを返すならVecを受けたいだけw
今回のケースではメリットとかないよw
同様にsliceで受けたらArrayで返したいし、iteratorを受けたらiteratorを返したいw」
slice->&[T]
array->[T]

265:デフォルトの名無しさん
22/03/26 09:55:08.60 Vvd4qIhx.net
はるかに長い期間やってるのにこの有様
子供の遊びかな?

266:デフォルトの名無しさん
22/03/26 09:56:51.30 9q2PYIcF.net
実際のロジック書くのに使ってたのVecだもんw

267:デフォルトの名無しさん
22/03/26 10:02:36.56 +G9UHc/m.net
結局TypeScriptがどの場においても最強って言いたいの?

268:デフォルトの名無しさん
22/03/26 10:18:06.61 Iuuv9oj0.net
間違ってても普通に説明すりゃいいのにお互いに煽りながら主張しあってるから、くだらない議論が余計に長引く

269:デフォルトの名無しさん
22/03/26 10:39:18.75 9q2PYIcF.net
TypeScriptさいきょー

270:デフォルトの名無しさん
22/03/26 10:44:45.97 Z1/vdmI3.net
>>263
Vecを返す関数は原則引数の型はVecにしたいということ?
敢えてそうする理由ってなにかあるの?

271:デフォルトの名無しさん
22/03/26 11:44:23.82 3zXxZFyx.net
goとtypescriptどっちかを捨てればいいのに
tcshやrubyを捨てるみたいに

272:デフォルトの名無しさん
22/03/26 12:29:34.61 5mCX3GGP.net
新しい言語はどれも配列の宣言があまりきれいじゃない気がする
Cなどの型名 変数名[要素数]だと何か都合が悪いのだろうか
それともやってる感を出すために変えてるの?

273:デフォルトの名無しさん
22/03/26 12:37:22.57 9D+dR2jG.net
>>271
固定長で問題ないならそれが一番いいが、
大体において固定長である事自体がものすごく不便だから。

274:デフォルトの名無しさん
22/03/26 12:41:53.15 sDWgty5N.net
>>271自身がモダンな言語における配列を正しく理解できてないから変なように感じるんじゃないかな
最近の言語ではCスタイルの配列、いわゆる配列変数(複数個の変数が連続して並んでいるもの)はあまり積極的に使用されないんだよ
最近の言語では配列は配列型のオブジェクトであって、変数が並んでるわけじゃないの

275:デフォルトの名無しさん
22/03/26 12:49:13.92 N9qlOq0y.net
>>263
Vecを返すならVecを受けたい、って
例えばこういうこと?
fn foo(input: Vec<i32>) -> Vec<i32> {…}

276:デフォルトの名無しさん
22/03/26 17:16:05.98 +G9UHc/m.net
>>271
Cの形だとパーサーをLRにしないといかんのでは?
GoとかPascalの形だとLLでパースしきってしまえるから早い。

277:デフォルトの名無しさん
22/03/26 18:34:45.11 9q2PYIcF.net
別スレの引用なので、興味があればそれを見てこいw
LL/LRとか懐かしいなw
S式とかに回帰するかw

278:デフォルトの名無しさん
22/03/26 18:46:07.16 MJID/KD0.net
ちんちんシュッ!シュッ!シュッ!

279:デフォルトの名無しさん
22/03/26 20:52:37.86 Vz8Iz6e1.net
>>263
Vecを受けてVecを返すインタフェースに通常することはない
普通は以下のようにする
(1) 同じVecを返す場合 (=書き換えたい場合)
まずこの場合はVec<T>自体を渡さなくても参照を渡せば済む
書き換えるから&mut Vec<T>を渡せばいいように思うが
普通はスライス&mut [T]を渡すインタフェースにする
なぜならVecの書き換え参照を渡すとVecの書き換えしかできないが
スライスの書き換え参照を渡せばVecの途中一部の書き換えもできるし
配列や配列の途中一部の書き換えもできるからである
(2) 別のVecを返す場合 (=引数側のVecのデータから作り出したい場合)
この場合も同様となる
引数としてVec<T>を渡すのではなくスライス共有参照&[T]を引数にする
これで入力データがVecだけでなく配列やそれらの一部でも受け付けることが可能
(2)' (2)のケースで入力を順次アクセスのみする場合
この場合は入力としてイテレータを受け付けられると良い場合がある
なぜならイテレータはVecのようなメモリ領域を必要としないため有利
イテレータを入力とする場合のインタフェースは更に2通りに分かれる
 [a] イテレータのメソッドとしてしまう
  イテレータチェーンに組み込むことができて便利
  ただしVecや配列やスライスに適用する時はinput.iter().method()の形になる
 [b] 引数として IntoIterator<Item=T> を受け付ける
  これだと引数に直接スライス、配列、Vec、イテレータのどれも渡せて便利
  ただしイテレータチェーンに組み込むことはできない
  イテレータメソッドの2つ目の入力インタフェースとしても使われる
どちらの場合でも順次出力でない場合ならばVecを返すのもありだが
順次出力ならばイテレータを返したほうがイテレータチェーンに組み込めて有利
なぜなら中間生成Vecを無駄に返さずに済むからである
この場合にVecが欲しければcollect()すればよい

280:デフォルトの名無しさん
22/03/26 21:26:11.73 9q2PYIcF.net
>>278
間違ってるよw それは俺のポリシーだからw 普通こうするという話じゃないw

281:デフォルトの名無しさん
22/03/26 22:23:14.39 27vH2xuj.net
ガイガー君はRustに関しても素人だから
そういう常識を知らなくても仕方ない

282:デフォルトの名無しさん
22/03/26 22:42:20.46 Z1/vdmI3.net
>>279
なんでそういうポリシーなの?

283:デフォルトの名無しさん
22/03/26 23:07:56.60 Z1/vdmI3.net
>>279
&strじゃなくてString使ったり、&TじゃなくてBox<T>やRc<T>使ったりするのかな
初めて聞くポリシーだからどういう考え方なのかが気になる

284:デフォルトの名無しさん
22/03/26 23:13:02.38 Z1/vdmI3.net
>>279
あっ、もしかしてborrow checker通すために借用使わないようにしてる?

285:デフォルトの名無しさん
22/03/26 23:29:11.35 fQbyL396.net
鋭い指摘だな
確かにガイガー君は参照を使いこなせなくて借用を批判してた

286:デフォルトの名無しさん
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するメリットもない


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