次世代言語18 Go Rust Elixir Kotlin TypeScript

**デフォルトの名無しさん** · 2019/10/01(火) 02:58:03.93

スレタイ以外の言語もok

前スレ
次世代言語17 Go Rust Kotlin TypeScript Julia
https://mevius.5ch.net/test/read.cgi/tech/1567602619/

**デフォルトの名無しさん** · 2020/01/05(日) 17:01:50.31

>>121
RubyはPythonの地位にあってもおかしくなかった
アカデミックな世界の人たちがPythonに流れたのが大きかった

**デフォルトの名無しさん** · 2020/01/05(日) 17:41:07.92

rubyが出た頃には既にpythonは十分人気があったわけで、流れたというより
pythonのシェアを奪えないまま自滅したという方が合ってる気がする。

**デフォルトの名無しさん** · 2020/01/05(日) 18:38:52.97

>>123
研究者が使うフレームワークが殆どpytorch一色になったので、
tensorflowもどこまで安泰か分からん

**デフォルトの名無しさん** · 2020/01/05(日) 18:48:23.54

>>125
いや、一時期は間違いなくRubyはPythonよりも人気があったよ
日本に限らず世界でね
2000年代に入ってからSciPyとNumPyという科学計算ライブラリの決定版が出たことで一気にPythonの地位が上がった
それまでR言語とかに注目してた層が根こそぎPythonに飛びついて大逆転した
もしSciRubyやNumRubyだったらRubyが天下を取っていたはず

**デフォルトの名無しさん** · 2020/01/05(日) 18:56:14.34

PyTorchやTensorFlowがどうしてPythonなのかが全く分からん
あんな遅い言語で機械学習をやるメリットは何なの？
ディープラーニングは複雑な計算が必要だからこそ高速な言語でやらないとって思ってしまうのは俺がド素人だから？

**デフォルトの名無しさん** · 2020/01/05(日) 19:08:07.33

単にAPIとして優秀だからだよ
それだけ

**デフォルトの名無しさん** · 2020/01/05(日) 19:12:24.89

PythonではC等で書かれたライブラリを呼ぶだけで計算はしないから、遅くても問題ない

**デフォルトの名無しさん** · 2020/01/05(日) 19:15:19.30

どんな言語で書いてもCUDA等を呼び出すだけだから

**デフォルトの名無しさん** · 2020/01/05(日) 19:19:55.04

>>128
この分野ではライブラリ叩くのだけが役目で速さがいらないからこそPythonが生き残ったんだよ

**デフォルトの名無しさん** · 2020/01/05(日) 19:44:46.12

ruby好きの奴らなんてmatzも含めて絶対数値計算なんかやらんかっただろう。
そういうとこだよ。

**デフォルトの名無しさん** · 2020/01/05(日) 20:12:28.37

客観的な数字がない以上どっちが人気があったかというのは水掛け論でしかないけど、
rubyが世界的に人気が出たと言えるのはRoR以降で、登場時期はNumpyとほぼ同じなんだよな。
仮にrubyの人気がpythonを上回ったことがあったとしても非常に短い期間に限られたと思われ。

**デフォルトの名無しさん** · 2020/01/05(日) 20:53:54.52

>>128
pythonが実行速度が必要なところはcで書けばいいと割り切ってる中で
rubyは言語自体の速さをあげることに時間かけてた。
そういう見識のなさがrubyなんだよ。

**デフォルトの名無しさん** · 2020/01/05(日) 21:17:35.10

68 名前：デフォルトの名無しさん[sage] 投稿日：2019/11/11(月) 08:41:18.73 ID:ugn4nfqU
炎上PJに巻き込まれて帰ってこれなくなってしまったのだろう

69 名前：デフォルトの名無しさん[sage] 投稿日：2020/01/03(金) 12:58:50.03 ID:f2V4CbYL
あけ　おめこ　とよろ

おまえら、この空白の2ヶ月間、何してたんだ？

**デフォルトの名無しさん** · 2020/01/05(日) 21:54:16.01

>>135
さすがに無知すぎるだろ
PythonもRubyも知らないなら無理すんなw

**デフォルトの名無しさん** · 2020/01/05(日) 22:23:58.34

>>137
Ruby信者イライラでウケるw

**デフォルトの名無しさん** · 2020/01/05(日) 23:09:54.68

