Kotlin 7

**デフォルトの名無しさん** · 2020/05/06(水) 16:00:38.76

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

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

**デフォルトの名無しさん** · 2020/12/23(水) 19:38:57.98

nullsafe って言うのは Null チェックしなくていいという意味じゃないよ？
チェック必要なものと不要なものを区別して、必要なものはチェックしてからアクセスしないとコンパイルエラーになるんだよ？

**デフォルトの名無しさん** · 2020/12/24(木) 07:36:37.88

>>502
普通にnullチェック入れればいいんじゃないの？

**デフォルトの名無しさん** · 2020/12/24(木) 08:10:29.60

>>502
nullチェックしながら
APIの作者にバグレポート上げろよ。

**デフォルトの名無しさん** · 2020/12/24(木) 08:57:55.57

まずレスポンスのデータクラスのフィールドををnullableにしないといけない
nonnullでもコンパイルエラーならないのにだ

**デフォルトの名無しさん** · 2020/12/25(金) 09:41:57.24

何で companion object って一番下なんすか
一番上じゃ駄目なんすか

**デフォルトの名無しさん** · 2020/12/25(金) 11:57:59.25

kotlin世界との境界部分はもろもろを自分で気を付けるしかない

**デフォルトの名無しさん** · 2020/12/27(日) 23:41:45.31

>>507
文法的にはどっちでもいいよ

**デフォルトの名無しさん** · 2021/01/01(金) 17:03:56.74

kotlin/nativeでサーバーサイド作る話はどうなった？

**デフォルトの名無しさん** · 2021/01/02(土) 07:50:34.05

SuperJobだと、子の失敗は親に影響与えないとのことですが、子をキャンセルすると親もキャンセルされてしまうとのことです

子が失敗しようが、子をキャンセルしようが親に全く影響を与えたくないのですがどうすればいいでしょうか？

**デフォルトの名無しさん** · 2021/01/02(土) 08:31:31.17

SupervisorJobだった
つか、なんかややこしくなってきた
間違ってた、SupervisorJobは子のキャンセルは親に影響しないからスーパーなのか？

**デフォルトの名無しさん** · 2021/01/02(土) 12:00:19.22

間違ってた
子Jobのcacelメソッドによるキャンセルは親が普通のJobだろうがSupervisorJobだろうが親をキャンセルさせない

子JobがCacellationException以外の例外で失敗したとき、違いがでてくるのか

**デフォルトの名無しさん** · 2021/01/02(土) 13:51:40.78

おちつけ

**デフォルトの名無しさん** · 2021/01/07(木) 12:30:36.60

明けましておめでとうございます。
ことりんもよろしくお願いします。

**デフォルトの名無しさん** · 2021/01/07(木) 13:06:35.86

酉年にやれよ

**デフォルトの名無しさん** · 2021/01/08(金) 00:22:29.53

2029年までネタとして取っておこう…

**デフォルトの名無しさん** · 2021/01/08(金) 00:30:46.51

その時まで生きてるのかな、ことりん

**デフォルトの名無しさん** · 2021/01/08(金) 07:52:19.70

こぅのとぉりん生きてますよ

**デフォルトの名無しさん** · 2021/01/08(金) 08:38:56.45

ことりんじゅうさまです

なんてことならないように使っていこう

**デフォルトの名無しさん** · 2021/01/09(土) 09:13:47.78

例えばUserクラスがあって、userIdプロパティとネストしたUser型のuserプロパティがあります

このときList<User> users
から、users.map?とかcollection apiを使ってネストしたUserも含めたすべてのuserIdのリストを求める方法があれば教えて下さい

再帰関数を用意しないと無理?

**デフォルトの名無しさん** · 2021/01/09(土) 09:19:13.14

flatmap

**デフォルトの名無しさん** · 2021/01/09(土) 09:28:30.58

userプロパティは多段ネストする可能性があるんですがflatMapでいけましたっけ?

**デフォルトの名無しさん** · 2021/01/09(土) 15:43:34.22

プロパティをどう辿るかはcollection apiだけじゃどうにもならないから自分で実装するしかないでしょ
扱うデータによっては重複や循環なんかも考慮が必要かも

https://paiza.io/projects/JkGNST_vjmARbX8XFfMLnA

**デフォルトの名無しさん** · 2021/01/10(日) 00:59:41.08

>>521
そのロジックに意味のあるものならUserにallChildrenUser : List<User>メソッドを作って子のallChildrenUserを呼び出す、つまり再帰構造、allChildrenUser() -> users.flatmap{ it.allChildrenUser() }
かな

ネスト構造の時点で循環参照の可能性があるわけで言語機能でどうにかなる話とは違うと思う
または、データ構造として最適なツリーを採用したほうが良いかもしれん

