9 ms·

OCaml type system is more powerful than F#. OCaml lacks operator overload, computation expressions (unless you use an extension?) and threading (coming soon?).

OCaml type system is more powerful than F#. OCaml lacks operator overload, computation expressions (unless you use an extension?) and threading (coming soon?). The community is tiny for OCaml. F# is small too but it can access all of .Net easily and there are some good IDE options. F# is backed by Microsoft. F# is low risk to adopt compared to OCaml. F# is the functional language pick that won’t get you fired.

aloisdg 6y ago
And if you already are a .net shop, adding some F# code in a dependence is really smooth.
- louthy 6y ago
  That is until Microsoft release a version of the Framework or a version of VS that breaks F# in your project. I dropped F# support from my one of open-source projects because of this, and at my company we've decided to stop all future F# development. The move to .NET Core was an absolute clusterfuck for F# ... well, it was for C# too, but everything broke in the F# world ... I even ended up on a Skype call with the PM of the F# team as he tried to help resolve my issues; it's amazing he was willing to help, but it was kind of indicative of a bigger issue (I believe). The tooling is poor in general, the interop is questionable at best. One example is `Option a` in F# becomes `FSharpOption<A>` in C#, with `None` being `null` - breaking all of the type-safety of the union-type. It isn't seamless in the way some might have you believe. The standard answer is build a wrapper to expose F# to C#, which is ok, but is an extra level of indirection and complexity that shouldn't be needed (if indeed the idea is to have seamless interop). I developed language-ext [1] to bridge the divide, but in the end there isn't a strong enough reason to write F# all the time in the .NET sphere. It is compromised by an ecosystem where C# is dominant. That includes the framework libraries and even the limitations of the type-system in F# (no higher kinds for example). There's no real reason for F#, other than a nicer syntax, it doesn't have a killer USP like Haskell (purity) or Erlang (concurrency). If it wasn't in C#'s shadow, and it was able to run free, and without compromise, there could be a compelling narrative - but what we're doing now is moving to PureScript for our front-end, and Haskell for microservices where we need the USP of Haskell (purity and strict domain modelling). [1] https://github.com/louthy/language-ext/ https://github.com/louthy/language-ext/
  - jiggawatts 6y ago
    The move to .NET Core broke everything. PowerShell is still broken, with fundamental issues that may remain unresolved for a long time. I don't expect most people to switch over until PS v9.0 at the earliest.
    - lc9er 6y ago
      What part of Powershell is broken? Are you referring to module compatibility or other issues? For my shop, the AD module was an obstacle until v7. Many Azure-related modules still seem to be 5.1 only.
      - jiggawatts 6y ago
        The module compatibility thing isn't just developers being lazy and not porting over their modules, it's actually a fundamental thing to do with the way .NET Core was architected. Because -- you know -- in the 2020s there are only web apps and mobile apps. There are no other types of "applications". That unnecessarily long word only exists in dead tree dictionaries like Oxford, and is used by old people that still cling to their "personal computers" of yesteryear. So of course, .NET Core was made only for web apps, with a hint that mobile apps might one day work also. Microsoft will say otherwise, of course, but in practice 100% of the decisions were to ship an MVP that can be used to create a web application. All the doco was for web apps. All of the samples were for web apps. Whenever there was a decision to be made, they made it with web apps in mind. This has made some things impossible, especially related to actually loading dynamic link libraries (DLLs) dynamically, which despite the "dynamic" in the name is surprisingly problematic in .NET Core. It really wants you to ship a monolithic, statically linked app. Anything else is just a nightmare of compatibility shims and flags that ought to be at the DLL level but are actually set (once only) at the EXE-level. This makes PowerShell Core modules very sensitive to the exact version of .NET Core used to compile PowerShell itself, contrary to how the old PowerShell used to work, where you could upgrade the system framework to enable the loading of a newer module built against that framework. Similarly, if there is another module that pulls in something with compatibility shims (or not), then that can break your module in weird and wonderful ways. I tried to write a .NET Core module for PowerShell core several times, and every time I got bogged down in reams of inscrutable internal framework errors that had 2-3 hits maximum in Google, all from other people complaining about PowerShell development having being broken.
