Выпустили, но несколько позже, чем можно было бы. Хотя это скалисты с опытом. Ну и если они, по вашему выражению, напрасно сразу за слик схватились, то как это сочетается с «если выбрали скалу, то это серьезно»?
Я не писал про 2 месяца на джанге, я писал «по-быстрому на джанге», а это неделя-две. То, что вам лично быстрее на Акке я не оспариваю. Мне больше интересно то, на чем будет быстрее широкому кругу разработчиков.
ЗА: Если компания использует Scala, можно быть уверенным в их серьезном подходе к разработке
Это утверждение и следующий за ней абзац откровенно повеселили. Я так познакомился с Erlang'ом, просто потому, что архитектору был выдан карт-бланш и очень хотелось попробовать Erlang, а тут такая возможность. Медленно переписываем теперь. Со Scala забавные ситуации, когда вместо того, чтобы взять Спринг или Джангу для того, чтобы по-быстрому написать несложный рест-сервис, разработчики воротят нос и два месяца втыкают в сликовские транзакции и пишут тот код, который для Джавы уже есть готовый. К сожалению, я отмечаю то, что людям важнее писать на Скале, чем выпустить продукт.
Хотя я согласен, что Скала может пробивать лед для тех языков, которые придут за ней и будут более удобны в работе, особенно для среднего уровня программиста.
Может лучше вообще всегда отдавать состояние на сторону (в Redis, например)?
Если действительно нужно хранить стейт (я убежден, что во многих случаях без него можно обойтись, это больше психологическая проблема), то всегда доступен встроенный ETS.
Странно, особенно после опыта Adobe, ожидать какой-то иной реакции от персональных пользователей, кроме как негативной (в основной массе). Ну и, что не менее обидно, в отличие от того же Adobe, JB как компания все же имела положительную репутацию. А теперь, в не зависимости от того, оставят perpetual licences или нет — «осадочек остался».
Более-менее регулярно заносил деньги в течение 4+ лет, но пару раз оставался без продленной лицензии на 3-5 месяцев (просто не было необходимости), потому новой модели просто испугался, да и вообще как-то в целом неприятно и дело не в стоимости. Повышение цены на Ultimate даже в пару раз я бы спокойно пережил.
А еще вся эта система лицензий запутанная. Если вы платите, то так, а если перестали то потом вот так, а если до этой даты успели то эдак — напоминает старый добрый MS, где нужны специальные люди, которые умеют толковать секретные свитки по которым можно купить MSO на 30% дешевле.
PS. задумался над тем, что можно было б те же деньги заносить какому-нибудь Эклипсу и получить годный свободный инструмент без купюроприемника.
А я и не говорил, что Servo оптимизирует JS, перечитайте, пожалуйста, мой предыдущий комментарий. Про клиент-серверное приложение это конечно хорошо, только на дворе второе десятилетие 21 века и многим приложениям сервер нужен лишь в качестве хранилища, что уже и сейчас можно делать не только с сервером. Вы как-то не понимаете, что браузер стал сам по себе платформой, и сервер ему может и не нужен вовсе — ну, максимум загрузить код вам в бразуер. По поводу травм — да легко — int64.
Ну, так как раз и хотят заниматься тяжелыми приложениями в браузере – в одной из статей говорится даже о риалтайм-приложениях, типа процессоров звуковых эффектов, обработка видео и т.д. С другой стороны, тот же Servo мозиловцы и делают с оглядкой на текущий медленный DOM, который изначально не был рассчитан на то, чтоб его модифицировали. Так что движение к быстрым веб-приложениям идет со всех сторон. Плюс, думаю, очень многих не устраивает медленная скорость обновления стандартов ES (включая доставку в браузеры) и у JS слишком много родовых травм, которые теперь надо оставлять для обратной совместимости.
Код выполняется той же самой виртуальной машиной, а в будущем обещают следующее:
When WebAssembly gains the ability to access garbage-collected objects, those objects will be shared with JS, and not live in a walled-off world of their own.
Вы и в сишной либе вызывая функцию можете передать ей ссылку на на вашу функцию (коллбэк тот самый), но от этого бибилиотека фреймворком не становится. Основное отличие фреймворка от библиотеки в том, что фреймворк дает каркас приложения (например), который вы наращиваете уже своим кодом, но не меняя при это кода самого фреймворка. Другими словами — вы расширяете фреймворк не меняя его — код фреймворка в нужное время будет вызывать ваш код, а интерфейс не поменяется. С библиотекой такого не получится.
Ровно этот же факт может свидетельствовать и об обратном — о том, что фремворк А не удовлетворяет потребностей некой группы разработчиков и они пишут фреймворк Б. ИМХО, чем менее типична задача, тем меньше шансов просто и легко решить ее на готовом фреймворке.
Самописные решения хороши до тех пор, пока есть их автор. Ни документации, ни ответов на SO/списках рассылки как правило не будет — только самому разбираться в коде. С другой стороны — обычно фреймворки жестко ограничивают тем, что было в задумке авторов. Мне кажется, что золотая середина где-то в районе «набора» приложения из проверенных и известных библиотек — есть и гибкость и нет вендор лока.
Но представим себе, что это просто новый фреймворк! Мы же не жалуемся, что мигрировать между Angular и React тяжело — разные фреймворки, каждый со своими фишками.
Что автоматически означает, что вы работаете с продуктом, который развиваться уже не будет и так или иначе нужно переписывать все заново — бизнес, зачастую, такого не понимает. Это никак нельзя сравнивать с миграцией на новую версию фреймворка XYZ. А актуализация инструментов, как мне кажется, жизненно необходима для поддержания приложения, эксплуатация которого планируется более-менее долгое время.
Это утверждение и следующий за ней абзац откровенно повеселили. Я так познакомился с Erlang'ом, просто потому, что архитектору был выдан карт-бланш и очень хотелось попробовать Erlang, а тут такая возможность. Медленно переписываем теперь. Со Scala забавные ситуации, когда вместо того, чтобы взять Спринг или Джангу для того, чтобы по-быстрому написать несложный рест-сервис, разработчики воротят нос и два месяца втыкают в сликовские транзакции и пишут тот код, который для Джавы уже есть готовый. К сожалению, я отмечаю то, что людям важнее писать на Скале, чем выпустить продукт.
Хотя я согласен, что Скала может пробивать лед для тех языков, которые придут за ней и будут более удобны в работе, особенно для среднего уровня программиста.
Если действительно нужно хранить стейт (я убежден, что во многих случаях без него можно обойтись, это больше психологическая проблема), то всегда доступен встроенный ETS.
Более-менее регулярно заносил деньги в течение 4+ лет, но пару раз оставался без продленной лицензии на 3-5 месяцев (просто не было необходимости), потому новой модели просто испугался, да и вообще как-то в целом неприятно и дело не в стоимости. Повышение цены на Ultimate даже в пару раз я бы спокойно пережил.
А еще вся эта система лицензий запутанная. Если вы платите, то так, а если перестали то потом вот так, а если до этой даты успели то эдак — напоминает старый добрый MS, где нужны специальные люди, которые умеют толковать секретные свитки по которым можно купить MSO на 30% дешевле.
PS. задумался над тем, что можно было б те же деньги заносить какому-нибудь Эклипсу и получить годный свободный инструмент без купюроприемника.
Что автоматически означает, что вы работаете с продуктом, который развиваться уже не будет и так или иначе нужно переписывать все заново — бизнес, зачастую, такого не понимает. Это никак нельзя сравнивать с миграцией на новую версию фреймворка XYZ. А актуализация инструментов, как мне кажется, жизненно необходима для поддержания приложения, эксплуатация которого планируется более-менее долгое время.