Ну, ты просто сказкой ее назвал.

Мне лень щас гуглить последовавшие объяснения про точность понимания этого подхода

Мне лень щас гуглить последовавшие объяснения про точность понимания этого подхода

Интересно просто а в хаске есть такой подход или в либе( сам понимаешь у разрабов разногласия Как обработать ошибку или Не надо)

И это точно выражаться мне лень, сегодня во всяком случпе

Как и везде depends on

И это точно выражаться мне лень, сегодня во всяком случпе

Ладно подумаем?

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

Будто есть простые ответы, где-то cleanup и рестарт, где-то нужно сообщить и они что-то должны восстанавливать и т.д.

Вот и в эрланге типо лень каждую ошибку парсить просто перезапустим сервис- мне это нравится

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

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

Да я с этим согласен причём полностью

Вот если рестартовать на ошибке парсинга, я не уврене

Вот и в эрланге типо лень каждую ошибку парсить просто перезапустим сервис- мне это нравится

Оно не так немного работает. ?

Вот что ошибки железа, и софта и т.п. одинаково трактовать и понимать что из части рекавер невозможен

Угу

Оно не так немного работает. ?

Я образно нарисовал

Не это у эрланга на уровне интерпретаторв=а - а хаск напрямую - это просто эрланг машину на хаскеле сделать итп?

Причём я думаю это реально?

Ээээ, вообще-то beam на plain c написана с ассемблерными вставками. Причину, думаю, не надо объяснять.

Ээээ, вообще-то beam на plain c написана с ассемблерными вставками. Причину, думаю, не надо объяснять.

Ну можно сам сказал - а про скорость или надёжность это выбор!

Кто-нибудь пробовал ghc собирать с помощью clang? Без тулчейна gcc.

Кто-нибудь пробовал ghc собирать с помощью clang? Без тулчейна gcc.

Зачем....?

Зачем....?

Потому что шлангом можно пересобрать большинство библиотек, которые под виндой или макосью существуют. А gcc - он к своему несчастному линуксу слишком крепко привязан и вслед за собой ограничивает использование ghc. Здорово, конечно, писать велосипеды, используя одну только стандартную библиотеку хаскеля, но не разумнее ли получить доступ к огромному количеству уже написанных библиотек?

Всем привет!

Привет.

Какая разница чем собирать ghc? И при чем здесь доступ к огромному числу библиотек

Хм. И правда. Надо же просто прикрутить шланг к ghc для сборки проектов

cabal.config cc-path: clang

Во, супер :)

Сегодня попробую

Я по памяти писал, если не сработает напиши, я перепроверю

Может опция по другому зовётся

Да я вроде умею справку читать, спасибо :-)

Мне кстати интересно что шланг реально даст из конкретных примеров

Даже на Эльбрус не скомпиляешь :) /* режим троллинга*/

Да есть у меня маленькая проблема.

Не хочу я линковаться с qt, скомпиленным gcc

а какая разница чем собрано? gcc там или clang?

Но ведь сборка qt совсем отдельно от сборки программы

Оно ж слинкуется если разные компиляторы?

В том и дело, что не линкуется

Во всяком случае с qt, собранным msvc не линкуется

Теоретически, можно решить проблему. Но что-то мне не хочется таким путем идти

А ghc вообще умеет в C++ ABI? ?

В плане, подгружать крестовые классы/объекты/шаблоны напрямую через FFI без обёрток

Я кухню толком не знаю, но вроде как через голый ffi грузит. Точнее, обертку сама библиотека ffi делает и компилирует при сборке.

Вчера, кстати, не взлетел у меня вариант с clang. Ругается на непонятные директивы в ассемблерном коде.

Что-то я не так настроил, короче

Склоняюсь к мысли, что нужно сменить backend (как это будет по-русски?) на llvm, но в справке об этом мутно написано. Вроде как это для формирования байткода под виртуалку llvm, и неясно, это то, что нужно или нет

Я кухню толком не знаю, но вроде как через голый ffi грузит. Точнее, обертку сама библиотека ffi делает и компилирует при сборке.

именно плюсовый интерфейс, не сишный?

у плюсов же name mangling

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

у плюсов же name mangling

Ну дык, я потому и спрашиваю)

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

