Kotlin 6

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

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

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

**デフォルトの名無しさん** · 2020/01/07(火) 13:06:26.78

レベルS　プラットフォームを問わずKotlinが広く利用される
レベルA　Kotlinを使うためにJavaプラットフォームが採用される
レベルB　KotlinによってJavaプラットフォームの採用障壁が下がる
レベルC　Kotlinによって既存のJava開発者の満足度が改善する

今のところせいぜいCだな

**デフォルトの名無しさん** · 2020/01/07(火) 20:56:09.81

Javaやってたら取っつきやすいみたいな扱いされてるけどC#の方が覚えやすくね？

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

kotlinってandroid専用言語という位置づけだと思っていいですか？
Webでも積極的に使われている言語ですか？

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

現状ではandroid専用。Java代替目指してる言語だからwebで使うポテンシャルはあるけど、その用途で流行ってるとは言い難い。

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

流行ってないだけで専用というわけでもない。

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

ま、しかし、みんながやってると自分もやるみたいなのはやはり日本人的な感じがするな。
保守的と言うか開拓精神がないというか。だから悪いということはないけどな。
自分が率先して使って自分を中心に世界中に広めるみたいなこともできるかも知れないのだが、そういう考えが最初から起こらないぐらい頭が固くなってガチガチに保守化していると。

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

「〇〇を作りたいのでKotlinを使う」の〇〇に入るのは非ゲームAndroidアプリ、ではある
現状これ以外で使うのは趣味とか修行とか苦行とかバカとかなんかそんな感じ
Kotlinは一応だいたいのものは作れるには作れるので、Kotlinで作ってみたいという情熱（または狭窄）で個人でいろんなもの作ること自体は別に止めない
手段が目的と化してるという点以外は問題はないからね
みんなあまりやらないことをやるという点では面白いはずだとは思うよ
どっすかRubyの二の舞

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

>>574
欧米の人って明確な目的があって、それに合う道具なら古いものも新しいものも使う印象
日本列島に生息するアーリーアダプタ猿はたいてい手段と目的が逆転していて、
新しいものを触っても「やってみた」で終わるからそれ以上の発展がない

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

有名人が使ってるから使おう・それが正しいみたいのがあるね

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

>>577
その後誰も使わなくなるものに手を出して半年で天を仰ぐ事例は事欠かない
だったらちょっとか有名人にも頼りたくなるというものだ

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

その、「失敗したらどうしよう・・失敗しないように安全パイを狙おう」ていう発想が日本人ていう話

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

自分が有名人になろうという発想もない。

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

まぁ結局はjavaなんだから、だったらjavaのままでいいじゃんで終わってそう。

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

webなんかどうでもいい
今やブラウザからよりもアプリからの方がインタネットアクセスしてる人多い
サーバー側処理もこれから firebase的なものが主流になって独自実装はなくなっていく
Android専用とは即ち最強ということ

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

え？

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

サーバーサイドがDB直結で済むようなアプリなんてミニゲームくらいだろ

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

firestoreってrate limitやIP banみたいなこと課金なしにできないの?
セキュリティルールで、他人のデータおもらしや、入力データ検証はできるけど。個人で使うとrate limitみたいのないと課金攻撃食らうのが怖い小心者の俺。

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

貧乏人のくせにうるせえな
ガキはオフラインでlampでもやってろ

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

サーバーエンジニアは時代遅れ

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

まあ、金払って押しつけるのが正しくはある
自社メールサーバーを運営するのが今や愚かな行為であるのと同じ

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

サーバーサイドは原始時代の技術

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

かといってサーバなしにはできない

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

クラウドもサーバだっつの

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

flutterきてるからもう色々諦めて、サーバーサイドkotlinに注力して欲しい。。

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

結局javaと同じ道筋を辿るのか。

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

クロスプラットフォームは全部糞
そもそもDartが糞
ちょうど今日はてぶでflutterの記事を読んだがやっぱりDartが糞
ttps://hachibeechan.hateblo.jp/entry/flutter-is-great-good-but-dart-is-dirt
結局サンプルアプリみたいな見た目のしょぼいごみアプリしか作れないのがオチ

**デフォルトの名無しさん** · 2020/01/13(月) 10:33:07.31

