Если кому интересно почему используется не C#, который является разработкой MS и во многих аспектах целится в ту же нишу, что и Go, то дизайнер Typescript дал развёрнутый ответ, в котором, если опустить то в чём C# не уступает Go, остаётся один важный пункт:
Совместимость с существующим JavaScript-кодом. Go позволил сохранить структурное сходство с текущей кодовой базой (функции и структуры данных, без использования классов), что сделало построчное портирование проще. Код на идиоматичном Go похож на код их оригинального компилятора.
C# тоже рассматривался как кандидат (был прототип), и это сработало бы, но его использование потребовало бы значительных изменений (в сторону OOP), так как изначально задача не предполагала полной переработки компилятора. По мнению Андерса, выбор Go был оптимальным для порта, а не из-за недостатков C#.
Этот аргумент звучит здраво, если объяснять почему не Rust. Без GC ручное управление памятью превратило бы порт в переписывание компилятора. Но если выбирали нативный язык с GC, то выбором Go, вместо C#, озадачены многие в обсуждении на GitHub.
Хотя, в одном из интервью, Андерс сказал, что C# bytecode-first, а NativeAOT слишком молод ("doesn't have a decade or more of hardening") и не на всех платформах поддерживается, в ответ на этот же вопрос. Учитывая, что он покинул в своё время команду разработки C# в пользу разработки Typescript, могу предположить, что он слегка предвзят.
В видео на канале Microsoft'а был показан кусок кода оригинального компилятора и нового, похожих на построчный порт. Там же был пример ускорения в 10 раз на большом проекте. Помимо просто ускорения, полученного от перехода на компилируемый язык, они теперь при проверке типов компилятором Typescript делят файлы на 4 части и строят графы типов параллельно и независимо друг от друга, что заставляет их делать лишнюю работу (для базовых типов) и увеличивает потребление памяти из-за этого, но зато быстрее.
В nginx, начиная с версии 1.25.3, в стандартной комплектации (за исключением *-slim образов), даже в nginx-alpine, идёт модуль njs (ngx_http_js_module). Это динамический модуль, добавляющий интерпретатор Javascript'а, называющийся QuickJS, от небезызвестного Фабриса Беллара, для конфигурации nginx.
На базе него есть официальный проект у nginx'а - https://github.com/nginx/njs-acme. Буквально строчкой в вашем Dockerfile и парой строчек в конфиге nginx'а Вы сможете реализовать получение сертификатов из ACME-совместимого источника.
Бросилась в глаза на одной из картинок скобка вместо смайлика в конце предложения — «Direct order. It's rude. Even for russians )».
По-моему только представители СНГ используют скобки (из-за лени?!) вместо полноценных смайликов.
В оригинальном документе называются два преимущества:
For starters, this drastically simplifies their logical names
для начинающих: сильно упрощает наименование файлов (default/index.html.twig вместо AcmeDemoBunde:Default:index.html.twig)
Another advantage is that centralizing your templates simplifies the work of your designers. They don't
need to look for templates in lots of directories scattered through lots of bundles.
Это и странно:
заглянул в TemplateListener — не увидел ничего страшного: угадывание путей шаблона и вызов render();
проверил несколько раз скорость работы с @Template и без — абсолютно равны;
выключил целиком TemplateListener (sensio_framework_extra.view.annotations: false) — тоже ничего не изменилось;
Конечно, какой-то оверхед присутствует (то же угадывание путей шаблонов), но в целом описанная в документе разница (5 мс и 26 мс) недостижима.
Кардиологи станут самыми высокооплачиваемыми врачами — за доступ к секретной информации (кардиограмме), а от больниц будут требовать высокий уровень защиты личных данных.
проблема автоматического анализа в том, что название контрактов не всегда отображает реальные работы: так, например, обычные стеклопакеты обзывают системой вентиляции и климатического контроля (реальный пример) :)
или в названии контракта указана стройка (потому что деньги выделялись на стройку), а внутри — яхта :)
реальные вещи пишут в ТЗ, а единого формата для документации, увы, нет.
открывая пост — ожидал увидеть описание технологии работы, используемые эксплоиты…
увы, прошли времена лоулевельного ковыряния в прошивках телефонов, сейчас все можно сделать все одной кнопкой через зашитые разработчиком интерфейсы.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Если кому интересно почему используется не C#, который является разработкой MS и во многих аспектах целится в ту же нишу, что и Go, то дизайнер Typescript дал развёрнутый ответ, в котором, если опустить то в чём C# не уступает Go, остаётся один важный пункт:
Совместимость с существующим JavaScript-кодом. Go позволил сохранить структурное сходство с текущей кодовой базой (функции и структуры данных, без использования классов), что сделало построчное портирование проще. Код на идиоматичном Go похож на код их оригинального компилятора.
C# тоже рассматривался как кандидат (был прототип), и это сработало бы, но его использование потребовало бы значительных изменений (в сторону OOP), так как изначально задача не предполагала полной переработки компилятора. По мнению Андерса, выбор Go был оптимальным для порта, а не из-за недостатков C#.
Этот аргумент звучит здраво, если объяснять почему не Rust. Без GC ручное управление памятью превратило бы порт в переписывание компилятора. Но если выбирали нативный язык с GC, то выбором Go, вместо C#, озадачены многие в обсуждении на GitHub.
Хотя, в одном из интервью, Андерс сказал, что C# bytecode-first, а NativeAOT слишком молод ("doesn't have a decade or more of hardening") и не на всех платформах поддерживается, в ответ на этот же вопрос. Учитывая, что он покинул в своё время команду разработки C# в пользу разработки Typescript, могу предположить, что он слегка предвзят.
В видео на канале Microsoft'а был показан кусок кода оригинального компилятора и нового, похожих на построчный порт. Там же был пример ускорения в 10 раз на большом проекте. Помимо просто ускорения, полученного от перехода на компилируемый язык, они теперь при проверке типов компилятором Typescript делят файлы на 4 части и строят графы типов параллельно и независимо друг от друга, что заставляет их делать лишнюю работу (для базовых типов) и увеличивает потребление памяти из-за этого, но зато быстрее.
Примеры цифр ускорения на различных проектах есть в оригинальном посте в DevBlog.
Оставлю сообщение для тех, кто пришёл из Гугла.
В nginx, начиная с версии 1.25.3, в стандартной комплектации (за исключением *-slim образов), даже в nginx-alpine, идёт модуль njs (ngx_http_js_module). Это динамический модуль, добавляющий интерпретатор Javascript'а, называющийся QuickJS, от небезызвестного Фабриса Беллара, для конфигурации nginx.
На базе него есть официальный проект у nginx'а - https://github.com/nginx/njs-acme. Буквально строчкой в вашем Dockerfile и парой строчек в конфиге nginx'а Вы сможете реализовать получение сертификатов из ACME-совместимого источника.
По-моему только представители СНГ используют скобки (из-за лени?!) вместо полноценных смайликов.
для начинающих: сильно упрощает наименование файлов (default/index.html.twig вместо AcmeDemoBunde:Default:index.html.twig)
упрощает поиск шаблонов для дизайнеров.
Как по мне — так оба довода сомнительны.
заглянул в TemplateListener — не увидел ничего страшного: угадывание путей шаблона и вызов render();
проверил несколько раз скорость работы с @Template и без — абсолютно равны;
выключил целиком TemplateListener (sensio_framework_extra.view.annotations: false) — тоже ничего не изменилось;
Конечно, какой-то оверхед присутствует (то же угадывание путей шаблонов), но в целом описанная в документе разница (5 мс и 26 мс) недостижима.
или в названии контракта указана стройка (потому что деньги выделялись на стройку), а внутри — яхта :)
реальные вещи пишут в ТЗ, а единого формата для документации, увы, нет.
увы, прошли времена лоулевельного ковыряния в прошивках телефонов, сейчас все можно сделать все одной кнопкой через зашитые разработчиком интерфейсы.