- pjmlp 6y ago
  Not if you are doing UWP, where F# support is an hack and it won't be ever supported officially (there is a github issue about it). However given the whole Project Reunion and uncertainity how both worlds are supposed to be merged, maybe it isn't such a big deal. Ah and don't expect Code Generators to ever support F#.
  - dpwm 6y ago
    > Ah and don't expect Code Generators to ever support F#. What sort of Code Generators are we talking? I ask because I have a very early alpha project that does F# code generation using Fantomas. Apart from an (uninvestigated) slightly higher startup time than I hoped for, it seems fine.
    - pjmlp 6y ago
      The ones in .NET 5 and .NET 6, integrated into Roslyn and a key part of the upcoming AOT support. https://devblogs.microsoft.com/dotnet/introducing-c-source-generators/ https://devblogs.microsoft.com/dotnet/introducing-c-source-g... The main goal is for them to be the .NET version of Java's annotation processors and thus allow many libraries to replace their reflection code with compile time code generation.
      - dpwm 6y ago
        Oh wow, thanks for that. I’m new to .NET and didn’t know anything about Source Generators. That seems to be a pretty interesting feature. I followed the link to the F# suggestions and found https://github.com/fsharp/fslang-suggestions/issues/864 https://github.com/fsharp/fslang-suggestions/issues/864 It seems like there is interest but with a "let’s wait and see what happens with C#" kind of approach. I’ll admit it looks far off, but there appears to be interest. I’m certainly not expecting them, and for my purposes F# provides more than enough anyway. I am nonetheless interested: why do you think they will never come to F#?
        pjmlp 6y ago
        Because Roslyn compiiler stack is only for C# and VB, F# has its own infrastructure. Until now, all the F# related tooling tends to be done by a mix of the tiny MS team and FOSS community, it is not the full steam rolling engine that C# and VB get.
Kuinox 6y ago
OCaml is maintened by the INRIA and is widely used in french academics. In the long term there is far less chance that the INRIA drop OCaml than microsoft drop F#.
- deleted 6y ago
  [deleted]
gameswithgo 6y ago
>OCaml type system is more powerful than F# In some ways, on the other hand F# has active patterns and type providers, which are quite magical.

aloisdg 6y ago

And if you already are a .net shop, adding some F# code in a dependence is really smooth.

