Kotlin 5

**デフォルトの名無しさん** · 2018/12/08(土) 20:29:41.41

JetBrainsが開発した期待の新言語、Androidの公式開発言語にしてサーバーサイドもなんでもいけるKotlinについて語りましょう

※前スレ
https://mevius.5ch.net/test/read.cgi/tech/1531818027/

**デフォルトの名無しさん** · 2019/02/07(木) 10:01:05.59

>>238
根幹の言語機能の所有権とライフタイムにより
C++でのムーブセマンティクスやRAIIみたいなのをより高度にコンパイラが認識出来るので
速度(効率)を保ったまま安全性を高められてる

**デフォルトの名無しさん** · 2019/02/07(木) 10:55:21.09

Goはフットプリントも小さいからな。
C++だと、iostreamを静的リンクしただけでもそこそこ大きくなるのに。

**デフォルトの名無しさん** · 2019/02/07(木) 12:43:04.54

上で1..10の速さ書いたんやけどあれは実測じゃなくて速さランクのイメージや。
go<kotlin native<<jvm<<壁<<script言語
こうなるなら納得なんやけど、現実には
kotlin native ≒ jvmなの？
最適化されたらgoに迫ると思い込んでるんやけどそんな甘くないんかな。

**デフォルトの名無しさん** · 2019/02/07(木) 13:44:29.30

最適化できたらそらそうだけど、その最適化がどこまで出来るかどうかはお天道様にしか分からない

**デフォルトの名無しさん** · 2019/02/07(木) 14:46:10.65

それもそうやね。大人しく半年か1年くらい待ってみるわ

**デフォルトの名無しさん** · 2019/02/07(木) 14:47:12.25

コンパイラの頑張り次第で Go ≒ Kotlin/Native まで行ける可能性はある

ベンチマークでは C ≒ Rust << Go ≒ JVM
Rust vs Go　https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/rust-go.html
Go vs Java　https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go.html

しかしGCの性質の違い、JVM起動時間、JIT、並列処理サポートなどにより
各ユースケースに対する適性は速度だけでは決まらない

**デフォルトの名無しさん** · 2019/02/08(金) 16:17:29.13

3桁ごとにカンマ打つには、
val str= "123456"
println( str.format("%,d"))

想定では、123,456のはずが123456になる
使い方間違ってるかな？

**デフォルトの名無しさん** · 2019/02/08(金) 17:15:55.53

逆じゃね？

**デフォルトの名無しさん** · 2019/02/08(金) 18:09:56.46

逆＋Intでないとダメみたい
BigDecimal放り込んだら勝手に12,345.6789みたいになればと思ったんだけど、自分で作るの面倒で信用ならん

**デフォルトの名無しさん** · 2019/02/08(金) 18:45:11.42

jvmならNumberFormatでいいんじゃないの

import java.math.BigDecimal
import java.text.NumberFormat

val BigDecimal.fmtStr: String
get() = NumberFormat.getNumberInstance().format(this)

fun main(args: Array<String>) {
val a = BigDecimal(12345.6789)
println("${a.fmtStr}")
}

**デフォルトの名無しさん** · 2019/02/08(金) 19:35:10.36

ごめんよく見たら丸められてたから訂正
https://ideone.com/AvbxFT

**デフォルトの名無しさん** · 2019/02/08(金) 19:59:36.92

>249

"."探して、整数と小数点以下に分けて整数部分にカンマ打ってから合体させようとしこしこ作ってたら別のアイデア出てた
ありがと

**デフォルトの名無しさん** · 2019/02/09(土) 06:09:56.82

locale によってはカンマが3桁区切りではないかも知れないし記号がカンマではないかも知れないので
こうやって自分でやっちゃった方が良いのでは？

println(java.text.DecimalFormat("#,##0.000").format(java.math.BigDecimal("1234567890.1235"))) // 1,234,567,890.124

**デフォルトの名無しさん** · 2019/02/09(土) 07:35:37.20

>>251
ロケールに従わず常にカンマにしたいという意図ならそれだとそぐわないと思う
DecimalFormatに与えたカンマはカンマという文字ではなくグループ区切り子なのでロケールに応じた文字で出力されるよ

