Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Есть ли желающие Джависты перенять опыт Scala разработчика?

Всем привет. У меня 4 года опыта на Scala. Недавно я для себя понял, что хочу поделиться с другими Java разработчиками своим опытом в изучении Scala.

Я сам когда-то пописав на Java 3 года, начал испытывать определённую боль от одних только взглядов на код. Тогда мне на глаза попалась Scala и я начал изучать. Язык очень понравился, но хотелось получить опыт в настоящем проекте, узнать best practices использования той же Akka, sbt, Play. Понять правильно ли я использую язык.

И вот сегодня у меня есть хороший опыт на Scala и есть желание поделиться таким опытом с ребятами, которые сейчас как я когда-то, пишут на Java и хотят расти дальше в карьере, научиться новым интересным технологиям. Если такой интерес есть, напишите здесь или мне в ФБ. Я хочу понять ценно это людям или нет. Спасибо.

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному0
LinkedIn

Схожі топіки

Найкращі коментарі пропустити

И вот сегодня у меня есть хороший опыт на Scala и есть желание поделиться
Я хочу понять ценно это людям или нет.

Если у вас есть желание поделится, то какая вам разница насколько это ценно другим людям.
Ведите блог. Напишите пару статей на ДОУ. Выступите на паре конференций.
Кому-то да пригодится.

хорошая попытка, но — нет

Людям ценно понимать сферу коммерческого применения этой самой Скалы.
Пока же я вижу её полное фиаско. Сам на ней писал какое-то время, и отказался. Уж сильно паршиво читается код. И вот эта, как ты выразился, «определённая боль», и оказалась критическим фактором.

Тот случай, когда синтаксический сахар — совсем не сахар.

Был тут уже некто Иван Головач, познавший Scala на уровне, недоступном для 90% простых смертных...

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Троллинга ради отвечю на коммент из фп топика в контексте риал лайф скалы тут.

1) как обстоят дела с вливанием новых людей в команду?
2) как обстоят дела с поддержанием старого кода?
3) на что похож ваш функциональный язык?
4) у вас выработались какие-то best practise и code styles для вашего языка? что такое «красивый функцилнальный код» по вашему мнению?
5) было ли у вас чувство — а вот с этой задачей отлично бы справился ООП подход?
6) есть ли у вас метрики, что подтверждают "

высокое качество своего продукта и поддерживать его в соответствии с требованиями
" или это интуитивное чувство?
7) если бы вы писали проект с нуля сегодня — какой язык/платформу бы выбрали?
8) возникали ли вопросы с оптимизацией функционального кода?

1 — никак. Чтобы из императивщины перучить на фп нужны годы. Ну и 98% разрабов нехотять переучиваться, спорят и доказывают что ооп круче. Прозе уволить, и написать самому.

2 -необстоят. У фп настолько красивыие и изящные абстракции, что проще старый код выкинуть и перепивать все заново, чем вникать в полет мысли автора.

3 -на функциональный язык ?

4 -Да, главное это выравнивать стрелочки, опускать точки и скобки, обзывать переменные одной буквой, делать все чтобы код был похож на «красивый хаскель» ценою читаемости, перформанса и здравого смысла )

5 — ООП подход отлично бы справился с любой задачей. Вообще вопрос не в подходе — а в руках.

6 — Бабло покачто платять — чем не отличная метрика ?

7 -Конечно Го.

8 — Невозникали, фп неоптимизируемо фпринципе.

Я сам когда-то пописав на Java 3 года, начал испытывать определённую боль от одних только взглядов на код.

Братан, with all respect, но если ты, пописав, испытываешь боль, то надо драпать к врачам, а не терпеть три года... бо так пописалка отвалится, потом неудобно будет.

есть одна проблема с которой я уже сталкиваюсь с Java 8/9
это то что в индии да китае готовят погромистов которые и без функциональщины еле еле программируют, как им монадки обьяснять я вообще не понимаю
а дать им в руки скала — и деплоймент сломают и руки порежут :)

Не только в Азии, среди наших тоже много неосиляторов лямбд и консюмеров встречал

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

Почему тогда половина всех книг по Скала и околоскальным технологиям написана индусами? может они-таки начинают потихоньку осиливать. Не вижу такого же кол-ва книг от индусов по Свифту, Хаскелю, Сишке

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

Так скала в целом рассчитана на индусов, поскольку перегрузка всякими абстракциями имеет много общего с хинди и дальневосточными языками. А вот зато Go прост и минималистичен, как языки на основе латиницы, и тем самым более удобен для разработки и развития проектов.

минималистичен, как языки на основе латиницы

Поинтересуйтесь, как выглядят числительные в немецком. Ну или сколько времен во французском. Про минималистичность такого английского слова как daughter можете ещё подумать, где 8 букв на 4 звука...

Эту книгу не читал. Рекомендуешь?

зря вы так. У нас в команде самые шарящие скаловоды индусы.

А просто сделать доклад о Scala на JEEConf или XP Days религия не позволяет?))

чуть не купился...

если на JVM-язык посмотреть просто как на API к виртуальной машине,
но с другой стороны, со стороны машины, т.е. приложения,
то наверно получается интересная картина:
требуются писаки байт-кода, вменяемые и много.
А из какого языка будет процесситься байт-код, не суть важно для Машины.
Проблема в том, что писаки ленивы, и не хотят изучать иероглифы, монады и трахомуды.

Был тут уже некто Иван Головач, познавший Scala на уровне, недоступном для 90% простых смертных...

btw єтот добрый молодец деньги вернул терпилам слушателям курсов ?

Какие деньги? Курсы были стартапом, слушатели инвесторами, стартап прогорел, инвестиции возврату не подлежат.
Вот такой он мир стартапов и л̶о̶х̶о̶в̶ бизнес-ангелов, бессмысленный и беспощадный

в былые времена ангелы могли и ноги переломать в порядке не фиатной компенсации неудачных инвестиций. Но иван молодец, дождался до появления денег у не склонной к насилию публики для исполнения своих чарующих трюков :)

эх не тот нынче ангел пошел, поплакал на форуме и пошел дальше новые фреймворки осваивать)

а шо такоє ? курс на Udemy всього за 9.99$ ! налєтай, покупай !

Просто оставлю это здесь. :-)

Не могу назвать себя фанатом Scala.
Но скажу кратко и просто — если у Вас есть опыт использования и желание им делиться, то — делитесь.
Не сомневаюсь, что найдутся люди, которые с интересном его изучат и будут Вам благодарны.
Мне, к примеру, будет интересно изучить и посмотреть.
Только одна просьба/совет — думаю лучше делать сразу на Английском. Это даст Вам большое интернациональное сообщество, причем куда менее агрессивное чем тут.

Только одна просьба/совет — думаю лучше делать сразу на Английском. Это даст Вам большое интернациональное сообщество, причем куда менее агрессивное чем тут.

На английском какраз уже дофига материалов.

А на русском/украинском оно не надо так как :)

На английском какраз уже дофига материалов.

Опыт Scala-разработчика — это боль и кровь из глаз при виде типичного scala-кода, усеянного монадами и starship-операторами? Спасибо, такой опыт перенимать не хочется :)

Scala никому не нужна (за исключением монадирующих программистов). Все вменяемые разработчики давно отказались от Scala в пользу Go. Подробности в этом топике.

Вменяемые — это неосиляторы нескольких абстракций и алгебраической типизации (ака теория множеств, школьный курс математики)? Это звучит скорее как диагноз граничащий с профнепригодностью.

