beam VS esqueleto

I'm not familiar with GPUs specifically, but I have seen this for ORMs that support multiple SQL dialects (e.g. [0]).

A great technique is called 'tagless final encoding' [1]. Using this technique, you can specify capabilities of an embedded domain-specific language (eDSL) such that you can have a shared (but narrow) common set of features, while allowing specializations of this eDSL to support extra features.

[0]: https://github.com/haskell-beam/beam

[1]: https://nrinaudo.github.io/articles/tagless_final.html

https://haskell-beam.github.io/beam/ is fantastic, but good luck understanding it if you don't already know some Haskell

Beam “is a highly-general library for accessing any kind of database with Haskell”. Beam makes extensive use of GHC's Generics mechanism — no Template Haskell.

One anecdotal opinion from a rando reddit user: I prefer beam despite the boilerplate and more complex types because of the authors make a serious attempt at sql-standards compliance: https://github.com/haskell-beam/beam

It's actively worked on: https://github.com/haskell-beam/beam Makes heavy use of the type level though.

The beam library is one example of this: https://github.com/haskell-beam/beam/pulls

Writing Haskell programs that rely on third-party packages is still an issue when it’s a not actively maintained package. They get out of date with the base library (Haskell’s standard library), and you might see yourself in a situation where you need to downgrade to an older version. This is not exclusive to Haskell, but it happens more often than I’d like to assume. However, if you only rely on known well-maintained libraries/frameworks such as Aeson, Squeleto, Yesod, and Parsec, to name a few, it’s unlikely you will face troubles at all, you just need to be more mindful of what you add as a dependency. There’s stackage.org now, a repository that works with Stack, providing a set of packages that are proven to work well together and help us to have reproducible builds in a more manageable way—not the solution for all the cases but it’s good to have it as an option.

However, we can use Esqueleto (”a bare bones, type-safe EDSL for SQL queries”) with Persistent's serialization to write type-safe SQL queries. It’s unlikely that you want to use Persistent by itself with SQL, so let’s use and review them together.

Postgresql-simple is a great library, it makes a nice use of overloaded strings to do the job. Some other nice libraries to keep an eye on are opaleye (postgres specific, which is equally nice but could be a bit difficult to get why the types are so big) and a combination of persistent (not DB specific! can work on postgres, sqlite, but also noSQL DBs like mongo, it's still easy to learn but you lose some things, such as joins due to the power of being agnostic) + esqueleto for type safe joins (be sure to look up the experimental package, it's a more comfortable syntax that will soon become the default one).

Using esqueleto in one of my haskell projects was a huge time sink and a major barrier to entry for colleagues.

In Haskell: https://hackage.haskell.org/package/esqueleto

Either it analyzes the given SQL to determine the in/out types of each SQL query, or it calls the database describe feature at compile-time.