Evan Martin

> Also, I see you amended your original comment with a jab against me for the type keys post.

I didn't realize you were the same person who wrote that blog post, and I edited it to include it when I realized. I linked your amended version, not your initial version if that's of any worth.

And you're correct it's not closed. I still stand by that particular proposal is going nowhere. You can make any proposal you want. It hasn't even moved to the design stage yet in 3 years, so I'm not sure why it's something you hang on to as a signal error handling is changing. Take generics for example, and the years (decade) of work that it took.

This is unsolicited blog feedback:

Your blog and writing style doesn't read like it comes from a place of humility and learning, but from a place of authority. Sometimes that's OK, but in your case, feels unwarranted. And the constant push to get it on to HN or Reddit or N other platforms so it can spread... Thought leadership as an aspirational goal has never been something I look for in blogs I read (I recoil and go elsewhere when I sense this is the goal).

I understand it's hard work, and you want others to see it, but just someone else's perspective.

Some blogs that I really enjoy (and I hope others emulate so I'm sharing):

- http://neugierig.org/software/blog/

- https://brooker.co.za/blog/

This comment (https://news.ycombinator.com/item?id=32702062#32703005) from this thread links to this post: https://neugierig.org/software/chromium/notes/2011/08/zygote.html

TL;DR: right after launch, Chrome forks off a helper process which is then responsible for forking off child processes, so that all child processes use the same process image as the main Chrome process. It also opens all files it will need right after launch and just re-uses the same file descriptors, so it always keeps references to the old files. This is complicated and brittle and a source of bugs, but when everything works and nobody makes a mistake, it means the old Chrome can keep running without problems even after all its files have been replaced with those from a new Chrome.

At least that's how it worked in 2011 according to Evan Martin.

Great post.

A point that neither this article nor the recent ninja retrospective (http://neugierig.org/software/blog/2020/05/ninja.html) touch on though is that hashing of files is an important step if you'd like to keep caches locally, but especially if you'd like to keep caches remotely.

A key reason that Bazel-alikes (including http://www.pantsbuild.org, which I work on) hash things is for use in cache keys. And many of those systems use file watching facilities (notify, fsevents) to determine whether files need to be rehashed. If done properly (i.e.: no false negatives), this is significantly faster than checking file mtimes, and it allows for "early cutoff", where if after hashing the digest of a file has not actually changed, you can skip rebuilding its dependents.

There's no secret sauce. The typical aphorisms of software development are generally correct and apply here:

* internalize the cost of core changes and don't push them downstream unless you have a really good reason
* staff a core team to take care of high ROI horizontal efforts that have high fixed cost to do efficiently, e.g. TypeScript migration of a massive codebase
* be careful of what you take on
* complexity and code are costs and not end goals

Reading them is one thing but seeing the principles play out in detail amidst the mess of reality was illuminating for me. The author's blog[1] touches on these themes a bit more and I think are a good glimpse into their stewardship of the TS/JS codebase.

[1] - http://neugierig.org/software/blog/

That assumption relies on two uncertainties:

1. The probability of discovering something in all that binary code, especially with the intricate and non-orthogonal nature of x86/x64 assembly and odd compiler optimisations. This isn't some 80's game.

A comparison:

28500000 = Chrome binary size [1]
750000000 = Human Genome size (converted to bytes - 1BP = 2bits so 4BP per byte) [2]

So we're only 26x more complicated than Chrome and we have absolutely no fucking idea what is going on with us most of the time.

2. The probability of a vulnerability being published to Google versus selling it on the private market.

[1] http://neugierig.org/software/chromium/bloat/

[2] http://www.biostars.org/p/5514/

In general I agree. My only current exception is that I use Brave[1] instead of Chrome on Android, because Chrome is missing adblocking. It appears that the company behind Brave is large enough to keep the fork somewhat up to date (compared with several other forks that are only updated very infrequently).

Also not only security updates are an issue. Some of the previous forks have been maintained by people who hardly had any idea of what they were doing. Interesting blog post about the Iron fork: http://neugierig.org/software/chromium/notes/2009/12/iron.html

[1] https://en.wikipedia.org/wiki/Brave_(web_browser)