Что-то про Scala давно ничего не слышно. Вроде новые релизы активно пилят, сам по себе язык сильный и выразительный, судя по последнему SO опросу, Scala разработчики самые высокооплачиваемые в мире...
А у нас тут тишина. Никто ничего не пишет? Все всё знают? Заинтригован
Здравствуйте, kaa.python, Вы писали:
KP>Что-то про Scala давно ничего не слышно. Вроде новые релизы активно пилят, сам по себе язык сильный и выразительный, судя по последнему SO опросу, Scala разработчики самые высокооплачиваемые в мире...
KP>А у нас тут тишина. Никто ничего не пишет? Все всё знают? Заинтригован
Здравствуйте, BlackEric, Вы писали:
KP>>А у нас тут тишина. Никто ничего не пишет? Все всё знают? Заинтригован BE>Все же на Котлин в джава мире переходят.
А он разве не больше про мобилки нежели про "весь JVM мир"?
Здравствуйте, kaa.python, Вы писали: KP>А у нас тут тишина. Никто ничего не пишет? Все всё знают? Заинтригован
все ждут релиза 3.0
у нас (Elsevier) на бэкенде скала — основной язык
в ING, насколько я знаю, тоже
Здравствуйте, VladD2, Вы писали: С>>Потому что тут своеобразная тусовка. Даже шароварщики живы и почему-то не померли. VD>А чё им помирать то? Виндовые десктопы, бэкэнды и даже переносимые кзамарин-мобилки на нем не плохо делаются.
Шароварщики, Влад, не шарписты...
Всё, что нас не убивает, ещё горько об этом пожалеет.
1. Java. Когда Scala была популярна, у Java после 1.6 через 5 лет вышла 1.7, в которой почти ничего нового не было. То бишь чувствовался такой жёсткий застой. Поэтому была популярна Scala как единственная достойная альтернатива. В настоящее время Java развивается очень хорошими темпами и нужда в альтернативах пропала. Поэтому свои позиции она укрепляет.
2. Kotlin. Язык очень простой, без академических закидонов. Стандартная библиотека простая как два рубля. Также есть non-null, которого нет у Scala. В общем для тех, кому не хватает практических фич в Java, он подходит намного лучше, чем Scala. Также его популярность нехило бустит статус официального Android языка.
3. Scala. По-моему он сейчас стал хаскелем от мира Java. Несмотря на то, что я его знаю, желания писать на нём у меня нет. Очень эзотерические фичи, которые сложно понять. Очень эзотерическое коммьюнити, любители смайликов для всяких foldl. Автор языка пилит несовместимую Scala 3, как я понял. Многие проекты на моей памяти переезжали со Scala на Java. В общем, имхо, это судьба хаскеля — мега умники будут на нём писать, а простым людям оно не надо. Отсюда и высокие зарплаты, эти люди даже на бейсике будут получать высокую зарплату, а смотреть на этот показатель не надо, это тупо элита программирования, вот и всё. И от того, что вы выучите Scala, в эту элиту вы не попадёте, там отбор идёт не по языку программирования а по числу ссылок на докторскую диссертацию, грубо говоря.
Здравствуйте, kaa.python, Вы писали:
KP>А у нас тут тишина. Никто ничего не пишет? Все всё знают? Заинтригован
Scala интересная, но сложная.
Имхо, держится за счет Spark — будет развиваться пока Spark не перепишут на чем-нибудь другом.
Плюс, наверное, будет поддерживаться как академический язык (как haskell), пока в Java не появится что-томощное с ФП и типами.
Kotlin — питон в мире Java. Скоро все будут писать на нем — и мобилку и серверы.
Здравствуйте, kaa.python, Вы писали:
KP>Что-то про Scala давно ничего не слышно.
Сдохла. Вместо того, чтобы работать на постройку стабильной экосистемы, разработчики Скалы пилят 100500-ю версию "новых коллекций в формалистике SI-алгебры для формального анализа". В результате, код на Скале по сложности понимания уже обогнал C++.
Ну и Скале пришёлм полный Котлин. В нём прекрасный баланс между краткостью, практичностью и лёгкостью понимания.
Здравствуйте, Cyberax, Вы писали:
C>Сдохла. Вместо того, чтобы работать на постройку стабильной экосистемы, разработчики Скалы пилят 100500-ю версию "новых коллекций в формалистике SI-алгебры для формального анализа". В результате, код на Скале по сложности понимания уже обогнал C++.
Мне кажется они в началае 2010-х уже сумели обогнать C++ по сложности, но вроде тогда это народ сильно не пугало.
C>Ну и Скале пришёлм полный Котлин. В нём прекрасный баланс между краткостью, практичностью и лёгкостью понимания.
Наверное именно в Котлине дело. Но если посмотреть по вакансиям, то Котлин — это практически только мобилки, а Скала либо бэкенд, либо анализ данных. Всё же какие-то экосистемные прдпочтения есть.
Здравствуйте, VladD2, Вы писали:
VD>Весь мир JVM больше про мобилки, так именно в этой нише Ява безальтернативна в виду ее встраивания в ОС. VD>А сам язык JVM-мный и потому может использоваться где угодно. Как он может быть про мобилки?
Довольно легко может быть что язык обычно применяется в какой-то одной сфере. И в случае с Котлином это обычно — мобилки. Как-то так.
В качестве доказательства моей теории берем любой сайт с вакансиями и вбиваем сначала Котлин, видим что 90% выдачи — мобилки. Потом вбиваем Скала, видим что 50% выдачи бэкенд, 50% выдачи анализ больших данных. То, за что платят с деньги, обычно является лучшим критерием понимания где обычно язык/технология используется.
Здравствуйте, kaa.python, Вы писали:
C>>Сдохла. Вместо того, чтобы работать на постройку стабильной экосистемы, разработчики Скалы пилят 100500-ю версию "новых коллекций в формалистике SI-алгебры для формального анализа". В результате, код на Скале по сложности понимания уже обогнал C++. KP>Мне кажется они в началае 2010-х уже сумели обогнать C++ по сложности, но вроде тогда это народ сильно не пугало.
Ага.
C>>Ну и Скале пришёлм полный Котлин. В нём прекрасный баланс между краткостью, практичностью и лёгкостью понимания. KP>Наверное именно в Котлине дело. Но если посмотреть по вакансиям, то Котлин — это практически только мобилки, а Скала либо бэкенд, либо анализ данных. Всё же какие-то экосистемные прдпочтения есть.
Бэкэнд на Котлине тоже есть. Ещё часто компании просто вывешивают объявления по поиску Java-программистов, и уже на месте переучивают на Котлин.
Здравствуйте, Cyberax, Вы писали:
C>Бэкэнд на Котлине тоже есть. Ещё часто компании просто вывешивают объявления по поиску Java-программистов, и уже на месте переучивают на Котлин.
Да я вроде не говорил что его нет, как минимум 10% есть, если смотреть по факансиям.
А вот если посмотреть на измениня, varenikAA выше линку повесил, хорошие же изменения, годные очень я бы сказал. По идее писать да писать на таком замечательном языке, но нет
Здравствуйте, kaa.python, Вы писали:
KP>А у нас тут тишина. Никто ничего не пишет? Все всё знают? Заинтригован
Я уже несколько раз рассказывал эту историю, но она продолжает развиваться. Имел счастья работать за последние 8 лет в двух инвест.банках, Имена называть не буду, кто работает на wall street знает, это крупные игроки. В каждом банке были созданы очень похожие системы примерно в одно и тоже время, но в одном на скале, а в другом на питоне.
В общем я в своем карьерном движение переместился с питона на скалу и будучи фанатом FP испытывал по этому поводу некоторый оптимизм.
К сожалению в настоящий момент наступилоэ полное разочарование.Система на питоне была на порядок производительный и удобней, как для пользователей, так и для разработчиков.
Сам я квант и в данный момент дело дошло до того, что мы фактически перестали вести разработку в скале и переходим в питон и kdb(библиотеки с моделями для ценообразования .остаются на плюсах) У ИТ такой возможности ессно нет и они продолжают пилить скалу.
Здравствуйте, novitk, Вы писали:
N>К сожалению в настоящий момент наступилоэ полное разочарование.Система на питоне была на порядок производительный и удобней, как для пользователей, так и для разработчиков.
А почему разочарование, не затруднит чуть подробнее?
Ну и как возможно сделать что-то, что медленнее чем Python? Или у вас тонкий слой Python, который скрывает жирный слой на C++?
N>Сам я квант и в данный момент дело дошло до того, что мы фактически перестали вести разработку в скале и переходим в питон и kdb(библиотеки с моделями для ценообразования .остаются на плюсах) У ИТ такой возможности ессно нет и они продолжают пилить скалу.
Я правильно понимаю что устали от своего рода C++ на JVM?
Здравствуйте, kaa.python, Вы писали:
C>>Бэкэнд на Котлине тоже есть. Ещё часто компании просто вывешивают объявления по поиску Java-программистов, и уже на месте переучивают на Котлин. KP>Да я вроде не говорил что его нет, как минимум 10% есть, если смотреть по факансиям.
Я заглянул на monster.com по слову Kotlin в области Seattle, WA. Чисто мобильных вакансий (Android) на глаз где-то так процентов 50. Остальное — backend или совмещённое.
Здравствуйте, Cyberax, Вы писали:
C>Я заглянул на monster.com по слову Kotlin в области Seattle, WA. Чисто мобильных вакансий (Android) на глаз где-то так процентов 50. Остальное — backend или совмещённое.
А для Котлета что-либо похожее на АККА завезли? Мне кажется что это одна из главных фич Scala.
Здравствуйте, kaa.python, Вы писали:
C>>Я заглянул на monster.com по слову Kotlin в области Seattle, WA. Чисто мобильных вакансий (Android) на глаз где-то так процентов 50. Остальное — backend или совмещённое. KP>А для Котлета что-либо похожее на АККА завезли? Мне кажется что это одна из главных фич Scala.
В Котлине есть свои корутины. Впрочем, большинство из того, что видел, просто использует Котлиновский порт Spring'а.
Здравствуйте, kaa.python, Вы писали:
KP>А почему разочарование, не затруднит чуть подробнее?
Вопрос не мне, но все же отвечу. Я тестил Scala в надежде использовать ее в нашем проекте. На первый взгляд казалось что это крутая идея, но на практике выяснилось что Scala просто люто тормозит. По сравнению с грамотно затюненой Java на порядок, не меньше. Учитывая, что сама Java тормозит относительно грамотно затюненных специализированных решений еще на порядок, получается совсем грустно. Выходит что вместо 16 серверов, как у нас, или двух серверов, как у наших конкурентов, после миграции на Scala нам потребовалось бы почти 200 машин. После этого вопрос о скале закрылся раз и навсегда. Вторая проблема которая вылезла это текущие в самых неожиданных местах абстракции поверх JVM. Мало того что сам JVM древний, так его разработчикам в страшном сне не могло присниться что поверх JVM будут строить чистый функциональный язык. Третья проблема это то, что Scala в действительности никак не ускоряет разработку. Там, где ты на Java можешь взять и сделать, на Scala ты сперва долго дизайнишь систему типов, а потом пытаешься упихать в нее свою задачу. И не дай бог ты чего-то не учел, системы типов в Scala получаются очень жесткие и на каждое изменение приходится их редизайнить. В итоге у меня сложилась впечатление что Scala хорошо годится лишь там, где есть четко определенная предметная область, сильно затруднено тестирование, при этом абсолютно безразлична производительность. Лично я таких областей не знаю, поэтому Scala и скатилась в какие-то совершенно маргинальные ниши.
Здравствуйте, kaa.python, Вы писали:
KP>А у нас тут тишина. Никто ничего не пишет? Все всё знают? Заинтригован
В общем, тут много написали по существу, но ИМХО основная проблема просто в том, что джавистам хотелось ФП. Вот они и делали вылазки в сторону Scala — больше же некуда, не на Хаскель же. Как только в Яву ввели ФП — так все вернулись в родную гавань.
Кстати, в экосистеме дотнета ФП уже было в момент наибольшей популярности Scala. Поэтому там никто на Scala и не взглянул — зачем ?
Здравствуйте, kaa.python, Вы писали:
N>>К сожалению в настоящий момент наступилоэ полное разочарование.Система на питоне была на порядок производительный и удобней, как для пользователей, так и для разработчиков. KP>А почему разочарование, не затруднит чуть подробнее?
Медленный компилятор, проект не был разбит на части. Перестройка мира от git clone занимала больше часа. Начали прикручивать глобальный кэш к компилятору. Ессно с кучей проблем, когда у людей начало выполнятся не то что они видят. Вроде сейчас более-менее наладили и свежая перестройка занимает 20 минут. На питоне на подобную деятельность тратилось ноль времени и усилий.
В ПитонБанк писались программки под конкретные цели в PySide или wxWidget, которые стартовали мгновенно, система пару лет назад вообще все еще была на 32-битах. В СкалаБанк все сливают в монстр апликухи, так как стартовое время на JVM уходит в минуты. Тут конечно дело не в скале, а похоже на обычную практику перегрузить все слоями, которая часто наблюдается в "энетрпайз джава". При этом ессно еще и память жрет как не в себя. В результате оно стало проблемой даже на трейдеровских рабочим станциям с 64ГБ и т.д. В результате переделали весь UI с swt на HTML, а процессы запускают не локально, а в облаке. В результате оно работает, но старт по прежнему медленный, UI лагает, все громоздко и потрачена куча времени и бабла.
Код перегружен абстракциями даже не функциональными (cats и прочие монады даже не используются), а обычной джава требухой с ненужными иерархиями и дженериками, но с добавлением скализмов в виде implicit, трейтов и прочего. Ситуация напоминает C++, когда народу раздали игрушки и бросили. Слава богу IDEA разбирает все это довольно неплохо, иначе была бы полная жопа.
Был внедрен Zeppelin(аналог jupyter), но почему-то запустить его можно только из IDEA и пока это все загрузится ты уже забудешь зачем оно было надо.
До продакшена в СкалаБанке код может плыть месяцами — все деплоится одним куском с кучей jar-ов и sharedlibs, а значит нужно утрясать кучу тестов и бюрократии с подписями. При этом косяки нукуда не деваются, но их стало весьма сложно откатить. В ПитонБанке новый код поверх старого, который ничего сломать не мог, можно было забросить в продакшен мгновенно, так как деплой был на уровне индивидуальных файлов. Если изменение было ломающее, то внедрялось оно частями и при поломках все было довольно тривиально откатить.
KP>Ну и как возможно сделать что-то, что медленнее чем Python? Или у вас тонкий слой Python, который скрывает жирный слой на C++?
Вычислительное едро конечно плюсы и там и там. Со скалой была идея, что можно будет и на ней потом делать, но до этого похоже не дойдет.
N>>Сам я квант и в данный момент дело дошло до того, что мы фактически перестали вести разработку в скале и переходим в питон и kdb(библиотеки с моделями для ценообразования остаются на плюсах) У ИТ такой возможности ессно нет и они продолжают пилить скалу. KP>Я правильно понимаю что устали от своего рода C++ на JVM?
Просто продуктивность ни к черту. Проект, который на питоне делается за неделю, тут до трейдеров доходит в лучшем случае через месяц.
Здравствуйте, kaa.python, Вы писали:
KP>А у нас тут тишина. Никто ничего не пишет? Все всё знают? Заинтригован
Лично я третью версию жду. Она уже почти готова. Реально по фичам получается мегаязык. Как выйдет, попробую какой проект запилить, как текущий закончится. Пока не вышла, сижу на Kotlin. До фич Scala даже второй версии сильно не дотягивает, но зато можно писать библиотеки и без проблем их использовать из проектов на любом языке. А там до третьей версии неопределенность — они весьма сильно переделывают язык, соответственно до третьей версии особо смысла начинать новые проекты нет, потом будет геморрой с переходом весьма вероятно.
Здравствуйте, novitk, Вы писали:
N>Просто продуктивность ни к черту. Проект, который на питоне делается за неделю, тут до трейдеров доходит в лучшем случае через месяц.
Спасибо, очень интересно! Перечитал дважды, но при чем тут Скала не очень понял. У меня создалось ощущение что Java разработчики накрутили очередного монстра, как положено их мире, но на Скале. Но эти деятели даже в Го пытаются свой мусор затащить
Здравствуйте, kaa.python, Вы писали:
N>>Просто продуктивность ни к черту. Проект, который на питоне делается за неделю, тут до трейдеров доходит в лучшем случае через месяц. KP>Спасибо, очень интересно! Перечитал дважды, но при чем тут Скала не очень понял. У меня создалось ощущение что Java разработчики накрутили очередного монстра, как положено их мире, но на Скале.
Я когда-то пытался выучить Скалу и использовать её для одного проекта (что-то типа компилятора). Но после месяца работы понял, что занимаюсь больше попытками подогнать всё под систему типов, а не продуктивной работой. Плюнул и переписал на тупой Java — кода получилось где-то раза в 4 больше по числу строк (не считая get/set-методов), но при этом он был написан за несколько дней.
Из того кода, который я видел внутри Амазона — везде примерно такая же история. Например, на Scala был написан автоматический доказыватель теорем для проверки IAM-политик. Но после того, как мега-гении, которые его писали, перешли в другие команды — новичкам пришлось год за ними разгребать. В итоге всё переписали на Kotlin.
Здравствуйте, Cyberax, Вы писали:
C>Из того кода, который я видел внутри Амазона — везде примерно такая же история. Например, на Scala был написан автоматический доказыватель теорем для проверки IAM-политик. Но после того, как мега-гении, которые его писали, перешли в другие команды — новичкам пришлось год за ними разгребать. В итоге всё переписали на Kotlin.
Приблизительно поэтому же с C++ переписывают на Go — просто не осилили технологию, да и вчерашних студентов надо куда-то приткнуть.
Здравствуйте, kaa.python, Вы писали:
C>>Из того кода, который я видел внутри Амазона — везде примерно такая же история. Например, на Scala был написан автоматический доказыватель теорем для проверки IAM-политик. Но после того, как мега-гении, которые его писали, перешли в другие команды — новичкам пришлось год за ними разгребать. В итоге всё переписали на Kotlin. KP>Приблизительно поэтому же с C++ переписывают на Go — просто не осилили технологию, да и вчерашних студентов надо куда-то приткнуть.
Но ведь, блин, работает. Вчерашние студенты реально пишут и поддерживают код, который на С++ они бы ниасилили. И точно так же с Котлином против Скалы.
Здравствуйте, kaa.python, Вы писали:
KP>А для Котлета что-либо похожее на АККА завезли? Мне кажется что это одна из главных фич Scala.
А какая проблема использовать Akka из Kotlin? Я отвечу — никакой проблемы.
Здравствуйте, kaa.python, Вы писали:
KP>Спасибо, очень интересно! Перечитал дважды, но при чем тут Скала не очень понял. У меня создалось ощущение что Java разработчики накрутили очередного монстра, как положено их мире, но на Скале.
В принципе ты прав. Безусловно главная проблема в устоявшихся процессах, привычках и культуре, а не языке. Просто я думал, что Скала позволит подвинуть планку, как это произошло в ПитонБанке, где люди тоже не с луны свалились, а в основном приходили с той же явы. По факту оказалось, что крутизна системы типов, макросы и прочие языковые навороты оказались гораздо менее важны чем удобство, простота и скорость инфраструктуры для получение рабочего кода в продакшене.
Здравствуйте, elmal, Вы писали:
E>Лично я третью версию жду.
Я перестал ее ждать после того как открыл для себя julia. Это ровно то, что доктор прописал. Все остальное в сравнении просто тормозное и неудобное говно.
Здравствуйте, novitk, Вы писали:
N>Я перестал ее ждать после того как открыл для себя julia. Это ровно то, что доктор прописал. Все остальное в сравнении просто тормозное и неудобное говно.
Динамическую типизацию недолюбливаю, что то сложнее скриптов я на таком писать не буду. Собственно Scala жду именно из за системы типов, ожидаю union & intersection types, это то, что не хватает в kotlin и чего не хватает в Scala 2.
Здравствуйте, elmal, Вы писали:
N>>Я перестал ее ждать после того как открыл для себя julia. Это ровно то, что доктор прописал. Все остальное в сравнении просто тормозное и неудобное говно. E>Динамическую типизацию недолюбливаю, что то сложнее скриптов я на таком писать не буду.
В Julia есть опциональная типизация, с generic-функциями и прочим.
Здравствуйте, elmal, Вы писали:
E>Динамическую типизацию недолюбливаю, что то сложнее скриптов я на таком писать не буду. Собственно Scala жду именно из за системы типов, ожидаю union & intersection types, это то, что не хватает в kotlin и чего не хватает в Scala 2.
Julia не совсем правильно называть динамическим языком, как и typescript.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, BlackEric, Вы писали:
KP>>>А у нас тут тишина. Никто ничего не пишет? Все всё знают? Заинтригован BE>>Все же на Котлин в джава мире переходят.
KP>А он разве не больше про мобилки нежели про "весь JVM мир"?
Ну, вообще, он и не про мобилки и даже не про "весь JVM мир".
Просто они грамотно зашли дав андроид разработке возможности которые не может дать java 8+ по причине того что на старых андроидах старый jvm.
А так есть kotlin native, но пока jvm это основная платформа колтлина.
Здравствуйте, Quadri, Вы писали:
Q>Ну, вообще, он и не про мобилки и даже не про "весь JVM мир". Q>Просто они грамотно зашли дав андроид разработке возможности которые не может дать java 8+ по причине того что на старых андроидах старый jvm. Q>А так есть kotlin native, но пока jvm это основная платформа колтлина.
Я как человек который почти 20 лет обычно пишет на разных нейтивах считаю пользу Котлин нэйтив около нулевой, в отличие от того же Котлина для JVM
Здравствуйте, kaa.python, Вы писали:
KP>Приблизительно поэтому же с C++ переписывают на Go — просто не осилили технологию, да и вчерашних студентов надо куда-то приткнуть.
Либо ГО тупо удобнее для решения задач чем С++ начиная с девтулов, заканчивая фишками языка.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, Quadri, Вы писали:
Q>>Ну, вообще, он и не про мобилки и даже не про "весь JVM мир". Q>>Просто они грамотно зашли дав андроид разработке возможности которые не может дать java 8+ по причине того что на старых андроидах старый jvm. Q>>А так есть kotlin native, но пока jvm это основная платформа колтлина.
KP>Я как человек который почти 20 лет обычно пишет на разных нейтивах считаю пользу Котлин нэйтив около нулевой, в отличие от того же Котлина для JVM
Так у них нейтив исключительно для кросс-платформенности. Я так понимаю, по производительности их нейтив тормознее JVM версии.
Здравствуйте, kaa.python, Вы писали:
KP>Приблизительно поэтому же с C++ переписывают на Go — просто не осилили технологию, да и вчерашних студентов надо куда-то приткнуть.
В компании, где работаю, С++-ники в очереди на собеседование стоят. В самом начале матёрые, в конце толпы студней (С++ изучается в ВУЗ-ах, в отличии от Go). Go-шников же найти практически нерально (из откровений руководителя проекта на Go), С++-ников склоняют поучаствовать в Go-проект. Да и стоят Go-шники уже давненько дороже плюсовиков. Что-то Вы отстали от жизни с парадигмой "Go для обезъян по рублю за пучок".
Здравствуйте, smeeld, Вы писали:
S>В компании, где работаю, С++-ники в очереди на собеседование стоят. В самом начале матёрые, в конце толпы студней (С++ изучается в ВУЗ-ах, в отличии от Go). Go-шников же найти практически нерально (из откровений руководителя проекта на Go), С++-ников склоняют поучаствовать в Go-проект. Да и стоят Go-шники уже давненько дороже плюсовиков. Что-то Вы отстали от жизни с парадигмой "Go для обезъян по рублю за пучок".
Это московская специфика, скорее даже скорее российская. Обычно РФ на 3-5 лет по трендам от мира отстаёт, поэтому сейчас просто мартышек не хватает, вот и берут их за дорого. Скоро рынок насытится и ситуация поменяется. Сейчас у нас тут противоположная ситуация — куча Go разработчиков, и куча позиций на C++, которые невероятно трудно закрыть.
KP>Это московская специфика, скорее даже скорее российская. Обычно РФ на 3-5 лет по трендам от мира отстаёт, поэтому сейчас просто мартышек не хватает, вот и берут их за дорого. Скоро рынок насытится и ситуация поменяется. KP>Сейчас у нас тут противоположная ситуация — куча Go разработчиков, и куча позиций на C++, которые невероятно трудно закрыть.
Да уж как скоро-то? Golang, как бы, уже далеко не маленький, и в РФ все крупнейшие компании на нём много чего пилят уже лет 5 как (даже в банковском тырпрайзе), а ситуация (по словам того же тимлида), только хуже последние пару лет.
Может тут как раз причина в том, что у вас на Go мало кто чего пилит, а в РФ наоборот?
Здравствуйте, kaa.python, Вы писали:
KP>Это московская специфика, скорее даже скорее российская. Обычно РФ на 3-5 лет по трендам от мира отстаёт, поэтому сейчас просто мартышек не хватает, вот и берут их за дорого. Скоро рынок насытится и ситуация поменяется. Сейчас у нас тут противоположная ситуация — куча Go разработчиков, и куча позиций на C++, которые невероятно трудно закрыть.
Один из апологетов плюсов из Омерики как-то заявил, что в России язык C++ популярнее, чем у них на родине. Честно говоря, я рад был такому сравнению.
KP>Бегло глянул документацию. В Скале тоже есть из коробки, но это несколько разные весовые категории с Akka.
Давно уже нет, в 2.10 была deprecated, потом выпилили. Сейчас на дворе версия 2.13. Все-таки акторы — это специфическая штука и далеко не в каждой программе нужны. А кому нужны — есть библиотеки.
Здравствуйте, kaa.python, Вы писали:
KP>А у нас тут тишина. Никто ничего не пишет? Все всё знают? Заинтригован
А нечего обсуждать. У скалы высокий порог вхождения. Причем не только в сам язык. Она очень гибкая и мощная, поэтому большинство задач имеют несколько совершенно различных решений. Нужно очень хорошо понимать проблему и альтернативные подходы. Если просто первое предложение из Гугла, обычно ничего красивого в итоге не получится. Это приводит к ситуации, когда Scala-разработчики сильно фрагментированы.
Есть команды, где взяли какую-то библиотеку (spark, akka) и только поэтому берут и язык. Им обсуждать нечего, они прямо по-учебнику библиотеки пишут.
В других командах Scala берут именно из-за богатства языка (и системы типов). Но там практически всегда есть человек, который уже все знает и принял решение. Поэтому тем для обсуждения на форуме нет. Плюс у нас в городе, например, до covid проводились meetup, на которых разные интересные вещи показывались. Там можно было иногда всякую маргинальщину обсудить.
В третьих командах ее берут "попробовать". Но не желают инвестировать много времени на изучение. Более того, не желают менять устоявшиеся в стеке Java привычки. В результате получается java-style с сахаром. И его с таким же успехом можно заменить котлином. Он менее страшен, поэтому разработчики используют его.
Мы — используем в силу осознанной необходимости, при этом с higher-kinded polymorphism. Удобно, одна и та же логика может работать асинхронно (сейчас станадртный режим работы) или синхронно (тесты, потенциально в лямбды и прочий serverless удобно). При необходимости всякие distributed tracing можно по всему приложению прозрачно для промежуточных сервисов протаскивать (в асинхронном выполнении, да).
Здравствуйте, smeeld, Вы писали:
S>Да уж как скоро-то? Golang, как бы, уже далеко не маленький, и в РФ все крупнейшие компании на нём много чего пилят уже лет 5 как (даже в банковском тырпрайзе), а ситуация (по словам того же тимлида), только хуже последние пару лет.
Где-то 5 лет назад, когда мы только начинали использовать Go, на рынке вообще не было никого кто бы его знал. Сами набили шишек и теперь хоть в консультанты по Go иди. А зато сейчас такое ощущение, что на Go тут пишут вообще все, но вот найти кого-то кто достаточно хорошо знает C++ огромная проблема. Плюсовые вакансии крайне медленно закрываются.
S>Может тут как раз причина в том, что у вас на Go мало кто чего пилит, а в РФ наоборот?
В РФ, почему-то, всегда было очень много разработчиков на C++ и новые люди с радостью шли в эту сферу.
Здравствуйте, maxkar, Вы писали:
M>Мы — используем в силу осознанной необходимости, при этом с higher-kinded polymorphism. Удобно, одна и та же логика может работать асинхронно (сейчас станадртный режим работы) или синхронно (тесты, потенциально в лямбды и прочий serverless удобно). При необходимости всякие distributed tracing можно по всему приложению прозрачно для промежуточных сервисов протаскивать (в асинхронном выполнении, да).
Спасибо, очень интересно! А то что в Lightbend по увольняли кучу народу не смущает? В духе всё сейчас сдохнет и надо будет переезжать...
Здравствуйте, kaa.python, Вы писали:
KP>А то что в Lightbend по увольняли кучу народу не смущает? В духе всё сейчас сдохнет и надо будет переезжать...
Не, не смущает. В таком виде это скорее политический риск ("почему вы используете что-то, что давно не менялось?") чем реальный. Пока с ним можно бороться ответом "у нас все работает, команда натренирована, зачем что-то переписывать?". Сложившаяся экосистема уже взрослая. Детских багов в компиляторе или платформе нет. Средства сборки привязываются к конкретной версии компилятора и платформы. Поэтому собиравшийся проект "случайно" собираться не перестанет. В стандартной библиотеке (которая "платформа") почти ничего нет. Большая ее часть — коллекции, плюс немного математики и ввода/вывода. Все остальное выделено в отдельные модули. В таком наборе нет security risk, а это обычно выступает самым главным аргументом за необходимость обновления. Так что здесь все хорошо.
Более реален риск с отсутствием поддержки в IDE. Лично меня это не пугает, у меня основной инструмент tmux + vim + sbt. Но команда может обидеться . В третьей версии Scala с этой проблемой будет легче. Там реализуют Language Server Protocol (LSP). В результате парсинг и прочее реализуется один раз в компиляторе а UI может быть разный. Как минимум в Visual Studio, Eclipse и Vim есть соответствующие плагины. Если интересно, проект называется Metals.
И самый большой риск — это изменения JVM от Oracle. Если они вдруг прекратят поддержку старых версий байткода (чего пока не случалось), старые версии Scala будет использовать невозможно. Вот здесь будет нужна поддержка. Но я на коммьюнити надеюсь. Или придется уйти в творческий отпуск на полгода и самому сделать. Правда потом политическая проблема встанет в полный рост Но если вдруг Оракл решится на такой шаг, в экосистеме java и без этого будет весело. Я не уверен, что в результате вообще платформу не придется менять.
Так что пока все нормально. Используем "старые проверенные решения". 3-5 лет мы как-нибудь продержимся, а к тому времени много чего может поменяться.
Здравствуйте, smeeld, Вы писали:
KP>>Приблизительно поэтому же с C++ переписывают на Go — просто не осилили технологию, да и вчерашних студентов надо куда-то приткнуть. S>В компании, где работаю, С++-ники в очереди на собеседование стоят.
Странно. Нам плюсистов приходится искать по всему миру. Пытаемся выращивать.
Здравствуйте, smeeld, Вы писали:
S>Здравствуйте, landerhigh, Вы писали:
L>>Странно. Нам плюсистов приходится искать по всему миру. Пытаемся выращивать.
S>В РФ поищите, заберите их отсюда, нам тут больше места останется.
Так те, кто
1. Мог
2. Хотел
Уже давно. Кто в Гугле, кто в Фейсбуке. Кто в HFT.
KP>Что-то про Scala давно ничего не слышно. Вроде новые релизы активно пилят, сам по себе язык сильный и выразительный, судя по последнему SO опросу, Scala разработчики самые высокооплачиваемые в мире... KP>А у нас тут тишина. Никто ничего не пишет? Все всё знают? Заинтригован
у кого там шило и неймётся всё?
выразительной мощи C# давно хватает за глаза
хватит плодить сущности и фрагментировать пространство разработки
Здравствуйте, Министр Промышленности, Вы писали:
МП>у кого там шило и неймётся всё? МП>выразительной мощи C# давно хватает за глаза МП>хватит плодить сущности и фрагментировать пространство разработки
Эм... кому хватает? Почему C#, а не Java? А почему не Go, его тоже для всего хватает
МП>>у кого там шило и неймётся всё? МП>>выразительной мощи C# давно хватает за глаза МП>>хватит плодить сущности и фрагментировать пространство разработки
KP>Эм... кому хватает? Почему C#, а не Java? А почему не Go, его тоже для всего хватает
мне хватает современного C#
ну подозреваю что и джавы тоже хватает (не знаю её) с костылями как тут писали для ФП
Go я тоже не знаю и даже не чувствую потребности узнавать что это
тут я могу быть неправ мол чужд новым веяниям
но опыт показывает, что последние лет 8 новые веяния исходят не от лучших специалистов и только вредят общей производительности
моё мнение — разработка была слишком фрагментирована и так
помимо языков есть ещё разные аппаратные платфомы, разные операционки
лень изучать новое — тоже верно
но опыт подсказывает что новое скорее всего очередное контрпродуктивное барахло и изучать его именнно что не нужно
Здравствуйте, Министр Промышленности, Вы писали:
МП>мне хватает современного C#
... МП>тут я могу быть неправ мол чужд новым веяниям
... МП>лень изучать новое — тоже верно МП>но опыт подсказывает что новое скорее всего очередное контрпродуктивное барахло и изучать его именнно что не нужно
Что ты вообще в АйТи делаешь? Можно же проще денег заработать
МП>>мне хватает современного C# KP>... МП>>тут я могу быть неправ мол чужд новым веяниям KP>... МП>>лень изучать новое — тоже верно МП>>но опыт подсказывает что новое скорее всего очередное контрпродуктивное барахло и изучать его именнно что не нужно
KP>Что ты вообще в АйТи делаешь? Можно же проще денег заработать
а я и эффективнее большинства в этом вашем айти
равных уже лет 8 не видел (допускаю что и они меня не видят в силу изоляции)
быдлокодят, применяют паттерны, методологиии и библиотеки не к месту
да и просто отстают по производительности
в том числе это потому что не трачу моральные силы на изучение барахла
Здравствуйте, Министр Промышленности, Вы писали:
МП>а я и эффективнее большинства в этом вашем айти МП>равных уже лет 8 не видел (допускаю что и они меня не видят в силу изоляции) МП>быдлокодят, применяют паттерны, методологиии и библиотеки не к месту МП>да и просто отстают по производительности
МП>>а я и эффективнее большинства в этом вашем айти МП>>равных уже лет 8 не видел (допускаю что и они меня не видят в силу изоляции) МП>>быдлокодят, применяют паттерны, методологиии и библиотеки не к месту МП>>да и просто отстают по производительности
KP>Как минимум 6 лет назад
это утверждение еще не было истинным, ну либо гениальности не оценили
откуда такой вывод?
я торговался в то время неправильно
можно было соглашаться на первое же предложение и не искать работу 2 месяца, как выяснилось
точнее предложения не последовало из-за того что я стал ломить невменяемую цену вместо того чтобы предложить её дать самим
кстати отработал тогда нормально, ведущий коллега попался покладистый, ответственный, даже немного мудрый
года на 3 старше меня
но по уровню тактического программирования и он мне не равнялся
Здравствуйте, kaa.python, Вы писали:
KP>Мне кажется они в началае 2010-х уже сумели обогнать C++ по сложности, но вроде тогда это народ сильно не пугало.
Здравствуйте, kaa.python, Вы писали:
KP>Где-то 5 лет назад, когда мы только начинали использовать Go, на рынке вообще не было никого кто бы его знал. Сами набили шишек и теперь хоть в консультанты по Go иди. А зато сейчас такое ощущение, что на Go тут пишут вообще все, но вот найти кого-то кто достаточно хорошо знает C++ огромная проблема. Плюсовые вакансии крайне медленно закрываются.
Дженерики то в Go добавили? Анонсы видел, но так и не знаю чем дело кончилось.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Дженерики то в Go добавили? Анонсы видел, но так и не знаю чем дело кончилось.
Да, наконец-то решились. Сделают как всегда примитивно, что бы даже мартышка не сломала, но думаю что зайдет хорошо, т.к. как минимум обобщенные алгоритмы и коллекции писать можно, ну а для типичного представителя Go-сообщества больше и не надо. Меня немного смущает подход к реализации который планируется использовать, т.е. можно было сделать более быстрое решение, но тут надо признать что те не многие обобщенные функции что сейчас есть в Go еще более криво реализованы.
Здравствуйте, kaa.python, Вы писали:
VD>>Дженерики то в Go добавили? Анонсы видел, но так и не знаю чем дело кончилось.
KP>Да, наконец-то решились. Сделают как всегда примитивно, что бы даже мартышка не сломала, но думаю что зайдет хорошо, т.к. как минимум обобщенные алгоритмы и коллекции писать можно, ну а для типичного представителя Go-сообщества больше и не надо. Меня немного смущает подход к реализации который планируется использовать, т.е. можно было сделать более быстрое решение, но тут надо признать что те не многие обобщенные функции что сейчас есть в Go еще более криво реализованы.
Встроенные в язык магические типы вроде map теперь перестанут быть магическими (ну хотя бы на уровне семантики)? Хватает ли этих генериков для того, чтобы выражать хотя бы их на 100%?
Здравствуйте, vsb, Вы писали:
vsb>Встроенные в язык магические типы вроде map теперь перестанут быть магическими (ну хотя бы на уровне семантики)? Хватает ли этих генериков для того, чтобы выражать хотя бы их на 100%?
Я не видел таких предложений. Вроде как эта кривая магия с нами теперь на всегда. Это же надо сильно сломать обратную совместимость что бы магию убрать.
Ну а в целом дженерики там нормальные. Не C++, конечно и не Haskell, вычисления на типах не замутить, но кому бы это в Go надо было?
Ну, это продолжение обещаний, которые я виде уже, наверно, два года назад. Синтаксис стал по разумнее. Первый вариант с двойными круглыми скобками был идиотским соасем.
KP>Сделают как всегда примитивно, что бы даже мартышка не сломала, но думаю что зайдет хорошо, т.к. как минимум обобщенные алгоритмы и коллекции писать можно, ну а для типичного представителя Go-сообщества больше и не надо.
Ну, больше всегда надо. Но может не в дженериках. А твое определение Гу-сообщества несколько пугает, так как попахивает на альтернативно одаренным, которым компьютер лучше не доверять.
KP> Меня немного смущает подход к реализации который планируется использовать, т.е. можно было сделать более быстрое решение, но тут надо признать что те не многие обобщенные функции что сейчас есть в Go еще более криво реализованы.
Посмотрел. Что-то какую-то дичь они городят с этими словарями. Им бы почитать как сделаны дженерики в дотнете. Там все довольно грамотно сделано. Сделали бы сохранение кода в неком промежуточном виде и генерацию специализаций при компиляции кода использующего обобщенные функции для размерных типов и общую реализацию для ссылочных. Или как в плюсах. Всегда генерить специализации, а потом свертывать те, что можно свернуть.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ну, это продолжение обещаний, которые я виде уже, наверно, два года назад. Синтаксис стал по разумнее. Первый вариант с двойными круглыми скобками был идиотским совсем.
Это уже не продолжение обещаний. До этого было обсуждение предложения, теперь же предложение принято. В Go довольно четко следуют процедуре и если приняли, то скоро будет. Обещают в течении пары релизов, значит около 1 года, может полутора.
VD>Ну, больше всегда надо. Но может не в дженериках. А твое определение Гу-сообщества несколько пугает, так как попахивает на альтернативно одаренным, которым компьютер лучше не доверять.
Да нормально, на деле в компаниях где куча студентов или просто средних разработчиков такой инструмент жизненно необходим и полностью себя оправдывает.
