Comments 52
Имхо, Scala хорошо развивает мозг и позволяет обогатить себя как профессионала за счет изучения новых подходов и принципов.
Но как язык промышленного программирования я бы не стал его использовать. Когда работаешь в команде понимание кода других участников может быть затруднительно, даже если вы более менее согласились с тем что и как будете применять. Разработка на Scala даёт много вольностей и возможности написать сложный для понимания код. Чем любят заниматься люди с целью повышения своего ЧСВ.
Сама Scala мотивирует активно думать над тем что бы писать выского абстрактный код и постоянно планировать абстрактную архитектуру. Что ни как не помогает быстро и качественно решать задачу а скорее подобно творчеству. А когда эта абстрактная архитектура написана кем то другим понять её зачастую затруднительно, хотя задачи которые она решает могут быть достаточно простыми.
Так же такую сильносвязанную абстрактную архитектуру сложно рефакторить. Потому что хоть она и должна быть отстранена от прикладной задачи(суть абстракции), в реальности основана на решаемой задаче, а новые задачи(бизнес требования) могут требовать существенных измений в коде для поддержки его согласованности или костыля, что обычно и происходит, со временем сильно ухудшая понимание кода.
По этому я начал искать другие языки которые позволяют писать быстро и качественно. Остановился на Clojure и очень доволен, язык соответствует тому что я хотел найти — быстро писать качественный код.
Спасибо за интересную причину не использовать на проде скалу, мне повезло работать в командах где с этой проблеммой не сталкивались, и ваш взгляд помог посмотреть немного под другим углом.
Имеющийся у меня опыт, подсказывает что на Java гиганты мысли могут написать вещи не менее страшные, ЧСВ ради, и сложность кода довольно часто не про язык а про уровень инженерных практик.
У нас, например, поощряется писать более простой код, хоть иногда и чуть больше, а иногда и чуть продублировать.
Apache Spark со своим style guide пример как огромное количество котрибьютеров с разным бэкгроундом может работать над одной большой кодовой базой
Twitter — отличный пример из индустрии, избегающий все упомянутые высокоабстрактные архитектуры и продолжающий с успехом использовать Scala
Twitter и т.п. гигантов, на мой взгляд, приводить в пример некорректно, у этих компаний практически неограниченные бюджеты по сравнению с рядовой конторой на постсоветском пространстве. Бюджет "разглаживает" почти все проблемы.
Некоторые оптимизации которые дает язык, в виде различных асинхронных моделей построенных на акторах, не нужны в 99% проектов. Как минимум в начале роста самого проекта, они даже вредны потому что заставляют продумывать то что пока не имеет смысл — рост нагрузки.
Уменьшение бойлерплейта даётся за счет усложнения кода, если взвесить это, возникает вопрос что лучше, нужно отталкиваться от проекта.
Уменьшение бойлерплейта даётся за счет усложнения кода, если взвесить это, возникает вопрос что лучше, нужно отталкиваться от проекта.
Такой довод можно использовать к споре о необходимости генериков в Go 2.
Scala это не только страшные картинки которые показывают в интернете с плохочитаемыми символами, это еще и компактный лаконичный язык на котором можно писать с использованием JVM окружения.
К слову, akka и аккторы не входит в стандартную библиотеку Scala. Возможно, они просто самые популярные.
Если в команде анархия и нет ни ревью, ни guidlines, нет способа рассмотрения и принятия архитектурных решения, то что-то не так в царстве датском.
Очень странная метаморфоза произошла с Typesafe.
Вообще, по моим ощущениям, примерно с того же времени в Scala начался какой-то застой. Если тогда появление Kotlin выглядело забавным, то сейчас выглядит так, будто новый JVM проект и в самом деле стоит начинать на Kotlin. Потому что действительно better java, а не wannabe haskell, со всеми вытекающими.
то сейчас выглядит так, будто новый JVM проект и в самом деле стоит начинать на Kotlin
Если у команды нет опыта на Scala, то может и стоит. В противном случае если есть экспертиза я не вижу смысла мигрировать на Kotlin.
Я вижу большую проблему адаптации Scala с нуля, с очень большой фрагментацией подходов и стилей библиотек. Но если у команды есть обозначеный путь и политика в отношении выбора, то разработка становится очень продуктивной и сильно превосходит Kotlin с его пока еще неразвитой экосистемой
Согласен.
Я вижу большую проблему адаптации Scala с нуля, с очень большой фрагментацией подходов и стилей библиотек.
К этому могу добавить только то, что сообщество у Scala и значительно более скромное в размерах, и по ощущениям действительно чаще чем хотелось бы снобистское. Особенно это заметно когда перепрыгиваешь совсем на другой, более распространённый стек технологий.
Но я считаю, что именно Scala, а не Kotlin, по-прежнему заслуживает такого звания. На то есть две основные причины:
Во-первых, неизменяемость в языке Scala первостепенна. Это связано с природой Scala как таковой: писать на нем код удобно прежде всего при помощи неизменяемых данных.
А чем иммутабельность в Scala отличается иммутабельности в Kotlin?
При этом насыщенная система типов полезна не только при написании кода, но и, в гораздо большей степени при чтении кода. Когда тебе легко сориентироваться в базе кода, понять, что он делает, а, к тому же, не страшно (или не так страшно) браться за его рефакторинг, это очень положительно характеризует язык как с технической, так и с прикладной точки зрения.
Вот! Идеально объясняет почему C# у меня вызывает такое чувство обескураженности при подходе к любому проекту где уже потрачены сотни человекочасов, а с F# все проходит легко.
Не могли бы вы раскрыть мысль? Я правильно понял что Scala которую разрабатывают с 2004 года украла систему типов у Цейлона который разрабатывают с 2011? Или украдет в Scala 3.0?
У меня плохая память и даты я взял из википедии.
Не знал, что Одерски 14 лет пилил встроенные html-тэги, в ожидании пока освободится единственный на планете человек, который знает что такое типы-пересечения и -объединения с наследованием… Но слава богу, что через 14 лет ожидания он наконец освободился и смог запилить все необходимое для скалы.
Вся информация тут. Не надо выставлять человека уж совсем идиотом.
Я не могу себя причислить к скала сообществу, потому что я не работаю с этим языком на постоянной основе. Но приходилось писать несколько проектов в прошлом на базе Play Framework. Перед этим я прошёл вводный курс по скале на курсере (который опять же ведёт Мартин). От этого языка всегда веяло какой-то академичностью — такое ощущение, как-будто его с интересом и любовью препарировали в стенах университетских лабораторий :) Я, кстати, не припомню, чтобы это кто-то скрывал.
И вот появился этот монстр, в основе которого JVM с своими возможностями и ограниченями, на которое сумели взгромоздить и FP и OOP, подружив их друг с другом, и доселе невиданную систему типов (я честно не знаю, украли ли они её у кого-то или сами придумали) и ещё бог пойми чего и всё это ещё и под соусом обещаний интероперабилити с java, type-safety, иммутабельности и т.д и т.п. Иронически, получился швейцарский нож. Университет EPFL, в котором преподает Мартин, так же находится в Швейцарии (Лозанна) :)
И вот тут уже конечному разработчику решать, как с этим многофункциональным ножом играться. Если юзать его аккуратно, как better java, оно, на мой взгляд, довольно хорошо работает. Писать на скале, как на улучшенной джаве действительно удобно и приятно. Прагматично? Ну, возможно.
Но можно заиграться и перерезать себе все руки (прежде, чем отстрелишь ноги) — любой обфускатор позавидует. Концов не соберёшь — в какой-то момент сдавался даже IntelliJ Idea для скалы. Отдельно радует SBT, в котором есть операторы, которые даже загуглить нельзя. :)
P.S. Я потом ещё прошёл курс по реактивному программированию на базе скалы — это просто взорвало мой мозг.
www.artima.com/scalazine/articles/origins_of_scala.html
Тут есть некоторые пояснения :)
Интересно, насколько корнями Scala уходит в самую первую Java и ранее. И как сама Scala, которая частично «базировалась» на малоизвестных Funnel, Pizza, в каком-то даже смысле опережала развитие Java на тот момент.
Вот кстати из моего наскального опыта, использовать scala как better java — это в самом деле дорога в никуда. Язык действительно достаточно хорошо заточен на то, чтобы возлюбить FP, FRP, иммутабельность. Правда в какой-то момент надо научиться понимать во что это всё хотя бы примерно компилируется, но тем не менее.
Не знаю с каким сообществом Вы боритесь, при мне никто таким не занимался, никто под ковер ничего не заметал.
Одна из сторон прагматичности в моей работе со Scala — количество ваканский, уровень зп и достаточный уровень сообщества для решения проблем.
А можно подробнее про этого человека? Возможно у него есть имя? Было бы интересно узнать.
А и в самом деле интересный товарищ http://www.cs.cornell.edu/~ross/
Спасибо
Вы по всей видимости говорите о Ross Tate который ведёт свою научную деятельность с 2010-го года. Его работа наверняка повлияла на Цейлон, Скалу и Котлин,
Однако Intersection и Union Types были изобретены (открыты?) и изучались задолго (эта статья 1995-й года и есть ещё более ранние) до работ Росса, и появлялись во многих экспериментальных языках. Изучать эту тему мог кто угодно, в том числе и Росс, и Мартин, и другие учёные.
Сама же Scala 3 базируется на компиляторе Dotty, основой которого является исчисление Dependent Object Types. Обоснование этой системы типов выполнено в-основном аспирантами Мартина (Nada Amin, Samuel Grütter, Tiark Rompf и Sandro Stucki). Intersection и Union типы являются частью DOT и используются для описания наименьшей верхней границы (least upper bound) для if- и match- выражений.
Так что 14 лет для построения компилятора, поддержки и развития ветки Scala 2, переосмысления ошибок, создания новой системы типов и доказательства её корректности, построения нового компилятора Dotty и использование его как бэкенда для языка Scala — вот для всей этой работы 14 лет для меня не выглядит сильно уж большим временем.
Можете проговорить, что вы считаете успешным тулингом в цейлоне?
В рамках дисскусси стало интересно разобраться.
Раз мы так далеко отошли от темы, я позволю себе задать вопрос, который может показаться провокационным, но мне интересна ваша точка зрения. Почему на stackoverflow по поиску работы с ключевым словом Ceylon 0 результатов, а Scala — 115. И где мне начать писать за деньги, если я решу бросить Scala\Java\Kotlin и переползти на Ceylon ?
Приведу ссылки дабы не казаться голословным.
https://stackoverflow.com/jobs?q=Ceylon
https://stackoverflow.com/jobs?q=scala
Зачем человеку Скала? Повыпендриваться и поразминать мозг — да, но уж точно не упростить себе жизнь.
Имею опыт внедрения скалы в продакшене (чего, как мне кажется, нет у большей части горячих фанатов этого языка). Начиналось это как небольшой вебсервис почти без бизнес-логики (перекладывал объекты из одного апи в другое), поэтому решил немного поэкспериментировать, так как это казалось безопасным. Разумеется пару лет спустя оно переросло в здоровенный сервис и обросло кучей фич. Никогда такого не было и вот опять, да. И началась боль.
И дело даже не в том что писать на скале сложно, как язык она мне скорее нравится чем нет. Но вот поиск сотрудников под это дело… он непрост. Далеко не все разделяют мое желание изучать этот язык и переезжать с джавы. Новых сотрудников на скалу фиг найдешь, а если и найдешь — то за очень высокий ценник.
Ковыряться в библиотеках — то еще удовольствие. Тут не работает вариант "использовать то что нравится, а всякую сложную хаскеллеобразную муть не использовать, если не хочется". Потому что разработчики библиотек зачастую придерживаются другого мнения, и их апи представляет густо замешанную смесь из монад, функторов, имплиситов, присыпанных всякими scalaz-штуками, от которых у меня глаза кровоточат когда я пытаюсь понять, что это все значит.
В итоге столкнулся с тем, что:
- Профессиональных скалистов взять негде
- Профессиональные джависты не горят желанием менять джаву на скалу. Раньше еще можно было убеждать всякими красивыми фишками, но после выхода 8 джавы с лямбдами и стримами число фич, ради которых стоило бы учить скалу сильно сократилось. А многие из колеблющихся сделали выбор в пользу Котлина, который красивее, проще и интероп с джавой легче делается
- Написание кода сильно замедляется без какой-либо выгоды для бизнеса, так как приходится курить мануалы и страдать при попытке лазать в библиотеки
В общем никому не порекомендую повторить это. Если у вас нет команды звезд ФП, то никакого профита с переезда на скалу не получите, только боль.
На хабре уже когда-то был перевод статьи на эту тему https://habr.com/post/273535/, могу в целом подтвердить со своего опыта что так оно и получается.
Конечно всегда можно сказать, что это мы (и команда в статье по ссылке) сами дураки и просто скалу готовить не умеем. Ну ок, может и так. Но возможно именно поэтому (что все вокруг дураки, не умеющие готовить) скала взлетает-взлетает уже пятнадцать лет, а так взлететь и не может, и я думаю с появлением Котлина сдаст еще часть своих позиций.
Имею опыт внедрения скалы в продакшене (чего, как мне кажется, нет у большей части горячих фанатов этого языка).<
Интереса ради, не споров для — а где Вы с фанатами Scala общаетесь ?
P.S.
Был перевод на хабре, о том что сам Одерски считает успехом не 1000 сервисов на Scala а Spark и Kafka.
Плюс пару раз общался с адептами ФП (не скалы) в реальности, там примерно то же самое — яростная концентрация на инструменте, а не на решаемых задачах.
Ну а Одерски считать-то может что угодно, его мнение к тому же вряд ли можно считать непредвзятым. История показывает, что сейчас зачастую даже изначально скала-сервисы постепенно возвращаются к джаве (подтягивают апи, документацию в джава-части), видимо какое-то определенное разочарование наступило.
На хабре довольно редко бывают статьи о Scala, в сообществе это настолько редкий источник информации, что мне довольно интересно кто сюда забредает. Те люди с которыми я общаюсь в интернете намного приятнее описанных вами.
Надеюсь сообщество хабра меня простит за постоянную рекламу, но доклад который я приложу ниже очень просто объяснил для меня плюсы функционального подхода на продакшене, и как он помогает решать проблеммы бизнеса
Если инересна тема, то можно почитать книгу Paul Chiusano and Runar Bjarnason, Functional Programming in Scala. Сам я ее еще не прочитал, только собираюсь, но слышал пложительные отзывы, как о хорошем введении в ФП. Она не является учебником по Scala, там лишь присутсвуют минимальные уточнения к коду и отсылки к документации, чтобы примеры были хоть как-то понятны и тем, кто Scala не знает, так что лучше ее читать будучи уже знакомым со Scala.
Красноая книга топ !
Мы очень надеялись и продолжаем надеяться, что Пол обновит эту книгу
Вот эта тоже крайне хороша
https://leanpub.com/fpmortals
Проблема в том(говорю о ссылке на доклад) что асинхронщина не нужна в 99%, и не дает какого то существенного увеличения производительности на среднем проекте тем более что её ещё нужно понимать чего нет у рядовых специалистов.
По этому все подобные плюсы перевешиваются минусами в сложности поиска сотрудников, потраченном времени на "идеальную" абстрактную и асинхронную архитектуру и её рефакторинг.
Зачем человеку Scala?