Except for the people using Windows 10, developing with HoloLens, gaming on XBox ONE (after the latest firmware updates), or using Surface meeting boards.
We can forget about UWP support, it isn't going to happen in the near future, who knows if it ever will.
"The F# team is currently focused on .NET Core tooling in Visual Studio and further support for .NET Core as it evolves. There is no ETA for .NET Native/UWP support at this time."
With UWP, Visual C++ kind of finally caught up with C++ Builder, it even has support from Blend for UI design.
MFC is mostly on maintenance and new application should use XAML + C++/CX.
C++/CX makes use of the C++/CLI extensions but it targets AOT compilation to native code instead.
The alternatives are C++ with WRL (Windows Runtime Library), basically ATL replacement, and what most Microsoft teams actually use for the UWP kernel components.
Because most C++ devs would rather use something more standards friendly, there is work in progress to eventually replace C++/CX with C++/WinRT, taking advantage of C++17 features.
Not much, throughout my career I have learned that the best path is always to only use the officially supported SDK languages for production code.
All productivity or enjoyment using alternative languages gets lost in extra FFI layer, unavailable platform documentation, lack of support on the IDEs, poorer debugging, GUI tooling and code generation.
So I only use alternative languages to learn about new concepts and ways to improve my skillset, but in what concerns production code, the golden rule is 100% SDK languages.
Going back to your question, Java on UWP is only possible via the JVM provided by CodenameOne and I think it actually makes use of the Desktop Bridge, so that rules out Scala.
Rust still has a lot to catch up with C++ for using COM in a productive way, let alone .NET based languages.
UWP is basically what .NET should have been, if they had kept the original COM+ plans instead of going with the CLR. So any language targeting UWP needs to have seamless COM support, and ability to handle .NET metadata.
Microsoft had to fix the C# compiler. The result was Roslyn. It's actually amazing that Roslyn was a successful project. Probably most software projects that ambitious fail. The project would have failed if they tried to make it F# compliant at the same time.
Speaking as someone who makes his living writing F# code, I'm as frustrated as anyone about this, but there will be a successful resolution. I just don't know how soon. Before today's announcements my personal thinking was that it would be this autumn. That's still possible. In the meantime I can still function in the F# world, as before. It just remains frustrating to branch out into some of the areas I would like to.
You're absolutely correct about .NET native not being .NET compliant...sigh...there are just higher priorities for such a big company. As quoted in the comments " [F# native support] depends on the Core CLR team improving support for a couple of big items. dotnet native is and AOT compilation are absolutely a goal for us ... they just are longer term than this roadmap anticipates."
It's actually eye-opening how few the number of people at MS who actually write code is. I suppose if there were more coders they would be stepping all over each other and never get anything done.
Wait what? That's totally astonishing - I thought the entire point of .NET and the CLR was to be a language-agnostic runtime. Why can't you build UWP apps with it? How do they even know?
There is no CLR on UWP, everything is AOT compiled to native code, excluding JavaScript.
VB and C# make use of .NET Native and C++/CX are just a few C++ extensions that look like C++/CLI but compile to native code as always. One can also use standard C++ with WRL or C++/WinRT libraries.
.NET Native shares the compiler backend with Visual C++.
The issue is that the .NET Native compiler team doesn't care about supporting the IL required by F#.
I once had to really compile one of my UWP apps to get it working on a locked down Surface Hub (otherwise, I just ever ran them in the debugger). My freaking god, it took 45 minutes to compile a small app...no way...they threw out everything that was good about the CLR for AOT that allowed them to what...run on embedded devices?
Windows 8 was also AOT compiled to native code, but using the old Bartok toolchain from Singularity(MDIL).
UWP is what Longhorn should have been in first place, if WinDev and DevTools actually worked together.
COM based OS ABI fully native, to the point only VB and C# are used in most Windows talks, even for the new UI composition engine.
C++ is still there for the kernel, device drivers, audio and graphical critical performance components like DirectX.
Everything else can enjoy the productivity of .NET languages and respective tooling.
Which meant that any of my WP 8.x and 10 devices run considerably faster than Android devices of similar price range, while having less overall memory requirements.
I get it: a UWP app might be noticeably faster with AOT vs. the standard CLR JIT, but for a UI program that isn't crunching numbers, you are unlikely to tell the difference. Also, the CLR, like the JVM, is no slouch when it comes to running things. As such, there is always a huge asterisk attached to AOT claiming it might improve performance, but it could also degrade it, it is hardly an obvious win. The way it was explained to me was that AOT is necessary for UWP to support IoT and lower end hardware, that on full computers you probably won't notice.
Also, look at all we gave up for AOT. Dynamic compilation in the DLR was pretty nice...and it was reduced to an interpreter in UWP because....no JIT. Granted, I was probably the only person to notice because no one else probably thought to cross the two.
The problem with Microsoft is that as soon as they move to the next thing, they basically abondon the previous one without having the next thing truly replace the previous one. So here comes UWP, meant for "different" things, but it gets all the new stuff while WPF is basically dead. Ya, want to use those new APIs? Sorry, you'll need to use UWP even if you have no intention of running on low end android devices.
So much good stuff, but you have to make a Faustian bargain to use them.
Two years after UWP was introduced still no roadmap in sight for .NET Native support, Visual Studio 15.3 just shipped with the F# team telling people to use VS Code instead.
I bet it will be joining Silverlight in a couple of years.
However Microsoft is not alone in these kind of decisions. I can think of a few similar ones from Apple, Google, IBM, HP, Oracle, Sun,....
Ya, I wouldn't single out MS as particularly bad here, but they used to be much better about this than the other companies. Now they are reaching down to parity, and developer support used to be their greatest strength.
It's because Microsoft's main client application platform's .NET runtime is not .NET compliant, resulting in their own language, F#, not be supported. See here https://news.ycombinator.com/item?id=15007166
They act as if C# is the only .NET language and nothing will change if we don't speak up about it.
> There is no timeline for F# support on UWP. If you must use UWP for your workplace, then F# is not an option for you. We make no such claim that you can do this, though. If there is such a statement somewhere, please do let me know. I do not wish to mislead anyone.
>This is an interesting point:
>> Full tooling support, every single feature as VB.NET and C# have on Visual Studio.
> Is it your expectation that every programming language be supported across everything you can use in Visual Studio?
>> As for .NET Core, most of us on the enterprise hardly care about .NET Core beyond UWP, until it gets feature parity with .NET Framework.
> I will challenge this position. Perhaps you’ve not seen .NET Core in your organization, but we’ve seen strong adoption and significant interest in the enterprise for .NET Core. And this also goes beyond Visual Studio tooling. Many enterprises have developer who wish to program on macOS and deploy to Linux machines. We’ve made that a priority for .NET Core, and F# is every bit as capable as C# on that front. This has also been a significant area of growth for C#, F#, and .NET as a whole.
> @KevinRansom My impression was that F# libraries would likely work immediately in UWP (not coreclr native code gen) if tail. was ignored. I think it's up to the UWP team though, not the Visual F# Tools team. It's not a compiler problem, it's a runtime problem.
> To be honest, it appears UWP is simply not implementing the .NET specs correctly - tail. has been in all editions of the ECMA 335 CLI Standard... Mind you, generics have also been in that standard, with no mention of "limits of 7 deep" or anything like that. I'm always somewhat surprised when I see adhoc limitations that incorrectly implement the ECMA standard - I really thought that was a standard which mattered.
Come on Microsoft, this is unacceptable, you're driving existing and potential valuable programmers away from your platform and F#.
> I found this thread tonight while looking for information about how to build a UWP application using F# in Visual Studio Community 2017. I kept seeing lots of references to C# .NET and VB.NET for this purpose, but suspiciously F# was missing. Which made me curious:
>> ... CAN you build a Universal Windows Platform native application with F#?
> And then I found this thread. I now regret investing any time in examining F# as a future development platform for any purpose. I'll probably never pay attention to it again, and I worry about the sincerity of any of Microsoft's future developer endeavors.
F# is a mature fully .NET compliant Microsoft language, it should be expected and a high priority to get the .NET Native UWP (your main client application platform) to accept F# code.
Most people I know invested in F# with the expectation to target modern Windows without fuss and workarounds. And no, UWP Bridge and Fable + React Native are not acceptable solutions.
