Kotlin 7

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

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

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

**デフォルトの名無しさん** · 2020/07/31(金) 00:16:16.55

逆引きKotlin

とか出ないんだろうか

**デフォルトの名無しさん** · 2020/07/31(金) 05:20:55.03

C#にはどぼんがあったけど、あれでかなり助けられたなあ

**デフォルトの名無しさん** · 2020/07/31(金) 05:26:08.98

>>191
高レベル放射性廃棄物は地中深く埋葬されて下さい

**デフォルトの名無しさん** · 2020/07/31(金) 07:45:44.70

>>168
Xamarinという選択肢は

**デフォルトの名無しさん** · 2020/07/31(金) 09:14:05.07

>>195
変なもん勧めるなよ・・・

**デフォルトの名無しさん** · 2020/07/31(金) 13:04:29.30

>>168
会社次第だろ

**デフォルトの名無しさん** · 2020/07/31(金) 13:07:43.26

>>197
万能の回答で中身ゼロ

**デフォルトの名無しさん** · 2020/07/31(金) 14:12:23.57

KotlinはC#と同じく統合開発環境の入力支援のおかげで難易度が低く感じやすい。
入力支援のないテキストエディタを使ってKotlinやC#の開発をするとつらみに気づく。

**デフォルトの名無しさん** · 2020/07/31(金) 14:56:18.07

今時ただのテキストエディタでやってるとこなんてあるの？

**デフォルトの名無しさん** · 2020/07/31(金) 15:16:49.29

基本はviだろ。

**デフォルトの名無しさん** · 2020/07/31(金) 15:34:09.86

>>198
お前にはBASICがお似合い

**デフォルトの名無しさん** · 2020/07/31(金) 15:49:22.55

カルシウムが不足してるから牛乳飲むといいよ

**デフォルトの名無しさん** · 2020/07/31(金) 17:39:05.12

>>202
おっと今度は要件も聞かずに回答するのはエスパーなのか

**デフォルトの名無しさん** · 2020/07/31(金) 18:57:36.39

>>196
えーなんで？
Xamarin好きやで。
スレチになって申し訳ないけど。

**デフォルトの名無しさん** · 2020/07/31(金) 18:57:50.76

>>196
えーなんで？
Xamarin好きやで。
スレチになって申し訳ないけど。

**デフォルトの名無しさん** · 2020/07/31(金) 18:58:02.83

>>196
えーなんで？
Xamarin好きやで。
スレチになって申し訳ないけど。

**デフォルトの名無しさん** · 2020/07/31(金) 18:58:59.05

>>196
ごめんm(_ _;)m
何回も書き込んてしまった。

**デフォルトの名無しさん** · 2020/07/31(金) 20:00:16.29

久しぶりにkotlin native試してみたら、いまだにhelloworldのコンパイルに10秒以上かかる。。

**デフォルトの名無しさん** · 2020/07/31(金) 20:17:07.59

玩具に何を期待しているのか

**デフォルトの名無しさん** · 2020/08/01(土) 01:12:23.76

夢と希望の未来がいっぱい詰まってるのさ

**デフォルトの名無しさん** · 2020/08/01(土) 05:35:09.86

気持ちよくなることかな

**デフォルトの名無しさん** · 2020/08/01(土) 11:56:02.27

build.gradle.ktsとか使ってるプロジェクトウザいな。
余計なプラグインが増えてビルド時間も長くなるわ、DSLもGroovyより劣化してて単純に読みにくいのに。

**デフォルトの名無しさん** · 2020/08/01(土) 12:28:07.34

Groovyとかいうマイナー型なしクソ言語よりはマシだろ

**デフォルトの名無しさん** · 2020/08/01(土) 12:30:03.91

Groovyの方がDSLに向いた文法であるのは同感
優れたプログラミング言語があってもそれでビルドを記述したいとは限らんな

**デフォルトの名無しさん** · 2020/08/01(土) 14:33:10.32

