What you're talking about was the HAppS-State component of the HAppS application server, a project which is in deed not active anymore. Happstack is the active fork of HAppS and had a "happstack-state" component for a while, but this was eventually rewritten from scratch and made independent of Happstack and is now known as acid-state [1]. It's even used for the new Hackage server that powers the Haskell package ecosystem.
You probably meant set -U because you probably don't want to export fish_greeting to child processes. fish_greeting is already universal though and you don't need the empty string to unset it. This is enough:
Possibly a historical artifact; fish was created in a time when the controversies surrounding lilo were fresh in memory and lilo was still boss. Actually there is a channel on freenode now, but it's about a third in size.
Other examples of projects officially on OFTC include: debian, tor, open street map, libvirt/qemu and related tech, ceph, awesomewm, gcc, smuxi... So fish isn't all alone there.
There are also projects that operate their own networks, such as GNOME and Mozilla.
Thing is in fish functions and completions load lazily as needed, and basically every customization is done with functions. Startup is pretty much instant regardless of configuration.
I think `-c` skips loading configuration. Launching a prompt will be much slower. In fish almost everything is a function and functions are loaded lazily.
Fish currently does not support executing shell functions or commands in the background with &, only external programs. This is a known omission, but the best way to fix it is to make the shell interpreter code thread safe so we can actually write multithreaded shell code. Currently fish only uses threads for potentially blocking i/o operations. But implementing this is quite a bit of work and has not been done yet.
Having said that, `enc &` erroring is indeed a bug, expected behavior would be to run the `begin ... end &` block in the foreground anyway.
Almost every exception a Python program ever throws is or can be made a type error (or otherwise statically caught) in Haskell and similar languages. A type error is not the same thing as a TypeError.
I would say that Snap is more like Pyramid and Happstack... not quite like anything else. Snap has snaplets, Pyramid has components.
Happstack on the other hand ... invented type-safe routing, which I haven't seen anywhere else before it. Dynamic languages tend to have something vaguely similar you might call "named routes" but they don't provide the same static guarantees.
Happstack likes to use templates mixed in with code, which sounds insane but note that this is rather different from code mixed in with templates. This templating is type-safe and syntactically checked at compile time, and allows reusing all of Haskell rather than a limited subset, so using modules and functions these templates easily end up more modular and composable than any template language you've ever seen before. Admittedly, it's not the most designer-friendly solution (but should designers really mess with the HTML to begin with?).
Happstack likes to use a persistence system for native Haskell values. I suppose you could say this is similar to ZODB with Pyramid, although it's "on steroids" (due to Haskell).
I'm biased towards Happstack as you might notice from this post, but the point I'm trying to make is more that Happstack is non-traditional (in the tradition of Haskell!) and not quite like anything else. This is often seen as a weakness because it means it is less familiar to new users; I might wonder why they're using Haskell to begin with, then. :-)
(You could even argue that Happstack should be more familiar, to Haskell programmers, because it favors reuse of existing Haskell idioms like combinators, algebraic data types, monad transformer stacks...)
That said, if you do want a more traditional framework, Snap and Yesod are both great options.
Believe it or not, Happstack is the one I favor and use, for basically all of these reasons (though I am far too much of a RDBMS partisan to use acid-state).
What you're talking about was the HAppS-State component of the HAppS application server, a project which is in deed not active anymore. Happstack is the active fork of HAppS and had a "happstack-state" component for a while, but this was eventually rewritten from scratch and made independent of Happstack and is now known as acid-state [1]. It's even used for the new Hackage server that powers the Haskell package ecosystem.
[1] https://github.com/acid-state/acid-state