How to become an author
Search
Write a publication
Pull to refresh

Comments 27

>>Тем более, что и работает движок только под Windows.

Закапывайте.

>>Microsoft не перестает удивлять своей новоявленной открытостью, предоставляя закрытые ранее технологии общественности.

А дальше уже пошли маркетинговые сказки.
Total votes 42: ↑10 and ↓32-22
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 не нужно
Total votes 9: ↑6 and ↓3+3
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).
Оригинал коммента.
Total votes 5: ↑5 and ↓0+5
Поживем-увидим) Microsoft уже давно обещают опенсорсят. Напомните какой-нибудь их софт, который под линуксами работает классно?

Встраивая ChakraCore в Node.js они решают вполне конкретную бизнес-задачу с продвижением Azure — там для Chakra (у которого CharkaCore лишь маленький кусочек) куча своих фишек, но проблемы с отсутствием конечных js-библиотек и фреймворков, которые в массе своей точатся под ноду, что снижает привлекательность платформы. Неспешно портировав базовые куски интерпретора на линуксы, они получат дополнительные возможности в плане регрессионного тестирования, и, вероятно, пересаживания разработчиков. Это все понятно. Но JIT это сильно более хитрое колдунство, как для технарей, так и для бизнесов, чем просто интерпретатор (посмотрите на Java, и историю развития альтернативных JVM). JIT для линуксов если и появится, то будет не настолько бесплатным, чтобы оставался смысл не пользоваться Azure. Тут вам не Googe))
Total votes 3: ↑2 and ↓1+1
CoreCLR. На маке норм :)
Думаю опыта в разработке колдунств у них предостаточно. Смысла особо не вижу в платном JIT. В свете перевода финансовых потоков на рельсы subscription based model нафиг это им надо. Они нашли свою жилу в виде Azure + Office Online и необходимость в анальном огораживании резко отпала. Сейчас пилят под все подряд и стригут купоны :)
Вполне вероятен сценарий, когда на винде перфоманс будет бодрее чем на никсах. Но это вполне ожидаемо и криминала в этом не вижу. Для той же JVM то же есть платные варианты с фейрверком из одного места, цыганами и медведями :) Вот на этой копеечке они могут и заработать.
Total votes 3: ↑3 and ↓0+3
А зачем вообще нужна поддержка других движков в Node.js? Чем V8 плох? Зачем вообще нужны два движка в одном репозитории? Может тогда до кучи еще и SpiderMonkey, и Rhino туда запихнуть.
И я не понимаю — как они собираются обратную совместимость с плагинами обеспечить?
А вообще это новым io.js-ом попахивает, как по мне.
Total votes 23: ↑11 and ↓12-1
v8 меняется и модули c++ написанные для node.js 0.10 не подходят для 0.12 и совсем не подходят для 4.х и для 5.х
Есть пакет nan для npm, но это один фиг не избавляет от необходимости переписывать модули.

Микрософт таким вливанием слоя абстракции v8 очень сильно поддержало проект. Что за этим стоит? Наверняка заговор трансконтинентальных корпораций :)
Total votes 11: ↑11 and ↓0+11
Хорошо, скажем слой абстракции нужен для того чтобы обеспечивать обратную совместимость (и почему его раньше-то не сделали :)) Но все равно — зачем нужен второй движок? Ведь в этом случае нужно обеспечивать совместимость с двумя движками одновременно, разве нет?
Вопрос вот в чем — мне, по сути, предоставляют выбор, о котором я не просил и который решает проблему которой, по сути, нет (или я ее не осознаю). Я понимаю разницу, например, между CPython и PyPy или каким-нибо Stackless, но чем Node с Chakra под капотом лучше чем Node с v8 или Node со SpiderMonkey?
Total votes 5: ↑5 and ↓0+5
Они хотят сделать прослойку, которая будет позволять абстрагироваться от движка. Например: у вас приложение, которое на js мапит огромный массив. Вы тестируете и обнаруживаете, что с движком Chakra в вашем случае есть прирост скорости 10%. Меняете движок на Chakra — profit. Это как перейти с Node 0.12 на io, получить прирост в ~30%, но при этом без геммороя с нативными модулями
Total votes 2: ↑1 and ↓10
Меняете движок на Chakra — profit.


