Jane Street Group получила $39,6 млрд торговой выручки в 2025 году, установив рекорд Уолл-стрит.
Фирма превзошла JPMorgan Chase & Co. (Нью-Йорк:JPM) на 11% по итогам года, имея в штате всего 3 500 сотрудников. Jane Street генерировала в среднем более $11 млн выручки на одного работника.
https://ru.investing.com/news/economy-news/article-93CH-3203846
https://t.me/emacsway_log/1765
Стажеры алгоритмических хедж-фондов, таких как Jane Street, получают базовый оклад от $250 000 до $300 000. И это лишь «только часть общей компенсации в Jane Street, которая еще включает в себя ежегодную премию». Jane Street в среднем выплачивает более $900 000 бонусов на каждого сотрудника.Для сравнения, голый оклад в Google для L6 (Staff SWE), по данным из публичного доступа, которые удалось найти, составляет ~$240000--270000 в год.
https://t.me/banksta/59283
Посты про OCaml в канале можно найти через поиск. Начать можно отсюда:
https://t.me/emacsway_log/1740
Главное - не спутать ML и OCaml, это всё равно что спутать LISP 1.5 и Clojure.
Экосистема у него скудноватая, но это компенсируется тем, что LLM на нём прекрасно пишет. Один из лучших языков для LLM (разве что Lean может его превзойти в этом аспекте). По моему опыту LLM пишет на нём намного легче, чем на Rust с аналогичной системой типов. На mass market языках LLM пишет тоже уверенно, но там есть вопросы по формальной верификации - проще писать на Dafny и затем компилировать его в целевой язык (Python, Golang etc.)
OCaml достаточно простой, как Golang (унаследовавший простоту от Oberon), только с упором на FP.
"Less is more" - the key principle of Niklaus Wirth’s Oberon philosophy.
При этом FP является неоднозначной концепцией, которая, с одной стороны имеет достаточно высокий порог входа, с другой стороны, позволяет радикально упрощать сложные вещи.
Но бесспорно сильной стороной FP является легкость обеспечения формальной доказуемости корректности (за счет отсутствия side-effect). Формальная верификация императивных программ напоминает попытку доказать истинность текста, который постоянно изменяет сам себя в процессе доказательства (хотя это и решаемая проблема). Вопрос в том, стоит ли решать сложную проблему, если её можно просто исключить.
Приведу пример из практики. Один и тот же компонент системы реализованный в OOP-парадигме (Strategy Pattern) занимал 2135 строк кода. Он же после переписывания на FP-парадигму (монадический декоратор) на том же языке - 316 строк кода. При этом в FP-версии с самого первого дня все работало отлично и никаких проблем не возникало, в то время как OOP-версия шлифовалась и доводилась месяцами.
Особенность OCaml в том, что он (наряду с Haskell) привлекает лишь тех, достиг определённого уровня понимания. Это не тот язык, который изучают ради широкой рыночной востребованности. Jane Street использует эту его особенность в качестве естественного фильтра на рынке труда.
