Kotlin 5

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

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

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

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

sunが震え声で
ハードの進化でJVMのパフォーマンスは向上していくから…
って言ってから何年経ったのか

**デフォルトの名無しさん** · 2019/06/02(日) 12:13:33.66

PHPで作ってたけどパフォーマンスが出なくなって来たからJavaで作り直す、みたいなのはよく聞くな
同じ理由で昔はRailsからJavaってのもあったけど最近のRailsは速いからあまり聞かなくなった

**デフォルトの名無しさん** · 2019/06/02(日) 14:27:04.47

Rails ができれば、コピーのCakePHP も出来る

違う言語だけど

**デフォルトの名無しさん** · 2019/06/02(日) 14:47:02.52

Rubyキチ、無視しろ。

**デフォルトの名無しさん** · 2019/06/02(日) 14:52:37.88

php8()

**デフォルトの名無しさん** · 2019/06/02(日) 15:29:19.09

新規でサーバ側でkotlinで作ってもらったけど
少数派なのか。
まあ、何ができるかが大事だからいいけど、流行に左右されるのは厳しいね。

**デフォルトの名無しさん** · 2019/06/02(日) 16:54:37.31

>>841
20年ぐらい？
まあ確かにあのWindows95だの98だので動かしていた時よりは速くなったけどね。

**デフォルトの名無しさん** · 2019/06/02(日) 21:44:03.80

結構Java嫌いな人多いんだね。自分もJavaは好きじゃないけど。

>>840
Javaが検討される規模のWEBサービス作る時にJVM以外の選択肢って例えば何かあるのかな？

>>841
Javaの出始めと比べたら劇的に進化してSunの言う通りになったと思うけどな。
Java離脱組もパフォーマンスじゃなくて開発効率やサービスの拡張性を気にしてる。

>>846
少数派なのはそうなんだけど、依頼側から見たサーバーサイドkotlinのデメリットは
・現状では開発者が少ない=人が集まらないことによる遅延、開発者単価
・実績がない=未知の何かが起こるかも
なのでローンチ出来てる時点でデメリットは乗り越えているし、
Android界隈では確固たる位置にいるからこの先メンテ人材が見つからない心配もない。(←ここが流行に左右されて困るポイント)
悪くない選択だったと思うんだけど

**デフォルトの名無しさん** · 2019/06/03(月) 23:56:34.84

JVMの性能は実行時最適化が強みだから
ベンチマーク系は不利
巨大なプログラムで長時間の動作において有利なはず
にもかかわらずベンチマークでもそこそこ速いんだからすごいのでは

**デフォルトの名無しさん** · 2019/06/04(火) 00:08:19.43

いや実行時最適化は繰り返し実行される処理に対して効くからベンチマークには強いぞ
立ち上がりの遅さとか、ベンチマークに現れない体感的な部分がJVMは遅い
事実上サーバー専用だから仕方ないが

**デフォルトの名無しさん** · 2019/06/04(火) 02:28:23.05

JVMはガーベッジコレクションでスローダウンするから未だに使い物にならない。
一番大事な時に直撃で機会損失が億いくと違約金も凄まじかったぜ。

**デフォルトの名無しさん** · 2019/06/04(火) 06:40:04.13

果てしなく嘘くさいな
シビアなシステムでどれだけ使われてると思ってるんだ

**デフォルトの名無しさん** · 2019/06/04(火) 07:41:14.05

10年以上前からあるコンカレントGCすら知らないような会社なんだろう

**デフォルトの名無しさん** · 2019/06/04(火) 08:08:31.64

業務用Javaに関しては新機能が使われずなおかつアプデなしで10年経過とか普通にあるからな
それはそれでもいいから対外的にJava語るなって話なんだが

**デフォルトの名無しさん** · 2019/06/04(火) 08:20:13.77

例のみずほのサグラダファミリアもJava1.5という噂を聞いたけどマジなんかな

**デフォルトの名無しさん** · 2019/06/04(火) 10:17:08.75

ネイティブでgc使わないようなコードも出せるようになればなんとかなりそうな気もするが、そうするとライブラリもそれ用のを使わないとダメか。