Это так не работает. Нельзя просто так взять и сменить ключевой элемент и чтобы при этом ничего не отвалилось. Попробуйте программе на C сменить libc. Попробуйте программе на Java сменить JDK. Попробуйте программу на питоне, писавшуюся под CPython, запустить на JPython. Да что далеко ходить, в браузерах до сих пор есть отличия в обработке JS/HTML/CSS.
Total votes 9: ↑5 and ↓4+1
Попробуйте сменить MyISAM на InnoDB в MySQL — у вас же просто так не получится! Oh, wait…
Total votes 6: ↑2 and ↓4-2
Фуллтекст индексы, например, от такого действия отвалятся. А от обратного действия отвалится поддержка внешних ключей и, если я не ошибаюсь, транзакций.
Total votes 6: ↑6 and ↓0+6
UFO just landed and posted this here
Это так не работает.

Вообще-то работает. Существует куча софта который работает на разных платформах и собирается разными компиляторами. Просто софт должен быть написан соответстветствующем образом.
Попробуйте программе на 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
А у него несколько миллионов строк кода.
Total votes 2: ↑2 and ↓0+2
Я не говорил, что невозможно обеспечить работоспособность софта в разном окружении, конечно возможно. Но это требует ненулевых затрат, а не просто взять и заменить окружение. И те же джангу с рельсами изрядно патчили для того чтобы они смогла работать под JVM.
Total votes 2: ↑2 and ↓0+2
Гм. Допустим Chakra умеет больше ES2015, чем v8. Вполне возможно где-то один движок превосходит другой. Альтернатива — это всегда хорошо. У v8 есть свои минусы и свои плюсы.
А еще есть интересное развитие событий — завтра google заявит о потере интереса к v8 и останется команда энтузиастов. Для мелких компаний это ничего не изменит, а крупные задумаются.
Total votes 2: ↑2 and ↓0+2
А как синхронизировать одновременно два движка в одной реализации? Если v8 реализует фичу A, а Chakra — фичу B, как обеспечить возможность использования этих фич в Node.js? Или придется ждать пока оба движка реализуют все возможности? А если движков будет три (четыре, пять)?
Total votes 3: ↑3 and ↓0+3
Ну смотря про какие фичи вы говорите. JS стандартная библиотека прямо сейчас никак в доках ноды не описана. Можно догадаться об определенных вещах по текущей версии v8.
А для нативных аддонов будет либо внутренняя, либо внешняя (nan) библиотека. От нее не много требуется. Просто прокидывать объекты туда и обратно.
This comment wasn’t rated yet0
Вопрос вот в чем — мне, по сути, предоставляют выбор, о котором я не просил и который решает проблему которой, по сути, нет (или я ее не осознаю).

Осознаете когда какая-нибудь зависимость в пятом колене цепанёт нативный модуль на с++ и он не скомпилируется под вашу версию nodejs.
Хотели как лучше — писать на js на сервере и клиенте, но навыки с++ будут не лишними, чтобы доработать проект напильником в нужную сторону :))
This comment wasn’t rated yet0
Я не против иметь Plugin API который обеспечит обратную совместимость и абстрагирует меня от внутренностей V8 и если это возможно — предоставит мне возможность использовать другие движки. Меня скорее интересует зачем иметь два движка в зависимостях в кодовой базе в референсной реализации. Если Майкрософт хочет Node на Chakra, почему бы не сделать форк — какой-нибудь chakranode и его сможет использовать кто угодно, если это ему нужно.
Total votes 3: ↑3 and ↓0+3
Мне кажется, что в этой ситуации также поможет внедрение Wasm, т.е. С++ модули будут предварительно скомпилены в формат WebAssembly, который будет работать на любой VM с поддержкой Wasm. Ну по сути сейчас уже так можно делать с ASM.js, но это всё таки костыль, да и к тому же в полной мере в V8 его вроде так и не поддерживают.
Total votes 4: ↑3 and ↓1+2
>> Chakra официально принят Node.js… И несмотря на то, что пулл реквест до сих пор не был принят…

Я не понимаю зачем вы так.
Total votes 16: ↑15 and ↓1+14
>> Chakra официально принят Node.js

>> В ходе обсуждений было принято решение не сливать проекты воедино и ограничиться форком до момента появления хоть сколько-нибудь стабильной версии.

Заголовок 80-лвл. А ведь даже не Ализар…
Total votes 9: ↑8 and ↓1+7
Ну продадут они тоговую марку, допустим. Как показала практика, сообщество спокойненько свинтило делать свою реализацию, когда начали закручивать гайки.
Total votes 2: ↑2 and ↓0+2
Sign up to leave a comment.

Articles

Show the best of all time

Your account

Sections

Information

Services

Support
© 2006–2024, Habr