akshayshah

In at least some parts of tech, it's common to view Facebook as a "mass surveillance and data collection system." But even after Cambridge Analytica and all the ensuing scandals, I don't think that this view is common among the general public. More commonly, I meet people who think of Facebook as a well-intentioned but sometimes careless product development company.

The shocking part of this article, and many similar articles, is how deeply misuse of user data and cavalier privacy practices are baked into Facebook.

Wonder Jason would evaluate Basecamp's own recent meltdown using this metric: a waste of time and attention, or a purge of ongoing distractions at work?

I used to work on the team that built this tool, and I've been eagerly awaiting its open source release. Of course, I think it's fantastic :)

There's so much interesting work being done on static analysis in Go (semgrep, ruleguard, etc), but I haven't seen similarly powerful refactoring tools. Gopatch is one approach to building a refactoring power tool - I'm excited to start using it, but I hope that it also inspires people (and companies!) to build even more capable tools.

Scaling Mercurial at Facebook: https://engineering.fb.com/2014/01/07/core-data/scaling-merc...

Agreed! This is super cool, and I hope a working prototype makes discussion of the formal proposal move a little faster.

I suspect you're right about overhead. 10us seems much more aggressive than even the author is actually suggesting, though - the motivating example was a service with latencies in the 10s of ms, so sampling every few ms would be sufficient.

Also, if anyone reading isn't familiar with sampling profilers, Felix gave a great talk explaining them: https://github.com/felixge/talks/blob/master/fgprof/

At least when I was at Uber (left in mid-2019), this was absolutely the case: most services weren't CPU-bound, but a few were. Rewriting the CPU-bound services in C++, Rust, or some other language might have helped, but would have required a _ton_ of well-understood, reliable libraries for networking, observability, authn/authz, database access, etc.

In nearly all cases, there was plenty of room to make the Go service faster. A more careful choice of data structure and algorithm, finer-grained locking, fan-out across a goroutine pool, or just avoiding a zillion heap allocations solved most problems. I don't recall any cases where Go was simply incapable of meeting our performance needs.

As a side benefit, services with more stringent performance requirements often exposed inefficiencies in widely-used libraries. Optimizing those libraries made every Go service faster and cut our overall compute spend. Avoiding rewrites in C++ or Rust let those wins add up over time.

Full disclosure: I used to work in Uber's infrastructure group.

I'm always happy to see improvements to Go's profiling - the standard library's profiling is good, but it hasn't improved much since Go 1.0 (it took years just to get flame graphs integrated, and it's still near-impossible to get a usable dump of the in-memory object graph).

That said, I'm _very_ wary of tools that require a fork of the compiler and/or runtime. Uber's programming language research group is small (though mighty) and has a lot of demands on their time. Even over the medium term, it'll be hard to allocate time to keep this project current.

In the Go issue tracker, there's a long discussion [1] of the formal proposal [2] for these improvements. My understanding of the feedback is that the changes introduce too many Linux and x86-specific APIs. I'd love to see the author narrow the proposal to just improve timer fidelity when the OS exposes the PMU, without any new APIs. The more controversial proposal to collect richer platform- and architecture-specific data can be discussed separately.

Discussion [1]: https://github.com/golang/go/issues/36821

Proposal [2]: https://go.googlesource.com/proposal/+/refs/changes/08/21950...

Edit: Yes, it's decompiled bytecode, not the original source.

Here's an example: https://github.com/augustgl/tiktok_source/blob/master/df_min...

Huge +1 to Martin Kleppmann's "Designing Data-Intensive Applications." It's the best single-volume introduction I've seen to the fundamentals of databases, queues, and the complications inherent in making those systems distributed.

Absolutely - the whole project depends on GitHub's language detection, which is sometimes a little odd.