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

**デフォルトの名無しさん** · 2021/08/22(日) 08:59:03.31

スレタイ以外の言語もok

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

**デフォルトの名無しさん** · 2021/10/23(土) 18:10:31.38

RustってC++のmoveが楽になった言語の認識だったけど
ここ読むと捉え方ちがうような気がしてきた

**デフォルトの名無しさん** · 2021/10/23(土) 18:12:33.07

>>288
競プロでもしてんじゃね

**デフォルトの名無しさん** · 2021/10/23(土) 18:14:14.05

最安で欲しい物を手に入れる方法が購入ではなく盗むことだとしたら盗むか？

unsafeで最速にするというアイデアはそういうイメージ

**デフォルトの名無しさん** · 2021/10/23(土) 18:26:04.70

>>289
メモリ安全性保証などの話は別にしても
C++は最初の小さな家Cを何度も建て増ししてきたような言語
Rustは最初から最新のパラダイムを洗練して採り入れた言語なのでプログラミングのしやすさがかなり違うかな

**デフォルトの名無しさん** · 2021/10/23(土) 18:53:49.04

誰もがc++ありえんと思ってて、代わりの候補もたくさん出てきた中で、ようやく使い物になりそうなのがrust

**デフォルトの名無しさん** · 2021/10/23(土) 19:14:18.65

C++が互換性を無視して不必要な機能をばっさり切り捨てることができればだいぶましな言語になる気がするけどそんなことはできないんだろうな。

**デフォルトの名無しさん** · 2021/10/23(土) 19:41:04.11

互換性がないバージョン1から3があるなら
最も不必要なのは2なんだよ
2を無視して1の互換性を重視するのは言うほど悪くない

**デフォルトの名無しさん** · 2021/10/23(土) 20:21:23.52

たしか、あわしろ氏がLinuxをRustで書き直すプロジェクト始めたはず。

**デフォルトの名無しさん** · 2021/10/23(土) 20:24:24.83

どこで？

**デフォルトの名無しさん** · 2021/10/23(土) 21:01:07.99

>>285
0か100しか認めないタイプか？
ストレスでハゲてそうだな。

**デフォルトの名無しさん** · 2021/10/23(土) 23:36:13.26

Rustは難しい言語ではない。気軽に始めてみるところからスタートしよう。Rust活用企業の現場に聞いてみた
https://engineer-lab.findy-code.io/rust

松本おおおおおおおお！

**デフォルトの名無しさん** · 2021/10/24(日) 14:51:32.96

FacebookはReactとかVRあるから日本でも結構重要なポジションになりつつあるな
SNSは全然流行ってないとしても

**デフォルトの名無しさん** · 2021/10/24(日) 17:16:59.20

c++の安心側に制約を追加したSmart c++は欲しい。Rustは要らない。

**デフォルトの名無しさん** · 2021/10/24(日) 18:13:51.90

D言語の話した？

**デフォルトの名無しさん** · 2021/10/24(日) 19:18:02.70

F#……

**デフォルトの名無しさん** · 2021/10/24(日) 20:44:53.71

F#って結局何作れる言語なの？

**デフォルトの名無しさん** · 2021/10/24(日) 23:46:02.08

>>301
プログラミングしやすいRustがあるのにC++ベースにはもう戻りたくないよね

**デフォルトの名無しさん** · 2021/10/24(日) 23:51:33.94

そういえばWebAssembly Studioなんてのがあるのを最近知った
https://webassembly.studio/

**デフォルトの名無しさん** · 2021/10/25(月) 00:38:46.00

>>301
c++23で契約プログラミングが標準化されたら改善するかも？

**デフォルトの名無しさん** · 2021/10/25(月) 00:42:01.96

そういやrustって契約プログラミングをサポートする文法あったっけ？

**デフォルトの名無しさん** · 2021/10/25(月) 01:31:51.79

https://crates.io/crates/contracts

**デフォルトの名無しさん** · 2021/10/25(月) 23:17:33.61

結局、データの共有かコピーかが楽に設定できるかどうかってことに焦点が当たって、
rustは捨てられることになるよ。
こんな明らかなことさえわからん連中ばっかなのが面倒ごとだな。

**デフォルトの名無しさん** · 2021/10/25(月) 23:55:02.93

コピーの反対はムーブかもしれないので、コピーの反対は共有だろうという雑な考えを捨てよう

