Hasnain says:

Pour one out for PHP. Just kidding - this bug would happen in most codebases out there unless specific precautions were taken.

"I had been at the company something like six weeks and had changed a line of source code to fix a bug (logging), to uncover another bug (wrong argument count), to enable yet another bug (wrong units, and zero type safety) that gave 25 grand worth of funny money to anyone who clicked! And I had clicked! And I got a friend to click! And other people got it too!

What happened? They just turned off the feature until they could fix it. Those of us who had way too much credit in our accounts turned off our ads so as not to actually consume any of the "bad money", and kept them off until they reversed it out of our accounts. Then we were clear to go back to dogfooding.

And no, nobody was fired for this.

This is yet another reason why I say bare numbers can be poison in a sufficiently complicated system. If that function had demanded a type called "dollars" and the caller had another one called "pennies", it simply would not have passed the type checker/compiler. But, this was before those days, so it sailed right through."

Hasnain says:

“Proving the full conjecture — that exactly half of all integers are the sum of two cubes — will require eventually tackling the set of numbers that have more than one associated matrix. This set, which Bhargava calls “very hazy,” includes both numbers that are the sum of two cubes and ones that aren’t. Handling such numbers will require completely new ideas, he said.

For now, researchers are happy to have finally settled the question for a substantial proportion of whole numbers, and are eager to probe the techniques in the proof further. “It’s one of those beautiful things: You can explain the result very easily, but the tools are very, very much at the cutting edge of number theory,” Sarnak said.”

Hasnain says:

Sign of the times: 40,000 people are out of power because domestic terrorists shot up multiple substations in order to prevent a drag show.

Hasnain says:

“At the end of the day, it seems like at least for this kind of large-scale, complex application, the cost of pervasive runtime bounds checking is negligible. It’s tough to say precisely why this is, but my intuition is that CPU branch prediction is simply good enough in practice that the cost of the extra couple of instructions and a branch effectively ends up being zero - and compilers like LLVM are good enough at local optimizations to optimize most bounds checks away entirely. Not to mention, it’s likely that quite a few (if not the majority) of the bounds checks we removed are actually necessary, in that they’re validating some kind of user input or other edge conditions where we want to panic on an out of bounds access.”

Hasnain says:

This is pretty cool. I’ve been doing a lot of SQL lately and developer efficiency is a mess (I have a lot to learn).

“In the query on the right, the author is trying to combine timestamps in milliseconds from the table user_login_events_mobile with timestamps in nanoseconds from the table user_login_events_desktop — an understandable mistake, as the two columns have the same name. But because the tables’ schema have been annotated with user-defined types, UPM’s typechecker catches the error before the query reaches the query engine; it then notifies the author in their code editor. Without this check, the query would have completed successfully, and the author might not have noticed the mistake until much later.”

Hasnain says:

Some great wins here. When I saw people complain about JS build times and how they moved things to Rust or Go; I was (perhaps naively) assuming the tools had been optimized as much as can be in JS. Being proven wrong here.

“At this point I stopped looking, but I'd assume that you'll find more of these minor performance issues in popular libraries. Today we mainly looked at some build tools, but UI components or other libraries usually have the same low hanging performance issues.

Will this be enough to match Go's or Rust's performance? Unlikely, but the thing is that the current JavaScript tools could be faster than they are today. And the things we looked at in this post are more or less just the tip of the iceberg.”

Hasnain says:

Really cool technical story of how they built a kernel + user space driver for the M1 GPU so it could run Linux. And some great hackery in between. I promise I didn’t share this just for the Rust fanboyism.

“Normally, when you write a brand new kernel driver as complicated as this one, trying to go from simple demo apps to a full desktop with multiple apps using the GPU concurrently ends up triggering all sorts of race conditions, memory leaks, use-after-free issues, and all kinds of badness.

But all that just… didn’t happen! I only had to fix a few logic bugs and one issue in the core of the memory management code, and then everything else just worked stably! Rust is truly magical! Its safety features mean that the design of the driver is guaranteed to be thread-safe and memory-safe as long as there are no issues in the few unsafe sections. It really guides you towards not just safe but good design.”

Hasnain says:

This continues to increase my motivation to learn more about garbage collectors.

“The numbers reported represent the 50th and 99th percentile for Blink memory allocated with Oilpan across the fleet[2]. The reported data shows the delta between Chrome 105 and 106 stable versions. The absolute numbers in MB give an indication on the lower bound that users can expect to see. The real improvements are generally a bit higher due to indirect effects on Chrome’s overall memory consumption. The larger relative improvement suggests that packing of data is better in such cases which is an indicator that more memory is used in collections (e.g. vectors) that have good packing. The improved padding of structures landed in Chrome 108 and showed another 4% improvement on Blink memory on average.

Because Oilpan is ubiquitous in Blink, the performance cost can be estimated on Speedometer2. The initial prototype based on a thread-local version showed a regression of 15%. With all the aforementioned optimizations we did not observe a notable regression.”

Hasnain says:

“But there’s also a part of me that’s just like, how can you not be curious? How can you write Python for 5 years of your life and never look at a bit of source code and try to understand how it works, why it was designed a certain way, and why a particular file in the repo is there? How can you fit a dozen regressions and not try to understand where those coefficients come from and the linear algebra behind it? I dunno, man.

Ultimately nobody really knows what they are doing, and that’s OK. But between companies not building around this observation, and individuals not self-directing their educations around this observation, it is just a bit maddening to feel stuck in stupid hell.”

Hasnain says:

Great read. Beyond the details of the static analysis itself, I enjoyed the insights into how they rolled out this program at scale and the lessons learned throughout.

"The problems outlined above are hardly specific to Meta. Unexpected null-dereferences have caused countless problems in different companies. Languages like C# evolved into having explicit nullness in their type system, while others, like Kotlin, had it from the very beginning.

When it comes to Java, there were multiple attempts to add nullness, starting with JSR-305, but none was widely successful. Currently, there are many great static analysis tools for Java that can check nullness, including CheckerFramework, SpotBugs, ErrorProne, and NullAway, to name a few. In particular, Uber walked the same path by making their Android codebase null-safe using NullAway checker. But in the end, all the checkers perform nullness analysis in different and subtly incompatible ways. The lack of standard annotations with precise semantics has constrained the use of static analysis for Java throughout the industry."