Скала готова к прайм-тайм? [закрыто]

Теперь, когда я сделал несколько тривиальных вещей со 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 посредственных инструментов не дадут вам то, что может дать вам один хороший инструмент. И не стоит забывать, что сам язык является частью этих инструментов.

Декларативность языка

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

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

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

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

Итак, вернемся к первоначальному вопросу: лучше ли существующие инструменты для Scala, чем для Java? Сложно сказать. Зависит от того, что вы хотите сделать. Я думаю, что мы все согласны с тем, что язык значительно лучше, теперь вопрос в том, насколько хороша экосистема в вашем бизнесе.
Для Интернета Lift действительно хороший выбор. Не знаю насчет настольного или мобильного телефона.

скажем, "нетривиальный" - это проект, рассчитанный на 10-20 лет.

Это много рисков. Награды должны стоить того. В мире корпоративных бизнес-приложений и средних и крупных проектов риск обычно ограничен. Или, скорее, уже достаточно риска, чтобы иметь дело с ... Предсказуемость важнее.

Я сомневаюсь, что усыновление будет работать таким образом.

Скорее всего, это начнется с горстки людей, работающих над частью, в которой содержится риск, такой как 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, который не полезен для серьезного обсуждения.

А какой клиент знает, на каком языке вы выполняли свою работу? Иногда они заботятся, иногда нет.

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