Хороший вопрос)
А если вычисления есть? Вытаскивать их из ноды и рулить внешним процессом? Причем я не про числодробилку, а про что-то достаточно простое, но не отрабатывающее в течении милисекунды.
Для типичных веб-задач конечно всё это от лукавого, но тем не менее.
Насколько я понимаю под «акторами» на node.js в итоге подразумевалась пачка нодовых процессов, запущенных через cluster, и общающихся через некий внешний event-bus?
Тогда эту штуку конечно по-прежнему можно назвать акторами, но тогда и классы на Java акторы, потому что «получают сообщения» при вызове методов.
Насколько я понимаю, вы из .net?
В JVM есть такая приятная особенность — type erasure. Это значит, что информация о типах из дженериков вся теряется. Это справедливо для любого JVM-based языка. Вот пример из Java: http://stackoverflow.com/a/339708/1040070
Соответственно все штуки, которыми так богата Scala, вроде type constraints (http://stackoverflow.com/a/4870084/1040070), path-dependent types (http://stackoverflow.com/questions/2693067/what-is-meant-by-scalas-path-dependent-types), и тотальное выведение-приведение-проверка типов происходят во время компиляции. В runtime типы дженериков затерты. В Scala есть механизм typetags/classtags, который позволяет держать информацию о типах в runtime, но это скорее опция, и повсеместно оно не используется.
В общем всё это здорово работает и проверяется ровно до того момента, пока вместе компилируется.
Runtime DI подразумевает в свою очередь внедрения кода во время исполнения. Этот код также может быть написан на Scala и быть проверен тайпчекером, но результаты могут оказаться различными — например поменяли List[User] -> List[Profile]. Это вроде бы не сильно тревожно, если у нас полтора модуля для DI, но если мы собираем половину приложения через DI, то как-то это уже начинает не внушать оптимизма. При том, что за все эти тайпчеки мы по-прежнему платим временем во время сборки проекта, да и вообще, нафига городить все эти конструкции из безупречно-типизированного кода, который чуть ли не сам себя пишет (привет макросы из 2.12), если в итоге в рантайме мы будем втаскивать зависимости?
Всё конечно не так плохо, и Scala по прежнему работает, но, кажется последнее время свернула со своего труе-пути и пошла рука об руку с Java. А с учетом нововведений Java 8 возникает логичный вопрос — зачем всё вот это вот хозяйство, если в рантайме у нас зависимости, разработчиков всё еще не так просто найти, если есть Java 8, которая перекрывает 70% того, что есть в Scala, никуда не денется послезавтра и разработчиков под которую можно найти в любом селе необъятной?
1. Почти ничего, кроме того, что Scala — это compile-time typesafe language, в котором этот самый typesafe чуть ли не самая продаваемая и продвигаемая фича, а в одном из самых популярных веб-фреймворков используется runtime DI :)
Не рискну за автора отвечать, но предположу:
отсутствием нормальной библиотеки для http/web? Мы ведь понимаем, что spray — это классный прототип и блестящая идея, а akka-http до сих пор в каком-то не очень понятном состоянии?
Вообще, надо сказать, мне как выходцу и Scala-фанатику это не очень приятно писать, но для того, что описал автор (быстрая реализация хотелок заказчика), связка Akka + Scala + Play 2 (или любой другой фреймворк на этом месте) очень дорогая связка. Мало того, что технологии не совсем мейнстримовые, и разработчиков на Scala надо не только найти, но еще и заставить придерживаться более-менее одного код-стайла, так еще и сам стек куда-то в непонятную сторону поворачивает — Typesafe переименовался в LightBend, Scala 2.12 где-то еще в разработке, Akka Http в каком-то невменяемом состоянии, в Play2 впилили !!runtime Dependency Injection.
Оно конечно всё работает, но вот именно Скальность всего происходящего вызывает вопросы.
Ойвей. Расскажите про акторы на ноде немного подробнее?
Что это такое и с чем его едят в сферическом вакууме понятно. Непонятны технические подробности реализации этого добра на node.js.
Насколько мне известно (а применительно к node.js я начал недавно в эту сторону копать), ничего толкового в духе erlang-а нету, причем по достаточно фундаментальным для node.js причинам. Прежде всего это пресловутая однопоточность выполнения JS. Не существует одного хорошего способа запустить thread: вроде бы был/есть node-threads-a-gogo, который через native код умеет делать что-то очень похожее на нити, но если присмотреться в багтрекер, то можно заметить, что многое добро из node.js в ней не работает (например TypedArrays). Вроде бы есть webworker-threads, но тоже не внушает оптимизма реализация, хотя штука, имхо, очень правильная и в духе ноды.
Cluster тоже не решение, потому что точно также блокирует интерпретатор (да, один из нескольких, запущенных в кластере, но тем не менее).
В общем нужно больше деталей. node.js в этом плане достаточно подходящая штука для написания акторов, но очень многих системных вещей не хватает, плюс их реализация таки идет вразрез с основной идеей node.js
В том числе из-за этих никаких не сложностей эти самые человеки покупают консоли. Вставил диск — поиграл. Купил телефон с нужным количеством памяти — и пользуешься.
Это конечно некоторый консьюмеризм и вендор-лок и все-все-все, но телефоны и компьютеры очень успешно переходят в один сегмент с кофеварками и тостерами. Ты его купил, а он работает. Ничего никуда вставлять и докупать не надо.
Ну сложно же. Разумеется в интересах производителей телефонов сделать так, чтобы пользователь отдал денег больше за встроенную память. Это с одной стороны.
А с другой стороны, как доступно объяснить пользователю, что нельзя взять и впихнуть в его замечательный дорогой Galaxy S8 вот эту скромную недорогую карту памяти, и что все тормозит именно из-за нее?
Так что не так уж и далек от правды некий Хьюго Барра.
Мне кажется, что вся работа программиста в экосистеме NPM сводится к написанию как можно меньшего количества кода, чтобы связать вместе существующие библиотеки, чтобы создать нечто новое, функционирующее уникальным образом для личных или коммерческих нужд.
А разве это не цель, для которой пишутся программы? Не Ваша цель, как программиста, а цель написания программы?
А если вычисления есть? Вытаскивать их из ноды и рулить внешним процессом? Причем я не про числодробилку, а про что-то достаточно простое, но не отрабатывающее в течении милисекунды.
Для типичных веб-задач конечно всё это от лукавого, но тем не менее.
Насколько я понимаю под «акторами» на node.js в итоге подразумевалась пачка нодовых процессов, запущенных через cluster, и общающихся через некий внешний event-bus?
Тогда эту штуку конечно по-прежнему можно назвать акторами, но тогда и классы на Java акторы, потому что «получают сообщения» при вызове методов.
В JVM есть такая приятная особенность — type erasure. Это значит, что информация о типах из дженериков вся теряется. Это справедливо для любого JVM-based языка. Вот пример из Java: http://stackoverflow.com/a/339708/1040070
Соответственно все штуки, которыми так богата Scala, вроде type constraints (http://stackoverflow.com/a/4870084/1040070), path-dependent types (http://stackoverflow.com/questions/2693067/what-is-meant-by-scalas-path-dependent-types), и тотальное выведение-приведение-проверка типов происходят во время компиляции. В runtime типы дженериков затерты. В Scala есть механизм typetags/classtags, который позволяет держать информацию о типах в runtime, но это скорее опция, и повсеместно оно не используется.
В общем всё это здорово работает и проверяется ровно до того момента, пока вместе компилируется.
Runtime DI подразумевает в свою очередь внедрения кода во время исполнения. Этот код также может быть написан на Scala и быть проверен тайпчекером, но результаты могут оказаться различными — например поменяли List[User] -> List[Profile]. Это вроде бы не сильно тревожно, если у нас полтора модуля для DI, но если мы собираем половину приложения через DI, то как-то это уже начинает не внушать оптимизма. При том, что за все эти тайпчеки мы по-прежнему платим временем во время сборки проекта, да и вообще, нафига городить все эти конструкции из безупречно-типизированного кода, который чуть ли не сам себя пишет (привет макросы из 2.12), если в итоге в рантайме мы будем втаскивать зависимости?
Всё конечно не так плохо, и Scala по прежнему работает, но, кажется последнее время свернула со своего труе-пути и пошла рука об руку с Java. А с учетом нововведений Java 8 возникает логичный вопрос — зачем всё вот это вот хозяйство, если в рантайме у нас зависимости, разработчиков всё еще не так просто найти, если есть Java 8, которая перекрывает 70% того, что есть в Scala, никуда не денется послезавтра и разработчиков под которую можно найти в любом селе необъятной?
отсутствием нормальной библиотеки для http/web? Мы ведь понимаем, что spray — это классный прототип и блестящая идея, а akka-http до сих пор в каком-то не очень понятном состоянии?
Вообще, надо сказать, мне как выходцу и Scala-фанатику это не очень приятно писать, но для того, что описал автор (быстрая реализация хотелок заказчика), связка Akka + Scala + Play 2 (или любой другой фреймворк на этом месте) очень дорогая связка. Мало того, что технологии не совсем мейнстримовые, и разработчиков на Scala надо не только найти, но еще и заставить придерживаться более-менее одного код-стайла, так еще и сам стек куда-то в непонятную сторону поворачивает — Typesafe переименовался в LightBend, Scala 2.12 где-то еще в разработке, Akka Http в каком-то невменяемом состоянии, в Play2 впилили !!runtime Dependency Injection.
Оно конечно всё работает, но вот именно Скальность всего происходящего вызывает вопросы.
Что это такое и с чем его едят в сферическом вакууме понятно. Непонятны технические подробности реализации этого добра на node.js.
Насколько мне известно (а применительно к node.js я начал недавно в эту сторону копать), ничего толкового в духе erlang-а нету, причем по достаточно фундаментальным для node.js причинам. Прежде всего это пресловутая однопоточность выполнения JS. Не существует одного хорошего способа запустить thread: вроде бы был/есть node-threads-a-gogo, который через native код умеет делать что-то очень похожее на нити, но если присмотреться в багтрекер, то можно заметить, что многое добро из node.js в ней не работает (например TypedArrays). Вроде бы есть webworker-threads, но тоже не внушает оптимизма реализация, хотя штука, имхо, очень правильная и в духе ноды.
Cluster тоже не решение, потому что точно также блокирует интерпретатор (да, один из нескольких, запущенных в кластере, но тем не менее).
В общем нужно больше деталей. node.js в этом плане достаточно подходящая штука для написания акторов, но очень многих системных вещей не хватает, плюс их реализация таки идет вразрез с основной идеей node.js
Это конечно некоторый консьюмеризм и вендор-лок и все-все-все, но телефоны и компьютеры очень успешно переходят в один сегмент с кофеварками и тостерами. Ты его купил, а он работает. Ничего никуда вставлять и докупать не надо.
А с другой стороны, как доступно объяснить пользователю, что нельзя взять и впихнуть в его замечательный дорогой Galaxy S8 вот эту скромную недорогую карту памяти, и что все тормозит именно из-за нее?
Так что не так уж и далек от правды некий Хьюго Барра.
А разве это не цель, для которой пишутся программы? Не Ваша цель, как программиста, а цель написания программы?