Hacker News Reader

Comment by neonsunset | Hacker News Reader

Massive amounts of headache could have been avoided by using “OCaml but with ecosystem and great tooling support” known as F# :)

View on HN

I got turned off of F# because it seemed like knowing C# libraries and tooling was assumed if one wanted to do anything non-trivial, kind of like some of the functional JVM languages always assume some amount of Java knowledge and use of Java tooling. F# seemed nice, but it didn't seem like a real stand-alone language. Unlike Elm or Purescript, where one should also know JavaScript and its tooling, I don't find learning all the C# and Java stuff independently compelling enough to use F#, Scala, Frege, etc.

"C# libraries"

Isn't this just .NET?

Think this was a feature. F# has access to all of the existing libraries, plus those made for F#.

It's a feature but also sort of an anti-feature. To do anything productive you will need to reach for a lot of .NET libraries, and those will force you to write code differently than you would if you could live in blissful pure-F# land. This results in a mishmash of styles.

Something as simple as calling a .NET function that doesn't have F# bindings forces a change (e.g. `someLibraryFunc(arg1, arg2)` instead of `f arg1 arg2`).

This gets worse as libraries force you to instantiate objects just to call methods which could have been static, or use ref parameters, etc.

I say this as somebody who loves F# - you do absolutely have to know .NET style (which really means C# style) in addition to F# style. It's extremely pragmatic if you're already familiar with C#, but I'm not sure how wonderful it is if you come in cold.

> ref parameters

I actually like the way F# does refs more! byref<'T> aligns more closely with internal compiler terminology and makes it more clear that this is something like a pointer.

Having to perform tupled calls over curried is indeed an annoyance, and even a bigger one is the prevalent fluent style which results in

  thing
  |> _.InstanceMethod1()
  |> _.InstanceMethod2()
  |> _.Build()

Ugh, I usually try to shuffle around what I find annoying into bespoke functions (which are thankfully very easy to define) or even declaring operators. It also helps that while selection is not vast, F# tends to have various libraries that either provide alternatives or wrap existing widely adopted packages into a more functional F#-native API e.g. Oxpecker, Avalonia FuncUI, FSharp.Data, etc.

" if you could live in blissful pure-F# land"

Yep. I love F# too, wish I could stay in blissful F# land.

Wish MS would just release a .NET re-done in F#? Huge task, with no payback. But would be nice.

F# compiler is so slow.. a big turnoff coming from ocaml, where compile times are fast, even faster than Go or Haxe.

Relatively yes, but F# also happens to be faster than other FP languages and has access to a vast ecosystem unlike Haxe. I doubt the public looking at FP languages would appreciate Go :)

F# includes an optimizer that performs e.g. lambda inlining. Then, .NET compiles the assemblies themselves to a final application, be it native executable or otherwise, so I feel like relative compiler slowness is not a dealbreaker. It is also relatively quick at starting for executing F# script files with `dotnet fsi` (I'm happy that F# is included in standard .NET SDK, much different to e.g. Clojure or Scala), it's slower to start than Python or Elixir shell but I can live with that.

This was also a good opportunity to write down a small workflow to use F# interactive to quickly build small native console applications thanks to FSharpPacker:

https://gist.github.com/neon-sunset/028937d82f2adaa6c1b93899...

In the example, the sample program calculates SHA256 hashes for all files matching the pattern at a specific path. On my M1 Pro MBP it does so at up to 4GB/s while consuming 5-10 MiB of RAM.

Well Haxe has access to whatever it compiles to. If i target JS i get the entirety of the JS ecosystem, in good and bad.

F# is indeed fast. Thanks the the work MS has put in. But so is Ocaml, it is close to C when written in perf first mode. Having said that i rarely need the speed of C for what im building, as bottlenecks tend to be IO anyway.

Finally, ocaml 5+ got multicore (domains) and effects, that really is a better abstraction than monads ever will be (imho)

Not all Clojure REPLs have slow startup. Clojure is a hosted language, it sits atop another PL. For instance, REPL of nbb (which runs on Node) is instantaneous, and babashka (for bash scripting) is also very fast.

F# is good because MSR used to hire a bunch of the top GHC devs and pay them to work on F# part-time. They put all their actual passion into Haskell.

I tried that about 10 years ago and spent 2 hours trying to open some files under Linux.

Then I gave up. Have things improved?

Vastly. You were probably using Mono. .NET is now fully cross-platform and very good at being so.

The below should work as is:

  sudo apt install dotnet9 # or dotnet-sdk-9.0 if the repo doesn't have dotnet9 metapackage
  dotnet new console --language F#

There is also a package for Avalonia that lets you write GUI applications in F#: https://funcui.avaloniaui.net

I didn't use it 10 years ago but I've been using it for the last 4 years on mac and linux exclusively.

Microsoft seems to be prioritizing "cloud" on all their developer products (rather than just windows). I don't feel disadvantaged by NOT using dotnet on windows.

Very much so.

Reply on news.ycombinator.com