プログラミング言語 Rust 4

**デフォルトの名無しさん** · 2017/10/14(土) 17:38:14.04

Mozilla発のプログラミング言語「Rust」のスレです

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

前スレ
プログラミング言語 Rust 3
https://mevius.5ch.net/test/read.cgi/tech/1495343069/

**デフォルトの名無しさん** · 2018/01/15(月) 15:28:44.95

>>688
君ははた迷惑な例のアンチかな？
破綻している証拠とやらをその辺はとか適当な言葉で誤魔化してる時点で説得力がないよ。
てか、君には聞いていない。君以外に聞いてるんだ。

**デフォルトの名無しさん** · 2018/01/15(月) 16:35:55.57

木構造にRcは要らんだろ
各ノードは直接の親にしか所有されないんだから

**デフォルトの名無しさん** · 2018/01/15(月) 17:21:29.47

質問1について分かりやすいのがforループだな
あるベクタをforループ中に、forの対象にしてるベクタそのものにpushするみたいな黒魔術操作を禁止するために
forループを回してる間は回す対象の配列にイミュータブル参照を作ってる状態にしてコンパイラにチェックさせる

**デフォルトの名無しさん** · 2018/01/15(月) 17:44:57.62

質問1がそうなっている理由は、以下のようなケースで解放済みのVecにアクセスしてしまうことを防ぐというのもある
let mut foo = Some(vec![]);
let foo_mut = &mut foo;
let foo_ref = foo.as_ref().unwrap();
foo_mut = None;
println!("{:?}", foo_ref); // drop 済みのVecへのアクセス

**デフォルトの名無しさん** · 2018/01/15(月) 19:10:45.82

重箱の隅だが四行目は
*foo_mut = None
だな

**デフォルトの名無しさん** · 2018/01/15(月) 20:48:46.10

>>691, >>692
なるほど。mutable参照が1つしか取れない理由はマルチスレッド以外にも理由があったのか。
単純なコードだけど実際に示されないと気が付けないな。(少なくとも俺は)
やっぱりGC無しの言語はメモリ管理が難しいな。
そして、それをコンパイラがはじいてくれるのはやっぱり有難い。
納得のいく答えが得られた。教えてくれてありがとう。

>>690
それは木構造でも親から子を辿るだけで済む場合に限定されない？子から親を辿りたくなった場合だと無理じゃない？
子は複数いるんだからそれぞれの子が全て親のmutable参照を持つことはできないよね。
だって、mutable参照は1つしか作れないんだから。
そうするとRcとWeakとRefCellを使わざるを得なくなるよね？ならない？使わなくても済む方法があるの？
ちなみにRcじゃなくてArenaっていう仕組みを使うって方法ならどっかのブログで見たんだけど、
その方法だと動的に追加していくことは出来るけど、動的に削除を行うことは出来ないよね。
例えばJavaScriptのDomツリーとかはparentNodeで子から親のNodeを辿れるようになってるし、
appendChildとかremoveChildとかでNodeを動的に追加したり削除したりももちろん出来るよね。
それと同じようなことをRustでもしたかったらRcとWeakとRefCellを使うしかないんじゃないかと思ってるんだけど。

**デフォルトの名無しさん** · 2018/01/15(月) 20:53:28.00

双方向参照する場合はそう

RefCell使わなければならないケースでrustの方がうれしいのは、
実行時にはなってしまうが&mutのエイリアスがチェックされることかな
C++だと領域破壊してもそれらしく動いてしまうとかあり得てバグの発見が遅れる

**デフォルトの名無しさん** · 2018/01/16(火) 05:17:55.44

Rustで木を作ったぞ!

https://play.rust-lang.org/?gist=dc4c67944190cb7ab83b2e25e4fdd4e2&;version=stable

**デフォルトの名無しさん** · 2018/01/16(火) 12:11:08.60

https://news.mynavi.jp/article/20180110-568199/
モジラ工作員ざまあ！！！wwwww
いやー一年は工作でごまかせたかもしれないがさすがにメッキが剥げてきたね！
これが現実！！
騙されてるやつはまだ間に合うぞ！

**デフォルトの名無しさん** · 2018/01/16(火) 12:21:19.07

>>697 ……
https://qiita.com/kmizu/items/b07f1dcad63f104248c5

**デフォルトの名無しさん** · 2018/01/16(火) 13:02:13.48

