LINUX.ORG.RU

Что вы думаете сегодня про Kotlin Native

 ,


1

2

Насколько эта технология имеет смысл?

Есть ли шансы мигрировать существующие Java-проекты со Spring на неё?

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

Рынок труда по java на порядок шире, чем по голанг, и гораздо больше выбор предметных областей. Заниматься хайлоадами и бекендами, честно говоря, скучно.

Но jvm и всё вот это нагоняет грусть. Kotlin Native выглядит на вид неплохо, но хочется понять, это реальная технология или просто маркетологическая замануха.

★★★★★

Ответ на: комментарий от anonymous

Думаю, этот пример чуть лучше объяснит, почему return так работает и зачем это сделали.

inline fun forEachInt(array: Array<Int>, body: (Int) -> Unit) {
    var i = 0
    while (i < array.size) {
        body(array[i])
        i++
    }
}


fun findFirstEven1(arr: Array<Int>): Int {
    forEachInt(arr) { x ->
        if (x % 2 == 0) {
            return x
        }
    }
    return -1
}

fun findFirstEven2(arr: Array<Int>): Int {
    for (x in arr) {
        if (x % 2 == 0) {
            return x
        }
    }
    return -1
}

Legioner ★★★★★ ()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от anonymous

Так на жабу сколько сикурити фиксов делали, сколько дыр закрывали, сан пыталась, затем оракл, так за 15 лет и не получилось. В общем апплеты запускать было стремно, под конец даже броузеры предупреждали об опасности запуска апплетов, но держали до последнего из-за банков. Я думаю даже JNI использовался, для токенов/ключей которые в usb втыкались и позволяли подписывать операции.

anonymous ()

Kotlin вообще смысла не имеет, убогенький недоязычек. Причём Native, а он, насколько я знаю, дюже сырой. Под натив есть много хороших языков, даже не рассматривать совсем хачкели всякие, OCaml, Dlang, Common Lisp твой любимый. Почему Kotlin Native то?

BIALYSTOK ()
Ответ на: комментарий от vertexua

Ну вот серезно так ментальной мощности не хватает чтобы изучать новые языки по методичке за неделю-пару месяцев?

Да легко! Настоящий программист на фортране напишет... нутыпонел. Но это во времена былинные, когда дискеты были большие, а кодовая база маленькая. Сейчас ты просто утонешь в говнокоде фреймворков и корпоративном легаси, будешь полгода только втыкать как оно вообще работает и что с чем в каком порядке соединять. Знание ЯП тебе никак тут не помогут.

anonymous ()
Ответ на: комментарий от Aber

спасибо. А стектрейсы так по сей день и без номеров строк? Я что-то не понял тут жизненный цикл:

https://github.com/JetBrains/kotlin-native/issues/1816

Бага закрыта по таймауту что ли, чтобы не портить статистику? Или они сделали, но не отписались здесь?

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от hbee

Ну, для многих российских програмеров это такой реалистичный план на пенсию

Я тебя умоляю, какая пенсия. Чтобы дожить хотя бы до 60, надо завязывать с комплюктером лет в 30.

anonymous ()
Ответ на: комментарий от BIALYSTOK

даже не рассматривать совсем хачкели всякие, OCaml, Dlang, Common Lisp твой любимый. Почему Kotlin Native то?

Они все уже не взлетели, а котлин еще может.

anonymous ()
Ответ на: комментарий от yyk

Для поставщика ПО - более чем, ведь вместо лицензии можно будет продавать подписку, а баги платформы делегированы разработчику браузера.

Для потребителя - зависит от ситуации.

Ford_Focus ★★★★★ ()
Ответ на: комментарий от Ford_Focus

Webassembly работает медленней нативного кода. Полноценного графического API по-любому не будет, т.е. графика тоже будет априори ущербная. Поэтому потребитель в любом случае проиграет. Впрочем такого не будет, разве что самые примитивные инструменты или нетребовательные к производительности будут в браузере. CAD-ы и прочее не будут. Люди просто будут пользоваться локальным софтом, который работает в разы быстрей, лишь бы выбор оставался. А так в браузер они могли перелезть хоть 15 лет назад. Ничего с тех пор не изменилось. И C++ можно было в жаваскрипт компилировать сто лет назад. Никому это не надо по большому счёту.

