Интересует, есть ли тут народ, который использует Scala для разработки? Какие остались впечатления?
Я так понял, что у Скалы есть три основные проблемы:
1. Байт-кодовая совместимости разных версий.
2. Трудно найти разработчиков.
3. Сложность. Типа, чтобы писать качественный код на Scala надо ее хорошо знать или что-то в этом роде.
У меня опыта на скале нет, так, что все проблемы почерпнуты из разных статей и могут быть вовсе и не проблемы. Хотелось бы услышать людей, которые наступали на грабли.
Здравствуйте, StanislavK, Вы писали:
SK>Добрый день,
Пишем на скале совсем недавно, но своё мнение выскажу
SK>Интересует, есть ли тут народ, который использует Scala для разработки? Какие остались впечатления? SK>Я так понял, что у Скалы есть три основные проблемы:
SK>1. Байт-кодовая совместимости разных версий.
Наверное да, пока не столкнулись.
SK>2. Трудно найти разработчиков.
Как мне кажется для нормальных джавистов перейти на скалу не проблема. К тому же, упоминание в вакансии скалы по-моему только привлечёт хороших спецов. Так что средний уровень кандидатов окажется выше, хотя они наверное и денег просить будут чуть больше.
SK>3. Сложность. Типа, чтобы писать качественный код на Scala надо ее хорошо знать или что-то в этом роде.
На скале можно писать java-подобный код без особых усилий. А вот использовать её эффективно надо учиться, это точно. Помогает чтение исходников библиотек
SK>У меня опыта на скале нет, так, что все проблемы почерпнуты из разных статей и могут быть вовсе и не проблемы. Хотелось бы услышать людей, которые наступали на грабли.
Ещё из проблем:
4. Неидеальная поддержка в IDE. С одной стороны intellisense нужен меньше из-за склонности скалы к коротким именам. С другой стороны после java всё равно немного непривычно. Лично мне пришлось ради скалы пересеть с Eclipse на IDEA, в последней поддержка чуть лучше.
5. Довольно медленная компиляция. Есть всякие SBT и FSC. Первый не очень удобно использовать из IDE. Вторым пользуюсь, но довольно часто инкрементальная компиляция обламывается и приходится делать rebuild.
Здравствуйте, RomikT, Вы писали: RT>Ещё из проблем: RT>4. Неидеальная поддержка в IDE. С одной стороны intellisense нужен меньше из-за склонности скалы к коротким именам. С другой стороны после java всё равно немного непривычно. Лично мне пришлось ради скалы пересеть с Eclipse на IDEA, в последней поддержка чуть лучше.
RT>5. Довольно медленная компиляция. Есть всякие SBT и FSC. Первый не очень удобно использовать из IDE. Вторым пользуюсь, но довольно часто инкрементальная компиляция обламывается и приходится делать rebuild.
Посмотрите последний релиз scala-ide. Не такой мощный, как в IDEA, но уже вполне адекватный. Я с радостью вернулся на нее после IDEA. Главное — компиляция происходит мгновенно.
Здравствуйте, StanislavK, Вы писали:
SK>Интересует, есть ли тут народ, который использует Scala для разработки? Какие остались впечатления? SK>Я так понял, что у Скалы есть три основные проблемы:
0) Нет нормальных инструментов.
И это самое главное, на самом деле. Даже с медленной компиляцией всё не так плохо, но вот переходить на глючные Scala IDE после нормальной IDEA совсем нет желания.
Здравствуйте, LeonidV, Вы писали:
RT>>5. Довольно медленная компиляция. Есть всякие SBT и FSC. Первый не очень удобно использовать из IDE. Вторым пользуюсь, но довольно часто инкрементальная компиляция обламывается и приходится делать rebuild. LV>Посмотрите последний релиз scala-ide. Не такой мощный, как в IDEA, но уже вполне адекватный. Я с радостью вернулся на нее после IDEA. Главное — компиляция происходит мгновенно.
Смотрел пару недель назад, да. Компиляция действительно мгновенная. Только этот scala-ide у меня почему-то любит по Ctrl+space поудалять все типы из исходника. Он наверное думает, что если тип заимпортировать, то его можно больше вообще не писать Может починили уже.
Вообще, пока у нас исходников мало и время компиляции в 5-10 секунд не сильно напрягает. А IDEA даже просто попробовать хотелось, ведь не спроста она кому-то нравится
Здравствуйте, RomikT, Вы писали:
RT>Только этот scala-ide у меня почему-то любит по Ctrl+space поудалять все типы из исходника. Он наверное думает, что если тип заимпортировать, то его можно больше вообще не писать Может починили уже.
У меня багов в scala-ide не возникает. Поэтому не понял, о чем речь
Здравствуйте, StanislavK, Вы писали:
SK>Добрый день,
SK>Интересует, есть ли тут народ, который использует Scala для разработки? Какие остались впечатления?
Писал небольшой компилятор, впечатления очень хорошие, кейс-классы и паттерн-матчинг позволяют в некоторых задачах писать очень короткий и выразительный код.
Использовал Idea с fsc-режимом компилятора, компилировалось всё очень быстро, впрочем проект был не очень большой. этот компилятор периодически почему то завершал работу, надо было раз в пару часов тыкать кнопочку на тулбаре, не особо напрягало. Ещё Idea не осиливала все премудрости скаловского фреймворка для парсинга и подсвечивала красным некоторые места, которые прекрасно компилировались. Это всё было в начале этого года, возможно поддержка улучшилась, новые версии плагина для Scala выходят очень часто.
Язык не показался сложным, точнее в нём есть много вещей, в которых я даже не пробовал разбираться, всякие implicit преобразования, traits тоже не особо понял, но в целом я в дебри и не залезал, в простом режиме проблем практически не возникало.
Единственная проблема, с которой столкнулся — в стандартной библиотеке не нашёл нормального связного списка, чтобы он был быстрым и можно было быстро конткатенировать такие списки. Может быть плохо искал, или ещё чего, у них там какой то супернавороченный фреймворк для построения своих классов коллекций, я его тоже не осилил и в итоге плюнул и на коленке за 2 минуты написал простейший связной список, который в итоге решил все мои проблемы. Вообще показалось, что с коллекциями они перемудрили, разобраться в том, как они работают, достаточно сложно, миллион наследований всяких, в джаве в этом плане проще. И есть такое ощущение, что эти коллекции в итоге получились очень неэффективными. Но может быть не прав.
Здравствуйте, RomikT, Вы писали:
SK>>Добрый день, RT>Пишем на скале совсем недавно, но своё мнение выскажу
А что вас к этому сподвигло?
SK>>1. Байт-кодовая совместимости разных версий. RT>Наверное да, пока не столкнулись.
вот тут прочитал: http://lift.la/scalas-version-fragility-make-the-enterprise
В общем, из-за этой штуки использовать Скалу для продакшн приложений как-то не срастается. Как-то не забавно (или забавно, на любителя) будет перекомпилировать библиотеки под ту версию скалы которая используется в продакшине.
SK>>2. Трудно найти разработчиков. RT>Как мне кажется для нормальных джавистов перейти на скалу не проблема. К тому же, упоминание в вакансии скалы по-моему только привлечёт хороших спецов. Так что средний уровень кандидатов окажется выше, хотя они наверное и денег просить будут чуть больше. SK>>3. Сложность. Типа, чтобы писать качественный код на Scala надо ее хорошо знать или что-то в этом роде. RT>На скале можно писать java-подобный код без особых усилий. А вот использовать её эффективно надо учиться, это точно. Помогает чтение исходников библиотек
Про служность и разработчиков вот тут: http://blog.joda.org/2011/11/real-life-scala-feedback-from-yammer.html
Суть поста можно уловить просто посмотрев на фразы в болд-шрифте.
SK>>У меня опыта на скале нет, так, что все проблемы почерпнуты из разных статей и могут быть вовсе и не проблемы. Хотелось бы услышать людей, которые наступали на грабли. RT>Ещё из проблем: RT>4. Неидеальная поддержка в IDE. С одной стороны intellisense нужен меньше из-за склонности скалы к коротким именам. С другой стороны после java всё равно немного непривычно. Лично мне пришлось ради скалы пересеть с Eclipse на IDEA, в последней поддержка чуть лучше. RT>5. Довольно медленная компиляция. Есть всякие SBT и FSC. Первый не очень удобно использовать из IDE. Вторым пользуюсь, но довольно часто инкрементальная компиляция обламывается и приходится делать rebuild.
В итоге получаются одни недостатки. А достоинства-то где?
Здравствуйте, StanislavK, Вы писали: SK>В итоге получаются одни недостатки. А достоинства-то где?
Вы всегда начинаете знакомство с технологиями с критических статей? Я думаю, про Java тоже писали не мало критического 15 лет назад (на вскидку — бедный язык, медленная платформа, нет возможности использовать привычные в C++ приемы работы и т.п.).
Здравствуйте, StanislavK, Вы писали:
SK>У меня опыта на скале нет, так, что все проблемы почерпнуты из разных статей и могут быть вовсе и не проблемы. Хотелось бы услышать людей, которые наступали на грабли.
Первая, она же основная, проблема Scala в том, что это сырой язык. Конечно, сырой только по сравнению с Java. Это проявляется буквально в всем: Невнятные сообщения об ошибках, куцая документация, отсутствие литературы сравнимой по уровню с Thinking in Java или Java pitfall или Bitter Java, отсутствие наработанных best practicies, глючность инструментов, таких как статические анализаторы кода, плагины к IDE, анализаторы code coverage, профайлеры и т.п.
Вторая проблема в крутой learning curve. Сам по себе синтаксис Scala довольно птичий поэтому поначалу непросто понять что делает реальный код. Только на освоение синтаксиса уходит около месяца. Но это только начало, потому что писать на Scala в синтаксисе Java можно, но не приносит профита. Scala требует функционального подхода, поэтому еще год начинающий программист на Scala занимается тем, что изучает функциональные паттерны и воюет с языком. Борьба с языком усугубляется еще и тем, что система типов Scala достаточно сложна, многие ли Java программисты имеют представление о ко- и контрвариантности типов? Все это усугубляется тем, что категорически неясно как писать правильно, т.е. безопасно, читаемо, расширяемо и эффективно. Книжек посвященных этому еще не написано, а спросить не у кого. Те кто давно использует Scala в промышленном программировании не слишком рвутся делиться опытом.
Третья проблема в том, что Scala это достаточно тормозной язык. Черт с ней с компиляцией, хотя то что hello world компилируется по 10 секунд это неправильно. Scala генерирует не слишком эффективный байт-код, если не по производительности, так по памяти. Это издержки того факта, что байт-код JVM не заточен под Scala. Время оптимизаций еще не пришло, пока что разработчикам языка было интереснее возиться с новыми фичами.
В результате у Scala довольно узкая область применимости: DSL, работа с данными, API, импорт/экспорт, межнодовое взаимодействие в кластере, и прочие технические вещи. Бизнес логику же проще писать на Java. За последний год, у меня было всего несколько задач, которые имело смысл делать на Scala. Остальные проще было писать на Java и Python.
Здравствуйте, LeonidV, Вы писали:
LV>Здравствуйте, StanislavK, Вы писали: SK>>В итоге получаются одни недостатки. А достоинства-то где? LV>Вы всегда начинаете знакомство с технологиями с критических статей? Я думаю, про Java тоже писали не мало критического 15 лет назад (на вскидку — бедный язык, медленная платформа, нет возможности использовать привычные в C++ приемы работы и т.п.).
Да, а почему нет? Зачем мне наступать на грабли, на которые уже наступали другие? Конечно про все можно написать, что это говно, не работает и т.д. Я об этом прекрасно знаю, помнимаю, что это все субъективно, с горяча и все такое. Сюда же написал в надежде, что может кто-нить тут скажет, что мол, не, все не так плохо, зато там есть что-то такое, что все проблемы перевесит и будет, пусть не счастье, но что-то хорошее.
Пока получается, что язык неплохой, интересный, но писать что-то серьезное на Scala не стоит. Может попозже.
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, StanislavK, Вы писали:
M>Первая, она же основная, проблема Scala в том, что это сырой язык. Конечно, сырой только по сравнению с Java. Это проявляется буквально в всем: Невнятные сообщения об ошибках, куцая документация, отсутствие литературы сравнимой по уровню с Thinking in Java или Java pitfall или Bitter Java, отсутствие наработанных best practicies, глючность инструментов, таких как статические анализаторы кода, плагины к IDE, анализаторы code coverage, профайлеры и т.п.
Не согласен. Есть несколько хороших книг, самая главная — Programming in Scala от Одерски. Вполне сравнима с Thinking in Java 4ed и Хорстманном. С другими источниками тоже все более чем прилично. Начиная от сайтов http://scala-lang.org и http://docs.scala-lang.org и заканчивая IBM Developers и Stackoverflow. Фактически не было такого, чтобы я не нашел ответа на поставленный вопрос.
M>Вторая проблема в крутой learning curve. Сам по себе синтаксис Scala довольно птичий поэтому поначалу непросто понять что делает реальный код. Только на освоение синтаксиса уходит около месяца. Но это только начало, потому что писать на Scala в синтаксисе Java можно, но не приносит профита. Scala требует функционального подхода, поэтому еще год начинающий программист на Scala занимается тем, что изучает функциональные паттерны и воюет с языком.
Просто использование Scala (без написания своих библиотек) не вызывает каких-либо сложностей. Работа с замыканиями и прочем — все ok. Говорю по своему опыту и по опыту студентки, которая со мной работает. Подготовки в функциональном программировании в обоих случаях — 0. Скорость выражения своих мыслей возрастает напорядок.
Известно же, что мощные Java IDE это следствие простоты(убогости?) языка:
а). Просто написать анализаторы и прочее;
б). Без мощных IDE писать на Java было бы очень неприятно.
Текущего состояние scala-ide мне вполне хватает для разработки проекта с такой же эффективность, как при использование JDT.
M>В результате у Scala довольно узкая область применимости: DSL, работа с данными, API, импорт/экспорт, межнодовое взаимодействие в кластере, и прочие технические вещи. Бизнес логику же проще писать на Java. За последний год, у меня было всего несколько задач, которые имело смысл делать на Scala. Остальные проще было писать на Java и Python.
Где-то читал, что как раз бизнес логику очень удобно на Scala реализовывать. Сам сейчас далек от задач автоматизации бизнеса, поэтому спорить не буду.
C>0) Нет нормальных инструментов.
C>И это самое главное, на самом деле. Даже с медленной компиляцией всё не так плохо, но вот переходить на глючные Scala IDE после нормальной IDEA совсем нет желания.
C>Так что ждём Kotlin от JetBrains.
почему тогда не groovy? у него и с инструментами и с совместимостью все ок.
Здравствуйте, insighter, Вы писали:
C>>0) Нет нормальных инструментов.
C>>И это самое главное, на самом деле. Даже с медленной компиляцией всё не так плохо, но вот переходить на глючные Scala IDE после нормальной IDEA совсем нет желания.
C>>Так что ждём Kotlin от JetBrains.
I>почему тогда не groovy? у него и с инструментами и с совместимостью все ок.
Уж у groovy-то и с соместимостью проблемы бывают, а инструменты под него в принципе нормально сделать нельзя из-за динамической типизации. Да и работает он достаточно медленно. Зато компилируется быстро.
Вообще мне groovy нравится, но на роль основного языка он как-то не тянет.
Делал вот фреймворк для веба и писал на нём блог-платформу. Язык сам по себе — очень нравится. Ненавязчиво позволил мне освоить азы ФП. Система типов достаточно мощная, чтобы в неё можно было прошить изрядное количество правил бизнес-логики, что даёт хороший прирост к надёжности. Рефакторить можно размашисто и нагло, огромными итерациями, не боясь ничего поломать. (Правда после возврата на PHP на работе эта разгильдяйская привычка немедленно привела к кровавому поносу.) Книга Одерски "Programming in Scala" (2е издание) — рекомендуется, отличная работа. Хотя на поверку, при простоте ядрового синтаксиса, с сахаром они малость переборщили, иногда возникает ощущение тяжести языка; уточнить не смогу, не помню.
С документированием библиотек — гораздо хуже. И в scala team даже нет консенсуса относительно необходимости эту документацию развивать: один товарищ из scala team в рассылках с пеной у рта доказывал, что мол если ты не знаешь математическую основу ФП и т.п., то и нефиг лезть. Я, в частности, срезался на акторах (ньюансы процесс остановки актора, но тут мне просто желания/необходимости не хватило доразобраться) и на scala combinator parsers в части совместного использования лексера и парсера (хотя идея там вроде простая — Parsers[Char, Lexem] + Parsers[Lexem, AST], но как-то опять не срослось).
IDE — сущий кошмар. Я юзал Idea Community с настроенным fast compiler, потому что старый eclise plugin был вообще уродцем за гранью добра и зла. На днях они зарелизели scala eclipse plugin 2.0, хз чё за зверь. Летом были видео с сабантуйчика "scala exchange 2011", где Одерски рассказывал на тему этого нового плагина, и там мне сильно не понравилось, что компилятор цепляет только открытые файлы. Т.е. если в исходнике есть зависимости из нескольких разных файлов, их все надо открыть в редакторе, чтобы компилятор на них не ругался. Это настолько дикая дичь, что хочется верить, что они её-таки исправили. Но, повторюсь, я сам не щупал.
Инкрементальная компиляция на большом проекте тупо глючила падала, поэтому fsc нифига не помогал. Приходилось бить проект на кучу мелких модулей, что не добавляло. Я правда юзал scala 2.8.3 ЕМНИП, что-то у меня там при попытке перехода на 2.9 с полгода назад сломалось (регрессия в компиляторе), с тех пор не пробовал. Может, сейчас нормально.
В целом, глюки они, надеюсь, вычистят, а хорошая вещь останется.
Здравствуйте, insighter, Вы писали:
C>>И это самое главное, на самом деле. Даже с медленной компиляцией всё не так плохо, но вот переходить на глючные Scala IDE после нормальной IDEA совсем нет желания. C>>Так что ждём Kotlin от JetBrains. I>почему тогда не groovy? у него и с инструментами и с совместимостью все ок.
Нет статической типизации -> в морг.
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, StanislavK, Вы писали:
M>Вторая проблема в крутой learning curve. Сам по себе синтаксис Scala довольно птичий поэтому поначалу непросто понять что делает реальный код. Только на освоение синтаксиса уходит около месяца. Но это только начало, потому что писать на Scala в синтаксисе Java можно, но не приносит профита.
1. val и вообще вывод типов
2. однострочные свойства вместо кучи бойлерплейтного кода с геттерами-сеттарами
3. замыкания
3.1 функциональный стиль работы с колекциями
4. case-классы и паттерн-матчинг по ним
Сами по себе фичи очень простые в освоении, но делают программирование намного приятнее в сравнение с Java.
Здравствуйте, StanislavK, Вы писали:
SK>Интересует, есть ли тут народ, который использует Scala для разработки? Какие остались впечатления?
Мы используем. Полтора месяца как один продукт запустили и оперируем, предшествовало 8 месяцев разработки силами 5 человек, для нас это был первый проект на Scala, для большей части команды — первых проект на JVM вообще. Результат понравился, будем продолжать использовать, в том числе передаем платформу внешней команде
Ощущения: неплохая задумка, но несколько "путанное" исполнение. Многие вещи ИМХО стоило сделать иначе, а некоторые — не делать вообще. Скверное качество scala-библиотек, т.к. Java-библиотеки доступны в полном объеме без ограничений или неудобств — не проблема, но нужно быть готовыми.
Кое-где лезут академические корни в виде расхлябанности и незавершенности.
Но кода реально меньше, пишется он быстрее и получается более понятным. Если предметная область ляжет на какие-то из предоставляемых фичей — может выпасть бинго — для нас это были линеаризация трейтов и матчинг на кейс-классах, существование которых сэкономило много времени, а код получился проще по структуре и более читабельный.
Резюме: наиболее оправданное применять для средних по размеру проектов (3-18 месяцев командой из 3-7 человек). Для маленьких не окупится время въезжания. Для крупных — вылезут косяки незрелой инфраструктуры.
SK>Я так понял, что у Скалы есть три основные проблемы:
SK>1. Байт-кодовая совместимости разных версий.
Слышал, но не видел. Теоретически да, на практике используются Java-окружение, и единственных Scala-код — это код непосредственно проекта.
SK>2. Трудно найти разработчиков.
Хороших разработчиков вообще найти трудно =) Из нашей практики хороший C++ или Java разработчик начинает писать код примерно через неделю и еще через две — делает это хорошо. Ну правда мы наработали определенные неформальные практики, которых и придерживаемся, не скатываясь в ребяческое "Ууу! Смотрите какой новый блестящий молоток!"
SK>3. Сложность. Типа, чтобы писать качественный код на Scala надо ее хорошо знать или что-то в этом роде.
Да, правильные практики применения не наработаны. Поэтому при отсутствии гуру, который расскажет и покажет "как нужно" — лучше идти маленькими шажками, начиная с "пишем как на Java, только на Scala" — даже в этом виде определенный выигрыш будет.
SK>У меня опыта на скале нет, так, что все проблемы почерпнуты из разных статей и могут быть вовсе и не проблемы. Хотелось бы услышать людей, которые наступали на грабли.
"Британские ученые скрестили слона со слоном. Без всякой определенной цели. Просто позырить."
M>В результате у Scala довольно узкая область применимости: DSL, работа с данными, API, импорт/экспорт, межнодовое взаимодействие в кластере, и прочие технические вещи. Бизнес логику же проще писать на Java.
Вот не соглашусь. Как раз технические вещи, которые пишутся один раз и потом используются как платформа — выигрыш минимальный. А как раз в логике — где важнее гибкости, ясность выражения логического конструкта в код и скорость написания — вот тут Scala дает выигрыш.
Здравствуйте, doarn, Вы писали:
D>Здравствуйте, Miroff, Вы писали:
M>>В результате у Scala довольно узкая область применимости: DSL, работа с данными, API, импорт/экспорт, межнодовое взаимодействие в кластере, и прочие технические вещи. Бизнес логику же проще писать на Java.
D>Вот не соглашусь. Как раз технические вещи, которые пишутся один раз и потом используются как платформа — выигрыш минимальный. А как раз в логике — где важнее гибкости, ясность выражения логического конструкта в код и скорость написания — вот тут Scala дает выигрыш.
Я склонен полагать, что выигрыш будет огромным и там, и там. Либо в банальном количестве букв, либо в плане кодирования логики фреймворков в систему типов, что даёт недостижимую в жаве защиту от ошибок неправильного использования фреймворка прикладным программистом. И кстати, насчёт DSL — я бы побоялся бога называть минимальным выигрышем тот же squeryl (LINQ-like DSL for Scala). Не говоря уже о тех же Combinator Parsers, код использования которых выглядит ровно как BNF, не требует никаких препроцессоров, жёстко контролируется типизатором и имеет при этом вполне достойную производительность.