**デフォルトの名無しさん** · 2021/10/26(火) 10:23:33.99

>>267
goroutineのネイティブスレッドとM:N関係。軽量と言っても、当然、中でコンテキストスイッチのように
実行の切り替えがある。他の言語は（機能が）無いので真っ当に比較出来ないが、ほかの言語で似た外部の
ライブラリを入れるとgoより重たいし、nodeのように、I/Oバウンドな非同期しかないと1つが詰まったら
全部止まるデメリットがある。goのGCが遅めなのは、当然、このgoroutineの並行性における不可分操作が
難しいからであり、rustのRc/Arcやnimの--gc:arc/orcに比べ並行性を保ちながら参照カウントを不可分の
操作にするとコストがとても大きくなるためと言われる。多くの人が勘違いしているのは、理論上はRcより
（トレース系のGCは）GCのほうが効率的（高速化が望める）だ、ただしGCはネックが生じる

**デフォルトの名無しさん** · 2021/10/26(火) 11:22:52.21

バカが老害ガー言われ始めるのに大体１０年くらいかかる。
こうして流行は終わる。

**デフォルトの名無しさん** · 2021/10/27(水) 12:05:58.55

Crystal入れてください

**デフォルトの名無しさん** · 2021/10/27(水) 14:14:45.58

存在感微妙だし。nimもいらんな

**デフォルトの名無しさん** · 2021/10/27(水) 15:48:46.91

Zigでもいれとく？

**デフォルトの名無しさん** · 2021/10/27(水) 16:26:23.01

Vがいいかも

**デフォルトの名無しさん** · 2021/10/28(木) 12:19:59.27

Vの良さでも語ってくれ
情報少なすぎてよく分からない

**デフォルトの名無しさん** · 2021/10/28(木) 13:00:24.39

あれは詐欺だろ

**デフォルトの名無しさん** · 2021/10/29(金) 00:13:25.52

vlangは0.3が全然出ないね。mutを後から導入したのがよほど不具合頻発になったのだろうか

**デフォルトの名無しさん** · 2021/10/30(土) 02:12:19.09

次に取り沙汰されるのはKokaみたいなAlgebraic Effectsのある言語だと思う

**デフォルトの名無しさん** · 2021/10/30(土) 02:29:08.63

取り沙汰される、って何年後のことやねん
やたら表現力高そうだし、ベストプラクティスがなかなか定まらなそう

**デフォルトの名無しさん** · 2021/10/30(土) 03:11:26.17

rustだgoだと言ってたら一瞬Vが騒がれて消えてなくなって今はnimなの？
今ならrustでいいじゃん
クッソ速くて賢くて小さくて安全でどこでも動いて便利な使いやすい言語誰か作ってくれ
一番大事なのは速いことな

**デフォルトの名無しさん** · 2021/10/30(土) 08:15:37.97

Nim is efficient, expressive, and elegant.

どこらへんがどうエレガントなのか謎やわ

**デフォルトの名無しさん** · 2021/10/30(土) 10:49:51.87

「エレガントさ」とか「楽しさ」で売ってる言語はクソの法則

**デフォルトの名無しさん** · 2021/10/30(土) 11:52:44.92

他の言語の存在を無視したりOSの存在を無視したりしたら
まともな説明ができなくなる
空虚な言葉を使うのは原因というよりむしろ結果

**デフォルトの名無しさん** · 2021/10/30(土) 13:21:47.38

むしろ複数のコンピュータをまとめて1つの環境として扱い、その環境で最適化して実行可能な言語を作ってくれ

**デフォルトの名無しさん** · 2021/10/30(土) 13:40:35.45

>>327
速度優先とメモリ効率優先は誰が決めるの?

**デフォルトの名無しさん** · 2021/10/30(土) 14:03:03.78

>>328
細かい部分は最適配分して決めるとしか
最初は適当なヒューリスティックでいい

**デフォルトの名無しさん** · 2021/10/30(土) 22:25:15.35

>>324
公式は3つ挙げてる。macro記述と言語そのもの差異がほとんど無いことを挙げている。$aとか別言語になったり
してない。もう１つはpython風の構文がエレガントだと言っている（これはpython風の構文を多くの人が嫌うの
で賛否が分かれると思う）もう１つは多くの言語が該当するので書かない。個人的にはvar/letじゃなくlet mutや
いちいち打つ::や、マクロで!とかの方がエレガントだと思わんけど、goでいえばpanicがあるのにtry/catchが無い
（多値戻りの2番目にerrorを入れてif判定させる）、genericsがまだ無いのもエレガントとは思えない

