Jet.com has an interesting post on why they chose F# for similar reasons [1]
[0] I'm working through the How to Design Programs book from Matthias Felleisen which I highly recommend despite its rough edges http://www.ccs.neu.edu/home/matthias/HtDP2e/
F# seems to be getting more attention, but I mostly just see people struggling to get EF migrations going, and it seems general ecosystem support is still shoddy (compiler bugs on .NET core 1.1? 3rd party VSCode support? official VS plugins crash all the time?). I have to use C# for work, so it's just not stable enough despite F# itself being around for ages :)
I'd definitely like to give it a go for some bigger projects.
Lisp let's me understand how procedures go together to build things. In particular, it helps get to a dual phase of programs. Macros aren't my program running. Rather, they are a program that makes the program I want to run. It just so happens that being able to cycle between those phases is very useful.
I can make no claims that one is superior.
Edit: s/string/strong/.
Take ASP.NET, for example using method attributes for authorisation:
It's great and magical if you want to lock down a controller or a method to admins only, or people whose standard user object has an Age field > 18 or something like that. But if you want per-project permissions, with a user->permissions<-project relation? Sorry, you can't easily pass invocation parameters to your AuthorizationPolicy classes because C# Attributes don't support that. You could try having a naming scheme for your url fragments and get the project ID from there, but this means you need to have project parameters in every route, which is often redundant and would need to be checked on any object in a POST request. Any way you go, you have to write code inside your method to get the job done. You have to break out of the magic, and let go of the automatic 403 responses to do anything beyond the simplest case.To actually build this without a clumsy if/else and manually returning 403 with JSON (to describe the error) in every controller method, it was necessary to create an exception and a custom exception handler middleware, and in the handler, produce a non-standard HTTP code and catch it again in a second middleware after the framework would otherwise gobble up 403s and return HTML instead of JSON. Exceptions inside controller methods are a perfectly adequate model for authorisation failures, but because the framework expects you to hook into their middleware for it, they made it very difficult to do it any other way.
Ok, that was a lengthy example. But it illustrates what I mean by wanting to write my own magic. Frameworks shouldn't cripple userspace magic by design.