I don't think coming across these problems in general is Haskell specific. We've grown enough to bubble these issues up in this Haskell project, but would have needed to do something much sooner if this was C++. > make…
I should have emphasized the speed of deployment being a first order concern more. We certainly can (and do) build our code for every change, but not at the speed that we want to be updating. We use a monorepo for all…
I'm assuming you're asking what's important in writing "production" Haskell rather than "toy example" Haskell. Ixiaus's point about mechanics more than theory certainly rings true, though we did think a lot about…
Build times for this library haven't cropped up as a first-order concern. Using GHCI and `stack test` for the dev workflow has been fast enough (though could always be better).
One of the cases we found while performance profiling was a tradeoff between memory usage and computation completion. On certain requests FXL would use too much memory and be halted by the equivalent to…
This is in a similar space to reactive programming, but isn't reactive at its core. The best explanation of the monad we use developed is described in the paper here:…
Haxl is the only team using Haskell in prod, so the team itself isn't all that large. With the traction we gain, though, we could grow.
lbrandy also gives a good explanation here: https://news.ycombinator.com/item?id=7874537
Our blog post goes into some of this: https://code.facebook.com/posts/302060973291128/open-sourcin... Interpreted code was no longer cutting it for perf reasons, and any time you create your own language you end up…
I'm an engineer on the Haxl project and am really excited to launch this today. Ask me anything!
I don't think coming across these problems in general is Haskell specific. We've grown enough to bubble these issues up in this Haskell project, but would have needed to do something much sooner if this was C++. > make…
I should have emphasized the speed of deployment being a first order concern more. We certainly can (and do) build our code for every change, but not at the speed that we want to be updating. We use a monorepo for all…
I'm assuming you're asking what's important in writing "production" Haskell rather than "toy example" Haskell. Ixiaus's point about mechanics more than theory certainly rings true, though we did think a lot about…
Build times for this library haven't cropped up as a first-order concern. Using GHCI and `stack test` for the dev workflow has been fast enough (though could always be better).
One of the cases we found while performance profiling was a tradeoff between memory usage and computation completion. On certain requests FXL would use too much memory and be halted by the equivalent to…
This is in a similar space to reactive programming, but isn't reactive at its core. The best explanation of the monad we use developed is described in the paper here:…
Haxl is the only team using Haskell in prod, so the team itself isn't all that large. With the traction we gain, though, we could grow.
lbrandy also gives a good explanation here: https://news.ycombinator.com/item?id=7874537
Our blog post goes into some of this: https://code.facebook.com/posts/302060973291128/open-sourcin... Interpreted code was no longer cutting it for perf reasons, and any time you create your own language you end up…
I'm an engineer on the Haxl project and am really excited to launch this today. Ask me anything!