Касательно AssemblyScript - предполагаю, что можно увеличить быстродействия обернув все обращения к массивам в unchecked, который отключает достаточно тяжёлые проверки на выход за границы массива. Около двух лет назад переписывал часть приложения на AssemblyScript. Для меня его киллер-фича - это возможность получить на выходе обычный JavaScript если скомпилировать его с помощью TypeScript - очень сильно помогает при отладке. Но язык был ужасно сырой, только в процессе переписывания я создал более десятка багов в их репозитории, которые, к слову, были оперативно исправлены. Однако даже после оборачивание всего в unchecked и частичного отключения встроенного GC код работал примерно с той же скоростью, что и оригинальный JavaScript, при этом всё ещё наблюдались отличия в поведении из-за багов, которые я уже не стал исследовать. Посмотрел сейчас в их репозиторий - и как будто за два года ничего принципиально не изменилось, куча достаточно мелких релизов с незначительными исправлениями.
У меня тоже была боязнь касания глаз, из-за которой всю жизнь носил очки вместо линз. Как не странно, полностью прошла после сделанной операции по коррекции зрения, видимо что-то типа шоковой терапии :)
В рунете тоже есть основная платформа для публикации (около)технических статей, и автора только что оттуда выпилили. Заставляет задуматься об опасностях централизации, особенно когда твоё мнение по какому-то вопросу не совпадает с общепринятым.
Проблема в том, что по-хорошему надо минифицифицировать не только приватные поля, а вообще все, за исключением тех, которые должны быть доступны через публичное API вашей библиотеки. Поэтому и сидим по-прежнему на closure compiler, который переименовывает вообще всё + Object.defineProperty('originalName', ...) для того, чтобы внешний код смог достучаться до избранных апишек. Грустно, конечно, что приходится использовать убогую систему типов closure compiler'а и терять кучу функциональности IDE, завязанную на typescript, но выигрыш в размере колоссальный.
По мне так мода и скорость разработки имеют мало общего. Раньше было круто полсайта одной командой RoR сгенерировать, а сейчас вообще избавляться от бэкенда, а потом полгода пилить на фронтэнде то, что на рельсах с html-шаблонами за неделю можно было сделать.
Всё верно. Уже 3 года как не использую Ruby / RoR, но до сих пор получаю огромное количество предложений от рекрутёров, которые ищут хоть кого-нибудь, кто согласился бы с этим работать. Но всё тщетно — нет больше лоска модности и молодёжности, плюс куча легаси проектов сомнительного качества (всему виной прошлая модность и молодёжность + очень низкий порог входа). Не мало бывших рубистов ушло в Elixir, и я не удивлюсь, если его ждёт такая же судьба.
Касательно AssemblyScript - предполагаю, что можно увеличить быстродействия обернув все обращения к массивам в
unchecked, который отключает достаточно тяжёлые проверки на выход за границы массива.Около двух лет назад переписывал часть приложения на AssemblyScript. Для меня его киллер-фича - это возможность получить на выходе обычный JavaScript если скомпилировать его с помощью TypeScript - очень сильно помогает при отладке. Но язык был ужасно сырой, только в процессе переписывания я создал более десятка багов в их репозитории, которые, к слову, были оперативно исправлены. Однако даже после оборачивание всего в
uncheckedи частичного отключения встроенного GC код работал примерно с той же скоростью, что и оригинальный JavaScript, при этом всё ещё наблюдались отличия в поведении из-за багов, которые я уже не стал исследовать. Посмотрел сейчас в их репозиторий - и как будто за два года ничего принципиально не изменилось, куча достаточно мелких релизов с незначительными исправлениями.У меня тоже была боязнь касания глаз, из-за которой всю жизнь носил очки вместо линз. Как не странно, полностью прошла после сделанной операции по коррекции зрения, видимо что-то типа шоковой терапии :)
В рунете тоже есть основная платформа для публикации (около)технических статей, и автора только что оттуда выпилили. Заставляет задуматься об опасностях централизации, особенно когда твоё мнение по какому-то вопросу не совпадает с общепринятым.
Проблема в том, что по-хорошему надо минифицифицировать не только приватные поля, а вообще все, за исключением тех, которые должны быть доступны через публичное API вашей библиотеки. Поэтому и сидим по-прежнему на closure compiler, который переименовывает вообще всё +
Object.defineProperty('originalName', ...)для того, чтобы внешний код смог достучаться до избранных апишек. Грустно, конечно, что приходится использовать убогую систему типов closure compiler'а и терять кучу функциональности IDE, завязанную на typescript, но выигрыш в размере колоссальный.