Web-фреймворк и сервер для Haskell

Hakyll

Yesod? От O'Reilly даже целая книга есть «Haskell and Yesod».
Судя по разделам всё присутствует.

scotty

servant

это type-safe описывалка rest поверх wai. Всякие плюшки типа поддержки разных content-type и автоматической генерации документации и клиента присутствуют. Удобный.

NeonBones Насколько я понимаю, Yesod = wai + warp + ненужно, где ненужно = persistence, шаблонизация и бог весть ещё что. Так что этот вариант я рассматривал.

iVS Разве Hakyll вообще может в REST API? Я думал, он для чистой статики.

vorpal Напомнило анекдот:

 — Приборы?

 — Сто!

 — Что «сто»?

 — А что «приборы»?

Спасибо, очень близко. А с rest-wai/rest-gen ты не сравнивал?

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

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

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

Scotty. Точнее, warp+scotty. Юзаю, работает, держит простенький REST. Под вендой. Протечек и глюков не замечал... Но у меня нагрузка низкая.

Warp — вполне серьёзный веб-сервер со своей кривой обучения.

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

Если твой вебапп в корпоративной сети, то юзай аутентификацию через TLS. Также, не пожалеешь.

И да, я надеюсь ты в курсе что на хаскеле (в смысле GHC) под винду принципиально нельзя писать высоконагруженные IO-приложения. Если, конечно, не юзать IOCP напрямую.

обеспечение TLS

Обеспечение HTTPS и WSS, а вот как бы круто было если бы он обычный сокет умел в TSL оборачивать, тогда можно было не мучить жопу с OpenSSL в своем софет

софте

а вот как бы круто было если бы он обычный сокет умел в TSL оборачивать

А разве этим не занимается stunnel?

И да, я надеюсь ты в курсе что на хаскеле (в смысле GHC) под винду принципиально нельзя писать высоконагруженные IO-приложения

А там же вроде какие-то подвижки были, GHC.Event или как его, через overlapped IO виндовый реализовать. Не сложилось, или путаю?

не под виндой все ещё всё плохо. Те кто может сделать у того нету времени/желания/оплаты, остальным не сильно надо видимо..

Те кто может сделать у того нету времени/желания/оплаты, остальным не сильно надо видимо..

Всё сложнее. Нужно с нуля писать IO-менеджер под винду. Скорее придётся писать спекулятивный менеджер, который будет в бэкграунде читать данные из зарегистрированных дескрипторов в кольцевой буфер рантайма, а hRead будет просто копировать данные в GC-контролируемую область.

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

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

Короче говоря, полнейший дурдом.

я знаю, что происходит с RTS под винду, так же я знаю людей, которые делали либой асинхронное-IO под винду, они готовы эту либу обновить и продавать или если клиенту очень хочется то и запилить в гхц. Цену я себе даже примерно не представляю, знаю точно, что средняя з/п у них в разы или на порядок больше чем у меня.

Цену я себе даже примерно не представляю

Во-во. А всё дело в том что логика работы XXXnotify под линуксом невозбранно прослеживается и юзерспейсе в в кернелспейсе. А под вендой — методом проб и ошибок и реверс-инжинирингом.

А насчёт «запихать в GHC»... ИМХО, это выльется в очень и очень отдельный прайс.