**デフォルトの名無しさん** · 2019/02/10(日) 17:34:05.13

日本, アメリカ, イギリス他
1 = 1.000 < 10 < 1,000 = 1000

ドイツ, イタリア他
1 = 1,000 < 10 < 1.000 = 1000

ロシア, フランス他
1 = 1,000 < 10 < 1 000 = 1000

オーストラリア, カナダ他
1 = 1.000 < 10 < 1 000 = 1000

国際単位系(SI)
1 = 1,000 = 1.000 < 10 < 1 000 = 1000
　　空白を小数区切りに使う国が無いことと、ポイントとカンマの各国のばらつきから
　　読み取り間違いを避けるための妥協案のようなもの

**デフォルトの名無しさん** · 2019/02/10(日) 17:41:28.40

おまけ

Ruby, Java, Kotlin 他
1 = 1.000 < 10 < 1_000 = 1000

C++
1 = 1.000 < 10 < 1'000 = 1000
　アンダースコアをユーザー定義リテラル用に使っていたため

**デフォルトの名無しさん** · 2019/02/10(日) 18:10:30.74

そうか。じゃあグループセパレータを自分でカンマにセットしとかないと確実にカンマにはならないってことだな。

**デフォルトの名無しさん** · 2019/02/12(火) 05:43:38.35

Java全然書いたことないんだけどJavaのこと調べてたらこの言語に辿り着いた
Android公式言語とのことだけど、Androidアプリ開発以外の用途でJavaでやることもKotlinで出来るの？
もうJavaじゃなくてKotlin学んだほうがいい？
PythonとCしか書けない

**デフォルトの名無しさん** · 2019/02/12(火) 05:56:17.28

おわこん

**デフォルトの名無しさん** · 2019/02/12(火) 06:15:00.09

>>256
> JavaでやることもKotlinで出来るの？
できる。
> もうJavaじゃなくてKotlin学んだほうがいい？
JavaをやってからKotlinを学んだほうがいいけど、PythonとCができるなら、Kotlinから始めるのもありかも。

**デフォルトの名無しさん** · 2019/02/12(火) 08:01:07.40

>>256
APIリファレンス読むためにJavaのメソッド定義の構文を知っておくくらいで
Kotlinをメインに学んで良いと思うよ

成果物はJavaクラスファイル（※）なので出来ることは同じ
やろうと思えば1プロジェクトで混在しても普通にお互い呼べる

※Kotlin/JS, Kotin/Nativeとかの別形式もある

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

Scalaってどこいったん？

**デフォルトの名無しさん** · 2019/02/12(火) 14:31:00.63

Scalaは衰退しました

**デフォルトの名無しさん** · 2019/02/12(火) 15:06:09.44

使われてるところでは安定して使われてるみたい
拡大は止まったと思うけど

**デフォルトの名無しさん** · 2019/02/12(火) 20:08:57.00

scala組がkotlinに合流してくれたら覇権言語狙えるんやないか。
ということは、kotlinに必要なのはお洒落感？

**デフォルトの名無しさん** · 2019/02/12(火) 20:28:23.96

Scalaやってた意識高い系はみんなとっくにRustへ移行した

**デフォルトの名無しさん** · 2019/02/12(火) 21:03:35.46

>>256
それをJavaで作る必要があって、Javaで作ることを誰かに強制されているなら、それはJavaで作る
それをJavaで作る必要があって、Javaで作ることを誰にも強制されてないなら、それはKotlinで作る
それをJavaで作る必要がないなら、JavaでもKotlinでも作らない。他の言語を使う。めんどくさいじゃん

**デフォルトの名無しさん** · 2019/02/13(水) 09:04:09.69

ちょっと前はScala民がやたらKotlinを叩いてたけど、それももう見なくなったな

**デフォルトの名無しさん** · 2019/02/13(水) 13:18:45.36

現在はKotlin教とGo教の戦い？

**デフォルトの名無しさん** · 2019/02/13(水) 14:52:01.31

言語に自己肯定感を求める人は無難無個性言語Kotlinや低脳言語Goでは欲求が満たされないことを知りRustへ行った

**デフォルトの名無しさん** · 2019/02/13(水) 18:00:16.64

>>267
両方とも同時期に流行り始めたけど、用途的にあんまり競合してない希ガス

