Though I have posted a few times on some of the awesome things F# can do for your code, that doesn’t necessarily mean it’s always good choice for each of your applications. You may look at the code features and and some sample code and think This is great, but I can’t see this being used other than in finance or data science projects. True, F# may be used fairly heavily in those areas, but I’d like to argue that it can be quite useful in enterprise applications, as well.
Lena, a fellow F# developer, has a very thought provoking article talking about F# in the enterprise especially when talking to decision makers at companies. I figured I’d expand on Lena’s post and offer my own thoughts to using F# in the enterprise.
The main thing about F#, that I’ve found, is that people often ask I like it, but where can I use it in my day-to-day development? Well, hopefully the below list will help out a lot and may even cause you to rethink what all F# can do for you.
Mobile applications are probably not exactly the first thing you’d think when you hear F#, is it? But it’s true. The awesome folks at Xamarin made F# into a supported language and it can be used to create Android, iOS, and Windows Phone applications.
Even though F# is functional first, it can definitely be used to write Object Oriented applications like these.
There is definitely more awesome stuff to come from Xamarin in terms of F#. There will be more F# templates and it will soon be easier to use Xamarin Forms with F#.
Build your next mobile application with Wintellect and Xamarin!
Wouldn’t it be awesome to just be able to enclose your code to run on the cloud like this?
cloud {
// Code to execute on the cloud servers
}
Well, with MBrace you can do that!
To see a demo of it in action, check out the below video from dotNetConf. I recommend the whole video but the MBrace awesomeness is around 33 minutes.
While I will always suggest trying out F# for the data access layer in any application because of how awesome type providers are, the language actually has quite a few frameworks and libraries to help with your enterprise web application development.
Suave is a fairly new F# library for a lightweight, non-blocking web server. Not only that, it’s fairly easy to get started. From their documentation, it only requires just a couple of lines, including opening namespaces, to get a very simple web server going.
open Suave // always open suave open Suave.Http.Successful // for OK-result open Suave.Web // for config startWebServer defaultConfig (OK "Hello World!")
WebSharper is probably the most popular F# web framework. WebSharper has a built-in F# to JavaScript compiler so you can do fully rich websites without writing any JavaScript.
Of course, since F# is a CLR language it can still be used with straight ASP.NET. There is even an extension where you can have your MVC project all in F#.
I believe one of the best ways to incorporate F# into the enterprise is to use FAKE to create your build scripts.
Even Scott Hanselman has a post about using FAKE and Suave to deploy to Azure.
While NuGet does do a good job managing third-party assemblies, there is a fairly new way to do this and, honestly, I prefer this better. Paket still uses NuGet, but Paket can also reference GitHub or Gist dependencies as well as HTTP dependencies.
I hope this helped shed some light in some ways F# can benefit your enterprise applications. Look forward to future posts that go into some more detail in several of the ideas presented.
Cloud management is difficult to do manually, especially if you work with multiple cloud…
Azure’s scalable infrastructure is often cited as one of the primary reasons why it's the…
https://www.youtube.com/watch?v=wDzCN0d8SeA Watch our "Unlocking the Power of AI in your Software Development Life Cycle (SDLC)"…
FinOps is a strategic approach to managing cloud costs. It combines financial management best practices…
Using Kubernetes with Azure combines the power of Kubernetes container orchestration and the cloud capabilities…
In the intricate landscape of modern business, compliance is both a cornerstone of operational integrity…
View Comments
I've been a big fan of the F# language and concepts since version 2. I've written custom lexers/parsers and language designs with it. I've also found it powerful for high-speed file stream processing.
BUT I am here to play devils advocate today, because I can't really see much value in employing F# for common enterprise scenarios. Xamarin/MBrace I don't know much about so I wont speak about it. Suave syntax and distribution of logic makes it unwieldy for enterprise web services. Maybe this will be improved in a future version but I would only employ it in a microservice architecture. WebSharper hides javascript under F#. I learned a painful/valuable less on macro-javascript languages when using coffeescript: if youre developing javascript, write it in javascript or use a react container. When your application breaks, the errors will be in javascript and the debugging will happen in javascript, the inability to trace this back to F# brings pain.
ASP.NET: Granted F# is generally easier to develop with than C#, the tooling for C# in ASP.NET makes it a far better choice. the scaffolding, entity framework/linq and razor make the most common requirements much easier. Every time I take another look at NHibernate/razor/scaffolding support in ASP.NET for F# it seems it is a path far less traveled and less community/support/documentation out there.
Of course I'm not making the argument that these tools aren't useful in specialty scenarios but for those of us that know BOTH F# and C# (and generally lead teams who know C#) there isn't enough ammunition to justify departing from the plain old tool sets that have been the standard for years. Inertia in the enterprise realm is great, and C# continues to improve so I don't see this changing in the near future.
I've been a big fan of the F# language and concepts since version 2. I've written custom lexers/parsers and language designs with it. I've also found it powerful for high-speed file stream processing.
BUT I am here to play devils advocate today, because I can't really see much value in employing F# for common enterprise scenarios. Xamarin/MBrace I don't know much about so I wont speak about it. Suave syntax and distribution of logic makes it unwieldy for enterprise web services. Maybe this will be improved in a future version but I would only employ it in a microservice architecture. WebSharper hides javascript under F#. I learned a painful/valuable less on macro-javascript languages when using coffeescript: if youre developing javascript, write it in javascript or use a react container. When your application breaks, the errors will be in javascript and the debugging will happen in javascript, the inability to trace this back to F# brings pain.
ASP.NET: Granted F# is generally easier to develop with than C#, the tooling for C# in ASP.NET makes it a far better choice. the scaffolding, entity framework/linq and razor make the most common requirements much easier. Every time I take another look at NHibernate/razor/scaffolding support in ASP.NET for F# it seems it is a path far less traveled and less community/support/documentation out there.
Of course I'm not making the argument that these tools aren't useful in specialty scenarios but for those of us that know BOTH F# and C# (and generally lead teams who know C#) there isn't enough ammunition to justify departing from the plain old tool sets that have been the standard for years. Inertia in the enterprise realm is great, and C# continues to improve so I don't see this changing in the near future.
Hey, Pete. Thanks for sharing your experiences with Suave. May I ask if you can expand a bit more on the issues you noticed with it?
Fair question. My answer is based on my background/experience with ServiceStack. Comparatively speaking, coming from ServiceStack I would say suave.io is faster to get something up and running but ServiceStack conventions force you into an important practice of clearly separating the request/response data structures, logic, and http/REST stuff (urls/actions etc). Such practices are crucial for any service design in the mid to long run so it is worth the extra time investment to follow the conventions and do it up front. Whether you choose to write it in F# or C# the arrangement of logic in the framework remains consistent. Suave.io is perfect for lighter interactions but these two points are what I see. Of course someone better versed in Suave may have good responses for my points but this is a beginner's reaction.
Hey, Pete. Thanks for sharing your experiences with Suave. May I ask if you can expand a bit more on the issues you noticed with it?
Fair question. My answer is based on my background/experience with ServiceStack. Comparatively speaking, coming from ServiceStack I would say suave.io is faster to get something up and running but ServiceStack conventions force you into an important practice of clearly separating the request/response data structures, logic, and http/REST stuff (urls/actions etc). Such practices are crucial for any service design in the mid to long run so it is worth the extra time investment to follow the conventions and do it up front. Whether you choose to write it in F# or C# the arrangement of logic in the framework remains consistent. Suave.io is perfect for lighter interactions but these two points are what I see. Of course someone better versed in Suave may have good responses for my points but this is a beginner's reaction.