Кстати, вопрос пишущим на JS:

Мне необходимо ограничить всячески любое асинхронное взаимодействие. Я выпилил setInterval, setTimeout, частично Promise*. Но на этом моя фантазия сегодня закончилась

Как еще можно порождать асинхронный/отложенный код в JS? Напишите в комментариях идеи/мысли пж

* Частично, т.к. асинхронные функции в результате вызова дают Promise. Пока не придумал что с этим делать :(

UPD: перепроверил, спасибо за советы!

Очередная подтверждение для меня, почему я с уважением отношусь к сони (да, я сонибой, если вы забыли).

Каждый месяц, они оплачивают мне подписку на сетевые сервисы (причём не самую дешевую, а с огромным каталогом игр)

Сони ван лав

Пишу сейчас асинхронный рантайм сервера (+ пуллпотоков для тяжёлых задач) и подумал, а сколько времени все "тесты" выполняются

Ожидал конечно, миллисекунды, но когда увидел (!) микросекунды (а это напомню 0.000_001 секунды!) вообще удивился

Вау *-*

UPD: это еще дебаг билд, в релизе на 150-300µs быстрее — ~400-500µs

Сегодня планировал написать небольшой пост про асинхронные рантаймы в Rust, но пока что не срослось

Поэтому, чтобы отвлечься хочу поделиться находкой в инструментальной музыке:

Ryo Fukui, джазовый пианист, который очень круто наваливает. Если хочется сложной по звучанию музыки, которая щекочет нервные окончания, это самое оно

Трек Early Summer из альбома Scenery (シーナリィ) просто невероятный!

А кто что классного нашёл по музыке (любой) недавно?

Начиная с этой пятницы, будет новая рубрика: веб-комикс, который меня тронул. может даже, дважды в неделю

(с) PBFcomics / Ellis Rosen

сегодня с психоаналитическим уклоном :)

### Небольшая история про Rust-каналы и асинхронные функции

Предыстория: когда-то обсуждая* горутины из Golang с позиции их взаимодействия с друг другом, мне показалось неудобным, что всё взаимодействие идёт исключительно** через каналы. Видимо, я тогда был разбалован долгой работой на Nodejs и в целом JS Promise'ами, которые позволяли просто возвращать результат.

В чём проблема передавать канал как аргумент? Конечно ни в чём на самом деле, но хотелось бы иметь возможность получать результат как через обычную функцию, через возврат. Иными словами, вопрос эстетики/эргономики + небольшого снобизма.

Почему я вспомнил эту историю?

Мне, уже на Rust, потребовалось запускать отдельные OS-потоки*** в detached (отвязанном) для каждого отдельного JS runtime. Т.к. я не могу дожидаться завершения потоков (они работают, пока их не попросят остановиться), то чтобы получить результат мне приходится использовать каналы (прямо как в Golang).

Но чем хорош Rust, при желании могу сделать функцию — см. скиншот. И как пользователь этой функции буду использовать просто результат, не думая как он вообще получается — из канала, из другого потока, из другого асинхр... в общем, не думая как этот black box работает.

В общем удобно и мой внутренний задротский педант рад :)

Расскажите в комментариях, как радовали недавно своего внутреннего кодового педанта :)

—

* Разговор был давно, могу что-то упускать, т.к. Golang я только читаю, но не пишу
** Если нет, расскажите в комментариях
*** К сожалению, специфика работы Rust-обвязки вокруг JS-движка.

С одной стороны очень расточительно иметь целый поток, с другой стороны, они стартуют только в самом начале.
К тому же, планировщик Linux супер-круто раскидывает работу по ним (потокам процесса).

Или Linux стал лучше, или у меня железо мощнее стало, или всё вместе — что в итоге не создаёт проблемы.

Раньше, когда я был С++-бекендером, меня таким можно было пугать как скримером :)

Или пора заканчивать на сегодня кодить, или это и правда имеет смысл

Залип на пару минут на выборе между импортами :)

Есть необходимость, для простоты, сделать импорт A, B, C, D, которые лежат на разной глубине одного модуля

1) Импортировать с каждого подвложенного модуля на отдельной строке
2) Импортировать с одного модуля всё сразу

—

У каждого варианта, есть свои преимущества, 1) даёт более красивый git diff, 2) более компактные импорты

Вопрос чисто в духе табы или пробелы, но всё же :)

Ниже будет опрос) Помогите мне выбрать)

### Параллельный запуск JS кода и кустарные бенчмарки

Было очень интересно, сколько же времени займут параллельные запуски JS отдельных окружений в среде с ограниченными ресурсами (моём ноуте).

После полировки кода и выбора подхода с потоками (см. предыдущий пост). В качестве тестового стенда симулируем 4000 игроков, код каждого выполняется 100мс

Получились следующие результаты:
- Ожидаемо создание и подготовка* потоков заняла много времени: ~40 секунд
- Долговато, но для разовой акции терпимо
- Общий тик игрового сервера занял ~930-1000 миллисекунд
- Что в общем-то отличный результат! Честно говоря, рассчитывал на худшие результаты

Но стоит отметить, что для симуляции долго работающего кода использовалась наивная синхронная реализация функции sleep() (см 2ой скрин ниже). Ради интереса посмотрел, сколько раз она успевает вызваться для каждого потока.

Результаты для 4000 "игроков" следующие: от 8_000 до 12_000. Для 10 "игроков" от 200_000 до 400_000. Пока что рабочая гипотеза, что V8 движок начинает тротлить вызовы к API времени, чтобы снять нагрузку.

Хоть и разница существенная, но это не должно стать проблемой для реальных игроков в теории. Поэтому очень даже доволен промежуточным результатом :)

—

* Создание асинхронного runtime, и прочий bootstrap код

Вау, Adobe очень крутые