Многопоточный питон... снова

ну пример из жизни: у тебя есть 1000 сайтов, тебе нужно зайти на каждый и извлечь какие-то данные. При последовательном отправлении запросов это займет, например, 2000 секунд, а при использовании 24 потоков - 180. при использовании потоков нагрузка будет распределена по ядрам. проблема при использовании многопоточности - это gil. в питоне есть два вида операций: cpu bound и i/o bound (ожидание ответа от операционной системы при работе через сокеты).так вот cpu bound блокирует основной поток, поэтому для них нужно использовать multiprocessong.

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

Многопоточный питон - для 1 апреля сойдет, но на троечку ;)

Автор языка возражал против отмены GIL потому, что это снизило бы однопоточную производельность.

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

Ааа… Я думал ты бредишь, а ведь первое апреля! Развёл, малаца.

ну пример из жизни: у тебя есть 1000 сайтов, тебе нужно зайти на каждый и извлечь какие-то данные. При последовательном отправлении запросов это займет, например, 2000 секунд, а при использовании 24 потоков - 180

Это пример IO-bound нагрузки, и с этой задачей простые потоки питона или асинхронные фреймворки легко справляются, потому что основную работу выполняет ОС, а не питон.

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

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

Ааа… Я думал ты бредишь, а ведь первое апреля! Развёл, малаца

Нет, к сожалению, я брежу.

Ты сабинтерпретаторы заюзал и и добавил к ним in memory db в рамках одного процесса?

Ты сабинтерпретаторы заюзал и и добавил к ним in memory db в рамках одного процесса?

3.9 релизят в этом месяце, и я сомневаюсь, что подинтерпретаторы войдут в него. По этой причине я даже не пытался что-то делать на них, а сделал реализацию на множественных процессах.

Что-то поверх shared memory что-ли тогда?

Пытаюсь представить реализацию, которая имела бы смысл.

для реализации многозадачности в питоне, у меня возникает вопрос: а на кой черт она вообще нужна?

Мысль здравая, лучше поздно, чем… но улыбнуло.

Мы заменяем всякие там Redis, RabbitMQ, Celery на родные питоньи решения

Теперь совсем смешно.

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

Но если эту сову натянуть на мультизадачный глобус, то она лопнет ;)

Что-то поверх shared memory что-ли тогда?

А есть еще варианты? Если ты про конкретно shared_memory и shared_ctypes, то это просто мусор - я не представляю, кто может этим пользоваться. Мне пришлось делать свой менеджер памяти и свой сборщик мусора. Собсна, в shared_ctypes тоже сделали свой менеджер памяти, но там он люто топорный, а сборщика мусора и вовсе нет

Пытаюсь представить реализацию, которая имела бы смысл

Я написал большую статью на инглише, еще до того, как начинал что-то делать. но дело было полгода назад и она серьезно устарела, а смысла обновлять что-то до релиза я не вижу, к тому же, я еще не принял всех решений по архитектуре. Коротко говоря, это набор различных контейнеров, вроде очереди, массива, ассоциативного массива, в разделяемой памяти и с поддержкой транзакций. Естественно, простой питоний код и простые питоньи объекты со всем этим делом не дружат, потому работа внутри этой «объектной базы данных» довольно сильно огорожена от первобытного питонового кода, в том числе из соображений банальной безопасности общих данных. Что, впрочем, не лишает возможности выдавать прямой указатель на данные из базы в протопитон.

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

Сейчас уже есть: работающий менеджер памяти; сборщик мусора; простая реализация ассоциативного массива на дереве и с закрытым ключом (читай «быстрый и жрет много памяти»); очень примитивная реализация односвязанного списка, в котором есть только добавление элемента в конец и итерация по списку - оба контейнера поддерживают транзакции, то есть, откат изменений и изоляция изменений в одной транзакции.

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

Мысль здравая, лучше поздно, чем… но улыбнуло

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

Мы заменяем всякие там Redis, RabbitMQ, Celery на родные питоньи решения

Теперь совсем смешно

А мне смешно, когда детишки под свои детское проекты и нагрузки разворачивают целые инфраструктуры. Кроме того, редис, например, не поддерживает вложенные ассоциативные массивы, а потому для хранения сложных питоновых объектов приходится применять JSON/Pickle/etc.

Если эти «всякие там» заменить на «питоньи решения», то вы получите черепашью скорость из-за огромных накладных расходов

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

Ты ошибаешься.

