プログラミング言語 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/

**デフォルトの名無しさん** · 2017/12/25(月) 01:15:11.44

>>535
嫌いじゃない

**デフォルトの名無しさん** · 2017/12/25(月) 21:17:01.81

結局RustはKotlinとかSwiftと比べて何が良いのか
純粋に言語として
ライフタイムとかはコストに見合ってるのか

**デフォルトの名無しさん** · 2017/12/25(月) 21:18:48.87

>>539
汎用性ならKotlin
Rustは特化型

**デフォルトの名無しさん** · 2017/12/25(月) 21:19:18.87

そもそも「安全で高速に低レベルな事をする言語」だからね

**デフォルトの名無しさん** · 2017/12/25(月) 22:58:45.45

enumがtagged unionだから分岐と構造化束縛時の
スタック操作ばっかになって素直に書くと遅い。
cursesで描画してもそこそこ遅い。
cならuntagged unionだから想定してないメンバに
アクセスしたら落とせばいいからここまで遅くならないよ。
安全な抽象化にそれなりのコストかかってる。

**デフォルトの名無しさん** · 2017/12/25(月) 23:19:26.65

その速度比較に使ったＲｕｓｔとＣ＋＋のそれぞれのソースコードｐｌｚ

**デフォルトの名無しさん** · 2017/12/25(月) 23:31:01.92

untagged unionで想定してないメンバにアクセスしたときに落とすためにはtag必要では

**デフォルトの名無しさん** · 2017/12/25(月) 23:34:48.96

Cのenumを使いたいならbitflagsでやる方が良いかなと今のところ思ってる

**デフォルトの名無しさん** · 2017/12/26(火) 00:30:52.01

今日日パソコンはとても高速なわけだが
Rustでcurses使うと気になるほど遅くなるのか？

**デフォルトの名無しさん** · 2017/12/26(火) 02:21:08.27

>>542
>cならuntagged unionだから想定してないメンバに
>アクセスしたら落とせばいいからここまで遅くならないよ。

きちんと落ちるのなら苦労はしてない。
落ちないでスタックぶっ壊しながら突き進むから苦労してるんだろ。
スタック壊されるデメリットに比べればtagged unionのコストなんて安いもの。

**デフォルトの名無しさん** · 2017/12/26(火) 02:29:45.01

そもそもrust stableにもunionは入ってるんでお好きに使うがいいやってのと、
「想定してないメンバにアクセスしたら」ってどう判断すんのって疑問が残る

タグに相当するものを自作してもいいけど、そこまで気にする程のオーバーヘッドを感じたことが無い

**デフォルトの名無しさん** · 2017/12/26(火) 03:05:26.84

数百万回まわしてナノ秒単位で測るマイクロベンチマークならともかく、cursesで違いが分かるとか、ありえんわ

**デフォルトの名無しさん** · 2017/12/26(火) 12:24:50.36

今時のマシンでcurses使うと遅いっていう人間、明らかにニュータイプでは？

もしRustで標準入出力が目に見えて遅いって話なら、
単純に標準入出力のロックに無頓着ってだけのオチだと思う

**デフォルトの名無しさん** · 2017/12/26(火) 15:07:09.73

>>541
夢みたいじゃないか！

**デフォルトの名無しさん** · 2017/12/31(日) 20:32:09.45

@HiraokaTakuya
Rust で C++ の non type template arguments使いたい時は、適当に中身無しの struct 作るしかないんかな～(´･_･`)
午後1:18 · 2017年12月29日

他人のツイートなんだけど僕も気になるから教えて(´･_･`)

**デフォルトの名無しさん** · 2018/01/01(月) 03:23:35.09

これ？

Pre-RFC: Integer Templating - internals - Rust Internals
https://internals.rust-lang.org/t/pre-rfc-integer-templating/2974

**デフォルトの名無しさん** · 2018/01/01(月) 06:07:12.08

C++ の template<int N> か。
これが使えれば、
impl<T> Hoge for [T; 0]
impl<T> Hoge for [T; 1]
impl<T> Hoge for [T; 2]
...

