←back to thread

Why F#?

(batsov.com)
447 points bozhidar | 1 comments | 01 Apr 25 12:34 UTC | HN request time: 0.001s | 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 #
munchler ◴[01 Apr 25 14:58 UTC] No.43547567{3}[source]▶
Type providers are very powerful but involve running arbitrary external software at compile-time (e.g. a SQL Server or Postgres database). This can be difficult to set up and configure reliably in a multi-person project.
replies(1): >>43558570 #
1. owlstuffing ◴[02 Apr 25 16:39 UTC] No.43558570{4}[source]▶
You're not entirely wrong, but when it comes to SQL, the trade-offs are unavoidable. You either embrace a conventional, not-SQL approach with all its limitations, or you treat the database as the single source of truth (SSoT). Both have downsides, but configuring a designated local or shared database for this purpose is no less reliable than conventional approaches.

As for type providers in general, I don't think databases are the best example of their typical use case. Most type providers don’t interact with external systems; they usually parse schemas, configuration files, or other structured data to generate strongly typed representations. The database-backed approach is just one variant, not the norm.