>>698
どや顔で貼ったんだろうけど
記事内でリンクあるランキングでのRustの位置wwwwwwwwwwww
Rustのゴミさの補強にしかなってないwwwwww

**デフォルトの名無しさん** · 2018/01/16(火) 13:03:09.51

>>698
そいつはTIOBE IndexでScalaの順位が低いから
参考にならないの事にしたいだけのScala大好きマンだから
話半分以下で聞いとけ

**デフォルトの名無しさん** · 2018/01/16(火) 13:18:52.31

そもそも、みんなが使ってる言語だから良い言語みたいな理論を持ち出せば、
PHPをとても良い言語だと認識しければならなくなるんだが。
その辺を>>697はどう考えてるんだ？たぶん何も考えてないんだろうけど。
それとも、もしかしてPHP最高！とか思ってる奴だったか。

**デフォルトの名無しさん** · 2018/01/16(火) 13:31:11.79

>>701
Rustは誰も見向きもしないクソ言語未満っていってるだけで
みんなが使ってる言語は良い言語とは一言もいってないけど？

**デフォルトの名無しさん** · 2018/01/16(火) 13:37:29.94

だれも見向きもしない言語ってのはつまり人気のない言語のことだろ。
人気のない言語はクソ言語ってことにすると、逆説的に、
人気のある言語は良い言語になっちゃうよね。

**デフォルトの名無しさん** · 2018/01/16(火) 13:39:54.74

論理学できない人？

見向きもされないのは悪い言語が真でも
見向きされる言語は良い言語は真じゃないよ？
論理学できないからRustなんてもてはやすんだろうけど

**デフォルトの名無しさん** · 2018/01/16(火) 13:50:01.38

その理屈は論理学として正しいがそれを認めると
順位表では何が良い言語か一生懸命みてもわからんから意味なさそう

**デフォルトの名無しさん** · 2018/01/16(火) 14:05:58.36

>>704
それは悪かった。
どうせ君は物事を1か0でしか考えられない人間だと思ってたから、
そういう思考回路の人間だと思って会話を進めようとしてしまった。

じゃあ、別の方向から突かせてもらうけど、
関数型言語って最近（最近というほどでもないか？）の流行りじゃん？
でも、関数型言語の祖先ってLispとか言われてたりするよね。
で、そのLispはかなり昔から存在したわけだよね。
何で昔は一部の物好きだけが使ってて他は見向きもしなかったのに、
今更になって認められていろんな言語にラムダ式とかが採用されたの？
見向きもされない言語はクソ言語のはずなのになんで？
（ちなみにこの理論は反論できる余地があります）

**デフォルトの名無しさん** · 2018/01/16(火) 14:40:03.83

Lispが関数型言語の祖先かと言われると副作用だらけだし違和感しかないな
別に最近の言語のラムダ式はラムダ計算を構文に持ち込んだだけで、LispのS式まわりの成果を持ち込んだわけでもなかろうに
どちらかというとHaskellとかML系列の成果の方が主だろう

RustがLisp的な立ち位置になると言いたいんだろうが、言語のお粗末な出来から言ってもそれはない

**デフォルトの名無しさん** · 2018/01/16(火) 14:45:36.44

別にLispに限定した話じゃないよ。
関数型言語って昔からあるよね。でも当時は誰も見向きもしなかったよね。
見向きもされない言語がクソ言語なら関数型言語が
今更になって認められるのはおかしいよね？ってだけ。

**デフォルトの名無しさん** · 2018/01/16(火) 16:31:38.96

言語が変わらなくても時間の経過によって環境の方が変化して評価が変わることは十分に有り得る
プロセッサ負荷やメモリ使用量などの足枷がユルユルになって来たことで評価が高くなったのではないか
従って当時とか現在とかの時世を無視しては語れないこともある

**デフォルトの名無しさん** · 2018/01/16(火) 16:51:39.64

それを認めると将来Rustがクソではなかったと証明される余地があるってことで、
それは事実ではないから違うな

今評価されてるのはあくまでラムダ計算であってLispではない、と言えば分かるか？

**デフォルトの名無しさん** · 2018/01/16(火) 16:54:05.43

>>709
Yes! That's correct!!
反論の余地とは時代等の外部環境の変化により評価も変化することだね。
なんか別のIDの人が答えちゃったけど。

**デフォルトの名無しさん** · 2018/01/16(火) 16:56:00.39

