5 ms·

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 prob

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.

darksaints 6y ago
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.
- banashark 6y ago
  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.
  - pbiggar 6y ago
    I'd love to read through some production Saturn and Giraffe setups - is any of your stuff public?
    - banashark 6y ago
      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.
      - siwatanejo 6y ago
        are you freelancing by any chance? dm me on twitter at same username
      - JaggerJo 6y ago
        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.
  - deleted 6y ago
    [deleted]
to11mtm 6y ago
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/ https://github.com/linq2db/linq2db/
- banashark 6y ago
  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!
akra 6y ago
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.
siwatanejo 6y ago
maybe you should give this one a try: https://github.com/rspeele/Rezoom.SQL https://github.com/rspeele/Rezoom.SQL
JaggerJo 6y ago
We've been using https://github.com/Zaid-Ajaj/Npgsql.FSharp 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 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.
- dfgdghdf 6y ago
  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.
  - JaggerJo 6y ago
    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 https://github.com/Zaid-Ajaj/Npgsql.FSharp.Analyzer
tamrix 6y ago
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.

darksaints 6y ago

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.

banashark 6y ago
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.
- pbiggar 6y ago
  I'd love to read through some production Saturn and Giraffe setups - is any of your stuff public?
  - banashark 6y ago
    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.
    - siwatanejo 6y ago
      are you freelancing by any chance? dm me on twitter at same username
    - JaggerJo 6y ago
      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.
- deleted 6y ago
  [deleted]

to11mtm 6y ago

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/ https://github.com/linq2db/linq2db/

banashark 6y ago
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!

akra 6y ago

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.

siwatanejo 6y ago

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

JaggerJo 6y ago

We've been using https://github.com/Zaid-Ajaj/Npgsql.FSharp 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 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.

dfgdghdf 6y ago
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.
- JaggerJo 6y ago
  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 https://github.com/Zaid-Ajaj/Npgsql.FSharp.Analyzer

tamrix 6y ago

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.