←back to thread

Why F#?

(batsov.com)
447 points bozhidar | 1 comments | 01 Apr 25 12:34 UTC | HN request time: 0.216s | source
Show context
nickpeterson ◴[01 Apr 25 12:42 UTC] No.43546092[source]▶
Because it’s great, and people that think otherwise are dead to me.
replies(3): >>43546162 #>>43546305 #>>43548281 #
MrMcCall ◴[01 Apr 25 12:48 UTC] No.43546162[source]▶
Curried functions combined with that magnificent pipe operator, overlaid on the .NET runtime. Don Syme et al knocked it out of the park.

It's the one programming language that changed how I think about programming.

I'm only talking about the version before type providers. Then it got messy.

Before that, we could (and I did) recompile fsi.exe to do some custom prompt manipulation. It was a slog, but it worked, but then Microsoft faded from my life. Still, that early version (I believe 2.0) F# is just magnificent.

replies(2): >>43546316 #>>43550647 #
munchler ◴[01 Apr 25 13:03 UTC] No.43546316[source]▶
F# is up to version 9 now, and has only improved over time, IMHO. Type providers are a very small part of the story and can be avoided entirely if you want.
replies(3): >>43546741 #>>43546839 #>>43548606 #
speed_spread ◴[01 Apr 25 13:56 UTC] No.43546839[source]▶
Why would type providers be avoided? It seemed to me like a nice metaprogramming feature, akin to what Zig does with comptime types (except runtime?)
replies(4): >>43547007 #>>43547567 #>>43548456 #>>43550319 #
1. Akronymus ◴[01 Apr 25 14:11 UTC] No.43547007[source]▶
Type providers can be extremely brittle IME. Altough, I guess if it is referring to version controlled example data that probably works better than referring to a DB or something like that directly that the dev has to provide.