Multicore OCaml таки вмержат в апстрим

Там ещё Reason попердолило и появился https://rescript-lang.org/.

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

Reason – это больше JS чем OCaml. Самой экосистеме окамла от ризона не слишком перепадает, потому как большинство библиотек за пределами веба не очень применимы.

Если раньше OCaml считался языком для разработки компилятора Петуха, то теперь ещё будет языком для разработки компилятора Reason.

Кстати, компаний, юзающих Reason, мне пока не попадалось особо. Только про Facebook и слышу.

Не только Петух, но и нахер, т.е., пардон, Haxe на кококамле пишут.

Не знаю что мне нравится в этом языке программирования. Вроде говно говном. А нравится

Какая между ними связь?

По теме - как я понял effect handlers будут абстрагировать даже асинхронную работу. Можно ожидать чего-то подобного на Go runtime?

Thanks to the separation of effectful operations from their implementation, effect handlers enable new approaches to modular programming. Effect handlers are a generalisation of exception handlers, where, in addition to the effect being handled, the handler is provided with the delimited continuation of the perform site. This continuation may be used to resume the suspended computation later. This enables non-local control-flow mechanisms such as resumable exceptions, lightweight threads, coroutines, generators and asynchronous I/O to be composably expressed.

Тредов по ML-семейству не так много, так что чего плодить для каждой минорщины по теме. Вот и эксплуатирую имеющуюся.

Между ReScript и Reason

А, в общем, ReScript — это переименованный и переделанный BuckleScript, компилятор Reason в JavaScript. Reason для JavaScript тихо похоронили и вместо него будет разрабатываться ReScript с несовместимым с ReasonML синтаксисом — то есть интероп между JavaScript и OCaml отменяется, судя по всему. Какая судьба ждёт Reason для OCaml неизвестно.

Там сложно и непонятно кто на ком стоял.

Вроде говно говном. А нравится

Говно?

А есть тут кто-то с хорошим пониманием многопоточки и OCaml одновременно, чтобы разложил по полкам, чем это лучше-хуже других решений для многозадачности? Конечно, скала сильно подкосила позиции окамля, но это всё не беда, если на окамле станет возможно писать эффективную многозадачу.

Возможно, тебе просто нравится говно.

чем это лучше-хуже других решений для многозадачности?

Это не многозадачность. Это многопоточность. Сейчас в ocaml нельзя использовать несколько тредов в одном процессе. Как в пистоне с GIL.

Конечно, скала сильно подкосила позиции окамля

Scala никак не подкосила ничего, потому что позиций у ocaml не было. И проблема даже не в самом языке, а в ублюдочном тулинге. До сих пор дофига библиотек на окамле собираются через автолулзы, со всеми вытекающими из этого факта последствиями.

Это не многозадачность. Это многопоточность. Сейчас в ocaml нельзя использовать несколько тредов в одном процессе. Как в пистоне с GIL

Многозадачность — это широкий абстрактный термин. Разница между многопоточностью и многопроцессовостью небольшая, и минимальными усилиями можно сделать одно из другого (что я и сделал для питона).

И проблема даже не в самом языке, а в ублюдочном тулинге. До сих пор дофига библиотек на окамле собираются через автолулзы, со всеми вытекающими из этого факта последствиями

А может ли быть так, что просто библиотеки эти плохо поддерживаются? Вроде же в окамле есть модули, а потому нет основной проблемы сей «что, с чем, и как собирать», для решения которой и нужны костыли в виде башеговна.

Разница между многопоточностью и многопроцессовостью небольшая, и минимальными усилиями можно сделать одно из другого (что я и сделал для питона).

Разница огромная. Для многопоточности в рамках одного процесса требуется не обосраться в локингом и не срать друг другу в память.

Тащемта, если не считать неточности формулировок, ты прав. Но обмен данными между процессами дороже чем между потоками в традиционных системах, поэтому без поддержки многопоточности жизни нет.

А может ли быть так, что просто библиотеки эти плохо поддерживаются? Вроде же в окамле есть модули, а потому нет основной проблемы сей «что, с чем, и как собирать», для решения которой и нужны костыли в виде башеговна.

