Pull to refresh

Comments 26

Для проведения четкой грани, хотел бы спросить. Предлагается ли какое-то решение для сборки iOS-бандлов? Или подразумевается, что можно компилировать в JS, а дальше собирать через phonegap, cordova и т.п., для последующей работы через webview.

См. kotlin native.


Как:


It comprises a LLVM-based backend for the Kotlin compiler and a native implementation of the Kotlin runtime library

И где:


Kotlin/Native currently supports the following platforms:

Windows (x86_64 only at the moment)
Linux (x86_64, arm32, MIPS, MIPS little endian)
MacOS (x86_64)
iOS (arm64 only)
Android (arm32 and arm64)
WebAssembly (wasm32 only)

Кто-нибудь использует kotlin как заиену js в проде? Поделитесь опытом, как оно там? Js получается адекватный?

Тыкал несколько месяцев назад — адекватность в плане раздувания кода где-то на уровне babel. То есть ООП инициализируется максимально корректно со всякими defineProperty и т. д., есть немного специального кода для поддержки пакетов. Но сам алгоритм более-менее дословно преобразуется.

Однако, у Kotlin есть пара особенностей:
1) Что символы, что строки часто используют обёртки от Kotlin.
2) Нет switch на уровне языка, when же всегда преобразуется в набор if. Не знаю, плохо ли это.
есть немного специального кода для поддержки пакетов

Уже давно нет. Пакет — просто пустой объект JS, куда накидываются свойства.


Что символы, что строки часто используют обёртки от Kotlin

Не совсем. Строки точно никогда вообще не оборачиваются. Символы в ряде случаев оборачиваются, но тут есть нюанс: в JavaScript вообще нет понятия "символ", можно его представлять как строку из одного символа, можно как число. Но и в том и в другом случае нельзя отличить на рантайме символ от строки или числа. А если всё же хочется, приходится оборачивать.


Нет switch на уровне языка, when же всегда преобразуется в набор if. Не знаю, плохо ли это.

Как раз недавно пофиксили, см. KT-21160.

Тоже пробовали Kotlin. Код как после сборщика. По скорости немного медленнее, но это только на тестах и незаметно для пользователей. В принципе уже сейчас можно использовать для проектов. В планах попробовать Kotlin для nodejs на более серьезном проекте
Очень хотеть длинные числа в стандартной библиотеке… Ибо привязка к java.math.BigInteger и отсутствие условной компиляции в языке не позволяет держать одну кодовую базу для двух платформ. А между тем в JS я так и не встретил ни одной полной библиотеки для длинной арифметики — да, все умеют сложение-вычитание-умножение-деление, но как насчёт битовых операций? (конечно, их реализовывать очень легко, но хочется целостного решения, а не копаться в потрохах объектов)

Вполне возможно что появится мульти-платформенная реализация для длинной арифметики. На JVM это будет компилироваться в BigInteger, на других платформах скорее всего потребуются кастомные реализации.


Заводите тикет в баг-трекере, формулируйте спецификацию, пишите прототип. Котлин очень близко работает с сообществом, и многие фичи появиличь именно таким способом.


PS Скорее всего длинная арифметика будет не в стандартной библиотеке, а в соопутствующей библиотеке kotlinx, так что имеет смысл писать сразу туда. Или вообще делать свою биюлиотеку.

Ещё вы можете компилировать Kotlin в JS не через Kotlin/JS, а через вот это, и использовать хоть BigInteger, хоть всякие локали, форматы, даты и т.п.

Вот мне интересно зачем? Отличных языков под JS полно, с точки зрения скорости разработки и надежности написанного ПО, ClojureScript, TypeScript, и т.д. если у вас очень большой SPA. В други случая зачем менять JS, имхо отличный язык — потому что простой.
Под JVM для server side есть так же куча отличных языков Clojure, Scala, Groovy и т.д. которые несут новые концепции а не просто немного синтаксического сахара.
Может кто-то объяснить, приведя хотя бы несколько существенных преимуществ над Java? Только без Null Safety, пожалуйста. А что-то действительно существенное.
А так же что Kotlin дает для разработки front-end'a? Кроме возни и гемора с классами и как следствие тонн всяких конверторов JSON->Object и обратно?

А так же что Kotlin дает для разработки front-end'a

То же, что node.js даёт для разработки бэкэнда, а именно — возможность писать всё на одном языке. Дальше обсуждать бессмысленно, потому что есть 1000 мнений на этот счёт. Но уже одно то, что node.js есть и собирает большое коммьюнити, говорит о том, что идея иметь один язык для всего, не так уж маргинальна.


Кроме возни и гемора с классами и как следствие тонн всяких конверторов JSON->Object и обратно

