In my experience from a Googlish environment (tho mostly focusing on backend service development): 1. people don't know about check builds and have a much nicer iteration experience once they learn about it, 2: rust-analyzer red wiggles also help, and 3. a lot of the actual build time is from build/link of C++ dependencies from the rest of the codebase.
Python programmers love Rust:
- Lots of compilation errors, but then the code does what it says
- Fast! That gives an immediate benefit that people coming from C++ don't see.
One of the key requirements is that Buck2 had to be an (almost) drop-in replacement for Buck1 since there's no way we could reasonably rewrite all the millions of existing build rules to accommodate anything else.
Also Buck needs to support aggressive caching, and doing that reliably puts lots of other constraints on the build system (eg deterministic build actions via strong hermeticity) which lots of build systems don't really support. It's not clear to me whether waf does, for example (though if you squint it does look a bit like Buck's rule definitions in Starlark).
Undefined isn't the same as implementation defined. "Undefined" means you're not even talking about C any more. "Implementation defined" means which of the allowable semantics the implementors happened to choose.
Attempts to model C as being "close to the hardware" are at best misguided and usually hopelessly wrong. It's only possible by delving into the "implementation defined" parts of the spec but even then implementation s are often very bad at precisely defining what their semantics actually are.
Mono-repo -> we're focusing our efforts on few large repos
Mono-tone -> The first cryptographic Merkle-tree distributed source control system, which was a large influence on both Git and Mercurial.
Monotone was written by Graydon Hoare, who later went on to design Rust (I think he was actually designing proto-Rust at the time), so the reference to Monotone is to both Mononoke's function and implementation.
Tech lead of Mononoke here. Thanks for your comments!
The experience of using Mercurial within FB is quite different from the stock open source one. We have many local extensions, as well as integrations with the rest of our developer infrastructure. We're definitely optimizing for the linear-history monorepo model.
We don't see things as a competition between hg and git, but between good developer experiences and bad. Thus far, we've found it easier to improve the developer experience with hg than with git, so that have been our main focus.
But we feel we're reaching the limits of what we can do with hg, which is why we're investing in Mononoke. We feel that version control in general has been pretty stagnant, and we're hoping to do some neat stuff over the next few years (based on Mononoke and other projects).