**デフォルトの名無しさん** · 2021/10/30(土) 22:27:20.82

>>327
Juliaでは、標準ライブラリの一つとして提供されているDistributedモジュールで分散メモリ並列計算を実装して
いる。Juliaのベースインストール状態では、2種類のクラスタがサポートされる。（1つはローカル）
・複数のマシンからなるクラスタ。--machine-fileオプションで指定する。パスワードが不要なSSHを
用いてJuliaのワーカプロセスを指定した計算機で分散される
@distributed for i = 1:100000
a[i] + b[i]
end
こういうのが１つの実行環境で複数のコンピュータでクラスタ実行される
--machine-fileで
3 164.67.165.21 # 3process
5 164.67.165.22 # 5process

**デフォルトの名無しさん** · 2021/10/30(土) 22:36:16.21

まあmacro記述を簡単にインライン展開するために別言語風になるのも分かるけど、、名前衝突が起きないように
デフォルトで別名に自動で名前を付けて展開してインライン展開する場合は特殊タグを付けるほうが

**デフォルトの名無しさん** · 2021/10/30(土) 23:31:55.44

>>331
そんなの言語レベルのサポートいらんやん
分散も並列化も勝手にやってくれ
プロセスもマシンも意識したくない
意識してもいいけど必須じゃなく、自動で可能な限り適切にリソースが配分されてほしい
プロセスとかそんなざっくりした単位でもなくね
それが実現可能な言語を用意せよと言っている

**デフォルトの名無しさん** · 2021/10/31(日) 00:40:29.24

それって言語じゃなくてOSとか別のレイヤーが果たす役割じゃね？

**デフォルトの名無しさん** · 2021/10/31(日) 00:43:34.15

言語レベルサポートが無いということは、分散も並列化も勝手にやったら不可分解の通常のforループも
分解されてしまうので、そんなことは不可能。繰り返し順次実行と、（表現上は繰り返しだが）並列実行
では意味も結果も異なる。
要らないというコンピューター言語学での証明は無い。思想的には集合要素に対するmap/reduceなどが
並列の操作ができるからと言って、forだけで表現できる語彙ではない。言語の標準ライブラリにreduce
などのAPIがある事は、それそのものが（並列に実行していないのに）並列性の表現と同じ意味。
CPU側でそれが並行操作可能か、何らしらのマーカーは必要というのは素人以外はすぐ分かる事
>”言語を用意せよと言っている”おまえ何様やねんｗ

**デフォルトの名無しさん** · 2021/10/31(日) 00:44:58.68

プログラミング言語という概念すら理解してないのがこのスレの住人のレベル

**デフォルトの名無しさん** · 2021/10/31(日) 01:28:26.60

>>334
その通り。分散コンピューティング/グリッド・コンピューティングなどではミドルウェアが利用される。
Erlangなどでも、分散処理できるがspawn(node, ...)などノードを意識しなくてはならない。また
CPU処理が分散できたからと言って、ファイルシステムなどローカルしかないため、大規模分散には
分散ファイルシステムが必要になり、Googleのようにbigtableができ、その上で耐故障性を備えるように
仮想化して、スケールアウトやオーケストレーションのためにkubernetesなどなど、別レイヤーが
果たす役割が多い

**デフォルトの名無しさん** · 2021/10/31(日) 01:35:34.83

そういうことじゃないｗ
俺様が言ってるのはマシン/アプリ/ライブラリ/OS/デバイスの垣根を超えて
言語とそれらの複合環境がカバーしうる汎用な表現が可能な言語やｗ
作れｗ

**デフォルトの名無しさん** · 2021/10/31(日) 01:43:15.98

基地外かあ…、この業界こういうの大杉壮大な能無し基地外のかまってちゃん

**デフォルトの名無しさん** · 2021/10/31(日) 01:47:23.36

例えば組み込み制御系で使えばCの配列を作るのと同じ記述でスケールしたら分散KVSもどきやらが出来上がるような言語
並列実行可能かどうかはあるロジックの入力が別のロジックの出力を使ってるかどうかだけ

