3 ms·

F# still doesn't have UWP support nor is supported by .NET native compiler.

profquail 9y ago
That may well be true, but that’s irrelevant for many developers (e.g., me) writing things like data analysis tools and backend services in F#.
- bonesss 9y ago
  I'd go a step further: F# being slightly slow on the uptake of new shiney-shiney-shiney things from MS means you're less likely to hit solutions based on dead product lines and/or tech. A slight moderation in speed to avoid wasteful oscillations. I'm glad that the F# community uses its time making generalized cloud computing easier and more accessible and has smart data streaming solutions. I care 0% about windows platform apps, along with most of the world (given the sales and user stats). Not to mention: since you can always use C# and VB.Net as "glue code" with F# libraries behind that, you're generally only locked out of _pure_ F# solutions if you wanna play with the newest toys. It's bad for consultants who need 5 years experience in 3 day old tech to sell themselves. It's good business for companies trying to build value and not try to stick with technical fashion-trends for no reason.
bonesss 9y ago
F# does not need UWP support since MS have allowed ["desktop bridge" apps](https://github.com/Microsoft/visualfsharp/issues/1096 https://github.com/Microsoft/visualfsharp/issues/1096) (which may or may not signal the unofficial death of UWP...). The .NET native compiler has some issues with handling valid tail recursion MSIL commands IIRC - they're working on it. F# will always come in second in the MS tooling wars. Interesting, though, to follow the track record of MS techs that come in first in their tooling wars over the last decade... Maybe being a bit slow on the uptake of the "latest and greatest" EF, or Oslo models, or Silverlight, or WPF, or WCF, or dotnetcores new project format, or UWPs new APIs isn't the worst thing if you want your solutions to be supportable in production for a while.
- pjmlp 9y ago
  Microsoft is pretty explicit that it is a stop gap to port applications to UWP. That has been their main message in any presentation about the Desktop Bridge. Always showing how an existing application gets packaged, followed by replacing Win32 legacy features with modern UWP ones. The track record of other tech giants is not much different, let alone the usual reboots on GNU/Linux desktop stack.

That may well be true, but that’s irrelevant for many developers (e.g., me) writing things like data analysis tools and backend services in F#.

bonesss 9y ago
I'd go a step further: F# being slightly slow on the uptake of new shiney-shiney-shiney things from MS means you're less likely to hit solutions based on dead product lines and/or tech. A slight moderation in speed to avoid wasteful oscillations. I'm glad that the F# community uses its time making generalized cloud computing easier and more accessible and has smart data streaming solutions. I care 0% about windows platform apps, along with most of the world (given the sales and user stats). Not to mention: since you can always use C# and VB.Net as "glue code" with F# libraries behind that, you're generally only locked out of _pure_ F# solutions if you wanna play with the newest toys. It's bad for consultants who need 5 years experience in 3 day old tech to sell themselves. It's good business for companies trying to build value and not try to stick with technical fashion-trends for no reason.

bonesss 9y ago

F# does not need UWP support since MS have allowed ["desktop bridge" apps](https://github.com/Microsoft/visualfsharp/issues/1096 https://github.com/Microsoft/visualfsharp/issues/1096) (which may or may not signal the unofficial death of UWP...). The .NET native compiler has some issues with handling valid tail recursion MSIL commands IIRC - they're working on it. F# will always come in second in the MS tooling wars. Interesting, though, to follow the track record of MS techs that come in first in their tooling wars over the last decade... Maybe being a bit slow on the uptake of the "latest and greatest" EF, or Oslo models, or Silverlight, or WPF, or WCF, or dotnetcores new project format, or UWPs new APIs isn't the worst thing if you want your solutions to be supportable in production for a while.

pjmlp 9y ago
Microsoft is pretty explicit that it is a stop gap to port applications to UWP. That has been their main message in any presentation about the Desktop Bridge. Always showing how an existing application gets packaged, followed by replacing Win32 legacy features with modern UWP ones. The track record of other tech giants is not much different, let alone the usual reboots on GNU/Linux desktop stack.