Comment by banashark | Hacker News Reader

Comment by banashark | Hacker News Reader

Parent Full thread

I enjoy f# a lot, but it doesn't necessarily help with all of their problems.

One of the biggest problems they mention is with postgres. F# has a postgres problem as well.

Your options in f# for postgres usage include the following high-level categories:

• Dapper/RepoDb/Other community libs

• Typeprovider based like Fsharp.Data.Npgsql

• EF core (where you build the fsharp design-time support yourself)

• Using C# in another project as a database interaction abstraction

I've had to mix and match for the projects I've worked on because I've had trouble finding a single library where:

1) Joins are supported in a sane way

2) Batch inserts work

3) Interacting with native features (views, functions, SET variables) works

4) It's still in fsharp

It's not bad, but when I work on $DAYJOB projects in Typescript/etc where database access is smooth, I wonder how long it might take to rewrite for the database heavy projects.

Also should mention that I'm very thankful for the libraries that _do_ exist, and the effort put into making them as feature as they are. It's just one of the areas that I don't think is a strength of F# right now.

I've done quite a bit of F# Postgres in a previous life and I didn't find it much different than other programming languages. However I tend to just use the Npgsql library directly with ADO.NET for performance which I often needed for my cases with Postgres. These days you can insert array objects, insert whole objects graphs, do batch inserts and create little helpers to read/write sets with Npgsql/PSQL directly; often much faster than using a higher level ORM. In my experience Postgres often would produce query plans that required a lot of SQL tuning/rewriting in a different way to get right (e.g. loose index scan SQL to get latest entry per group). I just wrap the solution/build with DB tests to make sure the SQL is covered well vs using the type provider. Tbh the amount of code (in lines) is mostly the same as well to do it vs a higher level framework - we did the comparison.

Have you looked into Linq2Db [0]? (I'm a contributor to the project) I know a few F# users have had success with a couple of minor caveats. I can say it handles most of the points you mentioned fairly well however (Great join syntax, lots of bulk insert options, easy wire-in for native features.)

[0] - https://github.com/linq2db/linq2db/

It's been a while since I looked at linq2db, but it looks like a great project. I'll probably carve out some time this weekend to play around with it!

We've been using https://github.com/Zaid-Ajaj/Npgsql.FSharp and it's great. Uses well supported lib behind the covers and just provides a small layer on top.

Same thing exists from MS SQL https://github.com/Zaid-Ajaj/DustyTables , also great.

Used both in prod. No regrets and wouldn't wan't something else. Also involves zero magic - just raw SQL and a nice functional API.

I also had a good experience with Npgsql.FSharp. I love that it is just an idiomatic F# layer on top of raw SQL. I don't think that ORM is a good fit for functional languages anyway.

I believe there is some work with F# analyzers to provide compile-time checking of raw SQL, although I haven't tried it yet.

agreed. Often dealing with an ORM is more complex than just to write a bit of SQL and reading code.

Yep, never tried it either. https://github.com/Zaid-Ajaj/Npgsql.FSharp.Analyzer

But those are all database abstraction mechanisms or ORMs. Regular SQL access to postgres databases is pretty much a fully solved problem in F#, even if the ORMs are not.

This is true (with the caveat of some interesting edge-cases with npgsql and F#), however the next paragraph in the article mentions "a lack of a high-level, production web stack".

Definitely a personal take here, but since I've worked for a while with postgres, a "high-level, production web stack" for me is something that has an established, good DX way to work with this popular database.

Managing ADO.NET connections, working around the type systems and writing a lot of mapping/connecting code are all things that don't solve my business problem.

While not prolific, I've written a handful of production web applications in F# (Suave, Giraffe, Saturn, and Razor Pages) as well as other stacks, and have found a hybrid approach that works for my concerns, but I've found a comprehensive solution not as simple as other ecosystems.

I'd love to read through some production Saturn and Giraffe setups - is any of your stuff public?

Unfortunately almost all of my work is not public. I've always envied folks with lots of public code to show and share. I had created an F# starter-kit repo (somewhere between hackathonstarter and bullet-train saas kit) along with some blog posts, but I just haven't had free time to wrap it up and publish the repo/blog posts.

I see questions frequently about data access and serialization/validation in F# web apps, which I had specific sections about. Hopefully I'll have some time in the near future to continue the work.

In the mean time feel free to DM me any questions. There's nothing too fancy about the code. If you looked at other production code, and swapped out what your best guess for the F# translation would be, you're probably most of the way there.

We're using Giraffe and it's great. The nice thing IMO is that is sits on top of ASP.NET core. So it's fast and if you need something like SignalR, ... it integrate flawlessly.

are you freelancing by any chance? dm me on twitter at same username

If you're writing a while platform with a new ide concept, built in deployment and your own framework on top. (darklang) I think an ORM is the least of their problems.

They'll not going to pick F# because they're in competition with Azure.

They don't want ocaml because of marketability. It's technically the right choice and direction but the learning curve for developers is turning them off the platform as a whole.

maybe you should give this one a try: https://github.com/rspeele/Rezoom.SQL

Reply on news.ycombinator.com