**デフォルトの名無しさん** · 2021/10/31(日) 01:58:47.24

できそうにないだろ？
既存のアーキテクチャにどっぷりなら
高速にぶん回したかったらrustでもC++でもgolangでも使えばいいし
スケールするだけで十分な速度が出るなら誰でも使える言語を使ってスケールすればいいし
僅かに違う新しめの言語の差分をネタに趣味・嗜好を語るよりは夢を語った方が有意義でないかい？ｗ

**デフォルトの名無しさん** · 2021/10/31(日) 02:01:52.96

Common Lisp

**デフォルトの名無しさん** · 2021/10/31(日) 02:08:26.79

おまえのチンポコの穴から並列でションベン出来るか考えてロンパーロンパーしてろｗくそ基地外ｗ

**デフォルトの名無しさん** · 2021/10/31(日) 02:12:58.45

おまえがいるだけで世の中迷惑、人の足引っ張りまくり、親に迷惑かけまくり、誰もがお前を見ると顔をしかめる。
クズの癖に１つも優れた能力も、努力もなく、相手を貶し、悦に入る
問題の原因の根本たるおまえが消えて無くなれば、よほど有意義

**デフォルトの名無しさん** · 2021/10/31(日) 10:57:39.56

LISP専用CPUとRISC-CPUを聴き間違えたけど同じもの？

**デフォルトの名無しさん** · 2021/10/31(日) 11:13:06.97

>>330
微妙だね。
マクロもオフサイドルールも賛否分かれそうだし、最後に至っては「Goよりはエレガント」ってｗ

**デフォルトの名無しさん** · 2021/10/31(日) 12:55:57.25

>>346
公式はgoと比べてる訳じゃないよ？

**デフォルトの名無しさん** · 2021/10/31(日) 13:41:46.14

Goは断捨離の観点でエレガント
try throw catchなんか無くても関数は返り値をエラー値とタプルで返せばいいし
classなんかなくても構造体と関数でいいし
イテレータなんか使わずともfor回せばいい

**デフォルトの名無しさん** · 2021/10/31(日) 13:50:44.46

落ち着いていて品のよいさま。上品。優雅。エレガン。
（考え方や手法などが）簡潔で要を得たさま。手際のよいさま。明快なさま。

抽象度は高めたほうが優雅なのでは？

**デフォルトの名無しさん** · 2021/10/31(日) 13:56:01.91

昔のperlみたいにならないよう糖衣構文やそれに類するモノはどちらかに振った方がいい(エレガントな)こともある
結局は好みだけどなｗ

**デフォルトの名無しさん** · 2021/10/31(日) 14:23:30.67

中置記法をユーザー定義する構文糖を否定したやつは失敗
PythonとC++は少なくともその失敗をしなかった

**デフォルトの名無しさん** · 2021/10/31(日) 15:04:58.04

Nim言語では最近特定のunicode文字を2項演算子としてオーバーロードできるようになりました。
unicodeにある文字を演算子として使うのは文字を入力し辛いとか∪∨がアルファベットのUVと似ていて紛らわしいとかで反対派もいるようですが。

https://nim-lang.org/docs/manual.html#lexical-analysis-unicode-operators

proc `*` (x: Dollar, y: int): Dollar =
result = Dollar(int(x) * y)

みたいな感じで'*'演算子を定義できます。

https://nim-lang.org/docs/manual.html#procedures

**デフォルトの名無しさん** · 2021/10/31(日) 15:42:26.32

Nim言語にはtype classというのがあって、これを使うと特定の種類の型のみに限定されたgeneric procedureを簡単にかけます。
詳しくは
https://nim-lang.org/docs/manual.html#generics-type-classes

Nim言語ではprocedure/template/macroを呼び出す方法が複数あって、
foo(arg1, arg2)という普通の書き方に加えarg1.foo(arg2)というオブジェクト指向のメソッドぽく呼ぶMethod call syntaxと括弧を省略してコマンドラインぽくfoo arg1, arg2と書くcommand invocation syntaxがあります。
https://nim-lang.org/docs/manual.html#procedures-method-call-syntax
https://nim-lang.org/docs/manual.html#procedures-command-invocation-syntax

**デフォルトの名無しさん** · 2021/10/31(日) 15:50:59.21

実に表現豊かでエレガントですねぇ…☺

**デフォルトの名無しさん** · 2021/10/31(日) 16:18:17.43