**デフォルトの名無しさん** · 2021/01/10(日) 01:38:59.42

自分が出来ると心から信じることができれば必ずやれる

**デフォルトの名無しさん** · 2021/01/10(日) 20:09:18.30

言語機能でどうにかなるか否かはまた別の話でしょう
データが循環していたらスタックオーバーフローなりその他の例外なりが出るように標準ライブラリが設計されていればいいだけなので

**デフォルトの名無しさん** · 2021/01/10(日) 20:13:22.96

余談だけどグラフの探索は再帰を使わなくてもループに書き換えることができる
スタックオーバーフローしなくなるのが利点
ループではなく再帰でしか解決できないアルゴリズム問題が存在し得るかどうかは不勉強なので知らない

**デフォルトの名無しさん** · 2021/01/10(日) 20:31:18.39

再帰は必ずループに出来る

**デフォルトの名無しさん** · 2021/01/10(日) 21:54:19.01

クイックソートどうすんじゃ

**デフォルトの名無しさん** · 2021/01/10(日) 21:56:12.30

木の探索は横探索すればいいか
スタックのかわりにヒープがあふれる

**デフォルトの名無しさん** · 2021/01/10(日) 22:08:14.99

whileループでbreakすればいい

**デフォルトの名無しさん** · 2021/01/10(日) 22:25:02.75

flatmapで何でも解決できる

**デフォルトの名無しさん** · 2021/01/22(金) 13:56:01.26

じゃあflatmapで俺の資産を増やしてくれ

**デフォルトの名無しさん** · 2021/01/22(金) 14:36:13.50

flatmapと元気があれば何でもできる！

**デフォルトの名無しさん** · 2021/01/22(金) 20:45:59.10

Kotlin Roadmap
https://kotlinlang.org/roadmap.html

**デフォルトの名無しさん** · 2021/01/25(月) 06:26:23.02

>>534
理論上はflatmapで何でも解決できるとしても、実装するには十分な数学的能力が必要なのだ。

**デフォルトの名無しさん** · 2021/01/25(月) 18:04:21.90

>>537
そうか。じゃあお前なら出来るんだな。任せたぞ。

**デフォルトの名無しさん** · 2021/01/25(月) 22:47:14.88

プログラミングは
気合いだ

たとえば１万件のソートをするのに
処理のオーダーがどうとか
クイックソートのライブラリがないとか
代替するものをつくるかどうかとか
悩むときに

Ｅｘｃｅｌにはっつけたり
２重ループで平気で馬鹿ソートする
周囲の嘲笑をものともしない決断力

そういうやつができるやつなんだ

**デフォルトの名無しさん** · 2021/01/26(火) 08:07:03.00

>>539
そういう能力の人は便利屋として安い単価で使い捨てられるだけです

**デフォルトの名無しさん** · 2021/01/26(火) 11:42:19.41

いうほどflatmap使うか？
そりゃたまには使うけどさ

**デフォルトの名無しさん** · 2021/01/26(火) 12:25:48.83

1万件程度なら普通にExcelも使うし
バカソートも使う

もちろん製品コードではそんな事はないけど

**デフォルトの名無しさん** · 2021/01/26(火) 20:08:03.52

flatmapが世界を救う

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

flatmapはステータスだ！

**デフォルトの名無しさん** · 2021/01/27(水) 16:58:07.84

!!って基本的に使うべきでないんですかね

**デフォルトの名無しさん** · 2021/01/27(水) 23:12:27.62

>>538
STモナドの中に入れたら増やせそうな気がするが、取り出せなくなるけどいい?

**デフォルトの名無しさん** · 2021/01/27(水) 23:15:32.07

>>545
簡易的なアサーションとして理解した上でNPEが出てほしい場合は使っていいよ
知らない間に大事な処理が実行されずスルーされたりするよりも、バグなのでとっとと例外を出して知らせてほしい場合とかね

https://kotlinlang.org/docs/reference/null-safety.html
> Thus, if you want an NPE, you can have it, but you have to ask for it explicitly, and it does not appear out of the blue.

**デフォルトの名無しさん** · 2021/01/28(木) 09:16:46.22

kotlinではnullチェックの代わりに?.を使うべきですか

**デフォルトの名無しさん** · 2021/01/28(木) 09:54:30.26

nullチェックと一口に言ってもバリエーションを考えないとだめ
nullなら何もしない
nullなら空白で表示する
nullならハイフンで表示する
nullなら代替手段で値を取りに行く
nullならログを吐いてフォールバックする
nullならフェイルファストで例外を出す

?.は上記のうちの一部に最適ではあるものの、一部には役に立たない
実現したいことや状況に沿った措置が先にあり、それをコードで表現するために適した言語機能を選ぶという順序で考えるべき