Если это не just for lulz для себя, типа «написать, прикольнуться, выбросить», а есть хотя бы минимальные амбиции довести до ума, чтобы этим пользовались, то статью написать важнее чем релизнуться. Чем быстрее напишешь, тем быстрее о проекте узнают и подтянутся ещё разрабы.

Будь уверен, ты зарелизишь в любом случае преальфу. Нет особой разницы между тем, что у тебя сейчас и тем, что ты планируешь релизнуть, и то, и другое — очень сырое по фичам и, к бабке не ходи, всё равно будет бажное, пока толпа не набежит. А на словах звучит уже круто. Посмотри на Vlang.

ML скажет спасибо. Я не про то, что числодробилки на питоне пишут, но вот иной раз ту же обработку текста хочется параллельно пустить, а не в 1 поток. Очень часто надо лопатить сотни и тысячи разных файлов независимо друг от друга, а потом результат уже сливать в один файл по которому уже пускать числодробилки.

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

Я тебе скажу, кто подтянется. Подтянутся люди, которые скажут «да это ерунда, в питоне так не делают». И действительно, в питоне так не делают. А у меня будут делать. На мой обзор проблем питона, например, 95% комментов были в духе «меня в книжке по другому учили». Это тридцатилетние старые пердуны, которые не могут даже представить, что что-то может быть по другому.

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

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

Посмотри на Vlang.

И что я должен там увидеть?

ML скажет спасибо. Я не про то, что числодробилки на питоне пишут, но вот иной раз ту же обработку текста хочется параллельно пустить, а не в 1 поток. Очень часто надо лопатить сотни и тысячи разных файлов независимо друг от друга, а потом результат уже сливать в один файл по которому уже пускать числодробилки

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

По файлу на процесс. Т.е. сами файлы независимые, например, посты ЛОР-овцев.txt по файлу на пост, но с тегами разметки, которые надо убрать, вот почистить от шумов, убрать знаки препинания, сформировать из них набор слов для какой-то модели, потом слить в общую простыню, найти незначимые слова, убрать их и обучить модельку по признакам в виде оставшихся слов. Это так, самой примитивное для примера, что может работать на практике.

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

Сейчас уже есть: работающий менеджер памяти; сборщик мусора

Это больше похоже на 1Hippeus (как-то так писалось, не уверен) того-же автора. Он в 14-м году много чего обещал, но что-то пошло не так. Вроде-как ему тоже возражали «тридцатилетние старперы» что это сложно и небезопасно.

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

Нужно подобие OpenMP с готовыми рецептами «нарезать для распараллеливания» и «склеить результаты». Если сделать удобно и не сильно накладно/медленно, то тебя будут носить на руках лет 5-10.

сами файлы независимые, например, посты ЛОР-овцев.txt по файлу на пост, но с тегами разметки, которые надо убрать, вот почистить от шумов, убрать знаки препинания, сформировать из них набор слов для какой-то модели, потом слить в общую простыню, найти незначимые слова, убрать их и обучить модельку по признакам в виде оставшихся слов

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

На мой обзор проблем питона, например, 95% комментов были в духе «меня в книжке по другому учили»

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

Но потенциальную полезность твоего инструмента я вижу сразу.

Про не production ready понятно, но всё равно я бы лишних телодвижений не делал сверх работоспособной версии, до привлечения какого-то внимания (ради фидбека).

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

Это больше похоже на 1Hippeus (как-то так писалось, не уверен) того-же автора. Он в 14-м году много чего обещал, но что-то пошло не так. Вроде-как ему тоже возражали «тридцатилетние старперы» что это сложно и небезопасно

