Теперь, когда я сделал несколько тривиальных вещей со Scala (которые мне нравятся для «hello world» и надуманных приложений!), Мне остается задуматься… часть о зрелости инструментов для поддержки разработки и часть о общей применимости. Готовы ли наборы инструментов? Подходит ли Scala для корпоративных / бизнес-приложений? "Вы" использовали бы это на нетривиальном проекте?
Некоторые из моих (возможно, необоснованных) проблем:
- настолько ли богаты IDE и наборы инструментов, что и для разработки приложений .net и java (затмение для Scala кажется ограниченным по сравнению с затмением для java)?
- способны ли наборы инструментов сборки / CI / тестирования эффективно работать со Scala?
- Насколько поддерживаемым является краткий код, который можно (поощрять?) писать на языке?
- Можно ли найти разработчиков с опытом Scala?
- достаточно ли критической массы, чтобы получить помощь через онлайновые справочники и книги, которые больше, чем «введение» в язык?
Итак, суть в том, достаточно ли зрела экосистема, чтобы использовать ее сейчас, или лучше ждать, чтобы увидеть, как она развивается?
РЕДАКТИРОВАТЬ: скажем, «нетривиальным» является многолетний, много-релизный проект для 10-20 разработчиков.
Ответы:
Хотя это правда, что Scala использовалась в естественных условиях в Guardian и в Twitter, есть одна фундаментальная проблема.
Большая часть популярности Java объясняется тем, что его относительно легко читать и поддерживать. У Scala есть проблема, так как она может быть написана в разных стилях. ОО-стиль против функционального стиля здесь очевиден, но он становится более сложным, когда вы говорите о 3-х уровнях Scala .
Вы должны убедиться, что ваша команда и все потенциальные новые сотрудники могут следовать одному и тому же стилю, и что этот стиль достаточно прост, чтобы вы могли действительно нанять разработчиков, которые могут быть эффективными (не каждый может нанять 2% лучших) ,
Поддержка инструментов пока еще не совсем доступна, хотя я ожидаю, что этот пробел будет ликвидирован довольно быстро. Вы также можете получить поддержку полного стека Scala от толпы TypeSafe . Я думаю, что Scala будет занимать свою нишу, но до тех пор, пока уровни не будут встроены в язык / компилятор / что-то еще, я вижу головную боль, связанную с обслуживанием, в командах после первых 1-2 лет впечатляющей производительности.
Смотрите этот ответ для более подробной информации.
источник
Scala в настоящее время используется Twitter и The Gaurdian, так что он, безусловно, готов для нетривиальных приложений.
Программисты Scala будут очень мотивированы и, вероятно, очень хороши. Выбор нового языка - отличный способ привлечь таланты.
Конечно, программисты Scala часто не имеют профессионального опыта работы с Scala, и могут быть некоторые различия в используемых ими идиомах. Некоторые могут стремиться к чистоте, подобной Хаскеллу, в то время как другие могут рассматривать ее как Java с замыканиями. Таким образом, вероятно, потребуется некоторое время для разработки согласованных стандартов и соглашений кодирования.
Многие инструменты Java будут работать хорошо, хотя IntelliJ Idea, вероятно, будет стоить инвестиций по сравнению с Eclipse.
В целом, это может быть хорошим выбором, если у вас есть контроль над проектом. Если это часть крупной страховой компании, вы можете столкнуться с проблемами при наличии архитектурных указаний, таких как: «Все проекты должны быть созданы Maven и развернуты в WebSphere». (У меня нет оснований полагать, что это конкретное правило будет проблемой, но распространение таких правил может в какой-то момент вас запутать.)
источник
У меня сложилось впечатление, что большая часть экосистемы, которая поставляется с «обычными» языками (такими как Java), предназначена для компенсации их неуклюжести.
Вопрос не в том, сколько инструментов есть для данного языка (Scala), а в том, лучше ли существующие инструменты для этого языка, чем существующие инструменты для эталонного языка (Java). Потому что 100 посредственных инструментов не дадут вам то, что может дать вам один хороший инструмент. И не стоит забывать, что сам язык является частью этих инструментов.
Декларативность языка
Например, однажды я прочитал ужасный пост в блоге одного парня из Ruby, который утверждал, что статическая типизация бессмысленна, потому что ваши тесты охватывают безопасность типов. Это явно пришло от кого-то, кто еще не работал с выразительной статической системой типов. Предполагая, что я могу представить все отношения типов в языковой семантике, и это не так много работы (и это не так, поскольку большинство современных языков поддерживают вывод типов), я получаю все это бесплатно.
Чтобы продвинуть одну мысль немного дальше: модульные тесты гарантируют, что модуль работает так, как указано, или, если перефразировать его, модульный тест - это работоспособные спецификации. Однако благодаря декларативному программированию сами модули являются работоспособными спецификациями. Опять же, вы получаете что-то бесплатно.
Я пытаюсь сказать, что вы не должны недооценивать, что могут сделать языковые функции для вас. И если вы действительно не попробуете их в поле, вы никогда не поймете.
Итак, вернемся к первоначальному вопросу: лучше ли существующие инструменты для Scala, чем для Java? Сложно сказать. Зависит от того, что вы хотите сделать. Я думаю, что мы все согласны с тем, что язык значительно лучше, теперь вопрос в том, насколько хороша экосистема в вашем бизнесе.
Для Интернета Lift действительно хороший выбор. Не знаю насчет настольного или мобильного телефона.
источник
Это много рисков. Награды должны стоить того. В мире корпоративных бизнес-приложений и средних и крупных проектов риск обычно ограничен. Или, скорее, уже достаточно риска, чтобы иметь дело с ... Предсказуемость важнее.
Я сомневаюсь, что усыновление будет работать таким образом.
Скорее всего, это начнется с горстки людей, работающих над частью, в которой содержится риск, такой как POC, некритические компоненты, тестирование или части, где проблема кажется гораздо лучше решаемой Scala, чем альтернативами (возможно, если что-то связано с актер, например) ... Затем, когда инструменты станут зрелыми, сообщество будет расти, ноу-хау в компании будут расти, а затем они могут расширяться.
источник
Используя среду выполнения Java, Scala, безусловно, готова к прайм-тайм. Если вы можете развернуть приложение Scala, то после генерации байт-кода оно всегда должно работать с этой конкретной версией среды выполнения Java. Библиотека на основе Scala будет работать как любая другая сторонняя библиотека Java, с которой вы знакомы.
С точки зрения IDE, инструментов сборки и всего остального, Scala не имеет такого же уровня распространения, как Java. Таким образом, у вас не так много фреймворков на основе Scala или инструментов на основе Scala. Это говорит о популярности Java больше, чем о растущей популярности Scala. Scala имеет функциональные инструменты, включая Scala IDE и sbt, инструмент для сборки. Но они не так сложны, как некоторые другие вспомогательные инструменты на Java.
источник
Точки сбора вишни от @huynhjl и @FarmBoy:
Найти достаточно большое количество опытных программистов Scala может быть сложно.
Догма «лучшей практики» для Scala все еще развивается (*).
Руководства по стилю, соглашения и т. Д. Все еще развиваются (*).
Поддержка инструментов все еще развивается (*).
Собирая их вместе, возможно, лучший вопрос для вас (самих себя): готова ли ваша организация использовать Scala в «нетривиальном» проекте? Есть ли у вас люди, которые могут справиться с большим проектом с таким количеством вещей, которые все еще развиваются? И наоборот, лучше ли сначала сделать небольшой проект?
(* На самом деле, большинство языков все еще развиваются в одном или нескольких из этих аспектов. Проблема здесь заключается в скорости изменения / изменения ... и в том, сможет ли ваша команда справиться с этим.)
источник
У Дэвида Поллака в Good Stuff есть отличный пост в блоге под названием « Функциональные языки будут правилом (но не в этом году)» , в котором подробно рассматриваются функциональные языки в целом, а также Scala в деталях, которые я настоятельно рекомендую прочитать, чтобы лучше понять, готова ли Scala. в прайм-тайм.
источник
Я никогда не понимал различия между
enterpriseиnon enterpriseпрограммами.На работе использую те же программы, что и дома. Я бы не использовал посредственную программу в свободное время - зачем мне это?
Что такое непрофессиональная программа? Я видел, что плохие приложения использовались, потому что пользователь не знал лучше, из-за проблем с совместимостью, или пользователь отказывался учить что-то новое.
Но это проблема устаревшего программного обеспечения и целей, которые имел в виду разработчик, а не языка, на котором была написана программа. Если вы начнете думать, на каком языке написана программа, все уже закончилось: провал.
Enterprise-приложение - это термин marekting, который не полезен для серьезного обсуждения.А какой клиент знает, на каком языке вы выполняли свою работу? Иногда они заботятся, иногда нет.
У вас могут возникнуть вопросы, связанные со зрелостью языка, но вы не можете ответить на этот вопрос для всех видов предприятий и всех приложений.
источник