squirrellous

It was pretty clear to me after interacting with the first popular ChatGPT version around end of 2022 that all knowledge jobs will be replaced sooner or later. I don’t think coding is somehow special. What we have right now is an intermediate stage where “taste” still matters, but this won’t last forever.

I also believe that when all knowledge jobs are replaced, something fundamental needs to change in society. Trying to anticipate and prepare for that right now is premature.

If you believe juniors are already not safe, it’s only a question of time before seniors are in the same position. First they came for the socialists, etc etc.

I’m sure this has crossed someone’s mind but why isn’t this called zlibc? :-)

If you are at a place where that’s true, cherish it. It won’t always be true.

Another somewhat known case of a spinlock is in trading, where for latency purposes the OS scheduler is essentially bypassed by core isolation and thread pinning, so there’s nothing better for the CPU to do than spinning.

Not a direct answer to your question, but I’m recently trying to adopt the mindset of letting Claude “prove” to me with very high confidence that what they did works. The bar for this would be much higher than what I’d require for a human engineer. For example it can be near 100% test coverage, combined with advanced testing techniques like property-based tests and fuzz tests, and benchmarks if performance is a concern. I’d still have to skim through both the implementation and tests, but it doesn’t have to be a line by line review. This also forces me to establish a verifiable success criteria which is quite useful.

Results will vary depending on how automatically checkable a problem is, but I expect a lot of problems are amenable to some variation of this.

> But I will never call into a library I don't fully understand while holding a mutex again. Fool me once.

Nice sentiment and an admirable goal. Not really actionable in practice. Even if we disregard all userspace libraries out there, fully understanding the most frequently used syscalls is a monumental task already. You have to pick your battles in terms of understanding parts of a complex system.

Anecdotal perspective. I’m usually ok with others copying my code since code feels less personal (for lack of a better word). The other day I found a prompt for internal AI that copied my technical arguments in prose verbatim without attribution. This felt very wrong and invasive. It made me much more sympathetic to people with intellectual work out in the public domain.

Whether it is significant is highly specific to the domain. I think protobuf has accumulated enough problems that every large scale application will eventually run into a footgun or two. Almost all of them have to do with the generated types, not the wire format.

Examples that can noticeably slow things down even for “normal” web apps: map types and deeply nested messages.

I’m aware what TCP_CORK does. I’m not seeing how it helps the situation in the post.

Ah, maybe you are saying it doesn’t help the situation in the post. That’s what I misunderstood.

Can you explain how TCP_CORK helps here? The chaff packets are spaced 20ms apart and sent per socket, so I don’t see how TCP_CORK could help unless it coalesced across 20ms intervals? But coalescing is clearly not an option for the intended obfuscation effect of the original feature.

It depends on the language and codebase. For something very dynamic like Python it may be the case that grepping finds real references to a symbol that won’t be found by a language server. Also language servers may not work with cross-language interfaces or codegen situations as well as grep.

OTOH for a giant monorepo, grep probably won’t work very well.

I work with an amazing QA team right now. They are good programmers that don’t mind doing lots of grunt work, understand the goal of the software deeply, collaborates extremely well with other teams, and are just all around great people. I expect they would kill it as a non-QA dev team as well, so I’m always grateful to have such partners.

Does anyone knowledgeable know whether it’s possible to drastically reduce the overhead of reading from procfs? IIUC everything in it is in-memory, so there’s no real reason reading some data should take the order of 10us.

This is my go to article every time I think about using file locking to solve a problem.

Also, OFD locks are great if you target Linux only these days.

For some reason Opus 4.5 is blowing up recently after having been released for weeks. I guess because holidays are over? Active agent users should have discovered this for a while.

I don’t have much evidence but feel like fsync has overshot its significance. It’s really important in databases and that’s fine, but a lot of software can handle (very occasional) kernel / hardware crashes by e.g. restoring data from an external backup, and can benefit from the mmap guarantee that process level crashes won’t lose any data.

Thanks. These are actually achievable with a custom protocol buffer implementation, but I agree at that point one may as well create a new format.

FWIW the other use case I was expecting is something like database queries where you’d select one particular column out of a json-like blob and want to avoid deserialization.

Would you mind sharing what problems motivated Lite? Curious what are the typical use cases for selective reading / in place modification of serialized data. My understanding is that for cases that really want all of the fields, the zero-copy solutions aren’t much better than JSON / protobuf, so these are solutions to different problems.

Second this. Once I setup GitHub actions with Hugo (there’s one readily available), I rarely build the blog locally anymore. New article drafts become GH pull requests, and once ready they get merged and published. This also works on mobile well enough.

One reason to use shared memory mmap is to ensure that even if your process crashes, the memory stays intact. Another is to communicate between different processes.

Not sure how much value there is in beating Swisstables in very particular cases like this. For specialized cases, one can beat Swisstables by more margin and less effort by using more memory and decreasing load factor, thereby decreasing collisions. You don’t even need SIMD in that case since collisions are rare.

Perhaps someone can enlighten me on this. I never quite understood the sentiment of treating money-related tech as somehow more critical than others. The effects of large SaaS services failing and the bank failing can be quite similar - businesses interrupted, money lost, etc. but it’s typically not life and death, so the importance of reliability should be similar.

I can understand treating social network sites as less critical, of course.

Apologies. Please feel free to delete it. That was not the intention.

[flagged]

I feel this is easier if you treat day jobs almost as a side hustle and have significant hobbies and life elsewhere. It’s more difficult if your career heavily overlaps with what you love doing (e.g. software), except the career comes with unwanted things like politics, promos, managing others, etc.

Google is a somewhat widely known place where promo is a huge problem, but the problem isn’t particular to Google. Generally companies will require you to repeatedly “prove” you are worth the additional compensation before agreeing to it. The friction varies, but the structural incentives are always there. Therefore if the goal is to maximize earnings, and assuming you are a high performer, it’s in your best interest to job hop once in a while.

To not play this made-up game, you either decide to stop caring about compensation, or be your own boss. Of course these are not always realistic depending on one’s life situation.

IIRC the author has a good track record with programming languages.

I wish Google would open source their gtl library. Similar utilities exist elsewhere but not in the same consistent quality and well-integrated package.

I particularly like the “what to do for flat profiles” ad “protobuf tips” sections. Similar advice distilled to this level is difficult to find elsewhere.

Honest question. Why is a Rust rewrite of coreutils getting traction? Nobody thought it’s a good idea to rewrite coreutils with Go, Java, Python, C++, etc etc. It can’t just be memory safety.