SuaveIO is really nice to work with. Peformance is terrible but that could be fixed. Its on my list of things to have a go at improving some time with some PRs. I think the big low hanging fruit would be switching from async await to either Hopac or TPL, which is above my pay grade but there are lrobably othwr areas that could be tweaked. I encourage perf junkies to have a go at it, as it wonderful to work with.

There's a new F# project out there to utilize ASP.NET Core, which has got Kestrel under the hood. I just discovered it and have yet to do any performance testing, but I'd imagine it's pretty in-line with C# results.

https://dusted.codes/functional-aspnet-core

That looks promising!

the Suave extension for ASP.NET Core (https://www.nuget.org/packages/Suave.AspNetCore/) is fast and you can use lots of suave specific features, with same performant kestrel as base, because suave is added as middleware.

Or there is also a new attempt (https://github.com/dustinmoris/AspNetCore.Lambda) to use api similar to suave, more integrated with asp.net core itself (security/auth/etc).

fsharp would really take off if it had a framework as attractive as phoenix.

Is phoenix actually taking off outside SV startups?

There are zero Elixir jobs on my part of the planet.

Whereas F# is on my PC thanks to a full VS install done by IT, and I can at least use it instead of Powershell.

I've thought about this too, and unfortunately it is not feasible, because of the poor/nonexistent meta programming support in F#. Phoenix uses macros for optimizing functions from templates at compile time, handling translations in a clean way, and removing a lot of boilerplate.

Source: Have spent a lot of time with F#, including writing Type Providers (which would not solve the problem).

I'm not sure what you mean by optimizing functions. I understand quoting isn't the best thing going vs true macros, but fsharp has full metaprogramming capabilities and operator overload plus custom operators produce some nice DSL's.

Anyway, I don't think to be "attractive" it needs to match Phoenix/elixir macros. Nice frameworks can be made in fsharp, and its type system and tooling blows type specs and dialyzer out of the water.

Really it needs to be:

* (x-platform && easy to use) which is why I'm so keen for the official 4.1 fsharp release. The ecosystem around fsharp and dotnet core needs all the sharp edges ground down.

* Smooth OOTB experience

* Community momentum

* Excellent plug/middleware solution(building on top of asp.net core might be the right approach)

Then just let fsharp shine on its own merits.