build.gradle.kts の方が Intellj で編集するときに補完やエラーチェックがちゃんと効くという利点もある

**デフォルトの名無しさん** · 2020/08/01(土) 17:12:02.60

>>189
ま、しかし、たまにこうならないと過疎ってスレが沈んで消える。
逆に言うとこうなると言うことはまだまだ使う人が沢山居るということでもある。
使われなくなった言語のスレは見る人が少なすぎて煽っても何も起こらない。

**デフォルトの名無しさん** · 2020/08/02(日) 00:31:05.40

> 使われなくなった言語のスレは見る人が少なすぎて煽っても何も起こらない。
Delphi をディスるのはやめなさい

**デフォルトの名無しさん** · 2020/08/02(日) 05:00:23.72

Φを消すってどう言う意味だろう？

**デフォルトの名無しさん** · 2020/08/04(火) 17:47:41.53

5ちゃんが高齢化してるなぁと思うのは、Kotlinもそうだけど他の最近流行の言語やらフレームワークやらのスレが全然伸びないところよね
バリバリの若手世代が全然いない

**デフォルトの名無しさん** · 2020/08/04(火) 19:05:54.35

qiitaに行ってしっまったからでは？

**デフォルトの名無しさん** · 2020/08/04(火) 20:38:21.24

ここで聞かんでもググれば大抵の事がわかるからな

**デフォルトの名無しさん** · 2020/08/10(月) 16:05:28.72

拡張関数の中での this はその関数を呼び出したクラスのインスタンスになっているわけだが、
その拡張関数の中で object を作った場合はそのクラス内からはどうやってアクセスするのか?
this を使うと object のインスタンスになってしまう。かといって this@拡張関数のクラスにしてもできない。

例えばこれ。

fun String.hogeIterator() = object : Iterator<String> {
　override fun hasNext(): Boolean { .... }
　override fun next(): String {
　　/* ここでは substring() 等の拡張関数がアクセスしているインスタンスのメソッドを使えるが
　　 * this@String はコンパイル時に unresolved reference: @String になって使えない。
　　 * もちろん this は object を指すので使えない。
　　 */
　}
}

**デフォルトの名無しさん** · 2020/08/10(月) 16:08:45.69

fun().this(hoge)
みたいな呼び方出来なかったっけ

**デフォルトの名無しさん** · 2020/08/10(月) 16:16:22.91

>>224
ありがとう。 this@hogeIterator でできた。
this@拡張関数名ということだった。

**デフォルトの名無しさん** · 2020/08/18(火) 21:33:59.72

品質とパフォーマンスに注力した Kotlin 1.4 をリリースしました
https://blog.jetbrains.com/ja/kotlin/2020/08/kotlin-1-4-released-with-a-focus-on-quality-and-performance-ja/

**デフォルトの名無しさん** · 2020/08/19(水) 12:59:25.07

>>226
おめでとうございます！

**デフォルトの名無しさん** · 2020/08/21(金) 19:44:31.50

まだ違いがわからない

**デフォルトの名無しさん** · 2020/08/22(土) 07:19:26.47

kotlin/nativeがおもちゃじゃなくなるのはいつなんや。。

**デフォルトの名無しさん** · 2020/08/22(土) 18:48:47.15

全ての言語は俺のおもちゃ

**デフォルトの名無しさん** · 2020/08/22(土) 20:19:04.45

ちょっとダガログ語で遊んでみて

**デフォルトの名無しさん** · 2020/08/22(土) 21:48:01.83

Puwede bang maglaro dito?

**デフォルトの名無しさん** · 2020/08/23(日) 14:01:21.81

if式をネストさせる場合、内側のif式ないで早期returnしたいんですがどうすればいいんでしょうか？？
val hoge = if (条件) {
　if (条件1)
return hoge値3 <-　ここで早期returnで値を返したい
　hoge値2
} else
　hoge値1
内側のifをif elseにもっていけばいいのはわかるんですが、
その後、もっとifの早期returnがたくさんあって・・

