pgaultier.bsky.social

pgaultier.bsky.social

@pgaultier.bsky.social

87 followers26 following52 posts

Rant: if you are designing a programming language from the ground up and the only solution you have for data races is “use the runtime race detector”, then you have not spent enough time in the trenches suffering from data corruption and rare, incoherent errors due to data races.

Things that help: immutability at the language level (“const”), explicit shallow vs deep copy to avoid accidental sharing, documentation, high level concurrency constructs. Things that make life harder: implicitly capturing closures, not documenting what is thread safe or not in the standard library

Tracking and fixing many Go data races lately, I am getting a new found understanding and empathy for all these Mozilla developers who jumped on Rust the moment it was halfway usable. Like a lost, thirsty traveler in the desert seeing an oasis from afar. #golang #rust

There are ways to reduce harm: do not use closures (prefer standalone functions) to avoid accidental captures, use value types that are passed by value (copied), etc. But the language gives you no help at all and many ways to shoot yourself in the foot.

pgaultier.bsky.social reposted

I joined the Go team just after exploiting a carry bug in a Go assembly core, and I've been looking for ways to prevent the next one ever since. This year's attempt is very promising: mutation testing swapping e.g. ADC → ADD, CMOV → MOV, etc. to provide test coverage for constant time assembly.

words.filippo.ioGo Assembly Mutation TestingTest coverage of delicate Go cryptographic assembly through a new mutation testing framework.

Me: wow, my new work got me the new M4 MacBook Pro with 48 GB of RAM, every build is going to be instant! npm run build: Worker terminated due to reaching memory limit: JS heap out of memory. Tim Apple giveth, JavaScript taketh away

pgaultier.bsky.social reposted

Replying to @thephd.dev

Modern webdev is so much. I'm installing so many packages and gems and I'm completely unsure of what is doing how and where. One day I'll have to get used to this stuff. It's very different from Systems Engineering.

Today I wanted to dtrace a nodejs application at work but then I discovered that nodejs removed dtrace support some time ago (static probes). Bummer. Still can do a lot just dtrace-ing system calls… but still, unfortunate. Reminds me of the talk “platform as a reflection of values…

Also Node is just a C++ program using libuv so experience with either can help dtracing using usdt probes. I seem to remember years ago “jstack()” in dtrace showed the js call stack, but it seems this does not work anymore (or I did not yet find a way).

Me, after 10 years of coercing various crazy C & C++ build systems and mixed language codebases to work everywhere even on old unsupported BSDs: Unlimited power! I can do anything ! Me after 2 weeks of having to work with npm and the JavaScript world: I’m in danger.

pgaultier.bsky.social reposted

I recently had the honor of interviewing Zen’s chief architect Mike Clark! I tried to fit in as many microarchitecture questions as I could, including x64 vs ARM ISA power efficiency, 4k vs larger page sizes, 64-byte cache lines, scatter/gather and more: www.computerenhance.com/p/an-intervi...

computerenhance.comAn Interview with Zen Chief Architect Mike ClarkZen is one of the most important microarchitectures in the history of the x86 ecosystem.

How it’s going: due to increasing cloud cost, the new company policy is to have every employee get permission and justify it in writing before creating a new VM in Azure. Even if it’s a temporary, small instance for a few hours.