(ака теория множеств, школьный курс математики)

Для разработки на Go вам не потребуется осиливать не только что теорию множеств, но и таблицу умножения. Таким образом, решать задачи вы сможете без промежуточных лишних звеньев.

без промежуточных лишних звеньев

Таких, как мозг?

Как часто программистам приходится прибегать к теории множеств для решения повседневных задач? Исходя из личного опыта, уверен, что эта величина стремится к нулю (если исключить монадирующих программистов). Например, в последний раз я сталкивался с хардкорным матаном из теории множеств лет 15 назад, когда интересовался криптографией с открытым ключом. Теперь эти знания благополучно забыты за ненадобностью, что не мешает мне программировать.

прибегать к теории множеств
с хардкорным матаном

Иногда мне просто страшно за человечество.

Человечество спасут монадирующие программисты. Инфа 100%

Сдаётся мне, не будем мы никого спасать. Но выживем. Инфа 100% ;-) Просто другая эволюционная ветвь. Go-программисты же знают, что такое ветвь? Эволюция?

Просто другая эволюционная ветвь. Go-программисты же знают, что такое ветвь? Эволюция?

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

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

Инструментарий инженера-разработчика должен быть простым и понятным, как в Go, а не перегруженным бесполезными абстракциями, как в Scala.

Ну зачем всё так усложнять, достаточно же двух операций. Запоминать больше — моветон.

Инструментарий инженера-разработчика должен

Кому должен?

быть простым и понятным

Для кого?

бесполезными абстракциями

Это называется Computer Science.

Действительно, формошлепство и написание рестов-крудов не предполагает таких знаний

Интересно. Опыт у меня тоже есть, но пообщаться готов :-)

С «языками программирования» всё просто. Позволяет язык разбить проект на команду, хотя бы из 20 чел? Взлетит. Hе позволяет? Не взлетит.

Потому, не взлетала раньше (и не взлетит сейчас) всякая функциональщина. Но зато парят (и будут парить) всякие ооп.

Ну в целом у всякой функциональщины компонуемость выше, чем у ооп.

Если бы это было так — мир с 60-х программировал бы на Лиспе.

Прямо вот даже не знаю что ответить, ели мсье не знает о проблемах производительности лиспа на заре мироздания, когда компьютеры были большие, а программы — маленькие. Ну, во-первых, это так и есть (см. десятое правило Гринспена). А во-вторых: чтобы было очевидно, что это так, и не иначе, достаточно знать матчасть, слишком толсто.

Тогда программки были маленькие — и Лисп даже в тех условиях «наколенной писанины» не взлетел. С чего бы функциональщине взлететь сейчас, когда программы стали большими?

С того, что проигрыш в производительности у всякого фп уже особо не проигрывает, а зачастую и выигрывает при при прочих равных человеко-часах за счёт высокоуровневой оптимизации. И всяко меньше затрат того же jvm. Плюсов же масса — от ухода от недетерминированных состояний, и постоянного стреляния себе в ногу, и бесплатной многопоточности из коробки, до лучшей модульности. Вопрос не зачем, вопрос — когда уже, наконец, а то, право, стыдно же как-то. Все элементы ООП можно рассматривать, как частные, очень неуклюжжие случаи ФП (обратное не верно). Зачем отказываться от эскаватора для рытья троншей, предпочитая лопату за то, что с ней — «быстрее» и не надо ничего учить? Почему же сейчас везде ООП? По той же, что и qwerty и горизонтально смещённые ряды на клавиатуре. Стандарты, обусловленные техническими ограничениями позапрошлого века.

ООП подход — соответствует человечeскому способу решения сложных проблем (анализ и синтез). Для того, чтобы мыслить функциональщиной — среднему кодерку нужно поставить мозги раком, потому, массовым явлением функциональщина в мире людей не станет. А соответственно, для мало-мальски средних проектов (где скажем, 5 кодерков и более работают над кодом) — функциональщина неприменима. Т.к. 1) таких кодерков не найти 2) замену им не найти тоже.

Но когда кодить начнут при помощи роботов — возможно, появится место и для функциональщины. Но то будут совсем иные реалии, где не будет места кодеркам. :)

Абсолютно согласен с тем, что языки программирования создаются для людей в большей степени, чем для машин, и должны учитывать имеющиеся когнетивные особенности и ограничения. И с этой т.з. все современные языки далеки от идеала, но некоторые чуть лучше. С другой стороны, если открыть метод любого класса — это же пошаговые инструкции, люди так не думают, они думают декларативно, описательно. Да, есть проблема с тем, что языки ML-группы черпали из языка математики, который далёк от читабельности и когнетивной простоты. Синтаксис может быть лучше. Но к синтаксису можно привыкнуть. К фундаментальному отсутствию абстрактности — нет. То же деление на когнетивные фреймы, что даёт ООП — запросто реализуется модулями, областями видимости и протоколами (они же интерфейсы, они же классы типов).

Про роботов и индуктивное программирование — очень интересная, но совсем другая тема :)

Игра терминами, где ООП не ООП. Но вообще да, под изысканной функциональщиной в том числе, понимается типизация Хиндли-Милнера, а под вульгарным ООП — традиционное императивное программирование с классами в духе Smalltalk или Java.
И да, система областей видимости — ортоганальна как типизации, так и декларативности.

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

под изысканной функциональщиной в том числе, понимается

чистые функции и инкапсуляция сайд-эффекта. Больше ничего в функциональщине не нужно. Остальное — от лукавого и оверхеда там больше чем пользы.

Почему же тогда все современные языки постепенно тащат в себя ошмётки алгебраических типов данных, например? Rust, Swift, Kotlin — то, что на поверхности. Сильная типизация вплоть до зависимых типов — тоже очень годно.

Я не дизайню эти языки. Возможно это просто коммерческие фичи чтоб нагнать хайп. По моему опыту — Scala без ScalaZ и котов гораздо лаконичнее, более понятна и несёт меньше шума. Да и вообще должны быть ну ооочень веские аргументы для того чтоб применять, скажем, free там, где можно использовать final-tagless подход.

Почитаю на досуге для общего образования, спасибо.

Эм, у меня прям когнитивный дисонанс случилсе.

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

Не в кассу. Знаю «что», не знаю «зачем».

Да и

там, где можно использовать

и

как круто

очень разные вещи.

Наверно, больше всего ньюфагов пугает частичное применение функций, с непривычки оно может тяжело читаться.

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

Да не может оно пугать. Просто на той же Java curry понятнее выглядит. lazy — тут другое. Тут уже с синтаксисом проблемы. Возможно это у меня с непривычки, возможно не только у меня, но часто наталкиваюсь на путаницу между

=> B
и 
A => B
. Как минимум пару раз было.

Підозрюю, що ці ж люди плутали б способи використання f і g:

object A {
  def f(): B = …
}
val g: () => B = …

:-)

В жабе и гадюке периодически этого не хватает

В Python не знаю, а в Java HOF выглядят примерно так