Собирать любым компилером может, при условии что это будет gcc. Вроде как можно clang еще прикрутить, но что-то у меня не получается. А еще можно заставить ghc ,выдавать сишный код вместо нативного исполняемого файла и компилить дальше, чем захочешь. При условии, конечно, что это будет gcc :)

Именно с name mangling и связана проблема с выбором компилятора

Точнее с выбором лмнкера, но линкер от компилятора же зависит

Я про ffi-либу спрашиваю, которая обёртки для плюсовых интерфейсов генерит и компилит, если что

То бишь, допустима ли в принципе ситуация, когда ghc был собран с помощью gcc, а обёртки собираются clang'ом?

Конечно

Если поддержка clang доведена до ума. На MacOS ghc использует clang, судя по всяким stackoverflow, но в переписках разработчиков по этому поводу немало обсуждений необходимых патчей

Поддержка clang в генерируемых обёртках?

https://wiki.haskell.org/Cxx_foreign_function_interface

Если резюмировать то, что там написано (а информация там, насколько я понял, на пару лет устарела). то чистым FFI тут не обойдешься

Сейчас гляну, как это вообще делается с C++

Обертки пишутся с директивой extern "C"

ERROR: S client not available

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

С другой стороны, на экспорт ведь обычно выпускают только один класс, интерфейсный. Ну или несколько, не пересекающихся.

Скажу тут - хаск опять не прижился - на голанге за 2 часа всё сделал) Будем ждать когда после стэка ещё один шаг сделает на встречу(не холивар)

Скажу тут - хаск опять не прижился - на голанге за 2 часа всё сделал) Будем ждать когда после стэка ещё один шаг сделает на встречу(не холивар)

А в чем была задача? Я тоже на go пишу, на haskell посматриваю, но пока не чувствую себя в нем уверенно

А что конкретно не пошло?

@corpix я тоже на гоу пишу и на хаск просматриваю?

Да проект детский - консольная утила дла перевода - я 2 дня потратил как ошибки (но когда прочитал про 8 способов обработки в хаске я в ступор впал

Например теоретически приходят 8 прогов на хаскеи ии каждый любит свой подход к обработке - и что нам людям делать?

Один ушёл - и как нам переработать его материал?

Ну конвеншн нужен наверно

Ну конвеншн нужен наверно

Да думаю это нужно как воздух иначе яйцеголовые угробят это язык)

Ну так с любым языком и любой командой может быть)

Ну так с любым языком и любой командой может быть)

Я просто смотрел со стороны бизнеса - а там нет высоких материй - читал как го ругают и матерят) (как и хаскель) а вот подход голанг мне нравится

Either тебе не дает похожего в хаскеле?

Только ифы писать не надо

Either тебе не дает похожего в хаскеле?

Да но кроме Either там куча чего есть - хорошо если мы думаем одинаково а если разношерстная команда?

А какие еще невелосипедные варианты?

Я просто не работал в команде по хаску, поэтому и спрашиваю, что нынче модно

Кроме either, как очевидного варианта

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

А какие еще невелосипедные варианты?

Незнаю - мне хаск нравится что уже вроде всё предусмотрено - но шараханье доставляет ( если пер проект можно терпеть) но если например у Вас есть люди с деньгами как то это шокирует) (Джаву выбирают)

Помойму это не так сложно

В го можно паники начать бросать

Вместо ошибок

А какие еще невелосипедные варианты?

Да я понял почему нет команд на хаске - это боль )

Хоть ИДЕ нет(хотя она нафиг ненужна ) и много способов написать то же самое не доставляют - путь голанг один путь меня радует

То ли еще будет)

Я просто думаю может язык новый сделдать - декларативный умный и как конструктор( как в эрланг протестированный продакшн код) - тебе только логику писать)

А сколько времени мы провел с хаскеле?

В голанге берёшь либу уже всё сделано пишешь обвяку и делай деньги)

Хоть ИДЕ нет(хотя она нафиг ненужна ) и много способов написать то же самое не доставляют - путь голанг один путь меня радует

Смотря что считать IDE :) Я в youtube скринкастах видел как люди emacs затачивали до уровня IDE для haskell(для go тоже можно, достаточно prelude поставить)