[00:32:55] <ada_ru> (I_vlxy_I) Чот я в исходниках гната не могу найти ничего про Non_Preemptive_FIFO_Within_Priorities
[01:42:51] <ada_ru> (a) https://m.habr.com/ru/company/piter/blog/469135/ напочитать
[08:36:52] <ada_ru> (Максим) А что не так с адскими задачами? Sergei мне сто лет назад расхваливал задачи в ерланге, но я ничего не понял 🙁
[09:44:15] <nordwind> В специфике ерланга? Он типа на большие масштабы, скорости и объемы с распараллеливанием и все такое... Нет?
[11:47:42] <ada_ru> (Максим) Алексей поднял волну, что адские задачи не подходят для обслуживания 100_000 сетевых соединений
[11:48:56] <ada_ru> (Максим) Я попробовал, в Ubuntu 9_000 создаются в один момент. ps говорит VSZ=460124 RSS=144776
[11:49:30] <ada_ru> (Максим) https://pastebin.osuosl.org/view/4e1eddfc
[11:50:12] <ada_ru> (Максим) Больше - упирается в лимит cgroup: fork rejected by pids controller in /user.slice/user-1000.slice/session-233.scope
[11:51:01] <ada_ru> (Максим) хз, как увеличить. Авторы systemd не документируют
[12:00:39] <ada_ru> (Борис) В Эрланге легковесные процессы никакого отношения к процессам и потокам операционной системы не имеют.
[12:02:31] <ada_ru> (Борис) Естественно никто в здравом уме для обслуживания даже 10к соединений не будет использовать потоки или, тем более, процессы ОС. Это решается уже другими способами.
[12:03:08] <ada_ru> (Максим) Почему? 16к на поток, разве это так много?
[12:04:28] <ada_ru> (Борис) 16к чего на поток?
[12:04:45] <ada_ru> (Максим) RAM
[12:06:43] <ada_ru> (Борис) Дело не в памяти на поток. Переключение потоков это ресурсоёмкая вещь. С определённого момента ОС только и будет заматься переключение задач, а на остальное времени не хватит.
[12:09:16] <ada_ru> (Борис) Большое количество сетевых соединений это уже epoll, kqueue и прочий эвент-драйвинг. Плюс какое-то конечно-автоматное или подобное решение на обработку.
[12:10:10] <ada_ru> (Борис) А потоков/процессов по количеству ядер, чтобы утилизацию мощностей сделать.
[12:41:12] <ada_ru> (Максим) Т.е. кроме затрат на пямять, coroutine лучше временем переключения контекста? Судя по первому попавшемуся бенчмарку у меня 2_000_000 переключений между потоками занимает 3 секунды. Это не выглядит как-то очень существенно
[12:43:55] <ada_ru> (FROL256) ну как, 1.5 микросекунды
[12:44:39] <ada_ru> (FROL256) даже при частоте 1 Ghz это будет около 3K инструкций
[12:44:54] <ada_ru> (FROL256) а если там частота скажем 3, то уже ближе к 10K инструкций
[12:45:32] <ada_ru> (FROL256) ели исходить из того что процессор 2 инструкции в клок делает хотя бы
[12:49:13] <ada_ru> (FROL256) Я вот недавно развлекался с офтверной реализацией OpenGL и там получается примерно 300 инструкций на 4 пиксела в SSE, то есть 600 —1200 инструкций на тайл 4x4 пикселей если AVX
[12:50:18] <ada_ru> (FROL256) соответственно 10K это стоимость обработки почти что 20x4x4 = 320 пикселей
[12:51:26] <ada_ru> (FROL256) в image processing-е будет и того больше если только в память не упрётся
[12:58:06] <ada_ru> (Максим) Я просто не понимаю к чему всё-таки притензии, к функциональности задаст в Але или к эффективности реализации
[12:58:37] <ada_ru> (FROL256) если что у меня нет претензий к Аде )
[12:59:22] <ada_ru> (Максим) Нужны ли короутины или может достаточно реализовать задачи через зелёные потоки
[13:04:36] <ada_ru> (Максим) Ладно, может Алексей объяснит, что ему надо
[13:05:04] <ada_ru> (FROL256) Исходя из моего опыта нужен механизм фиксации треда на ядре, и по-моему в Аде он кстати есть. Чтобы треды не мигрировали. Если я опять вспомню свои эксперименты с OpenGL — там так получается, что если какой-то тред обрабатывает треугольник, то поскольку фреймбуффер тайловый, то некоторая часть фреймбуффера лежит в кэше и данные для треугольника лежать в кэше
[13:05:18] <ada_ru> (FROL256) и вот эта миграция
[13:05:32] <ada_ru> (FROL256) влияла на производительность
[13:05:46] <ada_ru> (FROL256) потому что на другом ядре в L1 не было тех же самых тайлов в кэше
[13:05:50] <ada_ru> (FROL256) и того же самого треугольника
[13:21:19] <ada_ru> (I_vlxy_I) отвечает (Максим) на <Нужны ли короутины и…>
Смотря что под зелёными потоками понимается.
[14:05:05] <ada_ru> (Лекс) Подскажите, если я использую aws, но от него мне нужно только отдавать json и статику, а всё остальное добро (на скриншоте не нужно), то можно как-то собрать бинарь без этого всего? И сократит ли это размер бинаря? https://www.ada-ru.org/files/bot/2019-09-28-x1.jpg
[14:16:31] <ada_ru> (Максим) Если использовать статическу библиотеку, то линкер потянет только те объектные файлы, которые используются.
[14:22:12] <ada_ru> (Максим) Есть и другие методы оптимизации, (lto, отдельные секции линкера на каждую функцию), но с ними сложно
[14:22:40] <ada_ru> (Лекс) отвечает (Максим) на <Если использовать ст…>
Это как сделать?
[14:24:40] <ada_ru> (Максим) В gps есть scenario view, там есть что-то типа AWS BUILD TYPE с вариантами static, relocatable. Нужно поставить static
[14:25:50] <ada_ru> (Максим) Если из командной строки gprbuild, то через ключ -X
[14:25:54] <ada_ru> (Лекс) по дефолту так и есть, 11 мегабайт это только база? потому что я пока собрал только шаблон из GPS О_О
[14:26:40] <ada_ru> (Максим) Ну можно стрипнуть отладочную информацию
[14:27:17] <ada_ru> (Лекс) Понял, спасибо
[15:07:28] <ada_ru> (Oleg) отвечает (Лекс) на <>
О, а если не секрет что делаете?
[15:07:45] <ada_ru> (Oleg) И как впечатления от AWS?
[15:09:01] <ada_ru> (Лекс) отвечает (Oleg) на <О, а если не секрет …>
Вы будете смеяться)
Пишу бакэнд для своего планировщика (типа как todo, только навороченее в плане менеджмента заданиями, но вся логика на фронте на js)
[15:10:36] <ada_ru> (Oleg) Во, сейчас делаю кучу рест апи , возьму для разнообразия Аду
[15:10:56] <ada_ru> (Oleg) А просить json там легко ?
[15:11:21] <ada_ru> (Oleg) Может на гитхаб положите ? :-)
[15:11:26] <ada_ru> (Oleg) Я б посмотрел
[15:12:08] <ada_ru> (Oleg) А то я человек измучаный go, хочу уже перейти местами на Аду.
[15:12:27] <ada_ru> (Лекс) Я только проект открыл в GPS вот сейчас, прототип на перле стряпаю 😃
[15:12:37] <ada_ru> (Oleg) Go кстати рест апи - 16 мегабайт , 16 карл !
[15:12:54] <ada_ru> (Oleg) Что он за собой таскает?
[15:13:01] <ada_ru> (Лекс) А чем вас go измучал?
[15:13:14] <ada_ru> (Лекс) Что именно что таскает?
[15:13:48] <ada_ru> (Oleg) Ну компилишь приложение, берет из монги данные и отдаёт в JSON
[15:13:55] <ada_ru> (t91x0) отвечает (Oleg) на <Go кстати рест апи -…>
А вы сходите в чат к гошникам
[15:14:00] <ada_ru> (Oleg) Исполняемый файл 16 мб
[15:14:24] <ada_ru> (Oleg) Не, не пойду
[15:14:26] <ada_ru> (Oleg) Ну их
[15:14:44] <ada_ru> (Oleg) Я на аде хочу попробовать
[15:15:32] <ada_ru> (Oleg) Так что жду ссылку на git :-)
[15:16:39] <ada_ru> (Лекс) отвечает (Oleg) на <Исполняемый файл 16 …>
Странно как-то... у меня скрэпер с GUI и JSON весит только 13, а там инклюдов штук 5 :-D
[15:17:06] <ada_ru> (Oleg) Да хрен с ним , надо больше Ады !
[15:17:08] <ada_ru> (Лекс) Ну и пустой проект на Аде 11 мегабайт, как бы
[15:17:36] <ada_ru> (t91x0) А если debug symbols убрать?
[15:17:40] <ada_ru> (Лекс) Подозреваю, что здесь дело не в размере бинаря, а в том сколько и как будет расходоваться память
[15:17:50] <ada_ru> (Oleg) Ну да
[15:18:39] <ada_ru> (Лекс) у меня так на лиспе бинари весили по 60 мб, распакованный в памяти 200 мб, но сам код дожирал не больше 20
[15:19:55] <ada_ru> (Oleg) Замерю кстати расход памяти.
[15:21:56] <ada_ru> (Лекс) отвечает (t91x0) на <А если debug symbols…>
Уберу, как дойду. Я Аду только начинаю изучать :-D
Я туда ещё lto впилю и всяких оптимизаций, и надеюсь оно не сломается как обычно бывает
[16:57:23] <ada_ru> (I_vlxy_I) отвечает (Oleg) на <Ну компилишь приложе…>
Драйвер для монги же. Плюс учти, что там статическая линковка по умолчанию, в отличие от плюсов и Ады.
[16:58:10] <ada_ru> (Oleg) Да я понимаю , но это все равно серезвычайно много
[16:59:39] <ada_ru> (Лекс) отвечает (I_vlxy_I) на <Драйвер для монги же…>
Это ж что туда напихано в драйвер для монги О_О
[16:59:57] <ada_ru> (I_vlxy_I) вроде ок. после плюсовых исполняемых файлов размеров в 4 гигабайта, меня 16 метрами гошки не испугать 🙂
[17:00:28] <ada_ru> (Лекс) отвечает (I_vlxy_I) на <вроде ок. после плюс…>
А это что за монстры у вас и где они исполняются?
[17:00:43] <ada_ru> (I_vlxy_I) отвечает (Лекс) на <А это что за монстры…>
кликхаус. исполняются на любом компе
[17:00:55] <ada_ru> (I_vlxy_I) 4 гиговый исполняемый файл так то не требует 4 гигов рамы
[17:01:17] <ada_ru> (I_vlxy_I) он же не грузится в оперативку
[17:01:23] <ada_ru> (I_vlxy_I) (целиком)
[18:00:14] <ada_ru> (I_vlxy_I) отвечает (Максим) на <Ладно, может Алексей…>
ну, смотри, как на Аде будет выглядеть логика - к тебе цепляется по websocket клиент, соединение персистентное, отсоединаться от тебя он не собирается и, периодически, он просит тебя выдать ему какую-нибудь информацию, причем какую именно информацию - это зависит также и от предыдущих его запросов.
кроме того, чтобы ответить на его запрос, тебе также нужно сходить например в базу данных, или дернуть какую-нибудь REST-ручку.
плюс клиент просит тебя слать ему (по тому же вебсокету) скажем нагрузку CPU сервера каждые 10 секунд.
[18:01:50] <ada_ru> (I_vlxy_I) в каком-нибудь Го или Ерланге тут код вот этой вот логики не будет отличаться вообще никак для случая когда у тебя 1 клиент и все запросы блокирующие (то есть будет простой тупой линейный код, без каллбеков) и для случая когда у тебя работа со всем этим IO асинхронное и клиентов у тебя миллион одновременно.
[18:04:09] <ada_ru> (Максим) Но как поток, который снялся с epull будет взаимодействовать с кодом, который в этот момент может висеть на ожидании БД? Или там вообще всё в один поток?
[18:04:47] <ada_ru> (I_vlxy_I) отвечает (Максим) на <Но как поток, которы…>
системный поток может быть один, да. а может быть несколько.
[18:04:59] <ada_ru> (I_vlxy_I) на производительность это особенно не влияет
[18:05:20] <ada_ru> (I_vlxy_I) а вот корутин (горутин) с собственным состоянием в стеке - сотни тысяч.
[18:05:22] <ada_ru> (Максим) если их несколько, как гарантировать, что два потока не будут обслуживать код одного клиента?
[18:05:55] <ada_ru> (Максим) их - системных потоков
[18:07:08] <ada_ru> (I_vlxy_I) отвечает (Максим) на <если их несколько, к…>
смотри. к тебе стучится клиент, создается под него сокет. для этого сокета (ака соединения) создается горутина куда передается этот сокет как аргумент (можешь пока считать, что горутина - это еще один поток, только с кооперативной многозадачностью). Всё. Больше никто не знает про этот сокет. С этим клиентом будет общаться только эта горутина.
[18:07:42] <ada_ru> (I_vlxy_I) Когда горутина эта, по запросу клиента полезет в базу данных например, то запрос будет асинхронный, и она заснет на этом вызове до тех пор пока база не ответит.
[18:08:18] <ada_ru> (I_vlxy_I) Как данные появятся, шедулер её разбудит и функция выдаст результат запроса. И так со всеми асинхронными вызовами.
[18:08:53] <ada_ru> (I_vlxy_I) При этом физических ОС-потоков - примерно по числу ядер. Горутина может мигрировать с одного потока на другой, если это необходимо. Это для прикладного программиста прозрачно. Ему про ОС-потоки вовсе не нужно знать.
[18:09:09] <ada_ru> (I_vlxy_I) В рамках одного ОС-потока горутины имеют не вытесняющую, а кооперативную многозадачность.
[18:09:16] <ada_ru> (Максим) а как она повесит сокет на ожидание данных?
[18:10:08] <ada_ru> (I_vlxy_I) отвечает (Максим) на <а как она повесит со…>
В смысле? сокет всегда ожидает данные же 😊 tcp стек имеет свой буфер. так всякие епулы или банальный селект работает.
[18:10:44] <ada_ru> (I_vlxy_I) на скольки потоках там этот селект запускается - я хз. может и на одном.
[18:10:48] <ada_ru> (Максим) ну вот ей нужны данные из сокета. она же не делает просто read оттуда
[18:10:50] <ada_ru> (I_vlxy_I) но горутины раскиданы по разным.
[18:11:39] <ada_ru> (I_vlxy_I) отвечает (Максим) на <ну вот ей нужны данн…>
да, она работает, грубо говоря, через прослойку-менеджер асинхронного IO. Говорит - мне надо вот из этого сокета вот данные. Ты их подожди, а я спать.
[18:11:54] <ada_ru> (I_vlxy_I) Как появятся - скажи шедулеру, пусть меня разбудит и данные в постель пожалуйста.
[18:15:37] <ada_ru> (I_vlxy_I) но для прикладного программиста, это именно что socket.read вызывается. То что там унутре неонка - он не знает особо.
[18:15:41] <ada_ru> (Максим) Мне кажется, если пользоваться адским синтаксисом, то короутина может быть написана, как задача, которая не имеет взаимодействия с другими задачами, а все ее блокирующие операции упираются в специальную библиотеку, менеджер асинхронного IO, как ты ее назвал.
[18:16:07] <ada_ru> (I_vlxy_I) Да. И шедулер для таких задач должен быть специальный.
[18:16:40] <ada_ru> (Максим) да. Компилятор должен как-то унюхать, что для нее не нужен отдельный ОС-поток
[18:16:49] <ada_ru> (I_vlxy_I) Для взаимодействия с другими корутинами в Го есть каналы, так то. По сути это очереди сообщения через которые можно общаться с другими. Передавать записочки.
[18:17:08] <ada_ru> (I_vlxy_I) отвечает (Максим) на <да. Компилятор долже…>
дык там есть для этого специальная прагма прямо в стандарте уже
[18:17:11] <ada_ru> (I_vlxy_I) в Адском
[18:17:22] <ada_ru> (Максим) А что ты разнюхал по поводу Non_Preemptive_FIFO_Within_Priorities ,
[18:17:25] <ada_ru> (Максим) ?
[18:17:33] <ada_ru> (I_vlxy_I) pragma Task_Dispatching_Policy
[18:17:38] <ada_ru> (I_vlxy_I) https://www.adaic.org/resources/add_content/standards/05rat/html/Rat-5-5.html
[18:17:46] <ada_ru> (I_vlxy_I) и там даже есть Non-Preemptive Dispatching
[18:18:01] <ada_ru> (I_vlxy_I) что как бы намекает, что поток отдельный для таких тасков не нужен
[18:18:14] <ada_ru> (Максим) И что, правда работает?
[18:18:35] <ada_ru> (I_vlxy_I) нет. не работает. 😞 всё равно плодит pthread'ы вне зависимости от того, что выставишь.
[18:18:58] <ada_ru> (I_vlxy_I) кажется в реализации рантайма gnat'a на это дело забили. по крайней мере для линукса.
[18:19:24] <ada_ru> (Максим) может это (non-preemptive) в pthread как-то реализовано?
[18:19:51] <ada_ru> (I_vlxy_I) я хез. но пытреды создаются.
[18:19:59] <ada_ru> (I_vlxy_I) а это не дело 😊
[18:23:31] <ada_ru> (I_vlxy_I) то есть, выше, про горутины я описал простейший (и самый ЧИСТЫЙ) сценарий использования.
теперь то, немного грязного белья — на самом деле горутины имеют доступ ко всем глобальным переменным, и к общей куче. это же не ерланговские процессы (которые реально не имеют общей кучи и изолированы). Поэтому в реальной жизни они там и мьютексами могут пользоваться, и каналами для общения друг сдругом и так далее.
То есть, в теории, какие-то механизмы взаимодействия для таких тасков в Аде можно и оставить, или доработать.
[18:23:56] <ada_ru> (I_vlxy_I) но я в Адских тасках не разбираюсь, поэтому не могу с уверенностью сказать что там и как должно было бы быть.
[18:24:37] <ada_ru> (I_vlxy_I) Но ясно одно - хочется возможность создавать и задавать свой шедулер для некоторых тасков и более гибко рулить их стеком.
[18:26:04] <ada_ru> (Oleg) А ещё бы это все на Embedded :-)
[18:26:26] <ada_ru> (I_vlxy_I) отвечает (Oleg) на <А ещё бы это все на …>
а оно там имеет смысл? встроенного не достаточно?
[18:26:29] <ada_ru> (Максим) Там, кажется, Рафаэль пытался всунуть короутины в Аду. Есть 4 AI, но на всех помтавили "тяжело реализовать" и "как-нибудь-потом"
[18:27:13] <ada_ru> (Максим) Для embedded есть Равенскар профиль. Он кажется не плох
[18:28:28] <ada_ru> (Oleg) отвечает (I_vlxy_I) на <а оно там имеет смыс…>
Конечно! Так как либо использовать ОС типа FreeRTOS либо использовать что-то типа протопотоков либо использовать прерывания либо one shot execution и все имеет свои плюсы и минусы
[18:28:43] <ada_ru> (I_vlxy_I) отвечает (Максим) на <Там, кажется, Рафаэл…>
смотри, то, что я описал - это позволило бы сделать "stackfull" корутины, то есть корутины со стеком полноценным. Часто же корутины рассматривают как stackless, то есть безстековые. Это по сути, получается, конечный автомат. В плюсы именно такое втаскивают.
Такие корутины (без стека) более легковесные, но требуют изменений именно что в языке прямо (а не в либе), там приходится всякие async/await аннотации в код вставлять. Ну и мигрировать на них сложнее.
Зато их и прибивать проще если что.
[18:28:47] <ada_ru> (Oleg) отвечает (Максим) на <Для embedded есть Ра…>
Посмотрю спасибо
[18:29:51] <ada_ru> (I_vlxy_I) отвечает (Oleg) на <Конечно! Так как либ…>
дык для embedded то адский рантайм без всякой оси всё что нужно реализует.
[18:32:01] <ada_ru> (I_vlxy_I) а, ну и в горутинах еще можно заснуть (то есть отдать управление) явным образом, кооперативная же многозадачность.
[18:32:12] <ada_ru> (Максим) На русском про Равенскар я вообще ничего не встречал :( Там набор ограничений на многозадачность. И разные планировщики. С их помощью можно гарантировать, что-то хорошее, типа, что хватит времени на всё 😊
[18:32:46] <ada_ru> (Максим) Ну да, заснусть я в Аде видел.
[18:34:10] <ada_ru> (I_vlxy_I) с горутинами, поскольку многозадачность кооперативная, если горутина сделает while (true) {}, то есть уйдет в бесконечный цикл, то, привет 😊 один поток (из, скажем 8), который обслуживает горутины, станет остальным недоступен.
если у тебя был всего один такой поток - то больше никто никогда ничего не исполнит.
[18:34:20] <ada_ru> (I_vlxy_I) грубо говоря. кооперативщина. 😊
[18:34:47] <ada_ru> (Максим) беда
[18:34:49] <ada_ru> (I_vlxy_I) понятное дело, что рантайм у Го поумнее и он вполне способен еще потоков наплодить, чтобы в них крутить оставшиеся горутины.
[18:35:09] <ada_ru> (I_vlxy_I) но это уже нюансы высшего порядка.
[18:38:15] <ada_ru> (I_vlxy_I) я просто вот помню как классически в плюсах делали обслуживание многих клиентов - есть тредпул (на сколько-то там клиентов), это у нас воркеры. а на каждого клиента создавался объект класса для обслуживания клиента. и всё состояние хранилось в полях этого класса, плюс у него дергались разные методы-каллбеки в зависимости от того, что там с IO происходит (типа данные такие пришли от клиента, данные сякие пришли от базы данных и проч).
и каждый воркер по мере надобности искал соответствующий объект и дергал его за эти каллбэки-методы.
это капец лапша.
[18:38:32] <ada_ru> (I_vlxy_I) сейчас стараются делать простой последовательный код для асинхронщины во всех языках.
[18:38:53] <ada_ru> (I_vlxy_I) и при этом не плодить потоков сверх числа ядер.
[18:39:27] <ada_ru> (I_vlxy_I) больше потоков - ниже эффективность, больше багов и больше накладных расходов.
[18:51:56] <ada_ru> (Eugene) цитирует (graninas)
Я тоже люблю типизированное программирование, это очень упрощает мне жизнь. Но ведь искажение смыслов ведет к тому, что мы не только вводим себя и других в заблуждение, но и делаем неверный упор в нашей просветительской деятельности. Вместо того, чтобы учить людей ФП, мы им говорим - иди, читай Бартоша, и пока не поймешь, что такое аппшикативная эндокатегория, не возвращайся. А человек меж тем даже не знает толком про лямбды, рекурсию, каррирование, композицию.
[18:54:20] <ada_ru> (Eugene) цитирует (graninas)
Мне, знаете ли, обидно за лисп, clojure и JavaScript. Последний вообще сделал больше для популяризации ФП, чем те же хаскеллисты. Наравне со Скалой, а то может и больше нее. А вот теоркатегорщики, наоборот, перепугали кучу народу и отвадили многих интересующихся.
[18:54:22] <ada_ru> (Eugene) цитирует (graninas)
Но мы ж не дадим теоркатегорщикам присвоить себе термин ФП. Иначе у нас приток людей иссякнет совсем, а он и без того слабый
[19:05:20] <ada_ru> (I_vlxy_I) ФП в резервацию!
[19:10:55] <ada_ru> (Eugene) в правильном ФП есть спец. резервация для всей этой вашей грязной императивщины, так что это ИП в резервацию!!!
[19:14:39] <ada_ru> (Eugene) цитирует (graninas)
Дядя Боб Мартин решил примазаться к восходящему тренду ФП. Даже подзаработать на этом.
[19:14:40] <ada_ru> (Eugene) цитирует (graninas)
<прислал документ>
[19:46:20] <ada_ru> (Лекс) За этой вашей декларативщиной совсем забываешь что происходит под капотом и как бы теряешь смысл из чего состоит реализация алгоритма.
Вместо простой итерации "сделай это так", приходиться думать о каких-то математических абстракциях (лямбды, херамбды) и зачем оно нужно, спрашивается?
А
[20:22:53] <ada_ru> (Eugene) если уж отказываться от абстракций, то спуститесь на уровень транзисторов тогда уж! решение будет заточено лишь под одну программу, зато эффективность выполнения выше чем у любых компиляторов
[20:30:12] <ada_ru> (Лекс) Всё это напоминает мне один случай из вуза, рассказаный моим другом. Преподаватель на уроке сказал, что не нужно стесняться использовать тяжеловесные яп с большим оверхедом, и вообще подналожить на оптимизацию, потому что железо позволяет.
Только вопрос бы в том, зачем гонять одну плюху если можно гонять десять плюх на том же железе(только программисту придётся слегка поднапрячся)?
[20:33:06] <ada_ru> (Eugene) ну так нужно искать баланс, что дешевле — напрячь железо или напрячь программиста
[20:33:53] <DiMM> channel list
[20:34:35] <ada_ru> (Лекс) Но вопрос абстракций был немного не о производительности, а о том, что в чистом ФП приходиться думать на уровне абстракций типы лямбды и прочего, хорошо если речь идёт об декларативном DSL и асбтракции уровня предметной области (фп здесь строго говоря не причём, многие люди путают функциональное программирование с декларативным программирование, которое включает первое как подвид, но не наоборот) тогда всё гуд, но когда речь о чистом ФП... посмотрел бы я на продакшен софт на Curry, Idris и на кайфующих мейнтенеров
[20:35:56] <ada_ru> (Eugene) автор идриса всегда прямо заявлял, что идрис не готов к продакшну, а на том же хаскелле, например, довольно многие в прод пишут
[20:35:58] <ada_ru> (Лекс) Тот же ерланг, не знаю что в нём хорошего в плане юзабилити, а до версии 15-й ещё и с числами работал плохо.
[20:36:15] <ada_ru> (Eugene) эрланг вообще вариант ООП на акторах
[20:36:24] <ada_ru> (Лекс) отвечает (Eugene) на <автор идриса всегда …>
Нередко используя его как императивный язык?)
[20:36:53] <ada_ru> (Eugene) отвечает (Лекс) на <Нередко используя ег…>
нук, один из авторов хаскелля заявлял как-то, что хаскель — лучший императивный язык ))
[23:59:03] <ada_ru> (I_vlxy_I) huh. калечный vscode не может в ppm картинки.