class MyFunction implements BiFunction<A, B, Function<C, D>>
Closure — точно так же, но ещё указав аргумент конструктора (нет, в Scala и Java8 стиле это делать плохо т.к. кложуры не инлайнятся и пересоздаются (не путать с чистыми функциями) по месту использования.
С lazy сложнее. Для lazy реализации передаётся функция от юнита и уже эта функция инвокается. Да, не проходит это так незаметно как в Scala, но уверен что наглядность того стоит.
Smalltalk или Java

Подавился. Сравнить строгую типизацию С++ для тупых и утиную типизацию одного из немногих ООП языков в изначальном смысле этого термина — это сильно.

А друг с другом их никто, вроде, и не сравнивает. Оба противопоставляются ФП.

Rather both modules depend upon a polymorphic interface.

Тайпклассы? Generic programming? Нє, не слышал.
Вцелом автор лишь подтверждает т.з. о том, что классическое ООП навязывает создание класса на каждый чих вместо банального применения обобщённой функции.

банального применения обобщённой функции

так мы не решаем обобщенную задачу. У нас задачи специализированы.

А паттерны проектирования как же, которые раз за разом «применяются» ввиду невозможности быть выраженными в абстракциях ООП, и предоставленными библиотекой, т.к. на преодоление ограничений этих абстракций и направлены.

Хотя, опять же, мы про статическую типизацию? Вывод типов? Замыкания? Иммутабельность? Декларативность? ФП — набор весьма ортогональных вещёй в целом-то. ООП — хак полувековой давности.

статическую типизацию? Вывод типов? Замыкания? Иммутабельность? Декларативность?

всё это есть и в ООП если его правильно применять. Например Scala as Scala, а не Scala as Haskell даёт возможность строить взаимодействие на контрактах, скрывая детали реализации в то время когда «присобачив», например, ReaderMonad ты expose-ишь во внешний клиентский код детали реализации, которые этому коду знать не обязательно. Тем самым завязываясь на эти детали реализации (внося coupling). Вывод: если без чего-то можно обойтись — то лучше без этого обойтись.

хак полувековой давности

не аргумент. ФП возрастом примерно такой же, просто только сейчас эти, описаные ещё в 60х-70х, концепции начали применять на практике.

всё это есть и в ООП если его правильно применять

и получится такая себе неудобная функциональщина, знаю, писал на Rx-whatever. Не знаю, что за проблемы с Reader, инкапсуляция — не исключительно особенность ООП. См паттерн smart constructor, например.

Тайпклассы

Пока никто так и не обьясних на#$@ оно надо?

1. Берёшь учебник
2. Читаешь
3. ...
4. PROFIT!

Been there, done that. Зачем, если я могу решить задачу без них?

Смотря о какой задаче речь :) Для большинства задач мне и компьютер-то не нужен. Добыть огонь там...

У меня есть набор данных A и набор данных B в разные моменты времени в одной и той же точке програмы. Мне нужно выполнить операцию foo(). Зачем мне применять ad-hoc polymorphism и открывать коду с каким количеством структур я должен выполнить foo() и изменять и перекомпиливать это место когда добавится новая структура, если я могу просто реализовать на них контракт что несёт foo() и выполнить её в том месте, а не писать

case A(aData) => fooA(aData)
case B(bData) => fooB(bData)

case A(aData) => fooA(aData)
case B(bData) => fooB(bData)

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

И импортировать его надо. А это не то же самое? Только имплиситы менее наглядны. Там больше «магии» и поди разбери какой имплисит инвокится. Не, пусть лучше Java-style многословно, но зато всё под контролем.
В случае ООП — мне просто нужно реализовать нужный контракт.

А это не то же самое?

Ран тайм вс компайл тайм, ну и вам нужно ручками каждый раз ваши кейсы во всех местах править. Если таких мест много — повод задуматься.

В случае ООП — мне просто нужно реализовать нужный контракт.

Ну если клас не в вашем ведомстве, например стандартный стринг, то нужно городить враперы итд итп.

Ран тайм вс компайл тайм, ну и вам нужно ручками каждый раз ваши кейсы во всех местах править. Если таких мест много — повод задуматься.

я же как раз против этого выступаю

клас не в вашем ведомстве, например стандартный стринг

именно по этому string-типизированые програмы — плохо и нужны value-objects.

поди разбери какой имплисит инвокится

зачем вы спорите о вкусе устриц, которых не ели?

поди разбери какой имплисит инвокится

Так ж IntelliJ IDEA по Ctrl+клік переходить до реалізації. Принаймні Ultimate Edition, але, думаю, Community Edition теж таке може. Чи малися на увазі combine під ++ і т. п.?

Поздравляю, вы открыли для себя Generic Programming. Хотя Type Classes для решения этой задачи в большинстве случаев хватит, когда не нужна интроспекция типа.
Ответ на вопрос зачем — ну, например, для гарантий, предостовляемых системой типов на этапе компиляции.

Опять таки, разрабатывая на контрактах (примитивы не в счёт — они на границах приложений, а там приложения не оо да и не функциональные тоже) у меня и так будет такая compile-time гарантия. Зачем? Что тайпкласс даёт такого что, как я уже писал, без него или совсем не получить, или на получение этого требуется уйма времени?

Контракт — это рантайм. Конкретное значение. Тайпкласс — это тип. Множество.

Не согласен. Контракт — это, например, реализация интерфейса. Ни разу не рантайм. Использование трайта в Scala. Не рантайм. Разница, как я вижу, то где лежат операции разрешённые/реализованые на этом множестве. В случае с тайпклассами и ad-hoc полиморфизмом операции лежат далеко от непосредственно данных.

Тайпкласс — это просто интерфейс. Может быть реализация по-умолчанию, но она будет использовать обобщённое программирование, т.к. ничего не известно о типе. Или можно использовать forall-тип, т.е. любой тип, для которого где-то реализован этот интерфейс. Иначе же система постарается вывести единственный конкретный тип, для которого определён тайпктласс. Я говорю о Haskell.

Специально для вас выучил Скалу :)
Принципиальная разница похоже в том, что тайпклассы добавляют реализацию поведения для уже существующих типов данных (в скале привет evidence имплисит-параметрам), а контракт — на этапе проектирования собственно данных (что потенциально может увеличивать ненужную связанность).

Пока никто так и не обьясних на#$@ оно надо?

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

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

тайпкласы сферические, а еще и типы высших порядков, моноиды с функторами

Вот мне и надо понять — где такая задача, что я (одно из следующих):

  1. не смогу её решить без этого всего
  2. решение этой задачи без всего этого займёт дикое количество времени
не смогу её решить без этого всего

Нету такой задачи. Любая задача может быть решена императивно.

решение этой задачи без всего этого займёт дикое количество времени

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

Вообще, после двух лет использования скалаз\катс в продакшене, могу с уверенностью сказать что основной плюс ФП это ваше возросшое до небес ЧСВ по факту понимания\использования всего этого. Все остльное одни сплошные минусы. А то что задвигают адепты фп, включая Юрия тут — балшит, который быстро рушиться об бетонную стену жизни.

Все остльное одни сплошные минусы.

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

Явного кода — да, меньше. Дофига имплиситов и магии. На столько что очень развита кодогенерация типа scala meta. Без неё бойлерплейта ещё больше чем в привычной Java. Понять какая строчка выполнится следующей (какой имплисит) просто смотря на код мало реально.
Подозреваю, что в свифте что в хаскеле точно так же.

Понять какая строчка выполнится следующей (какой имплисит) просто смотря на код мало реально.

Idea решает часть из этих проблем. Правда не все.

Бойлерплейта хватает. Но суть не в этом, когда работаешь с ральными системами, вдруг приходит понимание, что количество кода далеко не самая важная метрика. Читаемость, возможность дебажить в случае ошибок, в конце концов — перформанс, куда более важные в жизни метрики.

не согласен

мартин не умеет в були, ссылаться на него — это моветон.