>>353
type classは関数型言語Haskell発祥
そのNimのページを見る限りその貧弱なおもちゃ版に見える
例えばNimと同じ手続き型言語のRustのtraitも用語は違えどtype classなので比較するとわかりやすいが機能面でも型付け面でも強力

**デフォルトの名無しさん** · 2021/10/31(日) 17:04:32.64

>>348
言ってる事はその通り。goで構文上、覚える事の少なさは”非常に良い”が、上の簡潔で要を得たさまを借りて
言えば、finallyに相当するdeferはあるのに、?演算子が無いだけでerrが2番目というルールでifを多発させる。
これはRust/Swift/HaskellのResult/Option/Either標準伴うルールとほぼ同じだが、?演算子が無いだけで
if err != nil { return nil, err }を書かなくてはならない。あるいは(panicではなく)exceptionに対する
try/catch/finallyとも言い換えることが出来る

**デフォルトの名無しさん** · 2021/10/31(日) 17:32:36.81

https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md
このドラフトでもRustの?演算子とかが言及されてるけど、そういうのはやっぱ欲しいわ

**デフォルトの名無しさん** · 2021/10/31(日) 18:15:22.28

演算子なら
∩∪⊕
あたりは欲しい

**デフォルトの名無しさん** · 2021/10/31(日) 18:21:20.58

>>355
最初に実装されたのはHaskellだがコンピュータサイエンスではもっと早く提唱されていた。NimはAdaから影響で
Haskellからも影響は当然あるが、範囲型の実装などはAdaから来ていると一般的には言われる。逆に、Rustは
機能面でHaskellのType classはフルセットでサポートしていない。traitは別の概念でType classを一部限定して
サポートしているに過ぎない。範囲型すら無いし、type c = a or cなんて出来ない、それとコンパイラ言語で
型付け面が強力では無い言語なんていまどきの言語なら珍しい、ランタイムが無くnative-compileなら尚更。

**デフォルトの名無しさん** · 2021/10/31(日) 18:42:57.86

Goに関して言えばユーザー定義のiteratorは何度もproposalされて撥ねられてるがいずれ入るちゃうかな？
演算子に関して言うならinや->,=== ,<>,instanceofなんていうものが世の中あるので、UTF-8/16で
関数名が書ける言語なら、uniform-func-callが出来る言語ならなおさら出来ないのはおかしかった

**デフォルトの名無しさん** · 2021/10/31(日) 20:07:49.45

>>359
typeのorならばRustでも色んな複数の方法で様々なアレンジ付けて出来るよ
例えばi32と&strのorをそのtraitを用いてするのも可能で
trait I32OrStr {}
impl I32OrStr for i32 {}
impl I32OrStr for &str {}

fn print<T: I32OrStr + std::fmt::Display>(x: T) {
　println!("{}", x);
}

fn main() {
　print(100);
　print("abc");
}
これでi32と&str以外の型は受け付けないprint()関数の出来上がり
あとtraitとimplの中身が{}で空なところにアレンジを書いたり

**デフォルトの名無しさん** · 2021/10/31(日) 20:24:12.66

例えば素朴な例だけどこんな感じ？
trait I32OrStr {
　fn info(&self) -> String;
}
impl I32OrStr for i32 {
　fn info(&self) -> String {
　　format!("{} <-- i32", self)
　}
}
impl I32OrStr for &str {
　fn info(&self) -> String {
　　format!("{} <-- &str", self)
　}
}

fn print<T: I32OrStr>(x: T) {
　println!("{}", x.info());
}

fn main() {
print(100);
print("abc");
}
これで>>361と同じくprint()関数はi32と&strしか受け付けないけど
実行結果は>>361と異なり型毎に別表示
100 <-- i32
abc <-- &str

**デフォルトの名無しさん** · 2021/10/31(日) 20:38:03.38

trait利用でなくもちろんenum利用で型のorも可能ですね
使い勝手が異なるのでRustでは両者を使い分け用いることが出来ます
enum I32OrStr<'a> {
　I32(i32),
　Str(&'a str),
}

fn print(x: I32OrStr) {
　match x {
　　I32OrStr::I32(n) => println!("i32: {}", n),
　　I32OrStr::Str(s) => println!("&str: {}", s),
　}
}

fn main() {
　let n = I32OrStr::I32(100);
　print(n);
　let s = I32OrStr::Str("abc");
　print(s);
}