**デフォルトの名無しさん** · 2021/01/28(木) 12:36:53.48

nullなら割り込み禁止してその場で無限ループ

**デフォルトの名無しさん** · 2021/01/29(金) 15:21:19.10

Kotlinって、SwiftやRuby以上にWindows切り捨て感があるのな

**デフォルトの名無しさん** · 2021/01/29(金) 16:40:33.72

そう？

**デフォルトの名無しさん** · 2021/01/29(金) 22:17:24.41

やっぱSwiftやRubyの方がひどいか・・・・

**デフォルトの名無しさん** · 2021/01/30(土) 13:36:04.18

>>551
なんでそう思うの？
普通にJVMだからむしろWindowsに優しい方の言語だと思うけど。
Rubyなんて酷いものだろう。。

**デフォルトの名無しさん** · 2021/02/16(火) 22:13:20.25

ねこ

**デフォルトの名無しさん** · 2021/02/20(土) 08:00:32.70

過疎なんか？

**デフォルトの名無しさん** · 2021/02/21(日) 22:47:03.15

TornadoFXが終わってしまったっぽい。

**デフォルトの名無しさん** · 2021/02/22(月) 03:31:15.20

>>553
そもそもその2つもそれぞれMacとUNIX系のことしか考えてないってだけで切り捨て云々以前の話

**デフォルトの名無しさん** · 2021/02/22(月) 07:50:49.54

>>557
最初だけ話題になったけどすぐ話聞かなくなったもんな

**デフォルトの名無しさん** · 2021/02/24(水) 06:00:45.34

>>559
TornadoFXで作ったソフトウェアがあるんだが、Java8の終了と共に沈めるしかないか…

**デフォルトの名無しさん** · 2021/02/24(水) 15:55:29.28

これから覚えようと思ったのに・・・

**デフォルトの名無しさん** · 2021/02/24(水) 20:06:34.71

残念だね

**デフォルトの名無しさん** · 2021/02/24(水) 20:12:49.29

ざんねんですね

**デフォルトの名無しさん** · 2021/02/24(水) 21:56:39.02

なんでお葬式ムードなんだwwww

**デフォルトの名無しさん** · 2021/02/28(日) 08:57:09.46

すでにピークは過ぎ去った。

**デフォルトの名無しさん** · 2021/02/28(日) 10:57:59.59

TornadoFXの話だろ。そりゃお葬式だわ。

**デフォルトの名無しさん** · 2021/02/28(日) 10:58:46.89

今KotlinでGUIアプリ作ろうと思ったら何がいいんだろうな

**デフォルトの名無しさん** · 2021/02/28(日) 11:03:50.21

ピークちゃんかわいいやろ

**デフォルトの名無しさん** · 2021/02/28(日) 12:53:09.27

>>566
Kotlin全体が、だろ。

**デフォルトの名無しさん** · 2021/02/28(日) 15:27:48.49

>>567
何がどうなっても変わる事のがない最底辺の awt ではないか?

**デフォルトの名無しさん** · 2021/03/01(月) 19:44:58.06

awtの上でいろいろ動いてるんじゃなかったか

**デフォルトの名無しさん** · 2021/03/02(火) 02:32:19.48

kotlin.awt というのを作ってみたらどうか?

無駄だな。

**デフォルトの名無しさん** · 2021/03/05(金) 11:41:14.83

未だにkotlin nativeのサーバーサイドに可能性を感じてるんだがどう思う？

**デフォルトの名無しさん** · 2021/03/05(金) 15:40:46.28

JVMを捨てて得られるメリットと比べて、Javaの資産を失うデメリットが多すぎかな
そのメリットの方を重視する人は普通はGoやRustを使うだろうし、あえてKotlin/Nativeを使うのはかなりニッチになるだろうから、JetBrainsもそこに注力しようと思わないし流行らない

まあでも、整備してくれるなら使ってあげるよｗ

**デフォルトの名無しさん** · 2021/03/06(土) 07:42:11.87

>>573
nativeにしたところでパフォーマンスはせいぜい数倍にしか上がらない。
事業が順調に展開してパフォーマンスが求められるような幸運なケースでは、
分散やクラウドでスケールしないと早々に限界にぶち当たるのではと。
やったことないけどね。

**デフォルトの名無しさん** · 2021/03/06(土) 09:17:28.12

頼みのAndroidもFlutterにやられて終わりだな。

**デフォルトの名無しさん** · 2021/03/06(土) 12:25:54.92

今そんなにflutter伸びてるの？
AndroidといえばKotlinの時代はおわり？

**デフォルトの名無しさん** · 2021/03/06(土) 13:41:46.08

クロスプラットフォームは総じて糞

**デフォルトの名無しさん** · 2021/03/07(日) 07:42:06.57

