Kotlin не только под Android? Веб-сайты и дескопщина тоже рулят?

как потомственный питонщик, всё писал на Python'е.

Число комментариев: 175

Раздел Число тем

Форум 114

Аутсорсил лору и борде

Починил, не благодари.

Я не аутсорсил, я пользовался консалтинговыми услугами!

И не бесплатно, особенно на борде.

^__^

предполагаю , будет в конечном итоге те же плюсы и минусы что с jvm на десктопе

А какие плюсы и минусы у JVM на десктопе?

На кой тебе эта жабка на десктопе? Бери уж сразу електрон. Жрать память - так по-взрослому!

Swing и потребление ресурсов - это минусы Плюсы - это кроссплатформеность ( хотя если у тебя QT и опенсорс можешь сам подо все собрать ) [много может быть подводных камней ]

Spring, там что-то подкрутили для колина, не знаю что было до этого, но я его пользовал в этом году против spring, все отлично. Только в gradle нужно доп плагины ставить, т.к. колин все «закрывает», т.е. классы и методы по умолчанию у колтин final, от чего не работают прокси, нужно либо явно прописывать модификатор открывающий их, либо пользовать плагин.

У тебя своей головы-то нет, лол? Если будут агитировать пороться в сракотан, тоже топик на ЛОРе создашь?

Scala лучше

колина...колин...колтин

%s/(колина|колин|колтин)/котлин/g

питонщик, всё писал на Python'е. Если надо GUI для десктопного приложения, то писал на PyQt. Если надо веб-интерфейс - то бэкенд на Django

И зачем тогда сползать с питоняки? Мобильные GUI на Python это на чем делают?