**デフォルトの名無しさん** · 2019/06/04(火) 11:48:04.89

graalvmでできるぞ

**デフォルトの名無しさん** · 2019/06/04(火) 12:44:23.82

それ回収しないやつじゃないですかね

**デフォルトの名無しさん** · 2019/06/04(火) 18:10:17.62

JVMが使い物にならないという人が何を使っているのかとても気になる

**デフォルトの名無しさん** · 2019/06/04(火) 18:49:03.68

JVM入りの指輪使ってます！

**デフォルトの名無しさん** · 2019/06/04(火) 19:32:40.19

jvmの引数でもGCのラグを解消できるし
最新のZGCというのも出てきた

**デフォルトの名無しさん** · 2019/06/04(火) 23:57:50.92

JVMというかspring fwの起動が糞遅いのは分かる
2.0になって少しましになったけど…

**デフォルトの名無しさん** · 2019/06/05(水) 01:12:19.63

springってそんな遅いっけ？

**デフォルトの名無しさん** · 2019/06/05(水) 10:00:02.20

気のせいかわからんがKotlinでspringやると遅いような気がする

**デフォルトの名無しさん** · 2019/06/05(水) 10:01:33.26

Ktor流行って欲しい

**デフォルトの名無しさん** · 2019/06/05(水) 10:13:38.35

>>876
ktorはマイクロサービス向き
kotlin/jvmはモノリシック向き
kotlin nativeが流行らないと無理やと思うで

**デフォルトの名無しさん** · 2019/06/05(水) 13:28:31.33

>>864
コンパイル時間は長いと思うけど、アプリ本体は変わらん。
というかそもそもspring本体はJavaだし。

**デフォルトの名無しさん** · 2019/06/05(水) 19:11:23.87

>>866
Ktorをその並びで並べるのはちょっと違うと思う。

**デフォルトの名無しさん** · 2019/06/05(水) 21:56:16.86

>>868
kotlin/jvmはJava代替でSIerによるフルスタックFW＆モノリシック開発が向いている
kotlin/nativeはGo代替を目指していてWeb系企業のマイクロサービスが向いている
kotlin/jvm＋ktorではGOに勝てるユースケースが無いので
ktor流行にはkotlin/nativeの流行も必須というのが自分の主張。
まあ異論はあると思う。ちなみにkotlin/nativeは応援してるしktorも流行ってほしい

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

>>822
vim + quickrunで動くよ！
kotlinc, javaなんてコマンドを打つことはしない。

**デフォルトの名無しさん** · 2019/06/06(木) 05:38:57.73

>>869
言ってることは分からなくもない。
ただ視野が狭すぎるというか、そんな可能性を狭めなくていいと思う。

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

そもそもKtorってJVM、というかServletに依存してね

**デフォルトの名無しさん** · 2019/06/06(木) 09:26:51.24

依存はしてなくね

**デフォルトの名無しさん** · 2019/06/06(木) 10:59:43.79

次のリリースでkotlin/nativeのbuild時間が改善されそう
リリースいつなんだろ。。

**デフォルトの名無しさん** · 2019/06/06(木) 12:47:51.63

利根川さんにでも聞け

**デフォルトの名無しさん** · 2019/06/06(木) 20:06:45.07

kotlin/nativeはGraal（AOT）に勝てるかどうかすら怪しいのに、夢見過ぎだろ。

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

ktsって誰も使ってなさそう

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

Gradleで使う

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

>>876
AArch64の対応が進んではいるもののGraalがiOSに対応するのは当分先
Kotlin/Native側も資産(ライブラリ等)不足やパフォーマンスの課題があるけどな

**デフォルトの名無しさん** · 2019/06/07(金) 08:44:09.41

>>879の補足

Graal側はAArch64/Linux対応が完成してからiOS対応をやるかどうか検討するとのこと
https://github.com/oracle/graal/issues/373#issuecomment-454697157

まだAArch64/Linux整備中の段階
https://github.com/oracle/graal/commits?author=sanzinger&;since=2019-05-15&until=2019-06-07