Я не вижу чтобы проект продвинулся дальше идеи. Прям вообще не нахожу ничего совсем в интернете (кроме очевидной презентации https://www.youtube.com/watch?v=2_TDmQtWnD0 ). На самом деле, уже в 1993 году была реальная ОС, которая основывалась на взаимодействиях через разделяемую память:
https://ru.wikipedia.org/wiki/L4_(микроядро)

Да, сложно, да, небезопасно, но когда разработчиков системного софта это останавливало? В случае моего проекта вопросы стабильности и безопасности решаются просто: если любой процесс пишет 1 Мб случайных байтов в разделяемую память, то система с 90-99% вероятностью падает, вся и целиком. Для ОС такое недопустимо, но для системы доверенных процессов - вполне приемлимо, особенно если учесть, что сама по себе библиотека не даст из своих функций записать что угодно куда угодно, потому сбой возможен либо из-за бага в самом коде «СУБД», либо при злоупотреблении прямыми указателями (memory view). Собсна, ничего нового - многий софт на Си имеет примерно такие же гарантии стабильности и безопасности, и если у вас внезапно отвалится RabbitMQ из-за повреждения памяти в серверном процессе, то мало не покажется.

Нужно подобие OpenMP с готовыми рецептами «нарезать для распараллеливания» и «склеить результаты». Если сделать удобно и не сильно накладно/медленно, то тебя будут носить на руках лет 5-10

Вот это интересная идея, да.

Можно, но это не так просто, как нормальный многопоток.

Про не production ready понятно, но всё равно я бы лишних телодвижений не делал сверх работоспособной версии, до привлечения какого-то внимания (ради фидбека)

Я сейчас тесты гоняю из сишной программы, и месяца два уже не собирал даже те примитивные биндинги, что написал — они и не соберутся сейчас уже. Но вся идея проекта заключалась именно в поддержке питона или любого другого медленного и однопоточного языка, а иначе не получается proof-of-concept, иначе мы получаем куцую альтернативу тому же libmdbx. Делаю в свободное время и по настроению, потому за полгода только 5 тыс строк. Для сравнению, за примерно то же время на Vue/JS я написал 15 тыс строк.

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

И получить из этого ничего, кроме «очень значимого сообщества». Я не претендую на роль организатора-заводилы, который собирает вокруг себя всех подряд — меня интересует исключительно написание хорошего софта, и меня интересует общество людей, которые умеют это делать. Во всем мире есть считанные сотни разрабов, которые вообще понимают, как писать многопоточку. Не на уровне «защищаем общий ресурс мьютексом», а хотя бы на уровне «лишняя запись в общую память дает cache-miss, особенно на NUMA-системах, потому целостностью данных можно пожертвовать ради сохранения возможности масштабирования параллелизации», хотя бы на уровне понимания сути блокировок MCS и CLH, чтобы модифицировать и расширять эти алгоритмы, не теряя полностью весь смысл их создания в процессе, как сделал вот этот пациент:
http://concurrencyfreaks.blogspot.com/2014/06/clh-reader-writer-lock.html

К слову, я признаю, что полгода назад сам находился на весьма примитивном уровне понимания. По этой причине на полном серьезе хотел использовать исключительно reference counting, но вовремя осознал масштаб трагедии и сократил интенсивность подсчета ссылок при помощи упрощенного epoch-based reclamation аля RCU линуксового. Причем, ни деталей работы RCU, ни про epoch-based reclamation я в то время не знал.

Автор вланга доннейты успешно собирает.

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

Автор вланга доннейты успешно собирает

А, вот оно что. Ну так-то да. Можно еще шаманом целителем устроиться - там тоже донаты нормальные. Принцип простой: половину заработка пускаешь на пиар, чтобы завтра заработать еще больше и половину снова пустить на пиар.

Как хочешь. Но доннейты как правило помогают уделять чуть больше времени проекту.

Но доннейты как правило помогают уделять чуть больше времени проекту

Да, это правда. После релиза мне придется этим вопросом заняться, потому что иначе ничего серьезного не получится. Просто vlang тут — это плохой пример, поскольку автор проекта не разрабатывает софт — он разрабатывает методы выпрашивания донатов.

Нужно подобие OpenMP с готовыми рецептами «нарезать для распараллеливания» и «склеить результаты»

Вспомнил:
https://numba.pydata.org/numba-doc/dev/user/parallel.html

Я так понимаю, этот вариант неудобен и накладен?

Подобие OpenMP в Python не нужно, во-первых, потому что OpenMP - результат длительной работы квалифицированных программистов, во-вторых, использование OpenMP можно сделать в программе на Си, которую можно вызвать из Python.

Программировать плохо то, что уже запрограммировано хорошо - по моему наблюдению распространённая ошибка .

Подобие OpenMP в Python не нужно, во-первых, потому что OpenMP - результат длительной работы квалифицированных программистов

Честно говоря, я не представляю, зачем мне когда-нибудь бы понадобилось использовать OpenMP в сях. Какая разница, квалифицированные ли прогеры или нет, если фич в итоге мало? Этот костыль создавался для фортрана, где без него ничего не сделаешь, но уже в Си ему нечего ловить, поскольку Си не так ограничен, как фортран, что создает как возможности для параллелизации вне OpenMP, так и возможности для внесения багов в «безупречный» код на OpenMP. Вот эта штука повеселее будет:
https://software.intel.com/en-us/tbb

использование OpenMP можно сделать в программе на Си, которую можно вызвать из Python

...в доме, который построил джек. Питон здесь - лишнее звено.

Подобие OpenMP в Python не нужно

можно сделать в программе на Си

Программировать плохо то, что уже запрограммировано хорошо - по моему наблюдению распространённая ошибка

да и сам Python не нужен

При последовательном отправлении запросов это займет, например, 2000 секунд, а при использовании 24 потоков - 180

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

gil

Я конечно не погромист, но ожидание ответа сервера, многопоточность и GIL - только косвенно связанные вещи.

а как правильно?

Существующие потоки в питоне позволяют параллелить http запросы, хоть и на одном ядре. GIL на месте, но и параллельность http на месте. Узкое место не в этом, хотя, наверно, без GIL и с настоящими потоками код был бы приятнее.
Это я ещё до async не дошёл (я им ещё не пользовался).

Иногда хочется в питоне многопоточность каноничную, но рядом с GIL вставлять ее не дело - слишком много там на него завязано.

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

• Мне для GUI нужна была и для некоторых фоновых задач типа фонового парсинга относительно тяжелых порций данных через вебсокет. Да много таких задач можно придумать.

Покажите мне хотя бы один лисп с gil.

Не показывайте мне хоть один нужный лисп. Его нет, поэтому вы и влезли в не относящуюся к нему тему.

Покажите мне хотя бы один лисп с gil

Справедливости ради я должен заметить, что отсутствие GIL ни разу не значит возможность написания многопотоков. Первое, что обычно делает новоприбывший в многопотоки - это пишет четырехпоточное приложение, которое работает в два раза медленнее однопоточного.

https://github.com/uber/fiber/

Видел?

Поэтому все новоприбывшие в многопоток должны жрать корутины и gil?

ОК. Я, прибывши в многопотоки, писал хелловорлд на сишечке, разбив вход на потоки и кидая вывод на мьютексах. Оно работало точно быстрее однопотока.

За «возможность написания» можно взять культуру написания кода, не меняющего на каждый чих состояние сверху и сбоку? Лисперы такое практикуют, за питонистами такого что-то не особо наблюдается. Я уж не говорю про то, что у лисперов эту самую многопоточность можно обуздать тысячей и одним способом.

его нет

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

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

Python не мой. Это один из актуальных сейчас языков. Нет одного лучшего языка, но есть актуальные. Я в основном программирую на Java. На Python - немного, но есть области программирования, где он важен. Для Lisp-ов нет таких областей. Есть новые перспективные языки, интерес к которым у бублики растёт: Go, Rust, Julia и др. Частично они потеснят существующие языки, в том числе Python. Но Lisp просто никому не нужен. Вам нужен, чтобы хвастаться его знанием. Но для программирования не нужен.

Нападка на GIL со стороны пользователя Lisp-а нелепа. В Python ограниченная многопоточность хотя бы позволяет без ухищрений создавать GUI - один поток для GUI, второй для логики работы программы. В Lisp-е вообще нет стандартной поддержки многопоточности.

It is easy to learn. Fiber provides the same API as Python's standard multiprocessing library that you are familiar with. If you know how to use multiprocessing, you can program a computer cluster with Fiber

Дело в том, что multiprocessing изначально использует сокеты. То есть, как бы напрашивается перевод его на сетевой уровень. Однако, сам по себе multiprocessing тормознутый при условии взаимодействия процессов, и, к тому же, содержит баги плана SEGFAULT, один из которых я недавно вылавливал — там поток-демон оставался живой после уничтожения интерпретатора.

Далее: лишние фичи накладывают лишние ограничения, и то, что можно сделать на локалхосте, нельзя сделать в сети, например, разделяемую память, события, futex-ы, а отсутствие необходимости в сохранении данных на постоянном носителе дает возможность разгуляться в промежуточных состояниях.

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

Поэтому все новоприбывшие в многопоток должны жрать корутины и gil?

Потому что обратная совместимость и готовые решения. Есть валом многопготочных диалектов питона, но CPython-совместимый интерпретатор в принципе не может быть многопоточным, потому что именно таким его сделал Гвидо.

ОК. Я, прибывши в многопотоки, писал хелловорлд на сишечке, разбив вход на потоки и кидая вывод на мьютексах. Оно работало точно быстрее однопотока

Ну пиши на Си в питоне дальше, в чем проблема?

За «возможность написания» можно взять культуру написания кода, не меняющего на каждый чих состояние сверху и сбоку?

By design же ж. Это один из самых главных недостатков питона, согласен. Но что предложишь делать с готовыми решениями, которые опираются на возможность поменять состояние сверху и сбоку? Я вижу это так; поддерживать совместимость с отвратительной архитектурой CPython и при этом развивать ее - принципиально невозможно. По этой причине я поднимал тему о преобразовании питона и устранении недостатков — на фоне моего проекта появляется необходимость в новом диалекте, для которого будет допустима несовместимость с CPython, потому что в любом раскладе реализовать полную совместимость со всем этим бардаком не представляется возможным. Да и нет смысла к этой совместимости стремиться, потому что многозадачная среда заметно отличается от однозадачной — вспомните ту же асинхронщину/подзадачи питона, под которые приходилось переписывать библиотеки.

Не показывайте мне хоть один нужный лисп. Его нет, поэтому вы и влезли в не относящуюся к нему тему.

Clojure — вполне себе нужный. В каком-то смысле нужным он стал потому, что ограничил возможности метапрограммирования. Метапрограммирование — это проклятие лиспа, поскольку для прочтения типичного проекта даже среднего уровня приходится выучить десять языков, поскольку лисперы считают своим долгом под каждую мелкую задачку написать свой DSL инструментами лиспа.

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

Я тебе всё уже сказал, но ты продолжаешь упорно долбиться об ворота. Отвечу своими же словами.

Это один из актуальных сейчас языков.

Через некоторое время загнётся.

Нет одного лучшего языка, но есть актуальные.

Смысла сидеть на распиаренном языке и бегать в толпе хипстеров нет.

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

Это называется «распиаренность». Стоит множеству людей, обеспечивающих питон сишными батарейками, показать новый язычок, как они с дикими криками питон оставят. И убегут. За ними полетят фреймворкоделы. За ними полетишь ты. Вот и всё, питон умер.

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

Есть новые перспективные языки, интерес к которым у бублики растёт: Go, Rust, Julia и др.

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

Ничего особо нового в том же Go нет. Как и смысла на него переходить. Кроме пиара. В Rust, может быть, смысл есть, но тут я передам слово лавсану, он его трогал, я - нет.

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

Пишу для себя на Scheme. На Elisp у меня обвязан редактор. Скоро пойду смотреть на Guix, где пишут потихоньку юзерлэнд на Scheme. CL пока не трогал, но если захочу что-нибудь с батарейками, с поддержкой образов (пока что я делал горячую замену кода через REPL в соседнем потоке) и я не захочу их обвязывать, пойду смотреть его.

похвастаться его знанием

Тут как бы это, хвастаться нечем. Стандарт одного из лиспов занимает 50 страниц: https://bitbucket.org/cowan/r7rs/raw/4c27517de187142ad2cf4bcd8cb9199ae1e48c09/rnrs/r5rs.pdf

Язык простой и консистентный, ни капли синтаксического мусора; он проще питона, чем сам питон. Если синтаксиса не хватает, можно не ждать, пока добрый дядя Оракл или BDFL его запилят. Его можно запилить самому. Большая часть синтаксиса между разновидностями лиспа легко портируема. Даже гигиенические макросы, которые не любит Лавсан и когда-то не любил я (сейчас-то мне без разницы, какими пользоваться, но тяготею всё-таки к обычным и er/ir), можно использовать в стиле обычных лиспомакросов.

Нападка на GIL со стороны пользователя Lisp-а нелепа.

Это почему же? Потому что практически все реализации лиспов делались правильно, без расшаренных направо и налево данных?

В Python ограниченная многопоточность хотя бы позволяет без ухищрений создавать GUI - один поток для GUI, второй для логики работы программы.

Wow. А в C многопоточность без ограничений таковой поток, да и GUI, создавать не даёт ну никак. В Racket GUI делается прямо-таки с особыми ухищрениями. Биндинги для Qt и Gtk в реализациях Scheme работают с адскими костылями. Вы бы перед тем, как говорить за лисп, посмотрели бы на реализации. Я-то пользовался и питоном, и лиспами; я хотя бы имею представление о том, что говорю.

В Lisp-е вообще нет стандартной поддержки многопоточности.

В C тоже нет стандартной поддержки многопоточности, представьте себе. В разновидностях лиспа поддержка многопоточности таки есть (пусть и единой для всех, всеобъемлющей нет) и, представьте себе, на десятки реализаций Scheme и полудесяток реализаций CL нет ни одной реализации с GIL. Лисперы вообще не подозревали, что можно так уродовать рантайм.

никсы только-только начинают отказываться от третьей ноги в виде X-сервера.

Не никсы, а GUI-тулкиты, решившие на иксы выдавать не инструкции по отрисовке графики, а саму графику.