みたいなのを
impl<T, N: usize> Hoge for [T; N] でまとめられるよね（と良いな）

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

rustのジェネレータってasync function用のコンテキストスイッチしないまがい物か。
ジェネレータだけだと所有権奪ってキャプチャした値返すしか出来ないから
Cloneしないstd::iter::repeatくらいにしか使い道ないな。
ウォームアップしてないjsの倍程度の速度しか出ないけど
resume関数は最適化で綺麗になくなるみたい。

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

ほぼtraitしか無い状態なのにそんな評価できるの？

**デフォルトの名無しさん** · 2018/01/02(火) 20:34:21.94

型間のキャスト
https://rust-lang-ja.github.io/the-rust-programming-language-ja/1.6/book/casting-between-types.html

これの数値キャストのとこにリンクされてるissueまだOpenのままだけど大丈夫なんですか？

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

ターゲットごとに調整が必要だから後回しにされてんのか？

**デフォルトの名無しさん** · 2018/01/06(土) 15:03:12.41

Announcing Rust 1.23
https://blog.rust-lang.org/2018/01/04/Rust-1.23.html

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

今回の目玉は何？

**デフォルトの名無しさん** · 2018/01/06(土) 23:26:46.03

目玉無し

**デフォルトの名無しさん** · 2018/01/06(土) 23:35:55.23

コンパイラの最適化の改善くらいかな。
「メモリ使用量を平均で5～10%くらい削減することに成功した」だそうだ。

**デフォルトの名無しさん** · 2018/01/07(日) 00:56:06.77

この言語ってC++より遅くてJavaより速い感じ？

**デフォルトの名無しさん** · 2018/01/07(日) 07:28:23.02

間違ってはいない。
けどc++とは僅差なのでこんな感じかな。
C++ < Rust <<< Java
テキトーに書いたので異論は認める。

**デフォルトの名無しさん** · 2018/01/07(日) 08:28:15.81

下手すりゃc++より速いんちゃう

**デフォルトの名無しさん** · 2018/01/07(日) 09:11:44.01

全く同じアルゴリズムならC++のほうが速いはず。
C++のコンパイラはもう成熟してるけど、Rustのコンパイラはまだまだ改善中だから
将来的にはほとんど同じくらいになるんじゃない？
まぁなんにせよ、結局はアルゴリズム次第。

**デフォルトの名無しさん** · 2018/01/07(日) 10:36:20.02

Rustに限った話ではないが世の中のアルゴリズムの大半はC/C++前提に作られているのだから
C/C++の方が速いのは当たり前。新世代で速くしたければそれにあったアルゴリズムが必要

**デフォルトの名無しさん** · 2018/01/07(日) 11:03:31.13

>>567
トンデモだと思う

**デフォルトの名無しさん** · 2018/01/07(日) 11:59:29.53

「C++がJavaより早い」というのは「大抵は」が抜けているか、「原理的には」が抜けている
C++でVMとJITは作成しないなど、
いくつかの条件が整うと C++ より Java が早いというケースも存在する

無制限にコストをかけれるという前提なら Java より C++ のほうが早い

https://softwareengineering.stackexchange.com/questions/110634/why-would-it-ever-be-possible-for-java-to-be-faster-than-c

**デフォルトの名無しさん** · 2018/01/07(日) 12:31:49.44

Cは速いけどC++が速いってのは思い込みだな

**デフォルトの名無しさん** · 2018/01/07(日) 13:40:28.36

c++は実装依存激しいだろ。

**デフォルトの名無しさん** · 2018/01/07(日) 14:52:58.05

>>567
なんだそりゃ…

**デフォルトの名無しさん** · 2018/01/07(日) 14:53:20.71

>>570
なんだそりゃ…

**デフォルトの名無しさん** · 2018/01/07(日) 15:50:38.75

CとC++の速度比 ≒ C++とRustの速度比

みたいな感じ？