**デフォルトの名無しさん** · 2019/02/13(水) 19:36:21.84

おれもどうせならオシャレな言語がいいんだがスマホのアプリ作りたいならkotlinしかないよね？

**デフォルトの名無しさん** · 2019/02/13(水) 20:05:24.56

つDart

**デフォルトの名無しさん** · 2019/02/13(水) 20:07:39.49

dartがオシャレ…？

**デフォルトの名無しさん** · 2019/02/13(水) 20:43:21.05

flutter普及への最大の障害がDartだよな

**デフォルトの名無しさん** · 2019/02/13(水) 22:02:27.55

>>270
あなたの言うスマホアプリがゲームだけであるなら、Unityを使うことができる
これはWindowsマシンでAndroidゲームもiPhoneゲームも作ることができる（iPhoneの実機はあったほうがいいけど）

あなたの言うスマホアプリがiPhoneアプリであるなら開発マシンはMacでiPhoneは必須、個人なら言語は公式のSwift（就職する気なら今からObjective-Cに手を出して時間不足で爆死しよう）
Windowsマシンでも作成だけはできるがユーザーの「よくわからないけど動きません」に対して「よくわからないので直せません」と答えるしかなくなる（所詮エミュ）

あなたの言うスマホアプリがAndroidアプリである場合のみ、Windows（別にLinuxでもMacでもいいけど）でKotlinを使うことで作ることができる
ゲームを作ることももちろんできるが、基本的に全部自力での実装になるので序盤から山が高いし若干面倒くさい（後々勉強にはなるが）
手間と面倒だけ考えるならUnityとC#でやったほうがサンプルも解説も書籍もライブラリも山ほどあるし楽は楽、詰まってもだいたい先人が解いてるのでイージー。タイムイズマネー

もちろん他の言語で作ることもできて、たとえばもしあなたにC++の知識があるならC++でゴリゴリ作ることもできるんだけど、そんな人はこんなこと聞かないよね
えっXamarin？ごめーん忘れてた。「もしあなたがいっぱしのWindowsアプリケーション開発者であるなら」その知識とXamarinとC#と.NETを使うことでAndroid/iPhoneアプリ開発ができるよ

**デフォルトの名無しさん** · 2019/02/13(水) 23:07:05.67

>>268
それぞれちょっとずつカジってみたんだけどScalaの人がRustでファイナルアンサーするとは思えんかった。
RustはWebやるにはキツかったからまだどっかで彷徨ってるのかも。

>>269
現在のGoの用途→Webサーバ、Nativeアプリ
JetBrainsが思惑ってるKotlin, Kotlin/Nativeの用途→ Webサーバ, Nativeアプリ、というか何だか色々。
うまく行けばこれから競合していくんかな。

**デフォルトの名無しさん** · 2019/02/14(木) 06:44:05.14

>>275
Goもこちょりんもどちらも使うけど、一口にWEBサーバーと言っても得意なジャンルが違うな、少なくとも現時点では。
今後GoにSpringみたいなフルスタックのフレームワークが出てきたら思いっきり競合するかもね。

**デフォルトの名無しさん** · 2019/02/14(木) 09:29:59.23

合体させて Gotlin

**デフォルトの名無しさん** · 2019/02/14(木) 11:59:45.42

実際、Goの運用性とKotlinの生産性が合わさればわりと最強だと思う
Kotlin nativeみたいにKotlinのエコシステムを再現する方向だとどうしてもJVMをエミュレーションするような感じになって歪みが出る
逆にGoの文法をKotlinに寄せるほうが筋がいい

**デフォルトの名無しさん** · 2019/02/14(木) 13:00:16.45

歪みってどういうの？

**デフォルトの名無しさん** · 2019/02/14(木) 15:39:16.51

>>279
逆に聞くが、仮に完全にゼロベースで Kotlin native を開発してたとして、今と同じ言語仕様になったと思う?
特定の処理系を前提にして作られて普及した言語が他へ移植されて成功した例はない

**デフォルトの名無しさん** · 2019/02/14(木) 17:06:41.26

具体的な支障は無いってことでいいの？

**デフォルトの名無しさん** · 2019/02/14(木) 19:02:02.86