не знаю во что он не умеет, но практики, которые он приводит/описвает весьма полезны и преимущество их использования (то что ты получаешь им следуя) вполне понятны. Не возникает вопроса «зачем».

С чего это Вы взяли, что Scala не «взлетит»? Просто удивительно. С этим можно было бы согласиться года 3 назад. Но сейчас.. Вакансий просто полно. Она сейчас очень популярна. Да, в сравнении с Java — несравнимо.. Ну так и не надо. То что есть уже вполне достаточно. чтобы чувствовать себя уверенно на рынке труда. %IMHO% конечно же..

Вакансий просто полно.

Меньше, чем год-два назад, увы

Позволяет язык разбить проект на команду, хотя бы из 20 чел?

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

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

Проблема в том что два года назад их было в три раза больше чем сейчас :-(

А почему ТС вопрошает только джавистов? На скалу легко начнуть переходить джависты, которые писали на Java 8 и прониклись стримами, лямбдами и тд...
Но с еще большим успехом могут переходить и люди с C#, где LINQ появился намного раньше.
Да и питонисты, которые любят простоту синтаксиса и хотят получить статич. типизацию и скорость JVM.
На вопрос — а стоит ли переходить? Однозначно стоит...и не делать поспешных выводов, ибо не получиться писать сразу же красивый канонический код, это вопрос времени.

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

И снова здасте. Как минимум 3 человека уже сказали что стоит переходить на скалу. Но не один не попытался даже обястнить почему и зачем.

И просто для справки:
32 Scala 0.465%

UPD:
24 COBOL 0.798%

Почему и зачем — если кратко: Более краткий и продуманный синтаксис, получаете все преимущества JVM + библиотек, Akka, Reactive programming/design, Spark, BigData

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

И главное — на Scala уже можно найти работу всегда

неужели всю жизнь ровняться на толпу и оглядываться на остальных?

А я не про толпу говорил. Я просто показал что по какой-то причине скала за все время своего существания и имея «Более краткий и продуманный синтаксис» не набрала даже 1% при том что было лет 5 когда многие искали куда бы перейти с джавы.
Кстати у Го больше 1% и у «нишевых» Р и Матлаб тоже.

И главное — на Scala уже можно найти работу всегда

Бедные джава разработчики, у них то безработица и безнадега, на рынке нет ни одного придложения «нужен человек-спринг-хибернейт».

Не понимаю — откуда эти цифры. По нашим опросам — на Scala 1.5 % (у Go — около 2%), соотношение Java/Scala в приницпе коррелирует с западными соотношениями о работе (15:1).

Не понимаю — откуда эти цифры.

tiobe

соотношение Java/Scala в приницпе коррелирует с западными соотношениями о работе (15:1).

И тут 2 момента:
1) Очень интересно выглядит предоление перехода на рынок где предложение (вакансий) в 15 раз меньше. При том что-то мне подсказывает что часть из этих вакансий — это ЕТЛи на спарке.
2) Скала — это не новый язык, имеющий значительно больше фич, который развивался в период застоя джавы. И при всем при этом соотношение 15 к 1. Почему так?

скорость
JVM

Кстати да, «переходили» вполне успешно и питоньшики, и плюсовики, вполне минуя джаву.

Автору.
Реальность такова, что на данный момент Scala и преимущества, которая она дает в ежедневном программировании, находится вне порога восприятия большинства разработчиков (сужу также из личного опыта общения с людьми). Собственно, это можно увидеть по комментариям в этом топике — отсутствие какого-либо конструктивного диалога между людьми и нелепое упование на синтаксис (кто-то с серьезным лицом выбирает язык по его синтаксису?).

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

И именно по этому вы за 4 года на ДОУ ниразу не попытались донести эти преимущества до сообщества. А ТС вместо того чтобы просто разссказать всем что-то полезное, решил искать падаванов.

Реальность такова

...что проблема скалы (последние строки в большинстве рейтинов использования) не в синтаксисе, а в сообществе, которое не способно к «конструктивному диалогу».

...что проблема скалы (последние строки в большинстве рейтинов использования) не в синтаксисе, а в сообществе, которое не способно к «конструктивному диалогу»

О, а можно по подробнее, к какому диалогу, какое сообщество ?

кто-то с серьезным лицом выбирает язык по его синтаксису?

Коли є з чого вибирати, то чому б синтаксису не стати одним із критеріїв вибору?

Проблема в том, что какой язык использовать решают не программисты, а рынок. Бизнес будет оценивать доступность ресурсов на рынке для разработки и поддержки (об этом уже много писалось), зрелость технологического стека, наличие коммерческой поддержки, наличие и объем инструментария, наличие сообщества и еще много всего. Попробуйте обосновать бюджет проекта у CFO крутостью фунционального программирования и монадностью. Тебе сразу зададут вопрос, как быстро они смогут найти пачку индусов на саппорт. Поэтому Скала сейчас там, где она есть. Чем проще код, тем проще его совместная разработка, тестирование и сопровождение. Тем дешевле ресурсы можно привлекать, тем более конкурентным становится бизнес. Деньги/время — это язык бизнеса, а не функции и краткость кода.

Бизнес будет оценивать доступность ресурсов на рынке для разработки и поддержки (об этом уже много писалось), зрелость технологического стека, наличие коммерческой поддержки, наличие и объем инструментария, наличие сообщества и еще много всего.

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

Та вы шо? Вы видели много заказчиков, которые просто верят на слово техническому специалисту? От вас как минимум потребуют посчитать TCO и определить технические риски проекта для нескольких вариантов. А могут еще и попросить POC для всех вариантов. Вы себе представляете бизнес, который готов выкинуть несколько лимонов зелени и кучу времени, просто поверив специалисту, который выбрал ту же Скалу, потому что был ее сильным фанатом?

Вы видели много заказчиков, которые просто верят на слово техническому специалисту?

Если не поверят на слово своим специалистам, значит поверят на слово чужим, делов-то. А расчёт рисков — не больше чем техническая демагогия, поскольку никто из них не управляет этими рисками реально.

Вот поэтому такой большой процент неуспешных проектов, либо проектов, вышедших за рамки ресурсов. Для того, чтобы заказчик поверил на слово, вендор должен быть с безупречной репутацией и огромной капитализацией. Поверить можно Oracle, IBM, Red Hat, Misrosoft. И то с натяжкой. Никакой здравомыслящий бизнесмен не будет вкладывать ресурсы в проект веря на слово. Тем более без оценки рисков. Это не демагогия, а реальность.
Вы когда покупаете авто, тоже верите первому попавшемуся менеджеру? А если вы владелец компании и вам нужно купить 100 авто под определенные цели? Не будете интересоваться количеством СТО, доступностью мастеров и запчастей, временем доставки запчастей? Не будете оценивать риски для вашего бизнеса, если из логистики выпадет 10 машин на неделю, потому что нет запчастей? Или потому что такую замечательную марку китайского автопрома обслуживает только одно СТО в городе, у которого очередь на неделю вперед?

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

В больших бизнесах своя атмосфера, Менеджер выбивает бюджет на проджект. Дальше за откат договариваеться с компанией предоставляющей технологию. Что дадут то и жрать будешь, и никакие слова никаких технических специалистов ничего не дадут.

Да, вижу у вас большой опыт в большом бизнесе. Дальше обьяснять смысла не вижу.

Менеджер выбивает бюджет на проджект. Дальше за откат договариваеться с компанией предоставляющей технологию.

