i wish this was written 3 months ago. Knowing what tools and libs i should use when coding in f sharp to perform a simple crud web api really was frustratingly difficult (for something that should be at the homepage of any server side language).
it made me quit and try a different language (swift), and now i think i'll stay in that boat.
That's too bad, because i really liked the idea of coding in an ML family language.
Never hurts to give it a try again! Three months ago, .NET Core 2.0 hadn't actually shipped yet. Although it was certainly possible to write these sorts of things on .NET Core 1.0, there was a significant lack of APIs which prevented many people from using .NET Core. Now that 2.0 has been released, I figured it was as good a time as any to push the use of F# for web services.
I'll also be posting next month about using Fable to write "full stack" F# with .NET Core (Fable compiling to JS, F# with the Suave library on the backend). It'll be a bit more involved (docker, deploying to Azure, etc.), so I hope that it's useful to folks. Perhaps after that's posted, you'd be interested in giving it another go?
Looking forward to new articles! F# as a language is a pleasure to work with, and I really hope it catches on a bit more.
Last time I tried implementing a web api in f# was with core 1.0, and it was fairly difficult to find a proper tutorial that was up to date. Hopefully 2.0 will bring a lot of more stable examples.
I believe that full dotnet core 2.0 support will be something of a watershed moment for F#...
.Net on linux has a lot to say for hybrid cloud installations and cloud based development in .Net land. F# is a near-perfect match for many of the scalable, containerized, solutions one wants deploy. The F# community is fundamentally more cross platform, so there are a lot of impressive possibilities for best-of-breed solutions coming to a kubernetes cluster near you "any day now" :)
Mono is great for what it is, but a unified cross platform VM built with an eye to cloud friendliness... That's gonna be something special.
In your opinion could Giraffe shape up to be a serious competitor to Phoenix Framework for mind share? If the F# community could get something like that off the ground I think it would do wonders for the platform.
Also, what's your opinion of Fable vs TypeScript as far as support for interacting with existing libraries? Fable sounds very appealing, however all the momentum behind TypeScript, its type features aimed at typing in-the-wild js code, and the massive defintely typed project are hard to pass over..
One of the big strengths of Fable is that it can easily work with existing TypeScript bindings. ts2fable allows you to convert a TypeScript binding to be used with Fable, which allows you to leverage that mindshare easily.
I was/am worried about the type gymnastics the TypeScript team has done to support in the wild code not being compatible with systems like scalajs and Fable(F#). Giving it another look now though, it's pretty promising seeing that Alfonso has implemented erased union types and even opened an issue to have them added to F# :)
> In your opinion could Giraffe shape up to be a serious competitor to Phoenix Framework for mind share?
I think it can, yes. Although, it is not the only technology for this. The other libraries mentioned in the article are also wonderful, and I recommend using them.
I'm not one to play favorites, but I do agree that something like this would be helpful for F# mindshare.
> Also, what's your opinion of Fable vs TypeScript as far as support for interacting with existing libraries?
I think Fable has its place to grow, even though TS is absolutely killing it right now. Eventually, you hit a bit of a wall with TS in that it's not really a functional programming language. I believe that a lot of people in the JS world are looking for an ML-style language, and F# through Fable fits the bill there.
deployment is a really an important phase ( hint : if you add redundancy and platform monitoring you'll be perfect), but i'd recommend adressing two others important steps, which, imho, are more important than F# to js transpiling ( very few tech beyond node allow you to use the same language anyway) :
- work queue ( or jobs or long running tasks or whatever you call them) : because most real world service need thoses
- websockets : because live data stream is also pretty common those days.
From enthusiast to enthusiast, I agree that the state of F# is quite frustrating, however the route I chose is to forgo traditional development, I'm just using functions (Azure + Serverless). In my view, using a cutting edge language means cutting edge solutions for better or worse.
it made me quit and try a different language (swift), and now i think i'll stay in that boat.
That's too bad, because i really liked the idea of coding in an ML family language.