Вы знаете, я тоже уважаю Кутузова, Жукова, Королева, Курчатова. Но уже очень много лет после них прошло. Пора бы уже новые причины для гордости придумать. Дедам-то конечно же спасибо за Победу. А сами-то на что-то вообще годны кроме гордости за дедов?
Господа, о чем это здесь?
Применение микросервисов требует прокачать мозг? Ну так любые асинхронные, параллельные, многоядерные разработки требуют повышения квалификации персонала. А какая альтернатива? Линейное программирование в одном потоке с оператором goto? Кому этого достаточно, ну счастья вам. А мы пойдем упражнять мозг, ломать очередной раз свой майнд и строить крутые масштабируемые системы.
Спасибо за разъяснение. Нисколько не сомневаюсь в том, что Скала реально мощный язык и сыграл значительную роль в развитии рынка языков. Лично я сделал выбор после прочтения обзоров сравнения между Котлином и Скалой. Согласно этому обзору они очень близки, но все же Котлин несколько удобнее. Добило меня то, что попадались на глаза проекты, которые перешли со Скалы на Котлин (не помню какие).
Тайп хинты, позволяющие или нет null — фича php 5.0 (2004ый год).
В тайп хинтах ничего нового нет. Они сейчас есть и в Питоне и Яваскриптах. Только на практике мало кто их использует. Проверка на null в один оператор тоже древнее изобретение.
Под нал-сейфти сейчас понимается именно защит на уровне компилятора от присвоения нала значению, которое не предназначено принимать нал:
val hereWillBeError: String = null // вот такое не должно пропускаться.
val hereIsOk: String? = null // так нормально
По моему опыту, на KMP удобнее делать интерфейсную логику доступа к бэку для фронта. Удобно же когда один раз сделал ее и разные фронты пользуются одним кодом.
Менее очевидно и более спорно использовать его для генерации внутренних моделей, которые могут включать логику. Например, на транспортном DTO расчет ФИО из Ф, И, О будет избыточным, но для внутренней модели это вполне нормально.
Ну и еще одно применение. Фронт бывает не только SPA. SSR часто делают на ноде, но ничто не мешает делать его на Kotlin — какая разница на чем шаблоны заполнять? В этом случае логику действительно можно будет шарить между тем же Реактом и SSR-ным бэкендом.
А вообще, новые возможности могут значительно повлиять на применяемые практики программирования. Возможно, наш предыдущий опыт мешает увидеть какие-то новые подходы, которые могут стать преобладающими на рынке.
Это было не научное исследование :) Для себя проверяли.
Просто один и тот же разраб тупо сделал DTO на Java, потом на Kotlin.
Ну за сколько человек набивает 4 килобайта Явовского кода в сравнении с 300 байтами на Котлине?
Естественно, что когда идет более сложный код, там все хитрее и уже больше играет по времени сама проблема нежели язык.
Я все-таки не понимаю почему API некой библиотеки требует знания Java.
У меня был джун, которого взяли из мира Шарпа и он не знал Яву до этого. Парень толковый и ничем не выдавал своего незнания классической Явы. В Котлин зашел быстро и каким-то невежеством не отличался.
В качестве кандидатом мы всегда рассматривали выходцев из всех ООП языков.
В реальном бизнесе все решают деньги. Если Котлин позволяет делать проект дешевле, то выбирать будут его. Конечно с учетом консерватизма разработчиков.
PHP, например, уже лет 10 планомерно теряет свою долю рынка, но до сих пор жив и даже развивается.
Не вкурил до сих пор разницу между ними, ясное дело либо this, либо it, но вот run vs apply или let vs also?)
public inline fun <T> T.apply(block: T.() -> Unit): T
public inline fun <T> T.also(block: (T) -> Unit): T
public inline fun <T, R> T.run(block: T.() -> R): R
public inline fun <T, R> T.let(block: (T) -> R): R
А можно поинтересоваться — в проектах на Котлине с каким объемом кода вы участвовали?
Крупный BigData проект.
3 года разработки двух команд в сумме около 20 человек.
несколько десятков микросервисов, ближе к сотне.
Очень понимаю вашу боль. Плохой код можно написать на любом языке. Для того, чтоб код был читаемым, конечно недостаточно просто взять крутой язык, нужно еще разрабатывать качественную архитектуру и соблюдать определенную культуру разработки.
И соглашусь, что новичку не все элементы языка с ходу будут понятны. Именно поэтому я и указывал, что для освоения лучше воспользоваться помощью опытного разработчика или курсами.
Но после освоения языка, те же var и val покажутся действительно очень логичным и мощным инструментом.
Честно говоря, когда работал на PHP, ни про какие Null-safety слышно не было. Сейчас тоже попробовал поискать, но с ходу ничего не нашел кроме оператора `??`. Вероятно, это одна из новых фич и это похвально, что PHP дожил до такого уровня. Но, при том, что PHP остается очень востребованным языком, приходится констатировать, что свою долю рынка в последние 10 лет он методично теряет. Тем не менее, не хочу устраивать холивар по этому поводу, знаю много людей и компаний, которые до сих пор процветают на рынке PHP-разработки.
Правда пока не совсем понятно, как работать с бекендом без опыта в Java
Стоит разделять сам язык и экосистему. В язык войти новичку никаких сложностей нет. Понятно, что для высокого уровня требуется набить руку, но это везде так. Что касается экосистемы, то я не вижу как использование какой-то явовской библиотеки может потребовать знания, собственно, языка/синтаксиса Явы.
Взять тот же JUnit/JUnit5. Весь явизм в Котлин сокрыт от разработчика.
не сочтите хейтерством, мои комментарии больше ориентированы на читателей, нежели на ваш труд.
Я не против конструктивной дискуссии. Уже узнал для себя кое-что интересное и это прекрасно.
По моему опыту, утверждение о том, что без знания Java поход в в Kotlin невозможен, безосновательно.
Проблема Котлина без Ява специфична. Например, чисто котлинисты не знают устройство структур: HashMap, LinkedList, etc. Просто потому, что в Котлине идет Map и MutableMap, которые внутри — LinkedHashMap. Ни разу не видел, чтоб это как-то влияло на качество кода.
Так же котлинисты хуже знают внутренее устройство, примитивы и шаблоны многопоточности. Просто потому, что в Котлине работа с многопоточностью реализована на более высоком уровне.
Я не знаю людей, которые бы с радостью переходили с Котлина на Яву, но и такие прецеденты у меня были. Это требует плотного штудирования литературы и освоения низкоуровневых вещей. Но это возможно. Занимает пару месяцев.
На сегодня JVM от Оракл — это лишь одна из реализаций. И даже ее есть две версии: проприеритарная и OpenJDK с версией GPL.
При том, что Оракл отменил поддержку Java 8, она реально доступна от других поставщиков.
Я не думаю, что существуют целенаправленные исследования, доказывающие что один язык объективно лучше другого. Скорее все останавливается на утверждениях, что у такого-то языка такая-то ниша. Это я про личный опыт. Безусловно, личный.
Господа, о чем это здесь?
Применение микросервисов требует прокачать мозг? Ну так любые асинхронные, параллельные, многоядерные разработки требуют повышения квалификации персонала. А какая альтернатива? Линейное программирование в одном потоке с оператором goto? Кому этого достаточно, ну счастья вам. А мы пойдем упражнять мозг, ломать очередной раз свой майнд и строить крутые масштабируемые системы.
В тайп хинтах ничего нового нет. Они сейчас есть и в Питоне и Яваскриптах. Только на практике мало кто их использует. Проверка на null в один оператор тоже древнее изобретение.
Под нал-сейфти сейчас понимается именно защит на уровне компилятора от присвоения нала значению, которое не предназначено принимать нал:
Менее очевидно и более спорно использовать его для генерации внутренних моделей, которые могут включать логику. Например, на транспортном DTO расчет ФИО из Ф, И, О будет избыточным, но для внутренней модели это вполне нормально.
Ну и еще одно применение. Фронт бывает не только SPA. SSR часто делают на ноде, но ничто не мешает делать его на Kotlin — какая разница на чем шаблоны заполнять? В этом случае логику действительно можно будет шарить между тем же Реактом и SSR-ным бэкендом.
А вообще, новые возможности могут значительно повлиять на применяемые практики программирования. Возможно, наш предыдущий опыт мешает увидеть какие-то новые подходы, которые могут стать преобладающими на рынке.
Просто один и тот же разраб тупо сделал DTO на Java, потом на Kotlin.
Ну за сколько человек набивает 4 килобайта Явовского кода в сравнении с 300 байтами на Котлине?
Естественно, что когда идет более сложный код, там все хитрее и уже больше играет по времени сама проблема нежели язык.
Мне больше интересно:
Вам это помогало или мешало?
Мне этот вопрос интересен — готовлю курс по Котлину. Буду благодарен, если ответите развернуто.
У меня был джун, которого взяли из мира Шарпа и он не знал Яву до этого. Парень толковый и ничем не выдавал своего незнания классической Явы. В Котлин зашел быстро и каким-то невежеством не отличался.
В качестве кандидатом мы всегда рассматривали выходцев из всех ООП языков.
В реальном бизнесе все решают деньги. Если Котлин позволяет делать проект дешевле, то выбирать будут его. Конечно с учетом консерватизма разработчиков.
PHP, например, уже лет 10 планомерно теряет свою долю рынка, но до сих пор жив и даже развивается.
Крупный BigData проект.
3 года разработки двух команд в сумме около 20 человек.
несколько десятков микросервисов, ближе к сотне.
Очень понимаю вашу боль. Плохой код можно написать на любом языке. Для того, чтоб код был читаемым, конечно недостаточно просто взять крутой язык, нужно еще разрабатывать качественную архитектуру и соблюдать определенную культуру разработки.
И соглашусь, что новичку не все элементы языка с ходу будут понятны. Именно поэтому я и указывал, что для освоения лучше воспользоваться помощью опытного разработчика или курсами.
Но после освоения языка, те же var и val покажутся действительно очень логичным и мощным инструментом.
Стоит разделять сам язык и экосистему. В язык войти новичку никаких сложностей нет. Понятно, что для высокого уровня требуется набить руку, но это везде так. Что касается экосистемы, то я не вижу как использование какой-то явовской библиотеки может потребовать знания, собственно, языка/синтаксиса Явы.
Взять тот же JUnit/JUnit5. Весь явизм в Котлин сокрыт от разработчика.
Я не против конструктивной дискуссии. Уже узнал для себя кое-что интересное и это прекрасно.
По моему опыту, утверждение о том, что без знания Java поход в в Kotlin невозможен, безосновательно.
Проблема Котлина без Ява специфична. Например, чисто котлинисты не знают устройство структур: HashMap, LinkedList, etc. Просто потому, что в Котлине идет Map и MutableMap, которые внутри — LinkedHashMap. Ни разу не видел, чтоб это как-то влияло на качество кода.
Так же котлинисты хуже знают внутренее устройство, примитивы и шаблоны многопоточности. Просто потому, что в Котлине работа с многопоточностью реализована на более высоком уровне.
Я не знаю людей, которые бы с радостью переходили с Котлина на Яву, но и такие прецеденты у меня были. Это требует плотного штудирования литературы и освоения низкоуровневых вещей. Но это возможно. Занимает пару месяцев.
На сегодня JVM от Оракл — это лишь одна из реализаций. И даже ее есть две версии: проприеритарная и OpenJDK с версией GPL.
При том, что Оракл отменил поддержку Java 8, она реально доступна от других поставщиков.
Да, как-то так :)
А паттерны появились не на ровном месте.