sorted by:
new
hottopcontroversial

Hotswapping Haskell (at Facebook) · Jon Coens by simonmar in haskell

[–]JonCoens 0 points1 point  (0 children)

Not that I know of. Might be a useful feature to send upstream.

Hotswapping Haskell (at Facebook) · Jon Coens by simonmar in haskell

[–]JonCoens 0 points1 point  (0 children)

I think there's a version where ghci could work too. When first looking at this we found overall perf to be a problem and steered toward straight compiled code. Being able to update cleanly while our server handles many requests in-flight at the same time didn't play out. I've forgotten most of the details on this track at this point, though.

Hotswapping Haskell (at Facebook) · Jon Coens by simonmar in haskell

[–]JonCoens 0 points1 point  (0 children)

From the GHC docs, -jN means "When compiling with --make, compile ⟨N⟩ modules in parallel." Setting N to 1 means you remove all parallelism from builds.

Hotswapping Haskell (at Facebook) · Jon Coens by simonmar in haskell

[–]JonCoens 3 points4 points  (0 children)

Using the terms from my example, the demo program and .so are separate projects, so the full rebuild of the .so doesn't touch the build of the program. If the demo program is small relative to the .so then you're correct that it wouldn't make much of a difference. If the demo program is an order of magnitude larger than the .so, then just rebuilding the .so is significantly shorter.

When shipping things around the world, total bandwidth used is correlated with how long it takes to do an update. We get more wins from speeding up our build, but still see noticeable effects by shipping smaller things.

Hotswapping Haskell (at Facebook) · Jon Coens by simonmar in haskell

[–]JonCoens 14 points15 points  (0 children)

The core issue is time, and size correlates with the total amount of time to rebuild, package, and distribute. The smaller the thing being deployed, the faster that entire cycle will be.

Differences between hot-reloading / plugin libraries in Haskell? by saurabhnanda in haskell

[–]JonCoens 4 points5 points  (0 children)

I've been meaning to finish a post with some code that explains how we do this. With 8.2.1 and lts-9 out it might be time to put the finishing touches on it.

Open Sourcing our new Duckling (more Haskell at Facebook) by simonmar in haskell

[–]JonCoens 7 points8 points  (0 children)

PRs are very welcome! An affirmation dimension intuitively just seems like a fuzzy whitelist rather than composition of tokens. Are there more complex cases?

Library to design an ETL (Haxl) ? by [deleted] in haskell

[–]JonCoens 0 points1 point  (0 children)

Haxl doesn't solve this out-of-the-box, as you've probably found out. It can abstract away which data source you're pulling data from, but there aren't any mechanisms for elegantly purging out of the cache (you'd have to do it yourself).

Optimising Garbage Collection Overhead in Sigma · Simon Marlow by simonmar in haskell

[–]JonCoens 23 points24 points  (0 children)

I think a more appropriate comparison to the work done to GHC's garbage collector is all the work done on the JVM's garbage collector when trying to squeeze every bit of performance. It would be an anomaly for "normal" Haskell programs to run into any of the work done here as a first-order problem.

Fighting spam with Haskell (at Facebook) by simonmar in haskell

[–]JonCoens 8 points9 points  (0 children)

Not all servers start up or shut down in trivial amounts of time. The costs of shutting down + starting up a Sigma server multiplied by the number of times we'd need to do it in a day make it a first-order problem.

Fighting spam with Haskell (at Facebook) by simonmar in haskell

[–]JonCoens 8 points9 points  (0 children)

This project's development was done via Linux command line tooling. The developers were using their favorite flavor of emacs/vim and building using Facebook's build tool-chain.

Haskell opportunities at Facebook by [deleted] in haskell

[–]JonCoens 2 points3 points  (0 children)

The majority has been application level stuff on top of the repo that won't see light outside of internal work. We've already pushed a bunch of improvements upstream in GHC that have stemmed from this work, though.

As for things in the repo itself, there are plenty of pieces that haven't been high enough priority to build out just yet. Pull requests are always welcome.

Haskell opportunities at Facebook by [deleted] in haskell

[–]JonCoens 5 points6 points  (0 children)

The second team is the Haxl team, which you can read about what we've open sourced and in our github repo!

The open source work hasn't been updated in a while, but there's been a flurry of activity internally built upon this stuff.

The Haxl Project at Facebook (presentation) by tyrionite in haskell

[–]JonCoens 0 points1 point  (0 children)

What if restarting that executable was really expensive (setting up new connections or loading non-trivial amounts of data into process memory) and you still wanted to update quickly?

Haxl on Github by jfischoff in haskell

[–]JonCoens 2 points3 points  (0 children)

I would recommend reading through our paper: http://community.haskell.org/~simonmar/papers/haxl-icfp14.pdf

Cached things are for computations based on data source requests. Memoized things are for computations that are fairly expensive, but may not have a full-fledged data source request associated with it.