Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hotswapping Haskell

simonmar.github.io

Post reply on HN
Print view View original

31–36 of 36 posts

Re: Hotswapping Haskell

#31

Post by tazjin »

jimbokun wrote: post #24
teraflop wrote: post #2

I don't want to knock the technical achievement here -- it's a cool hack -- but I'm really surprised that it was deemed to be the best choice for a production system. In the first place, "we can't compile our code on every change because it takes too long" is a really awful situation to be in. Are developers not building and testing their changes before deploying them? Can Facebook not afford a continuous integration…

"In the first place, "we can't compile our code on every change because it takes too long" is a really awful situation to be in." Isn't this exactly the problem Go was invented to solve?

It "solves" it by not doing any of the things that you'd expect a modern language's compiler to do.

In my opinion the time wasted debugging Go issues that could have been statically prevented is better spent waiting for a slightly longer compile cycle to finish.

Re: Hotswapping Haskell

#32

Post by chillee »

Not really relevant to the article itself, but I've always been surprised how much attention Facebook's Haskell usage gets compared to Facebook's Ocaml usage.

From interning at Facebook, the only project that I'm aware of that uses Haskell is Sigma. On the other hand, numerous projects use Ocaml: Infer, HHVM, Flow, ReasonML, Pfff, etc.

However, it's Haskell that gets all the attention on Hacker News.

Re: Hotswapping Haskell

#33

Post by rtpg »

JonCoens wrote: post #26
teraflop wrote: post #2

I don't want to knock the technical achievement here -- it's a cool hack -- but I'm really surprised that it was deemed to be the best choice for a production system. In the first place, "we can't compile our code on every change because it takes too long" is a really awful situation to be in. Are developers not building and testing their changes before deploying them? Can Facebook not afford a continuous integration…

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 of the benefits it has, and deploying fast business logic updates this way helps mitigate one of its downsides (particularly when you've maximally parallelized the build). I've found https://danluu.com/…

How much is this because of Haskell's build times in particular? Is there a sort of "target build time" that would make you more comfortable with this stuff

Re: Hotswapping Haskell

#34

Post by JonCoens »

rtpg wrote: post #33
JonCoens wrote: post #26

Earlier quoted context omitted.

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 of the benefits it has, and deploying fast business logic updates this way helps mitigate one of its downsides (particularly when you've maximally parallelized the build). I've found https://danluu.com/…

How much is this because of Haskell's build times in particular? Is there a sort of "target build time" that would make you more comfortable with this stuff

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 you more comfortable with this stuff

Which stuff are you referring to? Overall I'd love if all builds were significantly faster, so we contribute to upstream GHC to make it better in the ways we come across. Our platform has a deployment SLA that we strive to maintain as our "target build time".

Re: Hotswapping Haskell

#35

Post by MaxGabriel »

chillee wrote: post #32

Not really relevant to the article itself, but I've always been surprised how much attention Facebook's Haskell usage gets compared to Facebook's Ocaml usage. From interning at Facebook, the only project that I'm aware of that uses Haskell is Sigma. On the other hand, numerous projects use Ocaml: Infer, HHVM, Flow, ReasonML, Pfff, etc. However, it's Haskell that gets all the attention on Hacker News.

I’ve seen them recruit for a second Haskell team, I believe doing internal analytics or machine learning.

Re: Hotswapping Haskell

#36

Post by pjmlp »

jimbokun wrote: post #24
teraflop wrote: post #2

I don't want to knock the technical achievement here -- it's a cool hack -- but I'm really surprised that it was deemed to be the best choice for a production system. In the first place, "we can't compile our code on every change because it takes too long" is a really awful situation to be in. Are developers not building and testing their changes before deploying them? Can Facebook not afford a continuous integration…

"In the first place, "we can't compile our code on every change because it takes too long" is a really awful situation to be in." Isn't this exactly the problem Go was invented to solve?

No because fast compile times were already solved in the 70's, when using languages like CLU, UCSD Pascal, Mesa and Modula-2.

The authors might have done it in regards to waiting for C++ builds, but the problem was not a problem for those using other programming languages.

Post reply on HN