木構造もインデックス使って書かないといけないのか

**デフォルトの名無しさん** · 2018/01/16(火) 17:19:58.51

>>710
ワロタwww
お前は未来人か？
未来人を肯定するならrustがクソ言語であることも認めよう。

**デフォルトの名無しさん** · 2018/01/16(火) 17:41:30.80

ここまで言語に粘着する精神が理解出来ない

**デフォルトの名無しさん** · 2018/01/16(火) 18:24:58.75

>>694
子→親のリンク無し縛りでも動的な追加削除はできると思うけど。
子からのリンクが必要なのは、各ノードへの参照をそのままイテレータとして見せて前後移動したい場合のみじゃね
で、まあ、子からのリンクが絶対必要として、そのためにRc使って要らん参照カウンタと間接参照を各ノード毎に持たせるってすごい無駄に思える
諦めてraw pointerでいいんじゃないかなあ……

**デフォルトの名無しさん** · 2018/01/16(火) 21:10:33.64

>>696
センスの無さを自分に感じる…Rust難しいな
https://play.rust-lang.org/?gist=0d5f8e5d767ac5b2a0b32b272e8c3797&;version=stable

**デフォルトの名無しさん** · 2018/01/16(火) 23:04:02.65

案外、未来でRustで書かれたプログラムが暴走して人類の危機だから、
現代にタイムリープしてきてRustを普及させまいとする工作員の可能性が微粒子レベルで存在……しないか

**デフォルトの名無しさん** · 2018/01/16(火) 23:45:58.12

そうだったら5chみたいな辺境じゃなくてもっとちゃんとしたところで活動してるだろ

**デフォルトの名無しさん** · 2018/01/17(水) 00:18:50.74

>>716
木構造がどういう構造なのかを勉強したほうがいい

**デフォルトの名無しさん** · 2018/01/17(水) 01:17:11.33

>>717
これすき

**デフォルトの名無しさん** · 2018/01/17(水) 01:43:08.30

スカイネットはRustで書かれていたか…

**デフォルトの名無しさん** · 2018/01/17(水) 14:46:11.61

>>704からの>>710の流れで草生える
論理学できない人？
ブーメランかな? wwwwwww

**デフォルトの名無しさん** · 2018/01/17(水) 18:26:41.06

子供じみたレスばかり

**デフォルトの名無しさん** · 2018/01/17(水) 22:00:00.30

言語オタクが喜びそうな機能を盛り込んだら本当に飛びつきやがったw
みたいな言語だよな。

**デフォルトの名無しさん** · 2018/01/17(水) 22:09:59.44

飛び付いたオタクは無事モジラの養分となりましたとさ

**デフォルトの名無しさん** · 2018/01/18(木) 23:44:13.29

オッス！オラMozillaの養分！Rustいっちょやってみっか！

**デフォルトの名無しさん** · 2018/01/19(金) 10:54:19.44

またrustfmtごたついてる?

**デフォルトの名無しさん** · 2018/01/19(金) 12:31:26.28

あれがごたついてなかったことが過去にあったか？

**デフォルトの名無しさん** · 2018/01/19(金) 12:47:00.76

せやねw

昨日まではcomponentに残ってたんだけどなぁ
また "rustup run nightly cargo install rustfmt-nightly -f" でいれるかー

**デフォルトの名無しさん** · 2018/01/19(金) 17:48:34.83

stableのやつ使えば良いのでは

**デフォルトの名無しさん** · 2018/01/19(金) 20:17:30.04

>>730
deprecated言われるんだよー

**デフォルトの名無しさん** · 2018/01/19(金) 22:14:56.98

ビルド速度がgo並になったら起こして

**デフォルトの名無しさん** · 2018/01/20(土) 00:14:19.48

Rustのビルドそんなに遅いか？
Scalaと比べたら誤差だろ

**デフォルトの名無しさん** · 2018/01/20(土) 04:07:03.70

誤差が流行語か何かなの？

**デフォルトの名無しさん** · 2018/01/20(土) 11:11:11.19

>>731
rustup component add rustfmt-preview --toolchain stable
でインストールできるやつのつもりだった
なぜかcargo-fmtは入ってないけど

**デフォルトの名無しさん** · 2018/01/20(土) 11:44:54.08

代入の結果が () を返すのって一見不満なんだが…

#include <stdio.h>
int main() {
int a, b;
a = b = 10;
printf("%d, %d", a, b); // 10, 10
return 0;
}

