5
points
TensorMetric
Joined 32 karma
- TensorMetric parenthttps://www.thurrott.com/cloud/office-365/161295/microsoft-r...
- They are actually using Typescript, and this will lead to less friction wrt hiring devs, supporting all those platforms and integrating web components. Still I would have hoped that MS would be a little more forward thinking, and put some of their MSR tech in good use, to encourage the use of better languages. Just like how Facebook is pushing ReasonML.
I think that the C# focus of .NET is a major mistake holding the platform back, especially when we have languages like F#, Scala, Swift, ReasonML and Rust these days.
- Not wrong, see the Windows 10 OneNote app for example, which already uses Typescript on WinRT/UWP. An Electron target will only be for legacy platforms, like Windows 7 and 8.
Also see https://www.thurrott.com/cloud/office-365/161295/microsoft-r...
- On Windows 10, they will target WinRT on UWP, with Fluent Design UI. Not Electron.
- > Why not C#?
See my comments here:
* https://www.reddit.com/r/programming/comments/8qqhlz/office_...
* https://www.reddit.com/r/programming/comments/8qqhlz/office_...
Also, they're actually using Typescript.
- 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.
- As was stated before, UWPs primary device type is every Windows 10 device.
https://np.reddit.com/r/Windows10/comments/75lgti/announcing...
You don't seem to understand what UWP is about.
- 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.
- 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.
- Nothing is being moved. UWP has been here since the dawn of Windows 10, which evolved from WinRT, going back to Windows 8, and is constantly being extended with new APIs.
- UWP is the primary Windows client application platform going forward.
https://np.reddit.com/r/csharp/comments/75mc1m/announcing_uw...
All this FUD and hostility from the F# community (including the Fable devs) towards UWP, or anything that's of interest to most Windows and C# developers making the switch, is why F# will never be popular.
And for most people who need to have their code running on anything else than Windows, F# and .NET wouldn't be their first choice anyway, given that there are plenty of better alternatives around, like Haskell, Scala, ReasonML, OCaml etc.
- That would require Microsoft, the F# team, and the vocal F# community members to actually want F# to be a proper first-class .NET citizen, which sadly isn't the case.
https://np.reddit.com/r/fsharp/comments/6tdrwq/after_so_many...
- This is minor compared to all the major things VS isn't shipping for many years in a row now.
- It's misleading to pretend that it's a substitute for full Visual Studio.
- It's only recommended temporarily, until the issues get ironed out. It doesn't make it THE first-class F# IDE.
- > You can gripe about your fav UI stack not being supported just the way you want (you don't seem to have any other complaints),
.NET Native and UWP are not just UI,
> but your claim the language is not improving is wrong.
You're confusing me with the parent commenter https://www.hackerneue.com/item?id=15029008
- I'm surprised that this comment isn't at the top of this thread.
- All those features mean nothing to seasoned .NET developers when you can't use the language natively on Microsofts primary application platform.
- Adoption of F# would not be a problem if it had .NET Native support and proper tooling
- The first-class IDE for F# is the full Visual Studio, not VS Code + Ionide.
- The real problem with F# is that the .NET Native UWP runtime isn't .NET compliant, therefore doesn't allow F# code.
See this link explaining the problem https://www.hackerneue.com/item?id=15026396
We wouldn't need to evangelize F#, if it just worked everywhere C# does with proper tooling support.
- The real problem with F# is that it isn't supported everywhere C# is https://www.hackerneue.com/item?id=15026396
- Thanks this is great information. Have you looked into using Scala or Rust for UWP apps?
- I really can't stand C#. F# is what drove me to .NET in the first place.
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.