Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 27
>>Тем более, что и работает движок только под Windows.
Закапывайте.
>>Microsoft не перестает удивлять своей новоявленной открытостью, предоставляя закрытые ранее технологии общественности.
А дальше уже пошли маркетинговые сказки.
Закапывайте.
>>Microsoft не перестает удивлять своей новоявленной открытостью, предоставляя закрытые ранее технологии общественности.
А дальше уже пошли маркетинговые сказки.
Они его вроде портировать будут.
Seth wrote that by June 2016, Microsoft wants to release «an implementation of ChakraCore interpreter and runtime, no JIT, on x64 Ubuntu Linux 15.10.»
Yes, that's right. Microsoft is porting part of an end-user program to Linux.
без JIT не нужно
Yes, its currently Windows only. For cross-platform support, the key target for next six months on the roadmap is to get the interpreter & runtime working. JIT would come after that (don't read it as no JIT forever — it was just a breakdown of what we need enable and its ordering for next 6 mos).
Оригинал коммента.
Оригинал коммента.
Поживем-увидим) Microsoft уже давно обещают опенсорсят. Напомните какой-нибудь их софт, который под линуксами работает классно?
Встраивая ChakraCore в Node.js они решают вполне конкретную бизнес-задачу с продвижением Azure — там для Chakra (у которого CharkaCore лишь маленький кусочек) куча своих фишек, но проблемы с отсутствием конечных js-библиотек и фреймворков, которые в массе своей точатся под ноду, что снижает привлекательность платформы. Неспешно портировав базовые куски интерпретора на линуксы, они получат дополнительные возможности в плане регрессионного тестирования, и, вероятно, пересаживания разработчиков. Это все понятно. Но JIT это сильно более хитрое колдунство, как для технарей, так и для бизнесов, чем просто интерпретатор (посмотрите на Java, и историю развития альтернативных JVM). JIT для линуксов если и появится, то будет не настолько бесплатным, чтобы оставался смысл не пользоваться Azure. Тут вам не Googe))
Встраивая ChakraCore в Node.js они решают вполне конкретную бизнес-задачу с продвижением Azure — там для Chakra (у которого CharkaCore лишь маленький кусочек) куча своих фишек, но проблемы с отсутствием конечных js-библиотек и фреймворков, которые в массе своей точатся под ноду, что снижает привлекательность платформы. Неспешно портировав базовые куски интерпретора на линуксы, они получат дополнительные возможности в плане регрессионного тестирования, и, вероятно, пересаживания разработчиков. Это все понятно. Но JIT это сильно более хитрое колдунство, как для технарей, так и для бизнесов, чем просто интерпретатор (посмотрите на Java, и историю развития альтернативных JVM). JIT для линуксов если и появится, то будет не настолько бесплатным, чтобы оставался смысл не пользоваться Azure. Тут вам не Googe))
CoreCLR. На маке норм :)
Думаю опыта в разработке колдунств у них предостаточно. Смысла особо не вижу в платном JIT. В свете перевода финансовых потоков на рельсы subscription based model нафиг это им надо. Они нашли свою жилу в виде Azure + Office Online и необходимость в анальном огораживании резко отпала. Сейчас пилят под все подряд и стригут купоны :)
Вполне вероятен сценарий, когда на винде перфоманс будет бодрее чем на никсах. Но это вполне ожидаемо и криминала в этом не вижу. Для той же JVM то же есть платные варианты с фейрверком из одного места, цыганами и медведями :) Вот на этой копеечке они могут и заработать.
Думаю опыта в разработке колдунств у них предостаточно. Смысла особо не вижу в платном JIT. В свете перевода финансовых потоков на рельсы subscription based model нафиг это им надо. Они нашли свою жилу в виде Azure + Office Online и необходимость в анальном огораживании резко отпала. Сейчас пилят под все подряд и стригут купоны :)
Вполне вероятен сценарий, когда на винде перфоманс будет бодрее чем на никсах. Но это вполне ожидаемо и криминала в этом не вижу. Для той же JVM то же есть платные варианты с фейрверком из одного места, цыганами и медведями :) Вот на этой копеечке они могут и заработать.
А зачем вообще нужна поддержка других движков в Node.js? Чем V8 плох? Зачем вообще нужны два движка в одном репозитории? Может тогда до кучи еще и SpiderMonkey, и Rhino туда запихнуть.
И я не понимаю — как они собираются обратную совместимость с плагинами обеспечить?
А вообще это новым io.js-ом попахивает, как по мне.
И я не понимаю — как они собираются обратную совместимость с плагинами обеспечить?
А вообще это новым io.js-ом попахивает, как по мне.
v8 меняется и модули c++ написанные для node.js 0.10 не подходят для 0.12 и совсем не подходят для 4.х и для 5.х
Есть пакет nan для npm, но это один фиг не избавляет от необходимости переписывать модули.
Микрософт таким вливанием слоя абстракции v8 очень сильно поддержало проект. Что за этим стоит? Наверняка заговор трансконтинентальных корпораций :)
Есть пакет nan для npm, но это один фиг не избавляет от необходимости переписывать модули.
Микрософт таким вливанием слоя абстракции v8 очень сильно поддержало проект. Что за этим стоит? Наверняка заговор трансконтинентальных корпораций :)
Хорошо, скажем слой абстракции нужен для того чтобы обеспечивать обратную совместимость (и почему его раньше-то не сделали :)) Но все равно — зачем нужен второй движок? Ведь в этом случае нужно обеспечивать совместимость с двумя движками одновременно, разве нет?
Вопрос вот в чем — мне, по сути, предоставляют выбор, о котором я не просил и который решает проблему которой, по сути, нет (или я ее не осознаю). Я понимаю разницу, например, между CPython и PyPy или каким-нибо Stackless, но чем Node с Chakra под капотом лучше чем Node с v8 или Node со SpiderMonkey?
Вопрос вот в чем — мне, по сути, предоставляют выбор, о котором я не просил и который решает проблему которой, по сути, нет (или я ее не осознаю). Я понимаю разницу, например, между CPython и PyPy или каким-нибо Stackless, но чем Node с Chakra под капотом лучше чем Node с v8 или Node со SpiderMonkey?
Они хотят сделать прослойку, которая будет позволять абстрагироваться от движка. Например: у вас приложение, которое на js мапит огромный массив. Вы тестируете и обнаруживаете, что с движком Chakra в вашем случае есть прирост скорости 10%. Меняете движок на Chakra — profit. Это как перейти с Node 0.12 на io, получить прирост в ~30%, но при этом без геммороя с нативными модулями
Меняете движок на Chakra — profit.
Это так не работает. Нельзя просто так взять и сменить ключевой элемент и чтобы при этом ничего не отвалилось. Попробуйте программе на C сменить libc. Попробуйте программе на Java сменить JDK. Попробуйте программу на питоне, писавшуюся под CPython, запустить на JPython. Да что далеко ходить, в браузерах до сих пор есть отличия в обработке JS/HTML/CSS.
Попробуйте сменить MyISAM на InnoDB в MySQL — у вас же просто так не получится! Oh, wait…
Это так не работает.
Вообще-то работает. Существует куча софта который работает на разных платформах и собирается разными компиляторами. Просто софт должен быть написан соответстветствующем образом.
Попробуйте программе на C сменить libc.Сравнение скорости на GCC и Clang www.phoronix.com/scan.php?page=article&item=clang-37-gcc52&num=4
У них не то что libc, у них все разное.
Попробуйте программу на питоне, писавшуюся под CPython, запустить на JPythonПрекрасно заработает, если нет нативных библиотек в зависимостях.
docs.djangoproject.com/en/1.9/howto/jython
github.com/jruby/jruby/wiki/JRubyOnRails
То что на каком-то софте такой подход не работает, это не значит, что это не возможно, это значит, что разработчикам жалко ресурсов или им это просто нафиг не нужно.
Посмотрите список поддерживаемых платформ у Qt doc.qt.io/qt-5/supported-platforms.html
А у него несколько миллионов строк кода.
Попробуйте программе на Java сменить JDK
Не буду вдаваться в подробности, но прежде чем утверждать, хотя бы попробуйте: www.oracle.com/technetwork/java/javase/downloads/index.html
Гм. Допустим Chakra умеет больше ES2015, чем v8. Вполне возможно где-то один движок превосходит другой. Альтернатива — это всегда хорошо. У v8 есть свои минусы и свои плюсы.
А еще есть интересное развитие событий — завтра google заявит о потере интереса к v8 и останется команда энтузиастов. Для мелких компаний это ничего не изменит, а крупные задумаются.
А еще есть интересное развитие событий — завтра google заявит о потере интереса к v8 и останется команда энтузиастов. Для мелких компаний это ничего не изменит, а крупные задумаются.
А как синхронизировать одновременно два движка в одной реализации? Если v8 реализует фичу A, а Chakra — фичу B, как обеспечить возможность использования этих фич в Node.js? Или придется ждать пока оба движка реализуют все возможности? А если движков будет три (четыре, пять)?
Ну смотря про какие фичи вы говорите. JS стандартная библиотека прямо сейчас никак в доках ноды не описана. Можно догадаться об определенных вещах по текущей версии v8.
А для нативных аддонов будет либо внутренняя, либо внешняя (nan) библиотека. От нее не много требуется. Просто прокидывать объекты туда и обратно.
А для нативных аддонов будет либо внутренняя, либо внешняя (nan) библиотека. От нее не много требуется. Просто прокидывать объекты туда и обратно.
Вопрос вот в чем — мне, по сути, предоставляют выбор, о котором я не просил и который решает проблему которой, по сути, нет (или я ее не осознаю).
Осознаете когда какая-нибудь зависимость в пятом колене цепанёт нативный модуль на с++ и он не скомпилируется под вашу версию nodejs.
Хотели как лучше — писать на js на сервере и клиенте, но навыки с++ будут не лишними, чтобы доработать проект напильником в нужную сторону :))
Я не против иметь Plugin API который обеспечит обратную совместимость и абстрагирует меня от внутренностей V8 и если это возможно — предоставит мне возможность использовать другие движки. Меня скорее интересует зачем иметь два движка в зависимостях в кодовой базе в референсной реализации. Если Майкрософт хочет Node на Chakra, почему бы не сделать форк — какой-нибудь chakranode и его сможет использовать кто угодно, если это ему нужно.
Мне кажется, что в этой ситуации также поможет внедрение Wasm, т.е. С++ модули будут предварительно скомпилены в формат WebAssembly, который будет работать на любой VM с поддержкой Wasm. Ну по сути сейчас уже так можно делать с ASM.js, но это всё таки костыль, да и к тому же в полной мере в V8 его вроде так и не поддерживают.
>> Chakra официально принят Node.js… И несмотря на то, что пулл реквест до сих пор не был принят…
Я не понимаю зачем вы так.
Я не понимаю зачем вы так.
>> Chakra официально принят Node.js
>> В ходе обсуждений было принято решение не сливать проекты воедино и ограничиться форком до момента появления хоть сколько-нибудь стабильной версии.
Заголовок 80-лвл. А ведь даже не Ализар…
>> В ходе обсуждений было принято решение не сливать проекты воедино и ограничиться форком до момента появления хоть сколько-нибудь стабильной версии.
Заголовок 80-лвл. А ведь даже не Ализар…
Ну продадут они тоговую марку, допустим. Как показала практика, сообщество спокойненько свинтило делать свою реализацию, когда начали закручивать гайки.
Видимо мы наблюдаем второй шаг
https://ru.wikipedia.org/wiki/Embrace,_Extend,_and_Extinguish
https://ru.wikipedia.org/wiki/Embrace,_Extend,_and_Extinguish
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Chakra официально принят Node.js