да, ищу решение)

Вот Rust для этой задачи выглядит очень логичным выбором.

Ещё, может, Zig.

а почему AssemblyScript тогда не выглядит логичным выбором (если мне не хочется изучать отдельный синтаксис и я привык к ts) ?

Потому что Wasm даже с файлами работает кое-как (через WASI, который очень низкоуровневый) + библиотек очень мало.

Кроме того, AssemblyScript только на первый взгляд выглядит как TS, на поверку оказывается очень мало общего.

Так что я бы на Вашем месте уже перестал ныть про синтаксис и начал пытаться принимать рациональные инженерные решения. 😁

Это, в общем, дружеская шутка — я Вас, @xbgnx , уважаю, и нисколько не пытаюсь принизить. Не поймите меня превратно. ✌️

А может топикстартер не хочет так быстро, и просто не понимает, что можно и посвопать по 4GB.
Были тесты вообще, хотя бы с неба?

ок) но я уже написал выше, даже если на напишу это решение на расте то там будет точно такой же код как на жс потому что код работы с этой памятью будет представлять собой такую же арифметику с ифами и циклами. В общем меня сейчас js (или точнее тайпскрипт) полностью устраивает и я уже остановился на решении аллоцировать н-буферов по 4гб (раз больше нельзя) но все же хотелось бы найти (если возможно) решение аллоцировать непрерывный кусок памяти (чтобы не заниматься этой трансляцией адресов по н-буферам)

какие тесты? причем здесь своп (и ram-диск в вопросе выше)? я говорю про хранение исключительно в оперативке, то есть сервер стартует дальше считывает подготовленный массив в typed-array и дальше уже обрабатывает бизнес-запросы (вычисляет нужные смещения и читает нужные байты или делает поиск)

я к тому, что в 99% случаев хранить все нет смысла в рам.
можно и с диска прочитать.

А рам диск как бэ и представляет файловый дескриптор который на самом деле в RAMе.
И там ограничения только сколько он влезет в RAM, + всякие линуксы умеют мапить файлики частично (на том же свопе)
Я не думаю, что в любом случае хавать 50GB Ram уместно

да какой диск? тут будет не просто хранение данных в оперативке а будут использоваться оптимизации под конкретный бизнес-кейс (иначе память обойдется в копеечку) - сжатие указателей-оффсетов, чисел (в пределах диапазона например хранение цены не в 4 байтах а в 20 битах) ну и будут отдельно собираться boolean-поля в виде битов для более эффективного поиска

удачи распаковать бит в JS.
Ну или в любом случае данные будут выравнены и на каждый шейп будет свой парсер.
А то кешмисы будут адцкие, если начать побайтам прыгать туда-сюда.

Допустим у тебя есть шейп:
1 бит на флаг, 20 битов цена, и ...все.
21 бит на шейп. Хорошо, а что делать с ещё 11 (uint32 слово) ?) Выкинуть или отдать на другой.
Я бы выровнял (выкинул), чтобы не читать из предыдущего.

А ещё это как-то надо записать в массивчик до этого, это ещё одна задача.

В принципе, вот это вот БД умеют и так...

Что касается выравнивания то это дилемма между скоростью и затратами памяти и кстати выравнивание нафиг не нужно если эти данные будут считываться последовательно. И 20 бит в которых будет храниться цена выравнивать не нужно если дальше в следующих битах будет храниться уже другой параметр (например количество продаж) и данные будут считываться последовательно (при поиске)

о каких бд идет речь?

А многопоточной поиск по выравненным данным не)?
Бинарный, ещё тоже очень неплохо бы если было бы выровнено

Да вроде СУРБД умеют. А так-то ещё есть колоночные (columnar) БД, например.

выравнивание данных это уже довольно значительные затраты по памяти (да и смысла нет если считываться будут последовательно и даже не по байтам а регистрами по 64бита или даже 128 бит если взять wasm simd). То есть там все будет упаковано максимально сжато под конкретный бизнес-кейс иначе для хранения 10млн товаров где у каждого товара есть еще цвета а у каждого цвета размеры а у каждого размера история изменения цены и продаж за каждый день - тут каждый лишний байт для выравнивания будет стоить лишний гигабайт оперативки (при хранении истории за год)