6 ms·

OCaml would meet all the requirements. Any thoughts on it?

by ollran 5y ago

swuecho 5y ago
ocaml ecosystem is smaller than haskell. ocaml kind of meets the minimal requirement, but far away from production grade. in frontend, bucklescript changes too quickly. js of ocaml is hard to use. good luck if you want to trim the code size.
pjerem 5y ago
The most impressive feature of F# clearly is its tight integration to dotnet/C#. It’s super easy to mix C# and F# code in the same project and it works out of the box. This allows you, if you want it, to write your domain code in F# and your technical code in C#.
- LandR 5y ago
  Do you mean same solution? I didn't think you can mix languages over the same project in C# / F#
  - pjerem 5y ago
    Yes, same solution, my bad.
- pjmlp 5y ago
  Only on regular .NET, the UWP story is a bit different.
- tigershark 5y ago
  There are a lot of places where interop sucks. Other than the ones already mentioned by someone else in a previous comment there are the events that need a lot of ceremony in F# to be compatible with C#, lack of implicit conversion that in some cases renders some C# libraries unusable unless you define some explicit conversion operator and probably some other stuff that now I don’t remember. If you can work only in F# it’s a much better experience compared to mixing C# and F#.
pharmakom 5y ago
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 5y ago
  And if you already are a .net shop, adding some F# code in a dependence is really smooth.
  - louthy 5y 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/
auxym 5y ago
OCaml has subpar windows support. The native version is experimental, otherwise it's cygwin or WSL.
nestorD 5y ago
I personnaly went from Ocaml to F# because it had much better tooling (IDE support) and a larger libraries ecosystem (access to all .Net libraries).

OCaml would meet all the requirements. Any thoughts on it?

by ollran 5y ago

OCaml would meet all the requirements. Any thoughts on it?

ocaml ecosystem is smaller than haskell. ocaml kind of meets the minimal requirement, but far away from production grade. in frontend, bucklescript changes too quickly. js of ocaml is hard to use. good luck if you want to trim the code size.

pjerem 5y ago

The most impressive feature of F# clearly is its tight integration to dotnet/C#. It’s super easy to mix C# and F# code in the same project and it works out of the box. This allows you, if you want it, to write your domain code in F# and your technical code in C#.

LandR 5y ago
Do you mean same solution? I didn't think you can mix languages over the same project in C# / F#
- pjerem 5y ago
  Yes, same solution, my bad.
pjmlp 5y ago
Only on regular .NET, the UWP story is a bit different.
tigershark 5y ago
There are a lot of places where interop sucks. Other than the ones already mentioned by someone else in a previous comment there are the events that need a lot of ceremony in F# to be compatible with C#, lack of implicit conversion that in some cases renders some C# libraries unusable unless you define some explicit conversion operator and probably some other stuff that now I don’t remember. If you can work only in F# it’s a much better experience compared to mixing C# and F#.

pharmakom 5y ago

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 5y ago
And if you already are a .net shop, adding some F# code in a dependence is really smooth.
- louthy 5y 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/

auxym 5y ago

OCaml has subpar windows support. The native version is experimental, otherwise it's cygwin or WSL.

nestorD 5y ago

I personnaly went from Ocaml to F# because it had much better tooling (IDE support) and a larger libraries ecosystem (access to all .Net libraries).