4 ms·

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

hedora 2y ago
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?
- bmitc 2y ago
  Vastly. You were probably using Mono. .NET is now fully cross-platform and very good at being so.
- neonsunset 2y ago
  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 https://funcui.avaloniaui.net
- devmunchies 2y ago
  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.
- spooneybarger 2y ago
  Very much so.
wyager 2y ago
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.
phplovesong 2y ago
F# compiler is so slow.. a big turnoff coming from ocaml, where compile times are fast, even faster than Go or Haxe.
- neonsunset 2y ago
  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/028937d82f2adaa6c1b93899e358e1c0 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.
  - phplovesong 2y ago
    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)
  - iLemming 2y ago
    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.
sinkasapa 2y ago
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.
- FrustratedMonky 2y ago
  "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#.
  - antonyt 2y ago
    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.
    - neonsunset 2y ago
      > 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.

hedora 2y ago

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?

bmitc 2y ago
Vastly. You were probably using Mono. .NET is now fully cross-platform and very good at being so.
neonsunset 2y ago
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 https://funcui.avaloniaui.net
devmunchies 2y ago
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.
spooneybarger 2y ago
Very much so.

wyager 2y ago

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.

phplovesong 2y ago

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

neonsunset 2y ago
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/028937d82f2adaa6c1b93899e358e1c0 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.
- phplovesong 2y ago
  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)
- iLemming 2y ago
  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.

sinkasapa 2y ago

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.

FrustratedMonky 2y ago
"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#.
- antonyt 2y ago
  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.
  - neonsunset 2y ago
    > 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.