Тем более, выгодно на проект тащить жабу, шарп и прочие плюсы. Т.к. по ним нет ограничения на ресурсы (ок, на плюсы уже появились). А попробуй найди на рынке хотя бы десяток свободных монадщиков, которым не стрёмно доверить проект...

Соответственно, проще, безопаснее (и выгоднее, в плане отката) — привлечь конторку с 20 жабистов.

Т.к. по ним нет ограничения на ресурсы (ок, на плюсы уже появились)

А что за ограничения появились на плюсы?

Мало плюсовиков в последний десяток лет штампуют. Одни жабисты и шарписты кругом...

Это всё тоже не вечные ценности.

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

Dart

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

Это верно, Dart не нужен никому нахер из-за отсуствия нормальной обратной совместимости — и там где TS нативно совместим со всем кодом и библиотеками написанным на JS, Dart сосет лапу.Какому идиоту прийдет в голову переписать весь этот код еще раз — если можно те же плюшки иметь от TS.

Вместе с Дартом поставляется куча встроенных библиотек, и аналог jQuery там уже встроенный. Поскольку Дарт всё равно компилируется в js, соответственно библиотеки js там тоже можно юзать. Но это всё детали. Идея состояла в том, чтобы создать нормальный компилируемый язык, который может выполняться в виртуальной машине, соответственно для которого можно задействовать современные средства разработки для нормальных языков с уже наработанным опытом. Этот подход позволил бы писать все приложения под браузер, поскольку разница в производительности с нативными приложениями здесь несущественная. Однако, Google здесь допустил ошибку в том, что не договорился с Microsoft, Apple, Mozilla. А начинать на самом деле нужно было с того, чтобы собраться, и выработать общие стандарты на байт-код для виртуальной машины под браузеры, и оговорить подходы реализации.

Вместе с Дартом поставляется куча встроенных библиотек, и аналог jQuery там уже встроенный.

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

Кто вам сказал, что ts выстрелил? Это чисто субъективное восприятие. Ни Dart, ни Typescript не являются стандартом, принятым консорциумом w3c для обязательной нативной поддержки. Зато js — является, вот он выстрелил. Хотя ничего ровным счётом прогрессивного там нет. Как лучше договариваться крупным игрокам, через w3c, или без него, и затем поставить перед фактом, это другой вопрос. Факт в том, что на сегодняшний день они занимаются перетягиванием одеяла. Хоть Google проявил мудрость, и пошёл на уступки MS, это всё равно кардинально дело не меняет. Я здесь не рекламирую ни dart, ни ts, а написал об обобщённых принципах, которыми лучше руководствоваться при выборе технологий.

Кто вам сказал, что ts выстрелил? Это чисто субъективное восприятие.

github.com/Microsoft/TypeScript — 30к звезд
github.com/dart-lang — ~ 2.2к звезд
github.com/golang — 37к звезд

Ну и в чём суть вопроса? Что ts, что dart не поддерживаются стандартом нативно, и компилируются в js. То есть, тут завязка на одну зависимость, на которую не могут никак повлиять, при этом ещё и конкурируют с этой зависимостью. В w3c при желании могут подосрать, и ввести в новом стандарте ecmascript изменения, которые будут либо ломать, либо заменять надстройку ts. Во всяком случае, другие компании, и Microsoft в том числе, подобные методы конкурентной борьбы применяла много раз. Навскидку примеры. AOL меняла формат протокола ICQ чтобы выбросить конкурентные клиенты под её протокол. Microsoft сделала расширение C++, где есть оператор for each для коллекций, а в стандарте C++11 принят оператор for для коллекций с другим синтаксисом. Для Lua сделали jit-компилятор под версию 5.1, сейчас выпустили без всякого умысла 5.3, который jit-компилятор не компилит. Насчёт golang, тут подобных рисков нет в принципе, поскольку согласно парадигме, это язык для кроссплатформенной разработки.

Ну и в чём суть вопроса?

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

Здесь речь идёт о принципах, которыми следует руководствоваться при выборе технологий, чтобы минимизировать риски для бизнеса. Эти риски могут быть актуальны на долгосрочном периоде, то есть, если проект развивается более 5 лет. Главный риск — вложить деньги в разработку с такой технологией, которая в дальнейшем отвалится и прекратит развиваться, если вообще не будет выпилена, как например Flash. Естественно фундаментальные звенья здесь — это принятые стандарты, затем капитализация бизнеса вендора с этой тенологией, капитализация всего рынка, увязанного на эту технологию. Конкуренция во многих аспектах имеет ключевое значение. Это не демагогия, а вопросы, которыми руководствуются многие при принятии стратегических решений. Вы как архитектор должны это понимать. И да, популярность тоже имеет большое значение, поскольку отражает капитализацию рынка на этой технологии.

В w3c при желании могут подосрать

хрен там — це просто здорова бюрократична махіна, що існує більше по інерції. IMHO, толку від нього для сучасного вебу небагато. По-факту балом правлять розробники браузерів — Google, Mozilla і MS.

У меня 4 года опыта на Scala. Недавно я для себя понял, что хочу поделиться с другими Java разработчиками своим опытом в изучении Scala.

И вы за все эти 4 года так и не поняли, что код лучше всего писать на Go? Go, и никакой боли от кода вообще в принципе.

— Простите, я потерял сынишку в вашем торговом центре. Можно сделаю объявление по радио?
— О господи, да, конечно.
Наклоняется к микрофону:
— Я пишу на Go.

А если б чувак ещё не хаскеле писал)

Я ещё на C++ пишу много кода, но это не повод для гордости

На хаскеле какраз понять можно — типу уникальный и сложный язык для простого обывателя. А Го который можно осилить за 3 дня возведенный в культ — эт какраз смешно.

А Го который можно осилить за 3 дня

Вы сильно недооцениваете Go, я его освоил за день особо не парясь. Достаточно прочитать тур по Go на официальном сайте, порешать примеры, и сразу можно приступать к крупным проектам. Тем временем, программистам Хаскелля предстоит ещё очень долго штурмовать язык, прежде чем начинать что-то писать.

Ну дык за 3 дня можно уже синьйором быть.
А за две недели писать код не хуже Пайка!

Вот именно, не говоря уже о перспективах через год. В то время как одни уже изучили Go, и баллотируются в президенты США, другие всё ещё изучают монады.

остаточно прочитать тур по Go на официальном сайте, порешать примеры, и сразу можно приступать к крупным проектам.

 о, я много видел кода , который написан по такому приницпу :-) (правда не на Go)

Если в скале народ так делает, то это звиздец :-)

Заходить в бар вейпер, веган та власник IphoneX. Звідки я це знаю? Вони самі це одразу сказали при вході

Go, и никакого кода вообще в принципе.

*очевидный фикс же

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

Шкода тільки що нам так і не вдалося побачити quick sort який би працював для колекції будь-якого типу даних...

В каждом языке, как и в женщине, должна быть своя маленькая загадка.

Я правильно розумію що в Го ця загадка в тому чому го-бої такі дивні і так схожі на сектантів?

Не совсем, Go — это не секта, это конфессия.

Добрый вечер.
Мне бы хотелось бы внести некоторые замечания.

1) Вы не можете просто сортировать любые объекты.
Уж не взыщите — но то, что Вы думаете сортировать, должно минимально удовлетворять неким критериям
Критерии эти просты и выражаются способностью к тому, что мы может получать однозначное сравнение объектов
Практическая реализация — к примеру в Java сортируемый объект обязан соот. и-су Comparable
отсортировать просто Object’ы ... сами понимаете