iPhone/iPadのチップ : A10～A12X : ARMv8ベース
ARMv8の64ビットモードがAArch64

**デフォルトの名無しさん** · 2019/06/07(金) 16:14:27.25

kotlin/nativeのメインターゲットはiOS開発なんだろうと思う。

**デフォルトの名無しさん** · 2019/06/07(金) 16:40:27.70

普通に考えりゃそうだわな

**デフォルトの名無しさん** · 2019/06/07(金) 16:53:00.43

Swiftネイティブでいいじゃん、他にはUnityもあるし。
入り込む余地ないでしょ。

**デフォルトの名無しさん** · 2019/06/07(金) 19:12:00.19

釣り針は大きすぎちゃいかんのだぞ

**デフォルトの名無しさん** · 2019/06/09(日) 13:55:10.20

kotlin3大いいところ
・android標準という安心感（直ぐには廃れない）
・モダンな書き方ができる（arrowもあるし）
あと1つは？

**デフォルトの名無しさん** · 2019/06/09(日) 14:23:05.48

>>885
Listが基本immutableなことやnull安全はモダンに含まれるのかな?
標準という意味ではGradleの記述言語としてもサポートされているので、廃れにくいかなと思っている。
個人的にはDSLを3つ目として挙げたい。

**デフォルトの名無しさん** · 2019/06/09(日) 14:43:33.75

JVMで動く言語でJavaのライブラリそのまま使えるのが良い
これに関してはKotlinである必用はないのだが、その他の利点の上に更にこれがあるのが良い

**デフォルトの名無しさん** · 2019/06/09(日) 16:29:58.10

最新のjavaも随分進化したから、そこまでkotlinにこだわらねえ。
kotlinがjavaや.netみたく自前の最初からnull安全なクラスライブラリ備えてるなら別だけど。

**デフォルトの名無しさん** · 2019/06/09(日) 16:35:14.81

逆にあえてJavaを使う理由が特に思い当たらんからとりあえずKotlin使うわ

**デフォルトの名無しさん** · 2019/06/09(日) 19:10:48.79

Javaに新機能が追加されてもざんねんなJava部分が消えるわけではないので
可能であるなら最初からKotlinでやりたいかな

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

>>888
自分も最初はラムダもOptionalもあるからとそう思っていたけど、immutable programmingで行こうと思った時に、
Listがimmutableであることを保証する方法がないことに気づいてKotlinへの移住を思い切った。
immutable programmingはそれほど実現しなかったと反省しているが、
Kotlin/JSやbuild.gradle.ktsとかも出来たので後悔はしていない。

**デフォルトの名無しさん** · 2019/06/10(月) 10:30:03.83

うちももう新規追加は全部Kotlinだわ
だってJavaで書くメリットがマジで何もないんだもん

**デフォルトの名無しさん** · 2019/06/10(月) 10:36:29.16

javaで仕事してるやつ転職できなくなるぞ

**デフォルトの名無しさん** · 2019/06/10(月) 11:17:01.74

coboちゃんが入れ替わっただけの蛇腹は逝ってヨシ

**デフォルトの名無しさん** · 2019/06/10(月) 13:43:04.79

>>893
Java経験あるならKotlinなんてすぐ書けるから別に気にしないよ。
社員で雇うならどの言語で書いてたかはあんまり関係ない。

**デフォルトの名無しさん** · 2019/06/10(月) 23:11:05.39

kotlin書いてる人は何の仕事してるの？
やっぱandroid？

**デフォルトの名無しさん** · 2019/06/11(火) 05:51:34.27

サーバーサイド
7割SpringBoot3割sparkその他

**デフォルトの名無しさん** · 2019/06/11(火) 05:52:20.89

2年くらい前まで都市伝説レベルだったサーバーサイドKotlinも最近は勉強会でよく見かけるようになったんだ

**デフォルトの名無しさん** · 2019/06/11(火) 07:18:21.72

できればkotlinで作りたいって言われてサーバー側のプログラムを作ってもらった。
DBサーバは別で画面制御だけ。

