Чи готовий Scala до прайм-тайму? [зачинено]

Тепер, коли я зробив кілька дрібниць із Scala (яку я люблю "привіт світ" та надумані програми!), Мені залишається цікаво .. частина про зрілість інструментів для підтримки розвитку, а частина про загальну придатність. Чи готові набори інструментів? Чи Scala підходить для використання в корпоративних / бізнес-додатках? Ви б "використали" це нетривіальний проект?

Деякі мої (можливо, необгрунтовані) проблеми:

• чи такі багаті IDE та набори інструментів, як те, що ми маємо розвивати .net та Java-програми (затемнення для Scala здається обмеженим порівняно з затемненням для Java)?
• чи здатні набори інструментів побудови / CI / тестування ефективно боротися зі Scala?
• наскільки ретельним є стислий код, який можна (заохочувати?) записати мовою?
• чи можна знайти розробників із досвідом Scala?
• чи достатньо критичної маси, щоб отримати допомогу через он-лайн довідки та книги, які є більш ніж «введенням» у мову?

Отже, підсумок - чи достатньо зріла екосистема, яку можна використати зараз, чи краще чекати, щоб побачити, як вона розвивається?

EDIT: скажімо, "нетривіальний" - це багаторічний, багатовипускний, 10-20 проект для розробників.

Хоча це правда, що Scala використовували в дикій природі в Guardian та в Twitter, є одна основна проблема.

Значна частина популярності Java пов'язана з тим, що читати та підтримувати її відносно легко. У Scala тут є проблема, оскільки вона може бути написана у багатьох різних стилях. Стиль OO проти функціонального стилю - це очевидний розкол, але він ускладнюється, коли ви говорите про 3 рівні Scala .

Вам потрібно переконатися, що ваша команда та будь-які потенційні наймані працівники можуть дотримуватися того самого стилю, і що цей стиль досить простий, щоб ви могли фактично наймати розробників, які можуть бути ефективними (не кожен може найняти топ-2%) .

Підтримка інструментарію ще не існує, хоча я очікую, що цей розрив буде досить швидко усунутий. Ви також можете отримати підтримку повного стека Scala від натовпу TypeSafe . Я думаю, що Скала викреслить свою нішу, але поки рівні фактично не вбудовані в мову / компілятор / що завгодно, я бачу, що головний біль у обслуговуванні знижується на команди після перших 1-2 років збудженої продуктивності.

Дивіться цю пов'язану відповідь для отримання більш детальної інформації.

В даний час Scala використовується Twitter і Gaurdian, тому вона, безумовно, готова до нетривіальних додатків.

Програмісти Scala будуть дуже вмотивовані і, ймовірно, дуже хороші. Вибір нової мови - чудовий спосіб залучити талант.

Звичайно, програмісти Scala часто не матимуть професійного досвіду Scala, і може бути певна різноманітність в ідіомах, які вони використовують. Деякі можуть прагнути до чистоти, що нагадує Haskell, а інші можуть розглянути її як Java із закриттям. Тому, ймовірно, знадобиться певний час, щоб розробити послідовні стандарти та конвенції кодування.

Багато інструментів Java працюватимуть добре, хоча IntelliJ Idea, ймовірно, вартує інвестицій за Eclipse.

Загалом, це може бути хорошим вибором, якщо ви маєте контроль над проектом. Якщо це частина великої страхової компанії, ви можете зіткнутися з проблемами, якщо існують архітектурні настанови на кшталт: "Усі проекти повинні бути створені Maven і розміщені в WebSphere." (У мене немає підстав вважати, що саме це правило буде проблемою, але розповсюдження подібних правил може в якийсь момент відключити вас.)

Моє враження, що значна частина екосистеми, яка постачається із "звичайними" мовами (як Java), покликана компенсувати їх незграбність.

Питання полягає не в тому, скільки інструментів існує для даної мови (Scala), а в тому, чи наявні інструменти для цієї мови кращі, ніж існуючі інструменти для базової мови (Java). Оскільки 100 посередніх інструментів не дадуть тобі, те, що може дати тобі один хороший інструмент. І річ, яку ви не повинні забувати, це те, що сама мова є частиною цих засобів.

Декларативність мови

• обернено пропорційна кількості та важкості помилок, які ви створюєте з цим, тому Java настільки чудова для створення помилок, і вам потрібно багато інструментів, щоб уникнути та відстежувати їх
• пропорційна вашій продуктивності, тому Java настільки багатослівний і вам потрібно багато генераторів коду та подібних інструментів

Наприклад, я одного разу прочитав жахливу публікацію в блозі хлопця Рубі, який стверджував, що статичне введення тексту є безглуздим, оскільки ваші тести будуть охоплювати безпеку типу. Це явно було від когось, хто ще не працював із експресивною системою статичного типу. Якщо припустити, що я можу представляти всі відносини типів у мовній семантиці, і це не так вже й багато роботи (і це не так, оскільки більшість сучасних мов підтримують умови виводу), я отримую все це безкоштовно.

Щоб підштовхнути одну думку трохи далі вперед: Тестові одиниці забезпечують, що пристрій діє, як зазначено, або перефразовувати його, тест одиниці - це технічні характеристики, які можна виконати. Однак за допомогою декларативного програмування, самі пристрої отримують технічні характеристики. Знову ви отримуєте щось безкоштовно.

Я намагаюся сказати, що ви не повинні недооцінювати те, що мовні особливості можуть зробити для вас. І якщо ви справді не спробуєте їх у полі, ви ніколи не зрозумієте.

Отже, щоб повернутися до початкового запитання: чи існуючі інструменти для Scala кращі, ніж для Java? Важко сказати. Залежить від того, що ви хочете зробити. Я думаю, що ми всі погодимось, що мова значно краща, тепер питання полягає в тому, наскільки хороша екосистема ви знайдете у вашому бізнесі.
Для Інтернету ліфт справді є надійним варіантом. Не знаєте про настільний або мобільний телефон.

скажімо, "нетривіальний" - це багаторічний, багатовипускний, 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-прикладення - це маректинг термін, який не корисний для серйозного обговорення.

І який замовник знає, якою мовою ви зробили свою роботу? Іноді вони піклуються, іноді - ні.

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