2) В Golang:
Для того, чтобы отсортировать некий список ( в терминах Go — слайс ) структур, структура должна удовлетворять и-су sort.Interface

То есть реализовывать методы:

Len() int
Less(i, j int) bool
Swap(i, j int)

То есть у нас уже все готово для универасльной сортировки ПРОИЗВОЛЬНЫХ структур, которые соот. и-су.

А теперь идем сюда и смотрим на реализацию:
golang.org/src/sort/sort.go

И видим то там quickSort (исправьте меня, если я ошибаюсь)

Таким образом хотя не отношу себя к поклонникам Go, не понимаю суть Ваших претензий

Претензії такі що мені доведеться писати одні й ті ж компаратори для того самого типу даних і різних колекцій. А ще доведеться імплементувати той же самий інтерфейс для однакових колекцій якщо сортування при цьому має виконуватися за іншими правилами. Тобто copy-paste що є сили.
Якщо я не правий то покажіть мені як для простого int відсортувати масив і список за збільшенням та за зменшенням. Цікавить обсяг коду.

Якщо я не правий то покажіть мені як для простого int відсортувати масив і список за збільшенням та за зменшенням. Цікавить обсяг коду

Две строчки — play.golang.org/p/M2OcxcioRVQ

А якщо не int? Бо я подивився на цей ваш sort.Slice на гітхабі і він схожу лише int вміє. До того ж як він зі списком буде працювати?

А, ок, шото я не туди подивився. Ну красівєнько так, майже С++ :)

То роба пайка часто упрекали в примитивности языка и он решил добавить в него из коробки костыль, коего ещё не видел по-моему ниодин из языков — сортирова на замыканиях(полная жопа как оказалось сложно передать в функцию аргумент в статически типизированном языке без генериков — пришлось всем комьюнити решать проблему :facepalm:) — в нем раскрыта вся мощь и сила языка, которой теперь могут с высоко задранным носом гордится неадекваты. Попробуйте усложнить немного задачу — сделать 3 последовательных действий, список({id, category, price}) отфильтровать, сгруппировать по категории и отсортировать. Вот тут в нормальных языках будет 3 строчки, интересно, что будет в го. 😂 Не удивлюсь если го слишком крут что бы осилить эту задачу — язык очень продвинут, выж понимаете.

костыль, коего ещё не видел по-моему ниодин из языков — сортирова на замыканиях

Не нужно пытаться изображать перед сообществом незнание очевидных вещей, в js который самый популярный язык, вся работа — на замыканиях, как и во многих других скриптовых языках. Лямбда-функции тоже частично работают по принципу замыканий, и тоже используются во многих вызовах, в том числе сортировки. Многое здесь делается также, как и в js. Одно из преимуществ Go как раз в том, что собраны лучшие практики из скриптовых языков, и при этом компилируется нативный код.

Многое здесь делается также, как и в js

В js как раз так не делается потому, что js динамически слаботипизированный язык — там нет проблем как передать в функцию аргумент, а потом обратиться к свойству аргумента — это не поломает интерпретатор, в отличии от Go компилятора.

Вышло отвратительно по правде говоря — в го мне надо что бы сделать сортировку знать кучу ненужной херни — слайсы(ога первого порядка элемент для работы с сортировкой, понимать что передав массив в функцию я его не передал на самом деле, а просто индексы передал, и мне потом еще раз надо массив как замыкание и получить значение из него используя эти индексы? что за полная херня — это вы называете натуральным путем решения алгоритмических задач на продвинутом языке программирования?
a := []int{5, 2, 6, 3, 1, 4} sort.Slice(a, func(i, j int) bool { return a[i] < a[j] })

В нормальном языке этого ничего нет.
[]int{5, 2, 6, 3, 1, 4}.Sort((a, b) => a < b);

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

Вы слишком драматизируете ситуацию. Строгая статическая типизация не усложняет разработку, а наоборот облегчает, поскольку устраняет часть ошибок сразу на этапе компиляции. Вот поэтому и появился typescript для замещения js. Его основная миссия как раз и состоит в том, чтобы принести статическую типизацию. Как видите, ничего не ломается. Замыкания в Go, так же как и в js можно использовать повсюду, в том числе в декораторах, для прослойки между разными типами данных, если есть такая необходимость.

Насчёт слайсов — тоже нет никаких проблем, это базовая парадигма языка, как объекты в js. Управляются GC, ни о чём беспокоиться не нужно. Ну и даже приведённый пример показывает, как удобно и коротко можно писать код, разве что только функция сортировки не является встроенным методом.

Насчёт декларативного подхода — вам никто не мешает делать декларации в одном месте если очень надо, а имплементацию писать в другом месте. В отличии от других языков Go не перегружен лишними абстракциями, и не нуждается в лишней писанине. Поставляемые тулзы типа godoc позволяют сразу смотреть справку по коду, построенную на основании коментов к исходникам, как например тут golang.org/pkg. Так что всё отлично.

Ну ок — мне это не интересно, соревноваться с вами в демагогии.

Давай к конкретике и техническими моментам. А именно, как на Go в декларативном стиле решить задачу

сделать 3 последовательных действий, список({id, category, price}) отфильтровать, сгруппировать по категории и отсортировать

Go не является декларативным языком, так что писать в декларативном стиле можно ровно также, как это делал бы на C++, C#, java и т.п. Тем не менее, стандартная библиотека достаточно хорошо абстрагируется от деталей реализации, и в целом её использование похоже на написание декларативных инструкций.

это не просто информационный шум — это небезопасный код в Go по отношению к типам в придачу ко всему.

Кому та Скала потрібна то?

Тем, кому нужен JVM. А jvm, как известно — не нужен. Потому да, только Haskell.

Смешной коммент, особенно если поискать на доу вакансии по скале, и по хаскелю.

А если поискать на rabota.ua вакансии риэлтора, их на порядок больше, чем Scala-разработчика. Бросаю всё, иду в риэлторы, тренд налицо же!

прикольно говорить с джавистами: ты им про jvm, они тебе про вакансии

прикольно говорить с джавистами: ты им про jvm, они тебе про вакансии

Ну если вакансий на джаве много. то выходит что жвм таки нужен.

И наоборот если вакансий на хацкеле нет — знач он не нужен.

мда. с такой логикой не поспоришь

И наоборот если вакансий на хацкеле нет — знач те, котоыре есть, оч хорошо оплачиваемые.

*очевидный фикс же

Если не смотреть по сторонам и сразу после Java отличный синтаксис :)

А можно конкретику ?

Возможность пропускать точки, опсы со всеми этими >>= <*> и прочим — можно писать так что от хаскеля и не сразу отличишь.

Ох уж эти функциональщики «многа букв тяжело читать».

З того що запам’яталося: { curly braces everywhere }, curried functions()()()()(), ADTs via case classes, etc.

Что плохого в скобках ? В лиспе же еще больше скобок.
Ну и адт через кейс класы — что плохого ? В любой момент можно функций напихать ооп стайл — оч удобно.

xs match { case Nil => List(e) case y :: ys => if (Ordering[A].lteq(e, y)) { e :: xs } else { y :: insert(e, ys) } }
При наличии опс стайл, имплиситов (как в кетсе), иф можно прилично сократить, например

xs match {
case Nil => List(e)
case y :: ys if (e iteq y) => e :: xs
case y :: ys => y :: insert(e, ys)
}

