Вы в rust тоже использовали не оптимальный код? Ведь сравниваете заведомо неоптимальный node код с rust? На разных языках сравнивать стоит идеальный код с идеальным, иначе вы не получаете объективной картины.
Попробуйте хотя бы устранить известные недостатки nodejs кода. Наверняка получится также кратное ускорение.
Думается, что время энтузиастов в 3d заканчивается и начинается время широкого использования. В связи с этим карты стола прячутся, каждый выпускает свой несовместимый софт, в слайсерах появляются функции ai для включения правильных опций.
Статья говорит, что in/our есть, но использовать их не нужно. А если нужно, то использовать с осторожностью. Так если они всё-таки нужны, то хотелось бы реальные примеры где они помогают.
Да, это безусловно субъективное. И применительно к обсуждаемому приложению я не вижу большого числа жаргонизмов. Но, как мне кажется, если заменить жаргонизмы на родные слова,то это никого раздражать не будет. А раз это снизит напряжение аудитории, то надо делать :)
Сверьтесь со словарем и не тащите ненужный мусор. Например, "замьютить чат" можно заменить на "выключить уведомления". Возможно, молодежь это не раздражает, но когда тебе за 40 все эти словечки выглядят ка ляпы, на которые акцентируется внимание и морщится мозг. Программа ориентирована не только на 20-летних же?
Постоянно дрюкать огромную таблицу в базе на предмет наличия ключа идемпотентности будет сильно тормозить брокер. Если складывать в redis set или lru-кэш в памяти, то их память будет пухнуть под высокой нагрузкой. Нет ли каких-то готовых подходов к реализации идемпотентности?
Например, если у вас есть какое-то публичное api, то можно сделать метод генерации ключа и использовать завязанную на timestamp генерацию (uuid v7 или что-то свое). В этом случае за старым ключом можно сходить в базу, а за свежим в redis. Но это первое что пришло в голову, может кто-то уже погружался в тему и знает типовые промышленные подходы?
Имеется в виду какая-то рабочая база данных? Если вообще ни к какой БД не привязываться, то можно поломать слой сохранения/считывания данных и в тестах это не увидеть. Или вы имеете в виду, что для тестов надо всегда разворачивать какую-то базу с нуля?
Не у всех заводится. Я пробовал несколько раз уже. То elastic-apm-node какую-то метрику нереализованную использовал. Пофиксили. Сейчас на express споткнулся. Он пакет depd используется (зачем я хз), а тот завязан на формат stack-trace (объекты Callsite у node и строки с переносами у bun) и снова не заводится.
Понятно, что express уже давно можно было бы заменить на fastify или что-то иное, но у нас пока так.
В статье дается какой-то класс, но не видно как этот инструмент применяется. Нет примеров встраивания.
По самому классу, код не выглядит ни отшлифованным, ни готовым к использованию в промышленной системе.
Несколько примеров.
Использование console.log. Для системы с централизованным логированием весь этот вывод должен направляться в класс/интерфейс логгера с учетом уровней логирования.
Обработка ошибок. Наверняка часть ошибок не обязана выбрасываться наружу, а может быть обработана на месте, например, через повтор операции (бывает что сеть дала сбой и надо сделать переподключение/переотправку).
Часть последовательных await может быть объединена в Promise.all(). Например, вот эти две строки:
Чего из предложений js действительно не хватает, так это принятие Temporal всеми браузерами и нодой. Как в базу пойдешь за датой рождения, так драйвер тебе дату-время дает то со смещением часового пояса, то без.
Зачем этим вообще заниматься мессенджеру? Его задача заблокировать доступ к переписке чужим органам и открыть своим. Теже тенденции сейчас и в Европе происходят.
А всякими анализами программ и чего-либо еще могут и другие заниматься (во что я вообще не верю), например, ruStore.
Из статьи можно сделать вывод, что страны готовы тратить без особых ограничений. Раз они в гонке, то хотят получить какой-то приз за первенство в чем-то, чего еще никто не достиг, но в чем каждый уверен. Возможно, они бегут за AGI? А поскольку вкладываются в стартапы, то ищут новые идеи и запас времени еще есть.
Javascript не ограничивается фронтендом, а указанные в статье библиотеки нацелены лишь на него. Так и написали бы в заголовке, что речь только о фронте.
Вы в rust тоже использовали не оптимальный код? Ведь сравниваете заведомо неоптимальный node код с rust? На разных языках сравнивать стоит идеальный код с идеальным, иначе вы не получаете объективной картины.
Попробуйте хотя бы устранить известные недостатки nodejs кода. Наверняка получится также кратное ускорение.
Думается, что время энтузиастов в 3d заканчивается и начинается время широкого использования. В связи с этим карты стола прячутся, каждый выпускает свой несовместимый софт, в слайсерах появляются функции ai для включения правильных опций.
Ссылка на вторую часть битая.
Интересно было бы сравнить как дела с этим:
У конекрентов wb в РФ (Ozon, Megamarket, Yandex market).
У конкурентов зарубежных (AliExpress, Amazon, Lazada, ...)
Ну т.е. ориентируется ли кто-нибудь на незрячую аудиторию или считают, что эта аудитория может справиться с помощью друзей/семьи, не интересна вообще?
Зачем вы вылили свои эмоции в техническую статью?
Статья говорит, что in/our есть, но использовать их не нужно. А если нужно, то использовать с осторожностью. Так если они всё-таки нужны, то хотелось бы реальные примеры где они помогают.
Да, это безусловно субъективное. И применительно к обсуждаемому приложению я не вижу большого числа жаргонизмов. Но, как мне кажется, если заменить жаргонизмы на родные слова,то это никого раздражать не будет. А раз это снизит напряжение аудитории, то надо делать :)
Сверьтесь со словарем и не тащите ненужный мусор. Например, "замьютить чат" можно заменить на "выключить уведомления". Возможно, молодежь это не раздражает, но когда тебе за 40 все эти словечки выглядят ка ляпы, на которые акцентируется внимание и морщится мозг. Программа ориентирована не только на 20-летних же?
Постоянно дрюкать огромную таблицу в базе на предмет наличия ключа идемпотентности будет сильно тормозить брокер. Если складывать в redis set или lru-кэш в памяти, то их память будет пухнуть под высокой нагрузкой. Нет ли каких-то готовых подходов к реализации идемпотентности?
Например, если у вас есть какое-то публичное api, то можно сделать метод генерации ключа и использовать завязанную на timestamp генерацию (uuid v7 или что-то свое). В этом случае за старым ключом можно сходить в базу, а за свежим в redis. Но это первое что пришло в голову, может кто-то уже погружался в тему и знает типовые промышленные подходы?
Имеется в виду какая-то рабочая база данных? Если вообще ни к какой БД не привязываться, то можно поломать слой сохранения/считывания данных и в тестах это не увидеть. Или вы имеете в виду, что для тестов надо всегда разворачивать какую-то базу с нуля?
Не у всех заводится. Я пробовал несколько раз уже. То elastic-apm-node какую-то метрику нереализованную использовал. Пофиксили. Сейчас на express споткнулся. Он пакет depd используется (зачем я хз), а тот завязан на формат stack-trace (объекты Callsite у node и строки с переносами у bun) и снова не заводится.
Понятно, что express уже давно можно было бы заменить на fastify или что-то иное, но у нас пока так.
В статье дается какой-то класс, но не видно как этот инструмент применяется. Нет примеров встраивания.
По самому классу, код не выглядит ни отшлифованным, ни готовым к использованию в промышленной системе.
Несколько примеров.
Использование
console.log. Для системы с централизованным логированием весь этот вывод должен направляться в класс/интерфейс логгера с учетом уровней логирования.Обработка ошибок. Наверняка часть ошибок не обязана выбрасываться наружу, а может быть обработана на месте, например, через повтор операции (бывает что сеть дала сбой и надо сделать переподключение/переотправку).
Часть последовательных await может быть объединена в Promise.all(). Например, вот эти две строки:
Тут нам ничего не мешает создавать или проверять наличие таблицы пока выполняется какая-то сторонняя обработка.
Вот тут не ясно зачем вам await внутри callback если вы и так промис ждете из него, а обработку ошибок внутри callback не делаете:
У вас в close делается освобождение занятых классом ресурсов. Для этого в typescript завели специальный инструмент.
Чего из предложений js действительно не хватает, так это принятие Temporal всеми браузерами и нодой. Как в базу пойдешь за датой рождения, так драйвер тебе дату-время дает то со смещением часового пояса, то без.
Зачем этим вообще заниматься мессенджеру? Его задача заблокировать доступ к переписке чужим органам и открыть своим. Теже тенденции сейчас и в Европе происходят.
А всякими анализами программ и чего-либо еще могут и другие заниматься (во что я вообще не верю), например, ruStore.
А здесь не так сказано:
https://developer.android.com/reference/android/Manifest.permission
Allows applications to disable the keyguard if it is not secure.
Я это читаю как если нет защиты, то снимет блокировку, иначе нет. Кому в итоге верить?
Из статьи можно сделать вывод, что страны готовы тратить без особых ограничений. Раз они в гонке, то хотят получить какой-то приз за первенство в чем-то, чего еще никто не достиг, но в чем каждый уверен. Возможно, они бегут за AGI? А поскольку вкладываются в стартапы, то ищут новые идеи и запас времени еще есть.
Во сколько примерно обходится станок целиком? На ваши детали есть понятная разумная цена, но там еще много чего требуется докупить в других местах.
Возможно, у вас есть готовая смета?
Почему нельзя прервать процесс поиска через AbortController?
Что-то вроде gitlab с ассистентом получилось?
Javascript не ограничивается фронтендом, а указанные в статье библиотеки нацелены лишь на него. Так и написали бы в заголовке, что речь только о фронте.