Kotlin 5

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

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

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

**デフォルトの名無しさん** · 2019/02/01(金) 21:35:19.79

Infoseek と Exite もよろしく

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

ビンガビリティ
強そう

**デフォルトの名無しさん** · 2019/02/02(土) 12:34:49.40

Anko使ってる？

**デフォルトの名無しさん** · 2019/02/02(土) 20:52:18.84

Unko？

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

大体レイアウトとロジックが混在してるのは良くないねってことで
レイアウトはxnlファイルに分離するようにしたんだと思うんだけど
何でAnkoってまたレイアウトとロジックを混在させるようなことしてんの
時代に逆行してるだけでは

**デフォルトの名無しさん** · 2019/02/02(土) 21:38:35.91

>>191
アーキテクチャ上重要なのはビューとロジックの分離
一方で、レイアウトとロジックの分離というのはビューに閉じた話であり、
マークアップエンジニア(笑)とフロントエンドエンジニア(笑)の分業をしやすくするだけのものでしかない
フロントエンドエンジニアが十分有能でマークアップエンジニア(笑)の仕事も自分でこなせるなら分ける必要は全く無い

**デフォルトの名無しさん** · 2019/02/02(土) 21:43:01.16

流行りのキーワード並べてドヤ顔

**デフォルトの名無しさん** · 2019/02/03(日) 07:45:41.73

レイアウトの中にロジックがダラダラ書かれたら見通し悪くてUnkoだけどそこは経験とコード規約とレビューで制御できる
適正なメソッド分割は主に人間の仕事であってライブラリーの責務ではない
XMLの欠点とDSLの利点はGitHubのWikiで説明されてる
設計開発にイチイチXML使うのは微妙じゃね？DSLとかいいよな！ってのは時流でもある
だから少なくとも時代に逆行しているだけということはない

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

いーや、Ankoは糞

**デフォルトの名無しさん** · 2019/02/03(日) 12:29:21.29

anko味のunko

**デフォルトの名無しさん** · 2019/02/03(日) 12:36:56.63

unko味のankoとanko味のunko

**デフォルトの名無しさん** · 2019/02/03(日) 15:59:31.11

あんこ餅食いたくなってきたからスーパー行ってくる

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

Anko程の糞はない

**デフォルトの名無しさん** · 2019/02/03(日) 21:27:31.59

気になってるんやがkotlin nativeが完成したらgoは駆逐できるんやろか。
それともシングルバイナリやら並列化でgoのメリット残るんやろか。

**デフォルトの名無しさん** · 2019/02/03(日) 21:58:54.28

>>200
現実的に考えると、全く話題にもならずにひっそり消える可能性が一番高いよ
kotlin nativeが

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

マジかあ。Scala状態は残念やのー。
俺にキラーアプリ作れるような力があればなぁ。。

**デフォルトの名無しさん** · 2019/02/03(日) 22:19:22.36

githubでkotlin-native使ってるプロジェクト探してみたけど、確かにあんまり盛り上がってる感じではないね。
今作ってるクソアプリが一段落ついたら何か作ってみよう。

**デフォルトの名無しさん** · 2019/02/03(日) 22:43:39.24

アプリよりFWだよな

**デフォルトの名無しさん** · 2019/02/03(日) 22:49:54.08

「オーケーグーグル、エロくて楽しいアプリ作って」でエロくて楽しいkotlin nativeアプリのソースが生成されるAIを作れば流行る

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

Kotlin/Native自体は現在進行中のSubstrate VMが出来上がるとやや辛い立ち位置になる

でもKotlin全体としては間接的にエコシステムが大きく強化されるし
Kotlin/Nativeから「Kotlin with Substrate VM」への移行は
性質的に割と容易なものになる期待もあるから使っても大丈夫だと思う

補足だけど Substrate VM はOracle主導のオープンソースプロジェクトGraalの一部で
JavaバイトコードをAOTするもの、
これによりjavaパッケージが使えるKotlin/JVMのままネイティブ化出来るようになる
Linux向けは出来ていてWindowsやiOSなどはまだこれから

**デフォルトの名無しさん** · 2019/02/03(日) 23:43:07.23

ちなみにAndroid Runtimeも同様にAOTしている
こっちはJDKをGoogleが好きなように取捨選択してるのでJava互換性テストは通らない

Android Runtimeの技術を利用してJava(Kotlin/JVM含む)からiOS用のネイティブを生成してるのが
RoboVMやMulti-OS Engine

Substrate VMはこれら(Kotlin/Native含む)に対して
後追いだけどOpenJDKフルサポートのAOT、ということになる
出来上がるまでまだかなりの時間が掛かりそうだけど

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