a = b = 10
p [a, b] # [10, 10]

let b = ref 0 in
let a = b := 10 in
Printf.printf "%b, %d\n" (a = ()) !b (* true, 10 *)

fn main() {
let (a, b);
a = b = 10;
println!("{:?}, {:?}", a, b); // (), 10
}

上から c, ruby, ocaml, rust の結果
所有権のこと考えるとこうなるしかないのかな

**デフォルトの名無しさん** · 2018/01/20(土) 12:30:50.40

>>735
うん　そのcomponentが木曜日はあったのに　金曜日に無くなって　今見たら復活してた
このままだと「月曜日に市場へ出かけ　火曜日にお風呂に入り　水曜日に力士でデビュー」ですよ

そして確かにcargo fmt無くなってるね　まぁ当面rustfmtが呼べればいいんだけど

>>736
その辺りの差異は慣れるしかないかーとあんまり気にしてなかった
言われると確かにもやっとしますな

**デフォルトの名無しさん** · 2018/01/20(土) 18:49:44.85

>>736
VBAだと a = b = 10 は a = (b = 10) となり (b = 10)は比較演算になって aはBoolean型になるよ

**デフォルトの名無しさん** · 2018/01/21(日) 00:23:31.24

>>542
君のRustは20倍遅い - 簡潔なQ
http://qnighy.hatenablog.com/entry/2017/05/02/070000

**デフォルトの名無しさん** · 2018/01/23(火) 19:31:47.22

https://qiita.com/SatoshiTerasaki/items/5bd3ee78a60f9a02e0fc
juliaにすら速度で負ける自称低レベル言語があるらしい
別の意味で低レベルwwwwww

**デフォルトの名無しさん** · 2018/01/23(火) 20:25:24.96

数値計算ならjuliaは最速でいいだろ

**デフォルトの名無しさん** · 2018/01/23(火) 20:28:32.79

疑似乱数ライブラリの差ね

**デフォルトの名無しさん** · 2018/01/23(火) 20:37:51.11

最適化のかかるリリースビルドしてない可能性は？

**デフォルトの名無しさん** · 2018/01/23(火) 21:02:12.15

>>740
Rust凄い！Pythonの1.45倍も速い！

って書くと、逆に遅く感じる

**デフォルトの名無しさん** · 2018/01/23(火) 21:07:23.42

アンチスレのほうがアンチが話題ふってくれてRustに貢献してる感じする

**デフォルトの名無しさん** · 2018/01/23(火) 23:14:43.88

俺の環境でも
Julia: 8.58sec
Rust: 9.66sec
で1秒遅いな。でも特にチューニングしてないコードで Julia にここまで迫るなら十分だな。

**デフォルトの名無しさん** · 2018/01/24(水) 00:30:05.97

juliaってスクリプト言語なのに、
スクリプト言語に負けて十分な速度と言い張る低級言語wwwwww
いやー信者ってすげえわwwwwww

**デフォルトの名無しさん** · 2018/01/24(水) 02:48:41.80

いやでもJuliaに勝とうと思えばIntel Fortran持ち出してくるか
Cで環境固有のattribute使いまくるぐらいしか無いぞ割りとまじで
JuliaもバックエンドはLLVMではあるんだけどな

**デフォルトの名無しさん** · 2018/01/24(水) 05:34:41.30

速い乱数ライブラリつかえばいいだけでは

**デフォルトの名無しさん** · 2018/01/24(水) 05:48:01.55

乱数生成のアルゴリズムが一致してないものを比べても言語の速さは比べられんだろう
Juliaの乱数生成のアルゴリズムが速度面で優れてるってことが分かっただけだ
それでも動的言語でこの速度は確かにすごいと思うが
あとC言語のベンチの結果が載ってないのも痛いな
これじゃJuiliaが速いってことは分かってもRustが遅いかどうかは分からん
でもJuiliaって数値計算特化の言語なんだろ
だったら文字列処理とかは遅いんじゃないの？
もう少しいろんな方面からパフォーマンス測ってみないとなんとも言えんな

**デフォルトの名無しさん** · 2018/01/24(水) 06:38:42.48

ボトルネックの概念はどこいった

**デフォルトの名無しさん** · 2018/01/24(水) 07:51:23.43

＊＊＊が速いと言われているので使ってみて言うほど速くなった試しはないな
実際に使うときはIO性能も重要だしよく使う言語の方が最適化手法を知っているというのもありそう

