но хорошего обоснования я дать не могу

А ты щас на чём-то кроме хаскеля пишешь? Вообще единственная проблема в том, что можно случайно не поместиться в System F2 и тогда нужно будет руками типы разрешать

конкретные команды определены в локальном vimrc, который запускается из глобального и игнорируется гитом

Тут про хаскель, а вы редакторосрач продолжаете

А ты щас на чём-то кроме хаскеля пишешь? Вообще единственная проблема в том, что можно случайно не поместиться в System F2 и тогда нужно будет руками типы разрешать

по работе нет, так иногда с растами, идрисами играюсь

по работе нет, так иногда с растами, идрисами играюсь

А в идрисе чокак с system f?

Мне кажется, что у тебя какой-то страх перед абстрактным полиморфизмом, по-крайней мере я других источников не вижу для твоего скепсиса

Либо приведи хармфул код

как вы относитесь к функциям полиморфным по монадке, т.е. MonadIO m => ... -> m a, а не ... -> IO a

А раз уж начал вбрасывать, можешь примерно сориентировать зачем это?

ну например для работы с базой которое тонкое FFI над IO делать MonadIO везде

А в идрисе чокак с system f?

я читал, что в идрисе нечто совершенно отличное от system f, но я в теории вообще никак, так что никак прокомментировать не могу

при этом без косячных реализаций как в lifted-async например

а что именно косячного в lifted-async? какие-то конкретные косяки, какая-то фундаментальная проблема?

оно не для всех монад справедливо

у которых есть MonadBaseControl IO

раньше еще всякие баги были но поправили их

это типа State, когда неизвестно, какой в итоге стейт получится?

когда есть зависимость от ThreadId или мутабельный стейт

например в ResourceT есть зависимость, что все треды форкающиеся должны инкрементить счетчик

и декрементить по завершению

этого в lifte-async не будет

или в Process тоже получится что 1 ProcessID будет у двух тредов

со всеми радостями

гм, ну это уже какие-то изощрённые ситуации, походу

во всяком случае, у меня не было необходимости иметь дело с ThreadId

и, надеюсь, не придётся, хотя угроза нависла

сопсна, вопрос такой - есть задача сделать простенький супервизор процессов

сходу нагуглился Angel, но он сделан в виде приложения, а мне бы что-то библиотечное, чтоб в свой сервис встроить https://github.com/MichaelXavier/Angel

вопрос такой - насколько много подводных камней, если делать всё самому?

возможно, проще будет взять этого ангела и вырефачить что-то в библиотеку?

квык чек ин жс :D https://github.com/jsverify/jsverify

Vasiliy там неявные зависимости могут быть

why not use systemd?

или s6?

systemd олрэди ин юз, но с ним возникают проблемы

нужно иметь возможность из приложения запускать/останавливать сервисы, переходить между таргетами итд

вариант1, который сейчас в работе - дёрганье systemctl с аргументами, вариант2 - dbus api, с которым тоже куча приколов

мы sytemctl дергали

но нам не нужны были нотификации о смерти и т.п.

дешево и сердито, если прав хватает

ну вот конкретная задача, после которой я задумался о собственном супервизоре - нужно через http-интерфейс залить бэкап в базу

+ в systemd уже принесли временные и параметрические юниты

ну что там - считали бэкап, положили все сервисы, которые сейчас с базой работают, залили бэкап, подняли всё обратно

я это делал дня три

вот, собственно, и появились мысли, что зоопарк и субд и демонов проще мониторить руками, чем systemd

нужно иметь возможность из приложения запускать/останавливать сервисы, переходить между таргетами итд

Докер с автореспауном

Управлять докерконтейнерами в сотню раз проще чем процессамм

но докер добавит кучу своего геморроя...

поясню ситуацию - есть основной, так сказать, продукт, с которым работают простые люди, есть демон, который помогает этим людям выполнять административные функции без залезания в консоль

этот демон занимается обновлениями, бэкапами, перезапуском этого продукта итд

продукт - типа LAMP из пачки демонов

Управлять докерконтейнерами в сотню раз проще чем процессамм

oh you

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

но докер добавит кучу своего геморроя...

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

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

Т.е. пересобрать грабли upstart, runit и systemd, да?

Контейнеризация - это тема.

Но...

Есть и минусы.

ну если четко понимать что нужно и как это делается, то можно запилить лучше для себя

хотя бы на основе чего-либо мелкого

всё таки, как лучше делать многопоточное приложение, которое что-то там читает, считает и пишет на диск? мне кажется, что считать и писать в одном потоке нецелесообразно - судя по простоям, которые видно в графике загрузки, причем простои довольно одинаковые, периодичные и синхронные. Не лучше ли писать в одном потоке, считать в куче других - и между ними сделать какой-нибудь channel / queue ?

т.е тупо генерить ленивый список, нарезать на чанки и потом писать - кажется не слишком оптимальным решением

вопрос - стоит ли связываться со всякими синхронизированными очередями/каналами, не вносят ли они в нашем уютненьком слишком большой оверхед?

Лучше писать в n потоках, где n количество ядер

есть ощущение, что тормозит вывод - поскольку это обновление базы

и со временем там увеличивается время записи

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

@voidlizard bounded channel / conduit-stm

n потоков обработки, которые из очереди читают

можно попытаться со strategies (parallel и генерить чанки, то там может быть все сложнее)

а почему bounded ?

для безопасности? что бы память не жрало если где-то не расссчитал?

стоит ли с этим возиться вообще?

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

если в один поток, то достаточно одного потока-писателя

Да, на один физдиск.

Дисков же может быть много...

опять я обсуждаю общие вещи тут вместо misc-dev-talks, но тут вопрос - не вносят ли хаскельные примитивы синхронизации слишком большой оверхед

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

сейчас же даже самое тупорылое распараллеливание даёт приход процентов 30

@voidlizard для того, чтобы память не жрал, и было сбалансировано

пара = ну два, ну три, но никак не болше пяти

чего толку IO гонять, если CPU не успевает

ну короче, писать в базу во всех потоках, которые и считают - это ошибка

и приводит к простоям

даже если писать батчами

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

ну и наоборот, чего толку считать, если у нас затык при записи в базу

ну то, что насчитали можно откладывать в пямяти

если она будет жраться на это - ну и пусть, размеры позволяют

а вот если памяти нет и на диске затык - то да, надо ждать

что же это получается

получается стандартное джава приложение, что ли - две очереди и k + n потоков - очередь на обсчёт, очередь на запись ?

все вот так предельно тупо и никакой хаскельной легкости?

ты можешь сделать обработку списка и призвать parallel

если у тебя там все чистое

ну чистое, но не очень - файлы-то читаются

сам обсчет правда чистый, но запись

https://hackage.haskell.org/package/parallel-3.2.1.1/docs/Control-Parallel-Strategies.html

концы не в счет

можно ещё conduit-stm