jonahkagan

What's your brown rice approach? I've tried a few diff ones I've found online but none have turned out amazing

(They are very good points though! Thanks for sharing them)

What if the private methods are complex but also module-specific? For instance, if they deal with a data type that is private to the module?

When you pull out complex code like this into another module, how do you specify that the new module is actually private to the old module?

That's a great point. I definitely agree that erring on the side of modules is better. I just worry about times when the purpose of a module is not clearly defined at the outset (e.g. when it only contains one function that is only used in one other module). I have often seen that devolve into the "helper" module, where random functions collect.

I'm also not sure I buy the assertion that all code you would want to test is code you would want to export publicly. Do you have any reasoning to support that idea?

Yep, we use CoffeeScript.

Good find! I can't seem to find a comment that indicates what the new limit is though. Experimentally, we were seeing processes dying at around the 1.7GB to 2GB range.

Did you find anything indicating what the expected new limit is?

sagichmal, could you elaborate on "we were able to map a fan-in-on-read stream product to a data model that could be implemented with a specific type of CRDT"? The post (which is awesome btw) glosses over exactly how Roshi is used to solve the problem presented in the first half of the post - or at least it seems that way to me as I am unfamiliar with CRDTs.

Link seems to be down, but I'd be interested.

Does anybody know of other flat companies? I've heard Valve is somewhat like this. What about outside of the software industry?

Yeah, that's a good point, but if you got all the CoffeeScripters' attention and then showed them that CoffeeScript is just one possible improved syntax...