Dartが糞なのはわかる。でもflutterがきてるのも事実。
もう「どこでもkotlin」とか言ってる場合じゃない。
このままだとandroid->fuchsia移行と共にkotlinは終わる。
なのでjava,goを押しのけて静的サーバーサイド言語の第一候補になるしか道はないと思う

**デフォルトの名無しさん** · 2020/01/13(月) 11:34:02.40

と思うけど、googleはなぜかKotlin版flutterのJetpack Composeを今年ベータリリース?に向けて作業中。
Jetpack Composeは最初はandroid向けかもしれんが、kotlinはnativeでクロスプラットホームになるし、Jetpack Composeも将来いつの間にかクロスプラットホームになったり?

**デフォルトの名無しさん** · 2020/01/13(月) 11:36:48.21

まぁ、composeはクロスプラットホームにならなくてもcomposeの存在はかなりflutterへの移行を押し留めることになりそう。
もちろんflutterはクロスプラットホームだけど。

**デフォルトの名無しさん** · 2020/01/13(月) 12:51:17.02

K/JVMとK/Nチームがあまり仲良くない感じだったし
K/Nの設計上の戦略ミスもあって先は厳しい
企業リソースが潤沢でないことも大きいんだろうけど

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

相変わらず世間で流行るかどうかばかりを気にしている。世間に依存して頼りすぎている。その結果振り回され続けてしまう。

**デフォルトの名無しさん** · 2020/01/13(月) 19:31:48.26

好きなやつ使え

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

俺なんて世間の流行なんか無視して我が道をいってるから
メインはDelphiパスカルだぜ！

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

給料上がるのならなんでもいいわ

**デフォルトの名無しさん** · 2020/01/14(火) 15:44:20.83

趣味なら何でもいいんだろうけど仕事なら需要を考慮しないと糞仕事で薄給とかやってられないでしょ

**デフォルトの名無しさん** · 2020/01/14(火) 17:03:38.63

流行ってるやつの方が情報多くて学習し易いというのはあるな。

そういえば今はまだJavaが結構使われてるようだがCも増えたんだってな。組み込み関係が増えたせいらしい。

**デフォルトの名無しさん** · 2020/01/14(火) 17:19:04.63

これこれ。

2019年に成長したプログラミング言語ランキング、第1位は？
https://news.mynavi.jp/article/20200110-952052/

**デフォルトの名無しさん** · 2020/01/14(火) 17:28:10.81

あ、でも、こんなページもみつけてしまった。

TIOBE Indexはあまり参考にすべきでない
https://qiita.com/kmizu/items/b07f1dcad63f104248c5

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

>>602
給料あげたかったら、プログラマーは卒業しないとね

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

日本はクソだ

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

>>601
自分が楽しめるならレガシーシステムのお守役としてニッチ極めるのは全然ありだべ

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

exposedのDAOとDSLってどっち使った方がいいんですか？

**デフォルトの名無しさん** · 2020/01/16(木) 18:03:07.20

>>608
いかにも。お前はクソだ。

**デフォルトの名無しさん** · 2020/01/18(土) 20:25:30.67

流行るか流行らないなんてどうでもいいんだよ
やりたいことをやれるかどうか
JavaScript界隈の気持ち悪いやつがflutterは流行らないといってるけど
流行ったらどういう態度にでるのか見てみたいものだ

**デフォルトの名無しさん** · 2020/01/18(土) 21:28:55.28

全部自力で作るわってレベルの奴ならそれでいいけど
流行りはコミュニティ規模、延いてはライブラリや関連技術の発展に繋がるわけでさ

何はともあれIOインターフェースのデファクトスタンダードを早くしろください！

https://github.com/ktorio/ktor/tree/master/ktor-io/common/src/io/ktor/utils/io/core
https://github.com/Kotlin/kotlinx.serialization/tree/master/runtime/commonMain/src/kotlinx/io
https://github.com/Kotlin/kotlinx-io/tree/master/core/commonMain/src/kotlinx/io

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

KotlinのコンパイラはKotlinで書かれてるの？それともJava?

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

Javaに決まっているだろ
Kotlinで書かれてたらどうやってコンパイラをコンパイルするのだ
鶏は卵からしか生まれないのだ

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

コンパイラがどの言語で書かれてるかを質問する人よくいるけど
知ったところで何か意味あるの？

