I work on the Protocol Buffers team at Google. I created upb (a small C protobuf implementation) and Bloaty (an ELF/Mach-O/PE/WASM binary size profiler).
Seattle, WA
Joined May 2011
- Tweets300
- Following117
- Followers607
- Likes354
Josh Haberman retweeted
This debugging technique should be common knowledge, but I run across it all the time.
When an error message is confusing, by far the most practical method to figure it out is to:
1. copy the file to a new file, save the original
2. delete code until the message goes away
3. revert to the previous version that still produced the error
4. goto step 2, and delete something else
5. continue until you have the minimum piece of code that generates the error
This usually clears up the understanding of the issue.
The D "dustmite" program (created by crackerjack developer Vladimir Panteleev) can do this automatically.
Recently, I was handed a program with a baffling error in it. I noticed it was loaded with templates, conditional compilation, irrelevant functions, and complex declarations.
Deleting all that fluff out of it led directly to the problem.
This is the most powerful debugging technique I know of. I use it all the time.
New from me: "No-Panic Rust: A Nice Technique for Systems Programming": blog.reverberate.org/2025/02…
I'm getting more and more spam texts these days. I can imagine a future where texting platforms don't allow cold calls from unknown contacts without an extra token.
The extra token could come from a mutual friend who shared the contact, or an in-person contact exchange.
Rust doesn't seem to have the concept of an internal/private crate. Any dependency of a public crate must also be publicly published on crates.io. There's no way to split a library into multiple crates in a way that is invisible to end users.
You can break a crate into private modules. But modules are allowed to have circular dependencies between them. So within a crate, there is no enforced discipline to prevent the crate from being arbitrarily tangled spaghetti.
File size of a trivial Python extension (Rust/pyo3): 401kB
File size of the protobuf Python extension (C): 277kB
The Rust extension has a single function that adds two numbers.
The C extension implements all of protobuf.
Both figures exclude debug info.
My biggest takeaway from Rust so far is that borrows should be relatively short-lived. While it is possible to put references in a long-lived struct, it creates spiraling complexity and is overall not worth it.
Rust wants structs to own their members.
I hear C is adding new stuff like lambdas. Here is what I'd rather see:
- musttail for guaranteed tail calls (clang.llvm.org/docs/Attribut…)
- arithmetic with overflow checking (gcc.gnu.org/onlinedocs/gcc/I…)
- uint128_t (or at least _umul128())
Less sugar, more low level capabilities.
Another Rust-focused post: my experience trying out arenas in Rust: blog.reverberate.org/2021/12…
I wrote a blog entry that compares thread-safety concepts between C++ and Rust: blog.reverberate.org/2021/12…
This is a fleshed-out version of my previous Twitter thread on the same subject: xitter.cf/JoshHaberman/status/14…
It appears that Rust's "Sync" trait is equivalent to the C++ concept of thread-compatible: abseil.io/blog/20180531-regu…
Sync does *not* map to C++'s concept of thread-safe. Example: Vec is Sync, but would not be considered thread-safe in C++.
It appears that Rust's "Sync" trait is equivalent to the C++ concept of thread-compatible: abseil.io/blog/20180531-regu…
Sync does *not* map to C++'s concept of thread-safe. Example: Vec is Sync, but would not be considered thread-safe in C++.
Thread-safe in C++ means "allows shared mutable access". But Rust forbids this at the language level. So it would be useless to implement a Rust type that implements the C++ concept of thread-safe.
The ELF/DWARF naming scheme makes for some odd Google results when you're looking for technical information.
I'm implementing Fission / split DWARF for github.com/google/bloaty. When I Googled "dwarf skeleton" I did not get the results I was looking for.