давайте про MonadIO vs IO везде подряд

В чём проблемы с MonadIO?

не знаю

а зачем хоткеями слать команды в консоль?

выше написал

чтобы в голом tty когда окажешься всегда был выход

У меня tmux :)

У меня тоже

мне зачастую не нравятся излишне полиморфные стеки

я для сборки проекта переключаюсь в консоль и там запускаю.

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

я для сборки проекта переключаюсь в консоль и там запускаю.

лень)

при том, что всегда можно подняться куда надо

то есть я на емакс перешел в том числе и ради консоли, но потом понял, что проще нажать вин-таб, вверх и энтер

как через monad-control так и lift

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

хотя и пытался в емаксе делать свои же собственные биндинги

с другой стороны я не считаю эти аргументы хорошими

то есть я на емакс перешел в том числе и ради консоли, но потом понял, что проще нажать вин-таб, вверх и энтер

ну это проще пока не настроил и не привык к своим хоткеям

настроил, но не привык

ну то есть я нажимаю F5,F6,F7,F8 для сборки, запуска, тестирования и линта например

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

А ты щас на чём-то кроме хаскеля пишешь? Вообще единственная проблема в том, что можно случайно не поместиться в 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 количество ядер