**デフォルトの名無しさん** · 2018/01/07(日) 16:38:03.27

>>574
単純なCだけ頭一つ抜けてて、C++とRustはvtableやsmart pointer由来の遅さを抱えた同じグループ

**デフォルトの名無しさん** · 2018/01/07(日) 16:57:20.32

ありがとうございました

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

腕振り回すのが早いからって、仕事も早いと思い込んでるのが未だに居るな。

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

>>575
検証結果plz
最適化コンパイラがない時代ならともかく今時のコンパイラで有意な差が出るとは思えない

**デフォルトの名無しさん** · 2018/01/07(日) 20:12:31.97

>>578
pc初心者？

**デフォルトの名無しさん** · 2018/01/07(日) 21:31:27.55

vtblと比較するならCの関数テーブルだろう
C++のスマポも必要なとこしか使わないし、使ったらその分だけ遅くなるのは当然

**デフォルトの名無しさん** · 2018/01/07(日) 23:35:47.39

https://benchmarksgame.alioth.debian.org/u64q/rust.html
https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&;lang2=gpp
これでいいか？

**デフォルトの名無しさん** · 2018/01/08(月) 00:09:18.31

c++もrustもアセンブルコード埋め込めるのだから速度を出そうと思えば出せるのでは

**デフォルトの名無しさん** · 2018/01/08(月) 00:56:10.81

今時、C#みたいなGC付きの言語で3Dゲームが開発できちゃう時代なんだ。
今のPCの性能を鑑みたら、C, C++, Rust の速度差なんてほとんど誤差みたいなもんだろ。
普通は気にするようなもんじゃない。
そんなわずかな差が気になるって言うのなら直にアセンブリでも書いてろよ。
ぶっちぎりで速いぞ。

**デフォルトの名無しさん** · 2018/01/08(月) 01:09:23.55

3DゲームってUnityのことか？Unityの内部はC#じゃなくC/C++では

**デフォルトの名無しさん** · 2018/01/08(月) 02:09:23.80

有能はコンパイラが上手く最適化できるコードを書く
無能はコンパイラが混乱するコードを書く

Cの方が速いとか言う奴は大抵無能

**デフォルトの名無しさん** · 2018/01/08(月) 02:29:49.41

まあそれ言い出したらそもそもそこまでcpu速度に影響ある部分なんて
少ないけどな。
ガベコレねーからrust速いってやつも
スマポないからc速いってやつも
大して変わらん。

**デフォルトの名無しさん** · 2018/01/08(月) 02:49:24.32

将棋ソフトとかチェスソフトは1%でも速くしたいという需要あるんちゃう
実際stockfishをRustで書き直したら速くなったりするのかね

**デフォルトの名無しさん** · 2018/01/08(月) 03:01:21.87

>>587
あんまり大きいプログラムじゃないみたいだけど、内部は木構造か
うーん

**デフォルトの名無しさん** · 2018/01/08(月) 05:39:51.66

>>585
それも突き詰めると絶対普段はこんなの書かねーっていうベンチマークのためだけのコードになったりするからなあ
>>581は有名な話だけどソース見ると言語によっては酷いもんだぞ

**デフォルトの名無しさん** · 2018/01/08(月) 16:00:03.99

rustで書き直すぐらいならC/C++のままでいい

**デフォルトの名無しさん** · 2018/01/08(月) 16:42:57.60

既存のC/C++コードを捨ててまで移行する価値のある言語ではないのはたしかだな

**デフォルトの名無しさん** · 2018/01/08(月) 16:49:10.90

そもそもRustが便利だと思ってるやついないだろ
C++書いたことない奴がC++より安全だの同速だの言ってヨイショする
本当にCやC++書いたことあるならただの制限厳しいだけのゴミだと分かる

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

そう思いたいのですね

**デフォルトの名無しさん** · 2018/01/08(月) 17:52:58.17

ここはアンチスレだからね。
わざわざまともな話題をここでやることはない。

本スレは過疎

**デフォルトの名無しさん** · 2018/01/08(月) 18:53:52.23

