4 ms·

Do you know alot of Haskell programmers? Because I'm enjoying my typesafe SQL queries, typesafe intra-application linking, typesafe templating, etc. Haskell is

Do you know alot of Haskell programmers? Because I'm enjoying my typesafe SQL queries, typesafe intra-application linking, typesafe templating, etc. Haskell is capable of far more than "pure, mathematical problems"—indeed, typed IO is a premier feature of the language. edit: sorry, this was pretty defensive; I shouldn't have written this comment so hastily.

hueving 12y ago
Do you get anything done with it?
- MaxGabriel 12y ago
  We don't use it at work so I can't say I've done anything at scale, but I was very happy with it making this internal-ish website for work http://heyzaphackday.com/hackdays http://heyzaphackday.com/hackdays I don't think I had a single 5xx or 404 when developing it, and last I checked 1 500 error in production. I know it's a small site, but it's still pretty unlikely that I'd make a small Rails site without typoing something/misremembering a SQL column name/making a bad assumption about e.g. always getting a value from a cookie.
virtualwhys 12y ago
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)

hueving 12y ago

Do you get anything done with it?

MaxGabriel 12y ago
We don't use it at work so I can't say I've done anything at scale, but I was very happy with it making this internal-ish website for work http://heyzaphackday.com/hackdays http://heyzaphackday.com/hackdays I don't think I had a single 5xx or 404 when developing it, and last I checked 1 500 error in production. I know it's a small site, but it's still pretty unlikely that I'd make a small Rails site without typoing something/misremembering a SQL column name/making a bad assumption about e.g. always getting a value from a cookie.

virtualwhys 12y ago

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)