>>137
やっぱrubyやってる輩って低レイヤーのことをまるでわかってないのな。
馬鹿丸出し。

**デフォルトの名無しさん** · 2020/01/05(日) 23:34:13.56

pythonもpython自体の高速化はやってきてるでしょ
pypyみたいな変態的なものもあるし
むしろrubyの方が言語仕様的に高速化できる余地が少なくて停滞してた印象
yarvも遅れてやってきた感しかない

まぁ身もふたもないけど、つたない英語で日本人がリードするプロジェクトに
外人はあんまり寄り付いてこないのがrubyがいまいち盛り上がらなかった原因だと思うよ
RoRの波の時にいろいろ仕掛けておけば違った気がするんだけど

**デフォルトの名無しさん** · 2020/01/06(月) 11:00:46.22

>>140
日本でRubyが人気あるのは日本で誕生した言語(→日本語のドキュメントやコミュニティが充実)だからってのは確実にあるだろうし逆に考えたらアメリカ人は英語圏で誕生した言語を使うわな
Python開発者はオランダ人だけどアメリカで働いていた人だし

**デフォルトの名無しさん** · 2020/01/06(月) 22:45:21.22

>>140
結局遅くてもデフォルトのcpythonを使うわけだよ。
そこまでcpuバウンドなプログラムなんて早々ないし、あったらcで実装したライブラリを使う。
なんでも同じ言語だけで無理やり何とかしようってのはバカの発想だわ。
cをどれだけ呼びやすくするかに労力をかけたpythonにrubyは完全に負けたわけよ。

**デフォルトの名無しさん** · 2020/01/06(月) 22:51:03.06

cというか共有ライブラリの呼び出しでそんな大きな違いあったっけ？
似たようなもんだったと思うけどな

**デフォルトの名無しさん** · 2020/01/06(月) 23:48:50.87

cで実装って言っても、cythonなら殆どpythonのように書けるわけで

**デフォルトの名無しさん** · 2020/01/07(火) 08:51:26.11

旧世代言語で言えばC++、Java、Python、JavaScriptの4つが書ければ組み込みからウェブまで基本的に何でもできた
1つの言語で何とかしようとすれば何とかなるかもしれないが開発効率を考えると結局この4つくらいの言語が必要
速さのC++、汎用性のJava、書きやすさのPython、ウェブのJavaScript
最強の言語に統一しようとする試みは全部失敗に終わって適材適所で使い分けるのが結局最適解だったわけだ
次世代言語では汎用性と書きやすさを兼ね備えたGoがあるのでRust、Go、TypeScriptが必須三大言語になる

**デフォルトの名無しさん** · 2020/01/07(火) 11:10:34.52

wasmの展開次第ではまた統一の流れになるかもよ
今のところRustかGoかかな

**デフォルトの名無しさん** · 2020/01/07(火) 15:35:35.01

cythonよりもpybind

**デフォルトの名無しさん** · 2020/01/07(火) 21:50:43.14

Ruby の主な設計思想は、C の拡張ライブラリを作りやすくする事！
今は、FFI

言語が流行るかどうかは、便利な拡張ライブラリの作りやすさで決まる。
VSCode がそう。
皆が作る、多くの拡張機能が大人気

R, matlab → Python → Julia
Ruby → Elixir

数十万もする、matlab を誰も使いたくない！
これが無料で使える、Pythonがコスト的に優秀だった！

ただ、文法が辛いから、Ruby風のdo ～ end を採用した、Juliaへ流れたw

**デフォルトの名無しさん** · 2020/01/07(火) 22:09:56.51

的外れのことをよく長々と書くもんだな

**デフォルトの名無しさん** · 2020/01/07(火) 22:35:33.23

juliaなんてインデックスが１はじまりな時点で終わってんだよ。

**デフォルトの名無しさん** · 2020/01/07(火) 22:54:19.05

ruby信者はrubyの文法が好きみたいだけど
rustは文法もゴミだからね？

**デフォルトの名無しさん** · 2020/01/07(火) 22:55:15.32

あ、rubyをrustに間違えた。rustすまん…

◆QZaw55cn4c · 2020/01/07(火) 22:58:02.03

>>152
許さん

**デフォルトの名無しさん** · 2020/01/07(火) 23:27:16.65