louthy 6y ago
That is until Microsoft release a version of the Framework or a version of VS that breaks F# in your project. I dropped F# support from my one of open-source projects because of this, and at my company we've decided to stop all future F# development. The move to .NET Core was an absolute clusterfuck for F# ... well, it was for C# too, but everything broke in the F# world ... I even ended up on a Skype call with the PM of the F# team as he tried to help resolve my issues; it's amazing he was willing to help, but it was kind of indicative of a bigger issue (I believe). The tooling is poor in general, the interop is questionable at best. One example is `Option a` in F# becomes `FSharpOption<A>` in C#, with `None` being `null` - breaking all of the type-safety of the union-type. It isn't seamless in the way some might have you believe. The standard answer is build a wrapper to expose F# to C#, which is ok, but is an extra level of indirection and complexity that shouldn't be needed (if indeed the idea is to have seamless interop). I developed language-ext [1] to bridge the divide, but in the end there isn't a strong enough reason to write F# all the time in the .NET sphere. It is compromised by an ecosystem where C# is dominant. That includes the framework libraries and even the limitations of the type-system in F# (no higher kinds for example). There's no real reason for F#, other than a nicer syntax, it doesn't have a killer USP like Haskell (purity) or Erlang (concurrency). If it wasn't in C#'s shadow, and it was able to run free, and without compromise, there could be a compelling narrative - but what we're doing now is moving to PureScript for our front-end, and Haskell for microservices where we need the USP of Haskell (purity and strict domain modelling). [1] https://github.com/louthy/language-ext/ https://github.com/louthy/language-ext/
- jiggawatts 6y ago
  The move to .NET Core broke everything. PowerShell is still broken, with fundamental issues that may remain unresolved for a long time. I don't expect most people to switch over until PS v9.0 at the earliest.
  - lc9er 6y ago
    What part of Powershell is broken? Are you referring to module compatibility or other issues? For my shop, the AD module was an obstacle until v7. Many Azure-related modules still seem to be 5.1 only.
    - jiggawatts 6y ago
      The module compatibility thing isn't just developers being lazy and not porting over their modules, it's actually a fundamental thing to do with the way .NET Core was architected. Because -- you know -- in the 2020s there are only web apps and mobile apps. There are no other types of "applications". That unnecessarily long word only exists in dead tree dictionaries like Oxford, and is used by old people that still cling to their "personal computers" of yesteryear. So of course, .NET Core was made only for web apps, with a hint that mobile apps might one day work also. Microsoft will say otherwise, of course, but in practice 100% of the decisions were to ship an MVP that can be used to create a web application. All the doco was for web apps. All of the samples were for web apps. Whenever there was a decision to be made, they made it with web apps in mind. This has made some things impossible, especially related to actually loading dynamic link libraries (DLLs) dynamically, which despite the "dynamic" in the name is surprisingly problematic in .NET Core. It really wants you to ship a monolithic, statically linked app. Anything else is just a nightmare of compatibility shims and flags that ought to be at the DLL level but are actually set (once only) at the EXE-level. This makes PowerShell Core modules very sensitive to the exact version of .NET Core used to compile PowerShell itself, contrary to how the old PowerShell used to work, where you could upgrade the system framework to enable the loading of a newer module built against that framework. Similarly, if there is another module that pulls in something with compatibility shims (or not), then that can break your module in weird and wonderful ways. I tried to write a .NET Core module for PowerShell core several times, and every time I got bogged down in reams of inscrutable internal framework errors that had 2-3 hits maximum in Google, all from other people complaining about PowerShell development having being broken.
pjmlp 6y ago
Not if you are doing UWP, where F# support is an hack and it won't be ever supported officially (there is a github issue about it). However given the whole Project Reunion and uncertainity how both worlds are supposed to be merged, maybe it isn't such a big deal. Ah and don't expect Code Generators to ever support F#.
- dpwm 6y ago
  > Ah and don't expect Code Generators to ever support F#. What sort of Code Generators are we talking? I ask because I have a very early alpha project that does F# code generation using Fantomas. Apart from an (uninvestigated) slightly higher startup time than I hoped for, it seems fine.
  - pjmlp 6y ago
    The ones in .NET 5 and .NET 6, integrated into Roslyn and a key part of the upcoming AOT support. https://devblogs.microsoft.com/dotnet/introducing-c-source-generators/ https://devblogs.microsoft.com/dotnet/introducing-c-source-g... The main goal is for them to be the .NET version of Java's annotation processors and thus allow many libraries to replace their reflection code with compile time code generation.
    - dpwm 6y ago
      Oh wow, thanks for that. I’m new to .NET and didn’t know anything about Source Generators. That seems to be a pretty interesting feature. I followed the link to the F# suggestions and found https://github.com/fsharp/fslang-suggestions/issues/864 https://github.com/fsharp/fslang-suggestions/issues/864 It seems like there is interest but with a "let’s wait and see what happens with C#" kind of approach. I’ll admit it looks far off, but there appears to be interest. I’m certainly not expecting them, and for my purposes F# provides more than enough anyway. I am nonetheless interested: why do you think they will never come to F#?
      - pjmlp 6y ago
        Because Roslyn compiiler stack is only for C# and VB, F# has its own infrastructure. Until now, all the F# related tooling tends to be done by a mix of the tiny MS team and FOSS community, it is not the full steam rolling engine that C# and VB get.

Kuinox 6y ago

OCaml is maintened by the INRIA and is widely used in french academics. In the long term there is far less chance that the INRIA drop OCaml than microsoft drop F#.

deleted 6y ago
[deleted]

gameswithgo 6y ago

>OCaml type system is more powerful than F# In some ways, on the other hand F# has active patterns and type providers, which are quite magical.