Look I'm no ML engineer or even a data scientist, I'm much closer to PS/VBS/AutoIT land, writing C# Console Applications for really complicated stuff and/or exposing helper methods via a simple web service, but I am increasingly liking F# for its pattern-matching and type providers that let me 'lock down' bugs much more than I can in imperative languages. I get that I'm probably misusing F# for general-purpose stuff, but no matter what I like that I can write my helper web-services in F# now and not just C#/VB.
Hopefully F# will become even more mainstream than it is right now.
I started out during the Node + JS revolution and I am more than certain I am seeing a similar level of innovation happening in F#. The community is titled towards more mathematicians and scientist, but mainstream adoption is right around the corner.
I've been on an ASP.NET Core project full-time for a year. Lately, I find myself wondering "Would it be nicer to write this part in F#?" almost every day.
There's some inertia there simply because I keep thinking that the next person will hate me for forcing F# on them, but it's almost a siren call at this point... I might have to just pull the trigger and commit a .fs file.
Go for it! Wiring up a new F# project is quite simple:
dotnet new library -lang F# -o FSLib
cd CSharpASPNETApp
dotnet add reference ../FSLib/FSLib.fsproj
There are some templates in the .NET Core SDK for ASP.NET as well, so if folks are wondering if it's possible to use F# with ASP.NET Core, the answer is yes! There's even support for async controller actions using F# async expressions, so there's no need to do some of the more awkward interop between Async and Task.
You should use Scott Wlaschin's informative site "F# for Fun and Profit". He has does a good job focusing on using F# for what he calls BLOBAs... boring line of business applications. I think F# would be great for your business logic.
And more specifically: F# is a first-class .Net langauge.
That means it has full access to the Base Class Library and cross language interop. It's as "general purpose" as C#, but wildly better for most "general" development by a) having builtin scripting support, b) being multi-paradigm, and c) having an interactive REPL-based development cycle.
There are certain kinds of OOP constructs that will always make more sense in a pure OOP language... For the other 99.95% of development being able to drop all the cruft and simplify your tasks, simplify your namespaces, and simplify your apps is a beautiful thing. Even while learning: at anypoint an imperative, OOP, or mutable solution makes sense you can just do it. You won't want to, but you can: easily.
F# feels as free and intuitive as Python in the small, while providing structural & type-based guarantees (and productivity!), that far outstrip C#/Java in the large.
[Arguably F# is also the first "mature" .net language in that it had the benefit of language design after most of the CLR was done... It's much more comfortable for dynamic generation/loading of AppDomains and such.]
Even though CLI improved with .net core 2.0, am I the only person feeling Interactive F# is missing? I know on Mono its fsharpi, but does .net core even has an equivalent ?
We haven't completed F# Interactive work for .NET Core yet. There are some big technical problems to solve there, and it's our top priority after we complete full support for the new project types in Visual Studio. Not timeline yet, but a workaround is to use fsharpi (from Mono) on unix or fsi.exe on Windows. Both use the same compiler that you get with .NET Core.
It seems that .NET Core still has no equivalent to fsharpi[0]. This is a feature that I also miss and would find helpful - I currently use fsi in visual studio as a replacement for opening up a calculator or using Python for scratch computation, and having the ability to run code directly from the IDE is nice.
What's the recommended way of doing SOA/microservices in .NET world these days? Are people still using WCF mostly? Or is there a clear new winner?
I'm searching for a new stack that will be both easy to work with, yet full of pluggable features if necessary (auth, async and non async channels, etc.). Since WCF is not present in .NET Core (will it ever be?), it would be good to find something solid that will last for as long as WCF did.
Azure Service Fabric replaces WCF. It takes all the good parts (like the interface-based programming model, interception pipeline etc.), throws out the unneeded complexity (around bindings, configuration etc.) and comes with built-in service discovery, fail-over, monitoring, deployment with rolling updates, and much more. It also supports the actor model with automatic state replication. Together with Azure Service Bus and CosmosDB it's the best stack for developing real-world .NET SOA systems.
That is not open source though, kind of skewed toward cloud deployments too. I need a stack that works perfectly on-premises and does not need additional services or artifacts to deploy. Does ASF meet such requirements?
Unfortunately I don't think SF meets your requirements. Even though you can run SF on-premises, this still requires you to install the SF cluster software on the nodes (VMs) that make up the cluster.
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.
The .NET native compiler has some issues with handling valid tail recursion MSIL commands IIRC - they're working on it.
F# will always come in second in the MS tooling wars.
Interesting, though, to follow the track record of MS techs that come in first in their tooling wars over the last decade... Maybe being a bit slow on the uptake of the "latest and greatest" EF, or Oslo models, or Silverlight, or WPF, or WCF, or dotnetcores new project format, or UWPs new APIs isn't the worst thing if you want your solutions to be supportable in production for a while.
Microsoft is pretty explicit that it is a stop gap to port applications to UWP.
That has been their main message in any presentation about the Desktop Bridge. Always showing how an existing application gets packaged, followed by replacing Win32 legacy features with modern UWP ones.
The track record of other tech giants is not much different, let alone the usual reboots on GNU/Linux desktop stack.
I'd go a step further: F# being slightly slow on the uptake of new shiney-shiney-shiney things from MS means you're less likely to hit solutions based on dead product lines and/or tech. A slight moderation in speed to avoid wasteful oscillations.
I'm glad that the F# community uses its time making generalized cloud computing easier and more accessible and has smart data streaming solutions. I care 0% about windows platform apps, along with most of the world (given the sales and user stats).
Not to mention: since you can always use C# and VB.Net as "glue code" with F# libraries behind that, you're generally only locked out of _pure_ F# solutions if you wanna play with the newest toys.
It's bad for consultants who need 5 years experience in 3 day old tech to sell themselves. It's good business for companies trying to build value and not try to stick with technical fashion-trends for no reason.
Hopefully F# will become even more mainstream than it is right now.