servant VS reflex

> do you really have to understand language extensions?

You do when your code doesn't compile and you're trying to figure out what the error message means, or when the library you want to use makes heavy use of it for even basic functionality.

> These days one just enables GHC2021

My experience was pre-GHC2021. I basically had to enable at a minimum 5-6 language extensions in every single file.

> Mostly they're just about removing unnecessary restrictions from the older standard.

Yeah, those ones are usually fine. I have zero objection to things like FlexibleInstances or DeriveFoldable.

> Could you give an example?

I believe I was trying to implement Central Authentication Service using Servant. However, that required returning a custom HTTP status code. There has been an open Github issue for this since 2017, but it seems to require basically rewriting the entire framework: https://github.com/haskell-servant/servant/issues/732

Looking back at it now Servant does have "ServerError", but that basically requires giving up all the advantages Servant claims to have and I believe it was not a viable option at the time. Looking at the timeline I was probably also on Servant 0.15, and there seems to have been a rewrite since then.

I vaguely recall running into a similar issue trying to interact with a database, but I can't remember the details of that.

a HasSwagger instance for NamedRoutes was added in May 2022 (in this commit) but there hasn't been a package release since March

If you don't like this style, the usual alternative is to change mkDualAuthHandler to take two additional arguments, Proxy tag0 and Proxy tag1 (as e.g. lots of Servant functions do, for historical reasons).

Dunno if this is helpful, but I found this github issue about ResourceT and servant https://github.com/haskell-servant/servant/issues/1345

And what about the cabal repl --with-compiler=doctest, which was added recently, in doctest v0.20? I recently submitted a PR for Servant to use this in place of GHC environment files, because it seems less finicky to me. Was this a bad idea?

I asked a somewhat relevant question recently. Maybe you'll find this discussion somewhat helpful: https://github.com/haskell-servant/servant/issues/1547; two packages were talked about. One of the folks from Well Typed replied, and said they tried it recently (and worked fine).

You are highly encouraged to test this release out and let us know what you think ! For bug reports, features requests or any kind of feedback, just open a ticket on our issue tracker.

Even slower than :<|> quadratic compile time in number of routes?

Check this out https://github.com/haskell-servant/servant/issues/335#issuecomment-172300487

There's other people around here who would like to know your opinion about these GUI frameworks! I haven't written a GUI in Rust personally, but my favorite GUI framework is not at all OOP: https://reflex-frp.org/

Not to be confused with Reflex, allowing web apps in pure Haskell: https://reflex-frp.org/

FRP solutions sound very attractive. But reflex seems to be stuck on the outdated GHCJS, and I haven't been able to get it to build. The newer JS output in GHC doesn't yet have DOM support. And even if I used one of those, figuring out how to interact with a LaTeX renderer might be tricky.

I only have experience using Reflex, which I regard as the main contender for FRP UI libraries in the Haskell sphere. It's got a flashy website, but I think the documentation is a bit disorganized -- it took a long time for me to figure out how to get going with the library (you find some pieces of knowledge scattered here and there, if you look hard enough). My plan was to learn it well enough to onboard other people, but I don't think I could convince anyone who hasn't already decided that they're gonna make UIs in Haskell no matter the required effort.

Once someone has spent a bunch of time with Haskell and sees the value, they will find Nix if it makes sense. Maybe they'll want to play with https://reflex-frp.org, or they'll discover they want a better way to package 3rd-party dependencies, or they start using NixOS and want to nix all the things, etc. etc. Or, maybe they'll never find a use for it, and that's okay.

Reflex natively supports iOS, along with Android, desktop and web. I would recommend it for functional reactive programming in Haskell: https://reflex-frp.org

It's been awhile since I've tried to get into Ubuntu Touch/Linux mobile development in earnest. I'm currently working on an app using the reflex framework that I hope to eventually target Android, iOS, Desktop, and Linux Mobile.

If you're talking about the current Elm approach, I'm not sure. Otherwise, the paper I linked to notes some of the FRP libraries that existed at the time, some of which are still supported today (like reactive-banana), and otherwise I'd suggest looking at reflex, mentioned in the first post in this thread. I don't think it existed at the time the Elm paper came out.