"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."
-- Phillip Carter [MSFT]
https://blogs.msdn.microsoft.com/dotnet/2017/08/14/f-and-net...
Better focus on C# and C++ and call it a day.
And I don't like going back to C++, is there any GUI/XAML tooling for it? If not, I'd rather use something like Rust.
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.
https://docs.microsoft.com/en-us/cpp/windows/universal-windo...
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.
“Embracing Standard C++ for the Windows Runtime"
https://www.youtube.com/watch?v=lm4IwfiJ3EU
“Putting Coroutines to Work with the Windows Runtime"
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.