bolinfest's comments

DotSlash is a new, open source command line tool that makes large executables available in source control with a negligible impact on repository size, thus avoiding expensive clone operations.

If you want to skip the paper and watch the video: https://youtu.be/ANDJ0TKjyWw

Disclaimer: I am the person in the video.

Originally started as an extension to Mercurial, but grew into its own SCM with a cross-platform virtual filesystem in C++ and a distributed server in Rust.

As a fellow Facebook employee, FYI, Hacker News is not a great place to get tech support.

For the benefit of everyone else on this thread, note that Facebook uses https://github.com/facebookexperimental/eden. From the README:

> Despite having originally evolved from Mercurial, EdenSCM is not a distributed source control system.

i.e., this is not "stock" Mercurial. For example, the Eden server (Mononoke) is written in Rust and the complementary virtual filesystem is written in C++. This has very different performance characteristics than real Mercurial.

EdenSCM works with both EdenFS (the custom filesystem) and a traditional filesystem. If you use EdenFS, pulls will be much cheaper because you only fetch what you use. If you use a traditional filesystem, EdenSCM supports the same "sparse checkouts" feature as stock Mercurial (https://firefox-source-docs.mozilla.org/build/buildsystem/sp...), which can also be used to reduce the size of the slice of the monorepo you pull down.

Last I checked, Perforce (and Google's "implementation" of Perforce, Piper) did not provide nearly the same level of support for stacked diffs as Eden. As both Google and Facebook have cultures of pre-commit code review, working with stacked diffs makes it much easier to make progress while waiting for approvals on earlier diffs.

I believe there are relative advantages/disadvantages of Eden vs. Piper+CitC and that both projects aspire to have the best of each in the limit.

My name is Michael Bolin and I created Buck.

When I started the project, Buck had one specific goal: to make Android builds faster (https://youtu.be/CdNw6mRpsDI). At the time, the recommended way of building Android (from Google) was to use Ant. So when someone points to Buck as an example of "creating competing tools more often than persisting with and improving existing ones," I'd like to point out that you can't fix Ant if these are your issues with Ant:

* It is unsound. * Because it is unsound, it is irreparably slow. * It uses XML as a build language.

Yes, in July 2012, there were a number build systems on the market (though Bazel was not one of them, but Pants was), and none of them focused on building Android. And even if they did, few (if any) software companies were building an Android app as large as Facebook, so it was unlikely that anyone else was going to design for our scale.

It also wasn't just about build times, but about how I wanted to see us organize code in our repository. At the time, there was a flat list of folders in the Android repo, each called lib-something. This drives me insane because you inevitably end up with two (or more!) people creating com.facebook.common.StringUtils, each in their own lib-something. (It's also annoying to `ls` this "lib-" directory over time.)

In contrast, Buck/Bazel encourage the use of a unified tree, but still encourage fine-grained modularization (which is key as your build graph gets very large). This has been shown to scale to extremely large monorepos at both Facebook and Google.

Finally, by having total control of the build system, we were able to build in all sorts of cool tricks to build Android very fast, both in the large and in the small: https://youtu.be/Y9MfGS3qfoM. I don't think there is any other build system we could have decided to work with at the time to achieve these gains.

Buck has since evolved to build everything else at Facebook. This is not because the Buck team set out to conquer the world, but because people internally wanted the benefits of Buck for their builds. Building an alternative toolchain to xcodebuild was a mammoth effort (and one for which I take no credit). Having one build language for a heterogeneous collection of programming languages in a monorepo is no small feat.

Finally, to the people who believe "The big guys want developers locked into their ecosystems," I have news for you: the Buck team is not offended if you use Bazel, Gradle, Make, or anything else. Buck is open source because we wanted to share it with the community, not dominate it. Like many of you, people are excited to show their work and learn from others.

I explained that here: http://stackoverflow.com/a/19111982/396304

Why gate your progress on standards committees?

For context, here's a discussion from the Atom forum that we had way back in August about the future of React in Atom:

https://discuss.atom.io/t/whats-the-status-of-react-in-atom/...

There are a few issues in play here:

(1) Atom wants to support a world in which every Atom package can install whatever version of a dependency it wants, including React. This is very common in Node (incidentally, this causes problems if you want to use singletons or instanceof in Node), but fairly uncommon on the Web (where React is primarily used). That is, it's rare that you inadvertently load multiple versions of React in your single-page application. If you did, you would likely get an error when adding one React component as a child of another React component because of the way React vends ids. (Solutions are possible, but none is employed today.)

From Atom's perspective, that is a problem. The only way they can work around it is by providing "one true version of React" with Atom core that all packages must use, but then Atom is forcing all packages to use a particular version of React. That would violate Atom's philosophy of letting each package choose its own dependencies.

(2) This is not just an issue for React, but for any UI toolkit whose components are not guaranteed to interoperate across versions. To sidestep this issue, Atom has currently decided to use the DOM API/HTML custom elements. I would call this the "least common denominator approach," which satisfies Atom's design goals, but fails to provide a higher-level abstraction for building UI in Atom. It's a tradeoff.

(3) React does not currently support the shadow DOM or custom attributes, which is the new direction that Atom has chosen. As React has not yet been evicted from Atom core, I recently upstreamed a change (https://github.com/atom/react/pull/1) to add one-off support for Atom's primary custom elements, <atom-text-editor mini> and <atom-panel>, in the fork of React bundled with Atom. As I develop Atom packages using babel (formerly 6to5) http://blog.atom.io/2015/02/04/built-in-6to5.html, which has default support for JSX, building UI in React has been a lot of fun. However, the lack of support for custom attributes makes it difficult to do things like add an appropriate onChange handler to an <atom-text-editor> to update the React component's state as shown in http://facebook.github.io/react/docs/forms.html.

(4) React is still version 0.x.x, which means it has not yet committed to a stable API. This makes choosing a version of React to bundle with Atom an even more uncomfortable decision for the Atom team, assuming they were willing to do so in the first place.

None of these items implies that there is something fundamentally broken about React's model. It just means that the React team has some work to do in order to support Atom's use case. The performance graphs cited in the original post are also significant (and of interest to the React team), but even if the performance problems were fixed tomorrow, that alone would probably not be enough for Atom to pull React back into core right now.

More on the background behind this project: http://blog.bolinfest.com/2013/01/generating-google-closure-...

When I met Jeremy at JSConf (this was at the end, during the super-loud party), I asked whether such a patch would ever be accepted, and he said, "no, probably not." Obviously that didn't stop me and I'm glad to hear that it would be considered once it has matured :)

If it were to happen, then yes, it should certainly be an option, though to clarify, you can use the Library without the Compiler, and the way things are written now, the only file from the Closure Library that your generated code would depend upon is the bootstrapping base.js file. (Though it may also depend on array.js down the road -- see the section "Leveraging More Closure Library Built-ins" on http://bolinfest.com/coffee/features.html.)

But I think it's completely fair to wait until it's "finished" before trying to upstream it, as Jeremy suggests. It will likely take a bit of refactoring for the CoffeeScript code to support "plugins" such as these. As you can see, I'm just spraying "if o.google" statements in https://github.com/bolinfest/coffee-script/blob/master/src/n... to get things done right now, which would not be acceptable to upstream in its current form.

Absolutely: it's easier for me to think about my own work when I see it in context (i.e., with the formatting). If I had to mouse around and select "Courier New" and the color green every time I wanted to format a code sample to get an idea of whether it looked right, I would have never finished. I had just enough formatting to tell whether things "felt right," but not so much that configuring it became a distraction.

Though what _was_ a distraction was having to stop writing to switch contents and fix bugs or add features to my editor. This was still happening when I was in the final stages of the book because any time I context-switched, I tried to spend as little time on it as possible so I could get back to work. In retrospect, maybe I should have just taken a day or two to focus on the editor and then never go back.

Fortunately, I'm still using NJEdit for other things now that the book is done, so it seems to have been worth the investment. I've also open-sourced it so others can use it or fork it for their own needs, so hopefully others can find a way to benefit from it.

I wrote my own web-based editor to write Closure: The Definitive Guide (O'Reilly): http://docbookeditor.appspot.com/ Unfortunately, it's in a bit of a state of disarray because in Google's process of migrating from Docs 1.0 to Docs 2.0, they basically screwed over all the GData users in the process, which broke my tool. But as explained on the site, I made it possible to write in a Wiki-like language that looked something like the final product (using HTML/CSS rather than plaintext, saving a lot of TeX compilation and context switching to look at the generated DVI).

My editor can export to either DocBook XML or HTML, so I used the former to publish my book and the latter to publish essays on my web site. I also added support for slurping in source code from my repository so that I could be sure that the code samples in my writing actually worked. This was a bit of a pain, but definitely paid off, as readers are often infuriated by code samples that don't work. So far, no errata for code samples have been reported: http://oreilly.com/catalog/errata.csp?isbn=0636920001416