自分でも勉強しようと思ってこのスレッドを見てるところ。

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

そっか。サーバサイドkotlin順調に普及してきてるんやね。ワイの周り以外では。
うらやましい！

**デフォルトの名無しさん** · 2019/06/11(火) 17:51:05.94

ほぼ0だったのがようやく1になったくらいで、まだまだマイナーだけどね

**デフォルトの名無しさん** · 2019/06/11(火) 19:13:42.98

分布が0から1になったら制圧完了じゃないか

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

kotlinは関数型も取り入れてるし
色々欲張り過ぎで言語仕様複雑化してるイメージがあるんだけど
実際使っててどうなの？
kotlinプロジェクトはコーディングスタイルが多様化しそう

**デフォルトの名無しさん** · 2019/06/13(木) 10:04:02.16

>>902
プログラマならまずそう思うわなｗ

**デフォルトの名無しさん** · 2019/06/13(木) 17:30:55.80

AndroidStudioやVSCode（mathiasfrohlichのKotlin Language機能拡張）で学習してるんだけどさ
どちらにしてもスペルミスは文字の色である程度わかるけど、文法が間違っててもその場で指摘してくれるわけじゃないのね
ある程度身につくまで文法間違いやを教えてくれるとありがたいんだけどそういうのはないのかな？

**デフォルトの名無しさん** · 2019/06/13(木) 17:36:07.23

文法間違いとはなんぞや
一応、実行できないくらい間違ってる場合はIntelliJ系だと「現時点で解釈不能でわけわかんないです」「これを書いてるつもりの場合は〇〇が必要です」って下に英語でちょろっと出る

**デフォルトの名無しさん** · 2019/06/13(木) 18:20:30.31

文法間違いは普通に赤線で指摘されるだろ

**デフォルトの名無しさん** · 2019/06/13(木) 19:19:37.31

kotlinのバグ発生率はJavaより低いですか？

**デフォルトの名無しさん** · 2019/06/13(木) 19:22:16.85

Javaのバグ発生率を教えてくれたら考えてあげてもいいよ
同じような式で計算して出すから

**デフォルトの名無しさん** · 2019/06/13(木) 19:32:38.72

>>905
具体的にどういうこと？
VSCodeは知らんけどIntelliJは大抵のミスは教えてくれると思うけど

**デフォルトの名無しさん** · 2019/06/13(木) 19:38:53.30

>>909
https://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf
>Java－0.01 (0.04)

Javaはいろいろな言語の中で平均的なバグ発生率のようです。
Kotlinはこの表にありません。

**デフォルトの名無しさん** · 2019/06/13(木) 19:43:19.29

Javaのバグ発生率は、
同じ領域で使われていると思われるC++,C#,Pythonと比べて最も低いです。
つまり、カーネルやデバドラやブラウザ系でなければJavaが一番優秀に思えます。
しかしKotlinはJavaを打ち倒すかもしれません。

**デフォルトの名無しさん** · 2019/06/13(木) 19:52:28.01

ぬるぽ
ぬるぽ
出まくるが
これはバグじゃないのか

**デフォルトの名無しさん** · 2019/06/13(木) 20:13:21.29

その比較研究はgithubのコミットに基づいているようなので
ほとんどのNPEは開発中に発生して修正済みでしょう。
最初からNPEを発生させないkotlinは、
むしろバグ発生率よりコーディングスピードで優れているかもしれません。

**デフォルトの名無しさん** · 2019/06/13(木) 20:40:07.05

その類の実証研究、大抵がJava対象だからKotlinだとどうなのかとかはまぁ分からんよね

**デフォルトの名無しさん** · 2019/06/13(木) 21:07:39.94

kotlinだとコードの行数が減るからjavaに比べて開発規模が小さかったと判断されてしまう

**デフォルトの名無しさん** · 2019/06/13(木) 23:03:46.90

>>913
仕様です。

**デフォルトの名無しさん** · 2019/06/14(金) 14:45:14.16

kotlinの言語仕様的にjavaよりバグり易そうな部分ってあるんかな？

**デフォルトの名無しさん** · 2019/06/14(金) 16:59:32.14