**デフォルトの名無しさん** · 2018/01/24(水) 09:29:26.67

Rustが将来どの分野で使われるようになるか分からないけど、
少なくとも科学技術計算の分野に食い込むのは無さそうね
過去の資産もない上に速度的な優位も無いんじゃねぇ

**デフォルトの名無しさん** · 2018/01/24(水) 10:25:57.27

そもそも既存の資産を置き換えるほどの魅力がない
学習コストもばかにならない

**デフォルトの名無しさん** · 2018/01/24(水) 10:29:05.95

そもそもrustの魅力って何？
コンパイル通させてくれない言語って印象しかない

**デフォルトの名無しさん** · 2018/01/24(水) 12:02:46.02

コンパイル通させてくれないのが魅力

**デフォルトの名無しさん** · 2018/01/24(水) 12:12:31.05

スレッドプログラムが書きにくいのがうり

**デフォルトの名無しさん** · 2018/01/24(水) 12:43:30.69

コンパイラが手取り足取り教えてくれるから誰でも簡単に安全なコードが書けるよ

**デフォルトの名無しさん** · 2018/01/24(水) 13:08:56.48

>>757
rustはスレッド書きやすいと思うんだけど
書きにくいって思う人が書きやすいと思うのはどんな言語？goみたいな？
ネイティブと軽量スレッドの違いあるけど記述自体は殆ど変わらんと思うけど
軽量スレッドが言語に組込まれてないから？

**デフォルトの名無しさん** · 2018/01/24(水) 13:33:02.69

コンパイル通せないのが魅力って、つまり
malbolgeみたいな実用じゃなくて難解言語ネタの一種ってこと？

**デフォルトの名無しさん** · 2018/01/24(水) 14:10:35.06

アンチスレでマジになるなって

**デフォルトの名無しさん** · 2018/01/24(水) 17:06:47.36

>>750
NimのベンチはCと変わんねーよ

**デフォルトの名無しさん** · 2018/01/24(水) 18:33:54.36

競プロだとRustが実行時間最速なケース結構あるから！

https://yukicoder.me/ranking/speeder

**デフォルトの名無しさん** · 2018/01/24(水) 18:55:55.94

そもそも科学数値計算はマルチコア・マルチノードで並列で処理するような

**デフォルトの名無しさん** · 2018/01/24(水) 20:32:13.14

>>763
競プロこそ全員違うアルゴリズムなんだから速度比べても当てにならん例じゃね

**デフォルトの名無しさん** · 2018/01/24(水) 20:44:20.26

数日前　Twitterに落ちてたWebFrameWorkの比較
https://github.com/tbrand/which_is_the_fastest

**デフォルトの名無しさん** · 2018/01/24(水) 22:10:38.68

まともに話題提供する人は本スレに書き込んでね。
ここは荒らしたい人専用です。

**デフォルトの名無しさん** · 2018/01/24(水) 22:32:48.54

>>767
本スレってどこ

**デフォルトの名無しさん** · 2018/01/24(水) 22:38:34.80

アンチは話題を提供してくれるという意味ではありがたいが
速度や人気度の話ばっかりで構文系の話が出てこないんだよなぁ。
ライフタイムがジェネリックとごっちゃになって書きづらくね？とか、
box構文いい加減にstableにしろよいつまでnightlyのままなんだよ？とか
swiftみたいにOption型をOption<T>じゃなくてT?って書けるようにしろよとか
標準ライブラリ薄すぎだろ？もう少し分厚いの用意しろよとか
そういう類の文句はなんで出てこないんだ？

**デフォルトの名無しさん** · 2018/01/24(水) 22:44:43.09

ライブラリ薄いってどういう意味？

**デフォルトの名無しさん** · 2018/01/24(水) 22:46:12.69

最近のKaggleのコンテストでRust使ってる人が上位にいたという話を聞いた

**デフォルトの名無しさん** · 2018/01/24(水) 23:45:26.58

標準ライブラリが少なくて外部crateに頼る方針のことでしょ
node.jsに近くてGoの正反対

**デフォルトの名無しさん** · 2018/01/25(木) 00:39:04.73

ライブラリ戦略についてはもうとっくにRustチームの方針は出てるから
一読することをおすすめする

https://blog.rust-lang.org/2017/05/05/libz-blitz.html