**デフォルトの名無しさん** · 2020/01/22(水) 16:21:05.17

>>615
最初はJavaで次からはKotlinに変換して自分で自分を記述する状態にしてるかもよ。するとその後はずっとKotlinでKotlinを書く状態になる。

昔はPASCALをPASCALで書いてハンドコンパイルしてから自身をコンパイルさせるなんての本当にあったようだけどな。

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

>>616
コンパイラを作れる言語かどうかがわかる。

ということ以外の意味はないかな。

**デフォルトの名無しさん** · 2020/01/22(水) 16:30:08.45

最初は別言語で書かれるが、その後自身の言語で書き直すことはよくある
セルフホスティングと言ってGo,Rustなども達成している

成果物の動作環境で自身も動作可能になるので
Kotlin/JSがセルフホスティングなら
babel/standaloneのようにブラウザ上でコンパイルが可能になったり
Kotlin/NativeのビルドにJVMが不要になったりする

実用上はJVM需要が主だしGradleが便利なので変えないだろうけど

**デフォルトの名無しさん** · 2020/01/22(水) 16:31:19.66

>>614
初期コンパイラはJavaで書かれて新規部分は基本Kotlinで書かれてる
置き換えたい気はあるようだけどJavaのコードはかなり残ってる

以下から拡張子の混在が見て取れると思う
https://github.com/JetBrains/kotlin/tree/master/compiler/backend/src/org/jetbrains/kotlin/codegen

**デフォルトの名無しさん** · 2020/01/22(水) 16:48:14.42

>>618
KotlinのコンパイラがJavaで作られたとしても
Kotlinがコンパイラを作れない言語ということにはならないと思うんだが

**デフォルトの名無しさん** · 2020/01/22(水) 17:03:14.84

美人のまんこと豚のまんことどっちが良いかって豚の方が名器なら豚を選べば良い
気にすんな

**デフォルトの名無しさん** · 2020/01/22(水) 17:04:15.03

>>621が童貞だとしても、
>>621が性的不能ということにはならない
つまりこういうことだ

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

>>620
詳しくありがとうございます！

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

kotlin1.4の展望を読んだんだけど、
「kotlin/nativeのコンパイル速度は、まだしばらく改善できません」
って言ってるのかな。。楽しみにしてたのに

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

まだ使い物になってないのに速度もクソもあるか

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

>>621
ならないね。実証できてないだけで。

**デフォルトの名無しさん** · 2020/01/25(土) 19:02:48.90

いままでバックエンドにIL採用してなかったのは不仲が原因・・・？

**デフォルトの名無しさん** · 2020/01/26(日) 18:55:55.74

そろそろ新しい本、出ないかな
待ってる

**デフォルトの名無しさん** · 2020/01/26(日) 20:04:28.42

サーバーサイドの分厚い本出てほしい

**デフォルトの名無しさん** · 2020/01/26(日) 20:35:36.28

コトリンの薄い本出してほしい

**デフォルトの名無しさん** · 2020/01/26(日) 21:42:21.85

本来の意味の同人誌だな

**デフォルトの名無しさん** · 2020/01/26(日) 23:29:22.09

自分で作れば良いのではないか？

**デフォルトの名無しさん** · 2020/01/27(月) 00:26:33.19

今日もnull安全だから…プロパティに代入して欲しいの

**デフォルトの名無しさん** · 2020/01/27(月) 10:04:25.03

近所の本屋ではkotlinの棚にflutterが侵食してきている
kotlin本は必要だー！出せー！

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

みんなで薄い本を出しまくろう

**デフォルトの名無しさん** · 2020/01/27(月) 13:18:35.57

薄い紙の本？
誰が薄い髪やねん！

**デフォルトの名無しさん** · 2020/01/27(月) 22:02:28.60

　　　　　　／/
　　　　／　./
　　　 / 　./　　　　ﾊﾟｶ
　　　/ ∩彡⌒ ミ　髪のはなし終わった？
　　 /　.|（´・ω・｀）＿
　　/／ |　　　　　ヽ/
　　"￣￣￣￣"∪

**デフォルトの名無しさん** · 2020/01/28(火) 00:20:15.54

通話中でもバックグランドで処理するアプリとか、スマートウォッチ向けアプリ作ってみたい

