3 ms·

If only Microsoft would let us build native UWP apps in F# without having to jump through hoops with web frameworks https://news.ycombinator.com/item?id=150071

If only Microsoft would let us build native UWP apps in F# without having to jump through hoops with web frameworks https://news.ycombinator.com/item?id=15007166 https://news.ycombinator.com/item?id=15007166

millstone 9y ago
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?
- bonoetmalo 9y ago
  I'm currently working through a CLR via C# book club at work, so I'm curious as well. I know you can make WPF apps in F#.
  - pjmlp 9y ago
    There is no CLR on UWP, see https://news.ycombinator.com/item?id=15015761 https://news.ycombinator.com/item?id=15015761
- pjmlp 9y ago
  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#.
  - seanmcdirmid 9y ago
    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? It's really too bad, Win2D was quite nice.
    - pjmlp 9y ago
      Performance. 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.
      - seanmcdirmid 9y ago
        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.
        pjmlp 9y ago
        Yeah F# is a good example. 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,....
- deleted 9y ago
  [deleted]

millstone 9y ago

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?

bonoetmalo 9y ago
I'm currently working through a CLR via C# book club at work, so I'm curious as well. I know you can make WPF apps in F#.
- pjmlp 9y ago
  There is no CLR on UWP, see https://news.ycombinator.com/item?id=15015761 https://news.ycombinator.com/item?id=15015761
pjmlp 9y ago
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#.
- seanmcdirmid 9y ago
  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? It's really too bad, Win2D was quite nice.
  - pjmlp 9y ago
    Performance. 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.
    - seanmcdirmid 9y ago
      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.
      - pjmlp 9y ago
        Yeah F# is a good example. 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,....
deleted 9y ago
[deleted]