3 ms·

You know, C#/F# programmers are enjoying most of the above in spades, and the libraries are fully vetted and mature to boot; could say the same for Scala to som

You know, C#/F# programmers are enjoying most of the above in spades, and the libraries are fully vetted and mature to boot; could say the same for Scala to some degree. Can we say the same for Haskell? Let's take a sample: you say, "I'm enjoying my typesafe SQL queries" There are 2 Haskell query DSLs worth talking about (read: that support joins): Esqueleto and OpalEye. The latter is fresh off the presses and not yet ready for prime time (see the "ideal sql" samples interspersed with the performance killing actual sql); the former at first blush looks decent, but then you realize, whoops, no string based SQL interface (for those ultra complex db-specific queries business requirements demand, but cannot be expressed in the dsl), and no Oracle or SQL Server support -- yikes, bye bye enterprise; in fact both libraries officially support one single database, Postgres. Also, given Haskell's lack of a module system (hello global namespace conflicts), the choice of operators is somewhat, well, hideous (Haskell itself remains beautiful though, at least in terms of concision). Not sure how things are on the web framework front, but given the claims of achieving C-like performance, that Yesod and Snap basically face plant in a popular benchmark[1], one wonders where reality and the ideal world Haskellers seem to live in, meet. [1] http://www.techempower.com/benchmarks/#section=data-r9&hw=peak&test=db http://www.techempower.com/benchmarks/#section=data-r9&hw=pe...

MaxGabriel 12y ago
Hi virtualwhys, won't have time to respond to everything but wanted to mention Esqueleto supports MySQL/Postgres/SQLite, they're mentioned in the testing section of their Hackage page https://hackage.haskell.org/package/esqueleto https://hackage.haskell.org/package/esqueleto. Re: the techempower benchmarks, my understanding is that they used an old version of GHC which didn't include the MulticoreIO manager or something like that. It's since been fixed [1] but it's been awhile since a TechEmpower benchmark (iirc round 10 was pushed back but they're now working on it again [2]). [1] https://github.com/TechEmpower/FrameworkBenchmarks/commit/9e8701c4311e04c92b8379819c65457697f07b7d https://github.com/TechEmpower/FrameworkBenchmarks/commit/9e... [2] https://github.com/TechEmpower/FrameworkBenchmarks/issues/1273 https://github.com/TechEmpower/FrameworkBenchmarks/issues/12...
tome 12y ago
> Esqueleto and OpalEye. The latter is fresh off the presses and not yet ready for prime time (see the "ideal sql" samples interspersed with the performance killing actual sql) On the contrary, Opaleye (lowercase "e") has been used in production to run multiple-hundred line queries with high performance. I gave the "idealized SQL" examples in the docs as a way of making the generated code easier to understand for readers, not to suggest that there is any performance loss. If you know of an example where the code generation leads to a performance loss in Postgres I would be interested to hear about it. (An aside: Esqueleto isn't anywhere close to typesafe, nor does the author claim this is one of its goals. It is trivial to produce crashing queries: https://github.com/prowdsponsor/esqueleto/issues/41 https://github.com/prowdsponsor/esqueleto/issues/41)

MaxGabriel 12y ago

Hi virtualwhys, won't have time to respond to everything but wanted to mention Esqueleto supports MySQL/Postgres/SQLite, they're mentioned in the testing section of their Hackage page https://hackage.haskell.org/package/esqueleto https://hackage.haskell.org/package/esqueleto. Re: the techempower benchmarks, my understanding is that they used an old version of GHC which didn't include the MulticoreIO manager or something like that. It's since been fixed [1] but it's been awhile since a TechEmpower benchmark (iirc round 10 was pushed back but they're now working on it again [2]). [1] https://github.com/TechEmpower/FrameworkBenchmarks/commit/9e8701c4311e04c92b8379819c65457697f07b7d https://github.com/TechEmpower/FrameworkBenchmarks/commit/9e... [2] https://github.com/TechEmpower/FrameworkBenchmarks/issues/1273 https://github.com/TechEmpower/FrameworkBenchmarks/issues/12...

tome 12y ago

> Esqueleto and OpalEye. The latter is fresh off the presses and not yet ready for prime time (see the "ideal sql" samples interspersed with the performance killing actual sql) On the contrary, Opaleye (lowercase "e") has been used in production to run multiple-hundred line queries with high performance. I gave the "idealized SQL" examples in the docs as a way of making the generated code easier to understand for readers, not to suggest that there is any performance loss. If you know of an example where the code generation leads to a performance loss in Postgres I would be interested to hear about it. (An aside: Esqueleto isn't anywhere close to typesafe, nor does the author claim this is one of its goals. It is trivial to produce crashing queries: https://github.com/prowdsponsor/esqueleto/issues/41 https://github.com/prowdsponsor/esqueleto/issues/41)