Почему компания вроде jane street использует язык с gc вроде

ocaml? Разве такой финтех не юзает verilog c++ , и прочую суету

У них разные задачи есть, и далеко не везде супер-рилтайм требуется. Там, где требуется, используются FPGA, например (в каких-то из подобных задач). А где не требуется — OCaml (почему бы и нет).

К слову, современные GC всё более для рилтайма пригодны. State of the art сдвигается. Уже не удивишь гарантией задержки сборки в < 1ms (например, её дают специальные рантаймы для Java; или даже Golang).

Во-первых, high-frequency trading это их не основная специализация. Они маркетмейкеры и берут объемами и играют вдолгую и на рисках. Во-вторых, в HFT они всё-таки тоже умеют https://github.com/janestreet/hardcaml

Они не hft трейдеры, они хедж-фонд менеджеры

а ещё меня извращенцем называли...

Почему? Сейчас мода на высокоуровневые языки в проектировании чипов.

Ну Chisel довольно популярный а это скала дсл по сути

Сейчас ещё пилят circt, с поддержкой FIRRTL как раз из того самого Chisel

каким образом такая гарантия получается?

Да, гарантия — слишком громкое слово. Это не hard-realtime ведь. Да и невозможно такое на обычных операционных системах. Но это best-effort с хорошими статистическими характеристиками и низким на практике tail-latency. Что до способов реализации — они разнообразные. Например, Go принёс в жертву уплотнение кучи — объекты не перемещаются там. И это снижает throughput и портит локальность, но и уменьшает задержки. А ZGC в Java вообще "pauseless" (типа), т.к. мусор собирают треды фоновые.

Вот я о том же. Ага, ясно.

как понять hard-realtime?) что под этим подразумевается ? Сори за вопросы, просто я джун на гошки.

Это когда гарантии нужны. Иначе человек умрёт, или реактор взорвётся, например. А soft-realtime — статистическое.

https://stackoverflow.com/questions/17308956/differences-between-hard-real-time-soft-real-time-and-firm-real-time

Hard-realtime означает всеволишь константные кванты времени. Как правило ниже определенного (тем не менее произвольного) порога. То есть если наш системный таймер гарантированно производит импульс в Х миллисекунд и все обработчики таймера гарантированно отрабатывают до следующего импульса — это хард рил-тайм, даже при Х исчисляемого десятками, а то и сотнями. Противная ситуация должна приводить к системной ошибке. Соответственно «мягкий пиал-тайм» — это когда в некотрых ситуациях импульс таймера не случился и/или какие-то обработчики не обработались до следующего импульса. Например по причине блокировки или stop-the-world GC. В таких системах упущенный такт не приводит к системной ошибке Soft/hard рилтайм не имеет общего с отзывчивостью системы и тем более с гарантиями

запуском gc в отдельном потоке РТОС , или квитированием времени работы (для игр актуально) ?

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

Никак, мусор будет копиться до OOM

никак, максимум аварийный callback задаче пришлёт "ты обосралась в кучу, врубай тормоза и суши вёсла"

какая восхитительная гарантия

Нормальная гарантия. Гарантия длительности пауз есть? Есть. Гарантий отсутствия OOM при определенном GC pressure никто не давал. Трейдофы же всегда есть.

я не вижу ничего хорошего ни академически, ни тем более практически в том, чтобы сводить якобы к out of memory ситуацию, когда memory-то есть, просто за отведенный квант времени GC не успел ее вернуть в достаточном количестве.

Не почему есть, пока есть оно будет работать

вытеснение по кванту времени сработает.