Система типов Scala позволяет избегать ошибок в сложных приложениях, а рантаймы для JVM и JS позволяют строить высокопроизводительные системы с удобным доступом к огромной экосистеме библиотек.
Q: Какой стэк библиотек взять?
A: cats, http4s, doobie, circe, ZIO
Q: Какие либы НЕ брать?
A: play, izumi, tofu, джавовые фреймворки
Q: Хочу Java without semicolons
A: Обрати внимание на Котлин
Q: Хочу угорать по функциональщине и теории категорий
A: Посмотри на Хаскелль
Предыдущий тред тонет тут >>1665014 (OP)
>рантаймы для JS
Кому нужона скала на фронте?
И что там с компилятором, очередные свистоперделки поверх гугловского кложура? Он еще поддерживатеся вообще?
> Q: Какие либы НЕ брать?
> A: play, izumi, tofu
А что с ними не так?
> Q: Хочу угорать по функциональщине и теории категорий
> A: Посмотри на Хаскелль
Да ты ж ебанутый.
В Москве есть замкнутая тусовочка Scala-разрабов из желтых банков.
Их особенность в том, что это такая самобытная секта - они пилят собственную библиотеку эффектов, и не замечают происходящего в коммунити за их пределами.
Короче, каноничные борщехлебы, только сидящие не на шее у мамки, а каким-то образом пробравшиеся в отделы разработки банков.
Значит они няши и сделали всё правильно.
Единственный способ спасти сраное софтостроительсво от окончательного скатывания в сраное говно - это возврат от «доступно каждому» к элитарной культуре «рассчитано на умных людей», вопреки хотелкам буржуев. Потом ещё спасибо скажут.
Я сам занимаюсь подобной деятельностью и веду активную агитацию на местах.
мимо-фп-партизан
Главный laws это то, что у твоей мамы ты родился не очень умным. Это обычный обычный трейт с тайп параметрами.
Не в курсе что именно они там делают, но что именно ты назывешь матаном? Любую абстракцию? Так почти любая библиотека и особенно фреймворк в любом языке дает тебе свои абстракции.
Кто такие академики? Люди, способные осилить эти самые абстракции? Все программисты этим занимаются каждый день ну уж точно когда приходят на новый проект.
>>1801101
Странно высрать рандомную строчку внутреннего кода и требовать по ней понять то что ты просишь. Тот анон наверное имел в виду что эта конкретная строчка понятна - есть какая-то передача данных, видимо но каналу с началом и концом и какими-то ограничениями. Все это параметризировно по типу эффекта, скорее всего, но сказать сложно без контекста проекта. Еще для меня не ясно что такое тип T - тип данных для передачи или что? Могли бы и попонятнее назвать.
Нужны ли эти абстракции и качственны ли они - другой вопрос.
> рандомную строчку внутреннего кода
Это не внутренний код, это абстракция которую эти пацаны запихнули в библиотеку. Предлагая понять, что это такое, я и намекал что это какой-то частный случай, который они пытаются выдать за нечто общее и абстрактное.
Так что мой пойнт как раз в том что
> Нужны ли эти абстракции и качственны ли они
Дай ссылку на код, по одной строчке сложно понять качество. Может там scaladoc на 50 строчек над этим определением.
>это какой-то частный случай, который они пытаются выдать за нечто общее
Ты же понимаешь что наверное о чем угодно можно сказать "это частный случай чего-то более общего". Монада - частный случай моноида, если что. Ты о "матане" точно в негативном ключе говорил?
>Потом ещё спасибо скажут.
За что? Программист -- это commodity, дешевый расходный материал. Неважно на чем он пишет - на скалке или пыхе.
Главное, что двигает ИТ иднустрию - наличие большого количества дешевой рабочей силы. Если вдруг кодерки станут элитой, то это замедлит прогресс
>третьей версии
Она уже готова на 95%, но из литературы только дока и хуй вместо вменяемой поддержки IDE. Но если сильно интересно, то можешь взять Dotty и ковырять прямо сейчас. Лично я уже около года балуюсь дома.
Но учти что разница между ней и прошлой версией, это как между Perl и Perl 6 - почти другой язык.
Так что учитывая слоупочную специфику эволюции скаламирка, на тройку можно забить ещё на пару лет минимум, если ты не энтузиаст early adopter.
Как лучше всего взаимодействовать с реляционными СУБД из Scala? Slick мертв и "поддерживается" пользователями, которые только новые ишью создают в трекере. Doobie завязан на одного человека, который сейчас вообще ушел в какой-то экспериментальный проект по написанию драйвера для PostgreSQL. Quill? Но это только DSL для написания SQL запросов. Т.е. исполнять их должен какой-нибудь Doobie. JOOQ? Так он вроде для Java/C#, т.е. Scala там даже и не пахнет.
Как люди работают с базами данных из Scala?
doobie норм работает, мы его во всем новом подключаем (но у нас не оч сложные схемы, просто локальный сторидж без джойнов), scalike, да и любая стабильная java-либа с небольшой оберткой подойдет, на самом деле.
>>1805881
можешь пока не переживать за дотти, учи что есть.
топ книги - functional programming от создателя (не обязательно целиком), от него же курсики по fp на курсере, scala for the impatient (чуть устарела вроде), твиттеровские ресурсы какие-то были неплохие.
>functional programming от создателя
Если ты имеешь Functional Programming in Scala, то ее писал не Мартин, а Рунар. Книга так себе, если честно. Начиная с 7 главы повествование идет в очень сумбурном стиле. Есть Functional Programming Simplified от Alvin Alexander - там по сути тоже самое, только написано более простым языком и примеры чуть ли не на пальцах разбираются.
>от него же курсики по fp на курсере
Курсы от Одерски по FP на Scala - это по сути передранный учебник SICP, где примеры кода и задачи переписали на Scala сo Scheme. Курс очень посредственный, если что.
>scala for the impatient (чуть устарела вроде)
Довольно таки бодрая книжка. Сложно сказать, что-нибудь плохое про нее.
>doobie норм работает
Меня пугает то, что его разрабатывает один челик. Над сликом пахало целая команда, которая сидела на зарплате у Lightbend, но его это не спасло.
>да и любая стабильная java-либа с небольшой оберткой подойдет, на самом деле.
На сколько это Scala-way? Если писать обертки поверх джавовых библиотек, то можно ведь и головой двинуться. Одно дело, если ты используешь какую-нибудь Akka, из которой футуры торчат, а если ты на котах или зио пилишь бекенд?
>книгу Одерски
Ну, это же типичный справочник по языку. Читать его скучно и там не разбираются ни типичные архитектурные приемы ни паттерны при работе на Scala. Красная книгу рекомендуется читать как введение для котов. Хотя я не уверен, что описанные там практики помогут тебе при работе с той же Akka, например.
https://github.com/slick/slick/issues/2126#issuecomment-674701468
>Slick is currently being maintained by its users who fix bugs and develop features that they need or want. As such, we don't have a roadmap or plans.
За крупными опенсорс продуктами обычно стоят крупные конторы на вроде VMware, JP Morgan, Apple, Twitter, Google и другие. И ключевые мейнтейнеры таких проектов либо работают в таких компаниях, либо наняты в виде внештатных работников. В любом случае - это люди на зарплате, которые пашут стандартную 5-дневку, где пилят "опенсорс проект, которые разрабатывается коммьюнити".
> Хотя я не уверен, что описанные там практики помогут тебе при работе с той же Akka, например.
Всё верно, чтобы узнать акку, нужно работать с аккой, чтобы освоить коты - использовать котов как можно чаще.
На моей практике вообще красную книгу стоит читать после некоторого опыта использования котов в реальном коде, а не наоборот.
> Ну, это же типичный справочник по языку. Читать его скучно и там не разбираются ни типичные архитектурные приемы ни паттерны при работе на Scala.
Мб, что бы сам посоветовал?
>Главное, что двигает ИТ иднустрию - наличие большого количества дешевой рабочей силы.
Только если называть движением повышение скорости высирания стартапного забагованного говнища, про 95% которого никто никогда не узнает, кроме заказчика и команды разработки. А те 5% что взлетят - или рухнут позже под тяжестью говнокода, либо не рухнут, но говном от этого быть не перестанут.
opinionated нытьё ↓ как будто остальной пост не opinionated нытьё, хех
Насмотревшись 10 лет назад на успехи популярных соц.сетей, людишки уверовали в мантру "пока в Вилариба выдрачивают код, в Вилабаджа уже зарелизились и фиксят баги". В целом логика правильная: во всех соц.ориентированных продуктах качество даже не на третьем месте, а главное - это захватить ресурс (людишек) и отхватить как можно больше. В итоге, если не получилось - отбиваемся минимальными затратами, а если получилось - конкуренты могут выпускать хоть в десять раз более качественный аналог, он нахуй никому не будет нужен, потому что в соц.продуктах - главное не сам продукт, а пользователи, вернее их количество. Фейсбук по сей день остаётся убогим говном, пользоваться которым невозможно без рвотных позывов, но все там сидят, потому что там все сидят. То есть даже при коммерческом успехе продукты остаются дырявым и забагованным, поэтому лаги, ошибки, слив юзер данных и прочий абьюз багов - вещь повсеместная, независимо от крупности компании. А выпуск новой версии в которой всё будет сделано правильно произойдёт в том дне, который не наступит никогда, а в том что наступит выпустят скорее свистоперделки для подогрева интереса юзеров, такие же забагованные и прикрученные сбоку на костылях.
Так как подавляющее большинство новых продуктов - тоже социальные, то вся эта история повторяется вновь и вновь, и самое печально, что оно задаёт тенденцию и влияет на другие области, например, на продукты ориентированным на бизнес, где вся эта спешка в общем-то ни к чему
Интересы буржуйчика и качество софта - вещи ортогональные, иногда они совпадают, чаще - нет. Но вот интересы людей в целом - иметь качественный софт.
Я не против, чтоб всякий MVP хлам на выброс клепала индусня на питоне и гоу, но разработкой полезного прикладного софта для людей должны заниматься как минимум умные люди, которых ныне в IT сфере страшный дефицит.
>про 95% которого никто никогда не узнает
Достаточно посмотреть где используется всеми ненавистный Spring и какие проекты на нем реализуют, чтобы понять, что не обязательно дрочить анус котами и плакать кровавыми слезами из-за того, что ИДЕЯ код краснит, чтобы выдавать продукт, который будет приносить радость пользователям, а тебе - деньги.
Да, читал её, отличная. По-моему оттуда же книжка про Cats стоит прочтения.
>>1809232
> дрочить анус котами и плакать кровавыми слезами из-за того, что ИДЕЯ код краснит
Коты это прекрасно, а идея уже давно почти не краснит код, во всяком случае проблем уже давно не было, хз о чем ты. Самое уродское, что есть в scala-мирке - sbt, вот там я плачу частенько от того, как он зависимости проебывает, остальное кайфец а может я просто привык годами жрать говно и мне комфортно
> какие проекты на нем реализуют
какие?
>идея уже давно почти не краснит код
Возможно ты не пишешь ничего сложнее хеллоуворлдов на пару строк, поэтому и не видишь всего того пиздеца который происходит при работе над крупным проектом.
Идея может краснить корректный код или не подсвечивать некорректный. Может валить эксепшенами и жрать память гигабайтами. Я все время порываюсь перейти на VS Code + Bloop, но меня быстро отрезвляет тот факт, что VS Code обычный текстовый редактор, а Bloop - не более чем очередная поделка Scala Center, где студенты Одерского осваивают гранты.
>Самое уродское, что есть в scala-мирке - sbt
К сожалению, ничего не изменится в ближайшее время. Всех все устраивает и все считают, что sbt - это путь Scala.
Очень жаль, что при разработке sbt, разработчики не ознакомились с такими проектами как Maven или Gradle, где банальные вещи делаются интуитивно и буквально за минуту, когда как sbt с самого начала начинает тебя грузить какой-то эзотерической хуетой и рассказывать как здорово, что у тебя теперь есть еще один DSL на Scala на котором ты можешь описывать свои билды.
Пожалуй это самая тормозная, забагованная и неинтуитивная система сборки, которая, ко всему прочему, еще имеет отвратительную интеграцию с IDEA.
>какие?
Любые крупные проекты, начиная от банковских систем, заканчивая какими-нибудь соц. проектами или крупными площадками на вроде Яндекс.Маркета. Тот же Netflix очень плотно сидит на Spring Boot и все микросервисы стартует именно на этой платформе.
Та же Scala у них там сбоку и вообще про Big Data.
Какой-нибудь Twitter мы не берем в расчет. Там изначально собралась отбитая компашка, которая изначально все писала на Ruby, а когда начало все тормозить, то они кинулись на Scala, т.к. синтаксис был похож. Ну и да - Twitter за все время своего существования показал прибыль лишь однажды, когда провел массовое увольнение разработчиков. А так это просто очередной убыточный проект, который проедает очередной раунд инвестиций. Но да, там есть собственная виртуальная машина, наработки на Scala (правда без котов и прочего тайплевл стека).
> Возможно ты не пишешь ничего сложнее хеллоуворлдов на пару строк
Пилю скалку в известном банке, тут немного не пара строк, но всё равно "пиздеца" прямо не ощущаю, как и ранее писал. Мб дело в настройках и мощностях, мб у всех разный порог пиздеца. Пользуюсь обычной комьюнити идеей на средней мощности воркстейшене на линуксе.
> Пожалуй это самая тормозная, забагованная и неинтуитивная система сборки, которая, ко всему прочему, еще имеет отвратительную интеграцию с IDEA.
Всё так.
Яндекс, кстати, регулярно пишет-зовет на небигдатную скалу, видимо не только спринг у них.
>Твердо решил перекатитьcя с пхп
Женя? Это ты в скаладжобс поливаешь говном пхп и хочешь перейти в скалу? Ты же понимаешь, что платят не за знание языка, а за экспертизу в предметной области и опыт разработки высоконагруженных проектов.
Учти, что те графики с зарплатами, где скала лидирует - это не более чем махинация со статистикой, т.к. в скале нет джюнов, а только сеньоры и принципалы.
Нет понятия "платят". Есть понятие вакансия. И в вакансиях пхп платят мало, полоток 300 тыщ, а в вакансиях скалы платят много, потолок 670 тыщ.
Это если говорить про удаленку из России
А вот тот факт, что в скале нет джун вакансий и невозможно вкатиться без 3+ лет опыта, конечно может меня остановить.
>Меня пугает то, что его разрабатывает один челик
Отчасти это проблема, но он достаточно много кем используется, входит в тайплевел стек, да и сам можешь подхачить что-то, не программист чтоле?
>Над сликом пахало целая команда, которая сидела на зарплате у Lightbend, но его это не спасло.
Не то чтобы его прям спасать нужно, он работает себе, пусть и не развивается активно. Просто появились альтернативы лучше, в том числе потому что его задумка оказалась не самой удачной как а смысле использования, так и в разработке.
>>1807431
>На сколько это Scala-way?
Вопрос не в этом, а в том насколько это нужно.
>>1806953
>Quill? Но это только DSL для написания SQL запросов.
Все из коробки работает, хотя можно и с Doobie подружить. Рекомендую, очень хороший проект, я его еще и с кассандрой и даже спарком использовал. Хотя возможно для новичков scalikejdbc понятнее будет, он простой (если все строго по примерам из доки делать и не стараться вникать как там этот DSL реализован) и на jooq похож. Обе либы, кстати, поддерживают асинхронную работу с постгресом, но я не знаю в каком состоянии эта функциональность, возможно альфа и это никогда изменится.
>>1808569
https://www.handsonscala.com
Сам не читал, но слышал положительные отзывы именно о том что тут разобраны реальные примеры. С другой стороны, автор использует свои библиотеки в книге. Это само по себе не плохо - они простые и позволяют сфокусироваться на языке и задачах, но если (скорее всего) в проде будут другие, придется их доучивать.
>входит в тайплевел стек
Туда много что входит, включая какие-то поделки от рандомных челиков.
>сам можешь подхачить что-то, не программист чтоле?
Зачем мне что-то "хачить" в библиотеках? За многие годы работы джава программистом мне не приходилось копаться в сорсах библиотек и что-то там править, т.к. все библиотеки и фреймворки поддерживались крупными конторами, где толпа разрабов на зарплате выкатывала релиз за релизом каждые несколько месяцев.
>он работает себе, пусть и не развивается активно
Посмотри когда вышел последний релиз и что в него включили. Заодно можешь посмотреть количество багов, которые весят в ишьюсах.
>https://www.handsonscala.com
>Сам не читал, но слышал положительные отзывы именно о том что тут разобраны реальные примеры.
Слышал ты из-за того, что этот хитрый китаец бегает по всем площадкам, где тусуются скала программисты и пиарит свою книжонку. Сама книга довольно посредственная и во многом опирается на поделки этого китайца, который изобретает очередной велосипед, которым пользуются полтора анонимуса.
Откуда столько ненависти к Lightbend стеку? В основном это исходит из ру-сегмента скала коммьюнити. Большинство называет Akka, Play, Slick - легаси и рассказывает охуительные истории про то как "все компании" переходят на typelevel и горя не знают.
>Туда много что входит, включая какие-то поделки от рандомных челиков.
Там есть разделение на включенные проекты и incubator projects, doobie именно включен.
>Зачем мне что-то "хачить" в библиотеках?
Чтобы добавить то, чего в ней нет, очевидно же, а не ждать пока разработчики соизволят уделить внимание твоей проблеме.
>За многие годы работы джава программистом мне не приходилось
>что-то там править
Везет, мне и на джаве, и на С# приходилось. Судя по, например https://github.com/hibernate/hibernate-orm/graphs/contributors, сюда тоже контрибьютят люди не на зарплате.
>копаться в сорсах библиотек
А вот это вообще странно, очень часто по документации невозможно понять как точно работатет та или иная фича. Ну может тебе не нужно было.
>Заодно можешь посмотреть количество багов, которые весят в ишьюсах.
50 багов. Это много или нет? Не знаю. По моему опыту 3-4 летней давности еще 2-ой слик был вполне работоспособным, но не слишком удобным в использовании.
Можешь, кстати, посмотреть на баги в Hibernate - там их сотни.
> Сама книга довольно посредственная
Ну вот теперь у меня еще один отзыв есть, негативный. Хотя я бы все равно советовал дать книге шанс - китаец хорошо пишет как минимум блог-посты.
Подоспела качественная аналитики от инженера, который не может найти работу на Скале - https://habr.com/ru/post/520114/
>Scala мертва
>получил 4-5 офферов на Scala в нескольких Европейских странах
Как-то не очень вяжется.
>Подоспела качественная аналитики от инженера
>Раунд 1: Go vs Java
>Безоговорочно Go.
>мой опыт с ним составляет всего пару месяцев
На этом думаю стоит закончить, и не тратить время на очередную аналитику про микросервисы - ебанутые совершенно не понимают сколько проблем создает перенос вызова из памяти в сеть.
Гоу сочетает в себе простоту освоения (неделя-две) и удобство программирования. На Scala, пока не осилишь красную книгу и не прорешаешь все задачи без подглядывания в решение - можно даже и не начинать проект, т.к. все равно обосрешься без понимания комбинаторов, монад и типов высших порядков.
Гоу не так уж и легко освоить на уровне написания идиоматичного кода, особенно если до этого не работал с CSP-based системами и не привык к structural typing и это еще go2 не вышел, а удобно на нем программировать только тривиальные сетевые сервисы, которые легко создавать на любом достаточно распространенном языке вплоть до Хаскеля. Его преимущества в другом, а именно в рантайме, заточенном под определенные типы задач и унифицированном тулчейне.
>на очередную аналитику про микросервисы - ебанутые совершенно не понимают сколько проблем создает перенос вызова из памяти в сеть.
Ты совершенно напрасно драматизируешь. Микросервисы и serverless - это будущее разработки масштабируемых приложений. Проблема Скалы заключается в том, что за ней не стоит никакой крупной технологической компании, которая бы выпускала библиотеки/фреймворки, которые бы, в свою очередь, радикальным образом упрощали жизнь типичному разработчику.
Какое-то время люди были в восторге от Akka и Play Framework, но вскоре основательно поели говна с акторами (которые слишком поздно сделали типизированными и это так и не решило никаких основных проблем, а только добавило новых, в основном с деплоем новых версий сервисов в кластере). С Плеем так вообще смешно вышло - сейчас бы в 2к20 писать на толстом веб-фреймворке вместо того, чтобы отдельно выкатить фронт, который бы отдавался инжинксом и отдельно рест-бек на чем-нибудь легковесном.
В итоге, получили ситуацию, когда весь LIghtbend стек в скала-коммьюнити считается легаси и не рекомендован для новых проектов.
Остается typelevel стек. Но проблема тайплевела в том, что это не технологическая компания как редхат или оракл, а просто конгломерат из приходящих челиков, которые проталкивают свои мутные велосипеды в инкубатор и консалтеров, которые напилили всяких котов, сёрсе и прочих дубей и теперь пытаются выехать на поддержке и внедрении.
Это не идет ни в какое сравнение с тем же Spring за которым стоит VMware или Helidon за которым стоит Oracle или взять тот же Quarkus, который пилится с подачи Красношапки.
Т.е. не стоит сравнивать жалкие потуги скалистов, которые нажравшись дерьма на Akka, побежали пердолить микросервисы на котах и гонять месседжи через кафку, попутно объясняя менеджменту, что такое моноиды и как залифтить монаду себе в очко и почему это важно для проекта.
>Его преимущества в другом, а именно в рантайме
Да похуй на твой гоу рантайм, старина. Там до недавнего времени GC врубался по таймауту. Преимущество гоу в том, что можно взять условную похапэ-макаку и она через неделю будет выдавать код, который можно будет лить на бой. Код при этом получается однообразный и в нем нет никаких сюрпризов, когда нужно себе анус рвать, чтобы понять, как он работает.
За интересным рантаймом это тебе в Erlang/Elixir и виртуальную машину BEAM или взять тот же OCaml.
Я уже хотел было написать развернутый ответ про микросервисы и фреймворки, но после этого
>попутно объясняя менеджменту, что такое моноиды и как залифтить монаду
передумал, слишком толсто. Менеджменту похуй на монады и технологии.
Для мимокрокодилов могу только сказать что
> весь LIghtbend стек в скала-коммьюнити считается легаси и не рекомендован для новых проектов.
только на дваче и можно услышать, большинство проектов как стартуют, так и остаются на нем. Хорошо это или плохо - другой вопрос.
>>1813263
Конечно есть рантаймы намного интереснее, да у той же JVM есть перимущества перед ним. Но для простых сетевых лоу-латенси сервисов он очень хорошо работает из коробки, как и CSP и то как он обрабатывает блокирующие вызовы. Ключевое слово здесь из коробки, его не нужно тюнить.
>OCaml
Интересно, а что в нем особенного?
>преимущество гоу в том, что можно взять условную похапэ-макаку
Это миф, на уровне "хороший программист осилит любой язык за неделю, они все одинаковые". Языки разные, и научиться писать идиоматичный код за неделю не выйдет. Кроме того, не похоже чтобы на Go писали макаки, судя по тому сколько за него платят.
>когда нужно себе анус рвать, чтобы понять, как он работает.
Что интересно, самый запутанный код который я видел в жизни бы написан на С# в абсолютно процедурной парадигме - только циклы, рекурсивные вызовы и изменения переменных. Ничего такого же сложного в скале со всеми ее фичами я никогда не видел, так что думаю что сложность, привносимая самим по себе языком очень преувеличена (кроме С++, но это отдельная история).
>Менеджменту похуй на монады и технологии.
Нет, не похуй. Менеджмент понимает, что если начать проект на непопулярной технологии, то это может загубить весь проект. Так случилось с Моим Складом. Пока его писали борщехлебы на Scala, то дела у компании шли так себе - новых сотрудников было тяжело нанять и они стоили каких-то безумных денег, продукт был забагован и вхождение в проект было тяжелым испытанием для новых программистов. Но вод пришел Козуля и переписал проект на Java и теперь разработчики находятся на раз-два, проект очистился от FP-дерьма и теперь все будет ништяк.
>большинство проектов как стартуют, так и остаются на нем. Хорошо это или плохо - другой вопрос.
Ну вот M2 стартанул на лайтбенде (акка), а потом раз, и теперь они ищут людей только на typelevel стек со знанием кафки. Тут уже вкидывали видео, где еще одна компания в ужасе съебала с акторов на тайплевел и кафку и горя не знает.
Сложность поиска людей конечно имеет значение, я скорее про технологии внутри одного языка говорил. Обьяснить разницу между lightbend- и typelevel-стеком менеджменту сложно, для них это сорта одного говна. Но lightbend продвинуть легче, если станет вопрос - мне вот недавно нужно было стек для нового проекта выбирать, я подумал-подумал над http4s + doobie, и решил что продвинуть akka-http + quill проще будет. Основные конкуренты были (и еще есть наверное) finagle и go, кстати.
> вот M2 стартанул
Понятно что кто-то переходит, но это единицы. Я достаточно часто на собеседованиях бывал (хотя последний год не хожу), чтобы иметь достаточно большую выборку.
>компания в ужасе съебала с акторов на тайплевел
С акторов кто угодно съебет в ужасе, а вот akka-streams вполне себе прилично работают и имеют огромное количество коннекторов. Я не то чтобы гоню на typelevel, просто он не и близко не занимает той доли проектов, что lightbend.
>ищут людей только на typelevel стек
>со знанием кафки
Если они действительно ищут людей со знанием этих обеих технологий, то удачи, хех. Что в той, что в той очень мало кто разбирается, а пересечение вообще почти пустое множество.
Ага, помню обратную ситуацию в Приватбанке, когда в одном из отделов страшно обосрались со своей джявой, в этот день уволили нахуй СТО вместе с половиной джавадебилов, остальным был предложено изучить Erlang в кратчайшие сроки (к счастью простота языка позволяет) или съебать тоже. Дальше разработка в том отделе велась исключительно на Erlang правда с ним тоже в конечном итоге поели говна, очевидно надо было брать Haskell или на крайний случай Scala
>Я не то чтобы гоню на typelevel, просто он не и близко не занимает той доли проектов, что lightbend.
Ру-сегмент Scala с тобой в корне не согласен. В их понимании Lightbend стек - это легаси и все адекватные компании сразу стартуют новые проекты на тайплевеле. Схожая риторика проскакивает и в зарубежном коммьюнити, где ту же Akka поливают говном и рассказывают как сладко живется на typelevel + Kafka.
>Если они действительно ищут людей со знанием этих обеих технологий
Сейчас как-бы 2к20 и от рядового бекендера требуют опыт работы с Kafka практически в обязательном порядке.
Никто не хочет пердолиться в кластеры или херачить микросервисы через какой-нибудь gRPC - все гоняют месседжы через кафку.
Ну так это известная история. Там же Максимка опердени на своем ёрланге ебал. По итогу все вылилось в то, что его возвышенный код никто не понял из команды и все пошло по пизде. Учитывая то, что они и с джавой говна поели, то можно сделать вывод, что уровень разработчиков там было довольно низкий.
>Ру-сегмент Scala с тобой в корне не согласен
Не очень знаком с ру-сегментом, даже скалалаз давно не слушал. Есть что почитать на эту тему?
>где ту же Akka поливают говном
То что в интернете все что угодно говном поливают - не новость. Не нужно из этого делать далеко идущие выводы.
>опыт работы с Kafka практически в обязательном порядке
Не толсти, кафка редко где нужна.
>>1813922 >>1813622
>если обосрались с джавой, то там уже проблемы на уровне хромосом CTO.
>с джавой говна поели, то можно сделать вывод, что уровень разработчиков там было довольно низкий.
Джава это залог успеха чтоле? Пишешь на ней и задачи сами собой решаются? Открою секрет, люди часто используют не мейнстримные языки именно из-за того что им надоело жрать на них говно.
>Открою секрет, люди часто используют не мейнстримные языки именно из-за того что им надоело жрать на них говно
ЭТО ПРЕКРАСНО, НО НАМ НУЖНО РЕАЛИЗОВАТЬ ЕРП СИСТЕМУ СУТЬ ТАКОВА ЕСТЬ БУХГАЛТЕРСКИЕ ПРОВОДКИ И ЕСЛИ ПОЛЬЗОВАТЕЛЬ ИГРАЕТ ЗА МЕНЕДЖЕРА, ТО БАЛАНСОВЫЕ СЧЕТА В ЛЕСУ СКЛАДЫ НАБИГАЮТ КОРОЧЕ ВОЗМОЖНОСТИ КАК В 1С
>Есть что почитать на эту тему?
Достаточно открыть @scala_ru где общаются тимлиды и разработчики топовых компаний в СНГ и РФ.
>Не толсти, кафка редко где нужна.
Если мы отбросим Big Data на Scala и посмотрим на чистые бекенд позиции, то увидим, что там либо Akka, либо тайплевел с Kafka. Люди пишут микросервисы на тайплевел стеке, а для общения между этими микросервисами используется Kafka.
Есть истории, когда люди сидели на кластере из Akka, а затем переходили на связку typelevel + Kafka.
Кафка обеспечивает надежную доставку сообщений между сервисами.
В Java разработке она тоже повсеместно используется - пилятся сервисы на Spring Boot, а затем они связываются через Kafka.
>Джава это залог успеха чтоле?
Если грубо, то - да. Java это считай 50% успеха проекта. Это не только простой в освоении язык на котором может писать любая макака, но и десятки фреймворков за которыми стоят крупные компании и сотни библиотек на все случаи жизни. Большинство проектов основаны на Spring Framework, т.к. он позволяет тебе собрать каркас приложения за считанные минуты и начать накидывать бизнес-логику предоставляя различную функциональность через всевозможные модули. Ничего подобного в экосистеме Scala даже близко нет.
Я не говорю про простоту найма джава-разработчика, которых на рынке труда только в РФ - десятки тысяч. Это со Scala ты вынужден брать кого попало и учить на месте. С Java ты можешь выбирать лучших, т.к. пул разработчиков невероятно огромен.
Готовые инструменты это замечательно, но помимо чисто технических аспектов есть еще и сложность доменной области. И проекты часто фейлятся из-за того что команда именно с ней не справляется, а не из-за того что в базу что-то записать не получилось или билиотеки не хватает. И вот хороший язык как раз позволяет писать логику понятно. Еще конечно случаются обсеры с архитектурой, например если пытаются в CQRS не подумав, или в 100 микросервисов, или, упаси Господи, какому-то долбоебу придет в голову связывать сервисы через Kafka. В общем такого чтобы обосрались просто из-за выбора языка я еще не встречал.
>>1814157
Ну так может 1С взять и все?
>>1814184
>@scala_ru
Зайду почитаю, чтоле.
>то увидим, что там либо Akka, либо тайплевел с Kafka
Да полно всего есть, Кафка далеко не везде. Ну и Акку с Кафкой часто видел, да и сам использовал.
>Кафка обеспечивает надежную доставку сообщений между сервисами.
Ты точно понимаешь что такое Кафка и что она отличается от очередей сообщений?
>Если грубо, то - да.
Все эти мифы про
> каркас приложения за считанные минуты
> и десятки фреймворков за которыми стоят крупные компании
уже в прошлом треде разобрали, не интересно уже.
>В общем такого чтобы обосрались просто из-за выбора языка я еще не встречал.
Целую команду скалистов из озона на хуй выгнали и все переписали на Пщ.
>Ты точно понимаешь что такое Кафка и что она отличается от очередей сообщений?
Есть паблики, на которые подписываются клиенты. Ты туда складываешь сообщения и они доходят до получателя.
>Господи, какому-то долбоебу придет в голову связывать сервисы через Kafka.
Вот тебе история успеха, как команда свалила с Akka и переписала все на микросервисы + Kafka - https://youtu.be/_sIOwQdQPIQ?t=525
>Целую команду скалистов из озона на хуй выгнали и все переписали на Пщ.
С чего ты взял что это связано именно языком? Истории миграции вообще интересные, можно почитать об этом кейсе?
>Есть паблики, на которые подписываются клиенты. Ты туда складываешь сообщения и они доходят до получателя.
Так обще можно о чем угодно сказать. Есть таблица в постгресе, кто-то туда кладет данные, а кто-то читает. Почти Кфака. У Кафки есть особенности, которые делают ее не слишком пригодной именно для использования как очереди сообщений, но очень классным распределенным логом событий.
>Вот тебе история успеха
Видел, как по мне это говорит только о том что ZIO вероятно пригодно к продакшену, а сырые акторы - неудобны, что впрочем достаточно известно. Если они организовали коммуникацию (именно коммуникацию, запросы-ответы, а не просто поток событий) между сервисами через кафку, ну что ж, земля пухом. Для этого должны быть какие-то очень серьёзные причины, которые я бы хотел узнать, будет очень интересно.
Работаю в около биг дате.
Жидко обосрались с кафкой между компонентами и всё переделывали на http сервисы. Так как нужно было часто гонять большие сообщения между сервисами, а потеря одного сообщения ломала всё. При этом нам ещё надо было ответ отдать клиенту. Слишком поздно мы поняли что кафка не подходит для запрос-ответ систем.
Тот кто её привнес в проект конечно ушёл задолго до вскрытия проблем.
Теперь вижу кафку только как уведомлялку между интеграциями, для чего-то более серьёзного нужно писать овердохуя кода
>С чего ты взял что это связано именно языком?
>Команда борщехлебов рвала себе анус и безуспешно пыталась в этерпрайз, подсев на уши менеджеру, что "вот-вот и Scala всем покажет, ух покажет!".
>Менеджер видит, что работа стоит, выделенный бюджет тает на глазах, а все что он имеет - это команду великовозрастных ебланов, которые свои монадки додрочить не могут, чтобы наконец-то запустить пилот
>Вся команда борщехлебов идет на хуй и заместо нее нанимаются гоферы, которые в кратчайшие сроки запускают проект
Да, действительно, что же тут не так с языком, хмммм?!
>обосрались с кафкой между компонентами
>переделывали на http сервисы
>нужно было часто гонять большие сообщения между сервисами
>потеря одного сообщения ломала всё
Ты же в курсе, что в случае, если твой сервис, посылающий HTTP запрос умрет или пропадет соединение между двумя сервисами и твой запрос отвалится по таймауту, то ты его потеряешь навсегда?
Кафка же тебе позволяет гарантированно доставить сообщение в кластер, сохранить его на диск и так же надежно доставить до получателя. Сравнивать HTTP запросы и Kafka - как минимум странно.
Это твои фантазии или где-то можно получить более достоверную информацию об этом кейсе, чем от анонимуса с двача?
Суть в том что я не один проект сделал на Скале, и знаю еще больше успешных проектов как у знакомых, так и во всемирно известных компаниях. Так что я точно знаю что на скале можно писать очень быстро и качественно, хотя и допускаю что она может быть не оптимальным инструментом и некоторых ситуациях. И вот о таких случаях хорошо знать, чтобы не наступать на те же грабли.
>>1814763
Ты же в курсе, что в случае, если твой сервис, посылающий сообщение в Кафку умрет или пропадет соединение между сервисом и брокером и твой запрос отвалится по таймауту, то ты сообщение потеряешь навсегда?
>Кафка же тебе позволяет гарантированно доставить
Because Kafka is webscale.
>Сравнивать HTTP запросы и Kafka - как минимум странно.
Сравниваются способы организации коммуникации между сервисами. И Кафка - не самое подходящее решение. Казалось бы, почему не взять нормальную очередь сообщений, если обычные запросы не подходят?
>>1814894
Вот действительно сириус пацаны - https://habr.com/en/company/lsfusion/. Целый ЯП вместо 1С придумали.
>Вот действительно сириус пацаны - https://habr.com/en/company/lsfusion/. Целый ЯП вместо 1С придумали.
Пиздец, одна история охуительнее другой:
https://habr.com/ru/company/lsfusion/blog/463095/
Думал, пиарить свою начальную стадию данинга-крюгера на хабре это совсем зашквар, но нет - пацаны шмагли.
>нормальную очередь сообщений
А ничего другого нормального и нет. RabbitMQ - это говно-говна, которое не умеет в кластеризацию (разваливается при split-brain) и херит данные, которые хранит в мнезии.
>можно получить более достоверную информацию об этом кейсе
Конкретно эта история затерялась за задворках scala_ru и scalaponv
Вот тебе еще история ребят, которые перешли со Scala на Пщ и горя не знают -
http://jimplush.com/talk/2015/12/19/moving-a-team-from-scala-to-golang/
>Ты же в курсе, что в случае, если твой сервис, посылающий сообщение в Кафку умрет или пропадет соединение между сервисом и брокером
Ну, не передергивай, старина. Одно дело, когда у тебя есть кластер из коммит логов и другое дело, когда ты шлешь запрос и ждешь на него ответ. В одном случае ты кладешь мессендж в кафку и идешь дальше заниматься своими делами, а в случае хтпп запроса - ты отправляешь его, ждешь ответ, а потом идешь что-нибудь делать. В случае асинхронных запросов ты все равно жрешь ресурсы.
> RabbitMQ - это говно-говна
> split-brain
Начинается, анонимус на двачах обсирает одну из самых проверенных в продакшене технологий. Во-первых, это может быть, а может не быть проблемой. Во-вторых, насколько я помню, стратегию обработки сплит-брейна можно конфигурировать. В-третьих, ты знаешь как Кафка сплит-брейн обрабытывает, или в чатике в котором ты вычитал про проблемы рэббита об этом не писали?
>А ничего другого нормального и нет.
Как минимум есть старый добрый ActiveMQ, NATS, SQS если на амазоне, если уж хочется велосипеды покрутить, можно что-то свое на ZeroMQ придумать, проще чем на кафке получится.
>Конкретно эта история затерялась за задворках scala_ru и scalaponv
Ну так и говори - я читал в каком-то чатике, что .... Не очень убедительно и полезно.
>Вот тебе еще история ребят, которые перешли со Scala на Пщ
Читал, у них там больше со scalaz проблема была и разными стилями. Ну и это 2015 год, эти уроки уже давно выучены.
>В одном случае ты кладешь мессендж в кафку и идешь дальше заниматься своими делами
И посылка в кафку может точно так же зафейлится, как и HTTP запрос.
>а в случае хтпп запроса - ты отправляешь его, ждешь ответ
В первом случае ты тоже должен ждать ответ, только он придет в виде сообщения в другом топике. После этого ты должен как-то сматчить запрос с ответом. Это можно реализовать, но достаточно сложно - не лучше ли позволить HTTP это сделать за тебя?
>В случае асинхронных запросов ты все равно жрешь ресурсы.
Соединение или что? С Кафкой ты его не держишь?
Это "говно говна" используют примерно все, лол. Просто как и у любой технологии у него есть свои ограничения. Конкретно раббиту, вроде бы, становится плохо при 300к сообщений в секунду (что-то такое я слышал от очень крупных ребят, которые имели его в продакшене), но при этом если у тебя есть такие нагрузки - ты или уже имеешь деньги на целый штат инженеров, чтобы тюнить его или переписать всё на гораздо более мудрёную кафку, или ты что-то сделал очень плохо и дидосишь сам себя.
А построение кластера и борьба со сплит-брейном - это сложная штука вообще всегда.
И да, раббит идеально подходит для простых проектов, потому что он прост в освоении и с ним легко работать. Кафка же сложная, как самолёт, с миллионом ручек, настроек и всякими зукиперами под капотом.
Это правда? Она умирает или есть какие-то перспективы? (я слышал, хадуп написан на предыдущей мажорной версии скалы и, поскольку переписывать такую сложную хрень себе дороже, а хадуп - основной поставщик вакансий для скалистов, то новую скалу будет использовать заметно меньше народу)
Какие вообще подводные для вката?
Давай так - кролик разваливается при сплит-брейне и там нет никакой автоматики, которая бы собрала кластер обратно и отрезолвила сообщения между половинками. Все это нужно делать руками, включая перезапуск самого кролика. Поэтому люди уходят на кафку, т.к. там эти проблемы решены на уровне архитектуры.
Но если область твоих проектов - это какие-нибудь сельские интернет-магазины, которые хостятся на VPS за 300 рублей в месяц и их посещают полтора сельчанина, то да - кролик лучший выбор в качестве MQ.
Хадуп написан на Java. Apache Spark написан на Scala. Да, все верно говорят. 3/4 всех вакансий - это т.н. data science/big data/data engineer job, где Scala нужна на уровне DSL к Apache Spark. Остальные 1/4 всех вакансий это какие-нибудь мутные стартапы, которые пытаются в FP на котах, либо какие-нибудь залетные микрочелики, которые пытаются писать энтерпрайз на Akka, когда есть Spring.
Основные подводные заключаются в том, что без опыта в Java, ты вряд ли попадешь на позицию Scala разработчика, либо будешь сосать бибу первые 3-5 лет, пока выйдешь на адекватный уровень компенсации.
Большинство вакансий в РФ - это либо желтые банки (где царит своя, собственная атмосфера из тру ФП и наколенных поделок), либо компании поменьше, где эта Scala используется сбоку в маленьких командах (big data/akka).
Если хочется чего-то нового и не хочется побираться и нищенствовать, то попробуй Go - платят больше чем на Scala, куча вакансий, полно библиотек и фреймворков, отличная поддержка IDE и прочего тулинга, включая билд системы.
При этом учится он за месяц максимум. Дальше люди выдают боевой код.
>>1815168
>Это "говно говна" используют примерно все, лол. Просто как и у любой технологии у него есть свои ограничения. Конкретно раббиту, вроде бы, становится плохо при 300к сообщений в секунду (что-то такое я слышал от очень крупных ребят, которые имели его в продакшене), но при этом если у тебя есть такие нагрузки - ты или уже имеешь деньги на целый штат инженеров, чтобы тюнить его или переписать всё на гораздо более мудрёную кафку, или ты что-то сделал очень плохо и дидосишь сам себя.
Если много денег то берут вот такую хуету и забрасывают все эти ваши игрушки в долгий ящик:
https://www.ibm.com/support/knowledgecenter/SSMKHH/mapfiles/product_welcome.html
Так, понятно... Давай тогда тезисно:
- Scala используется преимущественно в big data (Apache Spark)
- За 11 лет существования так и не появилось нормальной поддержки со стороны IDE
- Билд тулы находятся в заднице по сравнению с Gradle/Maven
- Нет никаких киллер фич со стороны языка, которые бы сделали работу рядового разработчика проще и приятнее
- Нет никакой альтернативы библиотекам/фреймворкам из Java (Spring/Hibernate/Quarkus/etc). Все либо сырое, либо нужно пердолить очередную обертку самостоятельно
- Scala 3 окончательно добьет Scala, т.к. это по сути новый язык, а значит, что поддержка IDE откатывается на годы назад, библиотек нет, программистов нет, а те что есть - идут на хуй и все переписывается на Java/Go.
— Знаете, почему у LinkedIn много лет такой тормозной, глючный и неудобный сайт? Потому что они надолго увязли в Scala и до сих пор не могут оправиться — https://www.quora.com/Is-LinkedIn-getting-rid-of-Scala/answer/Kevin-Scott
— Twitter отказывается от Scala — https://www.quora.com/Is-Twitter-getting-rid-of-Scala
— https://movio.co/blog/migrate-Scala-to-Go/
— http://jimplush.com/talk/2015/12/19/moving-a-team-from-scala-to-golang/
— http://uberblo.gs/2016/12/golang-is-really-awesome-and-why-it-beats-scala/jvm
>It took some of us six months including some after hours MOOCs, to be able to get relatively comfortable with Scala. In contrast, we picked up ‘Go’ in two weeks. In fact, the first time I got to code some Go was at a Code Retreat about 10 months ago. I was able to code a very basic Mario-like platform game!
Nice, nice!
>— https://movio.co/blog/migrate-Scala-to-Go/
Хуй знает. По мне так стоит посмотреть в сторону Go. Чувак описал буквально боль любого Scala разработчика. Нахуй себе волосы на жопе рвать, когда можно получать удовольствие от разработки?
Go звучит как история успеха.
Го так-то норм, правда, лично мне там как раз недостаёт гарантий. Он в ряде мест слишком уж низкоуровневый и никак не страхует тебя от того, что ты забудешь проверить указатель перед разыменованием или не проверишь ошибку. Но при этом действительно очень простой, буквально "си с утиной типизацией и зелёными потоками".
Ну, смотри. Haskell или какой-нибудь OCaml еще строже и предоставляют больше гарантий, только тулинг там никудышный и библиотек - хуй да нихуя. Пишут на них либо фанатики, либо какие-нибудь научные работники.
А нужен простой и понятный инструмент для решения типичных проблем с которыми сталкивается разработчик.
Какая у гошников интересная работа? Этот недоязычек настолько невыразителен, что его применение в любом сложном домене на монолитном проекте неизбежно приводит к горам невменяемого быдлокода. Поэтому он подходит только для микросервисов, для плоской примитивной хуйни, исходя чисто из ограничений самого языка.
Может ли быть интересно писать сотни примитивной хуйни на 2.5 экшена и склеивать всё это воедино в основном девопс методами? Возможно, если ты студент или свитер.
П.С. вчера звали в калифорнийский е-комерс стартап, где они тоже стартанули на гоу, но потом решили что всё это хуйня, и без нормальной системы типов программировать нельзя и взяли скалу.
Это принимается. С другой стороны, моделирование сложной предметной области на примитивном языке приводит к куче бойлерплейта с огромным пространством для потенциальных багов, особенно если в языке нет почти ничего для повышения сейвовости. В итоге, за счёт тулинга, инфраструктуры, малого порога вхождения, простоты самого языка ты действительно получаешь буст на старте, но при переходе в стадию продукта с поддержкой неизбежно ждёт возмездие, потому что одно дело накидывать goвнокод на стартапе, другое - менеджить крупную кодовую базу, которая прошла через кучу рук.
Scala как бы должна была стать посередине, с одной стороны дав инфраструктуру, с другой дав необходимые выразительные средства самого языка.
Ну и касательно изначального поста на который я ответил, фан от быдллкодинга на ЯП уровня бейсика может получать только вчерашний студент. Опытный разработчик либо вообще не получает никакого удовольствия, а только хочет побыстрее закрыть задачу в жире (типичный джява/пхп сениор), либо получает, но для этого нужен как минимум ЯП позволяющий ясно выражать абстрактные мысли, и go таким ЯП очевидно не является.
Если ты думаешь что кафка как-то резолвит сообщения между половинками, то у меня для тебя плохие новости.
>там эти проблемы решены на уровне архитектуры.
Ну-ка расскажи, как по твоему мнению эта проблема решена в кафке, а мы посмеемся я-то знаю как, лол.
>>1815189
>без опыта в Java будешь сосать бибу первые 3-5 лет
Справедливости ради, переходить на новую платформу и изучать Скалу действительно сложно. Впрочем, если ты с С# или PHP захочешь на Java или Go переехать, тоже будет непросто.
>>1815199
Мы же про очереди сообщений говорили, разве нет? Ну а твоим тезисам (выдумкам):
> - Scala используется преимущественно в big data (Apache Spark)
Нет у меня такой статистики, но возможно.
>- За 11 лет существования так и не появилось нормальной поддержки со стороны IDE
Появилось. Тут спорить бесполезно, каждый может просто проверить.
>- Билд тулы находятся в заднице по сравнению с Gradle/Maven
Ну так используй мавен, в чем дело?
>- Нет никаких киллер фич со стороны языка, которые бы сделали работу рядового разработчика проще и приятнее
Есть, уже разбирали в прошлом треде.
>- Нет никакой альтернативы библиотекам/фреймворкам из Java (Spring/Hibernate/Quarkus/etc). Все либо сырое, либо нужно пердолить очередную обертку самостоятельно
Есть, и лучше. Я использовал обе экосистемы и работал с людьми которые их использовали. Тоже разбирали в прошлом треде.
>- Scala 3 окончательно добьет Scala, т.к. это по сути новый язык, а значит, что поддержка IDE откатывается на годы назад, библиотек нет, программистов нет, а те что есть - идут на хуй и все переписывается на Java/Go.
Я так не думаю: язык не новый, библотеки и идея уже подтягиваются. В любом случае, увидим через год.
>>1815250
> Пишут на них либо фанатики, либо какие-нибудь научные работники.
Либо компиляторы с криптой.
Я бы очень хотел с тобой согласится, на самом деле. Только опыт показывает, что бизнес выигрывает от выкатки даже полусырых фич сейчас больше, чем от идеальных фич после и поэтому скорость найма обезъянок и выкатки говнофич - чуть ли не главное достоинство правильного айти стартапа.
Вот когда станет много денег - тогда можно будет и переписать. Только за такие деньги и с такой пользовательской базой уже все баги будут отловлены руками пользователей и обёрнуты в if'ы руками тех же обезьянок.
И я сейчас говорю даже не про го, а скорее про пехапе и plain js: я уже видел множество компаний, с разваливающимся спагетти-монолитом, которые были успешными финансово и им было вообще наплевать, что там работает. Переписывалось оно только и исключительно в том случае, когда всё ложилось от больших нагрузок и то часто дешевле плашку памяти купить или сервер мощнее, даже если там просто в цикле запросы в базу делаются.
К сожалению, качество не нужно практически никому кроме того, кто непосредственно с кодом работает. Пользователям кстати тоже не нужно, они очень консервативные и ленивые, им вообще не влом страницу обновить или вернуться через полчаса, они начинают отваливаться только если там действительно что-то ужасное.
Далее, можно было бы сказать, что такие языки как скала или хаскель должны помогать в тех областях, где вероятность ошибки критична, типа процессинга банковских транзакций - но я сам работаю в банке и знаю, что эти вещи элементарно пишутся на го и проблем с ними не возникает.
Далее, про го: да, мне хотелось бы больше гарантий и больше выразительности, но в реальности выгода от их использования неочевидна очень многим, потому что нормальные разработчики и так не забывают проверить указатель на nil и всё такое плюс пишут много тестов, на которых отлавливается подавляющее большинство глупых ошибок. Я вот вообще по tdd работаю.
Так что, к сожалению, мы живём не в идеальном мире и выразительность с мощностью и безопасностью нужны очень и очень мало кому. Особенно безопасность, гугл пароли для gmail до 2019 года в открытом виде хранил и всем было насрать, лол.
>Появилось. Тут спорить бесполезно, каждый может просто проверить.
Проверяй - https://youtrack.jetbrains.com/issue/SCL-18207
Остальное даже комментировать не хочу. Ты либо поехавший фанатик, либо на зарплате в JB/желтых банках.
Хороший у вас тут тред. Ладно, скоро рабочий день начинается, пойду писать на Scala в прод за 4 средних зарплаты пхпшника.
Ты и здесь обосрался, долбоеб. BSP - относительно недавняя разработка, как со стороны скалы, так в IDEA, так что баги там ожидаемы.
Для тех кто интересуестя скалой и просто мимокрокодилов: поддержка скалы и в IDEA хуже чем джавы, по вполне понятным причинам - джава приносит больше денег джетбрейнсу и проще как язык для анализа и компиляции. Я сам иногда сталкивался с тем что валидный код подсвечивается как некорректный и наоборот, а также что некоторые рефакторинги работают некорректно. С другой стороны, это и раньше нблаюдалось на коде использующем много магии системы типов (то есть 0.1% от всего кода, а во многих проектах 0%) и со временем ситуация улучшается (в 2013 действительно все было намного хуже). В любом случае, называть поддержку скалы не нормальной - не более чем троллинг, для каждодневной разработки ее хватает с головой.
>Ты либо поехавший фанатик
Да не сказал бы, просто пока Скала - самое удобное что есть на JVM.
>Остальное даже комментировать не хочу.
Слив засчитан. А мы еще даже на серьёзные темы вроде сплит-брейна говорить не начали, это тебе не какашками в ЯП бросаться, тут чтением чатиков не обойдешься.
>>1815445
В общем-то согласен, но вот это
>Только за такие деньги и с такой пользовательской базой уже все баги будут отловлены руками пользователей и обёрнуты в if'ы руками тех же обезьянок.
не вся правда. Проблема в том что софт развивается, и после определенного порога говнокода и количества ифов вносить измнения, не ломая уже сущесвующую функциональность становиться иногда невозможно, но чаще очень трудно, а точнее долго. А вот этого бизнес уже очень не любит.
>Пользователям кстати тоже не нужно, они очень консервативные и ленивые, им вообще не влом страницу обновить или вернуться через полчаса,
Так работает только если ты монополист.
>потому что нормальные разработчики и так не забывают проверить указатель на nil
Это сарказм?
> не вся правда. Проблема в том что софт развивается, и после определенного порога говнокода и количества ифов вносить измнения, не ломая уже сущесвующую функциональность становиться иногда невозможно, но чаще очень трудно, а точнее долго. А вот этого бизнес уже очень не любит.
Как бы да, но потихоньку рефакторится и всё такое. Таким изящным, каким он был бы на той же скале, код на го будет наверное никогда, но поддерживать +- приемлемую структуру и избегать соскальзывания в говномонолит можно очень долго. Это даже не вопрос языка, скорее умения писать достаточно абстрактно и знания, когда нужно немного порефакторить.
> Так работает только если ты монополист.
Неа, даже в нишевых продуктах. Понятно, что если у тебя хуи на главной странице или корзина грузится 30 минут, то никто туда не зайдёт, но таких ошибок обычно не совершают. А менее критичные типа всратой верстки, минутной прогрузки корзины или легких лагов обычно все игнорируют.
> Это сарказм?
Неа. Без шуток, я давно программирую на го и как правило перед использованием всё проверяется. Я согласен, что какой-нибудь maybe даёт больше гарантий и был бы лучше, но правда в том, что за последний год точно я не ловил nil pointer error ни разу (ну может во время тестов что-то падало, такое не запоминается).
>Как бы да, но потихоньку рефакторится и всё такое.
Конечно, рабочий и даже поддерживаемый софт писали на намного более сложных в использовании языках чем джава и гоу. Просто я за то чтобы хоть чуть-чуть двигать индустрию в сторону более оптимальных подходов.
>Неа, даже в нишевых продуктах
В нишах как раз часто и возникают монополии. Но никто не будет ждать минуту пока загрузатся сайт, если рядом есть такой же, загружающийся за секунду.
>я давно программирую на го и как правило перед использованием всё проверяется.
Прямо в каждом методе? Это на уровне стайл-гайда у вас? В джаве/шарпе это не так распространено, и там NPE - наверное самая частая ошибка. В любом случае, такой подход имеет свою цену в плане боилерплейта, а глобально с ним можно очень далеко зайти - можно сказать что раст не нужен, нормальные разработчики не делают free after free и не допускают выхода за границы массивов, статические анализаторы кода не нужны, да и вообще нормальные разработчики не делают багов вне зависимости от языка.
> Конечно, рабочий и даже поддерживаемый софт писали на намного более сложных в использовании языках чем джава и гоу. Просто я за то чтобы хоть чуть-чуть двигать индустрию в сторону более оптимальных подходов.
Я тоже и излишняя примитивность го мне тоже кажется во многом ошибочной. Не во всём (в их подходе есть здравое зерно, надо сказать), но во многом. В областе дженериков - так точно, лол, благо что их таки введут в го2.
> В нишах как раз часто и возникают монополии. Но никто не будет ждать минуту пока загрузатся сайт, если рядом есть такой же, загружающийся за секунду.
я имел ввиду не монополии. Даже сраный интернет магазин, продающий матрацы, может позволить себе минутную загрузку корзины. Да, может существовать другой магазин, грузящийся за секунды и самая прошаренная часть аудитории уйдёт туда (до 20 лет, айтишники и то), но подавляющая часть - какие-нибудь бабушки, деревенские, рабочие с заводов и прочий пролетариат очень непритязательны, у них и так всё тормозит, потому что комп обвешан яндекс-барами и mailru-игорами, они разницы и не заметят.
Но это зависит от целевой аудитории, это 100%.
> Прямо в каждом методе? Это на уровне стайл-гайда у вас?
При использовании перед разыменованием, если параметр опциональный и ты не проверил его раньше.
Ну и всем известные правила вида "не пили сук на котором сидишь", "не передавай nil непонятно куда, если это явно не требуется" и тп. Может, звучит странно и небезопасно, но повторюсь - проблем с указателями у меня не было примерно никогда, при том, что я работаю в команде и мы пишем довольно много кода.
> В любом случае, такой подход имеет свою цену в плане боилерплейта, а глобально с ним можно очень далеко зайти - можно сказать что раст не нужен, нормальные разработчики не делают free after free и не допускают выхода за границы массивов, статические анализаторы кода не нужны, да и вообще нормальные разработчики не делают багов вне зависимости от языка.
Я осознаю, что такой подход небезопасен и ни в коем случае не говорю, что он правильный. И даже выше писал, что мне такое не очень нравится. Просто заметил, что при этом в реальной работе таких ошибок не настолько много, чтобы суровая необходимость в таком подходе чувствовалась. Поэтому многим отбитым гошникам и сишникам он кажется избыточным.
А линтер в го кстати очень мощный, много чего отлавливает, рейс детектор вообще огонь.
>поддержка скалы и в IDEA хуже чем джавы, по вполне понятным причинам
Причина ровно одна - действительно важные фичи на вроде рефакторингов, инспекций кода, поддержки всевозможных фреймворков и т.д. есть в Ultimate версии IDEA для Java. В Scala за 11 с лишним лет существования плагина ничего такого не появилось, ровно как и нормального анализа кода, который бы не подсвечивал все красным. А, ну и в Ultimate версии для Scala ничего нет. Именно поэтому все сидят либо на Community, либо на EAP. Иными словами - разработка Scala плагина не приносит JB ни копейки.
> В областе дженериков - так точно, лол, благо что их таки введут в го2.
Интересно, кстати, будет посмотреть насколько go2 останется простым языком. Очень часто бывает что решения приклееные сбоку оказываются сложнее чем если бы проблему решали в изначальном дизайне.
>Даже сраный интернет магазин, продающий матрацы
Тут остается надеятся что через какое-то время сайты-магазины можно будет создавать без помощи программистов, а они будут заниматься более сложными задачами.
>подавляющая часть - какие-нибудь бабушки, деревенские, рабочие с заводов и прочий пролетариат очень непритязательны
Они действительно непритязательны к производительности (до определенного предела), но часто чувствительны к плохим интерфейсам - видел как приложения из телефона удаляли после минуты использования, а баги, особенно связанные с проебом данных никому не нравятся, особенно в B2B приложениях. Ну и если тормозит не магазин, в который ты заходишь раз в год, а что-то чем ты пользуешься каждый день, тут и работяга с завода альтернативу искать начнет.
>если параметр опциональный
Ну это понятно. А что если нет? Обычно проблема с null возникает когда его передают вместо обязательного параметра, а туда он в свою очередь попадает как результат вызова какой-то другой функции. По сути, нужно проверять не столько переданые параметры, а скорее возвращаемые значения. Это еще осложняется тем что функция, которая раньше нулы не возвращала, может начать это делать без изменения сигнатуры. А значит, эти проверки нужно делать просто всегда или же рано или поздно получишь NPE. С другой стороны, может в го это как-то по-другому обходится, или эти логические ошибки все равно существуют, но проявляются в другом виде. А может вы просто контролируете 90% используемого кода, не интегрируетесь с большим количеством библиотек и ловите все тестами.
>>1816473
>Причина ровно одна
Пока я нашел ровно одну причину нелепости твоих высеров - не никогда не пользовался тем, о чем пиздишь. Этот пост только подтверждает мой вывод.
>действительно важные фичи на вроде рефакторингов, инспекций кода, поддержки всевозможных фреймворков и т.д. есть в Ultimate версии IDEA для Java
Ultimate версия для Java действительно дает поддержку фреймворков, все остальное доступно в CE. Еще многие языки доступны только в Ultimate, если мне не изменяет память Node.JS, Python, PHP, Go.
>А, ну и в Ultimate версии для Scala ничего нет.
Есть, как раз таки поддержка фреймворков, а именно Akka и Play.
>Иными словами - разработка Scala плагина не приносит JB ни копейки.
Иными словами ты думаешь что бизнес потратил 11 лет и кучу денег на то что им не приносит прибыль, хотя бы косвенно?
На сколько хороша Scala в serverless? Как лучше всего собрать программу, чтобы не попасть на БАБКИ?
GraalVm - глюкодром и анальная лицензия от Оракула. Scala.js - еще один глюкодром, к которому подключается знание помоев в виде Node.js. Scala Native заброшен и по сути не имеет никаких байндингов к тому же AWS Lambda.
> Интересно, кстати, будет посмотреть насколько go2 останется простым языком. Очень часто бывает что решения приклееные сбоку оказываются сложнее чем если бы проблему решали в изначальном дизайне.
Ага, мне тоже интересно, во что в итоге это выльется.
> Тут остается надеятся что через какое-то время сайты-магазины можно будет создавать без помощи программистов, а они будут заниматься более сложными задачами.
Ну да. Только какой-нибудь pleer.ru (а сайт такого размера и сложности не так-то просто сделать "на цмске") может всё равно выглядеть всрато, обладать отстойным сервисом и при этом "жить".
> С другой стороны, может в го это как-то по-другому обходится, или эти логические ошибки все равно существуют, но проявляются в другом виде.
Ты наверное проводишь аналогии с джавой. В го можно передавать переменную по значению и тогда ты не сможешь передать вместо неё nil, а можно передать указатель на переменную и вот он может быть пустым. Но аргумента для передачи указателя может быть ровно два:
- или это опциональный аргумент и тогда его всё равно придётся проверять перед использованием;
- или мы специально передаём указатель вместо передачи по значению, чтобы не нагружать гц лишний раз (такое делается не всегда, а только если в каком-то месте на больших нагрузках гц проседает и приходится руками оптимизировать код) - но в таком случае ты всё равно будешь передавать аргумент вообще всегда и никогда не передашь nil, потому что ты знаешь, что он обязательный и указатель там чисто ради оптимизации.
Там есть отдельный момент, что вместо любого интерфейса (в смысле, когда вместо явного типа функция принимает интерфейс) можно передать nil и вот это жопа (и огромный камень в огород авторов го), потому что естественно никто в каждой функции не будет писать повторяющуюся лапшу типа if arg == nil return error - но реально это решается коллективным договором "никогда, вообще никогда не передавать nil вместо интерфейса". Звучит пиздец, конечно, но на самом деле это практика аналогичная "чисти за собой память" в си или "не делай die внутри библиотеки" вообще везде, просто никто никогда так не пишет, а если пишет - такой пакет никто не использует.
> не интегрируетесь с большим количеством библиотек
Их не так много, как в js, это да - но при этом почти все следуют тем же правилам, которые я описал выше, так что с этой стороны всё нормально.
> ловите все тестами.
Тестов пишем дофига, это верно, но даже не ради безопасности, а потому что так удобнее. Лень самому долбить в localhost джсончиками, когда тестируешь только написанный код. А так ты и проверяешь то, что только что написал - и на будущее тесты остаются. Хотя это настолько легко только потому, что у меня выстроена вся инфраструктура для тестов: под тесты создаются бд, миграции, вот это всё - и поэтому я реально только предсоздаю данные, шлю запрос и потом проверяю ассертами ответ.
И да, даже на тестах я не помню, чтобы были какие-то частые проблемы с указателями, значит, или не было совсем, или так редко и такие тривиальные, что в памяти не отложились.
>может всё равно выглядеть всрато
Да может. Вопрос в том почему нет конкурентов. Хотя может они и есть и отжирают у него аудиторию. Ну и у бизнеса могут быть другие преимущества - цены у магазинов и например количество уже существующих пользователей. В B2B с этим посложенее - если твои платные сервисы проебывают чье-то время или деньги, это не может продолжаться бесконечно (хотя может долго по разным причинам).
>никогда, вообще никогда не передавать nil вместо интерфейса
А что делать если тебе нужно вернуть значение которого у тебя нет? Нет пользователя в базе или ключа в мапе? Или не получилось выделить память, как в malloc? Почти во всех языках, которые я немного знаю (условно С, Python, C#, Java, Clojure), для этого обычно используется null и именно отсюда и вылезает пресловутая billion-dollar mistake. В С++ используют что попало, в Scala - Option или похожие типы. А в Go какой принят паттерн обработки таких ситуаций?
>Тестов пишем дофига, это верно, но даже не ради безопасности, а потому что так удобнее
Это радует, а то в 2020 все еще есть ебанутые, который именно что руками JSONы пуляют.
>>1817116
Гугли in-sync replica set и unclean leader election. Возникнут конкретные вопросы, спрашивай.
Все, кто хотел вкатиться в Scala, рекомендую прочитать сегодняшний срач тимлидов крупных контор в scala_jobs, которые на пальцах объясняют, что перебежчиков, вкатунов и прочих мутных личностей им не надо. А нужны люди с опытом (минимум 1 год коммерческого опыта разработки), чтобы войти в Scala. При этом они подтверждают, что в Scala люди идут не за высокой зарплатой, а за возможностью работать над сложными задачами, которые, по какой-то причине, невозможно решить на Java.
> Да может. Вопрос в том почему нет конкурентов. Хотя может они и есть и отжирают у него аудиторию.
Всегда есть конкуренты. Но при этом практически невозможно захватить ровно 100% рынка, всегда будут недовольные, кому не понравился дизайн или просто кто в гугле не на ту ссылку ткнул. Так что в B2C ты не обязан даже быть лучшим - просто держи свой говносайтик и живи, пока твой доход меньше твоих расходов. Тем более, что там куча маркетинговых механизмов, скидочки, реклама, вся хуйня. Если у тебя говносайт - то тебе сложно стать лучшим, но это не означает, что ты умрёшь, короч.
> А что делать если тебе нужно вернуть значение которого у тебя нет?
Ага, через указатель, точнее, указатель с ошибкой: в го функция может возвращать несколько переменных (как правило это [pointer, error]) - и гошные линтеры умеют понимать, проверил ты это ошибку или используешь указатель "всырую".
Но даже если функция возвращает только указатель (хотя так обычно не делают), если это геттер, то ты же не дурачок и сразу напишешь что-то вида
```
val := GetVal()
if val == nil {
return err
}
// use *val
```
и убьешь возможную ошибку в зародыше.
Было бы лучше, если бы были к примеру юнион тайпы и в го можно было писать `func Foo() (value | error)`, но чего нет, того нет :(
this >>1818978 Типа сложный домен (обычно финансовый), где нужно накрутить побольше тайпклассов и упороться монадами на отличненько. Все как один негативно относятся к Akka/Play/Slick и говорят, что это "не тру скала" и что им "жаль" людей, которые тратят время на беттер джава подход, когда можно все тоже самое писать на котах.
>Очевидно, написать кастомный scala-based-dsl.
Что еще можно услышать в скала треде кроме - скала ради скалы.
Нет такой бизнес задачи написать кастомный scala-based-dsl, есть задачи где это один из вариантов решения. Но кастомный DSL можно много на чем написать, есть и котлин и груви, в конце концов ANTLR.
>>1818997
>Типа сложный домен (обычно финансовый), где нужно накрутить побольше тайпклассов и упороться монадами на отличненько.
У кого в руках скала - тому все кажется тайпклассами и монадами.
>У кого в руках скала - тому все кажется тайпклассами и монадами.
Эти разговоры не на пустом месте появились. Большинство бекенд вакансий - это коты и прочий тайплевел стек. А это тайпклассы через тайпклассы.
Ни спарк ни лайтбенд стек не признается в скала коммьюнити как тру-скала. Хотя вакансии по спарку еще присутствуют.
>Там выше "сложными задачами, которые, по какой-то причине, невозможно решить на Java".
>Как видишь, слова "бизнес", там нет.
Там еще выше
>При этом они подтверждают, что в Scala люди идут не за высокой зарплатой, а за возможностью работать над сложными задачами, которые, по какой-то причине, невозможно решить на Java.
Как видишь там есть слово "работать", что подразумевает решение именно бизнес задач, а не скала ради скалы.
>Ну так выучи если работу не найти, делов-то.
Ах если-бы все было так просто! Ведь в РФ никому не нужен перебежчик без коммерческого опыта в Scala. Ну и вакансии на котах меня ничуть не возбуждают. Ведь я могу лишь только догадываться сколько боли и унижения приходится терпеть рядовому программисту, которые в очередной раз пытается реализовать тайпкласс из котов, а идея все краснит!
>betterjava
Отсутствие вакансий как класс. Общественное гонение на лайтбенд стек.
>ФП стек
Полторы вакансии в РФ, где нужно 3 года коммерческого опыта на котах и прочих фс2, минимум. Весь фп-стек - это леваки из тайплевела + пару отбитых кадров на вроде болгарина, который топит за дайверсити, и какого-то чела, которого поперли из твиттера и теперь он воюет с воображаемыми белыми супремасистами и пишет жысон парсеры.
Тааак, сейчас буду писать масштабируемые приложения на Скэйле!
@
Падажжиии, а почему ИДЕЯ краснит! Тааак...
@
Что же это такое, почему Скейла срет в хип! Падажииии!
@
Хм, а это что за закорючка?! Таааак!
@
Да как так то?! Почему всего 1к запросов в секунду! У на с же должно быть РЭКТИВ ПРАГРУММИНГ! Тааак, падажжии!
@
Михал Брсыч, ну дайте еще полгода - мы все на котлин перепишем и людей наймем!
@
Сап /pr, мне не перезванивают...
> Нет, не похуй. Менеджмент понимает, что если начать проект на непопулярной технологии, то это может загубить весь проект. Так случилось с Моим Складом. Пока его писали борщехлебы на Scala, то дела у компании шли так себе - новых сотрудников было тяжело нанять и они стоили каких-то безумных денег, продукт был забагован и вхождение в проект было тяжелым испытанием для новых программистов. Но вод пришел Козуля и переписал проект на Java и теперь разработчики находятся на раз-два, проект очистился от FP-дерьма и теперь все будет ништяк.
Я уж сильно извиняюсь, что отвечаю на пост далекой давности. Но блэт, какая же бредятина здесь написана. У МоегоСклада на Scala.js был написан только один маленький подпродукт (онлайн-касса), который не так уж сильно влиял, и говорить, что у компании шли дела плохо из-за этого - просто большая и наглая ложь. Основную прибываль в компании приносил сам МойСклад (невероятно, да), в котором скалы нет и использовался супер-древний полу-мертвый Java EE стэк (немножно вру, ибо капелька скалы в виде, например, джавовой обертки на скаловым персистентным вектором там была в коде). И лучше бы в МС хотя бы использовали Scala.js на фронте, ибо в реальности там используется для этого GWT, о котором ничего кроме кучи мата сказать вообще нельзя.
мимо бывший сотрудник МС, который ушел в скалу
Аналитика по Akka подоспела -
>Вот в акке ты что-то добавил и у тебя всё развалилось, и ты об этом не узнаешь
Проходить курс от Олега стоит только в случае, если ты потом собираешься идти в финтех школу Тинькофф и являешься при этом студентом. Только учти, что туда подаются одни из лучших ребят, которые побеждают в межнарах и щелкают задачки с литкод уровня HARD как орешки перед завтраком. 300кк/нс тебе, конечно же, никто не предложит. Типичная вилка для рядового разраба с 3-5 годами опыта - 100-130к. Сам желтый банк теперь куплен Яндексом (на самом деле Сбербанком, который держит "49%" акций Я).
В зависимости от вакансии, тебя ждет либо скандальная бабенка, которая будет тебе выносить мозг, доказывая, что Option - это не монада. Либо будет челик из инвестиций, который обмазывается тофу и прочими поделками ирландских бездельников, которые дожидаются выдачи паспортов.
В любом случае, перспективы у тебя далеко не радужные.
Неистово проигрываю в голосинушку с вакансий, которые вкидывают в скала_джоубс. "до 200к!", "ищем строго сеньоров!", "5 лет на спарке!", "физмат или математическое образование!". Какие-то мутные конторки, онлайн-казино из Литвы, где заебанные жизнью крупье со слезами на глазах крутят рулетки. Какие-то "стартапы" из Эстонии и Финки, пытающиеся найти сенек на 2к баксов через ИП.
Все эти "вакансии" не имеют ничего общего с настоящей работой, которую можно лицезреть в про_джмджобс. Вот где работа так работа! Каждый день вкидывают по 5-7 новых вакансий и все как на подбор - адекватные требования, вилки от 150 до 400к и выше (для лидов и крутых парней). Все хорошо у джавистов. Одни скалисты работают не за зарплату, а ради интересных проектов и пердолинья монад.
Очередная вакансия в скала_джоубс. Очередная компания пытается найти Apache Spark разработчика на вилку до 175к, лол.
Как начать писать пет-проекты? Прочел несколько книг, но все равно появляются моменты, когда я понимаю, что освоил не всю скалу. Понимаю, что без пет-проектов мое резюме даже рассматривать не станут, а на собеседованиях, скорее всего, будут попускать на алгоритмических задачках и каких-нибудь тонкостях языка на вроде линеаризации трейтов, например.
О, да, знаю эту проблему. Творческий кризис.
Если в кратце, старайся почаще задаваться вопросом "хуйнянейм не существует, а было бы супер, если бы она была".
Возможно, на андройде нет клиента для твоего любимого сервиса?
Или один бот в телеграмме работает не так хорошо, как бы тебе хотелось (если он вообще есть)?
Или ты бы хотел, чтобы малинка крутила резитивный диммер на маслянном обогревателе?
У меня нет проблемы с идеями проектов. Я боюсь, что мой код на Scala будет не оптимальным или всратым, в духе Java, т.к. я могу не знать каких-нибудь фишечек или паттернов, которые распространены в Scala-мире. Из-за этого у меня некого рода паралич, когда просто записываю и анализирую идеи (выбираю библиотеки и фреймворки, ищу аналоги и анализирую, что я мог бы улучшить, рисую архитектуру), но за написание кода так и не берусь...
У тебя на работе скорее всего есть куча штуковин, которые возможно многим лень сделать (ну или просто нахрен не нужно, а тебе может быть весело). Такие штуки и есть отличный плейграунд для маленьких пет-прожектов. Не факт, что кто-то будет использовать, не факт, что получится годно, но для игр с интересным стеком такие задачи прекрасно подходят.
Чаще всего можешь посмотреть в сторону CD (в очень многих проектах, особенно свежих, это целый простор для своих тулзов)
или, например, если сервис большой и публичный и с предыдущим пунктом все ок, можно написать какую-нибудь тулзу, играющуюся с АПИ. А может у тебя тестеры есть? Вот посмотри, что им не хватает.
- Лысый рекламщик-нацист
- Психически неуравновешенный Мистер Коричневый
- Гей-пара из Ирландии
- Поехавший тимлид из желтого банка с аниме на аватарке
- Телеграм-пацаны с λ и [F] в именах
Каждый раз в голос.
Учусь на старшем курсе и задался вопросами. Есть ли смысл вкатываться в скалу через Олежа-банк в Екате? И смогу ли я потом перекатиться в другую компанию на скалиста? Ведь жёлтый банк вроде как на тофу пишет.
У Apache есть либа kafka_2.12, я использую версию 2.3.1
В ней есть класс (Пик1)
Когда я подключаю как библиотеку в джава проект, я могу обращаться к этой штуке так: new RackAwareMode.Safe$()
Идея показывает байткод Пик2
Я попытался зашейдить эту зависимость с релокейтом ЗК, И теперь у меня нет доступа до Safe$ - не видно ее из джава класса + байткод стал другим (Пик3)
От чего это может зависеть? думал от таргет версии двм, но вроде как нет... Как такое гуглить?
Ух бля.
По идее делать new для обращения ко вложенным object тебе не нужно, гугли "scala static forwarders".
В остальном я хз, видимо зависит от того, как именно ты делаешь релокейт.
Но вообще, почему бы не написать код на скале, либо просто взять джавовый кафка клиент?
>>1859298
контекст: кровавый тырпрайз на джаве, а мне нужно обновить версию зукипера, при этом кафке нужна старая версия ЗК (Зукипер), поэтому я зашейдил кафка-зависимость и релокейтнул ЗК.
В итоге такой отвал жепы скалы случился.
то что new не нужно юзать - спасибо, но это не помогло, т.к. сам Safe$ не видно просто из джава кода, хоть как обращайся
способом тыка понял, что эта проблема появляется когда релокейт происходит
добавил в релокейт пакет, где лежит проблемный класс (kafka.admin) и все заработало.
Не знаю почему так :(
да шейдил, но пекедж менял только у "org.apache.zookeeper",
"org.apache.jute"
Попробовал зарелокейтить аналогично все пакеты с префиксом "kafka" - не помогло, та же проблема :(
Я пользовался для шейдинга плагином https://github.com/johnrengelman/shadow
Щас посмотрел - там много окрытых ишью со скалой - видимо плагин криво работает с ней.
Может кто нибудь посоветовать плагин для шейдинга кафки? с учетом что там сорцы на скале.
у мавен шейд плагин тоже какие-то проблемы есть https://issues.apache.org/jira/browse/MSHADE-345
короче деконплеировал бинарник самой либы kafka_2.12 (пик1) и то что у меня получилось зашейдить (пик2).
Почему-то плагин для шейдинга наколбасил для каждого вложенного object отдельный класс.
При этом джавовы конпелятор его не видит, иде показывает синтаксическую ошибку, когда пытаешься к нему обратиться. Но! Class.forName("kafka.admin.RackAwareMode$Safe$") работает.
ну и хуйня....
Сделать таск в SBT, который шейдит эту ебучую кафку и вызвать этот таск из градла как показано здесь https://stackoverflow.com/questions/51793555/how-can-i-call-an-sbt-task-from-gradle
пиздец остановите меня кто нибудь, скажите что есть способ легче
ну смотри как я понимаю
шейдинг - когда код зависимостей прямо запихивается в сам джарник, это удобно для развертывания приложения на серваке - чтоб все нужные зависимости нужных версий в самой джарке были
Во время шейдинга можно релокейтнуть классы в другой пекедж (т.о. изменить их FCN и импорты все соотв. в джарке поменять), таким образом можно позволить в рантайме иметь две версии одной и той же либы: джарка использует ту, которую сохранила и релокейтнула, а клиентский код, который подключил эту джарку как либу - может юзать другую версию
Я не претендую на гениальный код, я всего лишь начинающий разработчик и могу ошибаться, вот код, слева реализация класса с одним методом(пока), справа основной фай. Реализую нечеткие множества. Паттерн матчинг прекрасно передается в класс и используется в методе(первый метод работает), в ином случае никак не могу обратиться к паттерн матчингу. В принципе по коду все понятно должно быть, создаем юниверс(общее множество элементов) и несколько нечетких множеств. Прошу сильно не ругаться
сейчас скину второй скрин снова, чет тут хуево показывается
кто ж это в скалко-комьюнити так заходит? так тебя сразу определят в джявачерта и будут соответствующим образом относиться всегда
правильно заходить через хаскiль, чтобы все сразу поняли что ты правильный пацан
нужны знания хотя бы уровне осиленной тайпклассопедии, устройства основных либ и умения применять цацкель на практике
лишнего лучше не припёздывать, а то если фраернёшься адванседом и не вывезешь, то потом ещё хуже, чем джявочертом сидеть
ну и про свой старый опыт как ты там на джяве спринг лизал тоже помалкивай офк
пис
То самое коммьюнити, где один вайс си-ти-оу хвастался как они пересели на базель, и как у них все заверте...
А потом выяснилось, что под базель нет и десятой доли плагинов, да и поддерживается он так себе. И теперь вайс си-ти-оу, запрягает команду, чтобы те метнулись кабанчиком и вернули все взад?
>Q: Какой стэк библиотек взять?
>A: cats, http4s, doobie, circe, ZIO
Почему, когда я открываю HH.ru, то вижу вакансии либо на Apache Spark, либо на Akka?
ну Акка очень неплоха, отработал на проекте больше года где все было на акке, мне понравилось. Это нормальные вакансии.
А вот с спарком лучше не сунутся туда. Так как сейчас надо овер дохрена макак которые все говно которое писали с 2003 на мап редюсе, сейчас переписывают на спарк, так как быстро и молодежно. и спарк писали на скале, значит нам надо скала девы. хотя им надо обезьяны знающие спарк. рекрутеры это не понимают поэтому ищут скалистов. Попал в такой местяк где хотели под шумок заставить выучить спарк и пойти на бигдату.
Хочу для себя поучить что-то интересное необычное. Из вариантов хаскель, идрис( но я так понимаю без хаскеля смысла нет макаться), эрланг, кложур, и возможно дотти.
Что имеет смысл попробовать? Цель - узнать всякие приколюхи которые глубокие по концепции. Например как в скале сделали с имплиситами, и таким корявым образом сделали тайпклассы из хаскеля.
гемблинг, вся бизнес логика была на модели акторов. Ну либы для функционального у нас тоже были, типа котов, шейплесов.
Та все так говорят, но я хз, может есть проблемы с перформансами. Некотрые жалуются что тяжело разбираться. Но надо просто привыкнуть к модели. Мне нравилось что тестировалось очень хорошо. плюс у акки есть типизиованые актеры. с персистансом хорошо сделано. Но если бы я начинал делать свой проект то явно не на акке, а скорее на зио и всяких модных вещах
Варианты такие:
- clojure - макросы, трансдьсеры, CSP
- agda/coq/TLA+ - формальные доказательства/завтипы
- rust - new generation байтоебство
- prolog - логическое прогрмаиирование
А я вообще для себя решил что после после понимания основных парадигм слишком задрачивать их дальше смысла особо не имеет - нужно изучать что-то более фундаментальное (в моем случае распределенные системы).
>Type classes were first implemented in the Haskell programming language after first being proposed by Philip Wadler and Stephen Blott as an extension to "eqtypes" in Standard ML,[1][2] and were originally conceived as a way of implementing overloaded arithmetic and equality operators in a principled fashion
>Халло!
>Ай воркд он таск 953 энд ай хэв э куэстшон
>Хау ду ай коннект ту датабасэ, плэз?
Если ты учился в школе с углубленным изучением английского и тебя родители натаскивали, то да, проблем устроиться в подобные конторы не будет. А так будешь мычать как побитая собака на собеседовании с рекрутером, вспоминая слова.
Ну и не забывай, что там, за забором, столько первоклассных разработчиков, что ты должен быть литерали гением, чтобы с ними конкурировать.
ладно, тогда сиди в рашке и не пизди, если не можешь выделить 200 долларов в месяц и пойти на курсы английского, или даже нанять репетитора. и за год уже говорить в 5 раз лучше.
А еще пиздят на хохлов, тут каждый 2 кто не совсем даун, или уже перекатился или перекатывается, или сидит дома и пиздячит на пиндосов.
Ну так таким нужно английский, а не скалу учить. И знать его нужно на уровне что быть понятым, а не идеально использовать речевые обороты и знать нюансы синонимов (хотя и желательно).
>Ну и не забывай, что там, за забором, столько первоклассных разработчиков, что ты должен быть литерали гением, чтобы с ними конкурировать.
1) Первоклассных не хватает. Работодатели за них конкурируют, а не наоборот.
2) У тебя точно есть конкурентное преимущество - цена.
>>1874113
Это по-разному. За пару лет активного изучения (курсы, сериалы в оригинале, грамматика по учебникам) вполне можно подтянуть до сносного уровня. Лет семь назад я за полгода разговорный язык с околонулевого подтянул до достачного для работы (ну это я, среднестатистическому двачеру как раз года два нужно будет).
В чем смысл переката в Scala, если в скала канале вкидывают один раз в месяц полудохлую вакансию на 160-200к на хадуп, спарк?
Подтверждаю.
Зычно проиграл на всю квартиру с этого высера - https://developer.lightbend.com/docs/akka-platform-guide/index.html
Такая-то нелепая попытка примазаться к тематике микросервисов.
я хз где вы видите что все закончилось. мне постоянно кидают вакансии, да, из них 40% это спарки. Куча людей работает, куча стартапов запустилось, плюс минус живое комьюнити, в раз 100 приятней чем в жабе. Люди развивают свои библиотеки, делятся знаниями.
может в россии и закончилось, но явно не в мире
добавлю, а не выстрелила потому что-пиндосы в своем большинстве крайне ленивые и не склонны к изменениям в карьере. был на проекте где люди работали по 20-25 лет в одной компании. и пришли туда как перл, потом переучивались на скалу. и таких 60%.
они не будут вкатываться с джавы на скалу.
наше снг комьюнити чаще всего готово в жопу давать за долларовые зарплаты, и им вообще похуй на чем писать, они пишут зарплаты прогромистов, видят что на жабе выхлоп один из самых высокий. на обжектив С и свифт сложнее вкатываться.
В итоге на скалу перекатились только ебнутые, которым не сидится на месте.
КОмпании которые примазались к "хайпу" в 2012-13 начали ахуевать, где им искать работяг на вашу это скалу. а остальные посмотрели на этих дураков и решили даже не макаться. Так как джава-макаку найдешь за пол часа, а хорошего специалиста за месяц-2. Порочный круг рынка, поэтому в нулевых было 2 базы или мускл(бесплатный) или оракл. так как на оракл ты найдешь всегда людей. и все ребята которые хотели идти в дба знали, что выучишь оракл, найдешь работу.
Если какой-то придурок с двача считает что какое-то решение провальное, то так очевидно и есть. Особенно если его уровень - рассуждения о переслащености языка и о том что фп в скале не развивалось никак.
>>1877170
>не выстрелила
Я вот что понять не могу - что для вас было бы выстрелила? Иметь такой же уровень использования как у джавы или что?
>>1877075
Ну это хорошая причина для преката, но я-то отвечал на пост в котором слова хайп и перекат в одном абзце стоят.
выстрелила, это значит как кубер, что его каждая собака использует, или как реакт, или как например как котлин, графкьюл, сваггер.
или технологии которые не стали топ запрашиваемым, а заняли свою нишу, например, спарк, го, кафка.
А скала по факту для бизнеса не нужна, и даже вредна. И проекты на скале сейчас ,или от энтузиастов, которым нравится фп и скала, или от "дураков" которые на нее перекатились/стартанули в 2012-2015 и думаю как найти людей.
Конечно, полностью с тобой согласен. Но большинство(95%) пришли работать девами за бабки. Есть товарищ, прога ему всегда как и мне нравилась, занимались олимпиадным. Но сейчас, он хочет, до усрачки, попасть в топ компании типа амазона, гугла, фейсбука, САП , в любую залупу, главное чтобы было много людей, и он так и оценивает все компании, мол, "200 человек, ну что за говноеды, вот у гугла 10 милиардов к людей работает", мотивируя тем что там он поднимется по лестнице и будет получать очень дохуища бабок. Ну и таких дохуя.
>выстрелила, это значит как кубер, что его каждая собака использует, или как реакт, или как например как котлин, графкьюл, сваггер
Никакую из этих этих технологий каждая собка не использует (ну кроме реакта наверное). Особенно кубер, лол - пиздят о нем много, а используют единицы.
>или технологии которые не стали топ запрашиваемым, а заняли свою нишу, например, спарк, го, кафка.
Ну вот и скала заняла свою нишу - лучший язык для JVM для тех кто понимает как ее использовать.
>А скала по факту для бизнеса не нужна, и даже вредна
Мне кажется или ты по кругу в своих рассуждениях ходишь? Скала не выстрелила потому что вредна, а то что она вредна подтверждается тем что не выстрелила? Ты все-таки можешь сказать что такое выстрелила, не на примерах, которые больше на список текущих хайповых технологий похожи, а определение которое можно применить к любой технологии?
я сразу написал что это замкнутый круг
Я не понимаю предмет спора и что ты хочешь доказать. хочешь сказать что скала популярная в бизнесе, ну ты тогда не прав. У нее хорошее комьюнити, она развивается, много хороших идей есть. Но бизнесу она не надо, так как заебешься искать людей.
>я сразу написал что это замкнутый круг
Этот круг делает необоснованным любое рассуждение в котором используется. Например - ты дебил, потому что сидишь на дваче, а сидишь на дваче потому что дебил. Вывод - ты дебил.
>Я не понимаю предмет спора и что ты хочешь доказать
Я ничего не хочу доказать. Ты (или кто-то еще) высрал фразу скала не выстрелила. Я хочу понять что под этим имеется в виду.
>Но бизнесу она не надо, так как заебешься искать людей.
Слишком сильное обобщение. Все что мы можем обоснованно заявлять - скала менее популярна чем джава, а потому на нее труднее искать людей. Все остальные обобщения - фантазии, пока не приведены факты и непротиворечивые рассуждения, а реальная ситуация зависит от конкретных обстоятельств.
Ошибка в том, что «бизнес» это слишком общее понятие.
Я знаю лично несколько контор, которые работают исключительно на ФП-стеке, в том числе на скале, и вполне себе успешно живут в своей нише, оставаясь конкурентноспособными. Да, их меньшинство, но это тоже «бизнес». Поэтому если пишешь что «скала бизнесу не нужна», нужно указывать какому именно. Супер-крупные компании как раз могут себе позволить (и позволяют) экспериментировать сколько угодно с каким угодно стеком, так как кадрового голода не испытывают, а бюджеты и количество разрабов позволяют спавнить сколько угодно экспериментальных проектов, контрибьютить в опенсорс и т.д.
Стартапу тоже всё равно на чём стартовать, тут даже чем хайповее или необычней - тем лучше. Средние и большие конторы тоже разные бывают, типичные снг-галеры заточены на максимальные охваты, поэтому фокусируются на консервативном стеке, чтобы с одной стороны иметь как можно больше заказов, а с другой чтобы была возможность быстро захайрить нужно кол-во рабов из местных. И то, даже там завозят пару скалистов, чтобы не пропускать скала-заказы, когда они всё таки случаются. Но ещё сейчас есть много чисто виртуальных полностью ремоут-контор, которые собирают людей со всего мира, поэтому проблема захайрить людей у них особо не стоит. Так же есть масса консалтеров, с CTO на своей стороне, где выбор технологии полностью зависит от них, которые берут только те проекты, которые соглашаются на их правила разработки. Все они существуют и некоторые функционируют десятилетиям.
Но:
1. горело жопьё с токситиси чатов скалки, видимо поцы оттудава внебрачные сыны старого пердуна мартина которые звали не маму и папу при рождении а монады и моноиды очень умные и не для меня сравни с рукомьюнити раста -это как жопа и палец
2. как котик плакал сру вакансий: либо какие-то адепты, либо вечер в типа большую дату
Короче для меня ru Scala environment - so-so. А язык прикольный, вписался бы в какую-нибудь опенсорс компашку долбачей но без желтого налета и был бы рад как слон, но нiт яких хлопцев.
Вкатывайся в англоязычное коммьюнити (реддит, гиттер) если владеешь языком.
В телеграм-чатики по Скале не заходи, там тусуются одни и те же долбоёбы. Мне вот с ними на работе приходится общаться, с постоянным А КАК В ТАЙПЛЕВЕЛ СТЕКЕ КАКАТЬ и прочими фразами уровня /b/
>как кубер, что его каждая собака использует
>>1878581
>Особенно кубер, лол - пиздят о нем много, а используют единицы
и оба мимо. k8s много где, но не везде используют. k8s используют в больших компаниях, тк в этом случае это значительно упрощает жизнь компании. каждая тима, которая деплоит свои приложения, не изобретает свой (кривой) способ деплоймента
>желтом банке
>пояснить за подводные
Пойдешь в один желтый банк - встретишь тимлида-анимешника, который упарывается тру эфпе и пердолит свои, никому ненужные, библиотеки.
Пойдешь в другой желтый банк - попустят на собеседовании, да так попустят, что выбежишь весь взмыленный и помчишь в свою съемную однушку, чтобы поскорее принять душ.
На мой взгляд сейчас в обоих желтых банках самые сильные команды скалистов в рашке. Но я ни в одном из них не работал, не знаю, есть ли подводные. ИМХО обычная банковская работа должна быть и з.п. должна быть средняя по рынку.
Еще они там большие фанаты ФП, причем странные фанаты. Типа считают, что ФП - это круто само по себе. Поэтому давайте писать монады на Скале и пихать zio куда не поподя. А то, что в Скале ФП - не пришей кобыле хвост, их как-то особо не волнует.
На мой взгляд, если ты не шаришь в ФП, но очень от него фанатеешь, иди в любой из желтых. По крайней мере ничего не потеряешь в плане финансов и попадёшь в сильную команду где будут всё это использовать. Если тебе пофиг, можешь идти в любой другой банк.
мимо из зеленого
> пихать zio куда не поподя
Сама по себе ZIO неплохая вещь, считай что это такие продвинутые Future'ы.
Однако, в жёлтобанках(тм) за использование просто ZIO тебя обоссут, потому что (по мнению отдельных упоротых персонажей) нельзя завязываться на конкретную реализацию IO-монады, грубо говоря, ты должен абстрагировать использование ZIO и писать всю бизнес-логику в абстрактном виде.
Дальше - больше, весь мир для таких целей использует cats-effect, но эта тусовочка не особо вдавалась в мотивацию и идеи положенные в основу этой библиотеки/стека, вместо этого они просто заявили что "тайплевел-стек говно", и сделали свою, более лучшую нет либу tofu, в которой идея абстрагировать конкретные типы возведена до абсурда.
И даже хуй бы с этими упоротыми челиками с их психическими расстройствами, но эта около-Московская тусовочка настолько токсичная, что за любое отличное мнение тебя просто загнобят (если ты уже там работает) либо попустят на собеседовании, как писали выше.
>Сама по себе ZIO неплохая вещь
Лол, базаришь. Я сам в ФП лет как 10. Вкатился на самом хайпе. Коты и ZIO - это попытки натянуть сову на глобус ФП на Скалу. ZIO лучше котов. Сам её использую просто потому, что мне так хочется. Раньше котов использовал. Тоже просто потому, что мне так хотелось. Но реальных причин этого делать в Скале нет в 98% приложений.
Что касается упоротых фанатов - я слушал их выступления. Есть хорошие работы, уважаю. Если ты фанат ФП, то почему не желтые? Быстро вкатишся, быстро прокачают. У меня минимум 2 сотрудника съебали к желтым, оба по итогу очень довольны.
tofu - нет не слышал. Вообще, срать на Скале ФП-либами - такое себе. Но раз они высрали, это уже говорит об уровне их культуры кодинга. И говорит о том, что культура есть.
И да, cats - говно (про tofu не знаю, возможно такое же говно, просто сбоку). Zio - говно (потому что сама Scala - говно, но лучше zio на этом говне уже не придумать). ФП на Скале - не нужно.
Но если ты молодой специалист, который угорел по ФП, то желтые - не говно. Причем оба желтых. И мне нет смысла их рекламировать, я сам из зелёных, как уже раньше писал.
> Чем тебе предстоит заниматься:
> изучением решения на Scala и переписыванием его на Java
Ну вот, ещё одна фигня-для-засирания-интернетов-рекламой переходит на надёжный и проверенный стек вместо хипстерского ФП
Не слушайте этого - >>1915290
Вкатывайтесь в Скэйлу. Вам все условия для этого обеспечили - https://fintech.tinkoff.ru/study/fintech/scala/
Даже если не найдете работу, то вырастите как инженер и на крайняк сможете колесить по миру и вызволять гарнiх дiвчiн из лап мужей тиранов - https://twitter.com/Oleksandra_A/status/1351287068681515012
> cats - говно
> Zio - говно
> сама Scala - говно
> ФП на Скале - не нужно.
> я сам из зелёных
Мы заметили.
Отхватил жирный контракт на запил BPM движка на Скэйле, между прочим - https://twitter.com/jdegoes/status/1349369761570947073
Будет вам функциональная камунда, лол.
>Q: Хочу угорать по функциональщине и теории категорий
>A: Посмотри на Хаскелль
как такое можно пейсать? это диверсия же.
Ой, будто бы конкурентность - это такая неебаться проблема и будто бы вещи типа Zio её ой как хорошо решают. Про многопоточность я вообще молчу (ты, кстати, перепутал многопоточность с конкурентностью).
>>1917325
Неоднозначно. Сам я старый и больной, но, думаю, где-то 300 рублей в месяц можно поднимать, если ты не совсем скатился в позапрошлом году больше 350 было с учетом бонусов, а сейчас вообще подозреваю, что меня уволят нахуй.
Те, кто помоложе и поживее - больше поднимают. Фокус сейчас на датасаентистов. Хотя какие-нибудь джавакодеры критических сервисов поднимают не меньше датасаентистов, но там работа менее интересная и со своей спецификой.
Думаю, максимум - это должность исполнительного директора и 500 р. Есть ребята, которые и в 25 лет это делают. Но я с ними общался, они реально умные и заряженные, я прекрасно понимаю, почему они могут 500 рублей зарабатывать, а я столько не смогу.
Нет, ну серьёзно, с чем ты из этого не согласен? Я вообще не представляю, какие профиты может дать cats. Он просто неюзабелен в текущих реалиях. Zio - юзабелен. Но с кучей оговорок. А профитов, опять же, не много. Почему не надо писать на Scala в FP-стиле я уже тут тысячу раз разбирал, не хочу делать это еще раз. Просто изучи нормальный FP-язык и посмотри, чем Scala от него отличается.
>Дегоус давно зашкварен
Кста, что за драма вокруг Дегоуса? Он у себя в твиттере пишет, что он весь дохуя толерантный, не токсичный и геев уважает. Я особо не следил, но подозреваю, что драмы в Scala-сообществе, это как драмы в европейских странах - люди просто с жиру бесятся и за неимением реальных проблем придумывают интрижки из нихуя.
> Я вообще не представляю, какие профиты может дать cats
Рискую начать срач, но тем не менее. Как ты будешь решать такую задачу:
Твоё приложение это некий HTTP-сервер. Ему нужно ходить к другим сервисам по HTTP и например к базе данных. Если клиент твоего сервиса отвалился, нужно канцелить все подзапросы к базе/другим сервисам, корректно закрывая соединения и другие ресурсы, а если ошибка прилетела от апстрима, ретраить её на другой инстанс.
В джава-мире это решается примерно никак. Максимум какой-нибудь fault-tolerance от нетфликсовых либ прикрутят, но чаще просто хуй забьют. Или поставят сервис-меш и будут надеятся что ресурсы внутри приложения не будут течь.
На акке ты охуеешь писать стейт-машины для этого добра.
На фьючерах не пробросишь кэнсел.
В cats-effect + fs2 это делается сравнительно легко.
>почему-то весь энтерпрайз юзает Скалу
Потому что ФП - это не энтерпрайз. И Скалы там с гулькин хуй, кстати.
>Х-ль был нормальным языком в 98-м
Нет. В 98-м он был абсолютно неюзабельным языком. В 98-м на нём нельзя было написать что-то практически применимое в принципе. Писать на Haskell в 98-м кстати, писать на стандарте Haskell-98 на современном стеке и писать на Haskell в 98-м году - это совершенно разные вещи, это как на Агде или Идрисе сейчас что-то писать. Ну язык вроде есть, но, с другой стороны, больше нихуя нет.
Более-менее нормальный GHC - это где-то начиная с 8-й версии. После появления Stack, либ Сноймана и прочей инфраструктуры. Вообще, хороший Haskell - это только самый новый Haskell. Старую версию ты даже устанавливать заебёшся, не говоря уж про то, чтобы что-нибудь с ней сделать.
>А Скала шагает в ногу со временем
Не. Скала - cripple by design. Дотти уже 100 лет пилят и никак допилить не могут. И, скорее всего, Дотти так и не станет продолжением Скалы. Будет альтернативный язык, вроде Питон-2, Питон-3.
Как раз Хаскель, в отличие от Скалы, развивается гармонично, потому что там за дизайном следят. Чем Дотти может быть лучше Хаскеля, я вообще не знаю. Тем, что там есть интеграция с JVM? Но JVM - это как раз против принципов ФП. Т.е. в языке пытаются решить изначально неразрешимую задачу. Поэтому всё будет на костылях и странных дизайнерских решениях, продиктованных существующей платформой, а не тем, как надо делать язык правильно.
>В cats-effect + fs2 это делается сравнительно легко.
Согласен. Но это очень частная задача, под которую effect и fs2 заточены.
>На фьючерах не пробросишь кэнсел.
Ну я же говорю, что это частная задача. В Джаве отменяемые фьючерсы сделали. Ждём, пока интегрируют со Scala-future (если интергируют вообще). Но это - марахайка. Кстати, effect и Zio - такие же марахайки, которые ничего магического не делают. Просто умеют останавливать интерпретатор между отедльными эффектами. И асинхронные исключения в Haskell - это тоже марахайки. Они тоже ничего магического не делают, у них просто есть шанс прервать исполнение программы не между биндингами, а при обращении к мусоросборнику. Но если ты пишешь высокопроизводительное приложение на Haskell, ты же не хочешь, чтобы оно теребило мусоросборник, ты пишешь его так, чтобы всё оптимизировалось в минимальный цикл. И там никакой кэнсел работать не будет.
Т.е. все эти штуки тебе предлагают просто красивую семантику, но за этой семантикой стоит контретная реализация. И в реальных высокопроизводительных приложениях тебе надо очень хорошо понимать, как именно эта реализация работает и очень грамотно её использовать. Это, в принципе, не сильно отличается от того, как бы ты это делал на Джаве, просто аккуратно чекая флаги в цикле и прерывая вейты.
Т.е. да, есть красивая обёртка. Но если кодить по хардкору, там внутри она не многое даёт, там разбираться надо. Поэтому самые высокопроизводительные приложения написаны, внезапно, не на Скале и не Хаскеле, а на тупой Джаве и С++, где всем этим говном страдают вручную. Потому что им в любом случае или вручную страдать, или это просто такой же замуд, как в нетфликс, который так же может не сработать, если ты всё вручную не проверил.
>В 98-м он был абсолютно неюзабельным языком. Ну язык вроде есть, но, с другой стороны, больше нихуя нет.
Вы путаете язык и тулчейн.
Да, Майкрософт инвестировала в развитие тулчейна в районе 2000-2010, когда Х-ль как язык собственно стагнировал, но зато его форсили наёмные маркетологи Майкрософта, и сформировали в результате субкультуру хипстеров-фрикциональщиков, которые сами не знают, чем хорош их Х-ль, а просто самоидентифицируются по принципу "мы не такие как все". типа готы от программирования, ага.
>Как раз Хаскель, в отличие от Скалы, развивается гармонично, потому что там за дизайном следят. Чем Дотти может быть лучше Хаскеля, я вообще не знаю.
Вот не знаете, а говорите, замечательно.
Проблема Х-ля в том, что в него напихали овер дохуа расширений системы типов, которые в совокупности не консистентны. В результате в скомпилированном коде местами невозможно обойтись без динамической проверки типа. Соответственно, есть примеры кода на Х-ле, который тайпчекает статически, но выдает ошибку типов в рантайме. Если вы об этом не осведомлены, то сожалею. И чем это отличается от JS, например? Так что современный Х-ль не лучше JS, а его фанбои - не лучше JS-макак, даже если они привыкли возносить молитвы статической типизации. Х-ль 98 был торт, а нынешний уже нет.
Теперь посмотрите на Дотти. В ней специально урезали ситему типов, чтобы достичь гарантированной консистентности. Она типобезопасна не хуже System F, она никогда не выдаст ошибку типов в рантайме.
Получается, что Скала за это время наверстала упущенное, зато Х-ль деградировал.
>И unsafeCoerce и другие unsafeSomething не считаются
эта новость стара, как мир, и про нее не слышали, наверное, только сами Х-листы.
https://migmit.dreamwidth.org/39346.html
но проблема не только отдельном в примере такого кода.
вопрос глобальный - как может возникнуть рантайм ошибка типов, если язык со статической типизацией? а он не совсем со статической, лол.
проблема в том, что система типов на поверхности языка отличается от системы типов внутри (Core). как следствие, статические гарантии высокого уровня отличаются от реальных гарантий скомпилированного кода. как следствие, компилятор в некоторых случаях ВЫНУЖДЕН вставлять динамическую проверку типа там, где гарантий Core не хватает. в результате код выполняется частично как динамически типизированный. это будет с любым кодом, содержащим некоторые сочетания расширений. а поскольку анон в своем коде будет использовать 100500 библиотек, которые используют 100500 расширений, то результат всегда будет такой.
с JVM точно такие же проблемы, если что.
но Дотти хотя бы не допускает глюков на верхнем уровне языка.
Твоей ссылке 8 лет, с тех пор появились type roles и этой проблемы уже нет.
То есть ты вообще не в курсе куда и как развивался Хаскелль за последние годы, но кукарекнуть про несовместимые расширений и райнтайм ошибки типов надо, да.
Иди нахуй с таким уровнем аргументов обмудок тупой
Хочу вкатиться в скалу и работу. Чё посоветуете?(кроме самовыпила)
>рантаймы для JVM и JS позволяют строить высокопроизводительные системы с удобным доступом к огромной экосистеме библиотек.
>Q: Какие либы НЕ брать?
>A: play, izumi, tofu, джавовые фреймворки
Как вам живётся с такой шизофренией?
>Т.е. все эти штуки тебе предлагают просто красивую семантику
Не просто. Эта семантика дает универсальные протестированные блоки, который в каждой твоей программе будут работать одинаково. Так же как ты не пишешь свои коллекции и используешь не циклы для операций над ними, а высокоуровневые комбинаторы, теперь ты можешь работать с асинхронными вычислениями. И это очень сильно отличается от
>от того, как бы ты это делал на Джаве
потому что аккуратно чекать флаги в цикле и прерывать вейты очень непросто. Люди все время off-by-one ошибки допускают, а ты про wait говоришь.
Разбираться что дает cancel в разных абстракциях нужно, но это часть понимания семантики. Разобраться с особенностями реализации нужно чтобы понимать какие проблемы с производительностью могут быть или как обойти уже существующие.
>кодить по хардкору
>самые высокопроизводительные приложения
High-load это спектр. На биржах, где тебе нужно вкладываться в миллисекунды, люди кодят по хардкору и выжимают все из железа. В каком-нибудь сервисе на 100к запросов в секунду тебе уже нужен асинхронный IO, но еще можно позволить себе променять быстродействие на четкую семантику библиотек.
https://techcrunch.com/2021/01/28/fintech-darling-nubank-raises-blockbuster-400m-series-g-at-25b-valuation/
Бразильский клон Тинькофф-банка гребет баксы самосвалами и зогхватывает мир. А в чем отличие? Да только в том, что Тинькофф-бэкенд на сабже, а нюбанк - на кложе+датомик.
Передайте этот пост Олегу, это очень важно.
> что люди в этом фп, решают вообще не те проблемы, которые решать важно
Есть разные виды проблем, и все они важные, и все так или иначе решаются во всех языках.
1) Проблемы программирования (сюда же входят проблемы порожденные языком или парадигмой). Сюда относятся библиотеки-улучшения стандартной библиотки (думаю есть в любом языке, в джаве это например apache-commons или guava, в скале - cats/zio), разработка библитек для уменьшения боилерплейта (lombok в джаве, shapeless в скале), а также разработка паттернов использования языка (в ООП это практически неформализуемо в виде библиотке, поэтому эти подходы изложены в GoF и других книгах по OOD, в ФП их частично можно выразить тайпклассами). Поскольку скала с ФП позволяет создавать намного более высокоуровневые абстракции, в ней есть больше библиотек для этих проблем, и это хорошо потому что в других языках эти проблемы есть, но их каждый раз нужно решать заново.
2) Инфраструктурные проблемы - хадупы, брокеры и все остальное. Это прямо пропорционально возрасту языка и количеству программистов на нем. Еще нужны библиотеки для взаимодействия со все этим добром, асинхронщины и сериализации и всего остального (вот они в скале есть). Кроме того, скале зачастую не нужны свои инфраструктурные библиотеки - netty работает отлично, хадуповские классы используют из спарка и т.д. Можно сразу использовать язык для
3) проблем бизнеса. Тут-то для написания поддерживаемого кода тебе и приходят на помощь наработки из п. 1)
> 3) проблем бизнеса. Тут-то для написания поддерживаемого кода тебе и приходят на помощь наработки из п. 1)
Тем не менее туча бизнесов как работали на императивных языках так и работают, а функциональные языки им только проблемы создают с их способностью писать высокоуровневые абстракции и невозможностью из-за этого масштабировать команду и заменять в ней людей. Само ФП создает не только проблемы для программистов, которые они решают абстракциями, так и бизнесам, которые пытаются людей обучать ему, если уж попали в ФП. А обучить человека хреначить на скале\хаскеле дело хлопотное и у него должна быть изначально предрасположенность к этому, иначе его просто не убедить, что ФП - это полезно.
Ну и вообще за 20 лет можно было бы кроме библиотек с тайпклассами хотяб ide сделать, которая не краснит. Про билд тул у меня такое же впечатление, но с ним я скорее всего не разобрался пока нормально.Тоже дополнительные проблемы.
>как работали на императивных языках так и работают
Это так себе аргумент. Если что-то работает это не повод не совершенствовать подходы.
>функциональные языки им только проблемы создают с их способностью писать высокоуровневые абстракции
Обычно в бизнес-коде тебе не нужно писать свои абстракции. Ты просто используешь то что тебе дают библиотеки. Если тебе понадобилось накручивать что-то свое сложнее функций типов данных, то или у тебя действительно сложная задача, или ты занимаешься оверинжинирингом. Последнее регулярно происходит и в ОО-языках (а может и чаще, потому что в них свои абстракции нужны всегда из-за невыразительных библотек), но там как-то уже научились в этом обвинять людей, а не инструменты.
>невозможностью из-за этого масштабировать команду и заменять в ней людей
Проблема масштабирования существует, но думаю она связана не с абстракциями, а именно с тем что есть масса людей уже обученых процедурщине (я видел буквально пару людей, умеющих в ООП).
>у него должна быть изначально предрасположенность к этому
Не знаю что за предрасположенность, но действительно для того чтобы начать разбираться в ФП и его плюсах нужно любопытство какое-то, чтоли. Или нужно просто подольше пожрать говна со стандартными подходами и в какой-то момент увидеть что можно-то по-другому.
> Про билд тул у меня такое же впечатление
Да мавен используй и не еби мозг. Можешь еще mill попробовать, он как раз из-за усталости от sbt сделан.
Вот думаю что пора отстраняться от JS и попробовать какой-то язык посерьезнее, с большим упором на ФП и с возможностью переката поэтому Хаскель не хочется рассматривать чисто из практической точки зрения. Стоит ли в Скалку вкатываться? Подводные камни? да, я хочу услышать позитивные ответы в Скала треде от скалистов
Другой вариант, который мне кажется реалистичным, это Эликсир.
Стаж 4 года, работаю на фронте и есть опыт работы на беке Руби.
Анон, ты как и многие опять поддаешься на провокации местных борщехлебов. ФП - это не тайпклассы и ебля монатками в очко. ФП - это тупо референциально транспарентные функции и иммутабельные данные. Когда у тебя у композитных объектов такая же семантика (эквивалентность, изменямость), как например у чисел. х = 2, потом х = 3. Икс изменился, а число 2 как было числом 2, так и осталось. И теперь генерализируй эту семантику на бизнес-объекты. Все, в этом и заключается ФП. Это уже лет 10 как common wisdom, что с такой семантикой в общем случае работать проще. Все новые языки и технологии(!) ориентируются на нее по дефолту. Вот и все, это и есть ФП. В расте фп, в джаве фп. Везде фп. Кроме тех мест, где оно дает большой оверхед по памяти\производительности, т.е. там, где надо ебаться в байтики. Но иногда и там можно.
А то, что местные фанатики тебе рассказывают - это на 20% полезные, но не критичные штуки (дело вкуса), а на 80% - маркетинговый буллшит и бойлерплейт, потому что тут так принято.
Добра, анон!
>референциально транспарентные функции
А как ты будешь соблюдать чистоту в языке с сайд эффектами без монад, или ещё чего ядрёнее типа афинных/линейных типов, что именно должно тебе поможет позволить изолировать чистую часть программы от сайдффектной на уровне типов, если не это?
пора бы уже начать пиздить за использование лингвистического термина reference transparency применимо к программированию, где он полностью теряет смысл
>А как
Просто и без задней мысли, я же не шизоид с ОКР.
>reference transparency применимо к программированию, где он полностью теряет смысл
Бред. Лень объяснять.
В любом случае, я свой пост адресовал конкретному анону, а не местным господам борщехлебам. Не вижу смысла устраивать очередной унылый одинаковый срач, кому-то нравится арбуз, кому-то - свиной хрящ. Я просто довел до анона информацию, что фп != борщи.
>Просто и без задней мысли, я же не шизоид с ОКР.
Ясно, то есть никак.
>Бред. Лень объяснять.
https://stackoverflow.com/a/9859966
>Я просто довел до анона информацию, что фп != борщи.
Это называется дезинформация.
Если ФП - это ФВП, замыкания + парочка стандартных комбинаторов, то 95% менйстрим программирования это ФП, даже пхп.
Но если ты уж начал говорить про чистоту, то нормальная система типов, позволяющая сэйвово разделить чистую программу и эффекты есть лишь кое-где и является тем, что ты определяешь как "борщи".
>>1926619
Челик начинает вкатываться в ФП, видит некоторые полезные для себя вещи и некоторые непонятные.
Но вместо того чтобы продолжить разбираться в мат.части, он решает для себя что есть "ФП" а есть ненужные "борщи", ведь проще назвать кого-то борщехлебом и смишно пошутить про "монады в очелло", чем пытаться найти профиты в "борщах".
>>1925652
>>1926619
Профиты "борщей" я понимаю, но всё-таки насколько в целом парадигма сильнее императивного подхода я понимаю только в теории. Планирую пописать какой-нибудь велосипед на скале/хаскеле, чтобы все-таки иметь какой-то опыт к чему-то приближенному к реальной жизни, пока я только книжки читал, да курсы проходил, там упражнения конечно показывают полезность ФП, но все это выглядит как что-то вырванное, отдельное.
Всем спасибо за ответы.
Не знаю, что в словах "мне неинтересно в очередной раз иметь тот же самый срач с юным адептом борщей" тебе непонятно.
>>1926645
Вообще мимо.
>>1926701
Для души бери х-ль и кложу\эликсир, чтобы ощутить все грани. Скалка объективно неактуальна, а чисто для изучения подхода в ней слишком много семантического шума.
>Местная истеричка все еще детектит меня в каждом втором посте
Смешно.
Антон Де Гузло
в sbt у меня два таргета:
lazy val lib = (project in file("."))
lazy val app = (project in file("app"))
.aggregate(lib)
.dependsOn(lib)
app зависит от lib
в app я при помощи runtime рефлексии хочу создавать классы из lib.
для этого думаю заюзать ClassFinder
import org.clapper.classutil.ClassFinder
val finder = ClassFinder()
finder.getClasses()
если выполнить данный код в lib, то все ок, я вижу классы определенные в lib
если выполнить этот код в app, то я не вижу классы из lib.
Что в sbt поправить, чтобы классы из lib так же были видны?
>в app я при помощи runtime рефлексии хочу создавать классы из lib.
1) Не страдай хуйней (рефлексией), а лучше опиши что именно ты хочешь сделать с точки зрения бизнес-логики. Скорее всего есть вменяемое решение без рефлексии или на крайняк либа которая уже это делает за тебя.
2) Словами описывать такие проблемы бесполезно. Чтобы хотя бы надеяться на помощь, кидай проект на гитхабе.
>лучше опиши что именно ты хочешь сделать с точки зрения бизнес-логики.
Вот тут чел описывает ровно ту проблему, которую я пытаюсь решить - https://stackoverflow.com/questions/27756064/java-register-available-classes-to-list-automatically
У меня конечно не монстры с пауками, но суть та же. Хочется иметь возможность просто добавлять новые классы, а приложение, которое бы эти классы использовало - чтобы само узнавало об их сущестовании ( например по специальным аннтоациям или еще как, не суть важно )
>2) Словами описывать такие проблемы бесполезно. Чтобы хотя бы надеяться на помощь, кидай проект на гитхабе.
Да, видимо придется чет такое сделать
https://news.ycombinator.com/item?id=26102358
Закрывайте тред
Поздравляю, скаланы! ДелиМобиль наконец-то съехал со Скэйли и все переписал на Kotlin + Arrow. Теперь компания не в опасности!
Пикрил счастливый адоптер Arrow.
>Почему ты решил вкатываться именно в scala? Ты джавист?
Чел, ты только не ври окружающим, окда? Даже помоечный динс воротит нос от перекатщиков и требует коммерческий опыт от 2 лет на скэйле. Что уж говорить о тиньке или райфе, которые такой анал-карнавал устраивают на собеседовании, что закачаешься. Они также требуют коммерческий опыт от года на скэйле. И да - пердоленье спарка не считается за скэйла опыт.
Интересуюсь Скалой и ФПхой вообще. Я яростно не люблю ООП классическое, программирую на Go. До этого писал на крестах.
С джавой не знаком вообще, знаю что рефлексия есть. На спринге в шкале один диплом делал.
Вопрос, можно ли вкатываться в скалу не залезая в этот явовый стек вообще?
Да, можно. Это в котлин без джавы не вкатишься. А в скэйле своего добра полно и можно обойтись без знания джавы. Только учти, что IDEA (единственная IDE, которая худо-бедно работает со скэйла) нещадно краснит код и отжирает просто гигабайты памяти и загружает твой процессор до отсечки.
Это норм подход - https://ideone.com/Fu1mXc ?
Где вообще почитать про дизайн и best practices при создании пользовательских библиотек в scala ?
Верно ли я понимаю, что Cats для либералопедерастов-SJWшников, а ZIO для правильных пацанов?
1) в scala for comprehension всегда транслируется в вызовы map, flatMap, и withFilter, правильно?
2) map ( и flatMap ) на выходе создают новую коллекцию. Если новая коллекция не нужна, то предполагается вызывать map либо у iterator либо у view, правильно?
Соответственно вопрос:
Следует ли из пункта 1) и 2), что в for comprehensions стоит использовать iterator или view для того, чтобы избежать overhead'а от создания ненужных новых коллекций при вызовах map и flatMap
т.е. что-то типа
for{
x <- xs.iterator
y <- ys.iterator
} yield x + y
Или это все не нужно и никакого оверхеда не будет?