От ручного вывода типов избавиться тяжело, но я видел как некоторые заворачивают тайп класс параметры внутрь велюэ класов + используют при этом алиасы: type L = List[A] Оно сумарно уже не так плохо выходит. Хотя бороть костылями синтаксис, чтобы выиграть в паре символов — какаято упоротая фишка чисто хаскелистов.

В цілому «якось багато літер» порівняно з Кложур і Хаскел.

И эти кложурхаскель девы (не все), потом в продакшен код пишут где обявляют все переменные одной, двумя буквами — поубивал бы.

При цьому для Скали існує багато ресурсів щоб навчити intermediate+ fp, архитектурі, best practices, etc

Да не так чтобы оч много. Но сугубо имхо, в скале фп с ноля гораздо легче учиться. В Хаскеле когда смотрел — либо какаято магия както работает, либо теория категорий. В скале все просто ибо в итоге все сводиться к классам и объектам, и никакой магии (имплиситы и сбт не в счет) :-)

И вот сегодня у меня есть хороший опыт на Scala и есть желание поделиться
Я хочу понять ценно это людям или нет.

Если у вас есть желание поделится, то какая вам разница насколько это ценно другим людям.
Ведите блог. Напишите пару статей на ДОУ. Выступите на паре конференций.
Кому-то да пригодится.

— Доченька, пора нам с тобой поговорить о сексе
— Хорошо, мама, а что ты хотела узнать?

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

Но видосов теперь дофига, так дофига :)

Александр, у меня есть огромное желание перенять хотя бы часть вашего опыта!

А с чего вы взяли что я её не знаю??? И на сколько она на самом деле нужна для качественного освоения Scala? Скорее Haskel выучить нужно, не писать же на Scala в java style? Java если разобраться даже не пооноценный ООП.

Людям ценно понимать сферу коммерческого применения этой самой Скалы.
Пока же я вижу её полное фиаско. Сам на ней писал какое-то время, и отказался. Уж сильно паршиво читается код. И вот эта, как ты выразился, «определённая боль», и оказалась критическим фактором.

Тот случай, когда синтаксический сахар — совсем не сахар.

Подпишусь на тред. Может кто-то действительно расскажет о реальных кейсах применения Скалы, где её использование принесло очевидный ощутимый профит.

www.paypal-engineering.com/...​al-to-build-applications

There is also a resistance from management and architects that do not get their hands dirty. It is the resistance to any change, a resistance to do what you know and not go beyond

Ми використовуємо Scala для побудови data pipeline на базі Spark. Попередня версія, написана на php, перестала справлятися із наростаючим потоком даних.
Легко гугляться переваги Scala над Java чи іншими мовами програмування у випадку обробки даних Spark-ом. :-)

Spark+Scala — это единственный известный мне кейс, где Scala в тему. Но ИМХО исключительно с точки зрения производительности просто потому что Spark написан на Scala и совершенно очевидно, что например UDF написанные на Scala будут в разы производительнее, чем Python хотя бы в виду отсутствия pickle-сериализаций. What else?

Ну обьяснил бы что это Actor model — принципиально другой подход к вычислениям, обработке состояния. Что подходу уже больше 40 лет, но только недавно его откопали и реализовали так что он крайне удобен в коммерческом продакшне там где тебе нужно работать не на одной железке, а на кластере таких. Что с этой либой ты получаешь бесплатное масштабирование горизонтально и вертикально.

Та в джаве уже 100 лет как JMS есть. Не совсем то, но бизнес задачи схожие решает.

Вообще не то и только одну из подзадач и не лучшим/более лёгким способом.

Akka вместе с Java уже использовать нельзя?

Чтобы PM потом не бегал с выпученными глазами в поисках хоть кого-нибудь, который этот код сможет поддерживать. И это после того, как он бегал с такими же глазами в поисках разработчиков. Вон свежий зарплатный опрос показал, Java почти 1000, Scala — 70. Что практически подтверждает соотношение 1:15, которое было озвучено ранее.

мне тоже интересно, где именно ее масштабно применяют, и в чем преимущества. в одном проекте была у нас Скала но только для интеграционных тестов (в основном коде Java)

Да ладно, лол) Коммерческое применение в Apache Spark конкретно, да и вообще в Big Data всякой. Внутри все это работает на Акка, которая внутри работает на Scala(ну не написано ничего такого на Java, ну не умеет она). Быстрые ссылки с опросников на stackoverflow:

insights.stackoverflow.com/...​es-and-other-technologies

insights.stackoverflow.com/...​survey/2015#work-complang

Не шутки же? А сравнивать с Java или выдумывать конкуренцию между этими языками просто нельзя

Сильно паршиво для джавистов читается код Erlang и Haskell. Но никто не пытается заливать, что на этих языках ничего не пишут, фиаско, боль.
Джава популярнее — безусловно. Быстрее писать, быстрее читать — конечно да. Но это все сравнения первоклассника

Быстрее писать, быстрее читать — конечно да. Но это все сравнения первоклассника

. Імхо, це чи не найголовніші критерії для мови програмування загального вжитку.

Мова загального вжитку — це якийсь джаваскріпт?) Типу інтерпрази кліпати на джаві? Сайтики, формочки, ДАОшечки, ’reactive’ programming?) Що це?

Понавходят такие вот в IT, а потом делятся своим весомым мнением о приоритетах критериев оценки языков общего назначения. Читать можно любой код, синтаксис и абстракции которого известны. Читать сложно плохо структурированный код. Некомпетентность основной массы разработчиков некоторой страны 3-го мира не является проблемой языка.

Читать можно любой код, синтаксис и абстракции которого известны. Читать сложно плохо структурированный код.

Читать сложно код, скрытый за кучей бесполезных абстракций, перегруженных методов и starship-операторов.

Чтобы не быть голословным, возьмем для примера код heap’а на Scala или на Go. Какой из них проще понять и рефакторить? Зачем в реализации heap’а на Scala такие абстракции, как stream, forest, fold, rank, flatten, map, singleton, monoid? Без них никак нельзя? :)

Я хоть на скале и не пишу, но у тебя ссылка сломалась. Стандартный heap тут

На Scalaz больше понравилось, так что ok.

Зачем в реализации heap’а на Scala такие абстракции, как stream, forest, fold, rank, flatten, map, singleton, monoid? Без них никак нельзя? :)

Вижу, кто-то код с моего нынешнего проекта спёр. :)

Правда, у нас вся эта хипстерщина на «шарпе». Но такое же, с точностью до имён функций.

На Scala по-лучше. Да и функционал жирнее. Нет этих чудовищных for-break control flow, нет разрушающего присваивания, поток данных линейный, простой, безопасный. Абстракции используют потому что они есть, и могут себе это позволить. Го языку это не светит, придётся писать те же абстракции в каждом конкретном случае снова и снова и снова.
Более короткий на Go в этом примере из-за меньшей абстрактности (и меньшей компонуемости, как следствие), более бедного функционала, и меньшей безопасности. Хотя на фоне того же Haskell оба примера ну оочень так себе (3/4 строк — документация и типы).

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

Необязательно. Можно сверху ещё «декораторов» понавешивать — тогда конкретную (расширенную) функциональность можно реализовывать при помощи них.

И как, типизация Go с этим справится, без дженериков-то?

Как и все без дженериков — руками специализируя алгоритм под определённый тип. Потом уповая что это не копипаста, а такое решение.
Или (что вероятнее, но менее правильно) будут кастовать. Вот тут то и отхватят проблему типизации в своём уютненьком «Goscript» или «Gohp» кому какой сорт ближе к душе.

И как, типизация Go с этим справится, без дженериков-то?

