А если серьезно, то выглядит симпатично, но не решает важные проблем:

Проблема Node.js не в встроенном API (уже понятно какие либы стоит или не стоит использовать), не в скорости компиляции (это оптимизируется), не в скорости скачки пакетов (это раз в месяц происходит) и даже не в скорости исполнения (любое CPU нагруженное задание так и так надо выводить в отдельный процесс)

Проблема Node.js в том, что чтобы написать на нем консольную утилиту, надо в нее запаковать саму ноду и весть это будет 200мб

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

Проблема Node.js в том что у нас есть TypeScript, но никто не хочет добавить стрикт мод, чтобы нельзя было импортировать JS, добавить вариации number (int64, float32, etc.) и начать компилировать TS в бинарный код, как Go

Проблема в отсутствии единого линтера, как в Go

Проблема в возможности сделать throw чего угодно

Bun не собирался решать эти проблемы, скорее он хотел дать полную обратную совместимость + всякие фишки и оптимизации

Если это приживется, класс буду использовать, если нет, жаль, надеюсь существующие решения будут пробовать с ним конкурировать и тоже станут лучше (вспомним как начал шевелиться npm после появления yarn)

Чего я реально жду, так это когда следующий движок ответвит TS разработчиков только с обратной TS совместимостью, компиляцией, паралелизмом и даст наконец-то отплыть от этого острова «это просто браузер на сервере» в «более медленная, но гибкая альтернатива Go»

Бро, у тя тело статьи в коменте лежит, так должно быть?

Да да, это референс к мему "ну умер и умер")

Хотя, я тут подумал... А вообще, я бы попробовал это как новый формат, основная фишка которого – сразу открывать комментарии и чтобы люди ближе были к тому, чтобы оставить комментарий + можно написать намного больше + лента будет чище, будут только заголовки или еще краткая подпись

По факту, как в Твитере (или как там сегодня это называется)

Кстати, насчет удобной библиотеки для удобного шеринга данных между потоками, в ноде есть нативный API SharedArrayBuffer, это как раз таки механизм который позволяет добавлять данные в массив чтобы он был доступен во всех потоках.

Но мне кажется если каждый поток будет менять этот буфер мы получить очередной memory leak, как с мидлварями которые постоянно меняют приходящие от юзера данные на каждой цепи, и мы можем получить бред, потому что нарушается chain of responsibility

Да, SharedArrayBuffer есть, но он неудобный – хочется иметь возможность автоматической (де)сериализации в этот SharedArrayBuffer причем как C binding, а не JS код

+ ты прав про потоки, но меня больше пугает не memory leak, а конкурентный доступ, а значит нам придется добавлять mutex как в С или read / write локи как в Go

Опять же, в read / write локах ничего страшного нет (кроме дед лока, но с этим можно бороться), проблема скорее в том, что Node.js дает нам треды (воркеры), дает нам шеренную память (SharedArrayBuffer), но не дает нам ни возможности использовать стандартные типы с этой памятью, ни инструментов управления конкурентным доступом к этой памяти

Это да, но честно говоря это не прям таки часто используется/то есть не оч частый use case в node.js разработке, как мне кажется

Хотя ты лучше знаешь

Я до сих пор не понимаю значения понятий mutex, semaphore

Если что узнаю это в чате у Шемсетдинова, он про такие вещи лучше шарит, и наверно где-то рассказывал

А конкурентый доступ нужен чтобы не доводить до race conditions?

Не используется, потому что нет удобного способа это делать)

Простой пример: если бы в Node.js можно было запускать треды по кол-ву ядер, c утилизацией этих ядер и I/O, а в этих тредах запускать воркеры с шеренной памятью, то цены не было бы Node.js

Это был бы кратный прирост скорости во всех аспектах языка при возможности обратной совместимости со всей текущей ковой базой

Да, "mutex" это примерно тоже самое что "read / write lock"

То есть, ты явно говоришь в какой-то момент времени "так, дайтека мне право на запись / чтение, я поедлаю что нужно и потом отдам вам обратно", если этого права на запись сейчас нет, от будет ждать

Могло бы выглядеть вот так:

- - - -
const shared = new SharedMemory("ping")

// ... как-то дальше попадаем в воркеры
await shared.writeLock() // 1. блокирую ресурс

const val = shared.value() // 2. достаю данные

if (val === "ping") shared.set("pong") // 3. изменяю их

await shared.releaseLock(); // 4. разблокирую ресурс
- - - -

Вот в случае с race-condition между 2 и 3 шагом shared мог быть изменен другим тредом, но поскольку я поставил на него лок записи, я точно могу знать, что этого не произошло

https://snyk.io/blog/node-js-multithreading-worker-threads-pros-cons/
тут про всё с тредами описано достаточно подробно)