Да нет, просто в окамле долго не парились. А потом, когда за жопу укусило, стало поздно. Сейчас вроде многие на Dune переползают, но тяжёлое наследие всё ещё даёт о себе знать. Сборка проектов на окамле по геморрою в среднем примерно на уровне плюсов. До того же Haskell, где 98% проектов собираются простым stack install, тут ещё пилить и пилить.

Ну и опять же, людей нет. Все фанаты функциональщины сбежали на Haskell. Из-за этого возникают довольно интересные лулзы: например, среди любителей ocaml наблюдается просто чудовищная ненависть к Haskell, но они толком не могут объяснить почему они его ненавидят зачастую.

Но обмен данными между процессами дороже чем между потоками в традиционных системах, поэтому без поддержки многопоточности жизни нет

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

И когда ты все эти проблемы обошел — ты с ужасом выясняешь, что средств отладки многопроцессовых программ просто нету. Есть ThreadSanitizer, но нету ProcessSanitizer или SharedMemorySanitizer.

Все фанаты функциональщины сбежали на Haskell. Из-за этого возникают довольно интересные лулзы: например, среди любителей ocaml наблюдается просто чудовищная ненависть к Haskell, но они толком не могут объяснить почему они его ненавидят зачастую

А F# они обожают? Я могу сказать за себя. но я — не любитель окамля: хаскель не годится для написания прикладных программ. Ну типа как эзотерический язык я его в общих чертах изучил, написал пару программ на 30-50 строчек, но писать что-то серьезное на этом языке я не буду.

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

Ты забываешь про смену контекста. Между тредами yield() – крайне дешёвая операция, от которой даже кэши не всегда сбрасываются. Между процессами же – ад и израиль.

Я могу сказать за себя. но я — не любитель окамля: хаскель не годится для написания прикладных программ. Ну типа как эзотерический язык я его в общих чертах изучил, написал пару программ на 30-50 строчек, но писать что-то серьезное на этом языке я не буду.

Тем не менее, ситуация на текущий момент такова: если сравнивать OCaml и Haskell, у последнего больше сообщество, больше библиотек, активнее развивается компилятор и прочие инструменты, и больше вакансий.

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

В последний раз, когда я искал работу, я был весьма рад за деньги на окамле код попечатать, но вакансий в Европе нет от слова совсем. На Haskell писать меня с радостью забрали за полторы недели. Такие дела.

Ты забываешь про смену контекста. Между тредами yield() – крайне дешёвая операция, от которой даже кэши не всегда сбрасываются. Между процессами же – ад и израиль

Когда ты, например, делаешься futex_wake из одного потока, а второй поток делает в это время futex_wait, то планировщик кидает пробужденный поток на новое ядро. Мне нужно пояснять, насколько это НЕдешево? У современных ОС планировщики настолько тупорылые, что проще не париться и просто приколачивать процесс к одному ядру. Но имеем что имеем — новые популярные ОС в ближайшие 5 лет не появятся.

И проблема даже не в самом языке, а в ублюдочном тулинге. До сих пор дофига библиотек на окамле собираются через автолулзы, со всеми вытекающими из этого факта последствиями.

Не встречал такого.

В любом случае, вменяемый package manager, немного странный, но юзабельный dune для сборки, LSP сервер для автокомплита и навигации по коду, интеграция с vim/emacs/vscode, локальная документация для каждого пакета, отличный repl, просмотр символов и быстрой документации для установленных пакетов.

Сэр, вы просто зажрались! Не все современные языки таким похвастаться могут.

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

Или не кидает. Зависит от affinity. Если у тебя реально это типовой сценарий, то лучше бы им озаботиться. И это мы ещё про NUMA не вспоминали.

У современных ОС планировщики настолько тупорылые, что проще не париться и просто приколачивать процесс к одному ядру.

Не. Реально зависит от туевой хучи факторов, включая модель процессора, формат работы приложения с памятью и так далее. На современных Ryzen/Threadripper/EPYC имеет смысл держать процесс в пределах чиплета, например, потому что между ядрами на одном чиплете и ядрами на соседних разница по латентности – раз чуть ли не 10.

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

Не встречал такого.

