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

**デフォルトの名無しさん** · 2022/03/22(火) 03:23:41.60

スレタイ以外の言語もok

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

**デフォルトの名無しさん** · 2022/03/25(金) 23:41:25.24

>>228
Cみたいなシンタックスにセマンティクスが浸食してる言語例に出すあたりマジで何も分かってないんですね

それにCのエラーだってシンタックスエラー以外に型エラーとかいろいろあるでしょ

とにかく文法という言葉の使い方が独特すぎるからあなたの言うところの文法とは何かをちゃんと定義して欲しい
コンパイル時にエラーと判断されうるものは全て文法という理解で良い？
リンク時エラーも文法エラー？

**デフォルトの名無しさん** · 2022/03/25(金) 23:57:36.32

>>227
> Linuxカーネル
それ前も言ったけど、forkしただけで、採用されてないよ。

> Firefox
結果シェアはズタボロに落ちて最早ゴミ。対応面倒で切られてる始末だろ。

> Discord
ブログにあった件なら、生存オブジェクトが大量にあるのにGC言語(Go）を使った点が間違ってる。
ただ、Go側で「GC非対象ヒープ」を（自前ででも）用意すれば済んだ話。
あれで言語移行したのはただの趣味だと思うよ。

他は知らんが、Goでも採用実績なんていくらでもあるし、Rustよりは多いと思うよ。
それを全部見るのは無理なので、折角詳しくて布教したがってる連中が居るのだから聞いてみるか、というわけ。
Goの連中はピンポイントでDockerを出してきたし、納得するものでもある。
Rustにはねえのか？という話。
(ただしDockerと同様の物を俺が組む事は多分無いので、他案件/構造も募集）

>>229
本当に「この言語じゃないと現実的に無理」なら、「書き換え」ではなく「新分野を開拓」出来るはずだ。
Dockerの構造は「新規」だよ。

**デフォルトの名無しさん** · 2022/03/26(土) 00:05:21.48

>>231
そんな言いがかりみたいなでたらめ並べてうれしいのかね
それともそれら次々とRustで置き換わっていく恐怖に怯えての言動かね

**デフォルトの名無しさん** · 2022/03/26(土) 00:18:45.11

ドッカーは確かにgoで書かれているが、作ったイメージをコンテナとして動かすランタイムはRustで書かれてたりするのだよね
抽象化されてることすら知らなそうけど

**デフォルトの名無しさん** · 2022/03/26(土) 00:19:28.54

>>231
そんなにGo使いたいならRustのことを気にせずGo使ってどうぞ
Goも良い言語だから安心してね

**デフォルトの名無しさん** · 2022/03/26(土) 00:22:51.04

実際、Dockerほどの人気があるプロダクトはめったに生まれないからね

**デフォルトの名無しさん** · 2022/03/26(土) 00:27:20.02

ランタイムあるからGoだけではコンテナランタイム作れないって聞いたんだけど本当？

**デフォルトの名無しさん** · 2022/03/26(土) 00:30:14.44

>>232
> 次々とRustで置き換わっていく恐怖に怯えての言動かね
自意識過剰すぎ。

というか、俺はお前らがそこまで言語に拘る意味が分からない。
それが適してたらそれを使うだけ、だろ。

俺がその言語作ったわけでもないし、その言語を使えば俺が偉くなるわけでもないし。
お前が修得出来たのなら、俺も修得出来るし、他の人も同様に修得出来るだけ。
修得で無理に差別化しようとするからおかしな事になるのだと思うが。

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

**デフォルトの名無しさん** · 2022/03/26(土) 00:33:29.42

Dockerコンテナランタイムは色々あってもちろんRust製もある

**デフォルトの名無しさん** · 2022/03/26(土) 00:35:20.61

>>237
じゃあ自分の使いたい言語を使っていいよ
こんなスレに文句を書きに来てるぐらいだから、本当はRustのことが気になって気になってしょうがないんだろうけど

**デフォルトの名無しさん** · 2022/03/26(土) 00:43:54.51

dockerのどの辺がRustで書かれてんの？？？ｗｗｗｗｗ

**デフォルトの名無しさん** · 2022/03/26(土) 00:44:14.12

>>237の人は前スレから一貫していて
Goに対してもクソ言動と批判しつつ
Rustを叩くための棍棒としてGoを使っている
C#については絶賛

**デフォルトの名無しさん** · 2022/03/26(土) 00:44:35.30

>>239
リスカブス乙
俺は定期的に他言語情報をクロールしてるだけだよ。

ただNimがCソースを吐くとは知らなかったのでちょっと気になってるが。（使うとは言ってない）

**デフォルトの名無しさん** · 2022/03/26(土) 00:51:02.81

>>241
> C#については絶賛
してねえだろ。
実際GUIは糞で、JSの方が数段マシ。そりゃ世の中のGUIがHTMLになるのも納得だよ。
GUIのメインスレッド＋サブスレッドの構造もよろしくないと思ってる。
（ここら辺も既に書いたが）

ただな、どの言語にも一長一短はあるんだよ。みんな色々考えて、改善してきてるわけだから。
だから、○○言語最強！ではなくて、言語特性を理解した上で選択、としたいわけ。

**デフォルトの名無しさん** · 2022/03/26(土) 00:54:11.51

>>241
それに対してガイガー君がC#を叩く構図だね
もちろんそれ以外の時はガイガー君はRust叩き
二人ともロクでなし

**デフォルトの名無しさん** · 2022/03/26(土) 00:54:44.30

Firefoxが墜ちたのは旧エクステンションを切ったからで…(またこの話？)

**デフォルトの名無しさん** · 2022/03/26(土) 00:58:24.45

>>242
そういうのが気になるなら vlang もいいかもね

**デフォルトの名無しさん** · 2022/03/26(土) 01:01:58.12

>>243
JavaScriptも良い言語だけど
型が弱いしTypeScriptは中途半端だから
最近Rustに移ったよ
もちろんサーバーサイドだけでなくブラウザサイドもRustでWASM
WASM⇔JavaScriptのオーバヘッドは誤差範囲とわかり実用的

**デフォルトの名無しさん** · 2022/03/26(土) 01:25:19.73

俺はC#を叩いたことは一度もないｗ
間違いを指摘し続けてただけだぞｗ
Rustは変なビジネスチャンスばかり狙った信者が嘘八百並べ立ててるから、すごい怪しげな新興宗教になってるｗ

**デフォルトの名無しさん** · 2022/03/26(土) 01:29:08.29

半年くらい前までは俺も静かにRustの普及を望んでたんだけどねｗ
今はもう・・・やばい印象しか受けない

**デフォルトの名無しさん** · 2022/03/26(土) 01:57:44.71

>>249
ガイガー君は嘘つきだな
Rustの配列とスライスの違いすら知らないことがこのまえ発覚したことで全てバレた
Rust初心者でも知っていることなのにな

**デフォルトの名無しさん** · 2022/03/26(土) 02:31:08.59

[T]がarrayで&[T]がスライスだと間違って覚えてただけだろｗ原因はarrayを初期化以外で使ってなかったからってちゃんと書いたｗ
多分Rustをやってる期間は多分お前よりはるかに長いよｗ

**デフォルトの名無しさん** · 2022/03/26(土) 03:04:03.73

>>251
そんな間違いする人を初めて見た
正解は[T]がスライスで&はその参照
&が参照を意味するだけにすぎないことも知らない時点でRustを知らないと確定

**デフォルトの名無しさん** · 2022/03/26(土) 03:36:58.66

ないないｗきっといっぱいいるｗこんな説明だからｗ
https://doc.rust-lang.org/book/ch04-03-slices.html

**デフォルトの名無しさん** · 2022/03/26(土) 04:31:22.21

>>251
> [T]がarrayで&[T]がスライスだと間違って覚えてただけだろｗ

酷くおバカな間違いだな
Rustを使ったことがないからそういう勘違いをしてしまう
ちゃんと公式ドキュメントの各1行目を読もうぜ

配列
https://doc.rust-lang.org/std/primitive.array.html
A fixed-size array, denoted [T; N], for the element type, T, and the non-negative compile-time constant size, N.

スライス
https://doc.rust-lang.org/std/primitive.slice.html
A dynamically-sized view into a contiguous sequence, [T].

**デフォルトの名無しさん** · 2022/03/26(土) 06:43:20.01

それはAPIリファレンスだろｗ

**デフォルトの名無しさん** · 2022/03/26(土) 07:50:27.56

>>62
それ、C/C++が全く出来ないレベルじゃん。メモリやポインターの理解が出来てないから実行時デバッグに時間が掛かる。普通は処理を書いたら動くことを確認するだけで済む。

**デフォルトの名無しさん** · 2022/03/26(土) 07:54:07.76

>>251
> 多分Rustをやってる期間は多分お前よりはるかに長いよｗ

はるかに長い期間やっててそれでは知能が低いです

**デフォルトの名無しさん** · 2022/03/26(土) 08:12:28.41

>>256
それはそういう話じゃないと思うぜ
C++とRustの両方使いこなせると分かるが
低レベルであるポインタアクセスがRustでは無くなり抽象化された参照アクセスとなり
安全でないアクセスがコンパイル時点で排除されるためその種の実行時デバッグが無くなる
その件だと思われる

**デフォルトの名無しさん** · 2022/03/26(土) 08:24:24.55

>>257
ただの記憶違いに知能は関係ないｗ実際それで困ったことがないからなｗ

**デフォルトの名無しさん** · 2022/03/26(土) 08:47:16.92

>>259
その件は君が嘘をついていると明確になっている
その件の書き込みを見ると君はarrayとsliceを勘違いしただけでなく関数からarrayで返すと明言している
一方でその関数は返り型宣言で必ず[T; N]が現れる
このNは定数であるからさらに宣言することになりarrayでNの存在を忘れる人はいない
しかし君はarrayを[T]だと間違えて覚えていたわけだから矛盾する
君はRustのコードを書いたことがないという結論となる

**デフォルトの名無しさん** · 2022/03/26(土) 09:14:29.48

何を勘違いしちゃったのか知らないけど、こう書いてあるんだけどｗ
「arrayは定義はあるんだけど、今まで初期化にしか使わなかったから、使わなすぎて間違って覚えてたｗ」

**デフォルトの名無しさん** · 2022/03/26(土) 09:23:18.54

>>260
正確にはガイガー君はsliceで受けてArrayで返すと言っている
この発言の時点でガイガー君はRustを知らないと証拠

動的サイズのスライスで受けて固定サイズの配列を返すのは不可能だからだ
Nが判明しないと配列で返せないが実行時になるまでスライスの長さは不明
この点からもガイガー君はRustを知らない

**デフォルトの名無しさん** · 2022/03/26(土) 09:51:30.12

ニュアンスが違うんだよｗ
「それは俺のポリシーとして、可能ならVecを返すならVecを受けたいだけｗ
今回のケースではメリットとかないよｗ
同様にsliceで受けたらArrayで返したいし、iteratorを受けたらiteratorを返したいｗ」
slice->&[T]
array->[T]

**デフォルトの名無しさん** · 2022/03/26(土) 09:55:08.60

はるかに長い期間やってるのにこの有様
子供の遊びかな？

**デフォルトの名無しさん** · 2022/03/26(土) 09:56:51.30

実際のロジック書くのに使ってたのVecだもんｗ

**デフォルトの名無しさん** · 2022/03/26(土) 10:02:36.56

結局TypeScriptがどの場においても最強って言いたいの？

**デフォルトの名無しさん** · 2022/03/26(土) 10:18:06.61

間違ってても普通に説明すりゃいいのにお互いに煽りながら主張しあってるから、くだらない議論が余計に長引く

**デフォルトの名無しさん** · 2022/03/26(土) 10:39:18.75

TypeScriptさいきょー

**デフォルトの名無しさん** · 2022/03/26(土) 10:44:45.97

>>263
Vecを返す関数は原則引数の型はVecにしたいということ？
敢えてそうする理由ってなにかあるの？

**デフォルトの名無しさん** · 2022/03/26(土) 11:44:23.82

goとtypescriptどっちかを捨てればいいのに

tcshやrubyを捨てるみたいに

**デフォルトの名無しさん** · 2022/03/26(土) 12:29:34.61

新しい言語はどれも配列の宣言があまりきれいじゃない気がする

Cなどの型名変数名[要素数]だと何か都合が悪いのだろうか
それともやってる感を出すために変えてるの？

**デフォルトの名無しさん** · 2022/03/26(土) 12:37:22.57

>>271
固定長で問題ないならそれが一番いいが、
大体において固定長である事自体がものすごく不便だから。

**デフォルトの名無しさん** · 2022/03/26(土) 12:41:53.15

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

**デフォルトの名無しさん** · 2022/03/26(土) 12:49:13.92

>>263
Vecを返すならVecを受けたい、って
例えばこういうこと？
fn foo(input: Vec<i32>) -> Vec<i32> {…}

**デフォルトの名無しさん** · 2022/03/26(土) 17:16:05.98

>>271
Cの形だとパーサーをLRにしないといかんのでは？
GoとかPascalの形だとLLでパースしきってしまえるから早い。

**デフォルトの名無しさん** · 2022/03/26(土) 18:34:45.11

別スレの引用なので、興味があればそれを見てこいｗ
LL/LRとか懐かしいなｗ
S式とかに回帰するかｗ

**デフォルトの名無しさん** · 2022/03/26(土) 18:46:07.16

ちんちんシュッ！シュッ！シュッ！

**デフォルトの名無しさん** · 2022/03/26(土) 20:52:37.86

>>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()すればよい

**デフォルトの名無しさん** · 2022/03/26(土) 21:26:11.73

>>278
間違ってるよｗそれは俺のポリシーだからｗ普通こうするという話じゃないｗ

**デフォルトの名無しさん** · 2022/03/26(土) 22:23:14.39

ガイガー君はRustに関しても素人だから
そういう常識を知らなくても仕方ない

**デフォルトの名無しさん** · 2022/03/26(土) 22:42:20.46

>>279
なんでそういうポリシーなの？

**デフォルトの名無しさん** · 2022/03/26(土) 23:07:56.60

>>279
&strじゃなくてString使ったり、&TじゃなくてBox<T>やRc<T>使ったりするのかな
初めて聞くポリシーだからどういう考え方なのかが気になる

**デフォルトの名無しさん** · 2022/03/26(土) 23:13:02.38

>>279
あっ、もしかしてborrow checker通すために借用使わないようにしてる？

**デフォルトの名無しさん** · 2022/03/26(土) 23:29:11.35

鋭い指摘だな
確かにガイガー君は参照を使いこなせなくて借用を批判してた

**デフォルトの名無しさん** · 2022/03/26(土) 23:34:15.32

なんか哀れだよね彼は

**デフォルトの名無しさん** · 2022/03/26(土) 23:41:42.26

同じ型の方が設計意図が明白になるし、繋げやすいからｗそれだけだよｗ他のにする理由がないよねｗ
まあもとのスレにも理由は書いたけどｗ

**デフォルトの名無しさん** · 2022/03/26(土) 23:58:50.18

>>286
繋げやすい？？
全く意味不明だ
繋げるならばメソッドチェーンにすべき
そしてVecが中間生成物となるのは無駄となるバッドパターン
イテレータメソッドチェーンにすべき
イテレータを使わないならばスライスを引数で渡すべき

**デフォルトの名無しさん** · 2022/03/27(日) 00:23:39.64

>>287
君にとって意味不明なら意味不明でいいよｗそう思っていればいいｗ
ポリシーとはそういうものｗ菜食主義者に肉を食わないとはケシカランって言ってるようなものだからｗ

**デフォルトの名無しさん** · 2022/03/27(日) 00:25:07.45

>>286
借用で済ませて良い場所で所有権要求するのは普通じゃないからドキュメントコメントにちゃんと書いた方が良いよ

**デフォルトの名無しさん** · 2022/03/27(日) 00:30:12.96

>>288
技術分野でのポリシーとはまず意味のある目的がありそのために設定される
それを説明せずにポリシーとだけ唱えて普通ではない非合理なインタフェースにしているから叩かれる

**デフォルトの名無しさん** · 2022/03/27(日) 01:18:29.05

ｗｗｗｗｗ
知ってて書いてるんだと思うが、もとを読めば分かるけど、参照で受けてるよｗ

**デフォルトの名無しさん** · 2022/03/27(日) 01:35:46.26

>>291
見てみた
確かに引数の型をVecの参照にしてることがわかった
そして元のお題では一貫してずっとlet input = ["a", "b", "c"];となっているのに
引数の型をVecの参照にしてしまったためそこだけlet input = vec!["a", "b", "c"];としている
つまりに引数の型をVecの参照したのは明白な失敗となっている
もちろん正解は引数の型をスライスにすること
これで配列もVecも受け取れる

**デフォルトの名無しさん** · 2022/03/27(日) 03:52:33.29

>>292
だから失敗したからではなくて、何度も言ってるようにポリシーとして合わせたんだよｗ
正解は動くことｗ 2つの方法からsliceとしない方を選択したのｗ

**デフォルトの名無しさん** · 2022/03/27(日) 04:12:54.52

>>293
それまでに他の人たちが書いたコードは入力元データが全てlet input = ["a", "b", "c"];と配列になっているね
そして関数の引数の型は全てスライス&[T]となっているね

ところが唐突にその引数の型を&Vec<T>へと変更したコードが登場
それまでの入力元の配列をスライスで渡すことが出来なくなる破綻
破綻の辻褄を合わせるため入力元データを配列から無駄で無意味なlet input = vec!["a", "b", "c"];へと変更
それまで入力元が配列でもスライスでもVecでも大丈夫だったのに入力元がVecしか受け付けなくなっているね

**デフォルトの名無しさん** · 2022/03/27(日) 07:57:46.18

> 2つの方法からsliceとしない方を選択したのｗ

キミはスライスが何なのかも知らなかったでしょ
自分の知能が低いのを弁えないと恥かくよ

**デフォルトの名無しさん** · 2022/03/27(日) 08:56:07.10

>>294-295
何を言いたいのか知らんが、I/F部分は自由にいじってるので、渡す型が変わるのなんて何の問題もないよｗ

**デフォルトの名無しさん** · 2022/03/27(日) 09:20:19.51

>>296
元々は利便性の良いスライスや効率で優る配列も受け付けていたのに
貴方の変更では効率の劣るVecのみを受け付けとなってコードが退化している

**デフォルトの名無しさん** · 2022/03/27(日) 10:51:24.60

>>297
何度も言ってるようにポリシーｗ

**デフォルトの名無しさん** · 2022/03/27(日) 10:56:32.38

>>298
劣ったコードにするポリシーかよ…

**デフォルトの名無しさん** · 2022/03/27(日) 11:10:30.04

さすがに可哀想やからもうやめたれ

**デフォルトの名無しさん** · 2022/03/27(日) 11:41:31.93

>>299-300
別に劣っても可哀想でもないよｗ意図が明白なコードになってるｗ

**デフォルトの名無しさん** · 2022/03/27(日) 12:11:24.82

面白い課題なんだね
input = ['a', 'b', 'c']; と集合が与えられた時に
そのべき集合（＝全ての部分集合）を返す関数subsets()を作成せよ、ってことか
[]とか['a']とか['a', 'b']とか['a', 'b', 'c']とか全てを漏れなく返せと

**デフォルトの名無しさん** · 2022/03/27(日) 12:27:49.24

初学の人でもすぐ書ける簡単なロジックだよｗ

**デフォルトの名無しさん** · 2022/03/27(日) 12:39:06.02

>>303
じゃあプログラム書いてみて

**デフォルトの名無しさん** · 2022/03/27(日) 14:06:20.96

>>301
Vec<T>を引数で受けることは配列全体の所有権を関数に委譲するという意図を表明してるんだけど
そういう意図ということで認識合ってる？

**デフォルトの名無しさん** · 2022/03/27(日) 15:46:34.95

このスレでも参照って何度も書いてんだけどｗアホなのｗ？

**デフォルトの名無しさん** · 2022/03/27(日) 20:05:48.71

たかだか数年で身につけたスキル、しかも数年後には使ってないかもしれないスキルでイキってんじゃねーよ

**デフォルトの名無しさん** · 2022/03/27(日) 21:23:46.37

Rustは数年後にはなくなってるかもねｗ

**デフォルトの名無しさん** · 2022/03/27(日) 23:33:02.98

人間よりは長生きしてもらわないと
AIが人間に勝てそうな所がどんどん減っていく

**デフォルトの名無しさん** · 2022/03/27(日) 23:40:27.92

Rustなんて人間に負けっぱなしな印象しかないけど・・・ｗ

**デフォルトの名無しさん** · 2022/03/28(月) 05:38:25.18

恥ずかしながら質問なんだがNimって何？

**デフォルトの名無しさん** · 2022/03/28(月) 06:43:08.84

中間生成となる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"]

**デフォルトの名無しさん** · 2022/03/28(月) 08:08:20.92

>>311
目の前にある箱で検索しろ

https://ja.wikipedia.org/wiki/Nim

**デフォルトの名無しさん** · 2022/03/28(月) 11:24:54.13

>>297
横からみてた感想だけど、コードの目的（全てのサブセットを列挙する）達成できているのに退化とは？
その論説は本来の設問からすると別のゴールが生えてる

**デフォルトの名無しさん** · 2022/03/28(月) 12:05:00.42

ツッコミついでにスライスの参照ではなくVecでインターフェース書くメリットについて考えてみたが
これ考え方がモロにPythonのそれだわ
こういう設計はRustだとあんまりやらないが、これをVecから派生した型へのimplとして書くとそこまで違和感ない

「Rustっぽくない」のは指摘されてる通りだが、思想としてはたぶんそこから来てる

**デフォルトの名無しさん** · 2022/03/28(月) 12:12:56.02

Pythonはそのまま例えばこんな感じで書かれた関数をオブジェクトに代入してメソッドに使えるからPythonって言ったけど
とにかくオブジェクト指向にどっぷり頭まで漬かった設計だな

元の「どちらのやり方もある」発言も、「関数型の書き方に寄せるかオブジェクト指向的な書き方に寄せるか」という意味なら納得
（まあオブジェクト指向に寄せるならimplで書けよなんだが）

**デフォルトの名無しさん** · 2022/03/28(月) 14:02:45.07

>>314
元々に挙げられていた例は入力が配列
そして彼のコードは配列を入力として受け付けなくなっているから退化であっている

**デフォルトの名無しさん** · 2022/03/28(月) 14:31:13.30

>>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するメリットもない

**デフォルトの名無しさん** · 2022/03/28(月) 22:32:51.22

ガイガー君完敗か

**デフォルトの名無しさん** · 2022/03/28(月) 23:11:23.81

1+1=の結果とか誰も興味ない上、俺がindex版、iterator版、vector版3つ正解を書いてやった後も、誰も興味のないその話題をひたすら続けて無視された挙げ句、このスレにまで持ってきて見当違いな自画自賛と自作自演の嵐ｗ
どれだけバカなんだよｗ

**デフォルトの名無しさん** · 2022/03/28(月) 23:19:40.94

>>318
ガイガー君とやらは配列とスライスの違いすら知らなかった超初心者だから仕方ないんじゃないか
もちろんスライスに対して実装すればVecにも配列にも適用できるからそれがベストチョイス

**デフォルトの名無しさん** · 2022/03/29(火) 01:19:51.25

>>312
Rustってスクリプト言語みたいに簡単に書けるんやな

**デフォルトの名無しさん** · 2022/03/29(火) 17:06:45.34

このスレなんでJuliaは扱わないの？

**デフォルトの名無しさん** · 2022/03/29(火) 18:10:38.94

Juliaって数値計算に特化してるイメージなんだけどそれ以外の用途でも良い感じに使えるの？

**デフォルトの名無しさん** · 2022/03/29(火) 19:43:35.70

数値計算というのはひたすら配列に対してループをぶん回すもんで、FortranやJuliaはそういう処理の記述に特化している
そういう意味だと、数値計算以外だと昔のCOBOLみたいに愚直に一行ずつレコードを処理していくような古典的なバッチ処理には向いてるんじゃないかな

**デフォルトの名無しさん** · 2022/03/29(火) 22:44:22.64

>>321
本人乙ｗ配列とスライスの違いは分かってたけど、配列の定義を誤って覚えてただけだよｗ
Juliaは入れていいと思うｗ

**デフォルトの名無しさん** · 2022/03/29(火) 22:53:46.10

>>326
あんたは [T] を配列だと思っていた
もちろん [T] はスライスが正解
これはあんたが配列とスライスの違いをわかっていなかったことを意味する

**デフォルトの名無しさん** · 2022/03/30(水) 08:18:40.34

型無し糞言語勧めてくる屑どもを全員●したい

**デフォルトの名無しさん** · 2022/03/30(水) 08:41:28.55

今時型無し言語を使うやつはそんなにいないだろ
動的型付け言語は使うが