**デフォルトの名無しさん** · 2018/01/25(木) 00:42:15.89

Option<T>に関してはSwift使ったことないから全く気にしたことなかったな
OCamlとかScalaとかフツーにOptionって書くし

box構文についてはなくても困らないとかそういう理由だろう
それよりimpl Traitとかdynキーワードとかトレイト境界の特殊化とか
もっと大事なのあると個人的には思うが

**デフォルトの名無しさん** · 2018/01/25(木) 01:55:14.44

>>773
それについてはもう知ってる
個人的にもう少し公式が積極的に用意してほしいなという願望を書いてみただけ
ライブラリ探すの面倒なんだよな

ただでさえ学習コスト高いんだから出来るだけ気軽に試せるようにとか
それ以外のところで努力しないと普及しないんじゃって不安になる

アンチ側からもこういった意見が出てもいいと思うんだけど出ないんだよな
速度云々とかStackOverFlowとか質問系サイトでの質問数云々とかばっかりでさ
構文だったり公式の方針とかには不満はないの？「こんな構文はダサすぎる」とかさ

**デフォルトの名無しさん** · 2018/01/25(木) 02:11:58.34

rustcでwindows gui用exeをコンパイルするためにコンパイラに指定するフラグって何ですか？

**デフォルトの名無しさん** · 2018/01/25(木) 02:12:53.18

>>774
impl Traitって戻り値の型にTraitを指定して限定的に型推論を効かせようとしてるやつのこと？
あれって引数の型も型推論できるんだっけ？
確かnightlyでは動くんだよね？まだstableには出来ないのかな？

トレイト境界の特殊化って何だ？今調べてみたけどこれのことか？
https://qiita.com/sinkuu/items/450ee1219b10072f09e8
へぇこんなのあるのか知らんかった

こういう話題が欲しかったんだありがとう

**デフォルトの名無しさん** · 2018/01/25(木) 03:06:48.02

>>765
最速を目指すような解法ならどれも大体同じでしょ

**デフォルトの名無しさん** · 2018/01/25(木) 07:25:36.79

>>768
ここ
http://mevius.5ch.net/test/read.cgi/tech/1514107621/

ここはキチガイとの戯れを楽しむスレになった。ここはここで楽しいが。

**デフォルトの名無しさん** · 2018/01/25(木) 09:55:44.06

>>776
コマンドプロンプト表示させないということならcrateのトップレベルに
#![windows_subsystem = "windows"]
と書けばよい

**デフォルトの名無しさん** · 2018/01/25(木) 11:40:56.27

本スレとやらが過疎ってレベルじゃなく、アンチスレが大盛況なモダン言語（）があるらしいwwwwwwwww

**デフォルトの名無しさん** · 2018/01/25(木) 11:44:16.98

Rustの構文とかバージョン1.0越えてるのにどんどん新しいRFC承認してばかすか変更加えてる未完成品じゃん
そんな状態でバージョン1系名乗るとかモジラの頭の悪さがよく出てる

そもそもnightlyの機能がないとクロージャー返す関数すらかけないってなんのネタ言語？
トレイト周りも、実装記述できないパターンいくつもあって草しか生えない

**デフォルトの名無しさん** · 2018/01/25(木) 11:50:20.45

トレイトとか変な言語機能をオレカッケーで採用なんてするからこうなる
枯れたオブジェクト指向で堅実に設計しとけばこうはならなかったはず
借用とかライフタイムとかはまともにコード書けなくなるくらいガチガチに固めておいてこういうところ雑に採用した結果の産廃言語

**デフォルトの名無しさん** · 2018/01/25(木) 15:02:08.44

キチガイ怒りの3連投

**デフォルトの名無しさん** · 2018/01/25(木) 15:09:07.07

まあトレイトについてはHaskellを真似してみたかっただけ感あるし
Haskellで過去に起こった問題を丁寧に繰り返してる感も確かにある

**デフォルトの名無しさん** · 2018/01/25(木) 16:29:05.71

>>784
なお一投目は大方は自身の功績の模様

**デフォルトの名無しさん** · 2018/01/25(木) 17:51:49.66

stableにするにはまだ早かったという意見には同意する

**デフォルトの名無しさん** · 2018/01/25(木) 18:29:51.71

過疎スレよりキチガイと遊ぶほうが楽しいのは確かだからいいけどね

まともに議論したいのにこっちに書くのはキチガイなだけで