**デフォルトの名無しさん** · 2021/10/31(日) 22:21:09.61

>>356
それくらい書けやとしか思わんわ。
まあパターンマッチで変なnullチェック減らすとかは入れてもいいと思うが。

**デフォルトの名無しさん** · 2021/10/31(日) 23:58:11.44

rustってデフォルトだと共用体みたいな形になるんだっけ？

**デフォルトの名無しさん** · 2021/11/01(月) 08:07:15.03

だからそれはtraitでありtype classじゃないでしょ。どっちが”貧弱なおもちゃ”やねん。こんな単純な事を
表現するためにクダラナイ事を何度も何行も貼り付けるなよ。もう一つについてはTagged Unionだが、Adaも
Swift/Nim/Pythonも出来るし、”両者を使い分け用いる”なんて必要ない。そもそも単純に書こうとしたら
or表現や、Typescriptのようにtype C = A | B;部分型だし、このように表現するのが限りなく一般的で
一行でシンプルです。Rust唯一教徒の話は回りくどい上にキモ過ぎる、別にRustそのものを否定している訳じゃ
無いし、traitは他にあまり無い十分に柔軟性がある特性なんだから、奇妙な信仰的な推し方をすんな

**デフォルトの名無しさん** · 2021/11/01(月) 08:14:17.55

go2もgenericsと関連して、Tagged union的なType set/Type list/Sum typeが入るはず

**デフォルトの名無しさん** · 2021/11/01(月) 10:40:50.02

