Build a web service with F# and .NET Core 2.0
blogs.msdn.microsoft.com
blogs.msdn.microsoft.com
Hopefully F# will become even more mainstream than it is right now.
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
Look at it from this perspective: you might be able to hire the next person because you put some proper tools/stack for them to work with. :)
Impossible. F# (a.k.a. OCaml.NET) is --like OCaml-- a general purpose language. It's on Wikipedia so must be true :)
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.]
Functional-style languages seem to have difficulty becoming mainstream.
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.
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.
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?
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..
It is my belief that time is on F#'s side.
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.
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.
.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.
- 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.
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.
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.
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.
Pick any of the following Dockerfiles: https://hub.docker.com/_/mono/