DartはChromeに組み込みが失敗して終わったと思ったのに、Flutterで巻き返してくるとは。
先日Flutter 2.0になりWebもデスクトップもカバーして、
クロスプラットフォームではReact Nativeを抜いてトップになったらしいけど、
モバイル全体で見た時のシェアはどうなんだろう。

>>578
そういえばこのスレでもXamarinの名前をすっかり見かけなくなった。

**デフォルトの名無しさん** · 2021/03/07(日) 10:05:36.59

xamarinは.NETに統合されるから単独の話題には
もうならないのではなかろうか

**デフォルトの名無しさん** · 2021/03/08(月) 22:27:58.05

Cocoaの件で悪い意味で話題の的になると思ってたが

**デフォルトの名無しさん** · 2021/03/10(水) 09:14:01.41

Googleと取り組むオンライン施策についての件名でGoogleからメールがきたんだが趣味アプリなのに返事しちゃっていいの？

**デフォルトの名無しさん** · 2021/03/11(木) 06:21:17.00

>>582
詐欺メールでなければ。
内容がわからないけど、趣味でやっているなら解約時に違約金を取られないか注意するくらいかな。

**デフォルトの名無しさん** · 2021/03/12(金) 11:34:03.78

>>576
kotlin nativeはkotlin jvmより遅いよ
起動とメモリ使用量は有利だけど

**デフォルトの名無しさん** · 2021/03/12(金) 11:41:14.42

>>575
jetbrains視点で、vs flutterよりvs golangの方がマシな気がするんやが。
rustは競合しないから置いとくとして、
golangより書きやすいのは間違いないんやし。

**デフォルトの名無しさん** · 2021/03/12(金) 13:35:25.78

Googleの女性担当者とビデオ通話で内容をご案内とか書いてあるんだけど趣味アプリなのにいいの？

**デフォルトの名無しさん** · 2021/03/12(金) 19:38:55.82

>>586
守秘義務とかがないならもう少し詳しく説明してもらえないと分からない。
内容をご案内、も何の内容を誰(Google?あなた?ユーザー?)に案内なのかさっぱりだし。
>>584,>>585
アンカ逆かな

**デフォルトの名無しさん** · 2021/03/14(日) 16:14:48.16

サーバーサイドのJVMって別にパフォーマンス悪くないからなー
nativeにするメリットがあまりない

**デフォルトの名無しさん** · 2021/03/14(日) 17:26:30.65

YMobileのCMに出てくる芦田愛菜ちゃんはかわいいと思う

**デフォルトの名無しさん** · 2021/03/15(月) 14:33:02.39

nativeにするのは
javaの遺産を継承したくないからだと思われる

**デフォルトの名無しさん** · 2021/03/15(月) 23:06:23.55

>>580
継承したくないなら使わなければ済むと思うのですが。

**デフォルトの名無しさん** · 2021/03/16(火) 11:55:42.45

nativeにしたいのは起動時間短縮(aws lambda利用とか)と、jvmレスによるメモリ軽減(kubeで複数pod利用とか)狙い
goと被ってるから倒したい

**デフォルトの名無しさん** · 2021/03/18(木) 12:54:36.74

Kotlinでそれをやりたい人は少数派だろうし、倒さずに住み分けするんじゃだめなの

**デフォルトの名無しさん** · 2021/03/23(火) 09:25:28.89

ヤらなきゃヤられるんだよ

**デフォルトの名無しさん** · 2021/04/06(火) 16:58:25.74

java勝ったからもうお前に用はない

　 ○　←google
　く|)へ
　　〉　ヾ○ｼ　←Kotlin
￣￣７　ヘ/
　　/　ノ
　｜
　／
`｜
／

**デフォルトの名無しさん** · 2021/04/06(火) 17:23:29.60

いやkotlinはjavaのラッパーでしかないだろ

**デフォルトの名無しさん** · 2021/04/06(火) 18:48:08.81

パクりまくりおｋで逆にJava終了ってマジ!?

**デフォルトの名無しさん** · 2021/04/06(火) 18:53:33.55

むしろKotlinの天下javaに取って代わるわ

**デフォルトの名無しさん** · 2021/04/07(水) 16:37:16.80

生き残るのはJava8までよ

**デフォルトの名無しさん** · 2021/04/15(木) 03:49:33.54

そういやOracleとGoogleで争ってたAndroidのJavaの件はGoogle勝ったんだってな。

**デフォルトの名無しさん** · 2021/04/15(木) 12:26:42.63

そういやって、まさにその話をしてたのよ

**デフォルトの名無しさん** · 2021/04/28(水) 20:51:31.93

そういやOracleとGoogleで争ってたAndroidのJavaの件はGoogle勝ったんだってな