横からだけどjvmの負の特性も引き継ぎやすいってことかと思った。
起動が遅いとか、メモリ食うとか。

**デフォルトの名無しさん** · 2019/02/14(木) 21:20:40.39

起動が遅い事は遅いが昔からすれば今時のPCは速いね。
Windows95や98の頃なんかどうしてくれようというほど遅かったからなあ。
昔はみんな忍耐力強かったよなあ。

**デフォルトの名無しさん** · 2019/02/15(金) 05:29:24.84

>>280
確かにJVMのジェネリクス型消去がなかったら、reifiedみたいな複雑怪奇な仕様はなかったろうな。

移植については大抵は非公式移植事例だから、楽観はできないけど、まだ決めつけるには速いかと。
Scala.NET...うっ、頭が...

**デフォルトの名無しさん** · 2019/02/15(金) 08:15:53.64

新しいところでいうと、inline classなんか普通にユーザー定義の値型があれば全く必要ないな
unsigned integerもだいぶ無理矢理感が酷い
Kotlin native特有の話だと、C interopのための構造体のマッピングとか超無理矢理で最高にエイリアン感ある

**デフォルトの名無しさん** · 2019/02/15(金) 09:58:26.61

iPhoneにおけるSwiftの立ち位置＝AndroidにおけるKotlinの立ち位置

**デフォルトの名無しさん** · 2019/02/15(金) 10:48:24.63

あ、はい

**デフォルトの名無しさん** · 2019/02/15(金) 10:54:34.88

inline class = ユーザー定義の値型 = C#のstruct
そして最適化が十分ならそれらが必要無いことをRustとGoが証明してる
ヒープかスタックかは自動で判断される

**デフォルトの名無しさん** · 2019/02/15(金) 10:56:38.52

特定のVM前提で設計されて他へ移植されて成功した言語の例としてはAndroidのJava/KotlinやUnityのC#、Node.jsのJSあたりが該当すると言えなくもないけど、
それらは言語の移植ではなくVMごと移植だからなあ
基本的にVM言語の他への移植は成功しないよ

**デフォルトの名無しさん** · 2019/02/15(金) 11:07:58.47

AndroidやC#のいくつかのターゲットはAOTで
それらも「VMごと」に含むなら
LLVMを使うC++(Clang)も同じ扱いになる

**デフォルトの名無しさん** · 2019/02/15(金) 15:42:23.69

最近、kotlin触ってるけど、C#より学習コストが高いです
それで、C#erがkotlinに切り替える際に、意識すべき点って何かありますか？

**デフォルトの名無しさん** · 2019/02/15(金) 16:15:05.26

>>291
Javaの制限を理解すること
JVMは.NETのCLRに比べて機能的にはずっとショボくて、その制限に由来する奇妙な仕様がKotlinには数多く存在する
Javaに慣れてないとそのあたりは直感的に理解しづらい

**デフォルトの名無しさん** · 2019/02/15(金) 17:24:02.62

>>292さんの言ってる「Javaの制限」て例えばどんなこと？

**デフォルトの名無しさん** · 2019/02/15(金) 17:29:59.00

>>291
プログラム言語全般に言えることだけど
各構文を概要程度でも良いので、まずは一通り知ること

C#知ってて引っ掛かりそうな箇所として思いついたのは
・最後のパラメータがラムダの場合は丸括弧の後に書ける
　他に引数が無い場合は丸括弧も省略出来る
　(GroovyやSwiftのTrailing Closureと同じ)
・レシーバ付きラムダ
・inlineラムダ
・returnはfunから抜けるもので、ラムダから抜けるものではない
・IterableとSequenceは遅延評価
・コンパイルでジェネリクス情報は消える
・suspendは同期(await)が基本動作

**デフォルトの名無しさん** · 2019/02/15(金) 17:31:30.02

>>294脱字
×　・IterableとSequenceは遅延評価
〇　・Iterableと違ってSequenceは遅延評価

**デフォルトの名無しさん** · 2019/02/15(金) 22:07:22.01

kotlin勉強中なんだけど、結局のところjetbrainsがscala推さずにkotlin出したのは何でなの？
商業的に旨みがあるから？それともbetter javaとしてのscalaに見切りをつけたから？それとも？

