тогда как Java-сахарок завозят лишь в Java 14+, которая в репах многих дистров Linux’а появится с типичным опозданием.

А в консервативном Debian как раз наоборот: Java самой распоследней версии, Scala в ужасном заброшенном состоянии из-за её новой монстроидальной системы сборки sbt. А Kotlin… а котлина нет вообще. Но готовят. Но готовить могут годами.

Можно, если есть нормальный Джава-бэкграунд.

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

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

И кто такие эти джетбрайнс? Бизнес таких не знает.

Ошибочное суждение. Хорошо знает. За JetBrains куча IDEA-based IDE и сотрудничество с Google по части Android. А мобильный рынок по капитализации сегодня может дать форум ынтерпрайзному с Oracle/IBM/Microsoft. Если бы это было иначе, мелкософт бы так не копротивлялся, пытаясь залезть туда, где балом правит Google и Apple.

А в консервативном Debian как раз наоборот: Java самой распоследней версии, Scala в ужасном заброшенном состоянии из-за её новой монстроидальной системы сборки sbt. А Kotlin… а котлина нет вообще. Но готовят. Но готовить могут годами.

Для тех проектов на котлине, что обычно появляются в энтерпрайзе, достаточно лишь Java-runtime 7-8 версии, всегда доступной в системных репозиториях. Отдельный компилятор по сути не требуется вообще, ибо идёт сразу с IDEA, а системы сборки вроде Gradle и Maven сами выкачивают всё нужное определённых версий и собирают тебе JAR или WAR.

checked exceptions тупо не вписываются в stream api и лямбды, и заставляют колхозить костыли

ссылка

Exception вообще не «вписываются» в реактивное программирование, их нужно выпилить.

Вот бы ЛОР переписали на Kotlin, Scala потихоньку помирает.

Вот бы языки для описания (синтезируемой) цифровой логики Chisel и SpinalHDL переписали на что-нибудь с… Scala. Надо же было до такого додуматься, для такой области взять Scala. Вот MyHDL на питоне ещё куда ни шло, и в Debian уже есть.

Надо же было до такого додуматься, для такой области взять Scala.

Ого. Очень сильно чем был обусловлен такой выбор.

Хороший вопрос. На EEVblog спекулируют, что причина как всегда:

IMHO Chisel is a typical product of academia where people tend to be more interested in the process as opposed to result.

Scala была разработана в швейцарском политехническом университете в Лозанне, если не ошибаюсь. Вот и в Беркли решили, а давайте возьмём язык коллег. Хотя до этого славились своей практичностью.

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

Для любых эксепшнов в потоковой модели обработки нужно городить «костыли».

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

На самом деле, Котлин предлагает решение, и, собственно, Елизаров в статье приводит его часть: вместо выбрасывания эксепшна возвращать sealed class результата, с двумя основными состояниями: «успех» и «неудача», - и вторым sealed class внутри неудачи, детально описывающим причину факапа. Го на максималочках.

На практике оказывается, что использовать такой способ в многослойном приложении, - например, слой операций над БД, слой бизнес-логики и протокольный и/или интерфейсный слои, - довольно утомительно и громоздко. Особенно, если внутри каждого «большого» слоя есть несколько слоев потоньше со своими цепочками вызовов.

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

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

И checked exception-ы в этой парадигме приходится обрабатывать точно также как и unchecked с той лишь разницей, что checked exception'ы при вызовах библиотечных функций видны сразу, а для unchecked'ов надо шерстить документацию.

На практике оказывается, что использовать такой способ в многослойном приложении, - например, слой операций над БД, слой бизнес-логики и протокольный и/или интерфейсный слои, - довольно утомительно и громоздко. Особенно, если внутри каждого «большого» слоя есть несколько слоев потоньше со своими цепочками вызовов.

это ты про какие-то страшные жирные монолиты рассказываешь, я такое боюсь

Scala не помирает. Просто швейцарские академики решили повторить выдающийся успех переходов python2→python3 или даже perl5→perl6.

Scala не помирает

А есть ли резон мне начинать ее учить сейчас или лучше Джаву?

Bладимир

Но есть кое что, что мне не нравится в этих языках - маленький рантайм тащит за собой большую виртуальную машину.

Bладимир

Ну выучишь этот хипсторский язычок. Денег на работе не добавят, бабы как не давали, так и не будут. В чем смысл потраченного времени?

Язык программирования Kotlin, разработанный петербургской компанией JetBrains, стал официальным языком разработок для Android. Об этом официально объявили на конференции Google I/O.

Bладимир

Джаву — если нужно вот прям щаз на галеру устраиваться. Скалу — если хотите сделать долговременную инвестицию в образование.

Я на него только из-за этого и обратил внимание, помню смотрел гугловский event про запуск android 8 и там объявили про kotlin. До того момента для меня что Kotlin, что Ceylon были чем-то вроде nim и crystal т.е. какие-то мифические языки которыми никто не пользуется.