**デフォルトの名無しさん** · 2020/08/23(日) 14:02:04.28

var hoge = if (条件) {
　if (条件)
　　return hoge値3 <-　ここで早期returnで値を返したい
　hoge値2
} else
　hoge値1

**デフォルトの名無しさん** · 2020/08/23(日) 14:34:14.58

無理にifの戻り値を使わなければよいのでは？
if (条件)
hoge = hoge値3

もしくは
if (条件) {
if (条件)
hoge値3
else
hoge値2
} else {
hoge値1
}

**デフォルトの名無しさん** · 2020/08/23(日) 15:24:28.03

うーん。なんかごめんなさい
わけわからないこだわりでしたね・・
おとなしくif else使っときます

**デフォルトの名無しさん** · 2020/08/23(日) 16:10:34.01

とりあえずベタで書いて放置
３日後に改めて見ると最適化出来る時あるよね
調子に乗ると思わぬ結果でバグるけど

**デフォルトの名無しさん** · 2020/08/24(月) 04:02:39.41

>>233
あれ？それ出来なかったっけ？

**デフォルトの名無しさん** · 2020/08/24(月) 06:52:54.71

ifもラベルつけられた気がするから余裕でできるんでね？
ただそもそもクソコードの香りがプンプンするから、そもそもその部分は別メソッドに切り出すしたほうが良いと直感がいってる

**デフォルトの名無しさん** · 2020/08/25(火) 03:35:59.04

そもそも >>234 は何をやりたいのか? return 書いたら普通にそのメソッドから return しない?
そうではなくて変数 hoge に hoge値3 を代入させたいの? だったら return じゃなくて普通に else 書いてやれば良いだけだし、
それではブロックが巨大で見辛いというのであれば別にメソッド作って外に出せば?

**デフォルトの名無しさん** · 2020/08/25(火) 07:21:25.63

>>240
それ質問者の自省と>>239の良回答を言い直しただけじゃね？

**デフォルトの名無しさん** · 2020/08/25(火) 07:53:18.31

>>233です
でも元からそこまででかくなかったです
if (条件1)
　値1 <- 1行
else if (条件2)
　値2 <- メソッド呼び出しの1行
else if (条件3)
　値3 <- メソッド呼び出しの1行
else {
　//
　// <- 13行くらい
　//
　値4　
}
else ifでやると1行、1行、1行、13行くらいで、すげぇ尻だけでかだったので気になったのです
で、とりあえず、最後の13行を一つ別にメソッドに追い出して、最後を4行にもっていけました

**デフォルトの名無しさん** · 2020/08/25(火) 07:58:14.54

でも、正直、このレベルだったので、if文で早期returnできた方がいいし13行くらいはそのまま書きたいですね

**デフォルトの名無しさん** · 2020/08/25(火) 08:03:18.20

>>243
メソッドとして切り出すかどうかの判断は行数よりもそのコードの意味の単位を基準にするといいよ

**デフォルトの名無しさん** · 2020/08/25(火) 08:06:41.76

すごい抽象的な言い方しちゃったごめん
わかりやすいやり方だと、その処理で何をやってるかをそのままメソッド名にすれば分かりやすい

例えばgetNameAndSaveName()みたいになるならこれはgetとsaveに分けるべきだと明らかにわかる

**デフォルトの名無しさん** · 2020/08/25(火) 08:09:57.72

whenの方がいいな
AndroidStudioも警告出してないか

**デフォルトの名無しさん** · 2020/08/25(火) 08:24:01.90

android studioで警告はでてないですね
whenも考えたのですが、なんかどうもまだしっくりこなくて使ってません
もちろん、when (式) {}形式は使いますが、
when { bool式 ->, bool式 -> , else -> }このタイプは・・

**デフォルトの名無しさん** · 2020/08/25(火) 08:33:07.94