**デフォルトの名無しさん** · 2019/02/15(金) 22:33:17.97

コンセプトの違い

**デフォルトの名無しさん** · 2019/02/15(金) 23:10:54.49

>>296
自分でScalaやってみればすぐにわかるよ
まともな感性があれば、あんなものが普及するわけがないことは明らかだった
JetBrainsもIDEを作る会社として自由にできる言語が一つは欲しかったというのはもちろんあっただろうけどね

**デフォルトの名無しさん** · 2019/02/15(金) 23:25:58.35

>>296
なるほど。Scalaのこれ以上の普及は難しいという判断があった(だろう)ってことなら納得。

**デフォルトの名無しさん** · 2019/02/15(金) 23:41:27.98

まちがえた。上は >>298
雑念を捨ててkotlin邁進してきます

**デフォルトの名無しさん** · 2019/02/16(土) 15:17:06.30

Scalaは言語マニアのオナニー言語だよなあ

**デフォルトの名無しさん** · 2019/02/16(土) 17:00:29.98

なんだかんだでscalaは採用企業多いけどね
kotlinもtwitterとかpaypalみたいな大手で使ってくれると宣伝になるんだけど

**デフォルトの名無しさん** · 2019/02/16(土) 17:31:16.36

日本のYahooがKotlin採用したくらいではさざなみさえ立たないか

**デフォルトの名無しさん** · 2019/02/17(日) 08:06:13.22

Scalaの方が出たのが早かったし意識高い系(笑)が挙って使ったから
でもそれを維持出来る新人たちが居ないのが現状
Scalaは端的に複雑で難解な部分が多い
2018年後半以降Scalaの記事殆ど見かけないやろ？
コップ本(笑)

**デフォルトの名無しさん** · 2019/02/17(日) 11:12:07.88

Androidの公式言語がScalaになる世界線もあり得たと思うけど、そうならなかったってことはつまりそういうこと

**デフォルトの名無しさん** · 2019/02/17(日) 11:17:52.27

一年くらいScalaで仕事してたしまあ慣れればどうってことはないと思うけど、ScalaとKotlinで選べるとしたらよほどの変人以外はKotlin選ぶと思うわw

**デフォルトの名無しさん** · 2019/02/17(日) 11:30:47.79

ScalaはHaskellを意識しすぎ
簡潔に書きたいだけならKotlinかClosureの方がいい

**デフォルトの名無しさん** · 2019/02/17(日) 11:57:32.09

Scalaのコンセプトは、スケーラビリティの理論実証
　オブジェクト指向と関数型の統合によりスケーラビリティが実現すると考え
　小規模から大規模まで同じ書き方/考え方で記述出来るように設計されている
　出自はコンピュータサイエンスの学者

Kotlinのコンセプトは、より良い産業向け言語
　Javaからの移行や相互運用、コンパイル速度、使い勝手について
　「仕事の道具」であることを意識して設計されている
　出自はIDE製品を提供する企業

**デフォルトの名無しさん** · 2019/02/17(日) 12:47:22.79

どっちも我田引水なだけやん

**デフォルトの名無しさん** · 2019/02/17(日) 13:01:53.97

設計思想と既存資産があるから多様に派生し人が集まる
C, C++, Objective-Cが合流しないのも同様
それを我田引水と評することに何の意味もない

**デフォルトの名無しさん** · 2019/02/17(日) 15:40:49.55

>>310
ｸｽｸｽ

**デフォルトの名無しさん** · 2019/02/17(日) 15:53:56.04

scalaでAndroidのプラグインとかあった気がする
我田引水ってなんか意味わからんな

**デフォルトの名無しさん** · 2019/02/17(日) 23:16:27.59

>>309
むしろ我田引水でない言語なんかあるんだろうか。
強いて言うならgrassとかwwww

**デフォルトの名無しさん** · 2019/02/18(月) 02:04:27.28

我田引水ってのは共用物について不正に占有したり自らの便宜を図ったりするような場合を言う
自己アピールや競争を含めた利己的な行動すべてを我田引水と揶揄するのは農耕民族的な発想が過ぎる
そういうのは道徳というより村八分や出る杭が打たれるのを恐れる面が強くイノベーションの足枷