c++ゴミ老害をマウントするために新言語が必要なんだろ。

**デフォルトの名無しさん** · 2018/01/08(月) 21:23:29.25

>>575
速度優先なら
vtable作らない
smartpointer使わない

**デフォルトの名無しさん** · 2018/01/08(月) 21:24:35.96

>>583
ゲーム開発はできてもゲームエンジン開発はどうなの

**デフォルトの名無しさん** · 2018/01/08(月) 22:12:41.54

無能が生ポインタを使うとコンパイラの最適化を阻害して遅くなる

**デフォルトの名無しさん** · 2018/01/08(月) 22:47:28.33

>>597
横レスだけどCAPCOMのC#自社エンジンはC++でモリモリ書いてあるしC#用VMもC++で独自実装(SlideShareに確か資料があったはず)
Unityだって結局ライブラリも開発環境もC++が大部分よね

**デフォルトの名無しさん** · 2018/01/08(月) 22:52:48.05

カプコンのあれはゲーム用に超最適化されたGC詰んでるから…

**デフォルトの名無しさん** · 2018/01/08(月) 23:20:56.60

>>584, >>597, >>599
そりゃぁ、ゲームエンジンは速度が求められるからC#じゃ力不足だろうな。
そこまで持ち出されるとグーの音も出ない。
だから「『普通は』気にするようなものじゃない」って書いた。
ゲーム作ろうとするのにゲームエンジンから自作しようとする奴なんて『普通は』いないだろ？
そして、仮にゲームエンジンの開発に使うんだったとしても、
C#みたいなGC付きの言語ならともかく、C, C++, Rustの差は誤差みたいなものでしょ。
なぜなら、C++とRustの差が気になるっていうのなら、当然、C++とCとの差だって気になるはずだよな？
だったらゲームエンジンの開発にC++じゃなくてCを使ってるはずだろ？
でも実際にはCじゃなくてC++が使われている。
ということはゲームエンジンみたいにシビアな領域でもCとC++の差はさほど気にされていないってことになる。
ならやっぱり、C, C++, Rustの差なんて気にするようなものじゃないと言いたかった。

**デフォルトの名無しさん** · 2018/01/08(月) 23:59:18.26

>>575, >>596
Rustは実装にもよるけど vtable はほとんど使わないはずだよ。
「ジェネリックとトレイト境界」を使えば引数に関しては静的ディスパッチが可能。
戻り値のほうは「ジェネリックとトレイト境界」じゃどうにもできないけど、
こっちはTagged Union 使えば大体は何とかなる。
現状、クロージャを返す場合はトレイトオブジェクトを使わざるを得ないけど、
クロージャを返すことって稀だし、そこまで気にするようなことじゃないと思ってる。
Cにはそもそもクロージャ自体が存在しないわけだし。C++でもクロージャは一般的じゃない。

smart pointer に関しても unique_ptr なら遅くはならない。(ほとんど誤差みたいなもの)
だって unique_ptr は参照カウンタ使ってないし、Rallの仕組みを使って構造体(スタック)に
ポインタを持ってデストラクタで解放を行ってるだけだから、その程度で遅くなるわけがない。
そして、Rustはデフォルトが C++の unique_ptr と同じだからやはり遅くはならないはず。
遅くなるのは内部で参照カウンタを使ってるshared_ptrとweek_ptrの2つ。
Rustの場合は参照カウンタは Rc or Arc として標準ライブラリに用意されてる。
まあ、Rustで Rc or Arc を全く使わずに作るってのはちょっと現実的じゃないけど。

まぁ、自分もそれほど詳しいわけじゃないけど、
vtableとsmart pointer はRustが遅い理由にはならないんじゃないかな。
RustがC, C++ と比べて少し遅い理由は他にあると思うよ。
個人的にはまだコンパイラが成熟してないってのが主な理由だと思ってるけど。

結構いっぱい書いたけど、やっぱり結論としてはC, C++, Rust の速度差は普通に使う分には気にすようなものじゃないと思う。

