top | item 26739501

A Brief F# Exploration

109 points| todsacerdoti | 5 years ago |notes.srid.ca | reply

60 comments

order
[+] bromanko|5 years ago|reply
I agree with the author about the slow inner loop experience. Recompiling the whole app to see browser changes gets tiring. The .NET team is planning a series of updates to address this in .NET 6. https://github.com/dotnet/core/issues/5510

I also dislike the default workflow for dealing with Nuget forks. I switched to Paket for dependency management which makes this much simpler. https://fsprojects.github.io/Paket/

[+] tasogare|5 years ago|reply
This is a very strange criticism given that F# was the first language to have a REPL and nowadays most web projects also have a compilation step.
[+] angio|5 years ago|reply
My favourite thing about F#/.NET Core (I guess .NET 5 now) on Linux is how easy it is to install multiple versions side by side using my distro package manager. This spoiled me so much now I'm disappointed when I have to use conda/rustup/etc.
[+] xfer|5 years ago|reply
Consider using nix package manager. You can have multiple versions for every tool/library you like.
[+] christophilus|5 years ago|reply
F# is a great language. I just wish it compiled as fast as OCaml or even anywhere near as fast. I also wish it produced a single static binary, though I guess this is now possible in .NET? It’s been a while since I toyed with it.
[+] JohnCurran|5 years ago|reply
You can produce a single file binary, with the caveat it includes the entire .NET runtime, which leads to massive build artifacts. Though it is better than no support at all I suppose
[+] ollran|5 years ago|reply
OCaml would meet all the requirements. Any thoughts on it?
[+] pharmakom|5 years ago|reply
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.

[+] pjerem|5 years ago|reply
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#.

[+] nestorD|5 years ago|reply
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).
[+] swuecho|5 years ago|reply
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.

[+] auxym|5 years ago|reply
OCaml has subpar windows support. The native version is experimental, otherwise it's cygwin or WSL.
[+] aranchelk|5 years ago|reply
> Must run natively on backend without nodeJS (rules out the likes of PureScript)

PureScript does have an Erlang backend as well.

My understanding is F# relies on a JIT just as Node (V8) does. Are either really native? Are both?

[+] tremon|5 years ago|reply
Yes, F# relies on a JIT, but not just as Node does. F# compiles to CIL, the .Net runtime bytecode format. It is much more like Python bytecode (pyc) or JVM bytecode (jar) than like Javascript.

FAFAIK Node doesn't compile to an intermediate language, it either compiles to minimzed (lets-just-remove-all-whitespace) Javascript, or it generates a native binary.

[+] pharmakom|5 years ago|reply
F# can run in a few different places: .Net, node, browsers, .Net core, Mono and AOT compiled. Some targets have JIT, some do not.
[+] Kipters|5 years ago|reply
It does, but you can produce self-contained applications that don't need the runtime to be installed (it's included in a native binary shipped with the application). Full AOT compilation is also being worked on.
[+] skrebbel|5 years ago|reply
I'm assuming that they primarily mean "I prefer not to depend on NodeJS for $REASONS". That's pretty fair, Node is amazing but there's definitely also plenty to dislike.