まぁほら、値を返す場合はセミコロンを付けちゃいかんとか、あの辺は真にゴミだ。

**デフォルトの名無しさん** · 2020/01/08(水) 11:36:37.71

どうしたらよかった？

**デフォルトの名無しさん** · 2020/01/08(水) 14:43:49.47

>>115
Dartは今一番来てる言語だろ
ちょうどFlutterのスター数がReact Nativeを超えたところだぞ
これで名実ともにクロスプラットフォーム開発のスタンダードがDartになった

**デフォルトの名無しさん** · 2020/01/08(水) 15:05:07.83

Rustのセミコロンは文の終端じゃなくて、「左オペランドを評価してその値を破棄し、右オペランドを評価してその値を返す演算子」だと理解すればスッキリする

**デフォルトの名無しさん** · 2020/01/08(水) 19:33:38.16

そんな独自ルール押し付けられても普通はくそだとしか思わんよ。

**デフォルトの名無しさん** · 2020/01/08(水) 20:28:36.87

>>155
「式にセミコロンを付けたら文になる」
「文の評価値はunit」
「ブロックの値は含まれる最後の式(文)の値」

それぞれは筋が通ってなくもないけど、2番目のは

「文の値は含まれる最後の式の値」

にしても問題なかったんじゃないのかな。

**デフォルトの名無しさん** · 2020/01/08(水) 20:40:04.73

結局Rustは死産だった

**デフォルトの名無しさん** · 2020/01/08(水) 20:46:34.81

>>159
問題あるからそうなってるんだよ

**デフォルトの名無しさん** · 2020/01/08(水) 21:11:26.71

>>161
具体例plz

**デフォルトの名無しさん** · 2020/01/08(水) 21:25:54.87

なぜ
Go
Rust
TypeScriptが
旧世代5大言語を超越するのでしょうか？

**デフォルトの名無しさん** · 2020/01/08(水) 21:50:40.19

>>163
Go→めっちゃ書きやすい。少ない行数で何でも書けるので生産性爆上げ。実効速度はC/C++よりは遅いがJavaやPythonよりもずっと速いので何にでも使いやすい。文法が分かりやすいので入門用言語にも適している。オールマイティな次世代エース的存在で欠点がほぼない

Rust→C++と同レベルに速い唯一の言語。なおかつC++よりも文法が整理されている。C++と違ってメモリ安全性が確保されている。Goほどの書きやすさ・利便性はないがC++の後継としてシステムプログラミングに使えると考えられている

TypeScript→JavaScriptを大規模開発にも使えるように整備した言語。JSがウェブだけでなくアプリ開発にも使われるようになったという背景にマッチ。既存のJSコードという遺産をそのまま使えるのでデメリットなし

3言語ともにGoogleやMicrosoftが推しているので他企業も追随して移行している

**デフォルトの名無しさん** · 2020/01/08(水) 21:58:55.88

Goの行数が短いとは

**デフォルトの名無しさん** · 2020/01/08(水) 22:05:03.81

GoはAI関連のPythonからの移行組、組み込み系のCからの移行組、アプリ開発のJavaからの以降組と色々なところから支持されてるよな

**デフォルトの名無しさん** · 2020/01/08(水) 22:19:11.42

goはガベコレ付きのcってくらいだろ。それくらい機能が少ないから良い。

**デフォルトの名無しさん** · 2020/01/08(水) 22:59:45.27

Goは機能が少ないから行数は長くなるな
ジェネリクスがまだなくて冗長になりやすい
良くも悪くも割り切ってる

**デフォルトの名無しさん** · 2020/01/08(水) 23:17:23.66

PythonやJavaは機能が多過ぎるからGoに移行すると言ってるように見えるが
多過ぎるという証拠がない

**デフォルトの名無しさん** · 2020/01/09(木) 01:00:17.42

GoがJavaよりずっと速いってことはない
ほぼ同程度

**デフォルトの名無しさん** · 2020/01/09(木) 01:23:41.01

かなり速いよ
起動が

**デフォルトの名無しさん** · 2020/01/09(木) 02:53:10.48

>>159
今日まで1200円（93%OFF）で買えるよ

現役シリコンバレーエンジニアが教える
Goで始めるスクラッチからのブロックチェーン開発入門
45レクチャー（5時間33分）
https://www.udemy.com/course/go-blockchain/

