Found something funny when reading Tailscale code.
They use a Cyrillic letter "ж" (reads as "zh") for the variable which shouldn't be exposed to callers and mutated. This is an artificial barrier for human devs that should raise concerns when trying to type it.
Apparently it looks like an asterisk meaning it's a pointer. But for me it's a familiar letter which I didn't expect to see in the code and was like Ж? WAT?
Yeah, you can use unicode letters in Go code if you want.
I now really want to use something like that in my code because I bet it'll make me smile every time I see it
We've decided to sunset Arc on December 22, 2026.
That's not an easy sentence to write. We spent years building Arc and celebrating each and every release along the way: we have so much pride and love for what we made alongside the Arc community.
Our priority is to deliver best-in-class security for our members. Keeping a browser secure takes constant, dedicated work that is only increasing in the age of AI. Dia was built from the ground up to meet today’s security standards, so that's where our engineering and security teams will focus moving forward.
We've worked to make switching to @diabrowser as easy as possible for Arc members. Here's how:
· Your passwords, bookmarks, extensions and history come over to Dia seamlessly.
· Spaces, Folders, and Tab Groups are in Dia and import over with your data intact.
· Dia now surpasses Arc benchmarks in stability, speed, and security.
· The browser features you use in Arc are free in Dia, and the AI is optional.
Thank you for using Arc, for pushing us to make it better, and for building alongside us. The team that made Arc is the same team behind Dia, and some of our most ambitious work is just ahead. We'd love for you to be there with us when it lands.
they sorta have a thing for singaporeans
Greptile has raised a $50M Series B led by Menlo Ventures. The round values the company at $750M.
Greptile reviews and tests more than 1% of all PRs opened on GitHub every day. Thousands of engineering teams including Nvidia, Coinbase, Decagon, and Vanta use Greptile as their independent and central validation layer.
Fewer than 50 people, we are a small, talent-dense team of engineers and researchers in a quiet corner of San Francisco. If you’re interested in joining us, we’d love to hear from you.
sky retweeted
We had a security breach last night related to a large scale distillation attack that impacted 1.4% of OpenCode Console users
We have notified them all this morning via email. If you did not get an email you were not impacted, it was a subset of users who had external providers linked
The incident is ongoing so we cannot share more details at this point but we are working with Anthropic, OpenAI, and Google to remediate
“systems, perf., Interence, profiling and physics”
Tbh, I spent about 3 weeks on some really fun perf. work in Apache DataFusion, and it got merged :) Long AND filters are now up to 22x faster. Gotta share what went into it [not just the numbers].
So here's the thing i learnt. When DataFusion sees a AND b AND c AND d, it builds a chain of nodes, (((a AND b) AND c) AND d). Each node had a neat little trick: if at most 20% of rows survived the left side, it shrank the batch to just those rows, ran the right side on them, then scattered the results back to full size.
Sounds smart, right. But it was checking the whole prefix so far, not the condition coming next. So once a chain got selective, every step after that shrank and re-expanded the entire batch again [every column of it], just to run something as cheap as x < 70. That honestly bugged me. Why should the 10th condition pay to re-filter the whole batch again?
So I made it evaluate the whole chain in one pass. It keeps one running result, and once only a few rows are still undecided, it shrinks the batch only before conditions that are expensive or can fail. Cheap comparisons just run on every row, because shrinking costs more than comparing. NULL rows stay around [NULL AND false is still false], everything gets scattered back only at the end, and it stops early the moment every row is false.
What I cared about most was safety. An expensive or fallible condition [like a division] never sees a row the old code wouldn't have shown it, so this can't create new errors. The randomized tests check it against plain AND logic on left-deep, right-deep and balanced trees.
On the reviewer's ARM machine:
- long AND chains: up to 22.5x faster
- TPC-H Q6 and Q12: 1.20x and 1.22x faster
- TPC-DS: 11 queries 5 to 10% faster
- ClickBench: flat
Well, review did catch one real regression. When the first condition already rules out every row, I was building a list of all the conditions before checking it, so 70 ns became 108 ns. Walking the tree in place fixed it, and now it's 63.8 ns [faster than main :)].
My favorite bug though: after that fix, one benchmark on my x86 machine looked 9% slower. About the same instruction count, and Arrow's hot comparison loop was byte-for-byte identical. It had just shifted 16 bytes relative to the CPU's 64-byte blocks, because I removed some code. Once I forced 64-byte loop alignment on both builds, the gap was gone. Removing code can slow down code you never touched, which is kinda wild.
Biggest lessons: run the existing benchmarks yourself before review, and real regressions repeat while noise just moves around.
I'm writing a full article soon [how i reproduce, every decision, the dead ends, and the code], so any feedback would be much appreciated! Huge thanks to Adrian and Jay for the reviews :), thank you!!
github.com/apache/datafusion…
hilarious seeing people claim credit for their work when the only involvement they had was being a meat proxy
