Kotlin 4
■ このスレッドは過去ログ倉庫に格納されています
JetBrainsが開発した期待の新言語、Androidの公式開発言語にしてサーバーサイドもなんでもいけるKotlinについて語りましょう https://kotlinlang.org ※前スレ http://mevius.5ch.net/test/read.cgi/tech/1521401186/ >>783 emojiのおかげでそのへん心配する必要はほぼ無くなったな >>788 代わりに極めて高い確率でKotlin nativeそのものが頓挫しコード資産や経験がパーになるリスクを背負うことになるけど、それでもよければ >>783 あるかなあ?元から国際化考えて作られたものだからnativeになったからといって新たにそれのバグが追加されるとは思えんが。 >>790 私がKotlin native習得に挫折するなら話は分かりますが、Kotlin nativeそのものが頓挫することは ないんじゃないでしょうか? >>793 普通にあるよ 何を勘違いしてるのか知らないが、たかが小さな会社の俺プラットフォームでプロダクションには現状誰も使ってないんだぞ? そんなもん毎日のように腐るほど生み出されては消えていっている 逆に成功したら超ラッキー、くらいのレベルだ Kotlinユーザーってほぼ例外なく他の言語も使えるから、Javaがゴタゴタしてるからって無理にKotlinに固執する理由もない 言っちゃ悪いけど、他に選択肢を持っている人がオモチャとして観察するフェーズであり、キャリアを賭けるようなもんじゃない これから新規でクロスプラットフォームでアプリ作るとしたらflutterとkotlin nativeどっちがいいんすか >>794 なるほど、社内でのKotlin nativeプロジェクトにおける開発という意味で頓挫と仰っておられたのですね 了解しました Kotlin自体の開発元のJetBrains社によるKotlin native開発の頓挫のことを指してるのかと思ってしまったので。。 確かに現場視点から見ると、著作権云々より色々考慮しなくてはいけないことがあるんでしょうね 私の元々の質問の意図は、Kotlin nativeで作成したネイティブバイナリのコードであれば、Oracleの著作権 侵害とは一切関わりのないコードが生成できるのかと確認することでした 実際の現場での開発運用までいくと、会社による顧客へのサポート対応とか諸々の課題を当然考慮しないと いけないでしょうが、今回の質問はそこまで踏み込んでおらず、あくまでOracleの著作権の影響範囲とその 回避について、Kotlin nativeの開発は有用か尋ねたつもりでした 多分私を学生だと思われて、現場の泥臭いことを教えていただいたのですね 勘違いさせてすみません 50近いオッサンが、趣味と好奇心の延長で質問したことですので >>797 そうじゃなくてJetBrainsによるKotlin native開発が頓挫する話だ JetBrainsはMSやOracle、Googleといった力押しで言語を普及させることのできるような企業と比較すれば遥かに「小さな会社」だよ 趣味なら好きにすればいいし、頓挫しても経験は決してゼロにはならないけど、 Javaロックインよりも遥かに大きなリスクを抱えることになるというのは理解しておきなさい >>794 に禿げ上がるほど同意しすぎて禿げたわ まだまだおもちゃとしか言えないレベルだよな。 とは言え一年前に比べたらだいぶ進化してるから、一年後にどうなってるかはわからない。 >>798 なるほど、まだKotlin nativeは使い物になるレベルに達していない代物なのですね 色々ご教授いただき、ありがとうございました。 正直、従来のKotlinとKotlin nativeとの言語としての完成度の差を知らなかったので、 大変勉強になりました 今は、(Kotlin nativeではなく)ノーマル(従来)のKotlinを触って勉強したいと思います 現状大差ない どちらもプロダクトに投入してる例はあるけどまだまだこれから React Native + Kotlin/JS + Objective-C でアプリ書いてるけど React Native + Kotlin/Common + Kotlin/Native (RCT_EXPORT_MODULEだけObjC) を考えてる >>804 Kotlin使ってるならObjCじゃなくSwift使えよ 構文とか似てるし >>804 なんでそんな目に見える苦行の道を選んだのかw >>806 以前別アプリで使ってたけど型推論あるとビルドクッソ遅いの直ったの? ちょっとでも欠点を見つけるとそれを理由にして新しいものを拒否するやつってどこの世界にも必ずいるよな それ以上に、古いものの欠点を過剰に騒ぎ立てて新しいものをゴリ押ししようとする奴のほうが多い気がする あと個人的な経験でいうと、新しいものの欠点はむしろ検討段階で見落とされて後で問題になることが非常に多い 新規導入におけるビジネス判断って、フィーチャーだけに目が行って非機能仕様や細かい制約はあまり考慮されないもんだ 今ある問題に目を瞑って現状維持に固執するやつは多い 新しいものを見ると特に検証もせず推し進めるやつもいる 新しいものを受け入れられなくなった時が老化の始まりだと思っている 人は歩みを止めた時に、そして挑戦を諦めた時に年老いてゆくのだと思います。 このソフトを使えばどうなるものか。 危ぶむなかれ、危ぶめば道はなし。 踏み出せばその一足が道となり、その一足が道となる。 迷わず使えよ、使えばわかるさ ありがとう! 都合よく自分の使いたいものを想定して一般論を語るのはいけない こんな糞パッケージや糞製品導入した奴は子ねって思ったこと、ITエンジニアならあるだろ? 自社が製品として販売しているオリジナルフレームワークを自社サービスで使っているせいで仕事を辞めたことはある。 本当に、本当にゴミフレームワークだった。 >>814 その新しいものとやらが実際には価値のないものだったら動かない方が勝りますね 重要なのは新しいか古いかではなく、自分の望みを叶える事に使える道具かどうかだ。 >>819 叶えるのに最適かどうか、と言わないとC言語でなんでもできるおじさんがやって来るぞ。 >>820 そういやそうだな。 C、そしてアセンブラ最強になってしまう。 Kotlin の Char には isAlphabetic() がないのな。 しょうがないからプログラムの上の方にこんなの作って使っている。 fun Char.isAlphabetic() = Character.isAlphabetic(toInt()) こういうのってこうやって簡単に作れちゃうから最初から標準のライブラリに入れてないんだろうか? しかし最初からあってくれた方が楽と言えば楽だなあ。 直接JavaのAPIを呼ぶべきだからだよ そんな基準でKotlin版作ってたらキリがない そもそもCharacterのメソッドってプログラマの使いやすさよりもUnicodeの仕様を正しく反映することを意図して作られていて、 そんなに頻繁に使うようなものではないだろ 知ってると思うけどisAlphabeticって平仮名とか含むんだぞ? おっUnicodeのクソさならおじさん語っちゃうぞ クロスプラットフォーム狙うなら用意しなきゃ駄目だな >>825 じゃJstarの開発マニュアルから初めてくれ 全て聞き流してあげよう >>824 Charでやっといてくれればnativeでコンパイルする時にもそのままにできるという利点がある。 なんでByte型に符号が必要なんだろ。 扱いづらすぎ c#のbyte型にしてたもんせ そして符号付きbitシフトとかどこで使うのか、今でも意味不明 Javaの負の遺産を引きずってるなー Kotlinがそれなりに流行ったのはJavaの呪いを受け入れたからに他ならない その代償がその程度であれば小さいもんだろう javaつうか元々cの右シフトの挙動が定義されてなかったから、それを引きずってるだけ まあそこらへんは存在したとしてもどうせ使うことはないだろうから別にいいよ >>830 シフトに関しては符号付き、符号無しの区別は重要だと思いますよ ビットシフトはビットシフトで考えたほうが早いオールドタイプを宥めるために存在する 彼らの言う「ビットシフトでやったほうが速い処理」が必要な、いつか来る未来というのは結局来ずに終わる可能性のほうが高い 残りの折り返し見えた人生、来るほうにかけて生きてもいいけどさ >>837 冪剰余のバイナリ法をみても、ビットシフトは重要だと思いますよ… 符号無しシフトは非常に稀には使うけど 符号付きシフトは使った記憶がない とはいえKotlinでは記号じゃないから負の遺産とは思わないな C++みたいに右シフトがtemplate構文の邪魔するとかなったら呪縛もいいとこだけど ビットシフトを使うほどカリッカリにパフォーマンスに拘る時にkotlin、というかjvm言語を使うかって話よね。 必要な場面があるのは分かるけど、今時のサーバーで普通のシステムを動かす前提なら普通はまず求められないし、可読性を犠牲にしてまで使うべきだとは思わない。 主に移植性や相互運用性のために残ってるだけで批判の対象になるようなケースはほとんど実在しないと思うけどな >>839 >右シフトがtemplate構文の邪魔するとか C++11 lator でこの制限はなくなりました 使うシチュエーションは確かにあるけどものすごく稀だな あれば2年に1回くらいは使うかもしれないけどなかったらなかったで別に困らない ビットシフトな。実務で使うことはまあないな。 何かの解析とか組み込み系なら多用するだろうけど、そんなところではそもそもこちょりん使わないだろう。 ビットシフトは画像処理やBluetoothで使いまくるぞ だからそういうのを自前で実装するケースってそうそうないやろ、って話でしょ 元々ビット単位で詰め込んであるようなデータの解析には使った方が見易くなるかも知れない。ネットワークのパケットとか、その他色々あるよね。 もちろん割り算や余り計算すれば特定のビット抜き出す事はできるし、恐らく最適化されると最終的なコードは同じになるだろうけどね。 なのでどう書くと見易くなるかの問題だな。16で割って8の余り出すように書くか 4 ビット右シフトして 7 を and するように書くか。 だいたいは後者の方が見易く分かりやすいかも知れないが、場合によっては前者の方が良いかも知れない。 ビット操作するなら素直にビット操作演算子つかえばいいんじゃね ことりんはわり算した時のビット内容に規定があるのかわからんし なんだ、低レベルな処理をkotlinで書きたい人って結構いるもんなのか。 そういうのはCか最近ならGoあたりを使うと思ってた。 最初は普通にkotlinで書いて、ボトルネックになるようならネイティブに逃がすでしょ。画像処理とか明らかにヘビーなことやるなら最初からネイティブで書くけど。 ところでkotlinネイティブで、本体の部分はJVMとかでkotlinで書いて、ヘビーな部分はkotlinネイティブで書いて利用するとか芸当簡単にできるようになるのか? 例えばandroid画像処理アプリ本体はdalvikのkotlinで動かして、画像処理本体はkotlinで書くけどネイティブでとか。 論理的にはできるはずだから、パフォーマンス比較してみたいなそれは 透過的にできるようになるといいな。例えばメソッドに native 付けておけばそのメソッドは自動でネイティブにコンパイルされるとか。 Androidならともかく、PCの方の非海賊版JVMのパフォーマンスをnativeが超えるのは相当難しそう >>855 LLVMのコードってほとんどただの抽象化された機械語だから、 Kotlinを動かすならこれまでJVMに依存してたランタイムの機能を独自に相当作り込まなきゃいけないよ 10月初めのと基本同じ情報だけど日本語で来てるから貼っとく Kotlin 1.3リリース ? コルーチン、Kotlin/Nativeベータ https://blog.jetbrains.com/jp/2018/10/30/1511 これだけの大幅機能追加なら、そろそろJavaみたいにKotlin3とかに名前変更してもいいと思うけどな Goとかrustみたいに、システムプログラミング向けとしてもkotlin /native は使われる将来性はある? >>861 プリミティブのintと参照のIntを明示的に区別する仕様ではないから向いていないのではと思う。 >>861 低いレイヤーを直接触るようなことはやりにくいから、あえて使う理由もないと思う 出来ないことはないだろうけど 参照型にnullを許さないってのも、微妙だな 書いてて疲れる。 hoge?.fuga とか hoge!! とか返って可読性が落ちてる希ガス >>864 そうだよ 面倒だから使いたくないでしょ 使わないようにしたいんだよ だからそうなっている arcだとすると既存プログラムはコードを書き換えないといけない場合があると思うけど、それを承知で採用してるの? やってみたかっただけでしょ 所詮オモチャなんだから ARC with cyclic collector というのをちらほら見る 弱参照を使わなくても既存コードのままで問題無いようだ ただこれがGCのような停止時間を発生させるかなどはよく分からなかった 諸々の問題の解決を試みているうちに、気がついたら出来上がったものはGCそのものだったというオチになりそう 既存の枯れた技術を舐めてかかって自分で実装してみてはじめてそれが十分に優れていたことに気付く 技術の過度な抽象化による間違った万能感に陥りがちなITエンジニアにはよくあること オリジナル言語を頑張って作ったが結局動作的にLispになったみたいな話だな そのまんまでしょ。弱参照ないARCで管理するが、循環参照用に定期的にGCは走らせる。 だから循環参照するクラス大量だとフルGC走らせるのと同じことになるが、大抵のプログラムでは循環参照するクラスはそんな大量じゃないので大抵のケースではARC with cyclic collectorの方が速くなるとか ところでkotlinにweak reference見たいのあったっけ? >>875 nativeでは kotlin.native.ref.WeakReference jvmでは java.lang.ref.WeakReference が有る jsには無いからcommonにも無い javaや.netにあるのは知ってるから質問けど そっか、所詮、最大公約数になるから他の言語に引きずられまくりでjsとかにねぇからkotlinで標準で用意されてねぇのか。 いやKotlinに無い理由はJavaにあるからだよ 建前はともかく、実態はAltJavaとしてしか使われてないしJBもそれを前提に開発してるのが実情 現状だとメモリ管理は対応プラットフォームの機能に寄生するみたいな感じになってるのは気になるね iOS向けだとiOSのARCを利用するし、Cなら手動で開放してる Kotlin/Native として統一的なメモリ管理機構を作らないと、プラットフォームを超えたコードの共有化とかはかなり限定的なものになりそう しかし統一的なメモリ管理機構を言語で用意すると、プラットフォーム側で用意してるメモリ管理機構と重複部分ができて無駄だなとも思う Xamarinとかはそんな感じだし ARCはOS関係無くね、Swiftと同じく普通にコンパイラとランタイムによる実装でしょ 現時点でcommon書くときメモリに関して支障は感じないけど メモリ管理機構ってJVM上やJS上でどういうのを想定してる? JS はランタイム側でGCやってくれるし、JVMもGCやってくれるので、 アプリケーション側の kotlin コードでメモリ開放する必要ないし、循環参照とかも意識する必要ないでしょう Kotlin iOS では、Swift や Obj-C と同じランタイム側にあるARCを使っているのではないのかな? この場合アプリケーション側の kotlin コードでは、循環参照とかを意識しなくてはいけないのでは? Cライブラリを使ってLinux上で直接動くような Kotlin Native コードの場合には、 malloc や free に相当するもので手動でメモリ確保開放とかやる必要があったりしますよね? https://kotlinlang.org/docs/reference/native/c_interop.html んなわけあるかい LLVMで普通に直接動く実行コードを生成してるだけで、iOSのオブジェクトモデルとは別物だ iOSに循環参照を自動的に見つけて解放してくれるって事実上の独自GCやぞ そんなもん勝手に組み込めるんならみんなとっくにやっとる var x = Foo() Bar(x) x = Boo() 以上のような Kotlin コードをコンパイルしたときに、Boo()の結果を x に代入するまえに x に入っていた Foo() への参照をどう処理するかってこと Bar(x)の結果、だれかが x に入っていた Foo オブジェクトへの参照を保持している可能性がある JVMやJSだと単に x を上書きするコードにコンパイルすればいいよね iOS向けにコンパイルするときには release(x) みたいなのを含んだ LLVM コードに変換される? もしくは、Kotlin が独自の ARC みたいなの持っていて、それに応じた処置がおこなわれるの? Linux 向けの Kotlin / Native でコンパイルはこのままできるのかな? >>882 >>884 ObjCランタイムは普通にCのABIのライブラリ群だから 純粋なC言語から呼べるしKotlin/Nativeからも呼べる iOSでもLinuxでもプラットフォームのAPIを使うには それに沿ったメモリ構造や解放関数の呼び出しなどのリソース管理が必要だけど 外部呼び出しを除いたKotlin/Nativeの部分にmalloc/free/releaseなどは必要無いよ >>885 そうすると、 Kotlin / Native で普通に確保したオブジェクトの解放はどういう方式で行われているのかな? リファレンスカウンタ? GCでは無いよね? リファレンスカウンタだとすれば、Kotlin/JVMでは問題無いオブジェクト同士が参照しあう構造は、避けないとダメだよね ここで不毛な言い争いするくらいなら実際にコード書いて試せばいいのでは。。 >>886 >>873-874 と https://github.com/JetBrains/kotlin-native/blob/master/FAQ.md > Q: What is Kotlin/Native memory management model? > A: Kotlin/Native provides an automated memory management scheme, similar to what Java or Swift provides. The current implementation includes an automated reference counter with a cycle collector to collect cyclical garbage. ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる