Стоит ли изучать Kotlin, если не знаешь Java?

Не Scala потому что она никому не нужна, в отличие от Котлина. В работе уже множество компаний используют Котлин в проде.

В работе уже множество компаний используют Котлин в проде.

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

Денис Загаевский:
Гы, по моим сведения Скалу использует больше. И раньше. А фактор времени - имеет значение для распространения.

Но вы в корне не правы - если вы полагаете изучать Котлин и использовать в РЕАЛЬНО работе, а не изучать для себя, для саморазвития, то вы столкнетесь как раз с той проблемой, которую неявно озвучал автор вопроса -

при реальной работе на Котлине без Явы вы никуда не денетесь.

dinegnet: Eugene Aristarhov:
Я на всё это смотрю с колокольни Андроида. Там Скалу никто не использует. Котлин - используют. Из крупных - Avito, например, точно использует чистый Котлин.
Раньше не раньше, а у Скалы есть определённые минусы, которые не перевесят никакие плюсы. У Котлина их меньше.
И я нигде не говорил, что Котлин без Джавы. Я говорил, почему не Скала.

Денис Загаевский:

Я на всё это смотрю с колокольни Андроида.

И я нигде не говорил, что Котлин без Джавы. Я говорил, почему не Скала.

А если посмотреть с колокольни веба или корпоративноего ПО?

Денис Загаевский: Да вот только андроидом всё не ограничивается. Котлин может занять свою нишу если сделает упор на андроид и будет развивать свою экостистему в эту сторону, тут может потеснить java, но нужно время и много работы. Один большой шаг в эту сторону они уже сделали.

Eugene Aristarhov: dinegnet:
JetBrains говорят, что очень много запросов на Котлин от энтерпрайза. Они сами пишут биллинг/авторизацию целиком на нём. Ну и как бы вкусно писать full-stack на одном языке, под все платформы, вместе с бекендом. Кажется, прецедентов ещё не было.

Денис Загаевский:

Кажется, прецедентов ещё не было.

Да ну?

Java, например.
или С.

Но сам по себе язык ничего не дает для универсальности.
Язык учится легко.

А вот библиотеки создаются (тем более под такой зоопарк) и изучаются - дооооолго.

И фуллстека все равно не получится. Ибо альтернатив JS в браузере в ближайшие годы нет и не будет.

Денис Загаевский:

Они сами пишут биллинг/авторизацию целиком на нём.

Было бы удивительно если бы они этого не делали.
Где еще проверить язык в бою - как не в своей разработке.

dinegnet: ну и где фулл-стек на Java или Си? Kotlin, в пределе, покроет бекенд, фронтенд, Android, iOS и Windows. Kotlin/JVM, Kotlin/JS, Kotlin/Native
Удивительно не то, что они пишут на нём, а то, что они пишут на нём очень важную часть своей системы.

Денис Загаевский:

От того, что имеется транслятор из Котлина в JS не следует что мы имеем Котлин в браузере.
Трансляторы из языка X в JS для чего только УЖЕ не писали.

dinegnet: раз пошла такая пьянка, давайте вы не будете только вопросы задавать. Где фуллстек на Си или джаве?

Денис Загаевский:

Kotlin, в пределе, покроет бекенд, фронтенд, Android, iOS и Windows. Kotlin/JVM, Kotlin/JS, Kotlin/Native

Гипотетически.... поэтому я бы не говорил об этом даже в пределе.
JetBrains не настолько крупная компания чтобы это осилить.

Подобного не удалось даже MS (и это при их финансовой мощи, ведь MS стабильно занимала 1-2-3 место в мировом софтверном ИТ десятилетиями), хотя она очень даже интенсивно развивала свой .NET в свои самые богатые годы.

Денис Загаевский:

ну и где фулл-стек на Java или Си? Kotlin, в пределе, покроет бекенд, фронтенд, Android, iOS и Windows. Kotlin/JVM, Kotlin/JS, Kotlin/Native

На фронтенде будет не Котлин, а всего лишь трансляция.
Что возможно и для почти любого универсального языка программирования. Уж для статически типизируемого - вообще раз плюнуть. Было бы желание написать транслятор в JS. И у многих уже есть такие трансляторы.

Бэкенд и Android язык Котлин покроет только благодаря Яве и только воспользовавшись ее библиотеками в значительной части.

iOS через какую нибудь эмуляцию/трансляцию/виртуальную машину - которой и сейчас полно для других языков. Да хоть бы Unity и C#.

Если уж так рассуждать - что неважно как затащить на платформу, но лишь бы затащить - то еще и C# уже все покрыл, а не только С и Java.

Только никому это не нужно.
Полное покрытие есть, но значимо удобнее от этого работать не стало.

Не вижу предпосылок, с чего бы это Котлин это сделает более удобным образом
чем Java, C# или С.
И не вижу предпосылок, почему это будет реализовано более полноценно и удобно, чем у вышеупомянутых языков.

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

Зная количество разработчиков в JetBrains (и кстати, львинная доля их занята совсем другими проектами - теми что приносят деньги, в отличие от Котлина) - не понимаю вашей мечтательности.

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

dinegnet: Я же написал - Kotlin/Native, о какой эмуляции речь?
Короче у меня нет желания спорить, время нас рассудит.

Денис Загаевский:

Как минимум на фронтенде в принципе не может быть нативного Котлина.
В принципе.
;)

Все остальное - не под силам оказалось даже самой богатой в то время компании в сфере software.

dinegnet: %) вы хоть читаете, что я пишу и на что я отвечаю?

Денис Загаевский:

то, что я с вами не соглашаюсь не означает, что не читаю.

Денис Загаевский:
сомнительно чтобы вообще было целесообразным/возможным/нужным создание единого языка для всех платформ.

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

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

dinegnet:
Вы говорите
>iOS через какую нибудь эмуляцию/трансляцию/виртуальную машину
Я отвечаю
>Kotlin/Native, о какой эмуляции речь?
Вы отвечаете
>Как минимум на фронтенде в принципе не может быть нативного Котлина.

Wat?

Денис Загаевский: как? в фирменном браузере? который никому не нужен?
что то не было популярности у гуглевого браузера с Дартом внутри.

dinegnet:

Как минимум на фронтенде в принципе не может быть нативного Котлина.
В принципе.

Вы так говорите потому, что незаметно подменили понятие "фронтенд" на "фронтенд, который в браузере". Никто не мешает сделать какой-нибудь платежный терминал, например, с фронтендом на котлине. Или игру. Или навигатор. Или интерфейс управления ЧПУ станком.

Stalker_RED:

а давайте вы не будете придуматься новое значение устоявшихся терминов?

фронтенд - это когда игра в интернете через браузер.
и браузер нужен стандартный, иначе не будет игроков

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

из того же что кто то будет использовать нестандартный браузер на станке или платежном терминале
вовсе не следует обсуждаемое утверждение, что "везде будет котлин"

Kotlin, в пределе, покроет бекенд, фронтенд, Android, iOS и Windows. Kotlin/JVM, Kotlin/JS, Kotlin/Native

Денис Загаевский:

если ты хочешь чтобы люди тебя понимали - пользуйся общеупотребимыми понятиями.

1. например, термин native означает, что программа будет откомпилирована в бинарный вид и исполняться непосредственно на процессоре безо всяких виртуальных машин
никаких предпосылок, что это когда-то случится с Котлин - нет.

2. так как вы предлагаете использовать Котлин (не JS-транслированный) в браузере?

dinegnet: как тогда называет андроид приложения на джава без использования NDK?

sim3x: там речь об iOS

dinegnet:
Что не отменяет моего интереса к вопросу, как различать натив в байткоде и натив в скомпиленном виде

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

sim3x: приведенная вами цитата про трактовку в контексте iOS

dinegnet: А котлин для iOS?

sim3x: вот в этом и вопрос.
гражданин Денис Загаевский: утверждает, что "Котлин будет везде":

Kotlin, в пределе, покроет бекенд, фронтенд, Android, iOS и Windows. Kotlin/JVM, Kotlin/JS, Kotlin/Native

Насчет Андроида как раз никаких вопросов и нет.
Котлин рожден для JVM. Его уже прикрутили на Андроид и будут развивать в этом направлении
Все дело в том, что это легко и просто.

Что до других платформ - то тут у Дениса разыгралась фантазия.
JetBrains недостаточно мощная компания для этого.
А Котлин не настолько распространен, чтобы community заинтересовалось и на серьезном уровне запилила его для всех платформ.

Причем этому не видно никаких подсказок: Котлин не настолько выдающийся язык. Все предыдущие попытки запилить универсальный и удобный для всех платформ язык, участниками которых были не менее достойные, чем Котлин конкуренты - те попытки не удались.

Ни о каком совместном решении MS, Google, Jetbrains и Apple по этому поводу тоже ничего не слышно.

Вот я и диву даюсь - на основании чего Денис это решил.

dinegnet: ты чё тупишь? Я тебе говорю - на
iOS оно будет нативное. Бинарный код. На iOS. Процитировал даже.

Для фронтá там трансляция в js, и, в перспективе, WebAssembly. С этим никто не спорит.

dinegnet:

а давайте вы не будете придуматься новое значение устоявшихся терминов?

А я и не придумываю.

(of a device or program) directly accessed by the user and allowing access to further devices or programs.

https://www.google.com/search?q=define%3A+frontend
И ни слова про браузер.

А на вики про веб есть, но как частный случай.
https://en.wikipedia.org/wiki/Front_end#Computing

Денис Загаевский:

Ну и как бы вкусно писать full-stack на одном языке, под все платформы, вместе с бекендом. Кажется, прецедентов ещё не было.

А как же Clojure/ClojureScript? В отличие от Kotlin оно как раз вполне юзабельно на фронтенде и обросло даже своей экосистемой (в основном завязанной на React).

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

Денис Загаевский: вакансии на него есть (я к слову на Kotlin тоже не видел, но верю, что они есть), Android поддерживает, на счёт iOS - хз, я нагуглил пару вариантов, но они как-то не очень активно поддерживаются. А так, есть React Native, который (к моему удивлению) судя по нагугленным мной бенчмаркам показывает вполне достойную производительность на мобильных платформах. Вот для сборки ClojureScript + React Native приложений под iOS я нагуглил несколько активно поддерживаемых вариантов, на первый взгляд минусов в таком подходе по сравнению с использованием JVM под iOS я не вижу, но конечно могу ошибаться, так как я только чуть-чуть пробовал писать под Android (кстати, и на Kotlin, я вообще-то против него ничего не имею, если что, язык классный) и вообще не пробовал писать под iOS.

Stalker_RED:
в данном контексте Денис словом фронтенд называл именно браузер.
есть еще значение слова фронтенд - в смысле "клиентское десктопное приложение, не обязательно браузер", но в контексте нашего разговора это бессмысленно, так как речь шла о конкретных платформах.
поэтому Денис говорил именно о поддержке в браузере.

Вот мне и интересно - какой такой нативный Котлин может быть в браузере. если там только ЯваСкрипт укоренился. И все кто проникли в браузер - только через трансляцию. Никто не будет ставить браузеров с Котлином внутри. Разве что Денис. Но это не показатель. Чтобы это работало, такие браузеры должны быть хотя бы на каждом третьем компьютере в мире.

Даниил Колесниченко:
Ну да, о том и речь.
Не понятно из каких соображений Денис считает, что Котлин завоюет всех. У Кложура и то больше шансов.

Денис Загаевский:
слабо представляете о чем пишете.

вы вообще задумывались - а почему так мало полноценных языковых альтернатив на некоторых платформах? библиотеки ибо, обвязки, связь с ОС, API ОС.

бинарную компиляцию на iOS кто только не умеет.
к примеру Go умеет это лет пять как - и никакого толку, так как нет библиотек почти

без наличия библиотек для взаимодействия с платформой - наличие "родного" бинарника ничего не дает.

на JVM под Android - да.
тут нет никаких проблем с доступностью библиотек у Котлина, он может Явовские использовать.

iOS в native - это ваша фантазия.
скомпилировать то можно научить сравнительно легко.

использовать - нет.
написание всей обвязки для доступа к функциям iOS не осилить.

Денис Загаевский:

Для фронтá там трансляция в js, и, в перспективе, WebAssembly. С этим никто не спорит.

тогда в этом смысле Kotlin ровно такой же как и еще туева хуча не взлетевших языков.
в JS умеют превращаться множество межплатформенных языков.
Котлин тут ничем не выдается.
если вас устраивает JS в браузере, то уже до Котлин существовали много лет как переносимые меж платформами языки.
хоть тот же Go.
он есть и в браузере через JS и на бэкенде и на iOS и на Windows и на Android.
только толку от этого нет ровным счетом никакого.
на бэкенде Go чувствует себя прекрасно.
на остальных платформах - только для галочки.

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

а все остальные платформы будут для Котлина столь же недосигаемы - он на них будет нефункионален, убог и неюзабелен.
так же как и Go.

dinegnet: это не моя фантазия, а создателей Котлина.

dinegnet:

Вот мне и интересно - какой такой нативный Котлин может быть в браузере. если там только ЯваСкрипт укоренился. И все кто проникли в браузер - только через трансляцию.

Нуу возможно имелась ввиду компиляция в какой-нибудь WebAssembly, хотя мне пока не совсем ясно куда вообще WASM приведёт фронтенд и начнут ли браузерные клиенты массово писать на языках, компилируемых в WASM. С другой стороны, трансляция в JS - это в принципе нормально, но с Kotlin я вижу проблему вот в чём: Kotlin статически типизирован, при этом система типов у него отличается от системы типов какого-нибудь TypeScript. Это значит что для использования любого браузерного API и любой JS-библиотеки придётся писать типизированные обёртки. И из-за несовместимости с TypeScript просто взять TS-декларации (*.d.ts) нельзя. Можно конечно писать обёртки не заморачиваясь с типами (везде Any), но во-первых, объявлять-то функции и классы все равно придётся явно, во-вторых, тогда теряем преимущества статической типизации Kotlin. Почему на мой взгляд ClojureScript так прижился во фронтенде, так это благодаря крайне лёгкой интеграции с платформой (в том числе благодаря динамической, как и у JS, типизации).