5 ms·

F# is your strongly typed contender to Python.

nextos 6y ago
Sure, it's a lovely language. But I find the lack of some basic linear algebra, probability and statistics libraries frustrating. As pjmlp said in a parent thread, those are closed source and usually bought. I guess a lot of the .NET ecosystem is like that. It's a shame, because MS has some open-source jewels like Z3 or Infer.NET.
- KurtMueller 6y ago
  Hopefully F# gets big enough that people will write those libraries - I think people deserve a better Python.
- mdm12 6y ago
  MS is making a conscious effort to push into the ML space with libraries such as ML.NET https://dotnet.microsoft.com/apps/machinelearning-ai/ml-dotnet https://dotnet.microsoft.com/apps/machinelearning-ai/ml-dotn... . IMO, the combination of a strongly-typed language with features such as type inference, data providers and discriminated unions/pattern matching make F# a perfect fit for this space. It's just unfortunate that they had to go through the .NET Framework -> .NET Core journey before focusing on the ML ecosystem... But, the F# PM has recently given talks recognizing that they want to go into the space that Python is dominating, so it's a clear goal of the F# team (https://www.youtube.com/watch?v=_QnbV6CAWXc https://www.youtube.com/watch?v=_QnbV6CAWXc). I hope they're successful!
  - pjmlp 6y ago
    On the other hand, they just hired Guido, have first class support for Python across VS and VSCode, and are in the process of creating a Python projection for UWP (which still doesn't support F#). From the outside it always looks like an uphill battle for F#. It would be great if F# finally gets its place across the .NET stack.
    - nbevans 6y ago
      Odd. I've been using F# for a UWP app since 2018.
      - pjmlp 6y ago
        Odd indeed, given that .NET Native doesn't support it without a couple of hacks. https://github.com/dotnet/corert/issues/5780 https://github.com/dotnet/corert/issues/5780 https://github.com/dotnet/fsharp/issues/1096 https://github.com/dotnet/fsharp/issues/1096
        nbevans 6y ago
        As per those links - the workarounds found in 2018 allow you to submit to Windows Store. But even still - my app is sideloaded and never needed to care about .NET Native at all.
        pjmlp 6y ago
        Workarounds are not official support and won't fly for many customers deciding what to place in production when picking technology stacks, so the choice ends up being C#, VB, C++, Rust, JavaScript and Python. The official set of programming languages getting UWP support as part of Project Reunion.
        nbevans 6y ago
        WinUI / Project Reunion is just a continuation of the UAP (Universal App Platform) libraries. The support for C# works for F# - just like basically any other C# library can be used from F#. I figure the reason they don't mention F# is because it is obvious and/or implied but perhaps at the same time don't want to infer there is some kind of F#/FP-style syntax. I wouldn't confuse Project Reunion and the arbitrary Windows Store requirement that apps be compiled with .NET Native. A requirement that, frankly, is on borrowed time anyway and I can't envisage it surviving much longer. Once .NET 6 delivers Mono-style AOT support - .NET Native's sole remaining purpose will cease to exist. Not that modern hardware ever needed it. It was intended for Windows Phones. If the choice facing us was a simple as you describe then, for example, we wouldn't have ended up building a UWP app in F# back in 2018, would we? Not everything is black and white nor zero sum.

Sure, it's a lovely language. But I find the lack of some basic linear algebra, probability and statistics libraries frustrating. As pjmlp said in a parent thread, those are closed source and usually bought. I guess a lot of the .NET ecosystem is like that. It's a shame, because MS has some open-source jewels like Z3 or Infer.NET.

KurtMueller 6y ago
Hopefully F# gets big enough that people will write those libraries - I think people deserve a better Python.
mdm12 6y ago
MS is making a conscious effort to push into the ML space with libraries such as ML.NET https://dotnet.microsoft.com/apps/machinelearning-ai/ml-dotnet https://dotnet.microsoft.com/apps/machinelearning-ai/ml-dotn... . IMO, the combination of a strongly-typed language with features such as type inference, data providers and discriminated unions/pattern matching make F# a perfect fit for this space. It's just unfortunate that they had to go through the .NET Framework -> .NET Core journey before focusing on the ML ecosystem... But, the F# PM has recently given talks recognizing that they want to go into the space that Python is dominating, so it's a clear goal of the F# team (https://www.youtube.com/watch?v=_QnbV6CAWXc https://www.youtube.com/watch?v=_QnbV6CAWXc). I hope they're successful!
- pjmlp 6y ago
  On the other hand, they just hired Guido, have first class support for Python across VS and VSCode, and are in the process of creating a Python projection for UWP (which still doesn't support F#). From the outside it always looks like an uphill battle for F#. It would be great if F# finally gets its place across the .NET stack.
  - nbevans 6y ago
    Odd. I've been using F# for a UWP app since 2018.
    - pjmlp 6y ago
      Odd indeed, given that .NET Native doesn't support it without a couple of hacks. https://github.com/dotnet/corert/issues/5780 https://github.com/dotnet/corert/issues/5780 https://github.com/dotnet/fsharp/issues/1096 https://github.com/dotnet/fsharp/issues/1096
      - nbevans 6y ago
        As per those links - the workarounds found in 2018 allow you to submit to Windows Store. But even still - my app is sideloaded and never needed to care about .NET Native at all.
        pjmlp 6y ago
        Workarounds are not official support and won't fly for many customers deciding what to place in production when picking technology stacks, so the choice ends up being C#, VB, C++, Rust, JavaScript and Python. The official set of programming languages getting UWP support as part of Project Reunion.
        nbevans 6y ago
        WinUI / Project Reunion is just a continuation of the UAP (Universal App Platform) libraries. The support for C# works for F# - just like basically any other C# library can be used from F#. I figure the reason they don't mention F# is because it is obvious and/or implied but perhaps at the same time don't want to infer there is some kind of F#/FP-style syntax. I wouldn't confuse Project Reunion and the arbitrary Windows Store requirement that apps be compiled with .NET Native. A requirement that, frankly, is on borrowed time anyway and I can't envisage it surviving much longer. Once .NET 6 delivers Mono-style AOT support - .NET Native's sole remaining purpose will cease to exist. Not that modern hardware ever needed it. It was intended for Windows Phones. If the choice facing us was a simple as you describe then, for example, we wouldn't have ended up building a UWP app in F# back in 2018, would we? Not everything is black and white nor zero sum.