**デフォルトの名無しさん** · 2020/01/28(火) 04:30:56.90

じゃあ厚い紙の本で

**デフォルトの名無しさん** · 2020/01/28(火) 04:32:09.25

>>639
どうぞ。遠慮なく。思う存分作ってよいぞ。どんどん作ってくれたまへ。

**デフォルトの名無しさん** · 2020/01/28(火) 08:26:16.34

できぬのだ
だから本出してくれ

**デフォルトの名無しさん** · 2020/01/28(火) 12:56:22.85

大丈夫。お前ならできる。俺は信じてるぞ。
とりあえずネットで検索しろ。

**デフォルトの名無しさん** · 2020/01/28(火) 16:04:32.98

よし、待ってろ！

**デフォルトの名無しさん** · 2020/01/29(水) 09:57:21.18

完成したらその事を本に書いて出せ。
Amazonの電子書籍なら簡単な審査だけで出せる。

**デフォルトの名無しさん** · 2020/02/01(土) 16:27:53.15

やはりできぬ！

**デフォルトの名無しさん** · 2020/02/03(月) 02:56:28.79

いやできる。絶対に完璧にできる。頑張れ。

**デフォルトの名無しさん** · 2020/02/03(月) 16:12:29.25

むーりー

**デフォルトの名無しさん** · 2020/02/03(月) 16:52:51.88

ヤレばデキる

**デフォルトの名無しさん** · 2020/02/05(水) 17:46:33.75

スマートキャストで、これは問題なくできる。

val x: Any = 0.3
if (x is Double) println(x + 0.2)

しかしこれはできなかった。

val x2: List<Any> = listOf(0.3)
if (x2[0] is Double) println(x2[0] + 0.2)

足し算する前に as Double でキャストすると問題なし。

if (x2[0] is Double) println(x2[0] as Double + 0.2)

なんで? val で List だから内容が変更されることはない筈で、スマートキャストできそうに見えるんだけど。
Listの中身まで推論してられっかボケってこと？

**デフォルトの名無しさん** · 2020/02/05(水) 17:49:43.62

Listに色々なクラスのインスタンス入れて返すメソッドを思い付いたのだがKotlinはスマートキャスト使えるから楽に書けるかなと思ったんだよね。
で、試してみてわかったんだけど、これだとJavaと大差ないね。

**デフォルトの名無しさん** · 2020/02/05(水) 17:54:45.88

>>650
[0]は.get(0)のシンタックスシュガー
でgetが要素を変更しない保証がない

**デフォルトの名無しさん** · 2020/02/05(水) 19:35:44.69

covariantの問題だから、将来的にもそこは変わないと思う。

**デフォルトの名無しさん** · 2020/02/05(水) 20:28:21.91

.get()がthisを変更しないことを
関数定義時に保証する文法を追加すれば解決可能では？

val y = x[i]で一旦受ければいいから
JBの言語改善にかける意欲の低さを考えれば超期待薄

**デフォルトの名無しさん** · 2020/02/06(木) 00:02:18.36

> Listに色々なクラスのインスタンス入れて返すメソッド

これのメリットがよく分からんけど List<Any> に対して get(i) + cast する拡張関数作ればいいんじゃね

**デフォルトの名無しさん** · 2020/02/06(木) 01:30:37.85

リストにいろいろと聞くとつい、生Listを構造体代わりにする昔ながらのクソコードを思い出す
あのアンチパターンに名前はないのだろうか
静的ならDestructuring Declarationsを使い動的ならSequenceを返してitをスマートキャストすればいいのでは

**デフォルトの名無しさん** · 2020/02/06(木) 01:34:47.55

>>650 >>654
メソッドを2回呼んで同じ値を返す保証は結構難しい
言語レベルでのメモ化や参照透過性、所有権システムなどが必要になる

フロー解析で出来たところでコンパイル可否がlistOfの実装に依存して
柔軟性もコンパイル速度も悪化するから
Kotlinディスカッションに投げても多分改悪判定される

valやletで十分だと思うけどな

**デフォルトの名無しさん** · 2020/02/06(木) 01:42:08.64

>>651
型チェック＋処理を頻繁に書きたいのなら
こういうの用意しておくといいんじゃね

inline fun <reified T> Any?.letif(b:(T)->Unit){ if(this is T) this.let(b) }

