Racket быстрее для многопоточной работы, чем Go

Винить мы должны лишь себя …

Часто люди не стараются следовать Заповедям Бога.
Например - «Не искушайте Бога своего».
А разве не является искушением то, что вместо светлого и ясного пути выбираем ДЕРЬМО?
Болото имеет свойство - ЗАТЯГИВАТЬ …
Но победить не сможет, если человек будет отвращаться его и просить помощи БОЖЬЕЙ!
А это и есть

МОЛИТВА!  

Владимир

Услышав это, ученики Его весьма изумились и сказали: так кто же может спастись? А Иисус, воззрев, сказал им: человекам это невозможно, Богу же все возможно

Владимир

Можешь сделать другой замер на горутинах. Я напишу эквивалент на Racket. Сравним. Разве что в Racket придётся количество ядер параметром давать.

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

Можно конечно и с ограничением в N одновременных. Но тут у меня сомнения. Ведь оно встанет на копировании ввода. Это и будет ограничивающим фактором.

В общем, такие дела.

Услышав это, ученики Его весьма изумились и сказали: так кто же может спастись? А Иисус, воззрев, сказал им: человекам это невозможно, Богу же все возможно

Раз Господь сказал так, значит ТАК И ЕСТЬ!

http://bible.optina.ru/old:is:43:25

Ст. 25-26 
Аз есмь, Аз есмь заглаждаяй беззакония твоя Мене ради и грехи твоя, и не помяну.  
Ты же помяни, и да судимся: глаголи ты беззакония твоя прежде, да оправдишися

Владимир

Не так. Большинство на этом форуме - Владимиры. Он как бы один, но его много.

Владимир

Не так. Большинство на этом форуме - Владимиры. Он как бы один, но его много.

Модераторы говорили что их лишь два … Помните, когда DELIRIUM куралесил.
И? …

Владимир

Помните, когда DELIRIUM куралесил.

Его Метапрог взял в жены, теперь ему не до ЛОРа.

Не надо над Делириумом шутить - его больше нет. Поищите в архиве ностей некролог!

Линуксоиды мрут как мухи. Я предлагаю ввести утренние пробежки и айробику для всех причастных. Иначе доступ только к проприетарному ПО.

Ну как умерло. Последний комит июнь 2021.

Хаскель вики говорит, что проект с 2019 года поддерживается только для Nix. Я не знаю значит ли это что-то, но в директориях linux, macos и win32 последний комит - четыре года назад. Но я больше о том, что эта штука не смогла стать ни то что «стандартной ИДЕ для хаскеля», а даже сколь-нибудь популярной.

