[TensorMetric]

I've been holding of targeting UWP, until proper F# support.

I have experience with plenty of languages and technologies, including C, C++, Rust, Scala, OCaml, Haskell, Clojure, Elm, Idris, WinForms, WPF, DirectX and dabbled with Silverlight. Migrating from WPF or Silverlight towards UWP shouldn't be a problem.

F# has been my favorite language since 2008, but the hostile anti-UWP, anti-Windows community, compounded with the lack of abstraction features such as ML functors, higher-kinded types, type-classes and terrible modern Windows client support, are driving me away from it.

UWP is pretty mature now and all modern default 1st party Windows apps and critical UI components such as start menu, action center and settings rely on it, and more is being migrated towards it all the time, there is no sign of UWP going away anytime soon.

[edgyswingset]

> there is no sign of UWP going away anytime soon

Except for Windows Phone getting killed, which was the _main_ device type for UWP. The Windows app store is the same graveyard that it was in late 2015 when the announcements around new Windows Phones piqued my curiosity. It looks like that's simply not a thing anymore. I'm betting my money on Xamarin and the browser for a client application, not UWP. There's just no point to it.

[pjmlp]

UWP is the future of Windows APIs, in case you missed Windows Developer day earlier this month.

So if F# doesn't speak UWP, the community keeps tweeting that GNU/Linux is so much better than Windows, and that we enterprise devs just don't get it, should we bet which of those technologies will last longer on MS roadmap?

[edgyswingset]

My F# code runs on Linux. My client code is migrating to the web and mobile, as is just about every enterprise in the US. Why would I watch Windows developer day?

[pjmlp]

Because Microsoft is the one paying the salaries of F# developer team.

The F# comunity has become quite strange, always bashing the products of the company that actually develops their programming language.

Not a good way to keep them motivated into supporting F#.

[enricosada]

There are lot of scenario where F# can be used.

In some scenario support is more stable, other experimental, other are not supported. like every technology.

Because budget is not infinite, you need to prioritize.

Just to show you things happened MS tech related to F# and .NET in the last two years:

- .net core

- .net standard (is not the same as .net core)

- new project system for VS

- new .net sdk (that mean work to support these on VS)

- portable pdb

- F# 4.1

- temporary stuff like project.json, who added work and was replaced

- new .net templating

- F# in VS now use roslyn workspaces (yes, that's big)

- integration of VisualF# powertools in default VS extension

- f# bundled in .net sdk and compiler in .net core sdk

- F# on azure notebooks

- F# on azure functions

- VS 2017

- VS 2017 installer (yes, that was annoying)

And that list is just some of MS technologies, who VF# team need to support/adapt too.

NOTE the list doesnt contains things created from community itself, like Fable. and some of these were added by community

Yes, and there is too:

- UWP

- .NET Native

- Corert

but you need to prioritize and choose your (moving) targets.

So ihmo while UWP can be nice to have (ihmo), was put in a lower priority than the others.

When you choose there are lot of factors:

- time to implement

- unknown

- other things open in parallel scenarios

- support needed to complete/make it usable

Community help a lot the F# development, and also a lot the VS VF# extension, see the repo. Because F# has lot of OSS in the dna.

But that doesnt mean we cannot complain when things need improvements, in some important scenario.

And as a note, the MS VF# project manager was awarded the `F# community Hero award`, that mean the community like and support his work (the award is indipendent and run from community voting)

[pjmlp]

We don't do Azure and .NET Core is meaningless for us, as it doesn't have GUI support and EF Core is a tiny subset of EF 6.

As consulting company we are not bound to a single language or platform. When we do UNIX projects we use programming languages that are better fit for such platforms, and that isn't .NET Core.

For us .NET only matters for Windows related development, and there F# keeps being the black swan since its early days.

No tooling support for Windows Forms, XAML, Blend, ASP.NET, EF, WCF and now not even .NET Native, because for some strange political reason F# is separated from the .NET development group, and never considered on the decisions of the .NET platform as such.

With C# and VB.NET our customers on Microsoft solutions can be 100% sure their code is safe regardless of what Microsoft thinks to do next, at maximum they would need to re-write parts of it.

[TensorMetric]

To me and many early investors of F# (loyal Windows developers), the current direction is the worst thing that happened to the language.

UWP is not just a nice to have, it's the backbone of client Windows development right now and going forward.

I used to be a huge F# advocate and all the people I converted to F# over the years have left, due to the lacking Windows support. And the VF# program manager siding with anti-UWP, anti-Windows, anti-MS detractors isn't helping the situation.

[TensorMetric]

The main device type for UWP is any Windows 10 device. See the list of benefits mentioned in the link above, which extend beyond phones. I've never owned a Windows Phone, yet I always prefer UWP apps.

Also there is a big market for 2-in-1 tablets, and new small Windows on ARM devices are coming out very soon.

http://www.zdnet.com/article/microsoft-to-pc-makers-lets-mak...

Not every kind of client app is suitable for the browser, especially if you care about performance and deep native platform integration. And I'd rather not deal with JS frameworks when not targeting the web.