Ну вот. А я встречал и много :(

вменяемый package manager

opam – не шибко вменяемый. У меня он часто не мог что-то собрать. Плюс, там не то чтобы очень много пакетов в его базе.

Те два упёртых окамлофаната, которых я знаю, используют Nix, а opam даже не устанавливают в систему себе.

LSP сервер для автокомплита и навигации по коду

Для какого языка сейчас нет LSP сервера? Его даже для, матерь божья меня за ногу, 1C сделали!

https://microsoft.github.io/language-server-protocol/implementors/servers/

Сэр, вы просто зажрались! Не все современные языки таким похвастаться могут.

Да на самом деле, почти все, если забыть про REPL. Плюсцы до сих пор в него не могут, как и Rust :(

Да на самом деле, почти все

Я как-то пропустил тот момент, когда в плюсцах появился пакетный менеджер.

Да даже слинковаться с нужными либами обычно жуткий геморой, даже если использовать более-менее распространенный cmake. Просто потому что 95% требуемых библиотек собираются не cmake-ом. А уж если надо статически собраться с некоторыми библиотеками, в которых есть зависимость друг от друга — удачи передать -Wl,--start-group/-Wl,--end-group

Я как-то пропустил тот момент, когда в плюсцах появился пакетный менеджер.

И раз: https://conan.io

И два: https://vcpkg.io/en/index.html

Ну и, опять же, Nix.

Да даже слинковаться с нужными либами обычно жуткий геморой, даже если использовать более-менее распространенный cmake. Просто потому что 95% требуемых библиотек собираются не cmake-ом. А уж если надо статически собраться с некоторыми библиотеками, в которых есть зависимость друг от друга — удачи передать -Wl,–start-group/-Wl,–end-group

Это да. С другой стороны, называть C++ современным языком – это огромный самообман. Современного в нём нет ровно ничего. Самая новая фишка была придумана ещё в 90х.

Или не кидает. Зависит от affinity. Если у тебя реально это типовой сценарий, то лучше бы им озаботиться. И это мы ещё про NUMA не вспоминали

Affinity — это и есть «прибить процесс гвоздями к ядру», то есть numactl, taskset — вот это всё. Это требует ручной работы, хотя бы по настройке, потому что если ты настроишь неправильно, то у тебя все процессы будут висеть на одном сокете, а другой сокет будет в этом время мирно похрапывать. То есть, планировщик в таком случае перестает выполнять свое единственное назначение — обеспечение разделения аппаратных ресурсов между задачами. А нахер он тогда такой нужен? Писатели многозадачных систем тоже так подумали, и реализовали зеленые потоки, которые собственными механизмами правильно раскидываются по ядрам ОС.

С другой стороны, если у тебя какой-нибудь Erlang, в котором у каждого эрлангопроцесса своя куча и память они фактически не шарят (кроме ETS), хоть и находятся в одном адресном пространстве, то тут вообще пофиг, на каких ядрах что крутится

Так у Erlang еще и собственный планировщик.

Это требует ручной работы, хотя бы по настройке, потому что если ты настроишь неправильно, то у тебя все процессы будут висеть на одном сокете, а другой сокет будет в этом время мирно похрапывать.

Что может быть быстрее, чем данные между сокетами и плашками памяти гонять ¯\_(ツ)_/¯

Так у Erlang еще и собственный планировщик.

Ага. Как и у Haskell, golang и прочих языков с M:N multithreading.

Что может быть быстрее, чем данные между сокетами и плашками памяти гонять

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

Ага. Как и у Haskell, golang и прочих языков с M:N multithreading

Заметь, что если у хаскеля потоки используются для ввода-вывода, потому что асинхронщину там тяжело реализовать, то в Go и Erlang зеленые потоки сделали совершенно целенаправлено.

https://conan.io

Хм, слышал много лет назад, но не ожидал, что так много всего опакетили уже. И все равно не верю, что это будет нормально работать со статической линковкой. Со времен libtool для этих целей ничего путного так и не создали.

В любом случае, C и C++ очень сильно «врос» во все дистрибутивы линукса, а судя по тому, что я видел в рецептах, conan к этому точно не готов — он же не сможет часть либ из системы, а другие подтянуть из своего репозитория. И это даже не вина самого пакетного менеджера.

Современного в нём нет ровно ничего

Разве так нельзя сказать буквально про любой язык кроме Rust?

Хм, слышал много лет назад, но не ожидал, что так много всего опакетили уже

Меня удивляет другое — почему этого не сделали 20 лет назад?

И все равно не верю, что это будет нормально работать со статической линковкой. Со времен libtool для этих целей ничего путного так и не создали

Вроде терпимо работает:

https://github.com/conan-io/conan/issues/4646

conan к этому точно не готов — он же не сможет часть либ из системы, а другие подтянуть из своего репозитория

А это нереально. Например, у меня на дебыче штатно поставляется патченный питон с патченными заголовками. Как с этим компилиться? То есть, это совершенно дикая штука, имеющая плохо предсказуемые отличия от официального питона — конан ничем помочь не сможет.

Разве так нельзя сказать буквально про любой язык кроме Rust?

А что у нас нового есть в Rust? Или ты о том, что прародитель Rust-а, Cyclone, прямо новый-приновый, всего-лишь в 2002 году разработан, индустрия кует железо пока горячо.

Заметь, что если у хаскеля потоки используются для ввода-вывода, потому что асинхронщину там тяжело реализовать

Не заметил. Пишу асинхронщину много лет. Брат жив.

Разве так нельзя сказать буквально про любой язык кроме Rust?

Нет. Линейные/аффинные типы засунули в тот же Haskell и, я вроде как слышал, в виде библиотеки/плагина в Scala. А это довольно свежая фишка. Ну и вышеупомянутые эффекты тоже сравнительно недавно появились. Буквально лет 10 назад.

Не заметил. Пишу асинхронщину много лет. Брат жив

На каких протоколах/фреймворках пишешь асинхронщину?

Вроде терпимо работает

В issue не пишут, как быть, если статическая библиотека требует чего-то дополнительного при линковке.

Например, у меня на дебыче штатно поставляется патченный питон с патченными заголовками. Как с этим компилиться? То есть, это совершенно дикая штука, имеющая плохо предсказуемые отличия от официального питона — конан ничем помочь не сможет.

Сильно сомневаюсь, что патчи как-то аффектят API или ABI, предоставляемый ванильным питоном.

А что у нас нового есть в Rust?

Модель работы с памятью, вынесенная на уровень системы типов, когда потенциально некорректный/рейсовый код не компилируется.

в OCaml таки добавят поддержку использования нескольких ядер

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

Такая же х*, не могу даже понять причину.

P. S. Это ты про реализацию или про сам язык?

С другой стороны, если ты фанатик теории категорий и лямбда-исчислений, то да, этот язык для тебя.

На текущий момент ситуация ровно как в пистоне, да.

Так и думал, что теория категорий теьбе плохо в школе давалась.

для шакала афинные типы

https://github.com/phaller/lacasa

Про ущербный синтаксис и форматирование кода. Мне наоборот нравится что он компилируется в натив

Ну я ее читал наверное ещё в школе, лет 15 назад. Давалась нормально

А если б не в натив он компилировался? Для тебя проблема что-ли это?

Вынос мозга реальный. Уважаю.

Ну не в натив - такого хвататет, надоело уже. Java/.NET - жизнь слишком коротка чтобы ее так скучно проводить. Тем более что уже последние лет 10 есть достаточно много нативных языков с похожими или лучше гарантиями безопасности - Rust, Go. И вот получается даже OCaml

Для меня остался единственный интересный байт-код - WebAssembly. Остальное пора на пенсию

Я тогда думал что это нужно чтобы быть нормальным программистом. Конечно нет, хаха.

WebAssembly ох*нен прям новое слово в веб-деве. Тебе старичку тяжело это все будет конечно принять.

Лучше б конечно было озвучить, реализация то от кого? От французов, или от фейсбука?

Функциональщины нет. Прям штоб в натив.

WebAssembly прям новое слово в веб-деве

WebAssembly не осчастливит вэб …
Вэб давно уже нужно

Выкрасить и выбросить

Хз, тебе видней наверное..