Про Го не в курсе. А у нас подобная вышеописанной скалаз-хрени (но не хип, а список-списков с извращениями) — обвешан десятком декораторов, с 3-4 темплит-параметров каждый. :)

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

Ну так норм, ФП в нутрях лучше всего живётся ;)
А типы с параметрами обозвать каким-то синонимом — и уже не так уж и страшно :)

С фронт-эндом я крякнул — и за неделю выкатил (с тех пор, мои ~220 часов/месяц, оплачивают без единого вопроса :) ).

Но с этой аццкой функциональщиной борюсь до сих пор — т.к. это большой «стоппер» для любого менее-продвинутого кодерка, если такой попадёт на проект. Впрочем, коллега сам начал утопать в этом аду — и, к примеру, уже повыкидывал параметры темплитов из декораторов, оставив лишь по одному (который тоже хорошо бы выкинуть).

С другой стороны, у функциональщины есть и преимущество. Если нагородить такого кода — станешь абсолютно-незаменимым спецом в конторе. После твоего ухода, весь код придётся выкинуть и переписать «с нуля». :)

У знакомой, что пишет на scala была обратная проблема — бить по рукам нубов, которые тащат в красивый проект с красивыми типами лютую оголделую императивщину (тот случай, когда json парсится проходом нод и іf-else конструкциями).

тот случай, когда json парсится проходом нод и іf-else конструкциями

JSON я парсил на прошлом проекте. :) Делал «интеллектуальный» дифф структуры 2-х JSON’ов — с отмечанием разными цветами добавившихся/изменившихся/удалённых нод, изменений в массивах, итп штуки.
Делал на C# рекурсивный проход по нодам и сравнения аттрибутов...

Но могу представить, что функциональщина под обработку таких рекурсивных структур лучше заточена.

да, в целом обход можно оставить либе парсера, и просто скормить ему типы данных, отображающих структуру.

у функциональщины есть и преимущество. Если нагородить такого кода

насколько я знаю, на функциональщине сложнее наговнокодить, чем на ООП)

насколько я знаю, на функциональщине сложнее наговнокодить, чем на ООП)

Для среднего кодерка, функциональщина — это один большой говнокод.

Придёт такой на проект с функциональщиной, откроет код, закроет код, расплачется — и сбежит побыстрее, куда-нибудь в другое место.

Для среднего кодерка, функциональщина — это один большой говнокод.

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

и сбежит побыстрее, куда-нибудь в другое место.

ну вот — наговнокодить не успеет значит))) и это есть гуд)

насколько я знаю, на функциональщине сложнее наговнокодить, чем на ООП)

Балшит. Просто уровень тех кто пишет-шарит в среднем оч высок по сравнению со средним по императивному рынку.

На Scala по-лучше. Да и функционал жирнее. Нет этих чудовищных for-break control flow

 О ужас! ЧУДОВИЩНЫЙ for и break! Это самый страшный грех программиста!

нет разрушающего присваивания

РАЗРУШАЮЩЕЕ присваивание! Это второй грех программиста! Нужно использовать СОЗИДАЮЩЕЕ присваивание!

поток данных линейный, простой, безопасный

поток данных, как и сознания, должен быть обязательно ЛИНЕЙНЫМ и БЕЗОПАСНЫМ! Не спрашивайте, что это значит. Это первая заповедь программиста! Она не подлежит обсуждению.

Абстракции используют потому что они есть, и могут себе это позволить. Го языку это не светит, придётся писать те же абстракции в каждом конкретном случае снова и снова и снова.

Может, эти абстракции тут как коню пятая нога? Какая от них польза? Большинство программ на Go неплохо обходится без этого ментального мусора.

Более короткий на Go в этом примере из-за меньшей абстрактности (и меньшей компонуемости, как следствие), более бедного функционала, и меньшей безопасности

Может, дополнительный функционал просто никому не нужен? Зачем реализовывать то, что никому не понадобится? И что такое «меньшая безопасность»?

самый страшных грех программиста!

с вашей логикой goto — тоже норм, почему бы и нет.

просто никому не нужен

отличный аргумент.

без этого ментального мусора

про избыточность ментального мусора откоментировал выше (S/K или absctraction/application вам в руки).

Вобщем и целом аргументы в стиле защиты невежества. Конечно, можно обойтись без чего угодно, хоть на машинных кодах пишите. Но холить и лелеить ограниченность, как благо — право же, забавно.

с вашей логикой goto — тоже норм, почему бы и нет.

В некоторых случаях goto вполне годен. В Go есть goto и иногда он используется. Например, для быстрого выхода из вложенного цикла или для единообразной обработки ошибки перед выходом из функции.

Кто ж тебя просит пользовать скалу как хаскель? Можно же Scala as Java или Scala as Scala — тогда от того же Go отличается явно не количеством абстракций.
В Go нативно реализованы channel’ы, но нет Actor Model (или я просто о такой не знаю). Actor Model отличная есть в Erlang’е, но нет годных channel’ов (снова таки, я могу не знать). В Scala благодаря либам есть и то и другое. И используя Scala as Scala (так, например, Akka написана) ты получаешь всё это + дженерики + обширную JVM инфраструктуру.

но нет Actor Model

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

Чувак, в твоих примерах две разные структуры данных.

На скале — purely functional структура (начать ознакомление можешь со статьи о persistent data structures).

На Go — стандартная куча из учебника по алгоритмам.

Последняя побыстрее, зато первая — потокобезопасная, и при допиливании может поддерживать версионность (т.е. можно трекать историю изменений и откатываться в нужное состояние).

Сильно паршиво для джавистов читается код Erlang и Haskell.

Паршиво читаеться код си шарпа и питона; код ерланга и хаскеля для джавистов — нечитаеться.

Джавісти не чітатєлі, джавсіти — пісатєлі?

Код C# и Python джависты читают с лёгкостью.

Не говорите за всех джавистов )

Когда читаешь код, где нет ничего, кроме математики, Яву от C# отличает фактически только extends вместо решёточного двоеточия.

Нахрена одну лишь математику писать на шарпе или жабе? Это так, чтобы помедленее считало?

Иногда скорость некритична. Иногда удобнее пройтись по результатам LINQ’ом. Да мало ли поводов. Да и чтобы писать на плюсах сильно более быструю математику, тоже об очень многом думать надо.

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

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

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

Ага. По бенчмаркам, которые «народные умельцы», в совершенстве владеющие лишь бейсиком пишут. :)

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

Кто хотел бы поговорить о API спарка для R, Python, Java — blog.cloudera.com/...​-hit-for-data-scientists
Т.е. Cloudera пишет скалу в спарке. А также статья на techcrunch с 2016-го:
Scala is the new golden child
techcrunch.com/...​-is-the-new-golden-child

И не надо, я люблю джаву не меньше всех кто тут ее защищает))

Вы хоть работали со спарком внутри CDH? С 2014 я вам намекну клаудера поменялась

Akka со спарка к гребеням выпилили уже какбэж

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

Людям ценно понимать сферу коммерческого применения этой самой Скалы.

Ты как маленький. Спарк и Акка — единственная реальная ценность. Их на джаве тожо можно, но там код громоздкое буэ выходит.

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

В big data scala и spark вроде мейнстрим.

Depends on you lawyer lier
Одна в мейнстрим уже Prest суют. другие Impala, третье — Hive2. Естественно бенчмарки каждого вендора не совместимы с конкурентами :)

хорошая попытка, но — нет

Підписатись на коментарі