kotlinx.serialization всю возню берёт на себя, это должно упростить жизнь.

Вы вырвали фразу из контекста и прилепили к ней кажущееся очевидным, но по сути некорректный контраргумент.
Тот что однороднось font-end и back-end с точки зреция общего языка, Может Быт хорошей идеей это факт беспорный т.к. нужно знать только 1-н язык и можно использовать абстракции не доступные в JS но доступные в другом языке и т.д…
Но язык этот должен подходить и для front-end и для backend. Если вы будете использовать C++ или Go для фронта, то ничего кроме раздутых сроков и бюджета не получите, для подавляющего числа проектов, надесь понятно почему?
А тут получается что котлин и для бэка не очень, т.к. есть другие альтернативы и получше. Так и для фронта не очень, т.к. придется писать кучу ООП шного кода, вместо простого JS или аналогов.


Для начала вы ответьте на вопрос зачем использовать колтин для разработки back-end'a, если есть другие альтернативы и они полуше, на мой взгляд, т.к. не являются незначительным улучшеним ситаксиса Java, а потому вопрос с фронтом сам отпадет, хотя я его уже обосновал, через резульат который вы получите — кучу ООП гемора и увеличение сроков, как следствие.


Возможно вы просто кроме Java ни на чем и не программировали, поэтому вам котлин кажется глотком свежего воздуха, во всяком случае я не вижу другого объяснения, почему вы считаете небольшое кол-во синтаксического сахара, чем то прорывным и вообще достойным внимания.

Вы вырвали фразу из контекста и прилепили к ней кажущееся очевидным, но по сути некорректный контраргумент.

Контраргументов я не приводил. Ответил на вопрос "зачем Kotlin/JS", который является подмножеством заданного вопроса (по остальной части вопроса позиции не имею, поэтому оставил ответ другим комментаторам). Ответ таков: если кто-то считает Kotlin уместным на бэкэнде, то ему приятнее будет писать на Kotlin на фронтэнде (как раз аргументы в пользу этого я привёл).


Но язык этот должен подходить и для front-end и для backend. Если вы будете использовать C++ или Go для фронта, то ничего кроме раздутых сроков и бюджета не получите, для подавляющего числа проектов, надесь понятно почему

Нет, мне вовсе не понятно, почему. Особенно, если мы говорим об абстрактной задаче в вакууме. Для каких-то задач C++ или Go не подходят, очевидно, для каких-то подходят. На фронте задач разных хватает. Держу пари, что у ребят из какого-нибудь ONLYOFFICE задачи такие, для которой 90% существующей JS-экосистемы, с вебпаками и ангулярами не подходит. А ещё ведь есть игровые движки (ради которых, как я понял, и затевалась вся движуха с WebAssembly).


и для фронта не очень, т.к. придется писать кучу ООП шного кода, вместо простого JS или аналогов.

Ну тут я сильной позиции не имею. Можете ваши аргументы высказать, не стесняюсь. Сам имею опыт написания больших приложений на GWT и лично придерживаюсь непопулярной точки зрения, что GWT хорош, а Kotlin/JS — это своего рода GWT для Kotlin.


Для начала вы ответьте на вопрос зачем использовать колтин для разработки back-end'a, если есть другие альтернативы и они полуше

Я не могу ответить на этот вопрос. Кто использует Kotlin для бэка, тот на него уже, видимо, имеет какой-то ответ.


Возможно вы просто кроме Java ни на чем и не программировали

Программировал. На ABAP, 1С, C#, немного C — в прод, и на Nemerle, Scala, Haskell, Scheme — в стол.


во всяком случае я не вижу другого объяснения, почему вы считаете небольшое кол-во синтаксического сахара, чем то прорывным и вообще достойным внимания

Я так не считаю, где я про это сказал? Я вообще лично не против продолжать писать на Java, если надо. Не во всех задачах Kotlin, Scala или какой-нибудь Haskell добавляют существенной продуктивности разработчикам (а иногда, наоборот, лишь убивают её), так что надо прежде всего смотреть на задачу, которую вы решаете, на ваши реалии.

А тут получается что котлин и для бэка не очень, т.к. есть другие альтернативы и получше

С чего вы взяли что он для backend «не очень»? Про другие альтернативы, которые, как вы утверждаете, получше, можно долго спорить. Все сильно субъективно. Могу лишь посоветовать вам попробовать самому написать что-нибудь на Kotlin и решить для себя, плох он или хорош.
Так и для фронта не очень, т.к. придется писать кучу ООП шного кода, вместо простого JS или аналогов.

Вы не путаете Kotlin с Java 6? В Kotlin есть много других сущностей помимо классов и интерфейсов, на нем можно писать без всякого ООП.