Legioner ★★★★★ ()
Последнее исправление: Legioner (всего исправлений: 4)
Ответ на: комментарий от Legioner

Я в целом понял что ребята попытались сделать более человечные лямбды, чтобы ненужно было лямбду менять на for-loop для таких вещей. Но на мой взгляд хватило бы просто записи из лямбды во внешнюю переменную. Все таки возврат из функции, минуя лямбду эт не самое распространенное явление. Это поведение продиктовано особенностями результирующего байткода? Все такие вещи автоматически разворачиваются в код без замыканий?

anonymous ()
Ответ на: комментарий от anonymous

Реализация null-safety просто омерзительна

По сравнению с чем? Вполне нормально там все.

Синтаксис с лямбдами в качестве параметров совсем трешовый

Наоборот нормальный, лишних скобок нет.

anonymous ()
Ответ на: комментарий от anonymous

Обрати внимание на слово inline у функции myForEach. Это означает, что это не настоящая функция, а её тело будет встроено в месте вызова. И её аргументы-лямбды тоже не настоящие функциональные объекты, а их тело будет встроено в месте вызова. Поэтому возможно сделать return. Если убрать inline, то всё будет по-настоящему, но return уже не скомпилируется.

В частности вот код mapNotNull:

public inline fun <T, R : Any> Array<out T>.mapNotNull(transform: (T) -> R?): List<R> {
    return mapNotNullTo(ArrayList<R>(), transform)
}

public inline fun <T, R : Any, C : MutableCollection<in R>> Array<out T>.mapNotNullTo(destination: C, transform: (T) -> R?): C {
    forEach { element -> transform(element)?.let { destination.add(it) } }
    return destination
}

public inline fun <T> Array<out T>.forEach(action: (T) -> Unit): Unit {
    for (element in this) action(element)
}

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

Legioner ★★★★★ ()
Последнее исправление: Legioner (всего исправлений: 2)
Ответ на: комментарий от Legioner

Webassembly работает медленней нативного кода

но, в общем случае, быстрее c# и java, что уже очень даже

Полноценного графического API по-любому не будет, т.е. графика тоже будет априори ущербная

webgpu (web vulkan) вроде как уже включается флагом в google chrome canary

А так в браузер они могли перелезть хоть 15 лет назад

15 лет назад не было 10-ядерных мобильников, айпадов, ChromeOS, гигабитных сетей и еще много чего - связки wintel хватало всем и для всего.

И вообще десктопный Linux вряд ли имел хотя бы половину сегодняшних юзеров в абсолютном выражении

Ford_Focus ★★★★★ ()
Последнее исправление: Ford_Focus (всего исправлений: 1)
Ответ на: комментарий от Ford_Focus

но, в общем случае, быстрее c# и java, что уже очень даже

Пруф?

webgpu (web vulkan) вроде как уже включается флагом в google chrome canary

Любое веб апи обязано быть безопасным и изолированным. А значит там будет миллион проверок, стандарты будут отставать на годы от актуальных. В хроме включается, а в фаерфоксе включается? Что насчёт сафари? Когда будет? Или работаем по принципу Chrome new IE?

Legioner ★★★★★ ()

Но jvm и всё вот это нагоняет грусть. Kotlin Native выглядит на вид неплохо

Что за нубское видение? Зачем тебе компилировать Spring в Kotlin Native, что ты этим хочешь достичь, чего не достигнешь через JIT? Ты уверен, что этот Native будет оптимальнее JIT в рантайме? Или просто тебя легко зомбонуть умными базвордами?

foror ★★★ ()
Ответ на: комментарий от bread

Кто не успел в 90-е появиться и в нулевые закрепиться, тот опоздал.

Полнейшая глупость. Используя накопивший опыт ИТ можно сделать очень качественный новый ЯП. Но делать его должны не очередные пердуны из 70-х или копроразрабы.

foror ★★★ ()
Ответ на: комментарий от dave

Современное программирование в своей массе, вообще, не особо, чтобы интересным было.

А причём тут современное программирование? Здесь скорее современные государства и корпорации ставят перед программистами в своей массе скучные цели. Так то современное желело и программирование может поставить всю современную цивилизацию с ног на голову...

foror ★★★ ()
Ответ на: комментарий от Legioner

В хроме включается, а в фаерфоксе включается? Что насчёт сафари? Когда будет?

