Я все-таки не понимаю почему 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, она реально доступна от других поставщиков.
Я не думаю, что существуют целенаправленные исследования, доказывающие что один язык объективно лучше другого. Скорее все останавливается на утверждениях, что у такого-то языка такая-то ниша. Это я про личный опыт. Безусловно, личный.
У виртуальных машин вырисовываются определенные преимущества по сравнению с нативным кодом.
1. динамическая оптимизация кода. В рантайме код докомпилируется под конкретные условия работы. Поэтому по производительности код jvm вполне сравним с c/c++.
2. VM обеспечивают мультиплатформенность. Одна программа на JVM одинаково работает как в Windows, так и в Linux и Mac.
3. В новой версии JVM — GraalVM обеспечивается интеоперабельность с Python и JS из коробки. В Native это делается заметно сложнее.
Я соглашусь, что какие-то проблемы действительно существуют, какие-то были в определенных версиях, но исправлены, с третьими я бы не согласился. Но речь сейчас не об этом. Котлин объективно превосходит Яву в бизнесовой разработке по скорости разработки и по дальнейшей поддержке продукта. Это объективно измеримая величина.
Недостатки у Котлина есть, как и у любого другого сущего элемента в реальном мире. Но, когда стоит вполне бизнесовая постановка, под нее выделен вполне определенный бюджет и стоит вопрос лишь на чем разрабатывать, то вариантов на сегодня все же не так много.
И по моему опыту, Котлин показывает более высокие результаты, по крайней мере в сравнении с Явой.
Нисколько не претендую на истину, если предложите какую-то другую достойную альтернативу, с удовольствием изучу вопрос.
Тут скорее опыт тех команды, с которыми я работал.
Конечно, при желании можно и на Котлине писать отвратительный код. Один мой коллега был замечен в чрезмерном использовании `Any` вместо нормальных типов. За это был посрамлен и научен жизни.
По-моему, он позиционируется больше как мультиплатформенный фреймворк для клиент-серверных приложений, и если есть что-то из фронтенда, то это только голый html, css
Ktor состоит из серверной части и клиентской. Клиентскую часть в очень сильном приближении можно рассматривать как попытку создания фронтендного фреймворка.
Имхо разработчикам языка надо больше времени уделять
Именно! Батчи в Кассандре созданы для обеспечения атомарности запросов, а не для ускорения загрузки.
Для загрузки должны использоваться АСИНХРОННЫЕ операции. Даже при работе с асинхронными запросами есть нюансы: для ожидания надо использовать не get(), а get uninterruptible(), который является не блокирующим, в отличие от первого. В этом случае можно в одном потоке обеспечить максимальную производительность.
По моему опыту, скорость загрузки в базу в асинхронном режиме была в 5 раз выше, чем в батчевом, видимо из-за того, что было 5 узлов.
Мне больше интересно:
Вам это помогало или мешало?
Мне этот вопрос интересен — готовлю курс по Котлину. Буду благодарен, если ответите развернуто.
У меня был джун, которого взяли из мира Шарпа и он не знал Яву до этого. Парень толковый и ничем не выдавал своего незнания классической Явы. В Котлин зашел быстро и каким-то невежеством не отличался.
В качестве кандидатом мы всегда рассматривали выходцев из всех ООП языков.
В реальном бизнесе все решают деньги. Если Котлин позволяет делать проект дешевле, то выбирать будут его. Конечно с учетом консерватизма разработчиков.
PHP, например, уже лет 10 планомерно теряет свою долю рынка, но до сих пор жив и даже развивается.
Крупный BigData проект.
3 года разработки двух команд в сумме около 20 человек.
несколько десятков микросервисов, ближе к сотне.
Очень понимаю вашу боль. Плохой код можно написать на любом языке. Для того, чтоб код был читаемым, конечно недостаточно просто взять крутой язык, нужно еще разрабатывать качественную архитектуру и соблюдать определенную культуру разработки.
И соглашусь, что новичку не все элементы языка с ходу будут понятны. Именно поэтому я и указывал, что для освоения лучше воспользоваться помощью опытного разработчика или курсами.
Но после освоения языка, те же var и val покажутся действительно очень логичным и мощным инструментом.
Стоит разделять сам язык и экосистему. В язык войти новичку никаких сложностей нет. Понятно, что для высокого уровня требуется набить руку, но это везде так. Что касается экосистемы, то я не вижу как использование какой-то явовской библиотеки может потребовать знания, собственно, языка/синтаксиса Явы.
Взять тот же JUnit/JUnit5. Весь явизм в Котлин сокрыт от разработчика.
Я не против конструктивной дискуссии. Уже узнал для себя кое-что интересное и это прекрасно.
По моему опыту, утверждение о том, что без знания Java поход в в Kotlin невозможен, безосновательно.
Проблема Котлина без Ява специфична. Например, чисто котлинисты не знают устройство структур: HashMap, LinkedList, etc. Просто потому, что в Котлине идет Map и MutableMap, которые внутри — LinkedHashMap. Ни разу не видел, чтоб это как-то влияло на качество кода.
Так же котлинисты хуже знают внутренее устройство, примитивы и шаблоны многопоточности. Просто потому, что в Котлине работа с многопоточностью реализована на более высоком уровне.
Я не знаю людей, которые бы с радостью переходили с Котлина на Яву, но и такие прецеденты у меня были. Это требует плотного штудирования литературы и освоения низкоуровневых вещей. Но это возможно. Занимает пару месяцев.
На сегодня JVM от Оракл — это лишь одна из реализаций. И даже ее есть две версии: проприеритарная и OpenJDK с версией GPL.
При том, что Оракл отменил поддержку Java 8, она реально доступна от других поставщиков.
Да, как-то так :)
А паттерны появились не на ровном месте.
На самом деле уже заложен и сеттер, и геттер. Этот код абсолютно аналогичен следующему:
И даже в этом виде он более компактен, чем в Яве, хотя функционально является полным аналогом того, что у вас в первом варианте приведен.
Мой камень в огород PHP, Python, JS был лишь в плане строгой типизации.
1. динамическая оптимизация кода. В рантайме код докомпилируется под конкретные условия работы. Поэтому по производительности код jvm вполне сравним с c/c++.
2. VM обеспечивают мультиплатформенность. Одна программа на JVM одинаково работает как в Windows, так и в Linux и Mac.
3. В новой версии JVM — GraalVM обеспечивается интеоперабельность с Python и JS из коробки. В Native это делается заметно сложнее.
Недостатки у Котлина есть, как и у любого другого сущего элемента в реальном мире. Но, когда стоит вполне бизнесовая постановка, под нее выделен вполне определенный бюджет и стоит вопрос лишь на чем разрабатывать, то вариантов на сегодня все же не так много.
И по моему опыту, Котлин показывает более высокие результаты, по крайней мере в сравнении с Явой.
Нисколько не претендую на истину, если предложите какую-то другую достойную альтернативу, с удовольствием изучу вопрос.
Тут скорее опыт тех команды, с которыми я работал.
Конечно, при желании можно и на Котлине писать отвратительный код. Один мой коллега был замечен в чрезмерном использовании `Any` вместо нормальных типов. За это был посрамлен и научен жизни.
Ktor состоит из серверной части и клиентской. Клиентскую часть в очень сильном приближении можно рассматривать как попытку создания фронтендного фреймворка.
Там много еще недоделок, но дело движется…
Речь о Java-драйвере от datastax
Именно! Батчи в Кассандре созданы для обеспечения атомарности запросов, а не для ускорения загрузки.
Для загрузки должны использоваться АСИНХРОННЫЕ операции. Даже при работе с асинхронными запросами есть нюансы: для ожидания надо использовать не get(), а get uninterruptible(), который является не блокирующим, в отличие от первого. В этом случае можно в одном потоке обеспечить максимальную производительность.
По моему опыту, скорость загрузки в базу в асинхронном режиме была в 5 раз выше, чем в батчевом, видимо из-за того, что было 5 узлов.