**デフォルトの名無しさん** · 2020/01/09(木) 06:44:29.90

Rust in Blockchain
Bringing engineering insight and experience to blockchain technology.
https://rustinblockchain.org/

**デフォルトの名無しさん** · 2020/01/09(木) 07:42:30.82

>>159
returnを省略できるから値を必ず返してしまう

**デフォルトの名無しさん** · 2020/01/09(木) 09:24:02.44

Goはそこそこ速くて文法もすっきりしてるから汎用性高い

**デフォルトの名無しさん** · 2020/01/09(木) 11:06:37.80

Goは機能も絞ってあるし文法も簡単だから初心者の入門用に最適だと思う
しかも当然Pythonより速いので実用性も高い
次世代では学校でGoを習ってプログラミングを始めて実務でもGoで書ける部分はそのままGoとなりそう

**デフォルトの名無しさん** · 2020/01/09(木) 11:22:30.94

旧世代五大言語…C、C++、Java、Python、JavaScript
新世代五大言語…Go、Rust、Kotlin、Swift、TypeScript

今のところこんな感じだけどDartやJuliaは五大に入ってきてもおかしくないと思ってる
クロスプラットフォームアプリ開発でDart(Flutter)がReactNativeに勝利しそうな勢いで注目してる
多分DartはJavaライクな文法がJavaScript嫌いなアプリ開発者たちから受けてるんだろう
AndoroidはKotlin、iOSはSwiftという棲み分け自体が不効率の極みなのでDartがもう少し使えるものになればクロスプラットフォーム開発に雪崩を打って移行していくと思う
JuliaはJuliaですでにAI関連で信者層が形成されているしPythonでできることはJuliaでもできる状態になってるからじわじわシェア奪っていけると思う
TensorFlow次第という側面もあるが

**デフォルトの名無しさん** · 2020/01/09(木) 12:07:25.94

dart2nativeのよってFlutter以外にもDartの使い道が

**デフォルトの名無しさん** · 2020/01/09(木) 12:45:50.31

GoはそもそものGoogle自身がほとんど使ってない

**デフォルトの名無しさん** · 2020/01/09(木) 13:01:10.01

AndroidはJavaScript、iOSもJavaScript
一方、サーバーは非効率の極み

**デフォルトの名無しさん** · 2020/01/09(木) 14:16:30.17

C#はMSの推奨言語である限り何が出てこようとVC++とともにMS環境下での第一選択肢であることは揺るがない
基本的にOSやハードウェアのベンダーが使えと言っているものと使うのが正しい

**デフォルトの名無しさん** · 2020/01/09(木) 21:24:14.26

関数型言語の特性を少しずつ取り入れる動きがあるのは（それが良いかどうか別にして）ある程度共通の認識として持たれていて
その中でも型システムに関してRustはライフタイム管理と参照の可変性制約に議論の余地があるとはいえそれ以外は程々な落としどころになってると思うんだけどどうよ
つまりはtraitとかenumとかgenericsとかについてなんだけど

**デフォルトの名無しさん** · 2020/01/09(木) 21:39:52.57

てかemunの網羅性チェックとか普通に考えたら欲しくなると思うんだが
なぜC/C++/Java等の手続き型/オブジェクト指向言語では今まで取り入れられてなかったのかが謎

**デフォルトの名無しさん** · 2020/01/09(木) 21:52:21.07

>>174
関数戻り値の型推論はされないんだから、関数の型がunitのときは型の不整合とみなさないとか
できると思うがなぁ。
その場合のデメリットって「特別扱いは一貫性に欠ける」というくらいしか思いつかない。

**デフォルトの名無しさん** · 2020/01/10(金) 01:35:53.38

ジェネリクスの起源はC言語の配列型やポインタ型のような気がする
ポインタ型を取り入れるどころか逆に排斥するのが常識だった
たまたま常識を疑うことができたのがC++と関数型言語だっただけ

**デフォルトの名無しさん** · 2020/01/10(金) 02:36:02.44

次世代とか関係なく趣味でやるのにオススメの言語ある？
https://rosettacode.org/wiki/Category:Programming_Languages

https://duckduckgo.com/bang_lite.html
!rosettacode Generics