The W3C «GPU for the Web» Community Group was launched on February 16, 2017. At this time, all of Apple, Google, and Mozilla had experiments in the area, but only Apple's proposal was officially submitted to the «gpuweb-proposals» repository.

foror ★★★ ()
Ответ на: комментарий от foror

Т.е. всё еще в далёких планах, а к тому времени и «настольная графика» на месте стоять не будет, и вебассембли будет вечно догоняющей и тормозной платформой по сравнению с нативом.

Да, для опердней. офисов, и прочего «органайзера» достаточно. Уже писал. Но там, где нужно будет 156% от грфики - не взлетит. или должна будет отобрать графику у ОС. Осилят? Когда?

yyk ★★★★★ ()
Ответ на: комментарий от anonymous

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

Там хитрее было. Ты можешь написать свою виртуальную машину со своим языком и JIT-ом, но назвать это можно было только после прохождения TCK (Technology Compability Kit), это набор тестов, которые подтверждали, что твой чёрный ящик работает в соответствии со спецификацией. И вот как раз прохождение тестов TCK было платным. Что не помешало IBM, Azul и другим разработать свою jvm. И за исключением MS гонений на них за это не было. И не будет. MS проиграла суд, т. к. хотела привязать намертво jvm к windows, за что и получила по наглой синей роже.

И сейчас если берёшь исходники OpenJDK и делаешь свой дистрибутив (как например adoptOpenJDK, Liberica, Amazon Correto), то гонений тоже не будет. Во-первых потому, что лицензия GPLv2, а во-вторых, OpenJDK прошла сертификацию TCK.

А вот Apache Harmony так и не стала называться java, потому что не прошла сертификацию. И основной посыл гонений (после бабла конечно же) Oracle на Google в том, что, взяв кусок Apache Harmony, прикрутив к ней ещё свой кусок, ты не получишь «Java», ты получишь некоего уродца, который похож на Java. Но это не мешало гуглу громко заявить, что на Android везде работает Java.

ma1uta ★★ ()
Ответ на: комментарий от Legioner

Го это такой DSL для микросервисов

А для «микросервисов» он, потому что кретины разработчики сами такой своей аффирмацией разогнали всех, кто мог бы использовать его для чего-либо ещё.

anonymous ()
Ответ на: комментарий от foror

Полнейшая глупость. Используя накопивший опыт ИТ можно сделать очень качественный новый ЯП.

Ох уж эти инженегры. Да, можно сделать. Ты его попробуй внедрить. Пока никому не удалось кроме микрософта (узкая но длинная ниша) и гугля (совсем маленькая ниша). И то, микрософт внедрял свое поделие в нулевые, когда это еще было не поздно. Короче, проще старые ЯП подшаманить, что и делается. А новые это все игрушки для бездельников.

bread ()
Ответ на: комментарий от anonymous

Она не имела возможности взаимодействовать нормально со сраницей так же полно как это сделано для JavaScript.

А каким боком webassembly относится к javascript? WA взаимодействует со страницей точно так же как и апплеты - через обёртку на js. Все дыры были только из-за того что хотели иметь возможность запускать привилегированный код в ряде случаев, в WA от этого отказались и только поэтому там нет миллиона дыр.

maloi ★★★★★ ()
Ответ на: комментарий от foror

Есть конечно жабы с нескучным синтаксисом вроде сабжа, но и они не сильно взлетают чот. В отрыве же от жабы оно сразу превращается в тыкву. Правильно выше упомянули пачку языков гораздо более зрелых и развитых, но тоже правда ненужных.

bread ()
Ответ на: комментарий от Legioner

Проблема Lombok-а в том, что он работает не как Annotation Process, а в том, что правит уже полученный bytecode. И из-за этого с ним подавляющая часть проблем.

Я всё хочу написать свой фреймворк, когда дата-класс и билдеры описываешь интерфейсами, а быструю реализацию уже генерит либа, вроде должно получиться очень удобно, но руки всё не доходят.

Зачем писать свой, когда уже есть готовый? ;)

Кстати да, хотя многие и уверяют, что в Java нет препроцессора, но есть annotation processor-ы, с помощью которых выполняется кодогенерация. А т. к. в Java синтаксис простой, то и в кодогенерации получается меньше ошибок и косяков.

