кстати, на котлине/свифте это дело выглядит очень даже вкусненько, что не скажешь про делфи)

последний раз, когда писал - думал: "а зачем я писал на нем, лучше просто на джсе все делал"

Ви хоч поділіться, шо саме не сподобалось

На TS можно по-разному писать. Можно построить тоталитарный режим вокруг типизации. И потом тратить кучу времени на то, чтоб тайпчеккер убедить, что твой код правильный. Зато потом запускаешь его - и все сразу работает.

А можно чисто местами накидывать типчики, чтоб в редакторе автоподстановка ±норм работала. А баги уже на твоей совести остаются.

Кому-то норм по одному пути идти, кому-то по другому.

эх
изначально спор был о ноде с пыхой)

а можно упороться наглухо и писать на хаскеле с TS транслитерацией)

а можно еще писать с++ модули для ноды с напи

модули для ноды можноо вообще на чем угодно писать

When это синтаксический сахар для switch. Сахар, не фича
Nullable типы это точно не изобретение котлина, Википедия говорит что они были ещё в, простите, vb.net
Inline классы - возможно, нововведение. Но по большому счёту опять же сахар для свойств, которых где только нет
Suspended функции - ну простите, на котлинланг прямо ссылаются на async/await из js и c#, каналы го и генераторы/yeld того же шарпа и питона

ну если с такой стороны...то можно
но опциональность такой вещи как типизация - наверное будет пораждать еще больший хаос?)

Разрабы, которые вместо багфикса тупо закрывают ишьюзы.

Коллеги, написал класс, в нём идёт открытие вэбсокетов и структурирование данных, с зписью в хранилище Эффектора.

создал массив, в которой запихнул данные которые нужны для запусков вэбсокетов.

И отмаптил это всё вот так:

const WSLauncher = (arr) => {
    return arr.map((d, i) => {
        return new WSConstructor(d.data).loadData()
    })
}

WSLauncher(dataArr)

и теперь смотрю как сервер отожрал 30% производительности процессора.... хотя у меня всего 40 вэбсокетов открыто, а мне надо таких 1к открыть...

Как мне понять на каком узле самая большая нагрузка, чтобы понимать где оптимизировать?

const WSLauncher = (arr) => {
    return arr.map((d, i) => {
        return new WSConstructor(d.data).loadData()
    })
}

WSLauncher(dataArr)

flamegraph

о. спасибо )

На практике нет. У меня серверный проект. Типы определены для некоторых DTO (в основном для входящих JSONов), для всех Entity. Если делаю какие-то запросы в базу через raw sql, то типизирую результат (часто inline, не завожу для этого отдельный интерфейс)

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

Итого:
1. типов достаточно, чтобы VSCode или другой редактор мог подсказывать тебе, что где приходит.
2. почти нет generics, которые определяешь ты. Нет всяких keyof, ReturnType<T>, каких-то трехэтажных объявлений.
3. TS только помогает, иногда ему нужно где-то что-то подсказать, но обычно 1 указанный тип облегчает тебе жизнь на следующие 10+ строк.
4. Выводилка типов TS мешает только при работе со сторонними либами, если там типы кривые. На 1000 строк приходится в среднем один случай, где через unknown или any приходится исправлять типы.

я был на вашей лекции про утечки памяти, где вы рассказывали и про С  и про Раст
а на чем вы сейчас в основном пишите? на ТСе?

Да

Можно ли как то узнать вес данных которые приходят с клиента сразу же как сервер получил запрос? Общее количество чанков или байтов например, ну не знаю. Перерил всю документацию по стримах не нашел ничего, видимо плохо искал, либо в встроенном пакете нет такого.

Каждый чанк - буффер (или его можно к нему привести). Берем байтсайз буффера и складываем их для каждого чанка.

Это я понимаю, но узнать объем данных таким методом можно только после того как передача данных будет завершена