Comment by pjmlp | Hacker News Reader

Comment by pjmlp | Hacker News Reader

Parent Full thread

As someone that likes F# and seldom uses, the fact it is a third class citizen on .NET tooling makes it hard to justify its adoption in many .NET projects.

If you want to be sure regardless of solutions vendors or framework, there is always tooling available, including Visual Studio plugins, then only C# offers that.

VB comes second after that, due its history on Microsoft tooling, and by being developed alongside in the same Roslyn infrastructure.

C++/CLI gets all the low level goodies, however since it is Windows only and probably due to Midori and Singularity efforts, C# is increasingly getting the same capabilities.

Then at the end comes F#, mostly developed outside of Microsoft, with its own frameworks, doesn't support all .NET features because F# knows better (e.g. protected members) and its advocates don't get enterprise, for example, I don't want to see yet another example of using type providers with World database, show me how to use EF with WPF, Sitecore renderings, SharePoint WebParts, WinUI, ...

The most recent strategy is to try to go after Python and Julia, which I wish them all the luck, but I am not convinced it will work out.

I don't think the risk is that bad. Especially if you are using .NET Core as a cross platform target most of the tooling is made for Windows anyway so is mostly unaccessible. VS Code for example works reasonably as good as any other VS extension - in my experience works better than the Java one. For a functional language it has a pretty good tooling story.

For the standard Docker microservice (e.g. ASP.NET Core, GRPC, etc stack) the tooling is more than adequate.

F# is mostly a superset of C# features these days with a much smaller lag in gaps than the other way around. On the protected members it isn't the biggest issue either - you can still override the method in your app code but it just changes it to public instead for the derived class. For interoperability to override C# classes it works and you wouldn't normally notice any difference; and in F# code you tend not to use the pattern anyway preferring composition to large object hierarchies. So your not blocked from overriding protected members on derived classes if you need to get a method overriden in a 3rd party C# library.

You may be giving the impression that there is missing capability from F# that will cause risk and block your project. Given I've used it professionally I don't think that's actually the case - it won't block you from developing anything that you couldn't do in C#. At worse case - if you actually want to use the really edge case C# features you can always create another project just for that bit of code and call it from F# code given the good interoperability. There's usually ways around this too.

Try to design a WPF/WinUI application in F#, including making use of the designers, Blend and EF.

Some product vendors will decline support if you use F# instead of C# or VB.

You will get told to reproduce the problem in C# or VB, otherwise the ticket gets closed.

Sure - those applications generate C# code in the background so that's that. Its not that F# couldn't do it, but the no language that's coded by a human competes with auto-generated tooling backend (XAML to C# form code). XAML and the widgets behind them are not designed with a code first flow in mind - so when they generate 100's LOC of C# spaghetti I don't expect to code that by hand in any lang. In that case I would choose C#, or more to the point, the Designer and whatever language it generates - the language is secondary.

Those apps you list are also not cross platform as I mentioned in my comment. They are also not the apps you typically code in Ocaml either which is where the comparison/comment was coming from I feel. For cross platform development and some of the software typical when comparing F# to Ocaml, F# IMO is perfectly fine and on par with C# (sometimes better depending on the problem space).

For vendor specific issues F# ports pretty well to C#. For the very odd time you've proven a bug in F# its pretty easy to whip up a quick C# project to give to one of those "vendors" (half an hour/1 hr maybe to build a repro you would need to do anyway). To be honest most of the time they don't help you with C# either - support sadly in my experience is only on paper and never covers you fast enough when you need it. It's just a tick in the box that you have the risk covered should you ever need to resort to this; which many projects never do.

I get your point for some applications, and if you are doing those kinds of apps fair enough. Use the right tool for the job. But I personally think for languages in the JVM/.NET camp the risks of project failure are overblown and aren't as big as people make them out to be especially if they are pragmatic rather than academic and/or syntax heavy. Given they can piggy back on the bigger ecosystem to avoid getting stuck for edge cases.

Reply on news.ycombinator.com