Например, https://mapstruct.org/, который тебе через кодогенерацию, а не рефлексию создаёт mapper-ы, можно даже посмотреть на сгенерированный код - он тоже вполне читаем.

ma1uta ★★ ()
Ответ на: комментарий от Legioner

Это я прочитал, но не совсем ясно, одно это тоже или нет. Т.к. в ютраке речь идёт о конкретной платформе. Но в любом случае «no priority», «feature», «no target version» и наглая пропаганда о том, что в C++ тоже нет строчек.

den73 ★★★★★ ()
Ответ на: комментарий от foror

Я думаю, что современные государства и корпорации хотят жить, не хотят, чтобы современная цивилизация была перевёрнута (ведь они уже наверху иерархии, а кто был всем, тот станет после переворота ничем), и поэтому морочат программистов. Я практически в этом уверен и в основном по этой причине бросил разрабатывать cвой нормальный ЯП. Теперь я пытаюсь дорабатывать потенциально безопасную операционную систему и та же проблема берёт меня за горло :(

den73 ★★★★★ ()
Ответ на: комментарий от anonymous

Мне непонятно, как можно не доведя даже поддержку Java до современного уровня

Суд с Oracle. JetBrains не только не будет судиться с Google, но еще и всячески будет помогать. Джава на андроиде всё, при этом у Котлина есть фичи свежей джавы. Все очень просто.

stevejobs ★★★☆☆ ()
Ответ на: комментарий от vertexua

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

А что именно?

den73 ★★★★★ ()
Ответ на: комментарий от bread

Короче, проще старые ЯП подшаманить, что и делается.

А вот ни фига не так. Я понимаю, почему ты так пишешь - увлекаешься C++. Однако, рожденное ползать летать не может. Кривой язык legacy очень трудно сделать современным и отвечающим новым требованиям. Я это не про C++, если что, а в общем ;)

dave ★★★★★ ()
Ответ на: комментарий от den73

Читай выше, теперь основной Андроид язык официально. А скучные вещи, как мобильные приложения, писать надо на чем все остальные пишут, запомни.

vertexua ★★★☆☆ ()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от vertexua

Это пустозвонство. Все прикладное ПО уже написано на жабе, и будет развиваться дальше на жабе. Вот прикинь, завтра Линус делает заявление: раст это теперь основной язык линукс. Официально, я сказал! И все побежали выкидывать сишку вместе со старым кодом. Заживем лол!

anonymous ()
Ответ на: комментарий от anonymous

Тысячи приложений начинают писаться прямо в эту минуту. И только гугл махнул флажком, сразу пошел отсчет роста Котлина с новой скоростью. С гигантским ядром все работает по другому, там нужно линковаться вместе

vertexua ★★★☆☆ ()
Ответ на: комментарий от ma1uta

Зачем писать свой, когда уже есть готовый? ;)

Прикольно, спасибо. Но как-то по-хипстерски выглядит. Мне бы попроще, да и свои хотелки есть (в частности три режима генерации - через Proxy, через генерацию байткода, через генерацию исходников плагином к сборке; возможность сделать freeze; самое важное: поддержка неинициализированных полей с киданием исключений из геттеров). Вряд ли у них всё совпало, но внимательно посмотрю.

Legioner ★★★★★ ()
Ответ на: комментарий от den73
  1. Возможность компиляции кода на три платформы: JVM, JS, Native.
  2. Nullability в системе типов.
  3. Inline-функции для функционального API, которые преобразуют код в функциональном стиле в идентичный в императивном стиле, позволяя писать некоторые куски кода в функциональном стиле практически не теряя в производительности. Да и вообще функциональщина в котлине получилась куда лучше, чем в джаве. Во-первых все коллекции поддерживают функциональные методы, во-вторых аналог Stream крайне простой и расширять его куда проще, чем в Java.
  4. Раздельные интерфейсы для read-only коллекций и изменяемых коллекций. При этом это всё магическим образом маппится на стандартные Java-коллекции.
  5. Корутины (в том числе позволяющие писать асинхронный код и генераторы)
Legioner ★★★★★ ()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от bread

Ну сколько миллиардов людей на планете? Все клепают убогие приложения на один view на свои магазины с огурцами, хотя открыли бы просто группу в ФБ и постили туда уведомления что сегодня закрыто, день взятия Бастилии

vertexua ★★★☆☆ ()