- 1 名前：デフォルトの名無しさん [2017/10/14(土) 17:38:14.04 ID:uWD69LeP.net]
- 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/
- 577 名前：デフォルトの名無しさん mailto:sage [2018/01/06(土) 23:26:46.03 ID:+G0EWjNB.net]
- 目玉無し
- 578 名前：デフォルトの名無しさん [2018/01/06(土) 23:35:55.23 ID:iXDfk3dJ.net]
- コンパイラの最適化の改善くらいかな。
「メモリ使用量を平均で5～10%くらい削減することに成功した」だそうだ。
- 579 名前：デフォルトの名無しさん mailto:sage [2018/01/07(日) 00:56:06.77 .net]
- この言語ってC++より遅くてJavaより速い感じ？
- 580 名前：デフォルトの名無しさん mailto:sage [2018/01/07(日) 07:28:23.02 ID:uw/m3vxc.net]
- 間違ってはいない。
けどc++とは僅差なのでこんな感じかな。
C++ < Rust <<< Java
テキトーに書いたので異論は認める。
- 581 名前：デフォルトの名無しさん mailto:sage [2018/01/07(日) 08:28:15.81 ID:N4ZmoDnH.net]
- 下手すりゃc++より速いんちゃう
- 582 名前：デフォルトの名無しさん [2018/01/07(日) 09:11:44.01 ID:uw/m3vxc.net]
- 全く同じアルゴリズムならC++のほうが速いはず。
C++のコンパイラはもう成熟してるけど、Rustのコンパイラはまだまだ改善中だから
将来的にはほとんど同じくらいになるんじゃない？
まぁなんにせよ、結局はアルゴリズム次第。
- 583 名前：デフォルトの名無しさん mailto:sage [2018/01/07(日) 10:36:20.02 ID:VPcvS++b.net]
- Rustに限った話ではないが世の中のアルゴリズムの大半はC/C++前提に作られているのだから
C/C++の方が速いのは当たり前。新世代で速くしたければそれにあったアルゴリズムが必要
- 584 名前：デフォルトの名無しさん mailto:sage [2018/01/07(日) 11:03:31.13 ID:YhE3wbKh.net]
- >>571
トンデモだと思う
- 585 名前：デフォルトの名無しさん mailto:sage [2018/01/07(日) 11:59:29.53 ID:zsxI9Sw+.net]
- 「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
- 586 名前：デフォルトの名無しさん mailto:sage [2018/01/07(日) 12:31:49.44 ID:S38kpWyE.net]
- Cは速いけどC++が速いってのは思い込みだな
- 587 名前：デフォルトの名無しさん mailto:sage [2018/01/07(日) 13:40:28.36 ID:vkdahwds.net]
- c++は実装依存激しいだろ。
- 588 名前：デフォルトの名無しさん [2018/01/07(日) 14:52:58.05 ID:ztEE4sQM.net]
- >>571
なんだそりゃ…
- 589 名前：デフォルトの名無しさん [2018/01/07(日) 14:53:20.71 ID:ztEE4sQM.net]
- >>574
なんだそりゃ…
- 590 名前：デフォルトの名無しさん mailto:sage [2018/01/07(日) 15:50:38.75 .net]
- CとC++の速度比 ≒ C++とRustの速度比
みたいな感じ？
- 591 名前：デフォルトの名無しさん mailto:sage [2018/01/07(日) 16:38:03.27 ID:lYFenZIw.net]
- >>578
単純なCだけ頭一つ抜けてて、C++とRustはvtableやsmart pointer由来の遅さを抱えた同じグループ
- 592 名前：デフォルトの名無しさん mailto:sage [2018/01/07(日) 16:57:20.32 .net]
- ありがとうございました
- 593 名前：デフォルトの名無しさん [2018/01/07(日) 18:25:18.16 ID:oRH7Tob1.net]
- 腕振り回すのが早いからって、仕事も早いと思い込んでるのが未だに居るな。
- 594 名前：デフォルトの名無しさん mailto:sage [2018/01/07(日) 20:07:26.07 ID:QaVgU45N.net]
- >>579
検証結果plz
最適化コンパイラがない時代ならともかく今時のコンパイラで有意な差が出るとは思えない
- 595 名前：デフォルトの名無しさん mailto:sage [2018/01/07(日) 20:12:31.97 ID:GuZkQfSu.net]
-
- 596 名前：et="_blank">>>582
pc初心者？ []- [ここ壊れてます]
- 597 名前：デフォルトの名無しさん mailto:sage [2018/01/07(日) 21:31:27.55 ID:sQmpVu5G.net]
- vtblと比較するならCの関数テーブルだろう
C++のスマポも必要なとこしか使わないし、使ったらその分だけ遅くなるのは当然
- 598 名前：デフォルトの名無しさん mailto:sage [2018/01/07(日) 23:35:47.39 ID:rkol6e+G.net]
- https://benchmarksgame.alioth.debian.org/u64q/rust.html
https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=gpp
これでいいか？
- 599 名前：デフォルトの名無しさん mailto:sage [2018/01/08(月) 00:09:18.31 ID:fNfSzvO3.net]
- c++�
- 600 名前：灑ustもアセンブルコード埋め込めるのだから速度を出そうと思えば出せるのでは []
- [ここ壊れてます]
- 601 名前：デフォルトの名無しさん mailto:sage [2018/01/08(月) 00:56:10.81 ID:y4IOANaR.net]
- 今時、C#みたいなGC付きの言語で3Dゲームが開発できちゃう時代なんだ。
今のPCの性能を鑑みたら、C, C++, Rust の速度差なんてほとんど誤差みたいなもんだろ。
普通は気にするようなもんじゃない。
そんなわずかな差が気になるって言うのなら直にアセンブリでも書いてろよ。
ぶっちぎりで速いぞ。
- 602 名前：デフォルトの名無しさん mailto:sage [2018/01/08(月) 01:09:23.55 ID:fNfSzvO3.net]
- 3DゲームってUnityのことか？Unityの内部はC#じゃなくC/C++では
- 603 名前：デフォルトの名無しさん mailto:sage [2018/01/08(月) 02:09:23.80 ID:xRIQXPI+.net]
- 有能はコンパイラが上手く最適化できるコードを書く
無能はコンパイラが混乱するコードを書く
Cの方が速いとか言う奴は大抵無能
- 604 名前：デフォルトの名無しさん mailto:sage [2018/01/08(月) 02:29:49.41 ID:+UJAnfcM.net]
- まあそれ言い出したらそもそもそこまでcpu速度に影響ある部分なんて
少ないけどな。
ガベコレねーからrust速いってやつも
スマポないからc速いってやつも
大して変わらん。
- 605 名前：デフォルトの名無しさん mailto:sage [2018/01/08(月) 02:49:24.32 ID:puck2ipT.net]
- 将棋ソフトとかチェスソフトは1%でも速くしたいという需要あるんちゃう
実際stockfishをRustで書き直したら速くなったりするのかね
- 606 名前：デフォルトの名無しさん mailto:sage [2018/01/08(月) 03:01:21.87 ID:88cycnja.net]
- >>591
あんまり大きいプログラムじゃないみたいだけど、内部は木構造か
うーん
- 607 名前：デフォルトの名無しさん mailto:sage [2018/01/08(月) 05:39:51.66 ID:PZS9kotp.net]
- >>589
それも突き詰めると絶対普段はこんなの書かねーっていうベンチマークのためだけのコードになったりするからなあ
>>585は有名な話だけどソース見ると言語によっては酷いもんだぞ
- 608 名前：デフォルトの名無しさん mailto:sage [2018/01/08(月) 16:00:03.99 ID:2tTEytIx.net]
- rustで書き直すぐらいならC/C++のままでいい
- 609 名前：デフォルトの名無しさん [2018/01/08(月) 16:42:57.60 ID:MR/7hfVk.net]
- 既存のC/C++コードを捨ててまで移行する価値のある言語ではないのはたしかだな
- 610 名前：デフォルトの名無しさん mailto:sage [2018/01/08(月) 16:49:10.90 ID:fzq0teyP.net]
- そもそもRustが便利だと思ってるやついないだろ
C++書いたことない奴がC++より安全だの同速だの言ってヨイショする
本当にCやC++書いたことあるならただの制限厳しいだけのゴミだと分かる
- 611 名前：デフォルトの名無しさん mailto:sage [2018/01/08(月) 16:54:23.84 ID:ZvHTaNmI.net]
- そう思いたいのですね
- 612 名前：デフォルトの名無しさん mailto:sage [2018/01/08(月) 17:52:58.17 ID:G8CneCok.net]
- ここはアンチスレだからね。
わざわざまともな話題をここでやることはない。
本スレは過疎
- 613 名前：デフォルトの名無しさん mailto:sage [2018/01/08(月) 18:53:52.23 ID:+UJAnfcM.net]
- c++ゴミ老害をマウントするために新言語が必要なんだろ。
- 614 名前：デフォルトの名無しさん [2018/01/08(月) 21:23:29.25 ID:aKL7Lo8F.net]
- >>579
速度優先なら
vtable作らない
smartpointer使わない
- 615 名前：デフォルトの名無しさん mailto:sage [2018/01/08(月) 21:24:35.96 ID:aKL7Lo8F.net]
- >>587
ゲーム開発はできてもゲームエンジン開発はどうなの
- 616 名前：デフォルトの名無しさん mailto:sage [2018/01/08(月) 22:12:41.54 ID:xRIQXPI+.net]
- 無能が生ポインタを使うとコンパイラの最適化を阻害して遅くなる
- 617 名前：デフォルトの名無しさん mailto:sage [2018/01/08(月) 22:47:28.33 ID:rvM8YIeZ.net]
- >>601
横レスだけどCAPCOMのC#自社エンジンはC++でモリモリ書いてあるしC#用VMもC++で独自実装(SlideShareに確か資料があったはず)
Unityだって結局ライブラリも開発環境もC++が大部分よね
- 618 名前：デフォルトの名無しさん mailto:sage [2018/01/08(月) 22:52:48.05 ID:cPU/Gv3T.net]
- カプコンのあれはゲーム用に超最適化されたGC詰んでるから…
- 619 名前：デフォルトの名無しさん [2018/01/08(月) 23:20:56.60 ID:y4IOANaR.net]
- >>588, >>601, >>603
そりゃぁ、ゲームエンジンは速度が求められるからC#じゃ力不足だろうな。
そこまで持ち出されるとグーの音も出ない。
だから「『普通は』気にするようなものじゃない」って書いた。
ゲーム作ろうとするのにゲームエンジンから自作しようとする奴なんて『普通は』いないだろ？
そして、仮にゲームエンジンの開発に使うんだったとしても、
C#みたいなGC付きの言語ならともかく、C, C++, Rustの差は誤差みたいなものでしょ。
なぜなら、C++とRustの差が気になるっていうのなら、当然、C++とCとの差だって気になるはずだよな？
だったらゲームエンジンの開発にC++じゃなくてCを使ってるはずだろ？
でも実際にはCじゃなくてC++が使われている。
ということはゲームエンジンみたいにシビアな領域でもCとC++の差はさほど気にされていないってことになる。
ならやっぱり、C, C++, Rustの差なんて気にするようなものじゃないと言いたかった。
- 620 名前：デフォルトの名無しさん [2018/01/08(月) 23:59:18.26 ID:y4IOANaR.net]
- >>579, >>600
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 の速度差は普通に使う分には気にすようなものじゃないと思う。
- 621 名前：デフォルトの名無しさん [2018/01/09(火) 00:07:21.22 ID:vsbSHK2s.net]
- >>606
訂正
week_ptr ×
weak_ptr ○
- 622 名前：デフォルトの名無しさん mailto:sage [2018/01/09(火) 00:16:14.62 ID:BgSfBmJG.net]
- 確かに
- 623 名前：デフォルトの名無しさん mailto:sage [2018/01/09(火) 08:02:08.21 ID:dghT81NU.net]
- HashTableがデフォルトで安全側に倒してSipHash使ってるのも大きい気はする
ripgrepやfont-rsなど既存の実装よりも圧倒的に高速なrust実装もあるし、言語自体の差と言うよりも、書き方の差だと思う
constexpr周りはDやC++の方が充実しているけど、build.rsなどで代替できなくもないと思う
- 624 名前：デフォルトの名無しさん mailto:sage [2018/01/09(火) 09:33:53.22 ID:4EiQrQ8s.net]
- Unityが出てからC#でゲーム書く人が増えたわけだし、どこかの企業が気合い入れてRustサポートしたエンジン作れば使ってみる人も増えるやろ
- 625 名前：デフォルトの名無しさん mailto:sage [2018/01/09(火) 10:25:16.50 ID:vtbi2ENx.net]
- 速さの差を気にする必要はないとかいう奴って
普段どんなところでコード書いてるプログラマなんだ？
プログラマなら一番速い選択するべきだろ
- 626 名前：デフォルトの名無しさん mailto:sage [2018/01/09(火) 10:36:54.87 ID:pRblgKD+.net]
- かけれるコストが一定という制約で一番速くなる言語を選ぶと結果は変わるんだよ
- 627 名前：デフォルトの名無しさん mailto:sage [2018/01/09(火) 10:59:57.42 ID:e9VuKocG.net]
- >>611
「速さ」にも何種類かあるのは理解してる？
最近は開発スピード優先だろ。
- 628 名前：デフォルトの名無しさん [2018/01/09(火) 12:31:14.96 ID:hZWQBtrg.net]
- 開発スピード優先とは言っても
アルゴリズムや計算量知らないで
とんでもない糞コード書く香具師はいる
- 629 名前：デフォルトの名無しさん mailto:sage [2018/01/09(火) 13:00:20.99 ID:CtLIzYrP.net]
- そりゃ論外だ。
開発言語の問題じゃない。開発手法は少しは関係あるか。
- 630 名前：デフォルトの名無しさん mailto:sage [2018/01/09(火) 13:08:01.94 ID:hgVWuJUP.net]
- Rustでプログラマが意識してないのに走るランタイム処理って何かあるかな？
起動時になんか処理してる？
あとは、メモリ解放時に意外とjemallocが重いとか？
- 631 名前：デフォルトの名無しさん mailto:sage [2018/01/09(火) 14:20:37.33 ID:vtbi2ENx.net]
- かけれるコストを減らすのがプログラマの仕事だろうに……
処理の肝の関数をアセンブリで書くのに一週間かけるのか？
- 632 名前：デフォルトの名無しさん mailto:sage [2018/01/09(火) 15:06:26.69 ID:pRblgKD+.net]
- > プログラマなら一番速い選択するべきだろ
> かけれるコストを減らすのがプログラマの仕事だろうに……
一番速い言語を選択した上でかけれるコストを減らすという主張のようだが、
コストの上限って大抵あるのよ？
上限ないならプログラム全部アセンブリで書いた上で
お好きなようにかけれるコストを減らしてください
> 処理の肝の関数をアセンブリで書くのに一週間かけるのか？
元になる関数の有無、関数の規模、ボトルネックとしての割合、
複雑さ、アーキテクチャ、既存のテストコードの有無、
作業する人数、スキルと単価の前提すらなく作業時間だけ提示されても
必要なら一週間かけますとしか言えないよね？
- 633 名前：デフォルトの名無しさん mailto:sage [2018/01/09(火) 15:08:41.92 ID:Im+qxt+8.net]
- >>617
> 処理の肝の関数をアセンブリで書くのに一週間かけるのか？
必要ならやるけど
ふつうは、アセンブリで書くというという結論に至る前に
処理の見直しで数ヶ月試行錯誤するかな
- 634 名前：デフォルトの名無しさん mailto:sage [2018/01/09(火) 15:46:18.74 ID:vtbi2ENx.net]
- 本当に必要なら
関数のアセンブリ化くらい一日でやるのがプログラマだろって話な？
- 635 名前：デフォルトの名無しさん mailto:sage [2018/01/09(火) 18:36:32.15 ID:pRblgKD+.net]
- 処理の肝の関数が一日程度のアセンブリの最適化ですむ程度なら、
絶対に手を付けないな
コードの保守性を考えるとむしろ害悪
ドライバのコードを一週間かけて最適化して劇的に早くしたことがあるが、
関数に対する暗黙の前提とかを見つけて、
ひらめきでニーモニックを最適化していく作業
一日程度でやることじゃない
- 636 名前：デフォルトの名無しさん mailto:sage [2018/01/09(火) 20:29:59.87 ID:6UEtXwLz.net]
- 今時の高性能(で複雑な)なプロセッサの最適化はコンパイラ＞人間
- 637 名前：デフォルトの名無しさん mailto:sage [2018/01/09(火) 23:11:43.33 ID:0nJMugwX.net]
- C++からRust移植で高速化！？
https://twitter.com/tanakh/status/950659594379968513
- 638 名前：デフォルトの名無しさん mailto:sage [2018/01/10(水) 00:25:27.71 ID:GZ3v7wml.net]
- 例の会社の方ですね
- 639 名前：デフォルトの名無しさん mailto:sage [2018/01/10(水) 01:04:10.48 ID:sDNuvOTB.net]
- stockfishもrustで書き直しましょう！
- 640 名前：デフォルトの名無しさん mailto:sage [2018/01/10(水) 05:48:28.54 ID:zJE5XuIr.net]
- 移植で高速化する案件ってのは、大概同じ言語で書き直しても高速化するからなあ
要するに作り直しに際して全体を見直すという行為が一番効く
- 641 名前：デフォルトの名無しさん mailto:sage [2018/01/10(水) 11:54:40.05 ID:kHYccep6.net]
- 詐欺会社の社員の言うことなんて信じるからRustなんかに飛び付くんやろなあ
- 642 名前：デフォルトの名無しさん mailto:sage [2018/01/10(水) 12:43:57.38 ID:6PCYvjwP.net]
- 気が狂ったようなレスだな
- 643 名前：デフォルトの名無しさん mailto:sage [2018/01/10(水) 15:45:01.02 ID:GLuGS5zO.net]
- >>626
お前それインタプリタ言語からコンパイル言語への移植でも同じこと言えんの？
- 644 名前：デフォルトの名無しさん mailto:sage [2018/01/10(水) 15:47:29.13 ID:GLuGS5zO.net]
- GoogleのAIエンジン、別にRustで書けとは言わんがせめてGoにしろやと常々思う
演算量多いんだよバーロー
- 645 名前：デフォルトの名無しさん mailto:sage [2018/01/10(水) 16:22:06.54 ID:Dg+5gWi5.net]
- GoogleのサーバサイドではPythonからGoへ置き換わりつつあるみたいだけど、そっちも置き換わるのか
- 646 名前：デフォルトの名無しさん mailto:sage [2018/01/10(水) 18:47:50.56 ID:GLuGS5zO.net]
- スレチだけど、Goはマルチコアでの並列処理に適した言語だからAIエンジンをサーバで動かすなら置き換えて欲しいよね
しかしまぁ、C/C++からRustの移植で早くなるのは、オブジェクトの取り回しが無理やり矯正されることによる恩恵かねぇ
mutexのlock/unlockによるブロッキングが早々起きないから待ち合わせしなくていい所の待ち合わせは矯正されてそう
プログラマが意識して作るならC/C++のままで良いけど、人がやるより機械がやってくれるならそれに越したことない
- 647 名前：デフォルトの名無しさん mailto:sage [2018/01/10(水) 20:16:34.04 ID:85p1Kkix.net]
- tensorflowの事言ってるなら、pythonで書かれてなかったら誰も使わないよ
- 648 名前：デフォルトの名無しさん mailto:sage [2018/01/10(水) 22:46:46.16 ID:GLuGS5zO.net]
- pythonは利用者==開発者での試験開発には非常に好ましい言語だけど、利用者!=開発者では性能悪くてver.2,3で言語仕様互換性のないRust未満のクソ言語だよ？
AIエンジンを実用ツールとして見ない日曜プログラマはtensorflow(python2 lib)をホクホクと使うけど、実用ツールとして見たらtensorflowは誰も望んでは使わないよ
同じように言語の適材適所を考えないプログラマはRustの適所を考えることもせず、アンチ活動に走るよね
コンパイル通るコード書くの大変だし、ローポインタ操作は好まれないし、日本語書籍少ないしで決して便利な言語じゃないけどRustもハマれば良い言語よな
- 649 名前：デフォルトの名無しさん [2018/01/10(水) 22:54:00.21 ID:aQix+RRX.net]
- アンチの存在はともかく
アンチと戦うのが好きな人が多いのが難点ですね
- 650 名前：デフォルトの名無しさん mailto:sage [2018/01/11(木) 01:05:22.99 ID:wQj3L0Ay.net]
- たなこふアンチはどっか逝って
- 651 名前：デフォルトの名無しさん mailto:sage [2018/01/11(木) 03:40:32.06 ID:iyu0SjqV.net]
- 演算グラフを構築してGPUに投げる処理をrustで書けば速くなると思ってる低脳っぷりヤバイわ
GPUの100倍も遅いCPUでループ回るのが速いとかマジでどうでも良いからw
- 652 名前：デフォルトの名無しさん mailto:sage [2018/01/11(木) 04:02:35.22 ID:QmzCPTgd.net]
- 今rustで業務アプリ開発してるけど、マルチスレッドでのデータ競合をコンパイル時にチェックしてくれるのが特にいい感じだわ
ただ、今まで気楽に相互参照使ってた所とかrust流の書き方しないとキツイのが結構あるな
- 653 名前：デフォルトの名無しさん mailto:sage [2018/01/11(木) 11:23:35.66 ID:s4xLMRqm.net]
- まあ行列演算のコアなところは今でもアセンブラだったりするわな。
一つの言語で全てのレイヤーを賄おうとするのがそもそも馬鹿すぎる発想。
- 654 名前：デフォルトの名無しさん mailto:sage [2018/01/11(木) 11:40:16.18 ID:AZiVul63.net]
- >>634
挙げてるデメリット全部致命的で、
全く嵌まれば強いように見えないな
- 655 名前：デフォルトの名無しさん [2018/01/11(木) 13:36:38.57 ID:c+w22aA0.net]
- >>640
それってpythonについて文句言ってんの？それともRust？
それとも両方？
- 656 名前：デフォルトの名無しさん mailto:sage [2018/01/11(木) 19:09:36.95 ID:iS+zA8r5.net]
- >>634
日曜プログラマとかレッテル貼ってdisってみたけど、
実は自分の方がクソど素人だと>>637>>639にバラされた気分はどう？
流行りだからってドカタが無理してAIとか口出さない方が良かったね
- 657 名前：デフォルトの名無しさん mailto:sage [2018/01/11(木) 19:11:41.94 ID:EF30eMeR.net]
- >>641
Rust
Pythonについては同意見
- 658 名前：デフォルトの名無しさん mailto:sage [2018/01/11(木) 23:02:05.67 ID:b1xHFrgv.net]
- 道具でしかないプログラミング言語ごときに何でそう愛憎うずまくレスが沸くんだぜ
- 659 名前：デフォルトの名無しさん mailto:sage [2018/01/12(金) 00:01:22.91 ID:v4YvA7k7.net]
- やっぱりマイナー負け組言語マニアは余裕がないから
簡単にムキになっちゃうんじゃね
- 660 名前：デフォルトの名無しさん mailto:sage [2018/01/12(金) 00:16:17.30 ID:8Bbkgawk.net]
- Rustが使える有能な言語だと思っている？お前がそう思うんならそうなんだろう お前ん中では
Rustが使えない糞な言語だと思っている？お前がそう思うんならそうなんだろう お前ん中では
お前がそう思うんならそうなんだろう お前ん中では
- 661 名前：デフォルトの名無しさん mailto:sage [2018/01/12(金) 10:24:05.79 ID:KQEkfNlJ.net]
- >>646
そういうお前のなかではどうなんだ？
- 662 名前：デフォルトの名無しさん mailto:sage [2018/01/12(金) 15:03:45.10 ID:yzgw2U0r.net]
- >>644
本当は電気ドリル使った方が楽なのに頑なにスコップ使わせたり、
逆にブルドーザーでやれというようなアホな現場があるのが
ITの世界だったりする。
まあそんなことが続けばその道具を嫌いになるのはわからんでもない。
- 663 名前：デフォルトの名無しさん mailto:sage [2018/01/12(金) 16:29:33.21 ID:/01TbNc2.net]
- >>648
わかる
そしてスコップやブルドーザーでも時間や犠牲を払いつつもやれてしまうのがITの世界
- 664 名前：デフォルトの名無しさん mailto:sage [2018/01/12(金) 19:30:59.16 ID:RuIpixvC.net]
- >>642
とりあえず、tensorflowのコードを見てないんだなって思った
GPUに投げる演算処理以外のステップ処理とか関数コールとか動的型変数の取り扱いとか
インタプリタ言語がコンパイル言語より遅い理由に挙げられるデメリットをガン無視かよぉ
>>643
IteratorやOption, Resultとか、ハマればC/C++で何行もかけて書いてた所が1行に収まって
短くて可読性高くて性能良いコードになるのはメリットだと思うんだけどなぁ
あとは、makeだのvalgrindだのgoogletestだの色々な3rd party toolを使わなくてもcargoで完結するのホント助かる
- 665 名前：デフォルトの名無しさん mailto:sage [2018/01/12(金) 20:43:22.05 ID:yzgw2U0r.net]
- >>650
3rdパーティツールを使ってないんじゃなくて、利用が簡易ってことだけどな。
そういう怪しげなこと書くくらいならモチっと使い方なり書いた方が普及には繋がると思うよ。
https://qiita.com/kubo39/items/cb84cd0ee89d257ce11e
- 666 名前：デフォルトの名無しさん mailto:sage [2018/01/12(金) 20:52:57.80 ID:/u+itip5.net]
- >>650
tensorflowはボトルネックになりそうな所はC++で書かれてるよ
想像でテキトーな事を書くなよ
- 667 名前：デフォルトの名無しさん mailto:sage [2018/01/12(金) 21:01:05.95 ID:/u+itip5.net]
- Pythonが科学技術分野で好まれてるのは
numpyやscipyのお陰だから言語に文句つけても意味ないし、
Rustで書くよりnumpyで行列演算した方が速いから
速度面でも移行するメリットがない
- 668 名前：デフォルトの名無しさん mailto:sage [2018/01/12(金) 21:54:28.61 ID:kjmG24Y8.net]
- >>648
ITに限らないような。低能率な環境や命令を棚に上げて生産性向上などと吠える製造業も多いぞ
- 669 名前：デフォルトの名無しさん [2018/01/13(土) 09:02:27.08 ID:PRFVc3V3.net]
- >>654
未だに設計にEXCEL使ってる現場とか多いしね。
自称IT屋がIT使ってない。
- 670 名前：デフォルトの名無しさん mailto:sage [2018/01/13(土) 19:22:01.99 ID:MW2t1rKM.net]
- excelがITではないとは暴言では
- 671 名前：デフォルトの名無しさん mailto:sage [2018/01/13(土) 19:34:17.26 ID:aU8wc9zz.net]
- エクセルは芸術
- 672 名前：デフォルトの名無しさん [2018/01/13(土) 21:22:56.33 ID:ZmH3DZ0F.net]
- >>656
ああ精確には「古いIT」だな。
客には「Excelで台帳管理しないでDBとWebアプリ使いましょう」とか提案する癖に、開発工程ではExcel使ってるという非効率さ。
- 673 名前：デフォルトの名無しさん mailto:sage [2018/01/13(土) 21:38:44.30 ID:V4m1sF41.net]
- Excelが悪いとは思わないけど処理の規模が一線を越えてくるとプログラムを書いた方が処理効率や保守性の面で有利になる
関数山盛りの激重スパゲッティワークシートを運用しているところは少なからずあるのでは
あとExcelに表計算ソフト以上の仕事をさせているところも結構あるな
- 674 名前：デフォルトの名無しさん mailto:sage [2018/01/13(土) 21:43:49.20 ID:aU8wc9zz.net]
- 経済学の論文でエクセル使ってて、しかし普通にバグってて問題になってたことがあったな。
- 675 名前：デフォルトの名無しさん mailto:sage [2018/01/14(日) 00:19:53.66 ID:Qz3+ZXNT.net]
- rustスレだと思っていたがexcelスレだった
- 676 名前：デフォルトの名無しさん mailto:sage [2018/01/14(日) 01:19:41.63 ID:I9Kg/0Pm.net]
- >>658
規模がでかくなるとすぐ破綻するが
使い捨て作業でつかうぶんには超優秀
なにもまちがってない
- 677 名前：デフォルトの名無しさん mailto:sage [2018/01/14(日) 03:40:45.43 ID:ppap/O0M.net]
- まあ実際はエクセルとバージョン管理使ってりゃそれで十分なケースは多いけどね。
|
 |