めっちゃ早(ry

**デフォルトの名無しさん** · 2021/11/01(月) 11:40:40.03

趣味・嗜好は昇華して信仰になる！
実際に共用体になるのとポインタだけ入るのを同じに分類したら何でもありな気はするｗ

**デフォルトの名無しさん** · 2021/11/01(月) 23:50:22.01

>>366
それは君の理解が浅く、君が間違っている。

まず、Rustのtraitはいわゆるtraitとは異なる。
つまりシェリルのtrait論文に従う他の言語のtraitとは異なっており、
複数traitでメソッドの名前衝突重複が起きたときに、メソッドの排除や名前の変更利用などのtraitが満たす条件を備えていない。
一方でRustのtraitでは重複自体は許して、メソッド呼び出しは一意性がないため許さず、関連関数呼び出しが自由に許される。

次に、Rustのtraitはいわゆる(Haskellの)type classに基本的な部分で合致している。
一番重要なところでいうと、Rustのtrait境界はHaskellのtype class制約である。
もちろん一般的なtraitにはこのような概念機能はない。
つまりRustのtraitはtraitではなくtype classであることがわかっていただけると思う。きちんと理解しているならば。

**デフォルトの名無しさん** · 2021/11/02(火) 01:20:08.88

そもそもB | Cのようなad-hocな型制約をRust開発者が好まないというだけのことだと思う
関数オーバーロードもC++のテンプレート特殊化みたいなのも無いし

**デフォルトの名無しさん** · 2021/11/02(火) 01:42:04.85

はあ…基地外が一生懸命調べて反論してるって感じだな、何が論文だ？気持ち悪りぃ

”一番重要なところでいうと、Rustのtrait境界はHaskellのtype class制約である”
Type classは制約だけではありません、アドホック多相を実現するための機能です。概念だけなら20年前の
Haskellから影響を受けているのは近代的な言語なら当然ですが、RustのtraitはHaskellのType classではなく
実装はSubtypingです。そもそも”貧弱なおもちゃ”に負けてるRange typeとかSum typeとか、Typescriptに
すらあるのに無い事、無理やりコードを書いて実現しようと自己弁護している事、Rustの書き手が減るような
非常に醜い弁護行為なので止めなさい

”つまりRustのtraitはtraitではなくtype classであることがわかっていただけると思う”
日本語でも、英語でも理解してますか？他の言語のtraitとは同じだと誰も主張していませんよ？そもそもこれも
因果関係が逆転しています。type classの「ほんの一部」を実現するために(rustの）traitを用いているだけです。

きちんと日本語と英語を理解しているならば、このような「間違い」は起きないはずです。それは君が理解が
難癖を付けたい基地外であり、おまえのような態度が気持ち悪い奴らRustの発展を阻害しているのです。

**デフォルトの名無しさん** · 2021/11/02(火) 02:02:23.69

ググってみたがRustのtraitは普通のtraitではない話がたくさんあるな
あとRustのtraitはHaskellの型クラスだという話も多数あるな
世間での認識は>>370で合ってるんじゃね？

**デフォルトの名無しさん** · 2021/11/02(火) 02:15:11.25

ID変えてまた自己弁護、市ね基地外

**デフォルトの名無しさん** · 2021/11/02(火) 07:36:44.59

ようはCommon Lispみたいなマクロ使える言語が最強って事だろ？

**デフォルトの名無しさん** · 2021/11/02(火) 08:27:57.62

>>372
Rustで実装できない具体例を挙げたら？
そっちの方が早い。

**デフォルトの名無しさん** · 2021/11/02(火) 08:34:53.92

>>375
せや、あんたが優勝や

**デフォルトの名無しさん** · 2021/11/02(火) 08:39:57.46

このクズは誰も言って無い事を言い出す、「他の言語のtraitとは同じ」「Rustで実装できない」
こんなことは誰も言ってない。
おまえはさ、Rustの発展にも、会社にも、社会にも邪魔だから消えろよ？おまえみたいのは、まだ技術が
浅く新しい人が入ってくる障害だからね

**デフォルトの名無しさん** · 2021/11/02(火) 10:07:28.88

>>378
お前は>>372？
じゃあ、「無理やりコードを書いて実現」についてのHaskellとの具体的なコードの比較でいいよ。
あと、「type classの「ほんの一部」を実現するために(rustの）traitを用いているだけです。」について、Rustのtraitで実装できないtype classのHaskell実装例。

まずはそれについて>>370に反論させりゃいい。
コードもないんじゃ傍から見ててつまらんよ。

**デフォルトの名無しさん** · 2021/11/02(火) 11:09:50.76

人の話を聞くのは正しいことかもしれないが
つまらない話を禁止したり面白い話を強制するぐらいなら人の話を聞かない方が正しい

**デフォルトの名無しさん** · 2021/11/02(火) 11:15:37.18

両方とも気持ち悪いなと思ってたら
もう一人気持ち悪いのが出てきたww
いつもの次世代wスレ

**デフォルトの名無しさん** · 2021/11/02(火) 11:48:12.43

また違う人物のふりして出現か、傍から見てる人が「お前は」なんてイキナリ怒り心頭顔真っ赤で言うかよ。
おめーがつまんねえから

**デフォルトの名無しさん** · 2021/11/02(火) 12:12:25.90

C++のtemplate引数はダックタイピング
ダックタイピングは気持ち悪い
HaskellとRustは気持ち悪くない

マクロ引数の問題はtemplate引数よりも更に気持ち悪い

**デフォルトの名無しさん** · 2021/11/02(火) 12:29:54.01

Haskellを悪く言うやつを見たことがない
もう全部Haskellでいいよ

**デフォルトの名無しさん** · 2021/11/02(火) 13:43:18.32

C++もね、conceptでだいぶマシになったんだけどね
そもそもどれだけの環境でC++20が使えるんだという話をされるとぐうの音も出なくなる

**デフォルトの名無しさん** · 2021/11/02(火) 14:57:01.19

>>384
俺は毎日のように悪く言ってるよ
数学オタクが作った非実用的な言語だってな

**デフォルトの名無しさん** · 2021/11/02(火) 15:36:03.35

3人いようが4人いようがそれ以上でも
描き込み全部気持ち悪い事実は変わらない

**デフォルトの名無しさん** · 2021/11/02(火) 16:14:12.44

お前らが気持ち悪さに敏感なのは良いことだと思う
気持ち悪さの応酬をして平気なツラしてるような地獄のスレもある

**デフォルトの名無しさん** · 2021/11/02(火) 18:13:46.42

Nim言語にもconceptがあります。(まだexperimentalだけど)
https://nim-lang.org/docs/manual_experimental.html#concepts

conceptやtype classを使ってgenerics(c++のtemplateに相当)の引数に指定できる型を制限すれば気持ち悪さを軽減できるか思います。

けどNimのseq[T](C++のstd:::vector<T>、Rustのstd::Vec<T>に相当)のようなコンテナ型にはコピー可能な型なら何でも指定できるわけですが、こういうのが気持ち悪いと言われても指定できる型を限定すれば不便になるだけだと思うのですが。