**デフォルトの名無しさん** · 2020/01/10(金) 10:47:12.28

次世代とか関係ないならスレチ

**デフォルトの名無しさん** · 2020/01/10(金) 15:44:58.26

>>186
https://mevius.5ch.net/test/read.cgi/tech/1571717826/

**デフォルトの名無しさん** · 2020/01/10(金) 20:05:28.59

>>182
逆だろ。
rustのやろうとしてることを考えればライフタイム管理と参照の可変性制約に議論の余地はない。
他のどうでもいいところに力を入れてることの方が問題。

**デフォルトの名無しさん** · 2020/01/10(金) 21:31:36.42

力を入れるより力を抜く方が難しい戦闘民族もいるんだろう

◆QZaw55cn4c · 2020/01/11(土) 11:07:27.64

>>185
多分趣旨は同一だと思いますが、私はC++ template がジェネリクスの起源だと

**デフォルトの名無しさん** · 2020/01/11(土) 12:52:41.76

お前初めてか次世代言語は、力抜けよ

**デフォルトの名無しさん** · 2020/01/11(土) 13:04:07.27

Genericsの起源 → template
Genericsの起源 → enum
Genericsの起源 → マクロ
Genericsの起源 → キャスト
Genericsの起源 → struct
Genericsの起源 → union
Genericsの起源 → ポインタ
Genericsの起源 → レジスタ

**デフォルトの名無しさん** · 2020/01/11(土) 13:42:11.23

全ての始祖にして始まりの言語　ダークネスオブライト　神光雪花繚乱　ーCー

おまえはまだ、本当のCを
知
ら
な
い

**デフォルトの名無しさん** · 2020/01/11(土) 17:39:11.16

>>189
ごめんこれは私の書き方が悪かった
Rustのやろうとしてることからすれば議論の余地が無いのは間違いない

ただRustのやろうとしてること（つまりそれらを型システムに落とし込んで管理しようとすること）そのものには反対意見も見られるのでそのように書いた
（私はRustの方針で良いとは思っている）

それなりに一般人類が扱える程々な型システムの機能は言語の目的に依存しない範囲でどの程度かなって話をしたかった
型システムの程々が言語の目的に依存するのは分かった上でなので、それ無しに語る事なんてできないと言われたらはいとしか返せない

あと例にgenericsを書いたのは最近の言語でGoが少なくとも今は取り入れてないからだったんだけど、冒頭に関数型～と書いてしまったがために >>185 みたいに起源の議論になってしまって申し訳ない

あとgenericsの起源の話をするならAdaちゃんのことも思い出してあげて下さい（小声）

**デフォルトの名無しさん** · 2020/01/12(日) 02:59:36.74

言っとくけどMITのJulia凄いんだから！バカにしたら許さないから！

**デフォルトの名無しさん** · 2020/01/12(日) 10:32:30.51

バーカ
おまえのかーちゃんAV女優

**デフォルトの名無しさん** · 2020/01/12(日) 11:36:08.74

juliaはクソだわ。推してるやつも数値計算まともに理解してないろ。

**デフォルトの名無しさん** · 2020/01/12(日) 15:31:32.23

実数クラスは複素数クラスを継承していない
数値計算の闇は深い

**デフォルトの名無しさん** · 2020/01/12(日) 15:35:53.73

おまえらクラスにはセックスメソッドすら実装されてないよね

**デフォルトの名無しさん** · 2020/01/12(日) 18:19:08.33

じゃあ実装するから
LGBTをふまえたモデル化やってみて

**デフォルトの名無しさん** · 2020/01/12(日) 20:19:36.78

は？キモ

**デフォルトの名無しさん** · 2020/01/13(月) 21:57:09.26

Go, Rust, Swift, Kotlin, Typescript
基本的にこれだけやっとけばいいわけか

**デフォルトの名無しさん** · 2020/01/14(火) 12:59:45.06

>>203
分野次第だろ
例えばiPhoneアプリ作らないならSwiftいらないし

**デフォルトの名無しさん** · 2020/01/14(火) 13:30:37.65

〇〇だけやればいい
これを満たせるのはC++とJavascriptだけ

**デフォルトの名無しさん** · 2020/01/14(火) 13:56:29.79

旧世代「綿密な準備、計画、理解、Go、Rust、Swift、Kotlin、Typescript」
ニュータイプ「あっ（察し）」

