ну то есть в kotlin/js такой код возможен (вроде): var a = 5 a = "b" a = 7.0

ну то есть в kotlin/js такой код возможен (вроде): var a = 5 a = "b" a = 7.0

это если обявишь дайнемик тип

такое возможно только в kotlin/js, и если такого не делать - то любая платформа возможна

ну то есть в kotlin/js такой код возможен (вроде): var a = 5 a = "b" a = 7.0

По моему конкретно этот пример не скомпилируется

это если обявишь дайнемик тип

причем указывать нада явно

просто в jvm не разбираюсь, говорят что геморно настраивать

тонкая настройка под максимальную производительность непроста, а без особых требований всё просто берёт и работает

По моему конкретно этот пример не скомпилируется

не енскомпилится

это если обявишь дайнемик тип

я пишу под kotlin/jvm и поглядываю на native, а этот пример вычитал в интервью, так что хз что там и как)

если писать Kotlin Native, и юзать либы - C , C++, можно ведь скомпилить в машинный код?

если писать Kotlin Native, и юзать либы - C , C++, можно ведь скомпилить в машинный код?

там будет LLVM, а не машинный код

я пишу под kotlin/jvm и поглядываю на native, а этот пример вычитал в интервью, так что хз что там и как)

var a: dynamic = 1

var a: dynamic = 1

аааа, спасиб

тонкая настройка под максимальную производительность непроста, а без особых требований всё просто берёт и работает

то есть я могу просто запустить и все? а потом если начнутся проблемы тут то я и начну е***********

там будет LLVM, а не машинный код

ну все равно компилятор потом скомпилирует тебе это

то есть я могу просто запустить и все? а потом если начнутся проблемы тут то я и начну е***********

ну это смотря какие проблемы :) Когда станешь держать больше соединений, чем вообще способна нода, тогда да.

то есть я могу просто запустить и все? а потом если начнутся проблемы тут то я и начну е***********

если производительности\памяти не будет хватать

нет идеального интрумента\системы

то есть я могу просто запустить и все? а потом если начнутся проблемы тут то я и начну е***********

Ты там игры что ли пишешь? Инженеры из Oracel вылизали за 20 лет JVM по полной, а бошковитые-авторы либ/фреймворков делают их максимально быстрыми.

ну все равно компилятор потом скомпилирует тебе это

насколько я знаю, там низкоуровневая виртуальная машина, которая типа JVM, только быстрее и значительно легче

машинного кода не будет никогда

Да, извините, я конечно имел ввиду, что можно на жвм запустить, на ноде нет

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

насколько я знаю, там низкоуровневая виртуальная машина, которая типа JVM, только быстрее и значительно легче

та вроде нет, только свой gc

насколько я знаю, там низкоуровневая виртуальная машина, которая типа JVM, только быстрее и значительно легче

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

у Rustlang тоже LLVM, там бинарник на выхлопе

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

да получаешь бинарь

в golang, не помню честно - но вроде тоже

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

честно: не пробовал ещё

интересно, будет ли у Unity/Unreal engine поддержка котлеты когда-нибудь

JB хотят двигатся в том направлении

JetBrains вообще молодцы

имею ввиду в геймдейв

только webstorm все равно тормозит

насколько я знаю, там низкоуровневая виртуальная машина, которая типа JVM, только быстрее и значительно легче

там нет никакой виртуальной машины, LLVM — не рантайм, а платформа для построения компиляторов

только webstorm все равно тормозит

ну мало кто ним пользуются, все на атомах и визуалк

да мы пользуемся ) я на vscode хотел, но все его юзают и мне приходится

в общем Kotlin это круто

да мы пользуемся ) я на vscode хотел, но все его юзают и мне приходится

нада писать в сапорт

в общем Kotlin это круто

это да, перспектив много, растёт быстро

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

?

интересно, будет ли у Unity/Unreal engine поддержка котлеты когда-нибудь

Есть проект позволяющий запускать котлинжс под анрил

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

Вот странно, пользуюсь котлином потому что там ФП ?

как бы мультипарадигменный язык :) Но больше ООП, конечно.

Настолько Bad Practice, что разработчики конвертера даже не учли это

Ясно)

та вроде нет, только свой gc

Нет там никакого gc. LLVM просто оптимизирует код в IR и компилирует в машинное представление. В Kotlin native пока счетчик ссылок собственный.

Нет там никакого gc. LLVM просто оптимизирует код в IR и компилирует в машинное представление. В Kotlin native пока счетчик ссылок собственный.

...и собственный поиск циклических ссылок.

конечно именно ради этого

Настройка и запусе программы под JVM на порядок проще, чем под node.js. Инструментов для тонкой настройки VM довольно мало, но я не знаю, где эта тонкая настройка вообще может быть нужна. Единственный минус в том, что JVM будет по определению резервировать больше памяти.

...и собственный поиск циклических ссылок.

И он тоже.

Я тут обнаружил, что между счетчиком ссылок и GC тоже холивар есть. Есть сторонники того и того

Настройка и запусе программы под JVM на порядок проще, чем под node.js. Инструментов для тонкой настройки VM довольно мало, но я не знаю, где эта тонкая настройка вообще может быть нужна. Единственный минус в том, что JVM будет по определению резервировать больше памяти.

Хм, а сколько памяти резервирует нода?