**デフォルトの名無しさん** · 2018/01/09(火) 00:07:21.22

>>602
訂正
week_ptr ×
weak_ptr ○

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

確かに

**デフォルトの名無しさん** · 2018/01/09(火) 08:02:08.21

HashTableがデフォルトで安全側に倒してSipHash使ってるのも大きい気はする
ripgrepやfont-rsなど既存の実装よりも圧倒的に高速なrust実装もあるし、言語自体の差と言うよりも、書き方の差だと思う
constexpr周りはDやC++の方が充実しているけど、build.rsなどで代替できなくもないと思う

**デフォルトの名無しさん** · 2018/01/09(火) 09:33:53.22

Unityが出てからC#でゲーム書く人が増えたわけだし、どこかの企業が気合い入れてRustサポートしたエンジン作れば使ってみる人も増えるやろ

**デフォルトの名無しさん** · 2018/01/09(火) 10:25:16.50

速さの差を気にする必要はないとかいう奴って
普段どんなところでコード書いてるプログラマなんだ？
プログラマなら一番速い選択するべきだろ

**デフォルトの名無しさん** · 2018/01/09(火) 10:36:54.87

かけれるコストが一定という制約で一番速くなる言語を選ぶと結果は変わるんだよ

**デフォルトの名無しさん** · 2018/01/09(火) 10:59:57.42

>>607
「速さ」にも何種類かあるのは理解してる？
最近は開発スピード優先だろ。

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

開発スピード優先とは言っても
アルゴリズムや計算量知らないで
とんでもない糞コード書く香具師はいる

**デフォルトの名無しさん** · 2018/01/09(火) 13:00:20.99

そりゃ論外だ。
開発言語の問題じゃない。開発手法は少しは関係あるか。

**デフォルトの名無しさん** · 2018/01/09(火) 13:08:01.94

Rustでプログラマが意識してないのに走るランタイム処理って何かあるかな？
起動時になんか処理してる？
あとは、メモリ解放時に意外とjemallocが重いとか？

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

かけれるコストを減らすのがプログラマの仕事だろうに……
処理の肝の関数をアセンブリで書くのに一週間かけるのか？

**デフォルトの名無しさん** · 2018/01/09(火) 15:06:26.69

> プログラマなら一番速い選択するべきだろ
> かけれるコストを減らすのがプログラマの仕事だろうに……

一番速い言語を選択した上でかけれるコストを減らすという主張のようだが、
コストの上限って大抵あるのよ？
上限ないならプログラム全部アセンブリで書いた上で
お好きなようにかけれるコストを減らしてください

> 処理の肝の関数をアセンブリで書くのに一週間かけるのか？

元になる関数の有無、関数の規模、ボトルネックとしての割合、
複雑さ、アーキテクチャ、既存のテストコードの有無、
作業する人数、スキルと単価の前提すらなく作業時間だけ提示されても
必要なら一週間かけますとしか言えないよね？

**デフォルトの名無しさん** · 2018/01/09(火) 15:08:41.92

>>613
> 処理の肝の関数をアセンブリで書くのに一週間かけるのか？
必要ならやるけど
ふつうは、アセンブリで書くというという結論に至る前に
処理の見直しで数ヶ月試行錯誤するかな

**デフォルトの名無しさん** · 2018/01/09(火) 15:46:18.74

本当に必要なら
関数のアセンブリ化くらい一日でやるのがプログラマだろって話な？

**デフォルトの名無しさん** · 2018/01/09(火) 18:36:32.15

処理の肝の関数が一日程度のアセンブリの最適化ですむ程度なら、
絶対に手を付けないな
コードの保守性を考えるとむしろ害悪

ドライバのコードを一週間かけて最適化して劇的に早くしたことがあるが、
関数に対する暗黙の前提とかを見つけて、
ひらめきでニーモニックを最適化していく作業
一日程度でやることじゃない

**デフォルトの名無しさん** · 2018/01/09(火) 20:29:59.87