**デフォルトの名無しさん** · 2019/02/18(月) 11:11:01.50

もはや何のスレだか分からない

**デフォルトの名無しさん** · 2019/02/18(月) 13:20:37.82

道徳説教スレ

**デフォルトの名無しさん** · 2019/02/18(月) 13:34:09.52

我田引水スレ

**デフォルトの名無しさん** · 2019/02/18(月) 19:19:37.69

後ろ盾がjetbrainsっていうのはどうなんやろ。
大手と比べてどんなメリットデメリットあると思う？

**デフォルトの名無しさん** · 2019/02/18(月) 19:29:55.81

てか、我田引水ってどういう意味だっけwwww

**デフォルトの名無しさん** · 2019/02/18(月) 19:50:06.12

>>318
googleと仲いいしintellijシリーズが売れなくなるとも思えんし安泰なんじゃ？

**デフォルトの名無しさん** · 2019/02/18(月) 20:44:26.76

スカラ信者がまた荒らしてるな

**デフォルトの名無しさん** · 2019/02/18(月) 21:57:58.91

>>318
大手と比べるとメリットはない。後ろ盾のない言語よりはいい。
IDEの開発会社という意味では、言語の普及がIDEの売上に直結する可能性があるので
Oracleみたいに独立不採算だからマネタイズに走るという思考にはなりにくいが、
絶対的なものではない。

**デフォルトの名無しさん** · 2019/02/18(月) 22:33:30.93

IDEの開発会社であるが故のリスクもあるけどね
VSCodeのような強力な他の開発ツールがKotlinサポートにおいてIntelliJを超えてしまってユーザーが流れた場合、
JetBrainsにとってKotlinの開発を続けることにもはや意味がなくなってしまう

**デフォルトの名無しさん** · 2019/02/18(月) 22:58:18.56

後ろ盾最強はやっぱrust？

**デフォルトの名無しさん** · 2019/02/18(月) 23:02:22.94

Goでぇす！

**デフォルトの名無しさん** · 2019/02/19(火) 08:14:46.86

後ろ盾の強さでいったらGoだべ
あれだけの巨大企業がついてる上に、開発も独裁せずに異常なまでにオープンであることを重視してるし

**デフォルトの名無しさん** · 2019/02/19(火) 09:12:17.39

>>326
最強のSEO力でそう見せてるだけだぞ
それでもDartに対するヘイトは抑えきれなかったようだが

**デフォルトの名無しさん** · 2019/02/19(火) 09:33:24.18

>>327
直接Go開発周りのディスカッションを見てきての感想だから、SEOも何も関係ねーよ
英語が読めるなら自分の目で確かめることをお勧めする
あれはある意味理想的なOSS開発の形かもしれない

**デフォルトの名無しさん** · 2019/02/19(火) 13:20:28.53

goは好きじゃないが>>326の言うことには同意
でもDartちゃんは駄目だから早く眠らせてあげて…

**デフォルトの名無しさん** · 2019/02/19(火) 14:47:06.45

FlutterがDartじゃなければ一気に覇権を取るまでありえただろうにな

**デフォルトの名無しさん** · 2019/02/20(水) 14:22:13.38

Android次期OSの開発言語がDartになるみたいな話どうなったん

**デフォルトの名無しさん** · 2019/02/20(水) 15:43:28.44

夢のOSなので夢で終わる

**デフォルトの名無しさん** · 2019/02/20(水) 15:54:05.41

ダー子

**デフォルトの名無しさん** · 2019/02/20(水) 16:09:47.41

>>331
https://9to5google.com/2019/01/02/android-runtime-app-support-fuchsia/

つまりJavaもKotlin/JVMも使える

**デフォルトの名無しさん** · 2019/02/20(水) 17:27:44.53

Dream → Nightmare

**デフォルトの名無しさん** · 2019/02/20(水) 19:05:59.81

夢は見るもの
目標は叶えるもの

**デフォルトの名無しさん** · 2019/02/20(水) 19:45:33.26

夢を見る島

**デフォルトの名無しさん** · 2019/02/20(水) 21:47:37.37

>>337
小鳥ん島
>>336
揚げ足鳥で悪いが、目標は達成するものだと思う。