Ну я даже не знаю… задавать вопрос «зачем» в комментариях к посту, в котором мы рассказываем о том, какое распространение получил Kotlin? Зачем же, интересно, люди из Google, Pivotal, Gradle и многих других компаний вкладывают столько ресурсов в поддержку технологии, которая несёт так мало новых концепций? Возможно, потому, что продуктивность работы программиста определяется не только тем, сколько новых концепций несёт в себе язык, которым он пользуется?

Про возможности Kotlin вы можете узнать в очень многих местах, начиная с официального сайта языка, и дальше вам уже решать, какие из этих возможностей вы считаете существенными.
Ну я даже не знаю… задавать вопрос «зачем» в комментариях к посту, в котором мы рассказываем о том, какое распространение получил Kotlin?

А где задавать данный вопрос? Мне интересно что люди находят в языке, раз он по вашим словам быстро растет. Не вижу проблемы, с вопросами.


Я прочел всю спеку котлина, но ничего интересного не нашел, в Scala, Clojure больше возможностей и они позволяют намного проще писать ПО и надежнее. У них есть как минимум тоже что в котлине на 99%. Что тогда дает котлин? По вашим словам новые концепции это не важно, может быть в языке какие то старые концепции реализованы лучше? Я хочу понять, т.к. не нашел не одного преимущества.


У Google поддержка ограничивается Android, это и понятно, только здесь у котлина есть преимущество и только одно — Scala и Clojure имеют свой не маленький по размерам рантайм, что не позволяет их использовать в разработке под Андроид.

проще писать ПО

может быть короче? на Scala точно не проще
Что тогда дает котлин?

Простой и с Java-like синтаксисом код
Нет, вопрос-то задавать можно, конечно, просто я не знаю, как на него отвечать. Особенно трудно с утверждениями про то, что в Clojure есть на 99% то же, что в котлине — учитывая, насколько эти языки друг на друга не похожи.

Вот, например, поддержка nullability. Мы считаем, что это преимущество. Очень многие люди, которые используют Kotlin, тоже так считают. С вашей точки зрения, это преимуществом не является. Какого продолжения разговора вы ожидаете? Я мог бы называть вам другие фичи, которые на наш взгляд являются преимуществами, но не очень понимаю, зачем это делать, если вы уже с ними со всеми ознакомились и ничего хорошего в них не нашли.
Подскажите, пожалуйста, я ничего не путаю, текущее положение дел — до сих пор нужно подключать руками к проекту kotlin.js?

Ну, то есть, суммарно проект выглядит как-то так:

package org.jetbrains.foo

expect class Foo(bar: String) {
    fun frob()
}

//////////////////////////////////////
import org.jetbrains.foo.Foo

actual class Foo actual constructor(val bar: String) {
    actual fun frob() {
        println("Frobbing the $bar")
    }
}

fun main(args: Array<String>) {
    Foo("Hello").frob()
}

//////////////////////////////

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Title</title>
</head>
<body>


<script type="text/javascript" src="kotlin.js"></script>
<script type="text/javascript" src="untitled-js.js"></script>
<script type="text/javascript" src="untitled-js.meta.js"></script>
</body>
</html>

Да. На всякий случай, чтобы предупредить возможные возмущения, что kotlin.js — огромная библиотека, дам эту ссылку. И третий элемент script не нужен — meta.js используется только компилятором. Кстати, это уже является во многом вашим выбором, но насколько мне известно, люди предпочитают проект на Kotlin/JS паковать с помощью webpack, с котором Kotlin совместим.

Никаких возмущений, я пишу бэкенды и радуюсь жизни :)

Извините, ещё один вопрос (не смог найти на kotlinlang.org/docs/tutorials/javascript/kotlin-to-javascript/kotlin-to-javascript.html ), а где вообще предполагается брать файл kotlin.js?

Я лично взял его из \.gradle\caches\modules-2\files-2.1\org.jetbrains.kotlin\kotlin-stdlib-js\1.2.0\bd74054944b9f4e8a8b290248ecb591dcf1810f4\kotlin-stdlib-js-1.2.0.jar!\kotlin.js, но уверен есть какой-то более простой путь.

Проще всего, пожалуй, включить DCE — он сам распакует и порежет kotlin.js. А так, можно всегда написать copy task в gradle, который вытащит kotlin.js из нужного артефакта. Где-то в документации была (устаревшее) руководство по этому поводу.

Нашёл конкретную ссылку


Правда, условие path.startsWith("META-INF/resources/") || !path.startsWith("META-INF/") надо убрать.

Нормально так DCE поудалял ненужного (в 10 раз) — с 1500 КБ до 140 КБ. Правда это пустой проект, но всё равно выглядит круто.
Sign up to leave a comment.