Представление о том насколько оно хорошо работает получил - спасибо. (:

Есть общая для всех хаскелевских проектов проблема: собрать под нужные версии библиотек и платформы.

Это ведь проблема всех компилируемых языков?..

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

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

А если пытаться в зависимостях взять фиксированную версию, то она хочет старый ghc, а старый ghc хочет старую операционную систему.

Свежий GHC старые библиотеки не собирает? А почему? Обратную совместимость регулярно ломают?

Кстати, в этом Racket тоже лучше. Я на современной версии могу взять пакет 2007 года и он скомпилируется и запустится без каких-либо плясок с бубном. В Haskell за это время почти у всех библиотек поменялось API.

Справедливости ради, неизменность АПИ может значить как стабильность, так и отсутствие развития.

Это ведь проблема всех компилируемых языков?..

Нет. Даже для C++ нет особой проблемы запустить программу, которую последний раз модифицировали в 2007. Для С нормальным считается скомпилировать без модификаций то, что было написано 30 лет назад.

У Haskell есть две инфраструктурные проблемы: во-первых, меняется язык (базовая библиотека), причём несовместимым образом; во-вторых, у новых версий платформ нет режима совместимости. Например, у 1С есть первая проблема, но благодаря режиму совместимости можно взять новую платформу и запустить старый код в режиме совместимости.

Вот суть проблемы: https://www.reddit.com/r/haskell/comments/4ip34h/avoiding_backwardincompatible_language_changes/

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

У leksah тысяча звёзд и сто ветвлений. Это его не спасло.

Свежий GHC старые библиотеки не собирает? А почему? Обратную совместимость регулярно ломают?

Да. В основном на уровне базовой библиотеки. Всё равно, что в Си в 1990 взяли и поменяли бы во всей стандартной библиотеке char* на struct string { char *begin, *end; }.

Справедливости ради, неизменность АПИ может значить как стабильность, так и отсутствие развития.

Скорее демонстрация проблемы с отсутствием инкапсуляции в Haskell. Разделили, например, класс типов Monad на Monad и Applicative: всем надо переписать свои монады (https://wiki.haskell.org/Functor-Applicative-Monad_Proposal). Для ООП выделение из класса базового суперкласса проходит бесследно для кода, использующего класс. Для Racket вообще модуль предоставляет именно API с полным сокрытием деталей реализации: недавно полностью заменили потроха на Chez Scheme, но API осталось без изменений. В Haskell можно было сохранить API создав новые классы типов (Monad2, MonadPlus2, …), но это похоронило бы язык ещё быстрее.

Настрочил МНОГО БУКВ и СТЕР.

Пусть ребята получают радость от общения о своих любимых языках программирования …

Владимир

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

А вот скала тоже кажется хорошим вариантом, хоть и со стороны.

Только по сравнению с Haskell практически не выигрывает: https://contributors.scala-lang.org/t/backwards-compatibility-in-scala/1017

в такие темы прийдут те же самые люди с теми же самыми лопатами с тем же самым

Ну всё-таки люди на лоре хоть немного да меняются. Как в плане состава (уходят одни, приходят новые), так и лично (хоть и не все).

Лично я именно ради таких тем когда-то на лоре и зарегистрировался. Люблю хороший языко-срач.

Нет. Даже для C++ нет особой проблемы запустить программу, которую последний раз модифицировали в 2007.

Я просто не сразу понял (поверил), что в хаскеле настолько нет обратной совместимости. Но вообще это странно: я слышал, что мол prelude в хаскеле содержит много мусора и есть альтернативные варианты, но поменять для всех не могут или не хотят как раз из-за совместимости. Или всё-таки иногда ломают? Или ломают многочисленные расширения языка, без которых всё равно никто не пишет?

Вот суть проблемы: https://www.reddit.com/r/haskell/comments/4ip34h/avoiding_backwardincompatible_language_changes/

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

В целом интересно насколько это часто происходит. Если было (условно) пару раз за всё время, то не так страшно и может даже лучше, чем копить легаси. Если же происходит регулярно, то действительно выглядит не очень. Так-то, раз уж ты упомянул С++, то там тоже было немало сложностей из-за COW оптимизации для строк в стандартной библиотеке GCC. Это правда слегка другая проблема (собрать старый код целиком оно не мешало), но по инфраструктуре ударило. А ещё мне периодически попадались статьи в духе «как мы перешли с древней версии microsoft visual c++ на что-то более свежее». И обычно там немало приключений, иначе и писать не о чем было бы.

А в Racket правда делают #lang racket2/3/...? Ну и кажется, чтo если ты пишешь на каком-нибудь racket27 и тут откопал важные исходники racket1, то прочитать их может быть непросто. Особенно если не следил за языком всё это время. Это к тому, что если проект не модернизируется, то оживить (а не просто собрать) его будет не так-то просто.

У leksah тысяча звёзд и сто ветвлений. Это его не спасло.

Не понял аргумент. Часто ставлю проектам звёздочки по принципу «о, прикольная штука, может что-то из этого и выйдет». Это совсем не значит, что я активный пользователь.

Насчёт «спасения leksah» вижу только два варианта: какая-нибудь компания вложится деньгами (но зачем?) или возникнет критическая масса активных пользователей. Последнее тоже весьма маловероятно: когда появилась эта IDE, то у хаскеля ещё, кажется, не было своего «language server», а теперь-то ещё проще прикрутить поддержку языка к vs code или emacs. Плюс у меня сложилось впечатление, что в среде хаскелистов несколько пренебрежительное отношение к IDE (правда кажется, что оно отчасти вызвано отсутствием соответствующих инструментов).

Для ООП выделение из класса базового суперкласса проходит бесследно для кода, использующего класс.

Если я правильно понял, то аналогия не совсем верная. Это как если бы в С# вместо двух интерфейсов IComparable и IEquatable когда-то был бы один (первый), а потом их решили разделить - естественно клиентский код, который реализует этот интерфейс, пришлось бы изменять.

Выходом было бы ввести, как ты и предлагал (если это твой вопрос на реддите), какой-то маркер «это старый код», который компилятор обрабатывал бы иначе. К слову, в расте так и сделано (там это называется «эпохами»).

В общем, или я не понял или это не совсем проблема «отсутствия инкапсуляции».

Только по сравнению с Haskell практически не выигрывает: https://contributors.scala-lang.org/t/backwards-compatibility-in-scala/1017

Я не прав или там речь идёт всё-таки о бинарной совместимости? Не уверен, что у хаскеля это вообще есть.

Но в мажорных версиях язык довольно сильно меняют, это да.

Я до сих пор вздыхая смотрю на Паскаль … Там было всего в избытке …

Владимир

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

Аналогом можно считать Qt. Вроде всё похоже, но взять программу, использовавшую Qt2 и скомпилировать c Qt5 не получится. Поставить одновременно общесистемно две версии Qt тоже, насколько я знаю, нельзя.

А в Racket правда делают #lang racket2/3/…?

Если изменения существенные, то да. Но такой был всего один (переименование PLT Scheme в Racket). И ожидается ещё один (#lang rhombus). В остальном просто делают новые функции/конструкции, а старые оставляют. Как в Си.

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

Да, похоже на то. Тогда я не прав.

И самое главное: в Racket я могу в одной программе использовать модули на старой PLT Scheme, Racket, Typed Racket, Rhombus и собирать из них один бинарник. В Haskell взять одну библиотеку старой версии и одну новой никак — надо брать из одной «эпохи» (в Haskell это называется lts). А если на новую эпоху библиотеку ещё не портировали, то хочешь сам пиши, хочешь жди.

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

Что касается котлина. Офигенный язык! Мне только мутными показались делегаты свойств, но видимо есть спрос. И вообще, в котлине очень-очень много взяли из скалы. И хороший код на скале будет похож на котлиновский, а я видел много скаловского (закрытого), как хорошо написанного, так и ужасного качества. Это в контексте скалы 2. Со скала 3 пока толком не знаком.

Что меня поразило, так это то, что во введении Programming in Scala, 5th ed. нет ни одного слова о котлине - как будто сильно обиделись на питерцев за то, что те украли лозунг «скала - это улучшенная джава». Современная и актуальная версия звучит, что все-таки «котлин - это улучшенная джава», а совсем не скала!

Вообще, я просто офигеваю от того, насколько удачным получился котлин!

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

#lang rhombus

Очередная попытка избавится от скобок? Надеюсь, они не собираются сделать s-выражения deprecated?

Надеюсь, они не собираются сделать s-выражения deprecated?

Запрещать пользоваться ими не будут (lang racket останется). А в том смысле, в котором MzScheme, действительно будут deprecated.

Мне больше интересно, будут ли переписывать на rhombus стандартную библиотеку.

Между релизами версий языка совместимость ломают: https://contributors.scala-lang.org/t/my-dsls-scala-3-migration-future-is-unclear-what-to-do/4944

Разные версии языка в одном проекте использовать нельзя.

Похоже, буксует проект Rhombus: https://beautifulracket.com/appendix/thoughts-on-rhombus.html

И это хорошо. Пока, насколько я знаю, ещё ни одна попытка убрать скобки из лиспа не закончилась хорошо. Автор правильно пишет:

The idea of “Scheme without paren­theses” sounds like “math without numbers” - doable but obtuse.

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

https://srfi.schemers.org/srfi-110/srfi-110.html

Похоже, буксует проект Rhombus

Буксовал (статья июля 2021). Но судя по активности на https://github.com/racket/rhombus-prototype/commits/master и отчёту от октября 2021 процесс идёт.

Не ищите Закон в книгах ваших с писаниями, ибо Закон есть — Жизнь, писания же мёртвы. Истинно говорю вам: получил Моисей законы Божии не писанными, но Словом Живым.

Иными словами, Владимир, со своею мертвичиной идите ка лесом.

Иными словами, Владимир, со своею мертвичиной идите ка лесом.

Вам стало легче от того, что вы заставили меня плакать? Почему здесь столько злобы и яда …

Владимир

Поставить одновременно общесистемно две версии Qt тоже, насколько я знаю, нельзя.

Ну можно слинковать статически. (:

В Haskell взять одну библиотеку старой версии и одну новой никак — надо брать из одной «эпохи» (в Haskell это называется lts).

Tогда это действительно проблема. Странно, что с этим ничего не делают.

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

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

От кого-то слышал мысль, что в хаскеле язык прекрасен, а всё остальное плохо, а в расте наоборот. И надо сказать что-то в этом есть.

Современная и актуальная версия звучит, что все-таки «котлин - это улучшенная джава», а совсем не скала!

Согласен, но я бы тут акцент слегка иначе поставил: котлин - это именно «улучшенная джава», а скала - нечто большее. (:

скаловские имплиситы - особая тема, в некоторых проектах их не любят, в других везде их суют, надо - не надо.

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

И это хорошо. Пока, насколько я знаю, ещё ни одна попытка убрать скобки из лиспа не закончилась хорошо.

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

А есть/будет typed rhombus?

Ы!

А есть/будет typed core?

А что это?

Ну можно слинковать статически. (:

А с двумя версиями Qt разве можно?

Tогда это действительно проблема. Странно, что с этим ничего не делают.

Также как и в Qt. Нельзя в одной программе использовать виджет от Qt2 и от Qt5. Просто такой подход. Все разработчики должны обязательно переписать свои приложения при выходе новой версии Qt/lhs.

А есть/будет typed rhombus?

Наверняка. Rhombus ведь всего лишь синтаксис.

Typed Racket разве не оно?

Кто-то когда-то на ЛОРе рассказывал, что не смотря на появление модуля Typed Racket, «самое-самое» ядро как было «безтиповым», так и осталось… Может что изменилось с переходом на Chez Scheme? Хотя с чего бы, не помню я в Chez Scheme «типизации»…

Т.е. «под капотом» у Typed Racket всё та-же схема без обязательной типизации, а о какой оптимизации тогда можно говорить… Только о «дополнительной безопасности»…

А с двумя версиями Qt разве можно?

Очень сомневаюсь. Это я скорее на «общесистемно» отвечал: так можно иметь несколько программ использующих разные версии Qt.

Ну вот и с хаскелом где-то также. Можно слинковать статически. Хотя GTK, через который работает GUI, насколько я помню, статическую линковку не поддерживает.

Т.е. «под капотом» у Typed Racket всё та-же схема без обязательной типизации, а о какой оптимизации тогда можно говорить…

Типизация не для оптимизации. Для целей оптимизации и так где возможно вычисления выносятся на этап компиляции и явные проверки типов выкидываются.

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

Также как и в Qt. Нельзя в одной программе использовать виджет от Qt2 и от Qt5. Просто такой подход. Все разработчики должны обязательно переписать свои приложения при выходе новой версии Qt/lhs.

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

Но да, в среднем с этим жить можно: если библиотека поддерживается, то её обновят. А если нет, то и баги там никто фиксить не будет.