4 ms·

What's your opinion on F# ? Does it share enough of OCaml goodness to be worth using in .Net world or instead of OCaml?

Yoric 7y ago
I never seriously used F#, so I can't tell for sure, but it looks pretty good!
Jorge1o1 7y ago
I’ve used F# and USING it feels very similar to OCaml in all of the important ways. The lightweight type structure where you can easily make Union types and the pattern matching are pretty much identical to how OCaml does it. Of course, the big difference is going to be in how easily you can interop with the .Net stuff in each language, obviously much easier in F#. This is great if you happen to have some kind of weird C# code that generates an IEnumerable, just pop that into F# and start working with it. For example, I have C# classes to read files to an IEnumerable of strings, you can just call List.ofSeq on it, and then start doing some really elegant things in F# with it. You can pattern match log files based on how the line starts and then run different functions whether it’s an error, info, debug, etc
gameswithgo 7y ago
F# is very much like a .NET port of OCaml. It is very nice to use and offers (usually) low effort interop with all of the worlds C# libraries. We use it in production at Olo, and I used it in production at my last company. Since learning F#, languages where if statements aren't expressions and that don't have option types feel broken to me =)
- polskibus 7y ago
  I can see that F# still does not support GADTs. Did you find it a serious limitation?
  - daxfohl 7y ago
    Depends on what you're trying to do. I've never found it to be a limitation but I don't do anything terribly intricate. Just web dev for work, and I wrote a toy language parser and type inferencer in it. There are maybe three lines of code that GADTs might have let me avoid casting in the type inferencer, but oh well. Different use cases that use GADTs to a greater extent, of course, you might miss them. What is your use case, and how much are you reliant on GADTs in your existing daily life?
  - amw-zero 7y ago
    You can go an entire lifetime without ever even knowing about GADTs. I don’t find their absence limiting at all.
nestorD 7y ago
Having used both for years, nowadays I would recommend using F#. The syntax is very similar but it solves many of Ocaml's pain points and you will get better tooling and more libraries thanks to .Net.
- polskibus 7y ago
  Could you elaborate on the pros of F# vs OCaml?
  - nestorD 7y ago
    In no particular order: - significant whitespace and no `let ... in` which makes for a more streamlined syntax - no +. vs + - a solid standard library - much improved tooling (see the ionide plugin for vscode) - you can use all the .Net libraries - multicore support - list comprehension and iterators - object support with a minimalistic syntax (I don't include type providers as I never had proper use cases for them) All of those either remove pain points (some of them arguably very small) or introduce improvements that are sensible in day to day life. With that and the fast that Ocaml and F# can (for the most part) easily be transpiled into one another, nowadays I see very little reason not to use F#. That being said, I find the fact that you basically never need explicit types in Ocaml very elegant (in F# the uniform syntax mean that you will need occasional types hints to disambiguate operations).
    - abhijat 7y ago
      How do you transpile f# to ocaml? Does this mean you can get a native self contained binary out of f# code, by first converting it to ocaml code?
      - yawaramin 7y ago
        You can't. See https://news.ycombinator.com/item?id=22394667 https://news.ycombinator.com/item?id=22394667
      - nestorD 7y ago
yawaramin 7y ago
If you are in the .NET world, then definitely prefer F# to C#. However be aware that it differs in some significant ways from OCaml. E.g., it does not have a separate module language (module types, functors, first-class modules). Its design is in a different, more object-oriented direction, with support for classes and interfaces. Basically, if you do use F#, be aware that it has its own idioms that you must learn; it's not a drop-in replacement for e.g. OCaml/Haskell/etc.

I never seriously used F#, so I can't tell for sure, but it looks pretty good!

I’ve used F# and USING it feels very similar to OCaml in all of the important ways. The lightweight type structure where you can easily make Union types and the pattern matching are pretty much identical to how OCaml does it. Of course, the big difference is going to be in how easily you can interop with the .Net stuff in each language, obviously much easier in F#. This is great if you happen to have some kind of weird C# code that generates an IEnumerable, just pop that into F# and start working with it. For example, I have C# classes to read files to an IEnumerable of strings, you can just call List.ofSeq on it, and then start doing some really elegant things in F# with it. You can pattern match log files based on how the line starts and then run different functions whether it’s an error, info, debug, etc

gameswithgo 7y ago

F# is very much like a .NET port of OCaml. It is very nice to use and offers (usually) low effort interop with all of the worlds C# libraries. We use it in production at Olo, and I used it in production at my last company. Since learning F#, languages where if statements aren't expressions and that don't have option types feel broken to me =)

polskibus 7y ago
I can see that F# still does not support GADTs. Did you find it a serious limitation?
- daxfohl 7y ago
  Depends on what you're trying to do. I've never found it to be a limitation but I don't do anything terribly intricate. Just web dev for work, and I wrote a toy language parser and type inferencer in it. There are maybe three lines of code that GADTs might have let me avoid casting in the type inferencer, but oh well. Different use cases that use GADTs to a greater extent, of course, you might miss them. What is your use case, and how much are you reliant on GADTs in your existing daily life?
- amw-zero 7y ago
  You can go an entire lifetime without ever even knowing about GADTs. I don’t find their absence limiting at all.

nestorD 7y ago

Having used both for years, nowadays I would recommend using F#. The syntax is very similar but it solves many of Ocaml's pain points and you will get better tooling and more libraries thanks to .Net.

polskibus 7y ago
Could you elaborate on the pros of F# vs OCaml?
- nestorD 7y ago
  In no particular order: - significant whitespace and no `let ... in` which makes for a more streamlined syntax - no +. vs + - a solid standard library - much improved tooling (see the ionide plugin for vscode) - you can use all the .Net libraries - multicore support - list comprehension and iterators - object support with a minimalistic syntax (I don't include type providers as I never had proper use cases for them) All of those either remove pain points (some of them arguably very small) or introduce improvements that are sensible in day to day life. With that and the fast that Ocaml and F# can (for the most part) easily be transpiled into one another, nowadays I see very little reason not to use F#. That being said, I find the fact that you basically never need explicit types in Ocaml very elegant (in F# the uniform syntax mean that you will need occasional types hints to disambiguate operations).
  - abhijat 7y ago
    How do you transpile f# to ocaml? Does this mean you can get a native self contained binary out of f# code, by first converting it to ocaml code?
    - yawaramin 7y ago
      You can't. See https://news.ycombinator.com/item?id=22394667 https://news.ycombinator.com/item?id=22394667
    - nestorD 7y ago

yawaramin 7y ago

If you are in the .NET world, then definitely prefer F# to C#. However be aware that it differs in some significant ways from OCaml. E.g., it does not have a separate module language (module types, functors, first-class modules). Its design is in a different, more object-oriented direction, with support for classes and interfaces. Basically, if you do use F#, be aware that it has its own idioms that you must learn; it's not a drop-in replacement for e.g. OCaml/Haskell/etc.