>>918
it や this が思ったものと違うものを指していたとか。

**デフォルトの名無しさん** · 2019/06/14(金) 18:14:32.08

確かに。let 周りで失敗してたことあったわ。あの辺はちょっと複雑になっちゃってる感あるね。

**デフォルトの名無しさん** · 2019/06/14(金) 18:28:44.08

KotlinはTypeScript, Swift, C#あたりの典型的なモダンCファミリーの範囲を超えてオリジナリティを出してきた部分については途端に微妙になる印象
当然っちゃ当然なんだが、天才的なものは感じないね

**デフォルトの名無しさん** · 2019/06/14(金) 20:01:34.38

Javaはエラーコードを強制される部分があって、プログラムの質の底上げがされてるんじゃないかな

**デフォルトの名無しさん** · 2019/06/14(金) 20:09:15.99

エラーコードを強制って例外処理のこと？

**デフォルトの名無しさん** · 2019/06/14(金) 20:23:59.56

なんかもう、わかんない人は無理に会話入ってこなくていいよ

**デフォルトの名無しさん** · 2019/06/14(金) 20:32:30.84

たぶんJavaにあってKotlinに無いものは無い
強いて言えばKotlinは関数型を採り入れて言語仕様が複雑化しつつあるし
Javaとの混在が可能だからごちゃごちゃしやすい
人によって書き方が変わりやすい
あとGSONとの連携で問題が生じやすいとかあったはず

**デフォルトの名無しさん** · 2019/06/14(金) 22:27:49.12

検査例外とラムダ式の相性の悪さは…

**デフォルトの名無しさん** · 2019/06/14(金) 22:47:52.21

検査例外ちゃんは皆に嫌われてるから…

投げられた例外を捌けるかどうかは呼び出し元の都合や要件に依るからcatchを強制されるのは好かん
て雲のジュウザが言ってた

**デフォルトの名無しさん** · 2019/06/14(金) 22:48:02.61

なんかQiitaにうまく書けるコードあったからちょっとカスタマイズして使ってる
https://qiita.com/q-ikawa/items/3f55089e9081e1a854bc

**デフォルトの名無しさん** · 2019/06/15(土) 04:17:10.27

マルチパラダイムな関数型言語はどう設計していくのが良いのか難しいと思う
OOPと関数型は根本的にミスマッチしてる

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

ポインタさえなければ、バグの出やすさは誤差の範囲じゃないかな

**デフォルトの名無しさん** · 2019/06/15(土) 07:54:39.96

Android kotlinで言えばMVVM一択だろ
悩むほど選択肢はない

**デフォルトの名無しさん** · 2019/06/15(土) 08:21:51.26

>>926
関数型とも相性が悪いが嫌わないで下さいませ

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

>>929
そうかな
イミュータブルオブジェクトと関数型は相性いいと思うけど

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

OOPそのものじゃなくてクラスでデータと関数が密結合してるのがいまいちという話は感じる

**デフォルトの名無しさん** · 2019/06/15(土) 10:29:34.05

本質的にはラムダ/クロージャでの束縛と変わらないと思うけどな

**デフォルトの名無しさん** · 2019/06/15(土) 10:40:41.99

>>909
有言実行な

**デフォルトの名無しさん** · 2019/06/15(土) 11:15:34.03

>>934
やはりdata Classだな

**デフォルトの名無しさん** · 2019/06/15(土) 11:31:49.90

これが f(g(immutableData))

こうなる immutableObject.g().f()

**デフォルトの名無しさん** · 2019/06/16(日) 15:28:56.20

>>918
わからない。なさそうな気がするが、KotlinにはKotlinなりの何かハマり易そうな部分があるのだろうな。弱点というかなんというか。

**デフォルトの名無しさん** · 2019/06/17(月) 09:40:35.09

宮迫の闇営業の件で何をトチ狂ったか、宮迫が出演する番組のスポンサーが
JetBrainsだと勘違いして開発者達にお問い合わせメール送りまくってるの草。
JetBrainsと宮迫は関係ねーよｗ