結局Java版Xamarinを作ろうとしてるだけだな
目的不在で技術だけが独り歩きしてる感すごい

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

>>200
無理だね。というかそもそもGoの得意分野とKotlin(native)の得意分野がかぶってないから現時点であまり競合してない

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

>>209
そうなんか。kotlin nativeの得意分野って何なんや？

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

>>208
Graalの主目的はHotSpotのJITコンパイラ(C2)の刷新

20年以上前に設計され、修正が積み上げられたC++コードなので
保守し辛く新技術の導入も困難とのこと

JITコンパイラ(Graal本体)はインタプリタやAOTとも関連が深く、
それらも考慮したエコシステムとしてサブプロジェクトを内包してる
Truffle / Sulong / Substrate VM

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

>>210
Kotlinの対応プラットフォームを広げるものだから
強いて言うならKotlin/JVMと同じく通常アプリでは

Goは並列処理や低レイテンシGC(リアルタイム用途)など
システム寄りが得意

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

Kotlin nativeは悪く言えば現状では得意分野などはっきり言って存在しないし、良く言えばこれから何に使ってもいいとも言える
Goの代わりに使うことももちろん可能

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

Ktor以上に急上昇してるJavalinってFWお前ら使ってる？

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

使ってないし知らない

**デフォルトの名無しさん** · 2019/02/05(火) 06:33:03.96

>>214
使ったら竜騎士とかにクラスチェンジできるかな

**デフォルトの名無しさん** · 2019/02/05(火) 06:59:09.94

マジで聞いたことすらなかった
悪くなさそうだけど、英語も含めて情報が少なすぎて趣味以外には使えないかな

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

軽く調べた感じだからよく分かってないんだけど、これ例えばSparkと比べて何が良いの？

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

Kotlin を今のプロジェクトに使いたいけど、eclipse とか言う糞IDE使ってて相性悪すぎて笑えない
SWT とか JFace とかでUI作ってるから、eclipse を外すのは無理だし

**デフォルトの名無しさん** · 2019/02/05(火) 09:40:26.01

ググると槍投げ画像が沢山出てくるな・・・

**デフォルトの名無しさん** · 2019/02/05(火) 10:08:44.38

>>218
https://javalin.io/comparisons/sparkjava

**デフォルトの名無しさん** · 2019/02/05(火) 10:17:58.97

>>216
宇宙刑事っぽさもあるし、使うと風呂釜が綺麗になって身体が芯からあたたまりそうな感じもする

**デフォルトの名無しさん** · 2019/02/05(火) 10:32:30.10

>>219
UI作るときとことりん書く時でIDE使い分ければいいんでないの？

**デフォルトの名無しさん** · 2019/02/05(火) 10:32:56.86

>>221
すまん、それ気付かなかった。
後で見てみるわ

**デフォルトの名無しさん** · 2019/02/05(火) 11:21:10.88

>>216
ガリで

**デフォルトの名無しさん** · 2019/02/05(火) 11:27:24.21

宇宙刑事 Javalin

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

やっぱJavanだろ

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

Javalinの半分はやさしさで出来ています。

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

リン付ければなんでも可愛らしくなると思いやがってそうはいかねえぞべらんめえ ←江戸っ子

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

> ←江戸っ子
ウザっ

**デフォルトの名無しさん** · 2019/02/05(火) 15:25:14.63

うざりん

**デフォルトの名無しさん** · 2019/02/06(水) 19:35:52.56

上でシステム系にはGoみたいに書かれてるんだけど、kotlin/nativeはGoより遅いのかな。
現状ではそうなのかも知れないけど、最終的にはGoと同等の速度が出せるポテンシャル(仕組み)だと
思ってるんだけどそうでもないの？

**デフォルトの名無しさん** · 2019/02/06(水) 19:49:42.95

goに勝つのは流石に無理じゃ？

**デフォルトの名無しさん** · 2019/02/06(水) 20:35:25.96

Goに比べたら遥かに複雑怪奇な言語だから最適化は不利だろう
JVMの挙動をエミュレーションするための無駄な処理は少なからず必要だろうし

**デフォルトの名無しさん** · 2019/02/07(木) 00:37:31.07

1 c
2 go
5 jvm
10 script系

3くらいいける？

**デフォルトの名無しさん** · 2019/02/07(木) 05:59:54.51

>>232
構造的に無理
Goは構造をシンプルに保って高速軽量を維持するために言語仕様を必要最低限にしてるから、
書く人間の使いやすさを追求してるこちょりんとは根本的に目指してるものからして違う

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

>>235
いけると思う
JIT後はJVMが1～2だけど

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

なんでRustはあんなに速いん？言語の抽象度は同じくらいやろ？

**デフォルトの名無しさん** · 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

あ、はい