>>244
もちろん、そうですけど
再利用されるならまだしも>>242のifを含むメソッド自体も>>242含めて、計30行くらいだったので
そこまで頑張って外に追い出してと思った次第です
そこは自分の適当なバランス感覚でやってます

**デフォルトの名無しさん** · 2020/08/25(火) 08:35:01.36

*そこまで頑張って外に追い出してもと思った次第です

**デフォルトの名無しさん** · 2020/08/30(日) 08:25:50.36

Kotlin派のお前らはKotlin以外にどんな言語に興味あるの？

**デフォルトの名無しさん** · 2020/08/30(日) 08:53:04.67

>>250
java 読めたらいい
swift iPhone向けも
C++ NDK
C♯ Unity

**デフォルトの名無しさん** · 2020/08/30(日) 11:54:12.41

>>251
サンクス。やっぱKotlinの人はスマホが多いのかね。
サーバーサイドだとみんな他に何使ってるんだろう。
まだまだRails多いのかな

**デフォルトの名無しさん** · 2020/08/30(日) 12:27:06.28

うちはJava/SpringBootからKotlin/SpringBootにした
サーバーサイドKotlinはJavaからの移行組が結構多いんじゃないかと思う
次にやるならやっぱりGoかなと思う

**デフォルトの名無しさん** · 2020/08/30(日) 12:35:38.68

Goって糞じゃね
なんで2020のいまどきポインタとか使わないといけないんだよ
スライスもなんか微妙やし
railsみたいに色んな便利機能が最初からないのも糞
大体Google自体もWebアプリ向けに作ったというより
C言語代替を目的に作ったんじゃないの

**デフォルトの名無しさん** · 2020/08/30(日) 13:06:57.56

>>254
全くその通りでGoはホント糞だと思う
でもFargate/マイクロサービス構成にした時にJVMが積み上がってメモリキツキツもつらい
Goの代替としてKotlin/Nativeに期待してたけど全然完成しないし、
Rustも入門してみたけど開発メンバ全員でこれをやるのは無理だなと思った。
なのでマイクロサービスやるんなら選択肢はGoしかないのかなって思ってる

**デフォルトの名無しさん** · 2020/08/30(日) 13:20:08.16

気の利いた機能は排除する代わりに
アホでも書けるように設計してるんだろうな
分かってる人にとっては使うとイライラする

**デフォルトの名無しさん** · 2020/08/30(日) 13:22:05.33

GoとKotlinは使い所が違うわなー
Goはまさにマイクロサービス向きで、Spring Bootで作るようなものにはまったく向いてない

**デフォルトの名無しさん** · 2020/08/30(日) 13:23:00.30

そう思うとJava、というかSpringはほんとよくできてる

**デフォルトの名無しさん** · 2020/08/30(日) 14:25:06.58

jetbrainsがさっさとJSとかモバイルを諦めて、
Kotlin/Native(完成版) + SummerBoot(SpringBootのKotlin/Native版)を
出してくれたら俺のモヤモヤは全部解消する

**デフォルトの名無しさん** · 2020/08/30(日) 14:41:42.24

Goの何が駄目といって名前がほんとうにクソ

**デフォルトの名無しさん** · 2020/08/30(日) 15:29:22.80

検索キーワード入れる度にぶちきれる

**デフォルトの名無しさん** · 2020/08/31(月) 16:31:33.81

>>255
迷走しすぎ

**デフォルトの名無しさん** · 2020/08/31(月) 20:15:30.87

>>262
もっといいのあるん？

**デフォルトの名無しさん** · 2020/08/31(月) 20:24:10.88

**デフォルトの名無しさん** · 2020/08/31(月) 22:28:16.28

GoでマイクロサービスするならfargateよりもGAEの方が良いよ
fargateというかAWS自体重厚すぎる

**デフォルトの名無しさん** · 2020/09/01(火) 13:49:50.85

>>255
同意