Без понятия. Я как-то попрбовал настроить и плюнул. Не понятно зачем. Я не уверен, что я прав, но JVM обычно по определению резервирует довольно много, V8 вроде по природе своей гораздо ближе к системе, так что я думаю, что к памяти оно более экономично относится... надо посмотреть

Я просто локально гоняю веб-сервис на девятке с -Xss180K -Xms16M -Xmx32M. Но сколько жрёт по факту — не в курсе.

Тут есть два пункта: память на тред и память на объекты в треде. По первому пункту ява всегда проигрывала однотредной ноде, но это лечится корутинами. А вот тот факт, что объекты в яве спроектированы так, чтобы не экономить память, не лечится.

Правда сейчас вроде в десятке оптимизированные строки, это может очень сильно все урезать

по первому пункту нода вынуждена стартовать по отдельной VM на поток :)

Тут есть два пункта: память на тред и память на объекты в треде. По первому пункту ява всегда проигрывала однотредной ноде, но это лечится корутинами. А вот тот факт, что объекты в яве спроектированы так, чтобы не экономить память, не лечится.

> объекты в яве спроектированы так, чтобы не экономить память можно подробнее?

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

Правда в JS тот же самый GC, так что и проблемы должны быть те же самые.

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

плюсоиды это нетолерантно

Нет там никакого gc. LLVM просто оптимизирует код в IR и компилирует в машинное представление. В Kotlin native пока счетчик ссылок собственный.

я про это и имел ввиду

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

> обычные структуры данных в яве и то, как они работают ну HashMap — да, а ArrayList вроде норм. главное всякие Linked* не использовать. > гарантирует, что общая аллоцированная память будет всегда сильно больше Не гарантирует, сборщик мусора не дремлет

плюсоиды это нетолерантно

А ладно, есть еще питоноиды. И наверно жабоиды и теперь котлиноиды... и хаскелисты.

> обычные структуры данных в яве и то, как они работают ну HashMap — да, а ArrayList вроде норм. главное всякие Linked* не использовать. > гарантирует, что общая аллоцированная память будет всегда сильно больше Не гарантирует, сборщик мусора не дремлет

Он не дремлет, но при этом JVM память-то все равно отгребает гораздо больше, чем реально используется.

Он не дремлет, но при этом JVM память-то все равно отгребает гораздо больше, чем реально используется.

причем намного больше

как бы мультипарадигменный язык :) Но больше ООП, конечно.

почему больше ООП? можно и без ООП писать на котлине, это в java ООП обязательно ведь

причем намного больше

ждём конкретные числа

почему больше ООП? можно и без ООП писать на котлине, это в java ООП обязательно ведь

Не желательно. Там много клево-функционального, но для чисто функционального кода (без побочных эфектов и так далее) он не годится.

Не желательно. Там много клево-функционального, но для чисто функционального кода (без побочных эфектов и так далее) он не годится.

я имею в виду процедурный стиль, как в C

почему больше ООП? можно и без ООП писать на котлине, это в java ООП обязательно ведь

Потому что функциональный тип выражен интерфейсами, а функции — объектами :)

я имею в виду процедурный стиль, как в C

Ну это мазохизм называется

я имею в виду процедурный стиль, как в C

функциональный != процедурный, это две разных вселенных. Процедурно, как в Си, к сожлению, никто писать не запретит. Именно поэтому Котлин нельзя назвать труъ функциональным языком.

ждём конкретные числа

jmc

Ну это мазохизм называется

это вроде относительно, на go вроде пишут в процедурном стиле

я пока не видел крупных проектов, а для маленьких реально много, это одна из причин почему javaGUI не зашло

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

jmc

?

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

ни в go, ни в rust нет ООП, тем не менее, люди пишут на этих языках, ядро linux написано на C

?

java mission control

Люди и на PHP еще пишут.

ни в go, ни в rust нет ООП, тем не менее, люди пишут на этих языках, ядро linux написано на C

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

java mission control

Да, я в курсе. И что?

java mission control

просто конкретные числа сложно привести

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

я не спорю

просто конкретные числа сложно привести

тогда откуда инфа, что намного?

я пока не видел крупных проектов, а для маленьких реально много, это одна из причин почему javaGUI не зашло

зашло, см. IntelliJ IDEA

тогда откуда инфа, что намного?

соотношения используемой\выделеной

соотношения используемой\выделеной

-Xmx

зашло, см. IntelliJ IDEA

ну електрон лучше зашел почемуто, вот это и печалит

ну електрон лучше зашел почемуто, вот это и печалит

потому что веб-разработчиков больше

-Xmx

ну вот и пошли настройки на старте, а хотелось на старте

хотя хз, кто и зачем пользуется приложениям на электроне

ну вот и пошли настройки на старте, а хотелось на старте

ну да, JVM привыкла жить на сервере, где она может сожрать всю память — надо её ограничивать)

потому что веб-разработчиков больше

они и пользуются

соотношения используемой\выделеной

Это не всегда правда, он выделяет виртуальную память, а не реальную. Сколько он реально использует, довольно трудно понять. Но у меня вот есть проблема с тем, что довольно накладно держать несколько инстансов JVM одновременно

хотя хз, кто и зачем пользуется приложениям на электроне

Собственно я про это и говорил. JVM не экономит память по своей идее. Про Node не знаю, не пробовал

IDEA, Gradle, запущенный рабочий проект, ещё всякие инструменты — вроде уживаются