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

Думаю, этот пример чуть лучше объяснит, почему 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
}

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

С этими токенами обычно можно работать через стандартные классы вроде javax.smartcardio.Card. JNI не нужно.

А к результатам компиляции какие-либо претензии есть? На размер компилятора, честно говоря, посрать.

с джавы на джаву?

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

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

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

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

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

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

Там же ссылка на ютрак: https://youtrack.jetbrains.com/issue/KT-25510

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

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

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

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

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

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

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

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

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

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

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

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

Обрати внимание на слово 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-ами и это круто.

гораздо больше выбор предметных областей

Мобилки и энтерпрайз-формошлёпство, что ещё?

Не взлетит, как и все прочие. Кто не успел в 90-е появиться и в нулевые закрепиться, тот опоздал. Даже голанг это однодневка.

Камло взлетело, про остальные сорно, да.

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

А, собственно, зачем? Если всё работает.

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

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

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

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

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

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

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

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

Пруф?

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

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

Есть ли какие-то средства/технологии чтобы такие ситуации упростить/облегчить?

Есть. Javascript.

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

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

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

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

Или работаем по принципу Chrome new IE?

Привет! Давно уже так. Приходится держать хромога, даже если используешь фокс, чтобы открывать в нем некоторые кривые сайты.

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

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

Я вообще не вижу смысла в Kotlin. Этот выб*ядок JetBrains имеет мало смысла после того как обновилась Java.

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

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.

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А что именно?

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

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

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

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

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

современные государства и корпорации хотят жить, не хотят, чтобы современная цивилизация была перевёрнута (ведь они уже наверху иерархии

Шаришь.

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

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

наглая пропаганда о том, что в C++ тоже нет строчек.

А они там есть? Покажи пример, как распечатать стектрейс для заданного std::exception?

Тысячи приложений начинают писаться прямо в эту минуту.

Как страшно жить.

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

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