今時の高性能(で複雑な)なプロセッサの最適化はコンパイラ＞人間

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

C++からRust移植で高速化！？

https://twitter.com/tanakh/status/950659594379968513

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

例の会社の方ですね

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

stockfishもrustで書き直しましょう！

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

移植で高速化する案件ってのは、大概同じ言語で書き直しても高速化するからなあ
要するに作り直しに際して全体を見直すという行為が一番効く

**デフォルトの名無しさん** · 2018/01/10(水) 11:54:40.05

詐欺会社の社員の言うことなんて信じるからRustなんかに飛び付くんやろなあ

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

気が狂ったようなレスだな

**デフォルトの名無しさん** · 2018/01/10(水) 15:45:01.02

>>622
お前それインタプリタ言語からコンパイル言語への移植でも同じこと言えんの？

**デフォルトの名無しさん** · 2018/01/10(水) 15:47:29.13

GoogleのAIエンジン、別にRustで書けとは言わんがせめてGoにしろやと常々思う
演算量多いんだよバーロー

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

GoogleのサーバサイドではPythonからGoへ置き換わりつつあるみたいだけど、そっちも置き換わるのか

**デフォルトの名無しさん** · 2018/01/10(水) 18:47:50.56

スレチだけど、Goはマルチコアでの並列処理に適した言語だからAIエンジンをサーバで動かすなら置き換えて欲しいよね

しかしまぁ、C/C++からRustの移植で早くなるのは、オブジェクトの取り回しが無理やり矯正されることによる恩恵かねぇ
mutexのlock/unlockによるブロッキングが早々起きないから待ち合わせしなくていい所の待ち合わせは矯正されてそう
プログラマが意識して作るならC/C++のままで良いけど、人がやるより機械がやってくれるならそれに越したことない

**デフォルトの名無しさん** · 2018/01/10(水) 20:16:34.04

tensorflowの事言ってるなら、pythonで書かれてなかったら誰も使わないよ

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

pythonは利用者==開発者での試験開発には非常に好ましい言語だけど、利用者!=開発者では性能悪くてver.2,3で言語仕様互換性のないRust未満のクソ言語だよ？
AIエンジンを実用ツールとして見ない日曜プログラマはtensorflow(python2 lib)をホクホクと使うけど、実用ツールとして見たらtensorflowは誰も望んでは使わないよ

同じように言語の適材適所を考えないプログラマはRustの適所を考えることもせず、アンチ活動に走るよね
コンパイル通るコード書くの大変だし、ローポインタ操作は好まれないし、日本語書籍少ないしで決して便利な言語じゃないけどRustもハマれば良い言語よな

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

アンチの存在はともかく
アンチと戦うのが好きな人が多いのが難点ですね

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

たなこふアンチはどっか逝って

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

演算グラフを構築してGPUに投げる処理をrustで書けば速くなると思ってる低脳っぷりヤバイわ
GPUの100倍も遅いCPUでループ回るのが速いとかマジでどうでも良いからw

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

今rustで業務アプリ開発してるけど、マルチスレッドでのデータ競合をコンパイル時にチェックしてくれるのが特にいい感じだわ
ただ、今まで気楽に相互参照使ってた所とかrust流の書き方しないとキツイのが結構あるな

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

まあ行列演算のコアなところは今でもアセンブラだったりするわな。
一つの言語で全てのレイヤーを賄おうとするのがそもそも馬鹿すぎる発想。

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

>>630
挙げてるデメリット全部致命的で、
全く嵌まれば強いように見えないな

**デフォルトの名無しさん** · 2018/01/11(木) 13:36:38.57

>>636
それってpythonについて文句言ってんの？それともRust？
それとも両方？

**デフォルトの名無しさん** · 2018/01/11(木) 19:09:36.95

>>630
日曜プログラマとかレッテル貼ってdisってみたけど、
実は自分の方がクソど素人だと>>633>>635にバラされた気分はどう？

流行りだからってドカタが無理してAIとか口出さない方が良かったね