**デフォルトの名無しさん** · 2020/09/03(木) 01:24:44.12

Goはこの時代に作ってなんやこのクソ言語ってなるのに使いどころあるところが、良くわかってるんだよなぁ

**デフォルトの名無しさん** · 2020/09/03(木) 11:44:56.18

Goはせめてジェネリック対応してくれ
ジェネリックもない言語とか今どきアホか、としか思わん

**デフォルトの名無しさん** · 2020/09/03(木) 12:44:23.73

>>267
わかる。好き嫌いでいえば嫌いだけど実用性は認めざるを得ない。

**デフォルトの名無しさん** · 2020/09/04(金) 10:54:31.12

モノリシックに作ったサービスを売れてきた段階でマイクロサービス化できるのが真の理想
現状それはGoでもKotlin/JVMでもやりづらい
なので、みんなもっとKotlin/Native&SpringBoot的なFWに期待しようぜ

**デフォルトの名無しさん** · 2020/09/06(日) 00:31:01.15

サーバーサイドだけどKtor使ってるよ

**デフォルトの名無しさん** · 2020/09/12(土) 20:57:55.93

>>271
kotlin/nativeで？

**デフォルトの名無しさん** · 2020/09/16(水) 20:47:09.88

そうか。じゃあそろそろGoの学習でもするか。

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

KtorってNativeで動くの？

**デフォルトの名無しさん** · 2020/09/19(土) 02:20:24.71

ネイティブやるならrustの方が良くない？
kotlinの存在意義ってjavaのライブラリが利用できる事だと思ってた。

**デフォルトの名無しさん** · 2020/09/19(土) 16:43:04.49

JAVAのライブラリと互換性のあるネイティブのライブラリは作りやすいのではないかな

**デフォルトの名無しさん** · 2020/09/19(土) 16:52:33.54

なるほど。

**デフォルトの名無しさん** · 2020/09/19(土) 17:44:18.38

オラクルの訴訟の関係で、Javaライブラリの互換ライブラリは、今は誰もやろうとしないだろう

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

Javaなんて覚えるんじゃなかった。

**デフォルトの名無しさん** · 2020/09/20(日) 11:04:20.31

>>275
Java資産を使わないならあんまり旨味ないよな

**デフォルトの名無しさん** · 2020/09/24(木) 21:05:14.57

ま、今のところはな・・・

**デフォルトの名無しさん** · 2020/09/24(木) 21:13:03.51

ExposedもJava依存してるしなー

**デフォルトの名無しさん** · 2020/09/28(月) 11:21:26.40

Oracleって関わるものすべてダメにするよな

**デフォルトの名無しさん** · 2020/10/11(日) 15:27:38.72

gradleはkotlin dslでも何の不都合もないの？

**デフォルトの名無しさん** · 2020/10/12(月) 20:09:38.21

次のプロジェクトのサーバーサイドを
kotlinにするかgoにするかで揉めとる。
goってそんなにいいの？

**デフォルトの名無しさん** · 2020/10/12(月) 20:51:58.16

その2つで揉めることある？
どんな性質のものを作るかで自ずと決まりそうだけど

**デフォルトの名無しさん** · 2020/10/12(月) 21:58:37.67

goは糞
今時ポインタとかさわりたくねえわ

**デフォルトの名無しさん** · 2020/10/12(月) 23:40:50.80

>>284
少し前まではsyntax heighlightが効かなかったりしていたけど、
今ではgroovyで書くときよりIntelliJの補完やIntelliSenseがよく機能していると思う。

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

goは何が糞といって名前が糞すぎ
なんだよ、goって

**デフォルトの名無しさん** · 2020/10/13(火) 08:15:37.13

goでググりにくい
ググラビリティが低い

**デフォルトの名無しさん** · 2020/10/13(火) 08:20:05.71

goとこちょりんで揉めるのがどういう状況なのか想像できない
何を作ろうとしてるんだよ