Та я не знаю, я мобильных GUI как-то до сих пор и не писал = (

Kotlin рулит везде где рулит Java

Дык, я пока в Java вообще не рублю. Я знаю, что для десктопа там есть Java FX, а вебню на чём явщики колбасят?

Kotlin рулит везде где рулит Java

В кровавом тырпрайзе и на мобилках. А из других мест уносите это говнище.

Spring

Не совсем. Они делают Kotlin Native - и значит, можно будет обойтись без JVM на десктопе.

Десктоп явно мимо.

А JavaFX для десктопа разве не рулит?

Сам на Котлине ничего не писал, только собираюсь с ним разобраться, зато общался с разработчиками. Одни из самых разумных и рациональных программистов, что я встречал. Подход у них чисто прагматичный, направленный на создание удобного инструмента, который работает на разных платформах (native Linux, Win,iOS, а также JVM, JS, WebAssembly). Кроме того, чуваки не страдают фанатизмом ради включения модных фишек в язык, потому что его нужно поддерживать, причем Kotlin почти одинаков как язык на всех поддерживаемых платформах, а «модная» фишка, которую не удасться реализовать на какой либо платформе приведет к фрагментации языка. Также на любой платформе его легко стыковать с более родным языком этой платформы (т.е. на JVM, например, можно писать часть кода на Kotlin, часть на Java и они друг с другом будут стыковаться как один язык), а кроме того, Котлин использует родные для платфомы библиотеки как свои собственные (поэтому под Android или iOS можно писать приложения на котлин и использовать родные библиотеки почти так же, как если бы ты писал на Java или Swift).

Не знаю, насколько удобно на нем писать под десктоп или веб приложения, но точно лучше, чем на Java. По сути Kotlin - это более современный чем Java язык за счет многих удобных добавлений в сам язык + отличная совместимость с родными для данной платформы языками и библиотеками (как я уже писал, из приложения на Kotlin ты можешь общаться с Java GUI библиотекой, как из приложения на Java).

IMHO, если нужен язык для коммерческой разработки, то Котлин выглядит более перспективным, чем Java, например.

Нет конечно.

Одни из самых разумных и рациональных программистов, что я встречал.

А за счет чего эти программисты собираются обеспечить Kotlin Native библиотеками? Когда Kotlin привязан к JVM, то для него доступны гигатонны готовых Java-библиотек. Чего просто не будет в «native Linux, Win,iOS».

А за счет чего эти программисты собираются обеспечить Kotlin Native библиотеками?

Рассказываю. Котлин JVM, JS и Native это три разных backend. Котлин JVM привязан к JVM, а Kotlin Native - это тот же язык Kotlin, но никак не привязан к JVM. Там есть (как я понял) парсер, который из заголовочных файлов C (и, возможно, бинарных библиотек) делает SDK для котлина, после чего с этой бибилиотекой ты работаешь, как будто она была написана на Kotlin (работаешь со сгенерированным SDK). Ну, а llvm backend потом все слинкует (результат компиляции твоего kotlin кода и библиотеки из которых ты сделал SDK). Т.е. ты можешь часть проекта писать на C (или использовать библиотеки, написанные на C), а честь на kotlin. Каждый из них скомпилируется своим компилятором, а затем слинкуется. Еще, насколько я помню, есть поддержка Swift/Obj-C (на самом деле это основная платформа для Kotlin Native, ибо именно там можно заработать бабло, а разработчики Kotlin очень разумные и прагматичные ребята, как я уже несколько раз говорил). Kotlin Native - это отдельная команда (про JVM и JS не в курсе), но парни озабочены тем, чтобы Kotlin был одним языков не зависимо от бакэнда (насколько это возможно), поэтому старательно избегают фрагментации языка. И, кстати, в Kotlin Native полноценный сборщик мусора, а не как в Swift (ARC), при этом никакой виртуальной машины - на выходе чистый бинарник.

С C++ так линковаться не получится. Плюсы слишком сложный язык и Kotlin Native с ним напрямую работать не умеет (как раз тот случай, когда сложность реализации фукнциональности и ее дальнейшей поддержки не оправдана).

P.S. Кстати, вспомнил, Kotlin Native - предназначен для прикладного софта (типа приложений для iOS мобилок), поэтому для серверных приложений может оказаться не очень. Однако, Kotlin JVM вполне себе будет работать на JVM и на нем писать серверный софт уж точно не хуже, чем на Java.

Подход у них чисто прагматичный, направленный на создание удобного инструмента, который работает на разных платформах (native Linux, Win,iOS, а также JVM, JS, WebAssembly).

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

Рассказываю.

Ответа, собственно, и не последовало.

Сейчас не 1980-е годы, когда языки были интересны сами по себе, даже если у них стандартная библиотека содержала всего десяток функций или классов. Народ сейчас хочет не только удобный язык со свистелками и перделками, но и богатый набор батареек в стандартной библиотеке. Именно в стандартной библиотеке, чтобы один и тот же класс, грубо говоря, Pathname, был и на iOS, и на Linux, и под Windows.

Так вот, когда Kotlin является языком для JVM, проблемы с библиотеками нет.

А вот когда говорят о Kotlin Native, то сразу же возникает вопрос: а откуда возьмется этот самый Pathname?

Если разработчики Kotlin-а рассчитывают на прозрачную интеграцию существующих C-шных lib в Kotlin, то это одно. Если хотят написать свою stdlib для Kotlin Native, то это совсем другое.

Стандартная библиотека у Kotlin есть. И она одинакова на всех платформах. Сторонние библиотеки, которые есть на платформе, Kotlin подключает как родные.

Ответа, собственно, и не последовало.

Может надо было по другому вопрос задать?

P.S. Одна из причин появления Ceylon была создание современной стандартной библиотеки (примерно тогда же зародился Kotlin). Предполагаю, что и в Kotlin стремились написать стандартную библиотеку с учетом недостатков стандартной библиотеки Java.

Стандартная библиотека у Kotlin есть. И она одинакова на всех платформах.

А не подскажите, что означают отметки JVM вот в этой документации: kotlin.concurrent?

Может надо было по другому вопрос задать?

Вы не смогли понять вот этот вопрос: «А за счет чего эти программисты собираются обеспечить Kotlin Native библиотеками?» Тогда извините.

молодые падки до всяких котлинов, докеров. они думаю, что модные фишки и сленг обеспечат им будущее.

Бери скалу, вон вайр вполне ведройд клиента даже на ней делают.

А, вообще, я бы не стал использовать ${tecnologyName} как затычку в любые места.

Бэкенд я бы на скале писал, а вот мобильный клиент - на котлине.

На стол даже не знаю на чем бы писал.

А смысл писать на козлине, если апи жабские? Получится та же херотень, ну может слегка лаконичнее. Зато жабий код легко отдается на поддержку любым индусам, а козлин никто не знает.

Что бы не жрать говно Java 6/7.

Kotlin годный язык. Вот здесь мои мысли по поводу языка Как там Kotlin поживает? (комментарий)