**デフォルトの名無しさん** · 2020/01/14(火) 18:52:16.13

本屋に行くとswiftやkotlinの本がたくさん陳列してあって流行ってるのを感じる

**デフォルトの名無しさん** · 2020/01/14(火) 20:52:15.46

まだ発展途上とはいえ、RustってC, C++の上位互換っていう認識でいたんだけどどうなの

ライブラリの充実度とかはまだまだだろうけど

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

>>208
上位互換を目指してるというのは正しいけどまだ上位互換とは言えない
C/C++のほうがまだ多少は実効速度が上みたい
体感できるほどの差はもちろんないけど

**デフォルトの名無しさん** · 2020/01/14(火) 21:37:06.70

Rustのほうが未来永劫遅いだろ
速くなる要素あるのか？

**デフォルトの名無しさん** · 2020/01/14(火) 21:53:54.59

言語の処理速度は　　　　　　C > C++ > Rust
プロダクトの性能の傾向は　Rust > C++ > C

理由は、コンパイラ時のチェック系の支援が大きいほど
プログラマが気を使う量が減って高度な高速化実装がしやすくなるため
実例はServo

一方Cで限界までチューニングすれば他は追いつけない
メンテ難易度は上がるがそれを扱えるメンバーと運用があれば問題無い
実例はLinuxカーネル

**デフォルトの名無しさん** · 2020/01/14(火) 22:06:05.36

色々な言語が登場しても未だにCが生き残ってるのはとにかく速さだからね
Cを置き換えようとする次世代言語は速さでCに負けてたら結局置き換えられないよ

**デフォルトの名無しさん** · 2020/01/14(火) 22:09:27.27

Cが使われる理由は速さではなく自由度
書いたとおりに動くという当たり前のことができる言語は、特に新しい言語においてはほとんどない

**デフォルトの名無しさん** · 2020/01/14(火) 22:16:53.48

>>211
と思うじゃん？
実際はコンパイル時間が鬱陶しすぎてクソな通し方するようになる。

**デフォルトの名無しさん** · 2020/01/14(火) 22:43:28.59

Rustは、Cには負けるけどC++には速度で勝った、みたいな記事を最近見たんだが

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

しょーもないブログ記事なんか真に受けんな

**デフォルトの名無しさん** · 2020/01/15(水) 00:35:12.86

C++のコンパイル時計算のあれこれを見ていると証明が必須じゃないCoqかよみたいな気持ちになるし人類にとってはできることが多すぎる
コンパイル時間のあれこれを言うならC++こそ人の事言えねぇよ

**デフォルトの名無しさん** · 2020/01/15(水) 03:36:18.54

まあそうなんだがc++を置き換えると言いつつ
c++の問題を後追いしてるところはアホとしか言いようないなと思ってるってことだわ。

**デフォルトの名無しさん** · 2020/01/15(水) 04:14:23.70

C++を越えようとすればするほどC++に近づき、最終的にC++そのものになっていく

**デフォルトの名無しさん** · 2020/01/15(水) 09:36:21.05

最近はセキュリティ要件厳しいから
静的解析パスしないとリリースできなかったりするんだけど
とりあえず静的解析を黙らせるために過剰にvalidity checkが入れられてると思う
そういう無駄をきれいに省けたらc、c++を上回る可能性はあるかもしれない

**デフォルトの名無しさん** · 2020/01/15(水) 11:05:13.31

でもボクシングとかで実行時に負担掛ける動的多相を導入しない限りコンパイル時間は大きくは変化しないでしょという気持ち（型渡しと型消去）
別にRustだって依存型（定理証明系）とか高階多相（Scalaとか）でコンパイル時間増えてるわけじゃないんだし

**デフォルトの名無しさん** · 2020/01/15(水) 13:04:38.24

高尚な低速言語供が売りとしてる機能を組上げる部品をゲロベチョっとコーダー側へぶちまけ
オマエ自身が工夫してどうにかしろな仕組みを提供してんのがrustだからのう
関数型へ傾いてるとはいえコンパイル時間がどうこう言うのにrustの例は不適切かな

**デフォルトの名無しさん** · 2020/01/15(水) 19:26:50.92

いや実際cの5～10倍ビルド時間かかるだろ。