Но есть кое что, что мне не нравится в этих языках - маленький рантайм тащит за собой большую виртуальную машину.

Больших, средних, … малых виртуальных машин не бывает …

Владимир

Джаву — если нужно вот прям щаз на галеру устраиваться. Скалу — если хотите сделать долговременную инвестицию в образование.

На галеру не пойду, а самообразоваться всегда рад. Благодарен вам премного за совет.

Bладимир

почему не сделать расширение к джаве вместо изобретения велосипеда.

В Java сделали этот велосипед под названием Lombok. И оказалось, что лучше бы его не делали. :)

А так есть ещё есть reified типы, data class-ы, extensions (но с их помощью можно сделать ещё хуже) и т. д. Где тут проскакивала ссылка на доклад «java 19 vs kotlin», и там показано, что разница уже практически минимальна. Но это надо во-первых ждать, когда выйдет java 19 и во-вторых дождаться для миграции legacy на 19-ую версию. А с котлином можно пользоваться уже всем прямо сейчас.

И при этом нет того груза обратной совместимости как в Java. Я не то, чтобы против обратноц совместимости, но это просто инструмент, когда-то он нужен, а иногда даже мешает :)

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

Сахарок так себе, на самом деле. Попробуйте без IDE разобраться в котлиноскриптах и «повыводить» типы возвращаемых данных. То себе «удовольствие».

Когда попробуешь покодить на сахарке, возвращаться к ванильной Java не слишком хочется.

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

И преимущество сахарка в том, что он доступен из коробки под какой-нибудь древней Java 8 или вообще Java 7

Забыли сказать, что для того, чтобы он стал доступен из коробки, надо ещё котлинобиблиотеки в свой проект притащить.

тогда как Java-сахарок завозят лишь в Java 14+

А вообще, что-то это мне напоминает… А, вспомнил: https://cellperformance.beyond3d.com/articles/2008/03/three-big-lies.html

(Lie #3) Code is more important than data

This is the biggest lie of all. Programmers have spent untold billions of man-years writing about code, how to write it faster, better, prettier, etc. and at the end of the day, it's not that significant. Code is ephimiral and has no real intrinsic value. The algorithms certainly do, sure. But the code itself isn't worth all this time (and shelf space! - have you seen how many books there are on UML diagrams?). The code, the performance and the features hinge on one thing - the data. Bad data equals slow and crappy application. Writing a good engine means first and formost, understanding the data. 

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

Саха это ведь ничто иноке как шаблон/подход встроенный в язык, ведь писать ООП-подобный код можно и на сях, но писать на языке где эта абстракция встроена намного удобнее. Тоже самое асинхронность, можно писать асинхронный код использовав фреймворк + колбеки, но если асинхронный код можно писать через suspend/async/await то получается проще.

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

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

Хорошая замена для мертвой Скалы.

Пока жив спарк, жива скала

а программизды на сколе больше зоробатываюд

а не по капле новых методов в класс String в два года,

Хватит развития ради развития.

Казалось бы, хочешь сахарок, есть скала, но нет

Котлин жив пока жив Андроид, а долго ли проживет Андроид? Я вот смысла не понял делать и хайпить яп ради костыля (ввиде надстройки к ядру линукс), чем и является Андроид по своей сути.

Казалось бы, хочешь сахарок, есть скала, но нет

Когда появилась scala одна часть программистов её стала использовали как улученную java, другая часть как функциональный язык, т.е. одни писали ООП, другие монады и функторы. Первые увидели что scala позволяет писать очень плохой код, они вернулись на java. О сложности языка и отказе от scala была куча статей в свое время. Теперь scala это вотчина функцоинальщиков и мигрантов с haskell.

есть

Android NDK, остальное лирика.

А для Kotlin есть полнофункциональные более-менее мейнстримовые фреймворки для веб-разработки, навроде Play в Scala? Или там toolset скорее под Android?

Spring во всю поддерживает kotlin. У них даже в доке примеры коды на java и kotlin. А так есть ktor, на любителя, api как DSL для конструирования REST сервиса. Я считаю DSL там не оправдан.

Вот тулза как надстройка над Spring(есть различные кастомные отличия, но уверенно движется в сторону Spring), в которой можно писать на котлине https://www.cuba-platform.ru/

Чтобы писать на скале без функторов и монад, это надо приложить усилие

Ну сами посудите, как так могло получится, что ТАКОМУ человеку дали ТАКОЙ проект международного уровня.

А что значит «дали»? Чуть ли не большинство мейнстримовых ЯП начиналось как инициативные проекты одного-двух людей. И ничего, взлетели.

Или ты себе это представляешь как собрание совета директоров крупной корпорации, которое решает - вот этот надёжен, морально устойчив, мы ему, блин, ДАДИМ проект международного уровня? Это какая-то логика парторга в СССР брежневских времён (к СССР я отношусь скорее хорошо, чем плохо, но не в этом вопросе).

> Приглашаем всех желающих на четырехдневную онлайн-конференцию, посвященную Kotlin 1.4!

Котлеты будут?