Представлен (http://allievi.sssup.it/techblog/archives/880) релиз проекта Duetto 0.9.6 (http://leaningtech.com/duetto/), в рамках которого подготовлен открытый инструментарий для разработки клиентских и серверных web-приложений на языке C++, а также набор средств для портирования существующих C++ программ для работы в Web-браузере. Код распространяется (https://github.com/leaningtech) под свободной лицензией UI/NCSA (http://llvm.org/releases/2.8/LICENSE.TXT), также используемой в проекте LLVM. Библиотеки поставляются под лицензией GPLv2+.
По своей сути Duetto напоминает систему Emscripten (http://www.opennet.me/opennews/art.shtml?num=35313) и также использует наработки LLVM для обеспечения компиляции кода C++ в представление на языке JavaScript. Ключевым отличием Duetto от Emscripten является достижение существенно более высокой производительности результирующего JavaScript-кода и предоставление средств для использования из С++ программ всех возможностей DOM и HTML5, в том числе WebGL (http://leaningtech.com/duetto/blog/2013/07/16/CMake-Bullet-W.../). Duetto не пытается как Emscripten эмулировать традиционное адресное пространство при помощи типизированных массивов, а обеспечивает прямой маппинг C++ объектов в объекты JavaScript, что позволяет снизить потребление памяти, так как сборщик мусора JavaScript имеет возможность удалять неиспользуемые объекты. Duetto также поддерживает использование стандартных библиотек libc и libc++, и позволяет применять инструменты сборки cmake/autotool.
По поставленным перед проектом задачам Duetto выходит за рамки простого компилятора из C++ в JavaScript и позиционируется как платформа для создания интегрированных клиент/серверных web-приложений на языке C++. В существующей практике, обычно используется выполняемый в браузере фронтэнд, написанный на языке JavaScript или компилируемый в JavaScript из CoffeScript, Microsoft TypeScript, Google Dart, Google GWT, с раздельной серверной частью на языках PHP, Python, Ruby или JavaScript/node.js. Duetto предоставляет средства для создания целостных web-приложений на языке C++, в которых бэкенд и фронтэнд поддерживаются в единой кодовой базе. В процессе компиляции серверная часть компилируется в нативный код, а интерфейс преобразуется в JavaScript-представление.
Новый выпуск примечателен предоставлением средств для отладки в браузере web-приложений на языке C++. При этом несмотря на то, что для выполнения код транслируется в JavaScript, отладка производится по исходным текстам на языке C++. Например, при возникновении ошибки отображается участок кода на C++, возможна установка точек останова в коде C++ и построчного пошагового выполнения С++ кода (все действия осуществляются с кодом С++, но фактически при отладке выполняется сгенерированный на основе этого кода JavaScript). Для отладки скомпилированного в JavaScript кода используется развиваемая компанией Google технология Source Map (https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiO...) (Duetto бесшовно генерирует Source Map на основе кода на языке C++).
<center><a href="http://allievi.sssup.it/techblog/wp-content/uploads/2014/04/... src="http://www.opennet.me/opennews/pics_base/0_1397836508.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
Кроме того, в новом выпуске представлена серия значительных оптимизаций, позволившая сократить потребление памяти и снизить нагрузку на сборщик мусора. Обеспечена поддержка вызовов стандартной библиотеки std::map, std::multimap, std::unordered_map, std::std, std::multiset и std::unordered_set.URL: http://allievi.sssup.it/techblog/archives/880
Новость: http://www.opennet.me/opennews/art.shtml?num=39600
Офигеть! Дайте две. :-о
Очень интересно, жаль что не показали что нить из демо.
"В процессе компиляции серверная часть компилируется в нативный код"
Для неё Native Client нужен или нет? А то он запускает машинный код в различных браузерах и на разных ОС. А на снимке Chromium.
> "В процессе компиляции серверная часть компилируется в нативный код"
> Для неё Native Client нужен или нет? А то он запускает машинный
> код в различных браузерах и на разных ОС. А на снимке
> Chromium.Серверная часть - это та часть, которая выполняется на стороне веб сервера.
Серверную часть они почему-то решили делать с нуля - скомпилированный бинарник сам биндится на порт и отвечает на http запросы, используя либу libpion.
Хотя его, конечно, все ещё можно спрятать за nginx, странно, что они не используют fastcgi/wsgi/etc для этих целей.
Благодарю, КЭП, но речь была не об этом.
> Благодарю, КЭП, но речь была не об этом.Оно компилится в бинарник, без всяких браузеров.
ок
>Какие хромы на сервере?Есть хромы для серверов.
>>Какие хромы на сервере?
> Есть хромы для серверов.Если вы про nodejs и v8, то там этим даже не пахнет.
Использование C++ обычно пытаются оправдать производительностью. А здесь? Это для тех, кто готов на все, лишь бы не изучать другой язык?
На js уже всё пишут, он даже для распределенных высоконагруженных систем подходит. За ним будующее!
>будующееО всеспящий Ктулху, пусть это будет невероятно тонкий сарказм, а не индикатор общей грамотности JavaScript-тистов///
Js как раз позволяет снизить нагрузку с высоконагруженных систем,
выполняя часть функционала на пользователе. Будущее, конечно, у этого
не особо хорошо спроектированного языка несомненно есть,
поскольку сейчас бум веб творчества, всем нужны сайты. Каждый чих
порождает новый сайт, даже багу heartbleed сделали сайт.
Боюсь показаться занудой, но ведь собственно "подходимость" javascript как языка, то есть синтаксис и семантика, не имеет отношения к проектам типа node.js, выполняемых в v8. Вы же на это намекаете?Будущее мне понятно. Раз у нас есть суперпрограмма, которая уже без пяти минут ОС (браузер) с виртуальной машиной и песочницами, то, действительно, часть вычислений с серверов имеет смысл переложить на пользователей, не зря же они себе всякие i7 покупают.
Непонятно только причем тут именно js, сложный и неудобный язык?
В Emscripten основная идея в портировании существующего кода. Портировали удачно и эффектно, но ни для чего кроме игрушек пока не используют так чтобы с пользой.
Здесь очередной Web-фреймворк, теперь банановый. Тоже игрушка, но другого плана.
А здесь - промышленный строго типизированный язык, пригодный для написания больших проектов. Впрочем, это решает только часть проблемы - безумный комплект "DOM/HTML/CSS" остаётся всё тем же - громоздким и плохо предсказуемым.
> Использование C++ обычно пытаются оправдать производительностью. А здесь? Это для тех,
> кто готов на все, лишь бы не изучать другой язык?Ага, порадовало предупреждение:
Warning: Depending on the browser and system configuration this demo may use a lot of memory
> прямой маппинг C++ объектов в объекты JavaScript, что позволяет снизить потребление памяти, так как сборщик мусора JavaScript имеет возможность удалять неиспользуемые объектыJavaScript позволяет, но как это задекларировать внутри C++ ?
или же получается что это не C++ а лишь язык похожий на него, но существуенно отличающийся при детальном осмотре.
>> прямой маппинг C++ объектов в объекты JavaScript, что позволяет снизить потребление памяти, так как сборщик мусора JavaScript имеет возможность удалять неиспользуемые объекты
> JavaScript позволяет, но как это задекларировать внутри C++ ?Так же как и в JavaScript -- никак^W удалить все ссылки на объект.
>>> прямой маппинг C++ объектов в объекты JavaScript, что позволяет снизить потребление памяти, так как сборщик мусора JavaScript имеет возможность удалять неиспользуемые объекты
>> JavaScript позволяет, но как это задекларировать внутри C++ ?
> Так же как и в JavaScript -- никак^W удалить все ссылки на
> объект.в C++ же "указатели" а не "ссылки" :-)
["ссылки" тоже есть.. но C++ "ссылки" это не тоже самое что "ссылки" Javascript]
Что только ни придумают, на какие хитрости только ни идут с мухлежом ведванольных "построителей чудес" (JavaScript, HTML5), но лишь бы не использовать Java-апплеты!
а из других языков много чемпионов по числу уязвимостей превосходящих Яву?
Сударь, с вашими аплетами я могу порекомендовать вам посетить Криптон.
> Что только ни придумают, на какие хитрости только ни идут [...], но лишь бы не использовать Java-апплеты!если эти Java-апплеты такие чудесные -- то не хочешь ли ты протолкнуть идею чтобы в библиотеки для KDE и GNOME -- включили бы функции вывода Java-апплетов внутри GUI-программ?
представляешь как здорово было бы -- открываешь ты какой-нибудь музыкальный проигрыватель -- а он в свою очередь подгружает Java-апплет!
вот веселье-то будет и для разработчиков и для пользователей :-) :-D .. я уже сейчас предвкушаю тонны нецензурной лексики :-)
Вроде скриптовые языки с утиной типизацией для того и придумывали, чтобы разрабатывать веб-приложения _быстро_. А сейчас - Facebook выпустил Hack (подмножество PHP со статической типизацией), MS выпустил TypeScript (JS со статической типизацией), Google пропихивает Dart (замена JS, язык со статической типизацией)Тут авторы еще дальше пошли, C++ под веб пропихивают. Мне кажется это глупо в квадрате. Во-первых, на С++ писать дольше и сложнее. Во-вторых, при трансляции в JS многие прелести C++, а в частности скорость, в значительной степени потеряются, т.к. JS код останется JS кодом и будет выполняться всё теми же JS движками
В чём смысл, кто объяснит?
Схрена дольше? Схрена сложнее?
>Facebook выпустил Hack
>MS выпустил TypeScript
>Google пропихивает Dartи что?
В том, что эта быстрота начиная с определенного размера проекта оборачивается граблями. Пока JS использовался для оживляжа страничек и реализации отдельного не слишком важного функционала - он был приемлем. Когда дело дошло до больших приложений - приходится что-то решать.Чем больше проект - не важно, IT или что-то ещё - тем важнее формализация взаимодействий. К примеру, мелкая контора из пяти человек может работать практически без бюрократии. Если у вас пара сотен сотрудников - вы не обойдётесь без должностных инструкций, формально прописанных полиси и тому подобного. Собачью будку или сарай можно просто построить. Для многоэтажки не обойтись без чертежей, строительных норм и тому подобного. Не потому что это кому-то нравится, а потому что без этого вы вообще ничего не построите. Для общего развития - вот: http://rusnano.fizteh.ru/courses/levenchuk/ - рекомендую хотя бы первую лекцию глянуть.
> Чем больше проект - не важно, IT или что-то ещё - тем важнее формализация взаимодействий.кто же вам мешает сделать формализацию для процесса разработки на JS ?
для этого не обязательно придумывать другой язык, который конвертируется в JS.. всё можно организовать на самом JS..
посмотрите крупные проекты на JS -- там всё формализованно без всяких TypeScript и Dart.
> Мне кажется это глупо в квадрате.мне тож так кажется :-)
писать приложения на Javascript
--- это быстрая разработка но медленная скорость полученного приложения..писать приложения на C/C++
--- это медленная-и-сложная разработка но быстрая скорость полученного приложения..писать приложения на C/C++ с компиляцией в Javascript
--- это медленная-и-сложная разработка и медленная скорость полученного приложения..:-)
а Emscripten хорош лишь только тем что с помошью него -- можно скопилировать в Javascript те алгоритмы, которые были *раньше* реализованы на C/C++..
(портировать уже готовое C/C++ приложение с использование Emscripten -- может занять времени меньше чем разработать всё с нуля на Javascript)
а чём же прелесть Duetto -- вообще не понятно.
Плюсую.писать приложения на Java без компиляции в JavaScript, а с JIT-компиляцией в код процессора
--- это быстрая разработка с потреблением большого количества памяти, но с высокой скоростью и безопасностью выполняемого приложения в конечном итоге.Ошибки в Java быстро находятся и исправляются благодаря развитым инструментам наблюдения и профилирования байт-кода. Повсеместно на Java принято использование автоматических модульных тестов, а в других средствах программирования на других языках это всё ещё находится в зачаточном состоянии, если вообще что-то есть. В других языках практически нет способа объективной оценки подтверждения корректности программ кроме ручного тестирования каждой функции.
Не забывайте, мы говорим о client-side приложениях.
Апплеты я уже давно не видел в вебе и видеть не хочу. Это спорно, вы можете доказывать мне что я не прав и должен любить джаву, но по факту её на client side нет (или количество пренебрежимо мало).Иными словами, у вас жуткий оффтопик.
> Повсеместно на Java принято использование автоматических модульных тестовВ энтерпрайзе - возможно. А, например, под тот же Андроид на той же Жабе пишет конный и пеший. И хорошо, если хотя бы один из десяти этих пишущих вообще знаком с таким термином.
Каким бы языком ни пользовались для раздувания веб-пузыря - это заведомо будет массовый говнокод, без острой необходимости никем и никогда не разгребаемый. Сейчас под эту раздачу попал Джаваскрипт, но если его заменит что-либо другое - результат будет аналогичным.
А вы давно в программировании? Просто, как мне кажется, существует много других обстоятельств помимо "утиной" или "не утиной" типизации.Например:
поддержка модели акторов (dart, м.б. scalajs),
поддержка функционального программирования (haskell-js, scalajs),
поддержка макросов в стиле плюсов,
поддержка макросов в стиле lisp/clojure,
поддержка макросов в стиле AST-трансформаций (scala, rust,..),
weak и strong typing (не путать с динамичностью!)
и так далее и тому подобное.Причём по моему комменту может быть видно что я всякими "Скалами" и статическими языками увлекаюсь -- а если бы взгляд был шире, то я бы сказал и почему питоно/php/ruby-подобные языки в JS компилят.
И, кстати, вот это не совсем верно, т.к. вы не забыли о том же asm.js:
> JS код останется JS кодом и будет выполняться всё теми же JS движками
> Во-первых, на С++ писать дольше и сложнее. Во-вторых,
> при трансляции в JS многие прелести C++, а в частности скорость,
> в значительной степени потеряются, т.к. JS код останется JS кодом и
> будет выполняться всё теми же JS движками
> В чём смысл, кто объяснит?Компании типа фейсбука могут себе позволить потратить кучу человеко-месяцев, чтобы их приложение работало на 10% быстрее (т.е. даже небольшой профит - уже хорошо).
Просто они решают конкретные проблемы, которые стоят именно перед ними.
И если у вас нет таких проблем (и таких ресурсов), никто не заставляет вас применять их решения.К примеру, в mail.ru, лет 10 назад тоже писали свои велосипеды, которые им требовались.
Им нужно было, они и писали.
Сейчас модно со всеми делиться своими наработками.
Но от того, что вы можете это скачать, не значит, что вам это нужно.
наконецто можно будет писать на нормальных языках вместо этого убогого js
> наконецто можно будет писать на нормальных языках вместо этого убогого jsНе забывайте, что потом все равно код транслируется с нормального языка в убогий js
Пока школота на нормальном языке неделю борет одну утечку на ровном месте, жалкие ремесленники с яваскриптом лепят по два безглючиных и в меру шустрых приложения в день.
скорее бы Qt5 портировали на эту хрень, чтобы можно было на Qt для Firefox OS писать
