Опубликован (https://github.com/isomorphic-git/isomorphic-git/releases/ta...) выпуск проекта isomorphic-git 0.13.0 (https://isomorphic-git.github.io/), в рамках которого развивается реализация Git на языке JavaScript, нацеленная на предоставление 100% переносимости с классическим Git и способная выполняться в web-браузере или в качестве модуля для платформы Node.js. Код проекта поставляется (https://github.com/isomorphic-git/isomorphic-git) под лицензией MIT.Проект изначально написан на чистом JavaScript (без компиляции в JavaScript при помощи Emscripten) и базируется на применении WebWorkers и ServiceWorkers. Isomorphic-git позволяет читать и записывать данные в локальные Git-репозитории, выполнять операции push и fetch с удалёнными репозиториями, например, с GitHub. Для работы с Git-репозиториями предлагается утилита isogit, поддерживающая большую часть команд git. Для встраивания отдельных возможностей Git в web-приложения предоставляется модульный API, позволяющий включать только необходимую функциональность. Как и в канонической реализации Git, в isomorphic-git все операции выполняются путём изменения файлов в каталоге ".git".
URL: https://news.ycombinator.com/item?id=17083807
Новость: https://www.opennet.dev/opennews/art.shtml?num=48615
Но зачем?
Чтобы набраться опыта, изучив тонкости JS. Всяко интереснее чем очередной калькулятор по учебнику.
Неужели JS на столько сложен, что его тонкости можно только так изучить? А то тут фанбои совсем другое вещают...
https://youtu.be/RGkIsUBfanQ?t=1m20sНу и дальше смотрите "why javascript is sucks".
Сложен. Но входной порог при этом низкий.
> Неужели JS на столько сложен, что его тонкости можно только так изучить?Наверное достаточно наличия книжки с названием "Javascript: The Good Parts" чтобы что-то заподозрить (:
Чтобы называться так же, но быть несовместимым, очевидно же.
Для online IDE, например
> Для online IDE, напримерНепременно в телефоне, а лучше в "умных часах" :)
Если брать тот же с9, то там нормальный гит, т.к. ОС запускается в контейнерах, гит нормальный и все как полагается.Зачем именно в JS - не ясно.
> Зачем именно в JS - не ясно.Скоро электрон перекочует в прошивку и JS сразу станет системным языгом, а старперы с их старыми плюсами и дривнющим си будят завидовать и кусать локди! Вот!
Затем, что под нормальной свободной лицензией, а не под вирусно-несвободным GPL.
Фронтендеры, успокойтесь уже.
Почему? Почему все думают, что JS медленнее нерушимого Си? Оптимизация движка JS скоро переплюнет оптимизации компилятора Си (кто в 21 веке пашет землю иголкой?), чего уже Rust ментально достиг, ускоряя свои имплементационные возможности стремительно завоёвывая умы думающих программистов.
Потому что тесты производительности не обманешь как и тесты на потребление памяти. Потому что си и с++ при правильной организации разработки и наличии статического анализа безопасней js-a. Потому что для С-подобных языков не нужен рантайм.
С-подобный это про синтаксис, javaScript как раз к ним и относится, так что вы тут некорректно выразились.
Есть Си-подобный синтаксис, да. Но в данном человек имел ввиду отсутствие вспомогательных средств для обеспечения работоспособности приложение, подобно тому, как работают программы, написанные на Си, и это не является некорректным выражением. Это всё равно что при упоминании экспоненты сразу думать про экспоненциальный рост.
> с++
> не нужен рантайм.ага, а libstdc++ фикция и не существует.
строго говоря, это такой же рантайм, т.е. имплементация stdlib, без наличия которой в системе ничего не запустится.
Статически линкуй
> Статически линкуйРантайм - это все что обслуживает выполнение программы, чтобы main() вывело Hello World, но не включая ядро.
Например: libc - рантайм С. Без разницы, статически или динамически прилинковать - это все равно будет рантайм для С программы.
> Рантайм - это все что обслуживает выполнение программы, чтобы main() вывело Hello World, но не включая ядро.Ага. Но только во время ВЫПОЛНЕНИЯ, а не во время компиляции (по секрету: поэтому и называется RUNtime).
После статической линковки можешь удалить то с чем линковал, а "hello, world" будет по прежнему выводиться. А это значит что во время выполнения не используется, то есть это не рантайм. По определению.
При чём тут статическая линковка вообще? Просто рантайм будет идти вместе с прогой и последняя будет больше весить. Вон бинарники после раста или го весят по несколько мегабайт даже если это hello world. Как раз из-за рантайма.
Когда ты слинковал статически либу, ты фактически сделал ее копию внутрь бинарника и эта копия используется при выполнении программы. И не играет роли, что ты там сделал с оригиналом. С тем же успехом ты можешь сделать копию интерпретатора js, удалить оригинал и запустить js в копии, после чего заявить, что у js тоже нет рантайма, ведь ты удалил оригинал.
> Рантайм - это все что обслуживает выполнение программы, чтобы main() вывело Hello World, но не включая ядро.а если bare-metal запускаешь вывод Hello World в UART - что будешь считать рантаймом?
Ерунду говоришь. Без этой либы на плюсах приложение мобрать можно (она и сама на плюсах, собственно). А на джаваскрипте без рантайма жить нельзя. Потому как динамика проклятая.
давай зайдём с другой стороны. есть golang. у него статические линкуемые бинарики со стандартными и не очень библиотеками на выходе. так вот, вопрос: это всё прилинкованное в файл (там зелёные треды, каналы и прочее) -- это, что, не рантайм? рантайм. так вот, у c++ есть такой же. прилинкованный stdlib -- это вполне себе рантайм, т.е. 3rd party code, который выполняется во время исполнения программы. реальные приложения в c++ используют stdlib и ты отлично это знаешь.
stdlib это стандартная библиотека функций. после компиляции линкуется не она целиком а только те кусочки которые ты явно вызываешь. + ты можешь использовать любой другой набор функций или написать свой или не использовать вообще ничего.
Собрать то конечно можно, вот только окажется, что значительная часть функционала плюсов у тебя отсутствует и практически любую программу, включая helloworld, надо переписывать.
Интерпретатор JS, написанный на C, станет быстрее С? Дак пусть сразу быстрее асмы делают, что мелочиться то.
А написанным на самом JS ещё быстрее!
Внезапно: а почему бы и нет? См. пример с PyPy.
Порой чувствуешь себя умнее сишников, объясняя им такие банальные вещи.
> Внезапно: а почему бы и нет? См. пример с PyPy.
> Порой чувствуешь себя умнее сишников, объясняя им такие банальные вещи.просто трудновато принять что компилятор нынче способен делать больше оптимизаций, делать их лучше и быстрее прямо во время исполнения программы.. по какой-то причине это контрпродуктивно..
> Внезапно: а почему бы и нет? См. пример с PyPy.
> Порой чувствуешь себя умнее сишников, объясняя им такие банальные вещи.Текущие версии PyPy транслируются из RPython в Си и компилируются (c) википедия
Ну и? Что мешает проделывать аналогичное с кодом на JS на лету? Собственно, это сейчас и делается, но все равно находятся ламеры у которых в голове не укладывается.
ключевое слово "emscripten"Но все равно работает существенно медленнее. Проверено и не раз, так как вот уже третий год разрабатываю и использую.
Это совсем другое направление компиляции, плюс тормозить может из-за того что движки JS не оптимизированы под код выдаваемый emscripten.
ну вот не любят люди лишних прослоек.. ощущения не те..
> стремительно завоёвывая умы думающих программистов.Это типа определять творческость креаклов по принципу заднепроходности.
А "думание программиста" - по переписыванию чужого готового на языке-изврате.
Просто оголтелая бестолочь с жс головного мозга, кроме как на вопли о крутизне своего язычишки и переписывания всего подряд по нескольку раз, ни на что больше не способна. Это факт.
Потому что есть такая штука: формальная (она же "математическая") логика...
Учитывая то, что сам JS вполне себе написан на C, т.е., формально является примером валидного C кода, очевидно, что C гарантированно может быть НЕ медленнее JS в 100% случаев.
При этом в обратную сторону гарантии не работают, т.к. JS- это, собственно, API к C, т.е. некоторое подмножество возможных реализаций. Т.е. JS гарантированно НЕ сможет быть производительней C во всех случаях.
> Потому что есть такая штука: формальная (она же "математическая") логика...Есть, есть. Но каким она боком к вашим умозаключениям - непонятно.
> Учитывая то, что сам JS вполне себе написан на C, т.е., формально является примером валидного C кода, очевидно, что C гарантированно может быть НЕ медленнее JS в 100% случаев.
Во-первых, реализация движков разная. V8 вроде как на плюсах.
Во-вторых … хоспади, какой бред *facepalm.jpg*
С такой "аргументацией" достаточно написать интерпретатор Си на JS. Получим "гарантию", что JS может быть не медленнее сишки в 100% случаев.
Хотя вообще-то нас интересует быстрота выполнения генерируемого из ЯП X кода и там язык написания компилятора/JIT имеет куда меньше влияния, чем сам ЯП, из которого генерируют этот самый код. Динамическая типизация, виртуальные методы, излишниий ООизм, GC и проч.
И кто только ведется на такой толстый троллинг...
Это у бородатых фронтендщиков уже спорт такой, типа как Дум на тостере запилить. Ждём появления компиляторов ЦеПлюс на жабаскрипте (если не появились еще).
https://felixhao28.github.io/JSCPP же
> https://felixhao28.github.io/JSCPP жеJS головного мозга...
просто no-life man
Проблема в том, что они эти тостеры потом в реальные приложения тащат... А дальше - электроны всякие вылезают.
Был же https://github.com/creationix/js-git, на который забили из-за сетевых ограничений а браузере.
Нет.
Пожалуйста.
Не хватает интеграции с Electron
Еще одно подтверждение закона Джеффа Этвуда - "Any application that can be written in JavaScript, will eventually be written in JavaScript".
Но зачем? WebAssemly решает проблемы при нулевых затратах времени!!!!
Видимо писать начинали тогда, когда про васм еще не слышали ничего
> писать начинали тогда, когдаА дописывали зачем?
Но как? WA это же кастрат - он не умеет пакеты по сети и файлы. Нет, ну хэш на нем посчитаешь, а все остальное на JS.
> реализация Git на языке JavaScript, нацеленная на предоставлениеНадо еще переписать на хРусте, на Скале, на голанге, на Лиспе, Эрлагне и Хаскелле, потом на Руби, Перле и Пыхе. Фанатиков обижать нельзя!
Я не совсем в теме, простите за возможно глупый вопрос - значит через JS уже можно обращаться к локальной файловой системе клиента? Или это таки делает Электрон, а JS как и прежде только прокладка между клиентом и API?
Зависит от API среды выполнения. Обычные десктопные браузеры дают API для работы с внутренним хранилищем сайта с определенной квотой на дисковое место. За пределы хранилища вылезти не могут. Другие среды дают другие возможности, та же Node - полный доступ к ФС.
господа жабаскриптизёры!
вот у питона есть pypy (питон написанный на питоне)
а на когда jsjs ? слабО?(надеюсь это их займёт на пару лет и мы перестанем видеть новости типа:
"очередной хипстер-н0ркоман написал очередную ненужную хрень на жабаскрипте")