fun main() {
val x2: List<Any> = listOf(0.3)
x2[0].letif<Double>{ println(it + 0.2) }
}

**デフォルトの名無しさん** · 2020/02/06(木) 06:43:59.78

>>650
val x2: List<Any> = listOf(0.3)
val x3 = x2[0]
if (x3 is Double) println(x3 + 0.2)
これはスマートキャストいけた。

雑に考察すると、x2の右辺には別スレッドで
val x4: MutableList<Any> = mutableListOf(0.3)
と定義したx4を書くことも出来て、
ifの条件式が評価されてprintlnが実行されるまでに、
元のスレッドでx4[0] = "string"が実行されている可能性が微粒子レベルで存在するのかなと。

**デフォルトの名無しさん** · 2020/02/06(木) 09:49:06.64

data classなんかの読み取り専用プロパティへの参照なら同じ書き方でスマートキャストできる
そのプロパティを参照するだけのメソッドやカスタムgetterを経由したら不可
コンパイラ設計上、メソッドの副作用がないことを無制限に推論することは時間的制約の面で不可能で、どこかで線引きするしかない
リフレクションで変数を書き換えてるかもしれない
その合理的な線引きの範囲がval値への参照なんだと思う

**デフォルトの名無しさん** · 2020/02/06(木) 09:57:34.37

>>659
あ、そーか。その可能性あるな。
Listの皮を被ったMutableListね。

**デフォルトの名無しさん** · 2020/02/06(木) 19:48:08.86

kotlinはc++みたいな玄人向けのクソ言語になろうとしてるのか?複雑すぎやろ。コルーチンでどうやってエラー伝えればいいんだ
https://qrunch.net/@kyoutoday/entries/64IYC8Ye81WyzA5L

**デフォルトの名無しさん** · 2020/02/06(木) 22:01:06.64

Eitherに一票

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

>>662
>coroutinesなどで実行している非同期なコードの例外をキャッチすることができません。
どういうこと？出来るだろ？

suspend fun f(): String { throw RuntimeException() }

fun main() {

try { runBlocking { f() } }
catch(e:RuntimeException){ println("catch") }

val d = GlobalScope.async { f() }

try { runBlocking { d.await() } }
catch(e:RuntimeException){ println("catch") }

}

**デフォルトの名無しさん** · 2020/02/07(金) 03:04:38.78

runBlockingって、名前の通りスレッドブロックするん?だったらさすがに実際そんな使わないだろ。launch,asyncなどのコルーチンビルダーで例外キャッチできないと

**デフォルトの名無しさん** · 2020/02/07(金) 03:18:27.55

>>662と似た記事https://qiita.com/kencharos/items/6fd0a9e92363b08c0340

c#のasync/awaitレベルで十分なのにやり過ぎkotlin...

**デフォルトの名無しさん** · 2020/02/07(金) 06:43:46.22

>>665
基礎無しで応用を全部使おうとして混乱してるように見える
Kotlinに関しては道筋のドキュメント不足が原因かもしれない

> launch,asyncなどのコルーチンビルダーで例外キャッチできないと
C#のasyncやJavaScriptのPromiseでも変わらんよ

言語に限らず非同期処理の基礎知識として
コールバック、待機/通知、イベントループをまず学ぶべき

**デフォルトの名無しさん** · 2020/02/07(金) 06:46:22.97

エラー処理については
まず、正常値/エラー値/多値/例外はどれも
結果(処理への入力に対する出力)の一形態に過ぎないというところからスタート

**デフォルトの名無しさん** · 2020/02/07(金) 08:06:13.01

>C#のasyncやJavaScriptのPromiseでも変わらんよ
他の言語とkotlinの違いはkotlinの場合は、suspend関数を呼ぶにはどっかにcoroutineが必要で、
coroutineの境界(lanuchなどで)例外は外側に伝わらないじゃん。
try {
　GlobalScope.launch { 例外発生}
} catch (ex: Exception) { キャッチできない }

で、どうすりゃいいの？ってことで悩んでて、ググったら上記の記事が出てきて、kotlinは他の方法でやるの？？
って思ったけど今回とあんま関係なかったのかも。
とりあえず、JobにinvokeOnCompletionで完了ハンドラ登録できるから、
coroutineの外側ではJobを受けわたせばいいのかな・・